The risks of disclosing web vulnerabilities
One would think that an organization would be grateful to someone who found a vulnerability in their web application and provided them with the information needed to fix it. A recent episode where a security researcher has been charged with breaching the security of an online database makes it clear that this gratitude cannot be counted upon, however. Eric McCarty found a flaw in the University of Southern California (USC) online application system that would allow a SQL injection attack to extract the contents of a database which included some 275,000 records of both current students and applicants.
According to the original SecurityFocus article, the researcher discovered the flaw when using the system to apply to USC. The username and password text fields could be used to feed SQL commands to the database, allowing the entire contents to be read and/or modified. He then anonymously contacted SecurityFocus to disclose the flaw. Other than corresponding with SecurityFocus anonymously, McCarty did little, if anything, to cover his tracks; believing he was acting in good faith.
SecurityFocus contacted USC; the administrators of the web site claimed that only two records could be accessed via the SQL injection. When confronted with additional records, they admitted that the entire database was vulnerable and shut down the site for ten days in order to fix it. In addition, the administrators found the entries in the logfiles corresponding to the 'attack' and provided the IP address to law enforcement.
The IP address allowed the FBI to determine his identity and to execute a search warrant against him and his Gmail accounts. On his computer they evidently found seven records from the USC database and his Gmail account provided copies of the emails that he sent to SecurityFocus describing the vulnerability. The charges do not claim that he did anything with the seven records, just that he possessed them and had gotten them via 'misuse'.
The affidavit filed in the case claims that McCarty caused $140,000 in damages by causing USC to shut down its system for 10 days. It is somewhat difficult to see how telling someone about a flaw in their system makes one responsible for the time it takes them to fix it. It would seem that the original programmers of the system would be the ones who are culpable here.
Computer misuse statutes are typically written in such a way that any access, other than what is intended by the site owner, could be considered a crime. The intent of the 'perpetrator' rarely seems to be examined and this case is reminiscent of the conviction of a British security consultant last year. Daniel Cuthbert was concerned that he had been phished at a tsunami relief website and he did two simple tests to see if the site was for real. These tests set off alarms in an Intrusion Detection System and ultimately led to his conviction. In addition, his arrest caused him to lose his job as a security consultant.
It is very difficult to see how these kinds of prosecutions will lead to a safer internet and, in fact, would seem likely to cause just the opposite. Even checking for the existence of a flaw is criminal (at least in some jurisdictions) and actually finding a flaw and disclosing it (not in a public way, but privately to the affected organization) can lead to charges in other jurisdictions. Anyone who thinks they may have spotted a potential problem area in a web application would be risking a great deal by probing it further. In addition, administrators of these sites are unlikely to even look at a flaw unless one can show them an exploit. Even then, as the first USC response shows, they may be unwilling or unable to see the implications of the flaw. The sad fact is that the best response to the discovery of a web site vulnerability may be to keep it to one's self.
[Editor's note: anybody who informs LWN of a vulnerability in the LWN.net
code will, assuming they have not exploited that vulnerability for their
own gain, be thanked, publicly if desired.]
| Index entries for this article | |
|---|---|
| GuestArticles | Edge, Jake |