Airplane
Are you ready to fly? - by blgsvnomer
The following post by 0xb0b is licensed under CC BY 4.0
Recon
We start with a Nmap scan and find only three open ports. 22, 6048 and 8000.
Unfortunately, a service and default script scan does not tell us what is behind 6048. At 22, it is OpenSSH 8.2p1, and at port 8000, we are dealing with a Python Werkzeug web server.
The first visit to the index page of Endpoint 8000 shows us that only static pages are loaded. This is done via the page parameter http://airplane.thm:8000/?page=index.html. Here we could find an entry via Local File Inclusion.
We start another Gobuster scan and try to find more directories, but only find the route/airplane.
We confirm our assumption about LFI. We can include the file /etc/passwd, which is downloaded directly. When accessing files to which we are not authorized, we receive an internal server error. Because the files are downloaded directly, we probably do not have the possibility of log file poisoning this time.
We see we have the users hudson and carlos. Unfortunately, we are not successful in probing for the user.txt in /home/hudson or /home/carlos.txt.
Let's check the environment variable of the current process.
We see that the app is run in the context of hudson, let's investigate further on the app itself.
We can find the app.py in the following directory:
Unfortunately, there isn't anything more. The app itself just provides the index and airplane page, and it's vulnerable to LFI.
Next, we probe /proc/[pid]/cmdline, to investigate what might be running on port 6048. /proc/[pid]/cmdline is a file in the Linux proc file system that contains the command-line arguments used to start the process with the specified process ID (PID). This can either be achieved by FuFF or a custom script fetching each possible ID. If the port is used as a parameter, we might be able to identify what is running on 6048.
On PID 536 in this case, we can see that a gdbserver is running on 6048.
The following show cases a script to fetch the first 1000 pids.
Shell as hudson
With the information we have gathered so far we should be able to get inital foothold. Since we know a gdbserver is running in the background, we can research how to use it to our advantage, for example to obtain a reverse shell. HackTricks has a great resource on that topic and provide step by step commands to upload and execute a reverse shell using a gdb server:
The following is an example provided by HackTricks.
We create the reverse shell binary using msfvenom.
Next, we set up a listener on port 4444.
We run gbd on our local binary and start a remote debugging connection via target extended-remote 10.10.242.124:6048. Then we copy our binary to /home/hudson/binary.elf via remote put binary.elf /home/hudson/binary.elf and execute it set remote exec-file /home/hudson/binary.elf run.
We get a connection back and are the user hudson. Next, we upgrade our reverse shell. We cannot find the first user flag here, so we have to move on to the other user.
Shell as carlos
After running LinPEAS we find the SUID binary find, owned by carlos.
Using the provided payload from GTFOBins...
... we are able to escalate to carlos and find the first flag in the home directory of the user.
Shell as root
We can now add a public RSA key to the /home/carlos/.ssh/authorized_keys file to establish a more stable shell using ssh. We create a new key pair using ssh-keygen.
Next, we place the public key into the authorized_keys of carlos.
After applying the correct permission, we are able to use our private key to log in as carlos to the machine. Next, we see we are able to run /usr/bin/ruby /root/*.rb using sudo without the need to provide a password. Here, we have the possibility to spawn a root shell by executing an .rb file that does exactly that. Since we have a wildcard in the path, we can place our script outside of root and still execute it.
We craft a script to spawn a bash. We place it in/home/carlos/evil.rb and call it via sudo /usr/bin/ruby /root/../home/carlos/evil.rb. We are root and find the last flag in /root/root.txt.
Last updated
Was this helpful?