Tr0ll 1

Overview


Objective:  Get Flag

OVA Link: https://www.vulnhub.com/entry/tr0ll-1,100/

Tools used: netdiscover, nmap, nikto, wireshark, hydra, scp, a brain


To start, we’ll get the IP of the tr0ll VM. I usually just use netdiscover as follows:

 

Next, we can do a quick nmap scan to see what we have going on. We can see telnet, SSH, and HTTP ports open.

Starting Nmap 7.40 ( https://nmap.org ) at 2017-06-10 13:13 EDT
Nmap scan report for 192.168.56.11
Host is up (0.00011s latency).
Not shown: 997 closed ports
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 3.0.2
22/tcp open ssh OpenSSH 6.6.1p1 Ubuntu 2ubuntu2 (Ubuntu Linux; protocol 2.0)
80/tcp open http Apache httpd 2.4.7 ((Ubuntu))
MAC Address: 08:00:27:BD:08:3E (Oracle VirtualBox virtual NIC)
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel

 

Going onto the web page, we can see a troll face, which I guess is fitting. It doesn’t look like the site is using a standard CMS we’re going to exploit either.

 

To get some more info, I’ll run a nikto scan to see if there’s anything obvious I can’t see.

nikto -h 192.168.56.11
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP: 192.168.56.11
+ Target Hostname: 192.168.56.11
+ Target Port: 80
+ Start Time: 2017-06-10 13:19:32 (GMT-4)
---------------------------------------------------------------------------
+ Server: Apache/2.4.7 (Ubuntu)
+ Server leaks inodes via ETags, header found with file /, fields: 0x24 0x500438fe37ded 
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ Entry '/secret/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ "robots.txt" contains 1 entry which should be manually viewed.
+ Apache/2.4.7 appears to be outdated (current is at least Apache/2.4.12). Apache 2.0.65 (final release) and 2.2.29 are also current.
+ Allowed HTTP Methods: GET, HEAD, POST, OPTIONS 
+ OSVDB-3092: /secret/: This might be interesting...
+ OSVDB-3233: /icons/README: Apache default file found.
+ 7536 requests: 0 error(s) and 10 item(s) reported on remote host
+ End Time: 2017-06-10 13:19:48 (GMT-4) (16 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

 

We have some interesting finds to go through! First up is the /secret/ directory, which gives us nothing to work with but:

 

Looking at the /robots.txt, we can see it references the same directory. No need to go there again. At this point, we’re better off moving to something else. Back up in the port scan, we can see ftp is open and check for anonymous access. Lo and behold, we can get in and retrieve a .pcap file!

Connected to 192.168.56.11.
220 (vsFTPd 3.0.2)
Name (192.168.56.11:root): anonymous
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
-rwxrwxrwx 1 1000 0 8068 Aug 10 2014 lol.pcap
226 Directory send OK.
ftp> get lol.pcap
local: lol.pcap remote: lol.pcap
200 PORT command successful. Consider using PASV.
150 Opening BINARY mode data connection for lol.pcap (8068 bytes).
226 Transfer complete.
8068 bytes received in 0.00 secs (7.7097 MB/s)
ftp>

 

We can open the .pcap file in wireshark and see what we have. This part was a little confusing. We can see a couple TCP streams to observe, one references a file called “secret_stuff.txt” and another stream has a message to mock us.

 

Here comes the troll part of the challenge. While I can summarize in a paragraph what the next step is in a few seconds, it took me quite a long time to realize what we were supposed to get out of this .pcap file. Essentially, sup3rs3cr3tdirlol is actually a hint to a web directory, /sup3rs3cr3tdirlol/.

 

Here we can see a file to download. This took me a little bit to figure out as well, however, here you can see the process I went through figuring out the hint to this file. Additionally if you’re running a 64bit OS, you’re going to have to install a couple 32 bit packages to be able to read this file properly.

 

At first, I ran through the elf file with readelf -a <filename>, however, there really wasn’t anything I can find to go on. Then I remembered the wireshark directory hint and well..

 

Ok now we have two folders, I downloaded the contents with wget and you can see the output below. The Pass.txt file was located in /this_folder_contains_the_password/ directory, while the which_one_lol.txt was located in the /good_luck/ directory. First thought? Username list and password to brute force the SSH.

root@kali:~/Documents/Vulnhub/tr0ll# cat Pass.txt 
Good_job_:)
root@kali:~/Documents/Vulnhub/tr0ll# cat which_one_lol.txt 
maleus
ps-aux
felux
Eagle11
genphlux < -- Definitely not this one
usmc8892
blawrg
wytshadow
vis1t0r
overflow

 

Ok so first off, I cleaned out the ” < — Definitely not this one” part of that list. Next I ran hydra using the two files and… got nothing. Hm. This was ridiculous actually. I got frustrated enough where I had to walk away, took a break, and sat down to give it all a second shot. Like the usual trolling, the situation isn’t what it seems. You’d THINK the password would be ‘Good_Job_:)’, but it’s not. I’ll just post this hydra screenshot and you can see what actually is going on.

 

So we can now login! Quick check of the kernel version and /tmp folder shows we can look up an exploit (old kernel) and use the /tmp folder as a upload vector.

 

A quick search online shows a great exploit usable on this kernel version. I uploaded it to the target host using scp as follows:

 

We can now see the exploit on the troll box, compile it, run it for root, and obtain the flag!