SickOS 1.1 - Vulnhub VM Challenge


tl;dr

  • Arbitrary File Upload

Solved by: 47Suriya

The IP of the target machine is found by using Netdiscover tool.

Netdiscover

IP of the Machine is 192.168.1.245

Initial Analysis

First, Nmap scanner is used to find all the open ports and services.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
┌──(kali㉿kali)-[~]
└─$ nmap -sV -T4 -A -Pn 192.168.1.245
Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times will be slower.
Starting Nmap 7.91 ( https://nmap.org ) at 2021-08-11 01:40 EDT
Nmap scan report for 192.168.1.245
Host is up (0.0011s latency).
Not shown: 997 filtered ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 5.9p1 Debian 5ubuntu1.1 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 1024 09:3d:29:a0:da:48:14:c1:65:14:1e:6a:6c:37:04:09 (DSA)
| 2048 84:63:e9:a8:8e:99:33:48:db:f6:d5:81:ab:f2:08:ec (RSA)
|_ 256 51:f6:eb:09:f6:b3:e6:91:ae:36:37:0c:c8:ee:34:27 (ECDSA)
3128/tcp open http-proxy Squid http proxy 3.1.19
| http-open-proxy: Potentially OPEN proxy.
|_Methods supported: GET HEAD
|_http-server-header: squid/3.1.19
|_http-title: ERROR: The requested URL could not be retrieved
8080/tcp closed http-proxy
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 16.51 seconds

Here, the ports 22 and 3128 are open. And SSH service is running on port 22 and a proxy service is open on port 3128.

So when navigated to port 3128:

3128

It returned an error.

Then, Nikto Web scanner is used with a proxy switch to scan for any possible vulnerabilities

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
┌──(kali㉿kali)-[~]
└─$ nikto -h 192.168.1.245 -useproxy http://192.168.1.245:3128
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP: 192.168.1.245
+ Target Hostname: 192.168.1.245
+ Target Port: 80
+ Proxy: 192.168.1.245:3128
+ Start Time: 2021-08-11 01:42:27 (GMT-4)
---------------------------------------------------------------------------
+ Server: Apache/2.2.22 (Ubuntu)
+ Retrieved via header: 1.0 localhost (squid/3.1.19)
+ Retrieved x-powered-by header: PHP/5.3.10-1ubuntu3.21
+ 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
+ Uncommon header 'x-cache-lookup' found, with contents: MISS from localhost:3128
+ Uncommon header 'x-cache' found, with contents: MISS from localhost
+ 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
+ Server may leak inodes via ETags, header found with file /robots.txt, inode: 265381, size: 45, mtime: Fri Dec 4 19:35:02 2015
+ 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.php
+ Server banner has changed from 'Apache/2.2.22 (Ubuntu)' to 'squid/3.1.19' which may suggest a WAF, load balancer or proxy is in place
+ Uncommon header 'x-squid-error' found, with contents: ERR_INVALID_REQ 0
+ Web Server returns a valid response with junk HTTP methods, this may cause false positives.
+ Uncommon header '93e4r0-cve-2014-6278' found, with contents: true
+ OSVDB-112004: /cgi-bin/status: Site appears vulnerable to the 'shellshock' vulnerability (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271).
+ 8726 requests: 0 error(s) and 15 item(s) reported on remote host
+ End Time: 2021-08-11 01:43:03 (GMT-4) (36 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

This revealed that there is a Shellshock vulnerability which can be exploited.

As there is a proxy service open on port 3128, let’s try to use a manual proxy to open the page.

Proxy

This worked and a page opened:

Page

It was just a page which contained nothing. When checked if a robots.txt file exists:

robots.txt

And yes. There was a robots.txt file which disallowed a directory “wolfcms”.

Exploit

When the directory wolfcms was checked:

Wolfcms

A page which looked like a blog opened which was managed by Wolfcms. When searched about Wolfcms a potential exploit was found which took use of Arbitrary File Upload vulnerability.

Looking at the description:

Exploit

There was a vulnerable URL mentioned. When that URL was checked:

Login

A login page was found. When trying some default username and password i.e. admin, admin :

Logged

It logged in. And there was an option to upload a file. Here this option can be used to upload a reverse shell and spawn it.

Here, a PHP reverse shell from Pentest Monkey is uploaded.
And in order to run it, the directory public was used as it was already mentioned above the uploaded files. That directory public can be used to run it.
When navigated to that directory:

Public

There was the php reverse shell that was uploaded. Before running this, a netcat listener was set up with the same port which was written in the reverse shell file. And also the IP was changed to the IP of the attacking machine.
Now when this was opened:

shell

A shell is spawned! But that shell is a dumb shell. That is made into a normal shell using the command below:

1
python -c 'import pty; pty.spawn("/bin/bash")'

Now checking the webroot directory (var/www/wolfcms) for some potentially useful files which might have been left out:

A php config file was found which contained:

config

A username and password for root. As there was an SSH service running on port 22, these credentials might be worth trying. When trying to login as root, an error was returned.

But when the username sickos was used, it logged in.

Now to escalate the root privileges, sudo su command is used. And finally root access is granted.

Now to get the flag, let’s navigate to /root directory and list the files. There is a text file and when displayed:

root

The challenge is now complete!!