# Security Research and Computer Crime - Where do we Draw the Line?

This is interesting - the [case of Eric McCarty][1], a security
researcher and sysadmin charged by Federal prosecutors last month
with "[knowingly having transmitted a code or command to
intentionally cause damage][2]" to the University of Southern
California's applicant website (I noticed the FBI press release uses
the word "sequel" instead of SQL. I hope that wording didn't come
from the complaint itself...).

Apparently, McCarty exploited a SQL injection flaw to access student
data (which included social security numbers and dates of birth) in
the database backing USC's website. He then notified
[SecurityFocus][3] via email, who notified USC of the
vulnerability. USC shut their site down for two weeks while it was
being fixed (my guess is the "damage" comes from the fact that USC
had to take their applicant website offline, since McCarty didn't do
anything malicious with the information).

Here is the [text of the statute][4] he is alleged to have violated
(see section (5)(A)(i)).

The case, and others like it, show the ethical conflict involved in
some computer crime prosecutions. In particular, this case reminds
me of [Randal Schwartz's case][5] from way back in 1993. The same
issues were raised back then - in that case, Schwartz was running
the crack program to disclose weak passwords, but without
authorization. In the end, he was convicted of three state felony
charges.

Unfortunately, the law is pretty clear in these cases. It appears
McCarty violated Federal law, a felony that could land him up to ten
years in jail. This seems quite excessive, however, given McCarty's
intent. Perhaps some exceptions are needed in various Federal and
state computer crime statutes to allow for legitimate security
research, although the question of what is legitimate and what is
not could be unclear.

Sure, USC had to take down their site for two weeks (does anyone
else but me think that's a long time to fix a SQL injection bug?),
but just think of how long it would have been down after a real
compromise.

At the same time such an exception could be said to encourage
security research, you could see this used as a loophole that
crackers with malicious intent could use to escape prosecution.
"Really, detective, I was just testing their security".

Web application security testing can also be dangerous,
unintentionally resulting in database or web server outages. For
now, the risks of doing "stealth" research just are not worth it,
whatever the intent.

## Comments

**[m](#25 "2006-05-11 20:22:00"):** He embarrassed USC, committed an
act which most people can't understand, and this is therefore a
"crime".I cracked a couple of systems with the sysadmin's or some
responsible persons permission. Usually the impetus was provided by
some boasting. I admit it was fun to hand a list of 80% of a
system's user ids and passwords to management, and watch the smirks
fall off their faces. Even though I always did it with permission,
nobody was ever grateful. I decided to stop before I got too many
people ticked off at me.

**[Randal L. Schwartz](#26 "2006-05-12 03:07:00"):** And just so
that comment isn't confused with [my case][6], I'll add that my
prosecution was (wild guess) pushed by the embarassment I caused as
well, and not related at all to any "damage" except from a
misunderstanding.

**[Thinknix](#27 "2006-05-12 04:58:00"):** Thanks for the comments. I
know that even from legitimate security assessment work I've done
over the years that there is frequently an adversarial relationship
between you, the consultant, and the IT staff where you are
working. They view you as an outsider with the power to embarrass or
even cost them their jobs. I think this stems from the fact that at
many businesses, the IT staff know that security is a farce, hidden
behind partially-working or poorly maintained infrastructure.
Sometimes they just have no idea what security is about, and don't
want their superiors to know.

[1]: https://web.archive.org/web/20070304042150/http://www.informationweek.com/news/showArticle.jhtml?articleID=187201428
[2]: https://web.archive.org/web/20061209151723/http://losangeles.fbi.gov/dojpressrel/pressrel06/la042006usa1.htm
[3]: http://www.securityfocus.com/news/11239
[4]: https://web.archive.org/web/20061231003020/http://www.usdoj.gov/criminal/cybercrime/1030NEW.htm
[5]: https://web.archive.org/web/20061106062239/https://www.lightlink.com/spacenka/fors/
[6]: http://www.lightlink.com/fors/
.