1 Raindrop

It a Vulnerability Mashup: Web 2.0 Security in a Nutshell

Matasano: Vulneraility Reporting in a Web 2.0 World. Same old security problems, just no one to report it to or fix 'em.

Step #1: I send in a vulnerability report. I explain the vulnerability in a concise email and include repro steps.

They reply:

Thanks for the tip, David. It’s been noted.

BTW, most of the talks at OWASP Milan last week were on Web 2.0 attacks.

The Dark Side of AJAX, Brian Chess, Chief Scientist, Fortify Software (a sampling of 400 different known XSS vulns, goes through the popular frameworks (Atlas, Dojo, et. al.) to see which ones address Jaavscript hijacking today (basically none) and whichs ones have fixes in next versions (rsn) more info)

Overtaking Google Desktop - Leveraging XSS into Mayhem, Yair Amit, Sr. Security Researcher, Watchfire (pass XSS and CSRF attacks through to Google desktop)

Advance Web Hacking Revealed, Petko D. Petkov (AKA PDP Architect), Senior Security Researcher (showed some interesting ways to extend fundamental XSS/CSRF and mash those atatcks up using Yahoo Pipes and Google APIs)

Protecting Web Applications from Universal PDF XSS: A discussion of how weird the web application security world has become – Ivan Ristic (not possible to see attack on server)

Testing Flash Applications: A new attack vector for XSS and XSFlashing, Stefano di Paola (Summarized several existing known Flash attacks and a new one Cross Site Flashing (XSF))

I think the term Vulnerability Mashup describes the current Web 2.0 security situation pretty well. You can take your javascript attack and use it across domains, requests, and technologies. It turns out attackers can leverage the Web 2.0 ethos "web as a platform" as easily as a portlet developer. So as Web 2.0 programs struggle to achieve a secuirty 1.0 posture, they will have an interesting time dealing with attacker 3.0. In other words, Google Maps looks great, but you really don't want to run your business on this stuff.

Web 2.0 Attacker Meme Map

Web 1.0		Web 2.0
Attack server	---->	Attack client & server
Attack sites	---->	Attack sites & users
Web 1.0 security model	---->	Web 1.0 security model
OWASP Top 10	---->	CVE 400

Fortify finds Web 2.0 security hosed - "An application can be mashup-friendly or it can be secure, but it cannot be both"

Fortify released a new paper on Javascript hijacking. The paper looks at 12 Ajax frameworks, including Google's GWT, Microsoft Atlas, Yahoo! UI, and a number of open source projects, to see which are vulnerable to Javscript hijacking, described as the attacker's ability to read confidential data in Javascript messages. The vulnerability testing uses JSON which the authors state makes the attacker's job easier to exploit Javascript hijacking, because JSON arrays are standalone Javscript statements. From the paper (emphasis added)

When the JSON array arrives on the client, it will be evaluated in the context of the malicious page. In order to witness the evaluation of the JSON, the malicious page has redefined the JavaScript function used to create new objects. In this way, the malicious code has inserted a hook that allows it to get access to the creation of each object and transmit the object's contents back to the malicious site. Other attacks might override the default constructor for arrays instead (Grossman’s GMail exploit took this approach.)

Applications that are built to be used in a mashup sometimes invoke a callback function at the end of each JavaScript message. The callback function is meant to be defined by another application in the mashup. A callback function makes a JavaScript Hijacking attack a trivial affair—all the attacker has to do is define the function. An application can be mashup-friendly or it can be secure, but it cannot be both.

If the user is not logged into the vulnerable site, the attacker can compensate by asking the user to log in and then displaying the legitimate login page for the application. This is not a phishing attack—the attacker does not gain access to the user's credentials—so anti-phishing
countermeasures will not be able to defeat the attack.

More complex attacks could make a series of requests to the application by using JavaScript to dynamically generate script tags. This same technique is sometimes used to create application mashups. The only difference is that, in this mashup scenario, one of the applications involved is malicious.

The paper helpfully concludes with a look at various Ajax toolkits' ability to deal with this type of attack,  Dojo, DWR 1.1.4, GWT, jQuery, Atlas, MochiKit, Moo.fx, Prototype, Yahoo! UI, all are vulnerable. DWR 2.0 has some protections that deal with CSRF that may mitigate JAvascript hijacking, the authors find.

The Javascript hijacking attack is also noted in this Subverting Ajax presentation from last year's CCC.

As I previously blogged,I think the overarching theme is that Web 2.0 brings new ways to integrate apps and data together, but it brings no new security mechanisms, so this guarantees security issues such as the above.

 

**************************************************

