Last night, Daniel Kennedy posted on his blog about a vulnerability in the Pentagon's web site. The vulnerability that was identified used XSS to steal session cookies. The story bothered me for a few reasons. Partially because it's usually a great blog, and the wording of the post made the vulnerability sound worse than it was. Daniel has since changed the wording, and I'm perfectly okay with that.
On to the exploit. My first reaction was that it isn't news. To begin with, the vulnerability is an old, known one- posted to XSSed last April. The site with the vulnerability contains no sensitive information, and unless you want to force somebody to book a tour of the Pentagon, really doesn't appear that useful at first brush. On top of this, there is no shortage of XSS vulnerabilities in much more sensitive .gov and .mil sites. The biggest story here really is that this vulnerability has been known for so long, and still has not been patched. Sadly, lack of fixes for every found XSS vulnerabilty isn't exactly a rare thing either.
I truly believe that XSS is one of the biggest threats on the web today. I'm not one to trivialize this kind of thing, but this one is small. As far as XSS holes go, this is about as trivial as can be. That said, this is still very dangerous.
Remember my cross-subdomain cookie attacks paper from last month? This is a perfect example of how widespread these issues are. The military has a hierarchical structure. It makes sense to give military websites a hierarchical structure. In this case, the domain with the vulnerability is pentagon.afis.osd.mil. Each of these subdomains means something- .mil for military, .osd for "Office of the Secretary of Defense," .afis. for "Armed Forces Information Services", and pentagon stands for, well, the Pentagon. Each department can have its own website, and its sub-departments have subdomains.
This is exactly how the web was designed. Academic Institutions' (.edu) websites also use this model heavily. It makes sense, particularly given the military and academic background of the web. Unfortunately, due to the cross-subdomain leakage of cookies described in my previous paper, any osd.mil website (there are hundreds, if not thousands of them, in various departments, serving various functions, and with various levels of sensitive data, user interaction, and exploitability) can be attacked due to this single, seemingly useless XSS hole.
As noted, finding such an XSS hole israrelydifficult. In less than half an hour, I was able to find half a dozen such domains vulnerable to XSS, some vulnerable to much worse. Most of those websites are simple informational websites, but there are a few with user logins, adminstrative sections, and sensitive data. This is where things get really scary.
Putting XSS in Perspective
After all that doom and gloom, I want to put this in perspective. As bad as an XSS hole is, it still requires somebody with the right level of access to click on it. Not necessarily hard, but definitely harder than a more direct exploit such as, for example, SQL injection. If somebody documents an XSS hole, they have not "hacked" that server. The Pentagon's website has not been "pwned." XSS is, and should be considered, a critical issue, but, at risk of appearing to agree with one of the dumbest quotes in the history of web security, it isn't generally used to hack into servers. Usually, that's not the point anyways- the attackers are after information, not a root shell.
Keep in mind, this is not a checklist of things you can and can't do with XSS. Don't use this in a risk assessment. Don't even quote me on it. This is just an attempt to put a realistic perspective around stories like the one mentioned above. I've seen too many headlines saying "$SITE Is Serving Malware!" or "$COMPANY Is Bad At Security" when there is no evidence of that happening. Web security is in a pretty dismal state right now, but spreading ungrounded FUD is simply not useful.
A single XSS vulnerability doesn't mean a company is bad at security. Frankly, a non-trivial application that is completely free of vulnerabilities is like a unicorn: It might exist, people claim to have seen them, but I have my doubts. I'd love to see organizations be more careful here, but in my experience, XSS vulnerabilities somewhere on a network is a virtual certainty. Security-wise, the key issue is what controls are in place to limit data leakage. News-wise, the key issue is how the organization responds to a vulnerability report.
XSS attacks are, by themselves, not actually very useful. However, they are attacks that stack beatifully with CSRF, credential theft, and clickjacking. They can also be leveraged nicely against vulnerable browsers and plugins to attack the client himself. It's worth noting though- unless you're stealing sensitive information directly from the page you're embedding the exploit in, it takes more than just XSS to do something malicious.
An XSS vulnerability in an application with sensitive data or access to sensitive resources (such as an internal network) is a serious matter indeed. A single targeted attack can compromise the data or allow an attacker to use the increased access of that user's browser as a jumping-off point for further attacks.
If that application is also popular, it is even more serious. The attack doesn't need to be targeted: it can be used in drive-by attacks or worms to hit a large number of users. As common as it is, this is in my opinion a worst-case scenario for XSS.
An XSS vulnerability can be used to anonymize attacks, but from what I've seen, attackers rarely bother. Using it this way generally just adds complexity without a lot of added benefit.
With cross-subdomain cookie attacks, an XSS vulnerability in one subdomain may attack another subdomain. Domains with many applications on their namespace (such as osd.mil) probably have other, more sensitive applications. Check before you disregard such a vulnerability on a non-sensitive application. They also may not. Check before you get too excited.
XSS works remarkably well for phishing. Currently, it's not particularly common to see it used this way, but it's happened before, and it will happen a lot more in the future.
There are many more uses for XSS, and there are just as many controls (ineffective as they are) for limiting XSS. The actual risks presented by an XSS vulnerability are extremely dependent on environment- the application, the server, other servers within the namespace, the web browsers being exploited, and security controls that are in place. Making vague statements about XSS vulnerabilities isn't particularly useful, and in most cases borders on FUD.
"Anything that can go wrong will go wrong." -Murphy's Law
Oftentimes misadventures and quirky failures are attributed to the Fates and Murphy's Law, as if we should have a reasonable expectation that everything will go smoothly all the time. Of course, given even the shortest amount of thought, the notion is absurd; especially if you work in IT! Whether we like it or not, we are dealing with complex systems every day, whether those be computers or cars or trains or planes or humans. The amount we don't know pretty much always exceeds what we do know.
As such, it's time that we embrace Murphy's Law. Instead of fighting the inevitable, as has been the modus operandi of security the past few decades, we need to adopt a survivability mentality that focuses on defensible and recoverable systems and processes. Murphy's Law enlightens us greatly in this regard: if we don't embrace failure, then failure will embrace us. And, as no position is absolutely defensible, it seems that a good place to start embracing Murphy's Law is in enhancing system and process recoverability.
There seem to be four key areas where a recovery mindset should always be applied:
Hardware Failures: Hard drives fail. Network links go down. Cooling fans die. Power cables get cut. These are facts, not FUD or innuendo.
Schedule Failures: It's not always possible to get the right people in the right place at the right time. It's not always possible to get the right equipment ordered and delivered on the schedule desired.
People Issues: We like to believe that people are capable of being consistent and reliable, and for the most part this is true. However, Murphy's Law tells us that we should expect key people to encounter unforeseen issues, such as sickness or family emergencies, at the least opportune time.
Unclear Requirements: One of the more fatal flaws in managing projects or people is failing to clearly articulate the expectation for performance. Yet, even when requirements are specified clearly, concisely, it can be difficult achieving a common understanding. As such, one should expect fuzziness around requirements, and thus gaps between expected and actual performance.
To address some of these challenges, and to help embrace Murphy and his Law, these key practices are recommended:
Update Policies: Policies provide your first line of due diligence effort when it comes to planning for the unexpected. Organizations should be familiar with business continuity planning and disaster recovery plans (BCP/DRP), but remember to expand those to account for more than just your typical break-fix scenarios. Additionally, policies for sick leave and remote access should be brought into the current era by allowing for extraordinary circumstances. Despite the media hype surrounding Avian Influenza and Swine Flu (H1N1), these plans should take into consideration pandemic scenarios (this Fall has already seen particularly virulent cold and flu strains). Plans should also consider natural disasters, man-made disasters, etc.
Ensure Remote Access Capabilities: One key consideration in the face of schedule and people challenges is finding ways to bring people together online when face-to-face collaboration isn't possible. Teleconference solutions, unified communications using VoIP and instant messaging, and video conference technologies have all matured well in the past few years to meet some of these needs. In terms of remote access, one additional consideration is to discuss spike license agreements with your VPN vendor, such as to be used in the case of a pandemic or weather disaster that would necessitate a largely remote work force for a short period of time.
Have a Communication Plan: It is imperative that organizations have communication plans in place, and that they provide personnel with routine awareness training about the communication plan. Severe weather, such as blizzards, ice storms, or tornadoes, can bring commuting to a standstill. The sudden emergence of a quickly spreading pandemic can force a switch into an emergency remote-worker configuration. In all cases, it's important to establish multiple communication vehicles, make personnel aware of those vehicles, and then follow the plan as needed. Incidentally, don't just rely on a single web site for your status communication, since the loss of your computing facilities could make it rather difficult to get the message out. Instead, make sure your communication plan is suitably diverse, making use of two or more communication vehicles for primary communication with personnel.
Test It! One of the worst things you can do is write policies and plans without testing them. In the middle of a crisis is the wrong time to learn that you made an error in planning. Instead, test plans on a regular basis (at least annually). This advice goes double for failover sites. If you don't test failover plans, then how do you know that they'll work? The last thing you want to do is compound an event by having additional failures. An ounce of prevention is worth a pound of cure.
Adobe has published a response to the latest issues I've been talking about. Somehow, they have managed to neatly dodge the issues in question and fixate on the Same Origin Policy. Is that policy news to anybody? Of course not. That's not the point. That's not even the issue, though I do believe the policy is flawed, which I'll explain in a few paragraphs.
Adobe continues to compare this to uploading Javascript files. Here's the difference:
If I upload a .js file to a webserver, I cannot execute it in the context of that server. Javascript alone will not execute.
If I upload a .html file to a webserver, I can execute Javascript within it in the context of that server, because my browser recognizes the text/html content-type header that the webserver sends.
If I upload a .html file to a webserver, but an application/zip header is sent by the server, it will not render at all.
If I upload an HTML file with a non-html extension to a webserver, and the server does not send a text/html content-type when serving the file, I cannot render HTML or execute Javascript.
If I upload a ZIP file with HTML prepended to it, I cannot render HTML or execute Javascript.
If I upload a .swf file to a webserver, I can execute it in the context of that server.
If I upload a SWF file with a non-SWF extension to a web server, I can execute it in the context of the server.
If I upload a ZIP file with a SWF file prepended to it, and the server sends an "application/zip" content-type, I can execute it in the context of the server.
Flash's handling of potential code is clearly MUCH more permissive than Javascript's.
This makes it far easier to upload an object to a webserver- a Flash file can look like anything to the server and still be executable, as long as it starts with the right sequence of bytes. In many cases, simply changing the file's extension is enough to bypass upload restrictions. In other cases, you have to get crazy with it, but as noted in the original post, the entire ZIP family of files can have a SWF embedded in them while still being valid. Checking whether the file is a valid ZIP file will do you no good. The only way to be sure that the file does not contain a SWF is to specifically look for a SWF header. Any security professional will tell you that a technology that requires a blacklist approach to input validation is poorly designed.
There are some solutions for the security administrator. They aren't easy to implement. The best thing to do is place all your user-generated content on a separate server. For large web applications, this is probably already happening. But do you think that every prebuilt forum, ecommerce, blog, and gallery application out there is going to get redesigned to fix Flash's problem? Do you think the hobbyists and mom-and-pop shops are going to set up a separate server for holding this content? As most of them don't even have one dedicated server, this is not just unrealistic to expect, it's virtually impossible. Again, I'll pull out the example of bugs.adobe.com, a prebuilt issue tracking application that stores files on... bugs.adobe.com. I reported this issue several days ago, and not only have they not moved all user-generated content off the server, they haven't even disabled the file upload feature.
The other solution for administrators is to serve user-generated files with the content-disposition: attachment header. This is relatively easy to do, and it's the only reasonable thing they've suggested. It is still hardly an ideal solution though. First off, some user-uploaded content shouldn't be served with this header. Images that people expect to be able to inline in other web pages are one example. Validating images is obviously easier (and more common) than validating zip files, but the point stands.
Now, let me be clear: The Same Origin Policy is a completely separate issue from the execution of the content, but since Adobe won't stop talking about Flash's Same Origin Policy, allow me to demonstrate exactly why it is designed wrong.
If a Javascript file hosted on foo.com is included in a web page on bar.com, that file can only affect the bar.com domain. Same origin policy. Woot.
If an HTML file hosted on foo.com is iframed into a web page on bar.com, that file can only affect the foo.com domain. Same origin policy. Woot.
If a Flash file hosted on foo.com is embedded in a web page on bar.com, that file can run Actionscript on foo.com, as well as execute Javascript on bar.com.
All the attention to this point has been on uploading malicious files, but let's take a look from another angle. What if victim.com has its own Flash objects, which use Javascript calls to interact with the web pages they're included on? This is not an unreasonable assumption- it's the very reason that a Javascript interface is built into Flash player. Here's the problem: these Flash objects can be embedded in evil.com's webpage. evil.com can run his own Javascript which modifies function prototypes (again, only in the context of evil.com), poisoning the functionality that victim.com's Flash object relies on. When that Flash object then uses data from the Javascript side of things to communicate with its origin server, you again have cross-origin interaction.
What kind of Same Origin Policy allows code to execute on multiple origins? A seriously flawed one.
From Adobe's response: "[The Same Origin Policy] states that two pieces of content hosted on the same domain and loaded by the same protocol trust each other. Conversely, two pieces of content hosted on different domains do not trust each other and cannot interact." If this was the way it worked, we would have no problem. In my examples, I used 2 pieces of content (a SWF and an HTML page with Javascript), on two domains (foo.com and bar.com), using the same protocol (HTTP), and I made them trust each other. By their own definition, Flash's policy does not work. Adobe's response is dead wrong.
Okay, people are looking at this Flash issue. Neat. A lot of people don't fully understand it, which may be my fault. Here, I'm going to try to respond to some of the questions and comments that I've received from various parties.
This is not a single issue
While it is a single, basic issue that enables this exploit, it is the intersection of that and several others that makes it critically bad.
Specifically, the fact that an uploaded file can attack a server is hardly news. As mentioned in my original post, Adobe has acknowledged this issue with advisories multiple times. If you were already aware of it, good on you. However, it still is new to most website administrators, and more importantly, these are the people that Adobe expects to fix it.
The part that is new, is the focus of this research, and admittedly could have been described better, is that the Flash player will execute any file it is asked to execute. The HTML <embed> tag is used to include objects that the browser may not be natively able to handle. Arguably, this may be a browser issue as well, as the content-type supplied by HTTP headers should take precedence over the type attribute specified in the HTML page, but the plugin itself should also verify that the proper content-type is sent in the server's response HTTP headers before executing the plugin. Flash's plugin does not do so.
If Flash's plugin did handle this correctly, the other issue documented here- that of overloading various filetypes, primarily ZIP, would be nearly useless. The point of that work was to demonstrate just how difficult it is for administrators to filter uploaded content by file validation, and to provide various examples of how to bypass such validation with 100% legal files, which are still potentially malicious. More on that in a moment.
This is not a cross-site scripting attack
The end result of the attack can indeed be XSS, as Actionscript may execute Javascript through the "ExternalInterface" method, but the source of this problem is not necessarily input sanitization. It is a core design flaw in Flash's same-origin policy, combined with the weak content ownership management that is already common on the majority of websites and prebuilt web applications on the internet.
Calling this attack XSS, when it involves no Javascript (arguably, not really a requirement), is not cross-site (again, not really a requirement, despite being in the name), and involves no HTML injection, is a stretch, but the similarity is certainly there, bringing me to the next point:
This attack abuses the user to attack the server
This is where it is very similar to XSS. The whole point is to hijack the user's browser and have the ability to issue requests to, and read the results from the server. In the context of a user's session, this can be a very bad thing. Neither the server itself nor the client's computer is being compromised directly; The web application, and any data or functionality within, is now accessible to the attacker.
Adobe does not intend to fix it
As they have made abundantly clear, Adobe considers this to be the web administrators' problem. Regardless of whether you agree with them or not on this, it is hard to dispute that Adobe's expectation of administrators to prevent this issue is unrealistic.
In fact, Adobe does not appear to be able to manage this issue on their own web properties. For example, photoshop.com is an interactive image library application. Uploaded images are not validated fully, and are stored on (and executable from) api.photoshop.com. This is indeed a separate domain from the rest of the application, and should be safe (though I'd point you to my paper on cross-subdomain attacks and say it is still poor practice), but www.photoshop.com's crossdomain.xml policy specifically allows access from *.photoshop.com.
Next, take a look at bugs.adobe.com. This third-party issue tracking system allows users to upload screenshots (or zip files of screenshots) of bugs. These files are hosted on bugs.adobe.com, and can be used to exploit not only bugs.adobe.com, but again through crossdomain policies, www.adobe.com, www.acrobat.com, www.photoshop.com, and other Adobe web properties.
You'll never guess where www.photographersdirectory.adobe.com keeps its uploaded images. Or where forums.adobe.com keeps users' uploaded avatars.
Clearly, expecting website administrators to understand, not to mention be able to fix this issue is ridiculous and unrealistic. I originally compared this to the GIFAR exploit, which uses very similar attack techniques against the Java plugin. Unlike Adobe, Sun took responsibility and fixed their plugin. Whether they are wrong or right, Adobe is uniquely in a position to create a client-side fix for the Flash users. Until they do so, many websites will remain vulnerable.
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.
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.
Posted by: Dave Amsler in Untagged on
Oct 12, 2009
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?
I spoke about CSRF attacks at Defcon a few months ago, and while I was there, I had the opportunity to meet with Justin Samuel, the creator of RequestPolicy. RequestPolicy is a Firefox extension designed to provide CSRF protection and enforce web application boundaries. I love it.
Request Policy completely breaks the web... in all the right ways. You'll initially hate using it. StumbleUpon links will no longer work, due to their use of cross-site iframes. Shortened bit.ly and tinyurl links will present you with an intermediate page instead of following 302 redirects. Deeplinked images on blogs, social networking sites, and other pages won't show up. You will have to manually approve off-domain requests on a case-by-case basis. It's not convenient, but it's a lot safer than letting your browser blindly request resources.
In short, RequestPolicy gives you granular control over your browser. If you know what you're doing, this is a good thing. If you're a normal user, you'll probably find yourself checking the "Temporarily Allow All Requests" box or disabling the extension completely. I can't say I'd blame you, but try not to. The extension is still very young in its development process, and most of the issues that I've run into are UI/usability problems. The developer is aware of many of these issues and working to fix them, but it's not easy. Samuel is very open to suggestions, feedback, and criticism, so if you have useful input, I'm sure he'd be happy to hear it- just hit the contact link on the extension's website.
The UI is heavily modeled after NoScript, so if you're a fan of that extension (and you should be), it isn't too difficult to figure out. Off-domain requests are disabled by default, and can be enabled on a per-site, as-needed basis. The preferences pane is simple and fairly easy to understand, allowing you to more easily manage your whitelist of allowed domains. Additionally, the extension ships with a setup wizard to create generic whitelists based on common sites (recaptcha, for example, has to be whitelisted for every domain that uses it). All in all, it's pretty easy to set up, and though it will break a lot of sites at first, as you fine tune the settings to your browsing habits, it really doesn't get in the way too much.
RequestPolicy was created for a very specific purpose: to give users the ability to better control their browsers and prevent CSRF. It's a bit rough at the moment, but it's very good at it.
When I was at Hacker Halted recently, I watched a great talk by Ron Gula of Tenable. He brought up that most of the advice for IDS tuning is wrong. It's something I've been arguing for years, but haven't ever sat down to write out the main process by which I recommend to clients to reduce IDS noise.
First, I'm a big believer in the horrible damage caused by false positives. My view on the world was altered irrevocably in the early days of IDS by Stefan Axelsson's paper "The Base Rate Fallacy and its implications for the difficulty of Intrusion Detection". It consistently amazes me how few in our industry have read the paper. For those who aren't going to read the paper (and you really, really should), the message is simple: false negatives are annoying. False positives will quickly undermine the value of the IDS in any environment.
This isn't counter-intuitive, as the advice given by most IDS tuning guides is to eliminate the "false positive generating" signatures first. While this is good advice, we don't usually consider what is meant by a false positive.
There are two types of false positives. First, the signature that detects good traffic as inappropriate. This is what we're used to tuning out.
But these aren't the cause of most of the noise in most environments.
In most environments, we spend a lot of time dealing with the second type of false positive: the inappropriate traffic that is legitimately detected that we just don't care about. This corresponds to the risk tolerance of the organization where it comes to security events. In most organizations, that nmap is run is not a risk that the organization cares about. However, we tune these events out of our IDS far too infrequently "just in case it finds something".
It's the "just in case it finds something" that causes us to take too much data from our IDS and get overwhelmed with the noise.
Ask yourself... where are you allowing your IDS to alert on items that are below your risk tolerance? Why?
