You can't see me, But I can you

Over the last couple of months I’ve learned that that the Web is fundamentally broken… or is it? In this post I will try to shed some light on the research that I presented at this year’s OWASP Application Security Conference. The presentation materials can be found the conference project page.

There is nothing ground breaking in my talk but rather something which can be used to enable more sophisticated attacks through web browsers. Web technology has turned out to be a quite useful tool for both sides of the fence. For the attacker, the Web is a stage where they can truly expand and control their virtual empire in no time. For the security researcher/tester, the web is a platform to track down the bad guys and hold them responsible for their actions. Everyone benefits. My job is to inform the public as soon as possible when the risk level rises.

So what is the big deal? Well, let’s put it this way: it is significantly easer to write malicious code with technologies such as JavaScript and ActionScript and I am not talking about code that attacks simple XSS and CSRF vectors. I am referring to tools that can potentially be very destructive. If you were surprised or even scared of what JIKTO can do, now you should be even more because by mixing and matching various web services (making a mashup) attackers can achieve so much more. No sophisticated programming skills are required.

In my talk I mentioned that it is possible to write something like NIKTO or even JIKTO in 20 lines of code. Maybe I am exaggerating but I am not far from the truth. As a proof of concept, I wrote a simple spider which does no harm to anyone. The spider can trace through any website on any domain as long as it is visible on the Web. Internal sites cannot be spidered. If you check the POC source code you will see that it is significantly simpler in comparison to other spiders and it is written entirely in JavaScript. It is simple not because I have some sort of superior programming skills. No! It is simple because I use services and public APIs to simplify the work. In this case I use a mashup service that I’ve built with Yahoo Pipes which makes use of Tidy from W3C. Keep in mind that I could’ve as well use Google Translate or the Google Mobile Search service. It doesn’t matter which one I use, the effect is the same.

I believe that this spider is a lot more stable then what JIKTO is using. Why? It is like that because the core component of JIKTO was the same origin unification hack which was initially described here. I repeat, it is a hack. By using a proper mashup service, we do not relay on hacks any more, we use actual service side components that can be scribed via client side technologies. In general, we can use publicly available services for their processing power and more over, we can use them in a distributed way and this is what is dangerous about them.

I can talk on this subject for hours and still not be able to say everything that I have in my head. For that reason, let’s have a couple of examples of potentially destructive uses of public APIs, so you can see the big picture from the angle I see it.

Jikto on Steroids

It is easy to write a tool in JavaScript that is able to spider remote web sites and fingerprint various common vulnerabilities. The tool does not need to contain any semantics (data) within its source structure. The signatures that are used for the scanning process are dynamically obtained from external resource such as the publicly available NIKTO database. If we can spider a site we can as well read any other file on the web.

Attackers can also build dynamic database of signatures on the web by using public resources. They can correlate various XML files into a single resource by using a mashup technology or they can use Google Base, DIGG or anything else that allows public access. For example, JavaScript can easily obtain XSS scanning functionalities by consuming RSnake’s XSS cheat sheet through a mashup API such as Yahoo Pipes. Even better, the tool can consumes the data when it is required, which means that changes in the cheat sheet will be acquired dynamically. In order to reduce the size of the JavaScript logic we can mashup the cheat sheet with a service to filter out records that are not required. In this case, instead of trying 200 vectors, some of which may not work, the tool/worm can try only those who are applicable to the browser that is exploited by filtering the rest of them out. Again, this can be achieved through Yahoo Pipes, Dapper etc. Keep in mind that the filtering is not performed by the client, but the server.

The Cross-site Scripting Super Worm

AJAX worms proved to be quite efficient. Usually, AJAX worms and worms in general, can attack only resources that they have information for. The Samy worm attacked MySpace while the Yamaner worm hit Yahoo mail. Both worms contained hardcoded payloads of the actual attack. However, today, worms can be totally generic.

Let’s say that a worm hits a user at a given resource. In order for the worm to propage, it needs to find other pages with Cross-site scripting holes. The attacker can write a spider and mash it up with RSnake’s cheat sheet but that is very inefficient because it takes time. However, here is a solution that is quite scary. All the worm needs to do is to instruct Dapper to screen scrape XSSED or Zone-H for the latest XSS vectors and feed the XML data into another mashup service where it will be translated and enriched. Once the worm obtains the vectors, an exploitation process is initiated and the user is attacked on all resources. The more versatile and updated databases XSSED and Zone-H have, the faster and further the worm will go. Moreover, it is easy to mashup a service that provides generic signatures when Zone-h and XSSED are not available.

Google Master Console

Today, attackers can base their entire infrastructure on the web without having to pay. In Web2.0 everything is free. Blogs are free. Storage is free. Services are absolutely free. This means that attackers can easily make use of something like Google Personalize page (iGoogle) to construct their malicious environment from common building blocks such as XHTML, XML, CSS and of course JavaScript.

Picture how simple it is! The attacker logs in into their iGoogle where they have several gadgets designed to control private Botnets, exploit targets and write exploits. It is possible. If you don’t believe me, do the following none malicious experiment. Take the spider code from the Spider POC and stuck it into a gadget. Import the Google gadget into your iGoogle. Now you can spider any website without the need to leave the browser or host the spider code. Simple isn’t it, and very scary too.

Expect to see more on this topic and give it a good thought because the impact is huge. I hope that everyone understands it so we don’t need to go to extremes. What can we do about it? This is what I would like to know.