Graduate student Christopher Soghoian is no stranger to controversy.
Last year he made a name for himself by making public an exploit for printing airline boarding passes, much to the dismay of the US Federal Aviation Administration, Transportation Security Administration and Department of Homeland Security. He then went on to expose a phishing scam at Indiana University and a man-in-the-middle attack which made use of the Bank of America key site authentication system.
Just last week, Soghoian went public with word of brand new vulnerability that affects some popular extensions used by the Firefox browser.
Although it may look like fun to poke holes in systems used by millions, the process of vulnerability disclosure is often fraught with peril. Lately companies have been suing researchers for violating the US Digital Millennium Copyright Act (DMCA) because they need to reverse-engineer proprietary code. In response, some researchers have foregone notifying vendors altogether and started posting vulnerabilities to public mailing lists.
Others seek shelter behind independent organisations that co-ordinate vulnerability disclosure between vendors and researchers. Still others simply sell their discoveries to security companies, like iDefense, which take on all the risks and work with the vendor to address the vulnerablities directly.
In the case of the Firefox flaw, Soghoian chose to contact the affected vendors himself and decided to give each 45 days to resolve the issue before he went public. Soghoian spoke about the delicate process of reporting a security vulnerability and any changes he'd make the next time round.
Q: The vulnerability you reported is not within the Firefox browser itself but on extension servers not under Mozilla's control. How did you come upon this vulnerability? Was it a hunch?
A: In this case it was basically a hunch. I wanted to see what Firefox was doing when it was loading. I had a suspicion that maybe it was calling home and revealing private information or something along those lines. I just wanted to see what Firefox was doing and who it was talking to when it started up. So I basically just started the browser up and watched the communications between the browser and anywhere else on the internet.
There were a few Secure Socket Layer [SSL] connections to various servers run by Mozilla for the extensions that I had, but there were a number of plain text requests going out to Google and other companies for other extensions that I had. Those stuck out like a sore thumb. It wasn't so much that they were sending information, it was that they were downloading information. And they were downloading updates, so that was a much bigger issue. [After] looking at it with a network sniffer, about two hours later I had a working exploit. So it was very, very quick to go from a hunch to a working code.
Vendors should at least have a fair chance. Especially when we're talking about software where millions of users are potentially at risk
Christopher Soghoian, security researcher
Because you're talking about intercepting a call out from your browser to an unencrypted server on the internet, is this attack more likely to occur if you're using a wireless laptop?
Not necessarily true. A wireless connection is really, really easy for an attacker to take over because of the fact he doesn't need to be sitting near you. If you're using a [LAN] hub environment, as opposed to a switch environment, for your network, then this attack is possible — anyone who is plugged into the same hub can do this. If you're using a home router, be it a wireless router or a wired router, and you have not changed the default password, it is possible, using what's called a drive-by phishing attack, for an attacker to change your router's setting when you visit a malicious website. In that case, the attack could work as well. This scenario of someone sitting in a Starbucks and getting infected is the most common scenario, but there are others.
Let's say I have a hunch about the security of a product and it proves to be true; I can write an exploit and demonstrate it. Now what do I do?
There are many things you can do. It sort of depends on which school of thought you follow. There's the responsible-disclosure school and the full-disclosure school. If you follow the full-disclosure school of thought, then you post the information, and potentially a proof-of-concept exploit, to a mailing list on day one to get your name out there.
That is not what you did.
I don't agree with that approach in most cases. Contrasting to the airline situation I was involved with last year, where it was an exploit that had been known about for three years and had been ignored, I feel like vendors should at least have a fair chance. Especially when we're talking about software where millions of users are potentially at risk. I feel an obligation to give the vendors a chance to fix things.
But there's only so much of a chance that we should give them. I gave Google and Yahoo, in this case, 45 days to fix it and they ended up not fixing it in that time frame. And then, after it was made public, suddenly they rushed. Once it's out there, they definitely have a strong incentive to fix it — the shame factor, I think — but, at least for my own peace of mind, I wanted to give the vendors a heads-up in an attempt to fend off criticism after the fact. I wanted to be able to claim at least [that] I did the right thing.
Whenever you follow the responsible-disclosure route, you're always taking a risk because the company knows your name and they can set lawyers on you
Christopher Soghoian, security researcher
Why give them 45 days? You didn't pick that number out of the air did you?
The CERT organisation, a security organisation run out of [Carnegie Mellon University], have a 45-day deadline, and that seemed about right to me. One of the other downsides to responsible disclosure is that someone else might come up with the attack also, at the same time. In this case, [my disclosure] came out after a couple of other people had figured [it] out within the last couple of weeks, and they were preparing to go public, too. So, the more you wait, the chance goes up that someone will try and steal your thunder.
So the burden's entirely on you, the researcher. You find the vulnerability, now you must behave responsibly, yet run the risk of others exploiting it in the meantime. Shouldn't there be a central repository you can tell when you discover a vulnerability?
You can tell CERT or, if you want to cash in, you can tell iDefense or one of those other organisations, and they'll take it off your hands. I read an academic paper about a guy who'd sold an exploit for $50,000 (£25,433) to a branch of the US government. In that case, the US government didn't tip anyone off; they kept it to themselves. But there are many things you can do.
In this case, I wanted to maintain friendly relations with the companies. I worked at Google last year. I travelled around the world with money that Google put into my bank account, essentially, so…
