Slashdot Mirror


Researcher Gets 20 Days In Prison For Hacking State Websites As Political Stunt (softpedia.com)

An anonymous reader writes from a report via Softpedia: David Levin, 31, of Estero, Florida will spend 20 days in prison after hacking two websites belonging to the Florida state elections department. Levin, a security researcher, tested the security of two Florida state election websites without permission, and then recorded a video and posted on YouTube. The problem is that the man appearing in the video next to Levin was a candidate for the role of state election supervisor, running for the same position against the incumbent Supervisor of Elections, Sharon Harrington. Harrington reported the video to authorities, who didn't appreciate the media stunt pulled by the two, and charged the security researcher with three counts of hacking-related charges. The researcher turned himself in in May and pleaded guilty to all charges. This week, he received a 20-day prison sentence and two years of probation. In court he admitted to the whole incident being a political stunt.

8 of 85 comments (clear)

  1. Political stunt as it may've been... by Lead+Butthead · · Score: 4, Insightful

    the abysmal security in place is down right embarrassing. and we all know how much the government likes to silence the messengers.

    --
    ELOI, ELOI, LAMA SABACHTHANI!?
  2. He gives "security research" a bad name by QuietLagoon · · Score: 3, Funny
    Granted some of the system (most?) needs to have a good security audit, he should not have done it so publically. He should have contacted the owner of the site and told them about the issues he found.

    .
    Putting the video on youtube shows that he deserved the jail time he received.

  3. Re:What, no thanks? by phantomfive · · Score: 4, Informative

    Here's the actual video. Between the guy who made the video, and the team that wrote code allowing SQL injections, the latter is the more serious crime.

    You should never, ever write code that allows SQL injections. It's negligent.

    --
    "First they came for the slanderers and i said nothing."
  4. Re:Never report security vulnerabilites by tomhath · · Score: 3, Interesting

    If he had reported the vulnerability he wouldn't go to jail. But by exploiting it to make a candidate look bad he deserves what he'll get in jail.

  5. Bad security is NOT an invitation to break in by Sycraft-fu · · Score: 4, Interesting

    You don't want it to become one either, or people can break in your house because it has shit security. Even if you have "good" security for a home, it still sucks in the grand scheme and is trivial to bypass. However I imagine you'd be pretty pissed if someone broke in and said "Well you have abysmal security, don't silence the messenger!"

    That doesn't mean people shouldn't try and have good electronic security (and physical security for that matter) but that they don't is not an invitation or excuse for breaking in.

  6. Re:Never report security vulnerabilites by AlphaBro · · Score: 3, Insightful

    If it's a live system, permission has not been granted, and a similar test environment cannot be setup, then I Ignore it, and if at all possible, I avoid using the vulnerable system in question. Bear in mind I say this as someone that does vulnerability research for a living. I'm not a fan of the extant legislation, but if that's what society wants from me, that's what it's going to get. I refuse to risk my freedom for a bunch of assholes that don't want my help, and I've plenty of paying customers that aren't complete idiots, so my attention is better spent on them.

    Maybe someday the pols will get their shit together and the problem will work itself out, but I have little faith at this point.

  7. Re:What, no thanks? by kbrannen · · Score: 3, Informative

    You should never, ever write code that allows SQL injections. It's negligent.

    Then why do nearly all SQL libraries enable injections? Why aren't parameterized queries required? Is there any reason not to use them?

    Is there any reason not to use parameterized queries? No.

    Is there any reason non-parameterized queries are enabled? Yes, probably plenty, but I'll give the easy one. :)

    The libraries and code can't really tell the difference between "select * from table1 where id < 100" and "select * from table1 where id < $variable" because the calling code is going to fill in $variable from some user input. The first form may be reasonable business logic because all non-reference values are less than 100 and user input values start at 101. The second form looks a lot like the first, but has different intent. The libraries can't determine the intent and by the time they see the SQL, the variable has been expanded and really looks the same.

    That being said, good libraries only allow 1 SQL statement per call so injection is a lot harder because "select * from table1 where id < 0 ; delete from users where 1" (injected part in bold) would be disallowed. But injection is a problem because many libraries allow that.

  8. Re:What, no thanks? by ssufficool · · Score: 3, Informative

    Vandal: I do not think that word means what you think it means. He exposed a vulnerability and reported before going public. He in no way defaced or destroyed the website or data.