Mike Murray here. Our always proficient Senior Researcher Mike Bailey has found a way to attack the way that browsers handle Adobe Flash objects. Anyone familiar with Mike's work knows his technical prowess, and I wanted to jump in at the top to quickly provide some insight in to the impact of this:
This vulnerability allows the same-origin policy of Adobe Flash to be exploited to allow nearly any site that allows user generated content to be attacked. No fix for this vulnerability currently exists.
This is frightening in that 99% of internet users worldwide use Adobe Flash. Almost everyone using the internet is vulnerable to a website that allows content to be updated inappropriately. That's not hyperbole - it's just fact.
With that said, on to Mike Bailey....
The same-origin policy of Javascript is pretty well-understood at this point: a script can access content only from the same domain as the origin HTML page that executes it. While this policy has not had a great track record, it does work reasonably well. When switching from Javascript to Actionscript, a similar language used to handle interactive content for Flash objects, most developers assume that the policy is the same.
It sort of is.
The basic policy for Actionscript is very close to the Javascript same-origin policy: A Flash object can only access content from the domain it originated from. There are exceptions, which I'll get into another time, but they actually aren't particularly important. This flash behavior is known and documented, but is not particularly well-understood, even within the Web Application Security community. The important difference, of course, is that flash objects are not web pages. A flash object does not need to be injected into a web page to execute- simply loading the content is enough. Let's consider the implications of this policy for a moment: If I can get a Flash object onto your server, I can execute scripts in the context of your domain.
This is a frighteningly Bad Thing. How many web sites allow users to upload files of some sort? How many of those sites serve files back to users from the same domain as the rest of the application? Nearly every one of them is vulnerable. To be sure, any server that allows unvalidated uploads of contents will let an attacker upload html pages with cross-site scripting or other attacks, but SWF files do not require a .swf extension or special content-type headers to execute. This means that poorly validated image upload features will be vulnerable. Also poorly validated document repositories. Also backup services, filesharing sites, webmail applications, and more.
It gets worse. Uploading a SWF with a .jpg extension, or a forged content-type header will get you a long way, but what if you can upload perfectly valid files with malicious content? Remember GIFAR? The basic premise is this: Overload a GIF file with a JAR archive. Specifically, the ZIP file format can be appended to any binary file and still be valid. The GIF format, in turn, can have any binary file appended to it. The JAR archive, being essentially a ZIP file, can be combined with a GIF image to create a a file that is both a valid image and a perfectly valid JAR archive. While SWF files cannot be appended to other formats, the inverse of the GIFAR exploit works- any file format in the ZIP family can have a SWF file prepended to it. This means that ZIP archives, self-extracting executables, Microsoft Office Open XML documents, XPI files, and, if you want to be ridiculous, even JAR files can all be crafted to contain executable SWFs. Additionally, if you don't care too much about compliance with standards (and what attacker does?), many server-side content validation libraries will also allow malformed PDFs, MP3s, and other media formats, so long as you are careful not to mangle them too much. This content overloading technique has countless variations, but the end result is always the same: no matter how good your validation routines, you simply cannot trust user-supplied content.
The short version of all this, of course, is that if I can convince a server to serve up a file on my behalf, I can use that file to attack the server. To demonstrate, here are screenshots of SWF files uploaded to and executed from cPanel's File Manager:
And from SquirrelMail:
To really get into it, let's look at a much more complex, but equally valid example: Gmail serves attachments from mail.google.com, the same domain that is used to access other webmail functionality. You may already see where I'm going with this, but actually exploiting this is extremely tricky, as there are a lot of hoops to jump through. It required uploading the SWF to my own account, then logging the victim into that account (via CSRF), loading the SWF into the browser, logging them out, and enticing the user to log in while keeping the original page loaded (eg. in another browser tab). Not simple, and that's the simplified version, but it worked beautifully. Here's video:
In fact, the Flash exploit itself still works, though the Gmail team has finally (after nearly 3 years of people attacking it) fixed the login CSRF issue that I used to load the object into the browser (well... sort of). At this point, one can still, theoretically, at least, execute the Flash payload as follows:
Send payload to a targeted user's email account
Predict or discover the ID within Gmail of the sent message
Use that ID to execute the payload out of the user's own inbox.
The problem here lies in predicting the message ID- not a simple task given the volume that Gmail handles. I've played with this approach, and while I suspect it is possible, it would take a better statistician than myself.
Back to the Flash issue: while some attacks may be self-contained, and only need to access the source domain to do their dirty work, this all becomes a lot worse if sensitive data can be handed off to the attacker's server. Of course, this is not too hard. Resources may be requested (but not accessed by the SWF) without bothering with same-domain and crossdomain policies. If the SWF is loaded into a malicious web page, Javascript on that page can communicate with the SWF object, as well as with its origin domain (which is different from thesource of the SWF). The SWF itself can also communicate directly with the attacker's server, assuming his crossdomain.xml policy allows it. Considering that it's his server, that shouldn't be difficult to arrange.
I normally wrap up posts like this with mitigation recommendations, but in this case it's not easy. For users trying to protect themselves, disabling Flash completely is the only way to be sure. But that breaks a lot of valuable stuff on the internet. So, you probably will end up mitigating rather than solving the issue.
The best recommendations we have involve ways to control when you're using Flash and when you're not. If you're a Firefox user, NoScript may save you in most cases, though ironically, mail.google.com is whitelisted by default. For those using Internet Explorer, the Toggle Flash application will let you enable and disable Flash as you feel appropriate. Mike Murray put together a quick video on the use and installation of these two products:
For website owners, all user-supplied content should be served from a completely separate domain. This is already implemented by Yahoo mail, Hotmail, Wikipedia, and many other major websites, but a huge variety of self-contained web applications do not do so (and if I can, for example, upload a malicious file to "apiwiki.twiitter.com", I can perform cross-subdomain cookie attacks). A partial solution was made possible by Flash 10,0,0,2: SWF files served with a "content-Disposition: attachment" header will not execute when embedded in a web page. If all user-generated content is served with this header (not a bad idea in any case), it may limit your exposure, but this is not a very robust solution.
The ideal fix should involve Adobe implementing a more sensible origin policy for Flash objects. According to Adobe, "unfortunately, there is no easy solution. This issue is very difficult to solve without also breaking existing, legitimate content elsewhere on the web." I don't see a fix coming from them anytime soon, but it should not be difficult to at least deny connections by default- even to the origin server of the object. Requiring a crossdomain.xml rule to explicitly allow these connections would at least save all the administrators whose sites don't use flash, while making sure that those who do are aware of the problem and opting in to the consequences.
Training is for Puppies (Or: Security Awareness Fail)
I recently spoke at the SecureWorld Expo event in Seattle on the data privacy panel. I had a blast being on the same panel with some really intelligent folks, and, as usual, I took my position on the dais as the trouble-maker. At some point during the discussion, the topic of user awareness training came up, and I got off on a rant.
And I'm still riled up about it. Because we've been educating our users for 15 years and it hasn't worked. And we blame the users. Or we feel like we need to put up more posters and rub more users' noses in it. (Someone in the audience actually suggested that his organization would be best to fire any user who violated security policy. If you're not shocked at the stupidity of that idea, you probably should call me. Or Dr. Phil. You need help.)
Security awareness isn't about educating our users. And other people have solved this problem. (And, in fact, Foreground has solved the problem for its clients in the same ways).
In Super Freakonomics (pg. 204) Levitt and Dubner talk about the difficulty when talking about trying to get doctors to wash their hands in the hospital:
"This failure seems puzzling. In the modern world, we tend to believe that dangerous behaviors are best solved by education. That is the thinking behind nearly every public-awareness campaign ever undertaken, from lobal warming to AIDS prevention to drunk driving. And doctors are the most educated people in the hospital."
Here's the thing. We're not "educating" our users. We're not "training" our users.
Our goal is to change their behavior, not make them smarter.
The solution to the doctor's handwashing problem is described in this column as well. And it describes the crux of what we have to do. We have to start treating users like adults:
"In the beginning, the administrators gently cajoled the doctors with e-mail, faxes and posters. But none of that seemed to work. (The hospital had enlisted a crew of nurses to surreptitiously report on the staff’s hand-washing.) “Then we started a campaign that really took the word to the physicians where they live, which is on the wards,” Silka recalls. “And, most importantly, in the physicians’ parking lot, which in L.A. is a big deal.”"
Note that there are two keys to success in any program of this sort.
Measurement. If you're not measuring the success of your program, how will you know (as the team at Cedars Sinai did) whether or not your posters are working? (Hint: they're probably not.)
Not Education, But Marketing Your security awareness program goal isn't that the users pass a test. It's that they behave correctly in a given organizational context. The geniuses of behavior change in our society aren't educators - they're marketers. Marketers get their messages in your head and change where you spend your money... this is how awareness must be run. So, create campaigns that target behavior change and create positive incentives that work. (Hint: threats of termination are not incentives that work).
This might seem obvious. But given how bad the user awareness is out there (and how bad the ideas are of most people who are talking about it), It's clearly not.
I did a talk at Toorcon last weekend on exploiting client-side applications' trust in subdomains. Primarily, it formalized and demonstrated a few attacks on cookies, which implement security policies backwards by placing more trust in a subdomain of a trusted domain, rather than less, as the hierachical nature of DNS would suggest.
Last night, I put together a quick paper summarizing these problems, with interesting proof-of-concept attacks against Google's new CSRF protection feature and Expedia.
I'm still looking into the ways that other client-side technologies (Flash, Java, etc) handle these issues, so expect a version 2.0 in the future. Also, I'm looking forward to some relevant new tools that will be released at AppSec DC next week.
Note: All the attacks outlined in this paper were responsibly disclosed, and the Google and Expedia ones, specifically, have been fixed for several weeks.
It is Gar*ner’s World and We Are Just Lucky to Live in It
As many of my colleagues know I have wanted to write a post about Gar*ner for a while now. There are many things about Gar*ner that bother me but I wanted to check my facts first before writing this. So, I set out to do some research on this “amazing” organization and the wonderful things that they do for our industry. So, I read numerous articles, blog posts, and most importantly I talked with several current or former employees/researchers about their practices and the “value” they provide in their research.
If you ask them, or for that matter they will simply tell you, that they are invaluable to the IT industry and to be honest without their “forward thinking” and unbiased research who knows where most organizations would be today. However, after my own experiences and the research I performed on Gar*ner it is clear to me that they truly don’t provide any real value to our industry. The only value obtained from their “magic quadrant” is the marketing the companies who are so “blessed” to be in that list gain and getting on that list is an extremely “skeptical” process at best. Some of you may be wondering why I keep using the term Gar*ner to refer to the organization and that is a funny but truly telling story of its own. Check out the experience this blogger had when he attempted to reference Gar*ner in a blog post. This truly shows the level of arrogance and pure ignorance of this organization. There are some follow ups to this story that add even more depth to the whole incident and highlight the true nature of the stance taken by Gar*ner.
There are several other stories that truly highlight the level of ignorance (or maybe arrogance) of this organization lately but this one seems to show it best. It is clear based on this post that Gar*ner truly believes they know better than the rest of us little people and we should simply bow and believe - http://identityblog.burtongroup.com/bgidps/2009/10/gartner-gets-privacy-dead-wrong.html.
The Facts about the “Magic Quadrant”. Everyone in our industry knows that when a lot of our customers or colleagues are trying to decide on a specific product to fulfill a need within their IT Architecture they look for Gar*ner’s “magic quadrant” report. They truly believe that report to be a thorough and unbiased review of all players within that market space and that Gar*ner has provided them with a great service. I know many vendors within the market who peddle these reports around as if it were “gold” and use it as their main selling piece. I will refrain from commenting in this blog the same way I do with my colleagues but this whole process is broken, flawed, and smells fishy to me. It appears that the process works as follows:
Gar*ner researchers are supposed to be an independent body within the organization that do not have any ties or responsibilities to other organizations or profit/quotas. I do applaud them on that as “it didn’t used to be that way”, as was made clear to me from a former Gar*ner researcher.
Here is where the problem lies…
A researcher truly only spends time with organizations that are Gar*ner clients learning about and reviewing their products. So, the only people the researches talk with are the ones who are paying for Gar*ner’s “services”. By services they mean having a researcher sit down with the organization (development teams, sales, marketing etc.) and talk about their products capabilities, the future of that market segment and how they fit into it.. The more money you pay to Gar*ner the more time you spend with the researchers on a consistent basis talking about the market and their products.
If you are not a Gar*ner client then the researcher has to review your product on their own time or talk with customers who use it and get their feedback. A former Gar*ner researcher admits that he knew of only 2 people while he worked there that ever did their own independent research.
The other portion of the “magic quadrant” comes from customer reviews and feedback on the products. Well who do you think the researcher talks with, yes you guessed it, references provided by their clients or other current Gar*ner clients. Again, unless the researcher takes it upon themselves to do independent reviews with customers not hand picked by the vendor there is no true review.
So, next time you read or come across the Gar*ner “magic quadrant” please read it with a grain of salt and please advise your customer or colleagues to do the same. This industry has enough problems that are real, allowing incorrect or misleading “research” to drive our purchasing and thus architecture decisions is only going to make the situation much worse.
P.S. This is all my opinion that I derived based on my own experiences with Gar*ner and interviews with former and current employees.
P.S.S. There is a pool within the company as to how long it takes before we are threatened with legal action based on this posting. Anyone think 7 days is a good bet?
