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 is rarely difficult. 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.

--Mike Bailey

Cross-posted from Skeptikal.org

"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.

--Ben Tomhave

Cross-posted from Skeptikal.org

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.

--Mike Bailey

Cross-posted from my personal blog.

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.