Posts in Kudos, Opinions and Rants
Page Content
Who do you trust?
In my earlier posts on passwords, I noted that I approach on-line password “vaults” with caution. I have no reason to doubt that the many password services, secure email services, and other encrypted network services are legitimate. However, I am unable to adequately verify that such is the case for anything I would truly want to protect. It is also possible that some employee has compromised the software, or a rootkit has been installed, so even if the service was designed to be legitimate, it is nonetheless compromised without the rightful owners knowledge.
For a similar reason, I don't use the same password at multiple sites -- I use a different password for each, so if one site is “dishonest” (or compromised) I don't lose security at all my sites.
For items that I don't value very much, the convenience of an online vault service might outweigh my paranoia -- but that hasn't happened yet.
Today I ran across this:
MyBlackBook [ver 1.85 live] - Internet's First Secure & Confidential Online Sex Log!
My first thought is “Wow! What a way to datamine information on potential hot dates!” :-)
That quickly led to the realization that this is an *incredible* tool for collecting blackmail information. Even if the people operating it are legit (and I have no reason to doubt that they are anything but honest), this site will be a prime target for criminals.
It may also be a prime target for lawyers seeking information on personal damages, divorce actions, and more.
My bottom line: don't store things remotely online, even in “secure” storage, unless you wouldn't mind that they get published in a blog somewhere -- or worse. Of course, storing online locally with poor security is not really that much better.....
So you think AJAX and Web 2.0 are all that and a bag of chips
You know, I would feel a lot better about this technology if someone had fixed basic problems with the way browsers handle JavaScript, about JavaScript policy specifications and compliance testing, and if there were good, usable and mature static analysis tools that could detect cross-site scripting vulnerabilities (Pixy by Jovanovic et al. comes to mind as a promising open source tool), and if people used them. These problems have been known for a long time.
- Same origin policy and shared servers. So, my home page is http://homes.cerias.purdue.edu/~pmeunier/; if I put a nasty javascript there, it can access or change the contents of other CERIAS home pages if you follow a link from my page, or if my page opens another home page for you. I made a demo which for Safari users displays Adam Hammer's home page url but with contents of my choosing (with apologies to Adam). Firefox is a bit smarter and the url displayed is instead that of my page, which could clue attentive users to the fact that the content really comes from elsewhere. Adam doesn't actually have a home page there.
- Modern browsers still can't survive a visit to this site (WARNING! Your browser will likely crash or become unusable when you click buttons on that site): Nasty Javascript Bombs (I didn't try all browsers, like Opera, but Safari died horrible deaths)
- Modern browsers can still be captured: Firefox users visit (WARNING! you won't be able to return) the jail, do not collect $200.
- Searching for JavaScript-related vulnerabilities in 2006 in the National Vulnerability Database gives 124 matches (and the year is not even over). 3 of those are accidental hits (because "javascript" was part of a file name or such). About 50% are cross-site scripting vulnerabilities, that could include the above Javascript (and likely worse code than changing your choice of hero). About 40% are coding errors in the JavaScript implementation. About 10% are still issues with the enforcement of JavaScript default security policies, or things that should explicitly be stated as part of default policies (e.g, CVE-2006-2900 and CVE-2006-2894, abusing Javascript keystroke events to trick users into typing where they didn't mean to). Cross-site scripting vulnerabilities are hard to avoid because scripts can be embedded almost anywhere inside HTML. The separation between code (JavaScript) and data (HTML) is flimsy and complex. I predict that XSS vulnerabilities will be to AJAX applications what buffer overflows and format string vulnerabilities are to C: a real pain. There is no sign that browsers have matured enough yet to be trusted in handling JavaScript safely, and this will likely continue for many years.
- Perfectly compliant JavaScript and browsers can be used to scan internal networks and even perform limited exploits.
- JavaScript seems to be used most of the time to perform tasks that are user-unfriendly (hide user interface elements and generally remove control from the user, create pop-unders, show ads, track you by history, etc...). So, I should expose myself to these, and the above and future vulnerabilities, so you can program something that's a little slicker, or poorly duplicates the functionality of executables on my system? Huh.
OSCON 2006: Where’s the Security?
OSCON 2006 was a lot of fun for a lot of reasons, and was overall a very positive experience. There were a few things that bugged me, though.
I met a lot of cool people at OSCON. There are too many folks to list here without either getting really boring or forgetting someone, but I was happy to put a lot of faces to names and exchange ideas with some Very Smart People. The PHP Security Hoedown BOF that I moderated was especially good in that respect, I thought. There were also a lot of good sessions, especially Theo Schlossnagle's Big Bad PostgreSQL: A Case Study, Chris Shiflett's PHP Security Testing, and the PHP Lightning Talks ("PHP-Nuke is a honeypot" - thank you for the best quote of the convention, Zak Greant).
On the other hand, I was very surprised that the Security track at OSCON was almost nonexistent. There were four sessions and one tutorial, and for a 5-day event with lots of sessions going on at the same time, that seems like a really poor showing. The only other tracks that has security-related sessions were:
- Linux (including one shared with the Security track)
- PHP
- Business
- Databases
- Desktop Apps
- Emerging Topics
- Java
- JavaScript/Ajax
- Perl
- Products and Services
- Programming
- Python
- Ruby
- Web Apps
- Windows
The biggest mistake of Myspace
Myspace, the super-popular web site that your kid uses and you don't, was once again hit by a worm, this time utilizing Macromedia Flash as its primary vector. This was a reminder for me of just how badly Myspace has screwed up when it comes to input filtering:
- They use a "blacklist" approach, disallowing customized markup that they know could be an issue. How confident are you that they covered all their bases, and could anticipate future problems? I don't trust my own code that much, let alone theirs.
- They allow embed HTML tags. That means letting folks embed arbitrary content that utilizes plugins, like... Flash. While Myspace filters Javascript, they seem to have forgotten that Flash has Javascript interaction and DOM manipulation capabilities. If you're a Myspace user, you may have noticed Javascript alert()-style pop-up windows appearing on some profiles -- those are generated by embedding an offsite Flash program into a profile, which then generates Javascript code.
Reporting Vulnerabilities is for the Brave
I was involved in disclosing a vulnerability found by a student to a production web site using custom software (i.e., we didn't have access to the source code or configuration information). As luck would have it, the web site got hacked. I had to talk to a detective in the resulting police investigation. Nothing bad happened to me, but it could have, for two reasons.
The first reason is that whenever you do something "unnecessary", such as reporting a vulnerability, police wonder why, and how you found out. Police also wonders if you found one vulnerability, could you have found more and not reported them? Who did you disclose that information to? Did you get into the web site, and do anything there that you shouldn't have? It's normal for the police to think that way. They have to. Unfortunately, it makes it very uninteresting to report any problems.
A typical difficulty encountered by vulnerability researchers is that administrators or programmers often deny that a problem is exploitable or is of any consequence, and request a proof. This got Eric McCarty in trouble -- the proof is automatically a proof that you breached the law, and can be used to prosecute you! Thankfully, the administrators of the web site believed our report without trapping us by requesting a proof in the form of an exploit and fixed it in record time. We could have been in trouble if we had believed that a request for a proof was an authorization to perform penetration testing. I believe that I would have requested a signed authorization before doing it, but it is easy to imagine a well-meaning student being not as cautious (or I could have forgotten to request the written authorization, or they could have refused to provide it...). Because the vulnerability was fixed in record time, it also protected us from being accused of the subsequent break-in, which happened after the vulnerability was fixed, and therefore had to use some other means. If there had been an overlap in time, we could have become suspects.
The second reason that bad things could have happened to me is that I'm stubborn and believe that in a university setting, it should be acceptable for students who stumble across a problem to report vulnerabilities anonymously through an approved person (e.g., a staff member or faculty) and mechanism. Why anonymously? Because student vulnerability reporters are akin to whistleblowers. They are quite vulnerable to retaliation from the administrators of web sites (especially if it's a faculty web site that is used for grading). In addition, student vulnerability reporters need to be protected from the previously described situation, where they can become suspects and possibly unjustly accused simply because someone else exploited the web site around the same time that they reported the problem. Unlike security professionals, they do not understand the risks they take by reporting vulnerabilities (several security professionals don't yet either). They may try to confirm that a web site is actually vulnerable by creating an exploit, without ill intentions. Students can be guided to avoid those mistakes by having a resource person to help them report vulnerabilities.
So, as a stubborn idealist I clashed with the detective by refusing to identify the student who had originally found the problem. I knew the student enough to vouch for him, and I knew that the vulnerability we found could not have been the one that was exploited. I was quickly threatened with the possibility of court orders, and the number of felony counts in the incident was brandished as justification for revealing the name of the student. My superiors also requested that I cooperate with the detective. Was this worth losing my job? Was this worth the hassle of responding to court orders, subpoenas, and possibly having my computers (work and personal) seized? Thankfully, the student bravely decided to step forward and defused the situation.
As a consequence of that experience, I intend to provide the following instructions to students (until something changes):
Edit (5/24/06): Most of the comments below are interesting, and I'm glad you took the time to respond. After an email exchange with CERT/CC, I believe that they can genuinely help by shielding you from having to answer questions from and directly deal with law enforcement, as well as from the pressures of an employer. There is a limit to the protection that they can provide, and past that limit you may be in trouble, but it is a valuable service.
- If you find strange behaviors that may indicate that a web site is vulnerable, don't try to confirm if it's actually vulnerable.
- Try to avoid using that system as much as is reasonable.
- Don't tell anyone (including me), don't try to impress anyone, don't brag that you're smart because you found an issue, and don't make innuendos. However much I wish I could, I can't keep your anonymity and protect you from police questioning (where you may incriminate yourself), a police investigation gone awry and miscarriages of justice. We all want to do the right thing, and help people we perceive as in danger. However, you shouldn't help when it puts you at the same or greater risk. The risk of being accused of felonies and having to defend yourself in court (as if you had the money to hire a lawyer -- you're a student!) is just too high. Moreover, this is a web site, an application; real people are not in physical danger. Forget about it.
- Delete any evidence that you knew about this problem. You are not responsible for that web site, it's not your problem -- you have no reason to keep any such evidence. Go on with your life.
- If you decide to report it against my advice, don't tell or ask me anything about it. I've exhausted my limited pool of bravery -- as other people would put it, I've experienced a chilling effect. Despite the possible benefits to the university and society at large, I'm intimidated by the possible consequences to my career, bank account and sanity. I agree with HD Moore, as far as production web sites are concerned: "There is no way to report a vulnerability safely".
Edit (5/24/06): Most of the comments below are interesting, and I'm glad you took the time to respond. After an email exchange with CERT/CC, I believe that they can genuinely help by shielding you from having to answer questions from and directly deal with law enforcement, as well as from the pressures of an employer. There is a limit to the protection that they can provide, and past that limit you may be in trouble, but it is a valuable service.


