[VulnHub] Troll: 1 - Solution

[johnmarston]

This is my solution to the Tr0ll: 1 challenge by Maleus. The challenge and his webpage can be found here:

Tr0ll: 1

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!

Details

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.                

    root@kali:~/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.

    root@kali:~/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.

    root@kali:~/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.

    root@kali:~/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 <printf@plt>
    
    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.

[alioo]

nice walkthrough

[johnmarston]

Thanks for reading, glad you enjoyed it!

[anon79434934]

I am really liking these Vulnhub challenges, finally something else other than RE.

Viva la revolucion!