Monday, October 11, 2010

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.

1 comment :

  1. Good job. If they fixed NetworkInterface's hashcode, I hope they fixed FilePermission's hashcode, too (I've blogged about it in the past).