Java JAR Attacks and Features

Sat, 10 Nov 2007 22:35:33 GMT
by pdp

This is my last post for this week, so I will try to keep it short and sweet. While playing with the JAR protocol for Firefox (here and here), I also did some investigation on the way Java handles jars, as well. To my surprise, the Java runtime seems to posses some very interesting features which may easily be implemented into an attack scenario. I shared some of my research and ideas with Aviv Raff and we both concluded that the observed behavior may not be the perfect way to attack someone, although IMHO, I see nothing more but opportunities for evilness.

Here is the deal. If someone manages to upload an Applet, as a JAR archive, on the targeted server, they will be able to invoke it from a page located on a different server/site. "This is not very exciting but we are getting to the interesting part soon."

Many Web servers come with quite a few open ports which are there for management purposes only (backup consoles, MsSQL or any other backend database, SMB, etc). Unfortunately, these services are behind the firewall, i.e. we can see only ports 80/TCP and maybe 443/TCP but nothing else, the rest is simply blocked for external IP address. However, if you are behind the firewall, well, no such restrictions are applied. This means that internal visitors have more access to the remote server then external visitors.

When a user invokes an applet, this applet will run within the sandbox of the codebase parameter, i.e the applet can only access resources that are located on the IP address/domain it was delivered from. This also applies to socket communication. For example, if we open an applet from, the byte code will be able to connect with a socket to without the need for extra permissions. This is how the Java's same origin policies are implemented. There is a lot more than this but you get the point.

Having this in mind, it is obvious that attackers can abuse Java to poke a server as being accessed behind the firewall. The attack of course is very simple. The attacker needs to upload the JAR blob or a .class file on the targeted server. Then the attacker needs to host a page that embeds the applet somewhere (does not have to be the targeted server) and get someone from behind the firewall to visit it. When the victim/proxy opens the page, the attacker will be able to poke the targeted server from behind the firewall. So in case the targeted server runs MsSQL with a blank SA password, the attacker will be able not only to compromise the backend database but also execute commands on the backend itself and as such get some sort of remote command execution. Of course, this all depends on how the MsSQL instance is setup, but most of the time, these services are very poorly configured, so attackers have some real potentials with this technique.

Of course, this is only one of the things the attackers can do to the target. Because applets have different origin checks from JavaScript and Web pages in general, attackers can bridge two zones together (the origin of the applet and the origin of the hosted malicious page). Therefore, it is possible to create some kind of proxy which will allow the attacker to access any service on the target, again as seen by the victim.

Aviv, pointed out that there are two many IFs, and I must agree with him. The first IF is related to whether the target can host user supplied files. This might be the case, but there also will be some kind of restriction on what files the users can upload (i.e. jpg, gif, doc, etc, etc). The second IF is related to how to get someone behind the firewall to visit the evil page. There are ways, which often involve social engineering and a bit of strategy, but I will leave this blank space for you to fill it yourself. Finally, the 3rd IF is related to whether there is anything interesting on the target. So, it kind of looks like a trick which is really hard to pull. But, I kind of like these the most.

IF #1 - uploading the malicious JAR/Applet

If the target does not have any file upload facilities then the attacker is left with nothing but to switch to another strategy. Keep in mind that this attack is tailer made for sites that allow uploads. The second obstacle is to trick the remote upload facility that you are uploading the right type of file while you are delivering something completely different at the end. This is where the second oddity, which I've discovered inside the Java runtime, comes into place.

Simply put, the Java runtime recognizes images as JARs, while the browser or any other software will recognize them as images. "How is that possible?" To answer that, we have to look at the following example. Follow the steps as described bellow:

  1. Get an image from the Web:
  2. Prepare your jar:jar cvf evil.jar Evil*.class
  3. Put them together: copy /B fancyimage.jpg + evil.jar fancyevilimage.jpg or cp fancyimage.jpg fancyevilimage.jpg cat evi.jar >> fancyevilimage.jpg

