Anybody who has had even a slight brush with the security industry would have heard of Botnets atleast once. Botnets are a group of computers compromised and controlled by an attacker, these computers or zombies would perform any actions that the attacker commands them to do. Botnets are usually created by compromising the victims' systems with some remote code execution exploits and then installing backdoors on them. The attackers must have been working on exploits for 0-days or newly discovered vulnerabilities to be able to infect more victims. Even then they are usually restricted to only one platform unless they have exploits and backdoors for the different platforms out there.
There is another type of remote code execution that is far more easier to perform
- JavaScript in web pages. Executing JavaScript in someone's system does not require any 0-days or exploits but simply requires the person to visit a website. Moreover the same piece of JavaScript would work across all OSs’ and platform(desktops, tablets, mobiles etc). Every time a user clicks on a link he is giving a remote website an opportunity to execute code (JavaScript) on his machine. The window of this opportunity is widened by the concept of tabbed browsing. Most users have multiple open tabs and most tabs remain open throughout the browsing session which could stretch for hours.
This enables an external entity to utilize the user’s processing power and bandwidth for his malicious needs. Spammers, especially on sites like Twitter, have been able to get thousands of users to click on their links in very short durations. But JavaScript is believed to be handicapped due to performance constraints and the restrictions enforced by the browser’s sandbox. This however is a misconception as JavaScript engines have become extremly fast over the recent years. Moreover HTML5 introduces WebWorkers which is a threading model for JavaScript. This lets any website start a background JavaScript thread unknown to the user and execute code without slowing down or making the browser unresponsive.
Creating a JavaScript Botnet:
A JavaScript botnet would include thousands of systems that have the attacker controlled page open on their browsers for an extended duration allowing continued execution of the attacker’s JavaScript.
There are two phases in building such a botnet:
A JavaScript botnet would include thousands of systems that have the attacker controlled page open on their browsers for an extended duration allowing continued execution of the attacker’s JavaScript.
There are two phases in building such a botnet:
1) Reaching out to victims
2) Extending execution lifetime
1) Reaching out to victims :
This involves getting the victim to visit an attacker controlled website. This can be done in a number of different ways:
1) Email spam
2) Trending topics on Twitter
3) Persistent XSS on popular websites, forums etc
4) Search Engine Poisoning
5) Compromised websites
6) Abusing URL Shortners
These are methods used by current JavaScript malware authors to attack victims to their website and can draw thousands of victms. While traditional malware spreading website can be quickly identified due to automated crawlers looking for signatures of browser exploits, JavaScript botnet payloads are less likely to be identified since its regular JavaScript working within the constraints of the sandbox and does not perform any exploitation against the browsers.
2) Extending execution lifetime:
Once a victim visits the attacker controlled page it is essential to keep this page open in the victim’s browser for as long as possible. This can be done by using a combination of Clickjacking and Tabnabbing.
When the page is loaded, it would contain an invisible link with the target attribute set to ‘_blank’. This link is always placed under the mouse pointer using the ‘document.onmousemove’ event handler. This way, when the victim clicks anywhere on the page a new tab opens and grabs the victim’s attention. With multiple tabs open the likelihood of the victim coming back to the main tab and closing it is reduced.
To add to this effect Tabnabbing can be used to refresh the page after the user leaves it, to update the favicon and appearance to seem similar to popular websites like YouTube, Google or Facebook so that the page blends in with the other tabs the victim would usually have open. There is a working demo[http://www.andlabs.org/hacks/xtend_life.html] for this available on the Attack and Defense Labs website.
JavaScript botnet activities:
JavaScript botnets can be used to perform the same activities that are performed by traditional botnets.
This article will discuss three such activities:
1) Application-level DDoS attacks
2) Email Spam
3) Distributed password cracking
1) Application-level DDoS attacks
DDoS attacks have been all over news in recent time as activists belonging to either side of the Wikileaks debate took out each others websites. Firms like Mastercard and Visa have suffered significant losses due to this.
Application-level DDoS attack is an effective type of DDoS attack that has affected even sites like Twitter. Usually these attacks involve large number for HTTP requests to specific sections of the website that could potentially be resource intensive for the server to process.
Background JavaScript threads that were started using WebWorkers can send cross domain XMLHttpRequests even though the remote website does not support it. The Cross Origin Request security restriction is only on reading the response.
A website that does not support Cross Origin requests will also process these request thereby creating load on the server. A simple request like http://www.target.site/search_product.php?product_id=% when sent in large numbers can create serve performance issues on the server.
A browser can send surprisingly large of GET requests to a remote website using COR from WebWorkers. During tests it was found that around 10,000 requests/minute can be sent from a single browser. With even a very small botnet of just 600 zombies we would be sending around 100,000 requests/sec, depending on the nature of the page being requested this could be enough to bring a website down.
After I wrote about DDoS attacks with COR a very smart person[http://shellex.info] showed me that similar numbers could also be achieved by using the img tag to request remote resources. Ben Schmidt has gone one step further by creating a malcious URL shortening service called d0z.me. d0z.me seems to work like any other URL shortening service but it actually shows the destination page in an iframe while perform DoS attacks on a target website from the victim's browser. It executes this so well that it is extremly unlikely that the user will even sense that he is part of a DDoS attack.
2) Email Spam
Spam mails are largely sent using open-relay mail servers and botnet zombies. Though it would not be possible to a regular open-relay mail server from JavaScript still it would be possible to send such spam mails through the web equivalent of open-relay mails servers.
Many websites have feedback sections which ask the user to enter their name, email ID, subject and feedback. Once these are entered and the form is submitted, the server would craft this in the form of an email, with hard-coded from and to mail addresses and send it to the internal mail server.
Poorly designed websites would contain the from and to mail addresses in hidden form fields on the browser and by overwriting them to external addresses it should be possible to send mails with spoofed addresses if the company’s mail server is also configured to operate in an open-relay mode.
Since only GET requests can be sent through COR, the feedback form should either be sending all data in QueryString or it should be differentiating between QueryString and POST parameters. Alternatively if it is JSP page then HTTP Parameter Pollution can be used to submit forms over GET.
3) Distributed password cracking
Password cracking has always been a task assigned for programs written in native code with performance enhancement by writing some sections in Assembly. With its relatively slower execution rate JavaScript has never been considered for performing such resource-intensive tasks.
Things however have changed, JavaScript engines in modern browser are becoming increasingly fast and the concept of WebWorkers allows creation of dedicated background threads for the purpose of password cracking. During our tests it has been possible to observe password guessing rates of 100,000 MD5 hashes/second in JavaScript.
This figure is still slow compared to native code which can easily loop through a few million MD5 hashes/second on a machine with similar configuration. The JavaScript approach has been found to be on an average about 100-115 times slower than that of native code but more than that it makes up in scalability. ~110 machines running the JavaScript password cracking program can match the cracking rate of one machine running a similar program written in native code.
As shown in the previous sections it would be very easy to build a botnet of a few thousand zombies executing our JavaScript password cracker in the background. Even with 1100 zombies our cracking rate would be equivalent to that of having 10 machines of similar configurations running a password cracked written in native code. An effective botnet creation effort could potentially get hundreds of thousands of such zombies to crack password hashes providing unimaginable computing capability.
I have built Ravan[http://www.andlabs.org/tools/ravan.html], a JavaScript distributed hash cracking system which is an implementation of this concept designed to be used for legitimate needs.
Lavakumar Kuppan
lava@andlabs.org
Lava is a Penetration tester and Security Researcher.
EntertainmentJavaScriptmodel for JavaScripttechGyanTechnologyTwitter Add new comment Author CHMag Collector's Edition Vol II
No comments:
Post a Comment