I remember reading about this case around the time the charges were originally filed and those are pretty much the charges. The guy ran nmap (or equivalent) on the website, and submitted some attempts at SQL injections in a few forms. That was pretty much the entirety of his "hacking". Honestly what he got on the plea bargain is at the far end of what I'd consider appropriate for what he did. Something like a small fine, say $500 and a "don't do that again" would probably be more appropriate honestly. Had he actually gotten somewhere with the SQL injection, or actually gained access to something I'd say more might be warrented.
FYI the 44 counts were arrived at by charging each form submission individually, so it was really just 1 charge, just counted 44 times.
I don't see any reason why attempting SQL injections on a few forms on the County website should be treated any differently than trying a few ways to pick the lock on a county building. Should the punishment for the latter depend on the sophistication of the lock-picking techniques the intruder uses?
Web servers are other peoples' property, and there's no "right to tinker" with them. All you have is an implied license to use the site in the way the owner expects you to use it, the same as with a physical storefront.
Yes but there are degrees with these things. If you attempt to open a locked door they don't charge you with armed robbery, even if that door has a sign that says "employee's only". I'm not suggesting attempting a SQL injection should just be ignored, but it should clearly be at worst a misdemeanor and not a felony, about on par with trespassing in terms of severity. Now, if you then use that SQL injection to steal protected data, gain further access, or delete data, then yeah you're talking about moving into felony territory.
Web servers are other peoples property, but they're also a public space when you open then up to the public by hosting public services on them. A private server is different from a public server in the same way private property is different from a public storefront. By making your server accessible to the public you lose some of the expectations of privacy and implicitly allow a certain degree of access.
Would you mind explaining which charges you'd get hit with? As a non-laywer, trespassing and entering (not breaking and entering, since you didn't break anything) are the only charges that would make sense to me in that context.
I agree, but I do see one distinction that I find interesting: if someone tries to pick a lock on a county building and they try 44 different lock picks, is that one charge or 44?
Even once is a serious charge, but I'm not sure there were 44 crimes committed.
A better analogy than lock-picking: the door has a sign that says "turn knob to the right to enter", he was arrested for unsuccessfully turning the knob to the left to see if it would opened into another room.
There is an interesting disconnect in the "HN perspective" in that online data is incredibly important and should be subject to all sorts of legal protections from the government (even if it's shard in plain text with all sorts of 3rd parties) but at the same time it should be completely OK for an individual to try to steal it just for fun.
The 44 counts thing is kind of ludicrous unless he literally made 44 separate attempts at SQL injection at different times rather than 44 separate HTTP requests. Having said that, I think the punishment for "attempted hacking" should be fairly harsh in the way "attempted robbery" is. He was likely attempting to steal copies of information or perhaps even destroy information that could've cost thousands or perhaps even millions to recover depending on who he'd gone after.
The problem is that "attempted hacking" is kind of a fuzzy thing. To go with your example is it "attempted robbery" if they catch you on camera scoping out the bank exits and camera angles? At what point does something go from looking around to "attempted hacking". He didn't actually succeed in anything he tried, so basically what they have him for is running a port map which shouldn't ever be illegal, and sending some garbage form data.
Because this is the law here and they'll always apply it as broadly and wrongly as they possibly can you have to consider the extremes on this. At what point do you draw the line? To go with the hypothetical worst case scenario, what if little bobby tables goes to sign up for a account somewhere, does he get charged with "attempted hacking"? This also puts grey and white hat hackers in a dangerous place as well (particularly grey hats which are already on shaky ground as is).
Someone didn't just get bored and fill a form field with random garbage. We're talking about attempting a SQL injection attack which shows clear intent.
>Someone didn't just get bored and fill a form field with random garbage.
Yes they do.
>clear intent
Intent of what, exactly? Intent to make the site do something it wasn't explicitly designed to do, yes, but that does not imply exceeding authorized bounds or causing any harm.
I'm not saying that people never put random garbage in a form field. We're talking about a specific incident where a person apparently made at least 44 requests attempting to perform SQL injection. The intent of unauthorized access or destruction of information. When you get caught trying to pick the lock at your bank you can argue you weren't trying to exceed authorized bounds or cause harm all you want but I doubt it will get you very far.
While I may have disagreed with you, I felt your original position was a reasonable one. Now you're attacking the straw man of someone being brought up on charges for an apostrophe in a form field. When that happens I'll gladly join you in declaring the ludicrousness of those charges.
And that's why we have DAs, grand juries, judges, and juries. If someone gets brought up on charges for literally putting an apostrophe in a form field on a website the system has failed because there's no clear intent to perform an attack of any kind in that case. When that happens, let's talk.
By checking all the locks, and not just a handful of them?
I don't think it's enough to show he was thorough to establish there is actual mens rea for a crime to have been committed.
I bet that site had at least 44 separate form inputs. No sense checking just a handful of them. None of the third-party certifications you suggest looking for to assess a vendor's worthiness are even roughly analogous to a bank with, for example, FDIC insurance.
If I have never undergone the certification processes myself (or perhaps even if I have, more so) they are the information-security equivalent of "tiger repellent" to me. I can only take the word of "experts" that they are good.
If I can't tug on all the exposed levers, then I guess at least I can be assured only people who are paid to do that (or people who are breaking the law) have actually tugged on them.
Can you understand how this kind of assurance would not reasonably instill any confidence of a system's security? The law does not forbid one from looking over one's own shoulder, so why should it be any more criminal to do that at every single corner you passed, even in an airport?
There is a reason info-sec experts are sometimes seen as paranoid, it's because you don't know if you don't check.
The remark about there being 44 instances was in direct reference to the idea that it could have just been random stuff put into form fields. I've already stated I think that being brought up on 44 counts is abuse and shouldn't have stood up in court. However, even if it's just 44 form fields that's far more than enough to show intent to perform SQL injection and not just an oopsie bad copy/paste or errant form entry. It seems clear that he was attempting to gain unauthorized access to information. What he intended to do with that information is irrelevant.
While 3rd party certifications might not hold the vigor of FDIC insurance you are unlikely to put information on a website that is as valuable or irreplaceable as what you put into a safe deposit box. Most of time we're talking about a name, address, and potentially credit card information as the maximum damage possible. Well, your name and address are almost certainly already public record. Your credit card similarly has excellent protection and aside from some incredibly rare nightmares most people who have their CC info stolen are back to normal within a few days of calendar time and less than an hour of time actually spent dealing with the issue. If you're putting something more valuable on the website you're perfectly within reason to contact the vendor and request permission to perform a security analysis or have your own trusted security analysis vendor perform such tests. This happens all the time in business.
You can feel assured that only people who are paid to tug on the levers or people who are breaking the law are the only people tugging the levers at every company you conduct business with.
And the literal "tuggin on the lever" analogy is really poor. A closer analogy would be, "I know many locks are vulnerable to being opened with a specially crafted bump key. I will walk around the building after hours and attempt to use a bump key on all the doors to ensure it's safe to conduct business here."
The "after hours" part doesn't help draw any real parallels either and only clouds things further. When is "after hours" for a website? All access is logged, at any time of day.
We are going to have to agree to disagree. You seem to think that performing SQL injection, even just to see if it is possible and with no intent to steal information or in furtherance of any crime, should be criminally prosecuted.
I think that SQL injection is such a basic attack that they should teach everyone how to perform it in introductory CS courses or earlier, as only through awareness of these basic forms can we all stamp out the threat of our own global systemic ignorance of those kind of forms.
It's not a kind of magic. Nobody is born with the knowledge that "SELECT * FROM Table WHERE #{userdata}" is completely and perfectly wrong approach to taking input from users in any production system. You have to learn it somehow, and the law practically forbids you from learning it through application in the wild. So I suppose only criminals will get to have guns, then.
> You can feel assured that only people who are paid to tug on the levers or people who are breaking the law are the only people tugging the levers at every company you conduct business with.
I understood that already, and it didn't make me feel warm and fuzzy. I don't really think there's a ghost's chance that I'm in the majority here, either, and I do find that to be a shame. Even many otherwise smart people are just totally ignorant of computers.
The word "SQL injection attack" has the word "attack" right there in the name. It's not innocuous. And there are plenty of places you can go where you're permitted to perform the types of analysis you're talking about without repercussions. If you want to be a locksmith you don't wander your neighborhood randomly attempting to break into houses as part of your training.
Yes, it's called an attack, and defenses are a thing too. You can't learn to block if all comers are expressly forbidden from punching or feigning punching. This need not be a violent attack, it will not incorporate any weapons, and there is furthermore no concept of assault and battery against computer equipment. One should avoid any destruction of property when wearing the white hat. They are not "unauthorized" accesses, however. The supposed authorization controls have failed and the doors are really unlocked if the attack succeeds.
Which situation is preferable:
a) As a new business, I am contacted by a good Samaritan who informs me that my public website is vulnerable to a common attack. I take this information to my development staff and they verify that we are indeed vulnerable, then we fix it. Millions are saved. I send a thank-you note to my new friend in Samaria and maybe even write a check.
b) Good Samaritans are prevented from helping by laws that divide adept lever pullers into only two groups: the paid kind and the unauthorized kind. There are then never good Samaritans because every Samaritan needs to take steps to remain anonymous themselves before performing any deeds which could constitute "an attempt to obtain unintendedly authorized access".
It's clear that "The only reason to obscure the origin of a packet is in order to not be the one caught sending it." Anyone who does not want to get caught doing whatever they are doing, I think it follows obviously, can't possibly be helping but only up to no good. Now all Samaritans with knowledge of SQL injection are at odds with web service companies and all good and rational Samaritans do the smart thing and cease all helping. If anyone helps, they will do so anonymously; if they are identified, they will have to swear they only found the issue by accident and didn't even really know what to look for.
In (B), your ability to secure yourself is directly at odds with the amount of spare time those (real) hordes of bad Samaritans or other nationalities behind seven proxies can spare. Got unlimited money? If you can't pay for enough pen testing, well I hope you did security right because nobody is going to help you now. Is that really the preferable scenario?
We have varying degrees of laws protecting certain kinds of "Good Samaritans" in cases of medical emergency, they are on the books in every state. Unless or until it's an issue of something wrong on a computer. There is no such similar protection for any security pros or curious tinkerers.
People who legitimately stumbled onto vulnerable services are best advised to never report them to anyone and forget whatever issue they saw, or they are persecuted by the FBI and prosecuted through CFAA and other legal channels. This cannot be considered optimal!
Or (to present an alternative explanation for why one might try to see what ports are open and whether some rudimentary attacks can succeed) maybe he was trying to evaluate a potential vendor and decide whether or not to put his secure personal or company information into the system.
You know, rudimentary attacks that should not succeed on any type of vendor system that has been through the most basic security audit or pen testing?
I guess we should either trust the vendor or don't. No real reason why would anyone want to see if other hackers with basic knowledge can get access to a system? I'm sure there are plenty vendors with transparent public records of the authorized penetration tests that they have ordered which have been done, you can trust!
There are a number of passive things you can do to gain some trust in an online vendor. You can, for example, look for certifications from a service like SiteLock. To maintain the brick and mortar analogy, you wouldn't try to pick the locks of a storefront after hours just to determine whether or not you should do business with them. And if you get caught doing that, I dare say you deserve to be charged with a crime.
Sending packets with strings which are commonly known to cause serious problems if systems are vulnerable to well-known exploits should not be a crime. If your system solicits users to input their private data and is vulnerable to easy attack vectors or common exploits like basic SQL injection, you are the one who should be charged.
So, the only problem left is how to establish your standing to sue the lazy vendor. It is a problem since you can't actually bring them up on negligence charges if you were not actually damaged.
Well, if picking the lock is thus illegal per your analogy, then the only way to have standing would be to first submit yourself to potential unknown harm and wait for the day when a bad hacker comes!
I think your analogy falls down too, because a brick-and-mortar storefront holds its own assets and is liable (or insured) for their own losses in the event of theft. You rarely store your own private things inside a brick and mortar storefront. If you did and they are stolen, the store would normally be liable and reimburse you.
People store their private data "in the cloud" all the time, but because of arcana in law which does not correctly distinguish between pulling on the handle and picking the lock, they are not allowed to check and see if the cloud-monger actually locks the door when he goes home at night?
There are ways to determine if a site is secure without attempting to gain unauthorized entry. You can look for third party certifications, a valid SSL certificate, etc. This is similar to the analogy of looking around at your bank to see they have a security person, locks, cameras, etc. protecting your safe deposit box. You don't go try to break into the bank to determine if it's reasonable to put your assets in the box there.
That's an absurd analogy. A more apt analogy would be to check if the bank had bothered to lock it's back door, while waving at the security cameras.
Prevent this kind of scan makes all of us less safe, since it encourages negligent behavior like taking risks with data that's not yours. Frankly, I think website owners should be held liable for security vulnerabilities.
This kind of culture of systematically undermining a secure internet only serves those who abuse our trust. Do you honestly think the FBI has a chance in hell of actually catching more than a minute fraction of all malicious hackers? Not to mention the fact that their motives here and elsewhere are rather questionable - if anything, they're less benign than the hackers they're chasing, seeing as they're essentially untouchable for whatever damage they cause.
No, not really. It's the wild west. SSL certs don't do anything to prevent SQL injection. That's done at the application layer, not the transport layer. You seem to be out of your depth.
This is equivalent to "checking to see if the door is unlocked when it should be locked" not "trying to pick the lock after hours"
I'm not out of my depth, this is what I do for a living. Verifying that a site is using valid SSL is one of the myriad of tools at your disposal to make sure a site is taking reasonable safety precautions with your data. That, accompanied by a third party trusted certification that indicates some basic penetration testing has been performed is reasonable protection for almost any data you'd be putting on the internet.
If you think that verifying that a site is using valid SSL is a tool to make sure that a site is taking reasonable safety precautions with your data, you most definitely are entirely out of your depth.
As to trusted certification - please elaborate; because many of these "certifications" are entirely worthless (some indeed indicate that a site is less likely to be safe).
Yeah, it's like driving by a house and seeing a sign on the lawn "This house is protected by Brinks" and from that concluding that none of the doors or windows have been accidentally unlocked.
It does show some kind of theoretical preference for security but it by no means assures one -- nevermind making any kind of a guarantee -- that said preference has been successfully translated into reality.
I would suspect that the rate windows or doors left accidentally unlocked between houses with security systems and without isn't a substantial enough difference to be meaningful. Sure the right might drop in half, but if it's from 4% to 2% that doesn't do much.
Having an SSL certificate is really the bare minimum that someone can do to have even a hope of a prayer of keeping data safe. There are about a dozen steps beyond that which must be taken. Worse, the effects are not additive, but multiplicative. If any one particular defense is handled improperly the properly handled other portions lend little/no assistance.
Naively one might assume that the total security score might be tabulated this way:
FYI the 44 counts were arrived at by charging each form submission individually, so it was really just 1 charge, just counted 44 times.