Hacker News Reader

Comment by kortex | Hacker News Reader

Eh, I agree it was kind of a dumb move, but there's no reason he shouldn't be able to have a snoop around. This wasn't "hacking" in the exploit sense. Web scraping, poking and prodding at APIs (yes even "private" ones), indexing a user ID, looking at source code, injecting your own code (e.g. modifying client js), redirecting some requests, none of these are hacking or exploitation, they are literally how the technologies of TCP/IP, HTTP, the web, and web browsers are meant to work.

I'm not sure where the line of "trying to break security" it, but none of the above count. Even accidentally blasting some endpoint with automated garbage. Intent matters.

View on HN

There is a reason he shouldn't be able to have a snoop around: it's a violation of federal law. Don't test other people's websites without permission (and even then, be careful).

I worry that people read a lot about vulnerability research conducted on iPhones or Chrome or whatever and assume that it's open season on any kind of application, but the rules for apps running on other people's servers are very different.

Ah, the ol' "press F12 and you're a criminal" argument.

> the rules for apps running on other people's servers are very different

Did the "hacker" ever have access to other people's servers? Or did he merely observe what his own computer was doing and then make some web requests?

I don't understand what you're trying to say here. An argument that your browser is just doing what it's supposed to do when it triggers e.g. a SQL injection on some server somewhere is, I promise you, not going to help you if the government decides to prosecute you.

You're mistaking the easy for the legal. It can definitely be illegal for someone to "observe what his own computer was doing and then make some web requests".

If "observing what your computer was doing and making <internet> requests" was always legal, then there would be no such thing as illegal hacking, because that covers essentially all possible activities one can do with a computer. There may be some who would prefer that world, but it is obviously not the one we live in.

By your logic, someone that successfully guesses a weak password and ssh's into someone else's server and takes all of the data they can find there is doing nothing wrong, as they are "merely observing what their own computer was doing and making some TCP requests".

Obviously, this is not how the law sees it.

I don't think anyone here is disputing the fact that in the eyes of the law, his actions were illegal. But as someone who develops web scrapers/automation for a living, I poke and prod APIs in much the same manner as this guy. I don't feel such exploration should be criminalized. Sadly, it is.

In your SSH scenario, its completely different- you're literally acting with the intent of accessing someone else's computer to exfiltrate sensitive data. That's not what happened here (according to the author).

Running a crawler and poking around API artifacts manually simply aren't the same thing under the law, even though on the wire what's happening is the same. As long as your crawler isn't programmed to go looking for SQL injection vulnerabilities or whatever, there's no case to be made that you had any intent to gain unauthorized access. That's what matters here: your intent.

If the "hacker" hacked his web browser, this wouldn't be an issue. They didn't. They attacked an application running on a server somewhere that was not their own machine, from a web browser running on their machine. The former is the important part in the eyes of the law, and the latter is irrelevant.

Well... his man-in-the-middle was a false attestation of identity to gain unauthorized access. That is pretty much the definition of hacking. The app would have otherwise encrypted the traffic and they wouldn't have been able to 'poke around'.

That doesn't sound like they were using SSL for authorization. SSL (in the usual use case) just ensures the client to server connection. You can e.g. use special installed certs for accessing VPNs, but I don't think that's the situation here. It just seems like the client was expecting some domain name to serve some endpoints, and he just MITM them to proxy it to his own servers. That's not hacking because here SSL isn't being used for authorization.

The bottom line is the resource permissions weren't scoped right, like at all, and no amount of SSL is gonna fix it - that's what logins and tokens and oauth and that whole dance are for.

Sorry, endpoints aren't doors of a house, where "waltzing in just because it's unlocked is breaking and entering." They are protocols. Merely "talking" to open protocols is/should not be a crime.

Whether or not you think it should be a crime has absolutely nothing to do with whether it is. In this case, you're pretty much dead wrong. There's no "this is how the open protocol" works exception to CFAA. A case will turn on your intent, and the standard to which you'll be held is "what a normal person on a jury would think to do with their browser", not "what people on HN think is reasonable to do with a browser".

Incidentally, cases of breaking and entering often turn on your intent as well; that's the whole concept of mens rea.

Right. Lets say you live in a cookie cutter apartment complex. You go to door 22 instead of 23, and because the landlord uses cheap locks, you are able to get in with your key and a bit of jiggling. You make it as far as the kitchen table with a very surprised family before you realize it's not your apartment. Not BnE.

The CFAA uses "intent" and "defraud" quite a few times. That's not gonna stop some DA from trying to throw it at you, and your life is gonna suck, but state of mind is going to be the most important factor. The disclosure shows you weren't in it to defraud. Obligatory IANAL.

The whole reason CFAA got passed in the first place was that Congress was concerned about crimes involving computers that weren't fraud, and thus weren't chargeable under wire fraud statutes. "Fraud" isn't the threshold act of a CFAA case; unauthorized access is.

I don't think it's pedantic to say it's not "what a normal person on a jury would think to do with their browser".

It is "what a person on a jury would think is legal to do with a browser".

Otherwise any niche activity would be de facto illegal.

No, you're not following the argument. The elements of a 18 USC 1030 charge have to include unauthorized access along with an intent or knowledge that the access was unauthorized. Just doing something silly like changing the colors in your own browser, a niche activity, can't get you charged --- there's no colorable argument that your access was unauthorized. Looking at other peoples' credit card numbers is a much easier case to make, and then the question becomes "did this happen totally accidentally, could I myself as a juror have found myself in this situation?".

I almost completely agree with this comment so I won't nitpick, I just don't think the statement I commented on earlier was a fair simplification on what's the jury's job.

>That doesn't sound like they were using SSL for authorization.

Not for authorization. As explained in the article, the man-in-the-middle attack was successful because the app didn't use SSL pinning. This allowed for them to decrypt the traffic between the app and the server; they could then view the API calls and get an understanding of how it worked. The traffic would have otherwise been encrypted.

It was a false attestation of identity to his own device. Surely you can't be accused of hacking your own phone?

It wasn't the device that was under attack but the communications between the app and server. Sure, there is an idea that everything your phone does ought to be known by its owner but that isn't how the phone or law is set up and the attacker had to find a security vulnerability to gain access.

I don't believe your assertion about how "the law is set up" is correct, if you mean to imply that altering the operation of code running on your device is proscribed.

Where it falls foul of the law is when you start sending requests/commands to other people's servers in excess of your authorisation.

>there's no reason he shouldn't be able to have a snoop around

Copyright, anti-trust, patent, civil and criminal liability beg to differ. It's just a bad idea to snoop around the technical implementation of your competitor's product. Nobody should do it without the explicit prior permission of their employer.

Reply on news.ycombinator.com