And honestly, writing this post at all continues to show bad judgment. I don't think this person understands where white-hat boundaries are, or how to deal with being accused of a crime.
Please reconsider if you think doing something like this to your competitors - or anyone - without some kind of program of consent on their part (like the previously mentioned Project Zero) is a good idea.
At the very least, if you stumble across something that spits out a plaintext credit card number, stop right there and don't do another damn thing with the target. Don't see which credit card numbers you can see, don't change the `/100` in your URL to `/101`, just stop.
And please, don't tell them you'll give them the bug if they pay you or give you a t-shirt - this is blackmail, most likely (IANAL), and sure to get you in trouble. (but it happens)
Most devs outside security would just assume that unless you're doing something encryption-related or at least trying multiple passwords, you're not hacking. You're just asking nicely for information.
It is amazing how little technical knowledge you need to violate the CFAA.
Simple data extraction is hardly a outside the what a white hat hacker should do. If there's an API endpoint that returns say, `user.name`, it's reasonable to try other things like `user.email` or `user.credit-card` to see what else could be do BEFORE reporting it.
It might be totally valid to return `user.name` where `name` is simply the first name. But you'd never know unless you actually tried a few more endpoints.
I agree with a parent comment in that someone dropped the ball here and threw him under the bus to protect reputations and prevent any nastiness between the two companies.
People share a lot of really bad advice about security research. The best advice you'll get from people that don't work in the field is "stay away" and "don't try to help"; it's cynical, but at least it's not going to get you sued, like following this kind of "poking around is a white hat norm" advice will.
There are bounds to what is or should be considered reasonable testing, and if you don't press against them then they will keep moving closer and closer to the point where simply using your own computer in ways the manufacturer didn't intend will be illegal (and that is already happening as well).
According to what the author describes he did absolutely nothing wrong morally or legally, and the attitude of victim blaming prevalent in this thread is a huge problem in the security industry. We should be supporting rather than crucifying him, because one of us will surely be next for looking at a website the wrong way.
If you're trying to discuss whether something is legal in general, looking at a broad spectrum of case law is generally more instructive than focusing on the outcome of one particular case.
You could have done everything the author claims to have done in order to stop a Martian invasion or the extinction of every living thing or in the genuine spirit of trying to help and it’s still several prima facie violations of CFAA. It just is. I’m sorry. The why doesn’t matter, barring the contractual scenario tptacek points out (and which STILL requires diligence by both parties to avoid prosecution).
To be clear I think it sucks what happened to the author, but if weev goes down for enumerating primary IDs via a Web browser (and to be fair, also trying to sell the data like a complete tool), setting up an entire technical infrastructure to compromise this app in this way is trivially demonstrable intent. You and I both know what Charles does. Now wait until a prosecutor spins the whole setup as a giant technical hack that shows this person intended to compromise a competitor. I’m not even finished with law school and I’m certain I could prosecute this person successfully, but note that doesn’t mean I’m saying they should be.
Given what you said here and to your point, I’m going to preempt your likely retort and point out that I’ve described the behavior as afoul of CFAA and not the person. You’re right that they are entitled to due process. The blog post is literally evidence is all. I’d bet my Rams tickets next year there’s a subpoena on its way to this post. If not in a theoretical criminal case, then definitely in the civil litigation already underway (again, taking the author at face value).
tptacek is right, and I mean this with respect: you really need to be careful with your opinions on CFAA, particularly when potentially suggesting violation thereof. Your pronouncement that the person didn’t do anything illegal is actionable in a very distant, fucked up world with a bunch of prerequisites, but still a very very possible world. (IANAL/YL, comment is general opinion and not advice, etc)
2. You don't need to be found guilty for a court to ruin your life. If you doubt me, ask anyone who's 'won'[1] a nasty divorce.
[1] And I don't mean the lawyer.
What he's saying seems to be exactly in line with what's happening. Even if the author doesn't end up being found guilty by any court, he'll still be wasting a bunch of money on lawyers.
Hack, but hack carefully, at least until there are laws that protect you. Today, there aren't.
I don't want to sound purposefully ignorant here but is your advice basically that, if you find a vulnerability, the only way to remain a white hat hacker, assuming you were not hired to check for vulnerabilities, to not report the security flaw?
If not, please explain.
If so, I can certainly understand the perspective, but for me, I feel a sort of obligation to make people aware of serious problems. Whether it be them driving around with a headlight burned out, or their website processing credit card info in an insanely insecure manner. Each are dangerous, and can cause many problems not just for the operator, but for the people around them as well.
To me, it seems like it is ultimately at least as malicious as a grey or black hat, if a white hat were to find a basic (or serious) issue, and not try to inform the owner (or in this case, their boss) of the issue in some fashion.
Perhaps the law should look for some kind of "good sanitarian law" for these sorts of situations.
I don't know what this "white hat hacker" stuff is. There's no rule of hats in the law. I know "white hat" mostly as a term of derision, not as a technical or legal term of art.
The problem this person has run into is that they went looking for vulnerabilities in someone else's website without permission to do that. You're not allowed to do that. If you do it, a lot of times you'll run into companies that are cool about it, but a lot of times the companies you run into aren't cool about it. The law is on the side of the people who aren't cool about it.
US law right? Out of interest, not trying to make a point; I cannot read the article so I do not know.
I think the important point is: if you don't want to risk a world of legal trouble, don't look for vulnerabilities in other people's systems in the first place, unless and until you have a contract with them. At the very least, make sure they have a bug bounty program or some other public indication that they are interested in getting vulnerability reports.
Again, the most important point is that you do this before even checking for the vulnerability you think you may have found.
Sueing people doing it is a fantastic way to ensure well intentioned people will never report vulnerabilities to you any more.
The same goes for your whole post chain.
We as developers and end users have to fight it and not simply argue for the sake of following rules.
It makes zero sense to prevent people from viewing source code of a page when that is how the entire tool chain was built to be used.
They should have made their own native app that couldn't be reverse engineered if they had any mind for real engineering rather than blame 'the web'.
True, but it was not somehow 'out of order' because it was not a rebuttal of the 'whitehat' claims. Given that the article is not primarily about how the author discovered the vulnerability, but the legal problems that ensued, it was not at all unreasonable to point out that acting in accordance with 'whitehat' behaviors and intent is not enough to shield oneself from legal scrutiny. Furthermore, the ensuing discussion, in which various attempts were made to deny this distinction, shows that the point needed to be made!
Poking around to see what kind of data is exposed by a bug is reasonable.
I’d stop there, and I’d suggest people do that, because it makes for a better society for all of us, regardless of the law. What’s that called? Civil disobedience?
You open the door a little and peak inside and see the office door is open. “This can’t be,” you think as you walk into it.
You bet there’s a safe left unlocked and customer reservation left unprotected on the computer, “how irresponsible can these people be…”
If their security is this bad, you wonder what their food safety processes are.
It’s a slippery slope, and maybe well-intentioned, but that doesn’t change the fact that you’re not allowed to wander into this restaurant’s back door or be there when it’s closed, and now that you have, how do you prove you didn’t do anything malicious if the only evidence there is is of you in the restaurant when you’re not supposed to be?
Maybe you can make an appealing public good argument against criminal accusations based on your stellar clean record, but how do you protect yourself from civil suits, which they have every right to spin up if they have damages and can link you to them?
You don't walk in and rummage around their house to "investigate the severity".
The mitigating circumstance is if you have a written agreement that says, you are authorised to be there, and doing what you’re doing.
You don't stop until you fully explore just how severe the vulnerability is and all affected systems. This isn't rocket science. You have to know just how bad things are if you to have any hope of fixing them.
Not that ignorance of the law is an excuse, but when are software developers not in infosec supposed to be taught these limits?
I think publicized security research --- which I obviously support --- has created expectations among technologists that either weren't intended, or were more wishful than the facts support (lots of researchers, most probably, think the CFAA is a bad law and are happy to set expectations premised on its illegitimacy, but: see Wesley Snipes for how that turns out).
If there weren't lots of public security research, I don't think you'd really have to tell developers not to go looking for vulnerabilities.
Again, and to be clear: if it's something running on your own machine, or a machine you own, go nuts.
Releasing the exploit, on the other hand, is a different story (don't do that)
Per my understanding, there is a distinct difference between releasing a bug (that you found in software on your own machine) vs. releasing a tool that exploits that bug.
This also comes up in discussions about exploit markets: you can sell an exploit to a bounty program, or to Zerodium or whatever, but people always think you can make more (for instance, if it's some dumb SQLI, more than the $0 the public exploit markets will pay you for it) by selling "on the dark web". But if you're selling a bug that only lets you exploit some specific SAAS application "on the dark web" to some anonymous criminal (or someone a jury will think you should have known was a criminal), you're taking a chance that a prosecutor will make a case that you took money to facilitate a specific crime that they're now going to charge you with.
My example was that cracking a game is illegal, but releasing a cracker is much much worse.
And, again, IANAL.
Power relations between employers and employees, corporate goons (lawyers), lack of honest communication, lack of trust, lack of collaboration to make things better, general FUD. This all leads massive inefficiencies, people get hurt, progress is slowed down or even reverted.
OK but where, exactly, ARE "white-hat" boundaries? Is there a rule-book somewhere that he missed? How does one know how to deal with being accused of a crime? Practice? Cop-shows on TV?
IMHO this person is someone who was just too naïve, overly trusting and unlucky. If there's blame here, much of it falls on his organization for failing to handle the initial incident report seriously.
That way you create a sort of trail that a discussion took place and at least that was your understanding at the time.
Even worse if it can be proved that they received the email and read it. Because in that case if they don't reply disagreeing, you can argue that the silence was an approval of your account.
That’s why I put many Ccs and ask them to respond if they agree or not; I make sure they do. This is always never, at that time, an adversary type of thing, so people generally play ball automatically. When things go rotten then we have everything to win. This happened a few times in court.
Edit: someone mentioned using CC as well to all those involved in the "plan", that's something I do as well but didn't think about it
Hard disagree. Why is he reporting it to his own company? It's in his company's best interest for a competitor to have a security issue. He should have gone directly to the competitor's security team. Could have potentially gone anonymous. Could have gone through another person. A reputable security researcher. Lots of other things he could have done, but didn't.
Moral lesson: your employer isn't your friend. They will throw you under a bus in a blink. Always cover your a*.