Perspective on Pentagon "Pwnage"
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.
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.
Labels: XSS
posted by mckt at
12:23 PM
3 Comments:
WADR, I don't think the wording of the post was off or needlessly hand wringing, it was the title you objected to. I think the post was ok, up to our usual "standards". :)
We tried to get alliterative with our P's as we try to catch some eyes with titles, but respected your feedback that we were getting cute and modified the title to be more precise within 5 minutes of first post.
On to your post:
You sort of vacillate in this post between XSS being something to be taken seriously and yet at the same time not that serious. That is sort of a good metaphor for how the security community views XSS. In the wake of more significant vulnerabilities, it is at the low end of the web application input validation food chain, however some consideration has to be given to the target.
Therefore I think a few things make this news:
- Its been open for 8+ months.
- It can be found trivially on that and other afis web sites.
- It has been noticed and reported on by 3 different sources.
- These web sites are probably under constant unsolicited penetration testing from around the world, and thus input validation problems should probably be corrected (proactively if possible).
- XSS attacks have enough of a threat level that sites under the DOD should take the time to close these out with proper input validation. Sort of a low risk attack + high value target equation, even if the high value is not based on sensitive data but rather reputation damage.
The Pentagon and other DOD entities have a reputation interest in appearing to be highly competent in securing their infrastructure. If there was no other reason to search out and correct common web site vulnerabilities (there are of course), this would be enough of a reason.
That said, this is not a condemning statement, input validation is a pain for many sites, and one can not draw further conclusions, as you point out, about an entity's security based on this alone.
Rather this is an opportunity to get some attention on this, and correct it. It is broken glass theory as applied to infosec.
By
DK, At
December 8, 2009 1:56 PM
Thanks for the feedback. I actually agree that I have dual opinions on this issue- on one hand, it's hardly new, newsworthy, or exceptional, on the other hand, that's scary in itself.
I absolutely think this needs exposure, and by pointing out that it affects more than just one useless domain, I hope to get the issue the exposure it deserves.
That said, if it's going to get exposure, we might as well get the facts right from the beginning, and worry about the appropriate issues. That was the goal of this post.
By
mckt, At
December 8, 2009 2:14 PM
I think one of the things to consider is that these types of vulnerabilities often include the potential to inject HTML content into the page.
In the industry, we tend to focus on "o noes! XSS! I has your cookies now and can do stuff you can do in this app! h0h0h0!" and presume that's the end goal.
Most likely, it's not.
Using the example in the article for instance, it's much more likely that an attacker will use that XSS vulnerability to inject an iframe that loads malware onto the viewing users machine (the required URL to do so is trivial to create).
That's far more useful to a criminal than stealing their cookie to force them to book a tour of the pentagon.
By
Jason, At
December 8, 2009 3:00 PM
Post a Comment
<< Home