Prologue
Our research team has identified a web-based attack technique that exploits the growing number of applications that require a web server being run on a local machine. Cross-Environment Hopping (CEH) is a result of this trend combined with the current limitations in browsers’ same-origin policy access restrictions.
The CEH technique enables an attacker to exploit a local XSS vulnerability in order to “hop” to a different environment, such as another locally installed server. Under certain circumstances it may even be possible for an attacker to access remote network services such as network share drives, remote procedure calls, intranet mail, SQL servers, and so on.
This write-up will prove that the current implementation of same origin policy on the localhost in up-to-date Web browsers, combined with the presence of an XSS vulnerability, creates a special set of circumstances that enable environment hopping, and that the resulting malicious activity can be performed on any server running on a designated port.
We would like to credit Rob Carter for his great work in describing the problematic nature of exploiting XSS vulnerabilities in local web servers by taking advantage of the promiscuous security behavior of Internet Explorer 6.
Current Browser Restrictions
As browsers are designed to access a wide variety of resources, their access restrictions are essential to maintaining the security of the client. It is imperative that the browser controls information access by limiting one application from accessing resources or information from another application, that belong to a different entity.
>> Same Origin Policy:
The same origin policy is an essential element in client-side scripting (primarily JavaScript) security. A valuable component of this policy is that client-side script cannot read information originating from a different domain. While this does not prevent a browser from making cross-origin HTTP requests, it successfully limits access to the content of other domains.
The following table outlines various methods that might be used by JavaScript to communicate with external domains. While some are not restricted to the same origin, access to content is limited.
|
Method
|
Same Origin Policy
|
Content Access
|
|
XmlHttpRequest
|
Yes
|
Yes
|
|
Socket Connections
|
Yes
|
Yes
|
|
IFrame Element
|
No
|
Same Origin Only
|
|
Dynamic Form
|
No
|
Same Origin Only
|
|
Script Element
|
No
|
JavaScript Content Only
|
|
Image Element
|
No
|
Height/Width Value Only
|
>> XML HTTP Requests
It is interesting to note that different methods of making XML HTTP requests use different components, because different browsers use different implementations. For example, Microsoft Internet Explorer supports the ActiveX component Microsoft.XMLHTTP, while the Firefox browser does not.
Not only is there a variance in the components used to make these requests, but behavior varies too. For example, the standard XMLHttpRequest object supported by both Microsoft Internet Explorer and Firefox does not support requests across different ports (on the same domain), while many of the implementations through ActiveX that are supported by Internet Explorer do. (These include MSXML2.XMLHTTP, Microsoft.XMLHTTP and various versions and derivatives of these objects.)
In Firefox and Internet Explorer 7.0, an XMLHttpRequest might be initiated using:
var xhr = new XMLHttpRequest();
In addition, in Microsoft Internet Explorer 7.0 (and earlier versions), this might be initiated using:
var xhr = new ActiveXObject("Microsoft.XMLHTTP")
While this behavior doesn't seem to have a significant impact in an Internet web environment, it has a huge impact in a desktop web environment: the localhost domain. .csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, "Courier New", courier, monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; }
Cross Environment Hopping
Cross-Environment Hopping (CEH) is the technique of hopping from the Internet to a port on the victim’s computer, and then hopping from one port (environment) to another on the computer, as illustrated below.
The attack sequence might begin with a blind request (perhaps using an IFrame element) from the attacker to a cross site scripting (XSS) vulnerability on the local web server running on port A.
>> Vulnerabilities in Local Web Servers:
As a vulnerability class, XSS is very prevalent in web applications. Numerous advisories have been published about XSS issues in local web servers. As an example, our own research team has published an advisory about a XSS issue found in the local web server installed by Google Desktop (see "Overtaking Google Desktop"). We are also aware of other such vulnerabilities in local web servers, but are restricted from disclosing information at the moment.
>> Cross Application Scripting (XAS):
A second method of initiating the CEH attack is by exploiting a Cross-Application scripting (XAS) attack. This is not a new type of attack.
Cross-Application scripting (XAS) is possible when an application executes data in a security context different from the original content (presumably one with less security restrictions). For example the data may be obtained from an un-trusted source (a remote web server) that is sent unfiltered into a trusted application such as when web content is downloaded from a remote server, and then re-displayed on the local host. Any application that downloads and then later displays and executes web content (such as JavaScript) may be vulnerable to XAS (“Cross-Application Scripting”, Security.nnov.ru)
The impact of a XAS vulnerability is usually access to the Local Computer Zone. One of the suggested countermeasures against XAS is to use a local web server in order to present the information gathered by the application instead of loading it from the file system.
The fact that the browser loads a page from a local web server guarantees that even if the application doesn't properly filter out hazardous characters (i.e. it is vulnerable to a XSS attack), the Local Computer Zone won't be accessible to attackers.
However, this countermeasure against XAS means that if the desktop application web interface is vulnerable, a CEH attack is made possible.
>> Crossing Ports Using XML HTTP Requests:
After the initial request has been sent and the victim has been exploited using XSS, the attacker can deliver payloads of his choosing. If the victim is running Microsoft Internet Explorer, the attacker may send ActiveX Microsoft.XMLHTTP requests to other local web servers running on different ports. As the same origin policy does not apply to ports (on Localhost), the attacker is able to read responses and make additional requests through the exploited system.
The following Cross Site Scripting payload, demonstrates how a malicious JavaScript payload returning from a web server installed on Localhost port 80, can submit an HTTP request to a different web application, installed on Localhost port 8080, and also have access to the information returned in the HTTP response:
<script>
var xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
if (xmlhttp!=null)
{
xmlhttp.onreadystatechange=state_Change;
xmlhttp.open("GET","http://localhost:8080/some_page.html",true);
xmlhttp.send();
alert("Request Sent!");
}
else
{
alert("Your browser does not support XMLHTTP.")
}
function state_Change()
{
// if xmlhttp shows "loaded"
if (xmlhttp.readyState==4)
{
alert('response:'+xmlhttp.responseText);
}
}
</script>
.csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, "Courier New", courier, monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; }
>> Crossing Ports Using Socket Connections:
Several client-side technologies are available, which allow the browser to initiate direct socket connections. For example, Java applets, Flash, and QuickTime all allow the opening of direct socket connections with the server of the same origin. Firefox has the unique distinction that direct socket connections are allowed using Java natively within JavaScript.
The following code will open a direct socket connection to the localhost on port 9999:
socket = new java.net.Socket( "localhost", 9999 );
Exploiting this ability, the attacker can send a request that hops from the local web server to any local server that the victim is running.
Theoretical Outcome
The potential exploitation of Cross-Environment Hopping could lead to many different outcomes. This write-up will consider only a few of the possibilities available to the malicious individual.
.csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, "Courier New", courier, monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; }
>> Cross Web Application Access:
An attacker could use ActiveX (XMLHTTP) components to send HTTP requests to web applications running on different ports. As web applications running on other ports are unlikely to be related (on Localhost), this could lead to significant application compromise. Web applications running on Localhost are likely to contain sensitive information (e.g. Google Desktop).
>> Public Share Enumeration:
During this research, we have managed to create a working exploit that demonstrates how an attacker may enumerate any public shares on the local computer using the SMB protocol. You can download the exploit zip file in this link. (works only on Firefox)
>> Local Proxy Exploitation:
The most significant damage of all, is possible if the victim happens to be running a local proxy server. As the local proxy server is merely used to pass through network traffic, it might be possible to use the victim’s machine as a conduit for an attack against the local network.
There are numerous examples of commercial products that install an HTTP proxy on the Localhost. In our examples we installed AVAST Anti Virus (v4.7), which goes even further and allows proxying using the HTTP CONNECT method (The importance of HTTP CONNECT will be demonstrated in the section “Accessing Non-HTTP Services Using HTTP CONNECT Method”, below.)
The Cross-site Scripting payload below performs a GET request to www.intranet.site using Java socket connection in JavaScript on Firefox and exploits the proxy that is running on Localhost: (line wrapped)
<script>
var sock = new java.net.Socket("localhost", LOCAL_PROXY_PORT);
var write = new java.io.DataOutputStream(new
java.io.BufferedOutputStream(sock.getOutputStream()));
var read = new java.io.DataInputStream(sock.getInputStream());
write.writeBytes
("GET http://www.intranet.site:80/ HTTP/1.0rnrn");
write.flush();
var buf1 =
java.lang.reflect.Array.newInstance(java.lang.Byte.TYPE, 65536);
len = read.read(buf1);
var resp = "";
for (i=0;i<len;i++)
{
resp += String.fromCharCode(buf1[i])
}
alert(resp);
</script>
The malicious JavaScript code has full access to the HTTP response coming from a completely different domain.
>> Accessing Non-HTTP Services Using the HTTP CONNECT Method:
Some proxy servers allow the tunneling of TCP protocols using the HTTP CONNECT method. The tunneling technique is used mostly for tunneling SSL traffic through proxies, but it can be used for tunneling all kinds of traffic.
A standard handshake for HTTP CONNECT tunneling between a client and a proxy might look like this:
Client HTTP Request:
CONNECT www.some.site:1234 HTTP/1.0 [CRLF]
User-agent: Some-Client [CRLF]
[CRLF]
Proxy Server HTTP Response:
HTTP/1.0 200 Connection established [CRLF]
Proxy-agent: Some-Proxy/1.0[CRLF]
[CRLF]
If the handshake was successful, the client is now free to communicate with www.some.site (using the service on port 1234), through the HTTP tunnel that was created.
The following Cross-site scripting example establishes a connection between the victim's computer and a remote SMTP server, using the SMTP protocol. Communication is tunneled through a locally installed proxy server that supports the HTTP CONNECT method, which avoids same-domain policy restrictions while enabling non-HTTP traffic:
<script>
var sock = new java.net.Socket("localhost", LOCAL_PROXY_PORT);
var write = new java.io.DataOutputStream(new java.io.BufferedOutputStream(sock.getOutputStream()));
var read = new java.io.DataInputStream(sock.getInputStream());
var buf1 = java.lang.reflect.Array.newInstance(java.lang.Byte.TYPE, 65536);
write.writeBytes("CONNECT mailserver:25rnrn");
alert("CONNECT sent");
write.flush();
read.read(buf1);
write.writeBytes("HELO mailrn");
alert("HELO sent");
write.flush();
len = read.read(buf1);
var resp = "";
for (i=0;i<len;i++)
{
resp += String.fromCharCode(buf1[i])
}
alert(resp);
</script>
>> Cross Environment Hopping vs. DNS Rebinding:
It is worth mentioning that while the outcome of a CEH attack is somewhat similar to that of a DNS Rebinding attack, the techniques themselves are very different. While DNS Rebinding bypasses the same origin policy to achieve its goal, Cross-Environment Hopping works under the same origin policy restrictions, and does not violate them during the attack.
As the security industry is continuously trying to fight against DNS Rebinding (and partially succeed. see DNS Rebinding security updates in Flash and Sun's JVM), CEH attacks are more relevant than ever.
Recommendations:
-
For browser and plug-in software providers:
As presented in this write-up, communication between different ports in the context of Localhost can lead to devastating results. Therefore, we believe that crossing ports on the Localhost should be restricted and bound to explicit user consent.
-
For the client:
The client should be very wary of installing software that runs a local web server. This write-up has shown that the restrictions in place on the local computer are not sufficient to prevent environment hopping from a vulnerable web application to other applications (not only web applications) that are running as a server.
-
For web application developers:
Web application security is paramount when building web applications that run in the context of a local web server. This write-up has shown that a single, simple XSS vulnerability can be exploited to gain access not only to the local web application, but to other applications and programs that are running the local machine. The responsibility involved in building such applications should be considered carefully.
-
For the anti-virus and local firewall software vendors
Anti-virus and local firewall software vendors should consider solutions that prevent socket and HTTP connections between web applications and different ports on the local computer.
Conclusion:
Cross-Environment Hopping can lead to the compromise of many different applications and expose some operating system features. The technique is relevant to any machine that runs a local web server.
When a machine runs a web server on more than one port, it is possible to exploit a vulnerability in one web application that leads to the compromise of a web application running on a different port entirely.
When a web server is co-hosted with other server types, the potential for exposure is dramatically increased. A vulnerability in a local web application could serve as a hopping point to open direct socket connection and exploitation of the other servers.
The research conducted so far is only a start, but highlights the dangerous potential of the technique.
Acknowledgements:
This research was performed by Yair Amit with additional help from Adi Sharabani, Danny Allan & Ory Segal.