If you double click on the fancyevilimage.jpg you get your default image viewer with the actual image displayed inside. If you put the image inside the src attribute of an img tag, surprise, surprise, it renders. If you try to verify the image headers, you will get OK. However, if you change the extension from .jpg to .zip and try to unzip it with WinRAR or the command line unzip utility, you get the archive content. So, it seams that uploading weired stuff on a server does not have to be as hard as it seams. In our case, the Java runtime, will happily interpret an image as a JAR.

It is actually possible to attach any other file before the JAR but you have to be careful since you may end up with corrupted JAR. If the remote site does not have any type checks, then the attacker can simply upload a .class file. It works pretty much in the same way.

As I side note, the same technique can be used to trick application into running arbitrary Java classes.

IF #2 - tricking the user into visiting the malicious resource

Come up with something. I really enjoyed the social science classes at my University. Keep in mind that social engineering is not only about telling lies on the phone or via an e-mail. There is a lot more into that like behavioral pattern analysis, for example.

IF #3 - dancing with the devil

The attacker might end up with nothing pretty much. This is the reason why the applet needs to be as sharp as it can get. The applet needs to scan ports, identify services, brute force passwords and pretty much whatever else is needed. The attacker may have only one shot so they will probably throw the kitchen sink at the server.

This is it. I know that it sounds too complicated to be feasible but, hey, if it is that complicated no one will think about it, so the chances of remaining undetected are very high. Also the JAR manipulation technique can be used in a number of other cases to achieve more devastating effect. BTW, if you are around San Jose next week, come for a chat. I will be there pretty much the whole next week at the USA OWASP conn.

Archived Comments

