This is my solution to the Tr0ll: 1 challenge by Maleus. The challenge and his webpage can be found here:
Tr0ll was inspired by the constant trolling of the machines within the OSCP labs.
The goal is simple, gain root and get Proof.txt from the /root directory.
Not for the easily frustrated! Fair warning, there be trolls ahead!
After locating the IP address of the target machine on our virtual network (we were not provided with login or networking information), I added the address to my
/etc/hosts to prevent from having to keep typing out the entire IP.
Currently scanning: Finished! | Screen View: Unique Hosts 4 Captured ARP Req/Rep packets, from 4 hosts. Total size: 240 _____________________________________________________________________________ IP At MAC Address Count Len MAC Vendor / Hostname ----------------------------------------------------------------------------- 192.168.171.1 00:50:56:c0:00:08 1 60 VMware, Inc. 192.168.171.2 00:50:56:fe:d9:5a 1 60 VMware, Inc. 192.168.171.133 00:0c:29:29:73:49 1 60 VMware, Inc. 192.168.171.254 00:50:56:f0:f5:0a 1 60 VMware, Inc. [email protected]:~/troll# echo "192.168.171.133 troll" >> /etc/hosts
Now that we have that out of the way, let’s start with an NMAP scan to get some more information.
[email protected]:~/troll# nmap -Pn -sT -A -p- -T4 troll Starting Nmap 7.31 ( https://nmap.org ) at 2017-01-03 00:56 CST Nmap scan report for troll (192.168.171.133) Host is up (0.00026s latency). Not shown: 65532 closed ports PORT STATE SERVICE VERSION 21/tcp open ftp vsftpd 3.0.2 | ftp-anon: Anonymous FTP login allowed (FTP code 230) |_-rwxrwxrwx 1 1000 0 8068 Aug 09 2014 lol.pcap [NSE: writeable] 22/tcp open ssh OpenSSH 6.6.1p1 Ubuntu 2ubuntu2 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 1024 d6:18:d9:ef:75:d3:1c:29:be:14:b5:2b:18:54:a9:c0 (DSA) | 2048 ee:8c:64:87:44:39:53:8c:24:fe:9d:39:a9:ad:ea:db (RSA) |_ 256 0e:66:e6:50:cf:56:3b:9c:67:8b:5f:56:ca:ae:6b:f4 (ECDSA) 80/tcp open http Apache httpd 2.4.7 ((Ubuntu)) | http-robots.txt: 1 disallowed entry |_/secret |_http-server-header: Apache/2.4.7 (Ubuntu) |_http-title: Site doesn't have a title (text/html). MAC Address: 00:0C:29:29:73:49 (VMware) No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ). Network Distance: 1 hop Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE HOP RTT ADDRESS 1 0.26 ms troll (192.168.171.133)
We have FTP (with anonymous login enabled), SSH, and an Apache web server. We don’t have very much to go off of so let’s start with the web server.
Staying true to its name, the web server immediately presents us with a troll. Nothing in the source, looks like a dead end to me. Let’s check out the
/secret directory that NMAP picked up.
No surprise here…At this point, I tried to search for data hidden in the images but I found nothing useful. Web server seems like a dead end for now, so I’m going to check out that FTP server. After logging with with
anonymous:pass, I see that there is a pcap file for us to download.
[email protected]:~/troll# ftp ftp> open (to) troll Connected to troll. 220 (vsFTPd 3.0.2) Name (troll: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 09 2014 lol.pcap
I download the pcap file and throw it into Wireshark. After skimming over the capture, I notice a file named
secret_stuff.txt. Looking down a little further, I notice that this file was downloaded and the data is readily available to read.
After scratching my head over this message for probably far too long, I finally figure out that this is a directory on the web server. I copy and paste it into my browser and finally make some progress!
Here we have some kind of file named
roflmao. I download it and run the
file command on it, it is a 32-bit executable. Upon running it, we get this message
Find address 0x0856BF to proceed
My first instinct is to start digging into the executable itself. I run
objdump on the file but discover that 0x0856BF is too high of a memory address and isn’t found within the binary.
[email protected]:~/troll# objdump -d roflmao roflmao: file format elf32-i386 0804841d <main>: 804841d: 55 push %ebp 804841e: 89 e5 mov %esp,%ebp 8048420: 83 e4 f0 and $0xfffffff0,%esp 8048423: 83 ec 10 sub $0x10,%esp 8048426: c7 04 24 d0 84 04 08 movl $0x80484d0,(%esp) 804842d: e8 be fe ff ff call 80482f0 <[email protected]> 8048432: c9 leave 8048433: c3 ret 8048434: 66 90 xchg %ax,%ax 8048436: 66 90 xchg %ax,%ax 8048438: 66 90 xchg %ax,%ax 804843a: 66 90 xchg %ax,%ax 804843c: 66 90 xchg %ax,%ax 804843e: 66 90 xchg %ax,%ax
Instead of wasting anymore time on that route, I write it off as a dead end and decide to try what worked before; check to see if it’s a directory. I copy and paste that address into my browser and we get a hit!
We are presented with two directories, one containing what appears to be a list of usernames and one containing what appears to be a password for one of those usernames. I’m gonna guess that these usernames and password are for the SSH. So, after lots of trial and error I discover that the password located in
Pass.txt is NOT the correct password. The password is in fact…“Pass.txt” (silly me, what was i thinking).
The correct login information is
overflow:Pass.txt. We have shell access! Now we can really start poking around
Remember, the goal here is to obtain root level privileges so we can read the flag located in the /root directory. After poking around for a bit, I don’t find any files that are particularly interesting, ran into lots of dead ends. I finally decided to check the exact kernel release and version of the target system. Running
uname -a gives us:
Linux troll 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:12 UTC 2014 i686 i686 i686 GNU/Linux
Before diving any further into the filesystem to try and enumerate vulnerable processes, I decide to start with the kernel itself. Utilizing
searchsploit, I discover that Ubuntu versions 12.04, 14.04, 14.10, and 15.04 that are running the Linux Kernel 3.13.0 - 3.19 are vulnerable to a local root exploit. If you care to read the exact workings of the exploit, which I recommend you do, it can be found here:
Linux Kernel 3.13.0 < 3.19 (Ubuntu 12.04/14.04/14.10/15.04) - ‘overlayfs’ Privilege Escalation
Let’s see if we can get this working! Since I have the exploit on my Kali machine, I spin up a simple web server and download the source code of the exploit over to the target system using
wget. Next, I compile the c file into an executable and run it. Let’s see what we get…
We have successfully obtained root and captured the flag! Quite a frustrating challenge, but very satisfying.