Upcoming public SOA, Web Services, and XML Security training by Gunnar Peterson, Arctec Group
- NYC (April 19), Unatek Web Services (May), OWASP App Sec Europe (May), Helsinki (June), DC/Baltimore (July 19).

Understand Web 2.0 Security Issues - As Easy as 2, 1, 3

The mix of Web 2.0 functionality protected by a Web 1.0 security model is going to continue to create some ugly results - A Growing Web's Harder to Secure:

"If you take this Web 2.0 apart, part one is rich user interfaces," says Watchfire founder and CTO Michael Weider, referring to the dynamic scripts now found on many leading Web pages, using Asynchronous JavaScript (Ajax) and other fast applications. "Secondly it's the idea of community, collective intelligence and users participating."

Community creation means distributing control to end users. "So history repeats itself. If you distribute control to the users, you're opening yourself to more vulnerabilities," says another security software exec, Dave Shackleford, chief security architect at software maker Vigilar. "The ability to dynamically update code on the fly is obviously going to open itself up to the ability to inject code from malicious sources. Cross-site scripting attacks are prevalent for exactly this reason."

Exhibit A is a worm that crawled across MySpace, the pre-eminent social networking community site, just before last Christmas. It used an exploit in QuickTime video software, using imbeds in an infected clip to alter the viewers' profile, which then created altered links on the profile page to dupe other users into going to phishing sites. "The idea is that they weren't targeting individual computers," says Chris Boyd, the UK-based director of malware research at FaceTime. "They were targeting the Web 2.0 services themselves. They get the same result. And there's nothing yet really to protect against it. In terms of its effect, the only way to protect yourself against this kind of thing is to not use MySpace. You can't get a bigger impact than not being able to use something."

..."You can put up nice content and bad content," Watchfire's Weider says. "The attack in a Web 2.0 situation is someone uploading nasty content and then poisoning the site for everyone else who hits on it."
...
The defenses, sources say, have to start in the development. As outlined in a recent report from Net Square founder Shreeraj Shah, the new rich interfaces with complex scripts make it difficult to identify application logic and resources buried within them-RSS feeds leading into an application surface constantly bring in data, code and information from multiple sources.

This makes scanning for malicious code a real challenge. From a tech perspective, firewalls, antivirus software that search for signature code patterns and network monitoring aren't really going to be that effective in the case of Web 2.0. Scanning is going to have to rely on technology and library fingerprinting, Shah reports.

This means mapping known vulnerabilities and clearly "printing" the Ajax and Flash libraries that create many Web 2.0 applications. It also means clearly identifying where third-party information, in the form of feeds, updates or community interaction, is coming from and having a clear understanding of which are trusted sources and which are not trustworthy, and more closely scrutinizing the "untrusted" feeds.

Access points to Document Object Model contexts, the collection of objects that represents a page in a browser-and which can be manipulated by JavaScripts-need to be clearly identified and understood.

Still, just now corporate America is experimenting with Web 2.0, Weider says, in pockets of development. Now is the time to take a more basic approach than depending on software fixes and defenses later. "Developers don't think of security in the same breath that they do for adding features and shipping code on time. The biggest thing to do is to educate your organization of Web application security, period," he says.

So let's do the math, we have rich Web 2.0 and its rich UI and lots of disparate data and links, we are protecting these brand new 2007-built apps with a Web 1.0 security model that was invented in 1995. This would not be a bad thing at all if the attacker community had learned nothing in the last 12 years, alas they have already upgraded to attacker 3.0, and so can use Web 2.0 to both attack and distribute attacks.

2.0 functionality, 1.0 security, 3.0 attackers. this cannot stand.

Ajax Security DOA 2.0

Brian Chess on how XSS is not overrated:

If anything, I think the attackers just haven't yet explored much of what's available to them. If a bad guy gets to run javascript on your box, he can make HTTP requests to anything on your intranet. Have a web console for your firewall? That XSS hole could allow him to bring the shields down.

It is a large hole alright, the thing is that there are many attack payload areas that have not yet been explored, Amit Klein touched on a few of them. Of course you have some of the same vectors in traditional, non-Ajax web apps that use Javascript, but web apps don't have to use Javascript, do they? Also, because it is an active application, Ajax makes XSS-enabled attacks able to act like a virus as Billy Hoffman pointed out at his Blackhat talk. Fast, distributed, iterative attacking. Great. At least the maps look nice.

My assumption is that the end game is that the users will eventually figure out to ask for some assurance around the payload and connectivity of ajax apps, but javascript and vbscript are not positioned to deliver these assurances today.

Update: looks like the Fortifiers have a new blog.