Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 

Freely subscribe to our NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Unsubscribe

Pete Simpson, Clearswift: Return of the Super Worm

March 2008 by Pete Simpson, ThreatLab Manager at Clearswift

In recent years, malware attacks have been targeted and mass worms have been quiet. The days of blockbuster headlines about mass infections such as Slammer are long gone. Or are they? Are we about to face the next Super Worm?

The rapid evolution of “Web 2.0” has sparked the convergence of social networking on a massive scale and the adoption of new combinations of technologies that significantly increase the so-called ‘attack-surface’. This combination offers irresistible opportunities to organised crime.

About two years ago, organised criminals discovered around 70% of web applications harboured security flaws and began to switch from targeting OS weaknesses to those in the applications. The web is now the preferred vector for malware. At the same time, the nature of the web has been transformed, through the phenomenon of social networking, and in a sense we have become the ‘we’ in ‘web’.

Under the traditional internet model, when a user clicks on a link, a web browser sends an HTTP Get request to a server. In return the server sends the requested web page to the client. If the client is to send information back to the server, another request is made following the same process. This synchronous communication method involves the transfer of entire web pages. From the point of a page request, the user must wait and is unable to interact further with the browser until the entire page has been served.

Ajax - Asynchronous JavaScript and Extensible Markup Language (XML) - is a grouping of technologies that allow seemingly more immediate, uninterrupted interactions through the browser. The response time is reduced by the intermediary Ajax application exchanging small amounts of data between the browser and the server, without refreshing the entire page. This gives an impression of seamless interaction. For example, Gmail, the web-based email service provided by Google, offers a search-oriented interface and a unique ’conversation view’ and is well-known for its use of the Ajax programming technique in its design.

But Ajax is not a new language or technology. JavaScript and XML have been used together over recent years to create a cross-platform technology, usable on many different operating systems, computer architectures and web browsers.

The problem:
Although Ajax can dramatically improve the performance of a web application, it also introduces new potential for attack. As Ajax applications reside on both the client and the server, they raise the following security issues:
?_ Exposure of a much increased attack-surface, as many more points of input are opened
?_ Exposure of the workings of internal functions of the Web server application
?_ Allowing a client-side script, with no built-in security mechanisms to access third-party resources

This leaves the web browser and users wide open to the threat of an Ajax Super-Worm.

As I mentioned above, Ajax applications extend across both client and server, unlike traditional web applications. This necessitates a trust relationship between client and server that may be exploited by an attacker. I like to compare a traditional web application to a house with just one front door and no windows, offering just one point of attack. An Ajax application, however, sends small requests, which create many more points of input in turn creating many more opportunities for attack. In addition to the front and back doors, the house could now be thought of as having numerous windows (points for break and entry) and the doors become of little consequence.

JavaScript in the Ajax engine exposes the server application logic, so an attacker can readily discover function names, variable names, function parameters, return types, data types and valid data value ranges. This information is then easily used to exploit any security design flaws in the application.

So, what about the Super Worm? Cross-site scripting (XSS) involves the injection of code into a page that is returned to the browser. The code is then executed by the browser, exposing the user to a variety of threats including cookie theft (an attacker assumes the identity of the victim and hijacks a live session such as online banking), keystroke logging (leading to the theft of user identification and authentication data), screen scraping (revealing further authentication information selected from dropdown lists etc) and denial of service attacks (armies of botnets transmitting huge volumes of packets to a target system, exhausting bandwidth and effectively making it unreachable).

XSS attacks against traditional web applications required manual injection of script into a website, perhaps included in an email link or saved as an entry in a back-end database. With Ajax, XSS can easily propagate like a worm. The script can autonomously inject itself into web pages and send multiple requests using complex HTTP methods to propagate itself without any page refresh and all completely invisible to the user.

A very interesting piece of research called The Next Super Worm from GNUCITIZEN, a creative hacker organisation, outlines the true power of Ajax worms and raises the prospect of an Ajax Super Worm (<http://www.gnucitizen.org/blog/the-...> ). A worm could scan IP ranges to identify those vulnerable to XSS attacks and inject itself into pages on the vulnerable sites. However, JavaScript Object Notation (JSON) in combination with web services such as Dapper (a web data mapper) and Yahoo! Pipes offer a much more effective and rapid means of identifying URLs vulnerable to XSS.

The site XSSed.com contains an archive of sites vulnerable to XSS and also a record of the attack vector. This database is maintained by volunteers who scour the web and report in a very timely manner. Setting up a Dap at Dapper, JSON - a notation for transmission of structured data - can be used to aggregate data from the XSSed database and store it in an XML file. A worm’s JavaScript then uses Yahoo! Pipes to retrieve the up-to-date XML file of target sites and the attack vectors. Since Yahoo! Pipes has a very powerful caching mechanism, retrieval of the data via JSON is almost instantaneous.

The XSSed database conveniently sorts the XSS prone sites by page ranking, so it would be trivial to extract all those in the top 500, for example. The actual JavaScript code would be very streamlined, as the data gathering has been done by volunteers and all the processing is performed for free by web services such as Dapper and Yahoo! Pipes (although others could be used).

A Super Worm of this kind could have potentially devastating consequences in the very near future. The technology exists and the key question is one of motivation. A multitude of easy targets within the Web 2.0 social networks must certainly be attractive to organised crime.

The response:

Ajax developers must understand that client-side applications cannot be trusted to perform any security-critical functions. Furthermore, on the server side all inputs must be validated to prevent the injection of JavaScript code or SQL queries. This validation must be applied to all input sources and with Ajax there may be many.

A permanent solution would be for browser makers to find ways to confirm that Ajax code is indeed running in the context of the current website being visited by a user, while marking web requests with the source of the request (whether a human or a script) could limit attacks on sites.

Whether a Super Worm of this type or similar will appear or not is up for debate. But what is clear is that the increasing use of Ajax in today’s web sites means that we are likely to see more complex attacks which harness the power of Web 2.0 technologies. And for the first time in a long time, we could see another large scale infection spread by a new breed of Super Worm.


See previous articles

    

See next articles


Your podcast Here

New, you can have your Podcast here. Contact us for more information ask:
Marc Brami
Phone: +33 1 40 92 05 55
Mail: ipsimp@free.fr

All new podcasts