Hey pdp, this is a really an ingenious technique, however, i havent come across web sites that runs java applet with uploading features.
you don't need a java applet with uploading features. All you need is to be able to upload a simple JPG file.
Hey, this is the same technic as "ActionScript 3 in Adobe Flash Player socket handling allows port probing". But could not be use as proxy.
And hope for lacking MIME checks of course ;)
isn't it even dangerous for the target server to host a malicious class file? We would use this user->applet-thing to be able to access more ports on the server, right? This is really frightening... :#
reznrezn also need a way to get the malicious image you uploaded to be the target of an APPLET or OBJECT tag inside someone's browser. If you upload an doctored image (with a jar tacked onto the end), and it ends up as the target of an IMG tag, all you've done is made someone download a few extra bytes. very interesting find, however, and i'm sure it'll come in handy in some situations. pdp, can you expand upon "As [a] side note, the same technique can be used to trick application into running arbitrary Java classes."
The flaw here is not really with Java but rather with insecure Firewall configuration / insecure permission models. If you trust machines on your local network then you had better make sure that those machines are secure. Better yet, don't use any sort if IP address based security model. IP addresses can be spoofed or even stolen and hence don't make for good authentication.
so you say that if i send user a web page with link to and there is cisco router on and cisco router has http bug, user can deliver payload to internal vulnerable IP ? heheh no news here (-;
IF #2 - tricking the user into visiting the malicious resource
what is a 'user' ? what is a 'visit' to a resource? rss embed into everything. internet pushing and pulling now. vista desktop make 'visit' on behalf of user and follow links and submit cookie and 'click' things. so does igoogle rojo netvibe yahoo live and more. link embedded in any page gets 'clicks' from automatic spiders and bots browser have widget to precache favorite page or predictive surf and restore session. we have tracking cookie and token everywhere that persist across many domain. user computer is clicking on links all day long without interaction therefore xss is important vector for delivery of serious hacking pdp!
vaj, :) not quite
pdp, i tried to figure out how this works? i was playing with a jar applet embeded in a jpeg imageg (copy /b...all of that) but in a IMG tag call from html file..nothing happens. I thing there must be a way of triggering the applet, but it doesnt seem to be an easy task at case that's even possible. Thank you.
The only interesting thing here is that it seems like Java will accept JAR files ending in ".jpg"... is that right? You didn't say that explicitly, so I'm unsure. As far as an attack vector, it's very weak (as you mentioned) -- it would require a server that outside users can upload files to, but which ALSO has some valuable services unprotected against internal users. I've certainly never seen a setup anything like that. It's common sense... a public-facing webserver, PARTICULARLY if you allow uploads of files that it then hosts! -- is occasionally vulnerable to flaws in PHP, your CMS, Apache, etc. etc., so you'd never put your important private company data on it, and you'd also never give it free access to the rest of your internal network (which is implied if your internal users can access it freely, which you require). So if someone actually has the exact setup you need, I'll bet there are much simpler ways to crack them than tricking a user to visiting your custom-built applet page! Last thing: what did you mean by this? "As I side note, the same technique can be used to trick application into running arbitrary Java classes."
flipper, you don't load the applet from the an HTML inside the JAR. you should load it from an external page. RobW, you've got it wrong. I will get back with a working example as soon as I get some of my other stuff on track. The technique is very simple. It is all described in the post above.
btw, RobW, I've certainly seen setups like that. However, I am not saying that this is the ultimate attack vector. All I am saying is that this attack is something to keep in mind.
This is utter rubbish, you can't learn anything about the server (the jar is executed on the client NOT the server. If the applet did try and probe the server from the client, you couldn't learn anything you could more simply learn by just running a port scanning tool) and the Java sand-box stops the applet on the client machine probing the client machine. If you are suggesting you get someone on the server side to run the applet, whoopie do, the applet still can't pass that information on as it can't connect to anything other than itself. I'm sorry, this is total nonsense.
Applets are not allowed to open network connections to any computer, except for the host that provided the .class files. This is either the host where the html page came from, or the host specified in the codebase parameter in the applet tag, with codebase taking precendence. Applet Security
So, therefore, all you have to do to exploit is get someone to load a malicious page with , since codebase takes priority? This seems a little too good to be true.
Gah. Apparently your board supports html. <applet codebase="localhost" src="malicious.jar" /> was the proper snippet.
bug, noone cares about hacking the individual server. Web 2.0 services are distributed, the attack surface is vast. get with the times, ./grandpa (-;
I think you missed the point that bug made. The friggin' applet still executes within the client. It doesn't suddenly acquire server priviledges. You'd have to spawn a virtual machine on the server machine and have a class run in it, that's the kind of support your applet would need in order to poke around. Yeah, they talk about that on the web -- if an applet requires connecting to something other than its originating host, some process on the server must help it. You're confusing some unrelated concepts here. If you seem to think that this upload-then-run-me issue is some sort of an Achile's heel, well, it is not. Simple sanitizing techniques in your file uploading should do the trick. Check out the bugtraq lists every now and then.
Mihai, none of the libraries that I've tested which check whether an uploaded blob is a valid issue has detected the malicious JAR attached. This is the fact. But if you don't believe me, go and do some experiments on your own. I think that you misunderstood the post.
No one seems to have noticed Dave's feedback. If you base your security on ip addresses... well... I know many people do just that, but it still is quite stupid. An IP address is an attribute of some machine on a network, which is quite different from a secure credential identifying some user. There could be a lot of users behind the same IP, a user could use multiple computers from different locations and still should have legit access... So, it isn't a safe, secure and flexible way of identifying users.
Hi pdp, I have found another server side fix for the GIFAR issue and also referenced this article at my blog Thanks, Inferno
thanks, I will have a look.
How many worthwhile targets are boxes that someone would be running a browser on at all? Honestly, as far as I can tell, the most interesting thing here is that java will run stuff with strange extensions. Which could be interesting, seeing as Netscape will automatically download files that it doesn't recognize an extension for. No matter what, this seems to be worthless without some form of social engineering. And there are already plenty of nasty things you can do if you can get someone to point a browser at your website.