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.
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."
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.
Keep in mind, what we are actually talking about is a tax payer funded website that is open to the public (and the entire world). How you make the leap from that to breaking into a private home seems to just be a straw man argument.
If you are a known election official with obligations to the voters, then you should expect to be held accountable if you are violating basic best practices.
So, back to your private home break-in metaphor, if the election official is bringing confidential information home, putting it in their trash and then leaving it in an unlocked trash bin at the public street curb, it should be open to public review. The fact the trash bin is in front of a private home should not ever be a valid excuse to betray the public trust in failing to meet the obligation to correctly handle confidential data.
I really don't care if your straw man argument dictates that such a review of the trash is a so-called "break-in" instead of an audit. The election officials still failed to meet their obligations to follow computer security best practices.
So, he went to a system that was intended for public access (similar to a public street curb) and issued a SQL injection which copied the data into a temporary memory buffer for storage and when the buffer was delivered, it was emptied for future use (similar to a trash bin). None of this involved breaking into a privately owned home or anything close to it.
Election officials should be shielded by the law for their failures. Best practices shouldn't be something you might "try" to do to meet obligations to the voters. Failing to meet those obligations very much should be an excuse for a security audit.
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.
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.
From the youtube link: "This video was NOT released until AFTER the Lee County SoE staff CONFIRMED they had fixed the holes and the information was not compromised. The holes were fixed on 1/25/2016 prior to the uploading and airing of this video. "