Live data from Hacker News

This hacker might seem shady, but throwing him in jail is bad for everyone

washingtonpost.com

111–120 of 213 posts

Re: This hacker might seem shady, but throwing him in jail is bad for everyone

#111
post #69

Earlier quoted context omitted.

This is currently downmodded because people don't like the implication. And they shouldn't, because it quickly forces someone into either a) agreeing with the law or b) saying that SQL injections must be, ipso facto, legal. Including ones like: 1 AND ("1" = SUBSTRING(select social_security_number from employees where employee_name = 'Angela Smith', 1, 1)) You can use variations on this to... a) Ask our librarian for…

I approach this from a different angle. If someone broke into my web app by injecting SQL, I'd be mad that I allowed them to do so. If someone broke into my apartment by smashing the window with a brick, I wouldn't be mad at myself for not using thicker glass. Therefore, I see SQL injections as sloppy programming, but physical break-ins as sloppy ethics. IMHO YMMV IANAL KTHXBYE.

Where do you draw the line?

What if your site uses Wordpress or some CMS, and it has a SQL injection zero day that is then exploited to gain access? Even if you did due diligence, kept your kernel and all your software up to date, and generally secured the server and the application as best you could, you could still be entirely unaware of flaws lurking within.

It'd be more comparable to the lock on your front door being vulnerable to easy lockpicking with a paperclip and 4 seconds. You're still not "allowing them to break in" by being sloppy (it's not like you left the door unlocked), but the manufacturer of the lock was sloppy and as a result, someone is able to break in without any "brute force".

Re: This hacker might seem shady, but throwing him in jail is bad for everyone

#112
post #102
post #72

Earlier quoted context omitted.

No, it is because lying about your user-agent is not explicitly trying to make an HTTP server perform an action it is not supposed to perform and is therefore not in the same category as SQL injections. HTTP servers are not supposed to use user-agent as authentication.

It's the equivalent of going to a Chinese restaurant and asking for the "Chinese menu" rather than the "American menu" even if you can't read Chinese.

Except for that the Chinese menu wasn't written in Chinese but in English. Moreover it contained an access card to the staff lounge where the customer records were open on the table.

Re: This hacker might seem shady, but throwing him in jail is bad for everyone

#113
post #105

Earlier quoted context omitted.

It is the server's problem. A misconfigured server is not a client's problem. Set aside the SQL injection. Suppose there's a bug in Apache's path parsing such that using "\" instead of "/" causes it to interpret it as an escaped string, which somehow (bear with me) causes it to run exec("/bin/rm -r /"). Now some n00b comes along and uses "\" in the path, because he's used to paths on MSDOS; crashing the server. Whose…

Whether it's the server's or the client's fault doesn't matter that much from a legal perspective. Intent plays a big role: if you knew that ending a URL with "\" causes `rm -rf /*` to be run, and intentionally run that on a server, you could likely be prosecuted and convicted if it were proven that you did it intentionally. If it were done accidentally by a client, they would (likely, and hopefully) not be convicted…

No, Weev did not "exploit" anything. He _requested_ information from a server. If the server owner had so desired, they could have made the data private by adding a password. They chose not to. In the end, the decision to offer Weev the data was made _by the server_ .

And if you're going to bring up the UserAgent spoofing, let me remind you that most browsers have done something like that for > 15 years.

Re: This hacker might seem shady, but throwing him in jail is bad for everyone

#114
government always prefers "shoot the messenger" to actual security. There should be literally be nothing illegal about what he did in that case. he didn't "hack" anything except HIS computer to pretend to be an iPad. And that would be the point of identifying it as a security concern. After all, if he had figured it out, surely the Russians and Chinese figured it out between when he did it and they prosecuted him... it doesn't make the hole go away!!!

What he did is like sticking a GM car key into a Toyota. Generally that doesn't work, it shouldn't work... but what if it does anyway? shouldn't the company that makes the cars fix that?

Re: This hacker might seem shady, but throwing him in jail is bad for everyone

#115
post #69

Earlier quoted context omitted.

So if I ask the librarian for a copy of the book with ISBN 1; DROP TABLE books; -- is that okay because, technically, the server let my request through?

This is currently downmodded because people don't like the implication. And they shouldn't, because it quickly forces someone into either a) agreeing with the law or b) saying that SQL injections must be, ipso facto, legal. Including ones like: 1 AND ("1" = SUBSTRING(select social_security_number from employees where employee_name = 'Angela Smith', 1, 1)) You can use variations on this to... a) Ask our librarian for…

