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

m (nikto)
m (Enumeration)
Line 37: Line 37:
 
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,  
 
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>
 
<syntaxhighlight  lang=shell-session highlight="" line>
xxxxx
+
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>
 
</syntaxhighlight>
  

Revision as of 18:11, 13 June 2018

Objective

xxxxxxxxxxxxxxxxxxxxx

Source: [xxxxxx]

Status: [In Progress]

Methodology

Discovery

Identify the target

root@kali:~# nmap -sP 192.168.56.0/24
.....
root@kali:~# export TANGO=192.168.56.104
root@kali:~# 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@kali:~# 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

xxxxx

Exploitation

xxx xxx xxx

xxx
xxx

xxx

xxx
xxx

Final Notes

xxx

Appendix A: Vulnerability Detail and Mitigation

xxx
Rating High
Description xxxx
Impact xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Remediation xxxxxxxxxxxxxxxxx