The Web has Betrayed Us
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.
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.
Comments
The spider has stopped working for me. Maybe something has changed in yahoo pipes.
I have tired both the webspider and tinyurl POC, but neither of them give me back any results.
i think we’re going to have to fix the big-four browsers as soon as possible.
we can’t just uplift our entire web infrastructure to signed scripts (although this might be a good idea). httpOnly isn’t going to prevent this sort of thing and has problems of its own. safer methods such as content-restrictions may be worthwhile to look at.
i think microsoft and firefox developers will fix xss at the browser-level this year, possibly after a devastating attack or two like the ones you describe. this would prevent future xss super worms.
as for the jikto on steroids - this has been an attack channel that has been waiting to happen for years. my suggestion is to learn how to get off firewalls as soon as possible. alongside your existing infrastructure, build an ipv6 network with systems and applications that are resilient to both the 12-year patch syndrome and the zero-day. this means all-new applications using developers certified in secure programming, that use secure frameworks, and that use threat-modeling and SCA tools that also combine fuzz testing before deployment. when you use third-party applications, make sure they complete a rigid software contract, get their reports/analysis on their secure software practices, and validate through external testing before any integration of their product.
until we get to the secure software paradise described above, i figure we’ll need to learn a lot about incident response and dealing with threats over vulnerabilities. consider a quick retirement of all legacy applications. firewall/IPS appliances and anti-virus software is not going to help us - so stop buying them. they may have bought us time, but that time is clearly now over with and done.
As web developers, reconsidering the mindless way we’re sharing content, we’re binding resources to random domains and we’re handling data turning it into code with no clue of what and where we’re running.
As web users, a conscious adoption of the NoScript Firefox extension ( http://noscript.net ) may be a start point…
Alternatively (or not), we can jump the fence and run for the easy money :)
Kishor and David,
Yahoo pipes experience some problems these days. It works now! The service was down when I was presenting my topic… that was so unlucky…
ntp,
very good thoughts, but I don’t see them happening. As I always mention, security and accessibility should be balanced. This means that you cannot go for only secure technologies because you will loose their easiness of use. IPv6, VPNs, SSL have their problems on their own. Nothing will change. Attackers will move from one type of attack vector to another. The sooner we understand that, the better. Security is not a destination, it is a process. I believe tat big organizations/corporations already understand that. They are not trying to fix all vulnerabilities in their systems but to mitigate the overall risk and come up with a strategy that can tackle the problem when it occurs.
Elio,
NoScript is OK extension but it does not solve anything. First of all, it is hard to use. The overage user will never use. Come on! Nobody likes being asked very time something happens. Moreover, AJAX the main way to develop applications on line. If we want to turn off JavaScript to protect against AJAX worms and viruses then we may as well block kernel32.dll to protect against desktop worms and viruses. The end result will be none-usable system. Consumers don’t like that! There must be other solutions! More creative solutions, that are ready to be discovered and implemented.
Hehe, we are on the same page with the super worms PDP. My blackhat submission (which had to be in by 5/14 so no one can claim I’m ripping you off) is all about Cross domain web application super worms. One of the things we have a demo of is pulling new vulnerability data from web security sites and changing the worms attack vector while in the wild.
We also polymorph too, but thats a long story…
Keep up the good work!
Acidus, well this is exactly what I did. I’ve designed POC code that replicates by using public databases to extract various vulnerabilities. I am not planning to release the code although my intentions was to show it in OWASP. Unfortunately, the connection was down so I was not able to, but I guess I will have some other time.
Just to stress on the real dangers of AJAX APIs in a harmless way, I designed a simple application that wraps around Johnny’s Google Hacking Database. You can learn more about it from here. Now imagine that something similar is implemented into a Worm… that could potentially bring a lot of problems. Of course, I am working on counter attack scenarios so let’s see what the future holds for us.
Well, I think the future is bright, I implore you all not to have a grim outlook as that’s what pdp is exhibiting..cheer up!! the problem is here to stay and we must find a way to mitigate the risk and not a one-stop-all solution. Keep up the good work man. Big up!