>This is currently downmodded because people don't like the implication. And they shouldn't, because it quickly forces someone into either a) agreeing with the law or b) saying that SQL injections must be, ipso facto, legal.

Not if you make a distinction between using a service and breaking a service. Analogize with entering vs. breaking and entering. In many cases it is valid to punish someone for bypassing security. But if a system has no security by design, then there is nothing to bypass. SQL injection, on the other hand, is always bypassing the design of the code, and loses any presumption of authorization.

P.S. Yes there will be edge cases. There are always edge cases. But this is not an edge case. The lack of security was definitely design, not software-bug.

Re: This hacker might seem shady, but throwing him in jail is bad for everyone

#116
post #74

Earlier quoted context omitted.

You totally nailed it. 100% right. Distilled it down to the essentials of how the internet works and the nature of a protocol as a contract. Bravo.

His whole analogy only works because the librarian is a human, and if a human with some apparent authority lets you do something, you can reasonably infer that you have permission to do it. But you can't anthropomorphize a server like that. It's not a gatekeeper, capable of granting permission, just a dumb lock which may be flawed. Only humans can consent. To repurpose his analogy, if you sneak into the staff room an…

If you're going to repurpose the analogy, do it right. The librarian is supposed to let you into x room. Someone somewhere expected you to look at one record before leaving, but you check out some other records. But at no point did you wholesale sneak past the librarian.

Re: This hacker might seem shady, but throwing him in jail is bad for everyone

#117

Earlier quoted context omitted.

If I were to threaten to murder you, you wouldn't expect the police to say "Eh, nothing we can do, he's got a right to free speech. Call us back after he shoots you, you'll have a case then." This is the problem with thought experiments regarding crime: they always make the facts 100% certain, when in real life, the facts are never 100% certain. If we were to rephrase your thought experiment, it would be: "Some guy s…

If only there were some way to determine what was meant. Barring that, maybe it's best not go around saying such things if you can't even convince one out of twelve people that you weren't serious. Regardless of whether you truly intend to carry out the threat, the threat itself is a form of violence. It imposes your will on an unwilling subject. If you rob a bank with an unloaded gun, you can't claim afterwards, "oh…

No, you missed my point. My point is that anyone can accuse anyone of a crime, so the law has to reduce the incentive for someone to make something up to get attention or revenge. "He said he would kill me," is nearly impossible to prove, so if you punish it severely, you create a cure that's worse than the disease. If you restrict it to certified letters, though, then you have a better balance.

Re: This hacker might seem shady, but throwing him in jail is bad for everyone

#118
It is annoying when people throw analogies around describe it to a highly technical audience. When is hacker news going to discuss the fact that User-Agent in the http header is not a security feature? When is the discussion that sequential id is equivalent to no security?

No analogy in the world is going to change the fact that User-Agent checking and sequential id:s are not security features. And if courts are allowed to make them security features it is bad news for everyones security.

Re: This hacker might seem shady, but throwing him in jail is bad for everyone

#119
post #56

Here is my analogy: 1. You just finished your workout and went to a locker room at your gym (he went to a public website) 2. You opened up your own locker and took your stuff from it (checked his account) 3. You found out that very few people are using locks in the gym locker room (figured the account id in url ) 4. You know that it is not your belongings in other people lockers, but they are not locked just because…

I reject that analogy pretty hard. Account ID is basically locker number. It's not a password/lock.

Re: This hacker might seem shady, but throwing him in jail is bad for everyone

#120
post #69

Earlier quoted context omitted.

This is currently downmodded because people don't like the implication. And they shouldn't, because it quickly forces someone into either a) agreeing with the law or b) saying that SQL injections must be, ipso facto, legal. Including ones like: 1 AND ("1" = SUBSTRING(select social_security_number from employees where employee_name = 'Angela Smith', 1, 1)) You can use variations on this to... a) Ask our librarian for…

I approach this from a different angle. If someone broke into my web app by injecting SQL, I'd be mad that I allowed them to do so. If someone broke into my apartment by smashing the window with a brick, I wouldn't be mad at myself for not using thicker glass. Therefore, I see SQL injections as sloppy programming, but physical break-ins as sloppy ethics. IMHO YMMV IANAL KTHXBYE.

And I imagine the line you draw for where it's "sloppy programming" vs a legitimate break-in coincides exactly with your knowledge and skill level...
Post reply on HN