I found a security issue on a competitor, got fired and served a summons
accidhacker.wordpress.com
accidhacker.wordpress.com
Someone else later discovered the same issue with OtherCo and stole a bunch more card numbers, and used them to commit fraud.
OtherCo looked through their logs, saw the initial exploration coming from this guy at CorpCo, assumed he was also responsible for the subsequent fraud, and contacted CorpCo which ultimately fired him. The fraud was substantial enough for OtherCo to convince authorities to pursue criminal charges.
It's a sad story - but it's not unreasonable behavior from all involved.
Isn't it? I understand OtherCo uses legal means to investigate more effectively, a judge might order ISP logs to be turned over or so, but CorpCo knows this person, knows they disclosed what they saw from the start. It sounds pretty unreasonable to fire someone over hearsay, especially when it's unlikely to be true (what dumbass does card fraud and tells their employer—a bank—and requests they disclose it to OtherCo?).
And even from OtherCo, they're acting like it's the 70s and they've never heard of responsible disclosure. I understand their logic a bit more for the aforementioned reason, but still, reasonable is not the first word that came to mind.
it's not proof of guilt but a reasonable trail to follow up on
Always reminds me of a CSI (original series) interview with the actor who played Grissom; the writers contacted the police and forensics labs for story ideas but the real life events were so insane that they would feel too fabricated for television.
People are generally greedy and often dumb; maybe they found an open house door, put a little note in the mailbox, slept on it and thought maybe they could get away with a further peek inside if no one closed the door yet (which makes the perpetrator think they didn’t read the note yet)?
What's disappointing is that his company didn't stand by him during the investigation, especially since he reported it.
Very unfair from employees perspective, but 'self interest rational' from the Corp.
If it's perceived that the employee 'went to far' in their 'discovery' of the competitive API, and that could possibly constitute a crime, then it's basically a 'no brainer', they're going to have to let him go.
Since the staffer did actually report it right away, hopefully he will have his own political cover, and can communicate that to future employers, who should 'get it' - though some won't.
It's unfair but these things happen when an incident blows up into something where the stakes are much higher. 'Fairness' at the microlevel goes out the door towards ostensibly bigger objectives.
Get protected status as a whistleblower.
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*.
Back before crime it was ok to explore all over town and on private property. When the kidnappings and burglaries started, all that changed. And I’m so very sorry about this because the old days were truly magical.
(I'm not a lawyer, but for obvious career reasons I nerd way the hell out on CFAA stuff).
Yeah, this supports that:
https://gizmodo.com/exclusive-at-t-hackers-last-bid-to-stay-...
It's one thing if it's a designated, well-vetted free for all, like Project Zero, with clear legal approval. It's another thing for a regular employee to be hacking competitors -- that begins to look like industrial espionage. And even GPZ doesn't hack banks.
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.
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.
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.
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.
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.
Where it falls foul of the law is when you start sending requests/commands to other people's servers in excess of your authorisation.
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.
> 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?
Obviously, this is not how the law sees it.
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).
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.
Maybe doing approved bug-bounty research in a competitors webapp is a safer proposition.
You’re not paid as a competitive intelligence analyst and security researcher, regardless of your “personal interests,” you’re paid to work on a product to make the company more money.
Furthermore, if you start unpacking the mobile app of a bank and doing actual pen testing analysis in the wild hitting their prod servers, even accidentally, you seriously need to understand the situation you are putting yourself in, regardless of where you work.
Forget CC fraud. This opens up liability for IP theft. Even if the other company doesn’t win the case it is going to create a shitstorm that might potentially give them free PR. “Look our new product is so good their devs are reverse engineering our innovation to copy us”
Forget what this person found out. Going and unpacking the app and using private APIs itself was a dumb move regardless of what happened after. People can be idealistic and talk about intent but it really is a bad move that opens all kinds of liabilities.
I think the moral of the story is don't do non-work related things on your work computer. It shifts the liability from the individual to the company.
To quote Tom Scott, a youtuber, "I'm not telling you how it should be, I'm just telling you how it is."
In my old company we were told to perform competitor analysis only through publicly available information - blogs, marketing announcements, videos, ads, etc. No creating a free account to poke around. I often wondered what happened in the past to have this rule.
At the present time the legal system is not involved beyond anything other than the terms of employment in the employee's contract.
Just because a company may have the right to fire a person at will does not prove that the employee did anything wrong. (morally or legally)
That sounds pretty damn incriminating, not sure how the OP thought he could get away with it. The article is not available anymore but at first I had thought that he might have poked around with the help of Chrome inspect tools on their competitors' web app, saw a call or two being made to their backend API and then randomly changed the ID in the query being made or something like that and see what the response would be. But unpacking the mobile app to see what API backend calls are being made is on a whole another level.
To be fair, nowadays I would not even choose to do the first thing, i.e. playing around with making backend API calls based on what I can see through Chrome inspect tools, I've read about too many cases of people getting in legal trouble about it to now know better. I might have done it 5 or 7 years ago, but definitely not now.
Now, if you do it and no one finds out, that's one thing. But telling your manager (worse case, in an email!) becomes a potential liability, as the company has to keep such records and provide them to the other party in case of a suit.
Where do you work? Just so I know where not to apply.
I just checked with my employer. To make sure I represented the situation accurately, here is what I wrote (I applied the situation to our line of business, IT security, and replaced credit cards with another type of authorization token to make it realistic for us):
> if <name of actual competitor> releases a hosted password manager, where you store all your secrets on their servers, would <our company name> condone me looking at the internals of that application in private time, or does <our name> rather think that's a liability risk?
The answer started with, and I quote: "not a problem". My employer did request advance warning (they expected me to actually have such plans it seems; I clarified afterwards this was completely hypothetical for a HN comment) such that, in case it's controversial, they can warn the competitor ahead of time and say it's just my private opinion, but that's just a request and sounds reasonable to me.
Additionally when you download and use any app, there’s probably somewhere in the TOS about not trying to reverse engineer anything. You’re probably breaking that at minimum.
That right there is where the company lawyers get called, and all of your contributions to the company code base start being reviewed and ways to remove the most recent ones start being contemplated. It is extremely easy to run afoul of copyright if your employees go around reading your competitor's source code. You may well have a dedicated team that does this, but you'll be keeping a very clear paper trail proving they never came anywhere close to your code base directly.
No. A million times no. You do not use double standards. It kills morale, because it's immoral. Anyway, a top performer, should know when to walk away and contact security and legal.
If I found this. I would immediately have contacted my manager, and our security team, and see if our security would advise legal. Then we'd immediately contact OtherCo's security team.
If you find a security flaw, you have to immediately report. You DO NOT "explore" someone else's machine. It goes sideways too easily, and people always want to get the cops involved. Your number one duty is to protect yourself.
Which may involve not informing your own manager or security team, depending on context?
I wonder if he would have been caught if he hadn’t told his own company?
If they guy hadn’t reported it to his company nobody would have know he was the once exploring their API and he’d be home free.
Saying the rules don't apply to certain individuals will destroy your team.
There are plenty of policies that will get you immediately fired at many companies. Inappropriate data access is always one.
And let me tell you from experience, EVERYONE is replaceable. Just do what you'd do if he left, or dropped dead. If you can't handle those contingencies, you have something deeply wrong with the organization of your team.
From what I've seen, exceptions can always be made and people will often put up with it, depending on the circumstances. Look at the number of people in here who don't believe what the OP did should be a crime, and don't consider his actions immoral. You're telling me those people wouldn't accept a little rule-bending if they were on the team? I can't agree.
Of course some people will accept rule breaking. There’s always people that will justify it post hoc. There are also others that won’t. The real problem is you’ve now created a culture of rule breaking. Soon everyone will be violating policies as a matter of due course.
This is exactly how you get lawsuits and criminal complaints. If you’re lucky, you just have a toxic culture that hurts recruiting and retention. People here always complain about “politics”, but that’s exactly what this is.
If you need examples of where exceptions came back to bite people and companies in the ass, it’s everywhere. Theranos, Uber, Zenefits, Google, the list goes on and on. Even so, I fully expect advocates for capricious enforcement (ie protecting their friends) will further justify it by saying something about how the fines and settlements were “good business decisions” or something, because self justification knows no bottom.
I'm not saying that rampant rule breaking should be encouraged, but I don't see the slippery slope that you do.
I've always found zero-tolarance policies to be rather unfair.
If you're going to go hack on a company, make sure you have some legal protection first. Check disclose.io or the company's website (look for a security.txt!) to make sure there's some sort of safe harbor provision, or a pre-existing vulnerability disclosure program or bug bounty program that allows you to do this kind of testing.
If you're not going to do that, then disclose the vulnerability anonymously and cover your ass while you're testing, or just don't.
Meanwhile if you're an American please write your local representative and express your displeasure with the antiquated, overly-simplistic CFAA and ask them to support initiatives to have it replaced or removed.
> If you're not going to do that, then disclose the vulnerability anonymously and cover your ass while you're testing, or just don't.
No. Just don’t. Know that video about not talking to the police because they interrogate people all day long and you’re an amateur in a pro fight? Same thing with infosec. We attribute IOCs to noobs all day long.
You don’t need a criminal record. It’ll ruin many parts of your life. I have friends who can confirm that the record they got in their late teens or early 20s closed many doors. Join a formal bug bounty platform and find legitimate work there.
There's some pretty concerted efforts in play to at least have it updated and tempered, which could have legs. I don't hold much hope it'll go away but I do think some of these efforts to have it replaced could have legs.
> No. Just don’t.
Yeah, fair, I mean I'm all too aware of the consequences myself, but within this setting telling a bunch of people "thou shalt not" seems almost more harmful (IMO it's akin to saying "never roll your own crypto" which someone inevitably ends up taking as a challenge)
I hate the CFAA, to be clear; it's just definitely still the law.
Espionage would include things like illegally surveilling the competitor's networks, bribing their employees for information and credentials, using malware to create backdoors, social engineering, blackmail, poaching their talent and incentivizing unethical disclosure of trade secrets, and cracking systems that explicitly bar access.
Reverse engineering their product through public IPs is legally acceptable up to CFAA boundaries, which are fuzzy, and it's not clear what kind of exploits were involved in this situation. They may have been relatively benign reverse engineering, or they may have been something associated with civil and criminal penalties.
There is a lot of authoritative writing about the legality of reverse engineering (long story short: reverse engineering is mostly fine, legally) --- but that writing covers reverse engineering stuff running on your own computer. It categorically does not extend to reverse engineering software running on other people's computers without their permission. You'd easily get into a bunch of trouble assuming otherwise.
A lot of terrifying stuff on this thread! It's good this person already has a lawyer.
I also don't see game-modders or game cheaters regularly going to prison even though gaming is an enormous industry.
So clearly there is some tolerance as connectivity being ubiquitous blurs the line a bit though. An app I reverse engineer on my device, may as a side-effect make some communications with a third party asset, though primarily it is all my stuff. The same applies to a cars and other items, surely.
That being said financial account creation is definitely NOT the place to take risks. Same with government systems. Pretty quick many other laws and regulations ij the book come into play. They can be very broad too.
You releasing a competing product after having personally worked on reverse engineering someone's product is a lot murkier, and easily opens you up to copyright lawsuits, which you'll have a hard time fighting if you do happen to have similar code, since in copyright it matters not just if the code was similar, but also whether it's likely that you actually copied it (unlike patent law).
This can and has been done, but normally you want a very clear firewall between the reverse engineering team and the dev team, with lots of paperwork proving that no-one on the dev team ever saw a line of code from the reverse engineering team - they were only told concepts and ideas, which are not copyrightable. This is how the first free Unix was created, for example.
I think part of the problem is that fixing a security issue is expensive and usually involves company management that has very little experience with code development so they think the person that reported the issue is a black hat hacker. It also makes life difficult for everyone involved.
A solution is to have a neutral in-between organization that can better understand how to deal with the problem without having to blame the person that reported it.
You don't have authorization, you're working for a competitor, that business decided to throw you to the wolves because its easy for everyone involved to forget you ever said anything since you didn't leave any paper trail.
If I find you sneaking around in my backyard having managed to open a ground floor window I'm going to probably lose my shit and call the cops, and not thank you for discovering a security flaw.
You need to get permission for this kind of shit, and not go around jiggling other people's locks.
And the level of effort here seems fairly high and a lot more than just "view source".
The author probably deserves to lose the ability to be employed at a bank because this was some pretty bad judgment.
Finding and disclosing a security flaw isn’t even needed for this to be a problem. You’re immediately a liability to your company. You’re breaking TOS or whatever agreement the competitor app install or usage has. You’re opening up your employer to an espionage or IP theft lawsuit.
There are many easy ways to do compete analysis that don’t involve these liabilities.
Yes, you do. Authorization and Authentication are part of the API. If you want to keep a server private, don't give it a public IP and DNS!
A business can be sitting unoccupied with its doors flung wide open, and that is still tresspassing if you enter without authorization.
"You were too dumb to stop me, so its my right to rifle through your shit" is a nerd law that doesn't exist in the real world.
Don't do this kind of jiggling of door handles without authorization, if you don't want to wind up like OP.
Ask a real lawyer for advice.
They'll almost certainly tell you not to do it.
That position seems wrong to me, and the strained physical-world analogies you give don't justify it. Often, testing something directly is the only way to find out how it actually works. Which is necessary in plenty of non-hacking situations.
So much here is just an absolute wild failure of judgement.
I want to help others, but not at the risk of destroying my life.
If you report it immediately, often you'll even get asked to dig further; but doing it on your own without authorization is the problem.
> But I mostly kept this story to myself and felt it was time to share, even if anonymously.
I’m sure your lawyer would beg to differ that it is “time to share” if you still have a criminal and/or civil case pending.
I’m not sure why you’re publicizing what you have been accused of and providing the level of detail you have provided.
And is a Wordpress-hosted blog truly anonymous?
Anyway, I guess you are here for questions, so here is one: Do you feel like you made an ethical mistake attempting to find security holes in the competitor, or do you think your former employer overreacted and was wrong to fire you?
Would not be surprised if someone figured out how to register a free Wordpress account to the point where any disclosed information is a dead-end trail to any corporate investigators. Takes a dedicated discipline and tradecraft.
If I was in the shoes of OP I certainly would not be discussing anything related to my case until either its conclusion or with all publications reviewed by lawyers.
Then again I have not been in this situation but have seen how things can go south when certain advice is ignored.
Is it ethically wrong to check a public product to see if it follows basic security protocols? Especially if you’re an expert having created those security controls previously? Obviously not.
Is it ethically wrong to ask your employer before submitting findings to a competitor? Maybe? But only because you have an obligation to disclose regardless of what your employer says, but a judge isn’t going to be mad about following chain of command. It probably helped the bug report get p0 attention from the security team.
The fact of the matter is if the vulnerabilities were real and it sounds like they were, it’s fantastic news that the vulnerable company was able to fix them before the errors were exploited widely.
"legit pen testing" requires consent from the owners of the system being tested.
Also, if true, you likely have enough evidence for a stellar lawsuit against the company once all is said and done. You may also have enough evidence for a second lawsuit against your employer depending on exact circumstances. Hopefully your lawyer is knowledgeable enough to navigate these issues.
In the future, don't involve your employer with security disclosures. Ensure you document everything and email or write the company in question to give them time to fix their issues. What they did is wrong, however you should have reported it to them in a reasonable amount of time. Not that you are required to, but rather, to cover your own butt and prevent this exact type of scenario.
To what end? If your adversary has attorneys on staff it will be a bigger gamble for you to bring a suit against them.
Archives of the first, at least, still exist.
"AccidHacker" "Coming Soon"
Is this happening for anyone else? Perhaps it has been deleted?
It is true that exposing a vulnerability in somebody's product can make them mad, since it can harm them. Especially with banks, they are not the most ethical entities out there. Good luck. I wonder if more people would like to offer their advise on what you should have done instead.
So basically we learn do the minimum possible, to not do the right thing so as not to get fired, and ignore gaping holes leaving them for someone else to risk their neck on, all so we can pay bills for 50 years and then hopefully retire.
What a life.
Anarcho-tyranny is truly the mot juste.
[1]: https://thegrayzone.com/2022/02/18/hacking-canadian-trucker-...
I saw it happen personally with a bunch of GNAA related hacks. He had befriended the people who actually did them, and within a year or two of finding out more details, was using them to claim he had either masterminded and planned them all or performed them all, alternating between the two based on whatever was 'cooler' in the situation.
During the y2k times I did a lot of contract work porting old COBOL code to be y2k compliant. The number of seriously spooky security things was mind boggling.
Having mocked API's like you found is not a surprise. The fact they even bothered to use API's was a step in the positive direction versus telnet and ssh tunnels to pipe data around with hard-coded ip's and accounts.
He *may* have broken the law, but if he didn't commit financial crimes with the information he obtained and was falsely accused of them, lost his job over it, and was prosecuted for the false claims then he definitely has damages, some of which would fall under libel. This could go not so great for "Whistlr" if the information found in process shows that they maligned him.
I’ve seen so many blatant violations in my short stint it would make your head spin.
Happy to never go back…
I used to explore APIs and do this sort of digging for fun, even though I was employed. My approach was the following. If the company had a decent bug bounty program, I'd be happy to report it there, it's the safest way for anyone to do that. If there was not, I'd try to sell it to an "alternate buyer", which is less preferred. I never many things worthwhile reporting though.
Note to OP: if things don't go your way with the lawsuit, do the society a favor and let the world know who these guys are so we can all steer clear.
You need to keep in mind that security disclosures and everything around (legal, why disclose? etc) it is a black box for most folks.
Also OP said after reporting it, "months later" OP was fired. This means anyone in those months anyone could've found what the OP found and abused it. And the effected bank might've not been involved until later? And all those crimes are now on your shoulders. Your then bank employee would get delayed through the politics in your company (even with good intentions). It will happen even for their own security disclosure handling. Let alone for competitors cos so much legal stuff are involved now.
From the effected bank's POV, you are just a bank employee who did some fraud. Mainly cos you didn't inform the effected bank and it's been months. Insider hacks from the same industry is not unheard of.
Like I said, this would've been a different scenario if you informed them ASAP. And I am sure when issues hit the roof your employer would wash their hands off. It is the easiest thing to do. Unless you are very well connected in the office. Otherwise even your employee are not sure about you. They will be asking questions like, why is this person doing this anyways? He is not in security so why was the OP poking around it? etc etc.
Hope this gets sorted out. Interesting case indeed.
We've seen many cases where if you report a security vulnerability to a company, they blame you as a hacker instead of thanking you.
Which is why I added this. It will not be a smooth experience. But the OP will still be in a better position than the current one IMO.
You tell me who looks MORE suspicious.
- A guy who found a vulnerability and reported very soon and hence the effected bank know about it soon.
Or
- Or when the effected bank finds out after A COUPLE OF MONTHS (even a few weeks after) that their competitors employee found a vulnerability and they still haven't heard about it?
Keep in mind the added issue of the employee being from a competitor and that they might have already seen abuse of the vulnerability which might not be done by the OP. But since it is delayed, all of it is in the OP's shoulders.
https://news.ycombinator.com/item?id=30707216
Resource: https://clinic.cyber.harvard.edu/files/2020/10/Security_Rese... (PDF)
HN submission: https://news.ycombinator.com/item?id=30710885
I learnt this lesson in high school when I disclosed serious security vulnerabilities in the schools IT systems and statewide VPN and firewall/censorship solution. I was effectively expelled (in technicality "asked to leave").
Unless someone is paying you just don't bother. Even if they are paying you stick to the systems in the brief.
The opinion as fact stating here is incredible. The law is the law because that's what the law says it is. This was a stupid thing to do. There's just no arguing that.
The linked twitter feed at the bottom of the page is also protected/inaccessible.
This is ironic, but it is how business people deal with issues.
weev. If one doesn't know his story, the one shall do no such web requests. Or at least should know what the Tor is :)
Interesting possibility here - say somebody intentionally left that as a backdoor for a little side hustle of card fraud for themselves and associates or just to sell it and masqueraded it as just sheer security incompetence, and the author just happened to be a convenient patsy of opportunity.
I wouldn’t involve my employer ever.
I’m confused by his employer’s response, he told them everything, they knew, then the other company said something else happened?
So they took the other company’s word and fired him?
I’m not surprised that could happen but a little they would just believe the other company who they already know don’t know what they’re doing.
The story ends abruptly and … seems missing things.
And then they wanted just one rando fired?
Not sure that sense.
You ask the server permission to access the data, just like you knock on someone's door to come inside.
If they open it up, or return you data then you can only assume they are allowing you access.
When you start guessing passwords or reusing tokens or trying to access something with a different token, that's a bit different.
Lock your door if you want to keep the things inside safe.
Shit like this is why we keep such outrageous behavior quiet.
Mark my words.
If it gets to trial the judge won't understand anything and all he'll hear is hacking. Same for jury if one is involved.
Most likely a plea with probation and now he has a criminal record (possibly felony).
This isn’t some “right click view source” nonsense.
OP put in some decent amount of effort into compromising the bank’s system. A judge and jury will not understand this, even if they are a computer literate power user, and even if they work in IT in a non-security role.
I also assume that OP is telling their side of the story in the most favorable way possible, and could be omitting some details.
Let the dinosaurs have their own ways, good or bad.
But also remember, surprise pentesting with an ad hoc payment model is crime.
I'm not even sure which company I fault more here, OP's or the one with the security issue.
Did OP do that? I thought he said he did it in private time, so I assumed using private resources (the post is deleted now). Using work resources does change the situation, though if it's just about client-side systems and not IP space then it makes very little difference in practice. Especially if your employer lets you use hardware for private purposes (this is apparently very common for company phones and laptops in NL/BE/DE; personally I like to have clear boundaries there...), but we don't know if that was the case here iirc.
> destructive pen tests
That's not really what happened though, if I remember the post correctly. Running a GET without authorization header whatsoever on a beta application and getting back production data with secret payment tokens in it... you can't make that stuff up.
...which is exactly why I was asking which jurisdiction OP is in. Kind of annoying when that information is omitted. I work in Germany but am from the Netherlands; both cultures and the resulting laws are quite similar anyway.
> Conducting unauthorized security testing on a company competitor will absolutely get you fired.
In the US, maybe. If all US companies are like OP's. For a data point from Europe, I actually asked my employer because it seems people here (mostly from the US afaik) thought I had too much confidence in my employer in other comments. I commented here with what I asked and their reply: https://news.ycombinator.com/item?id=30710078
It's also a bit different to look into a product meant for the general public (that's how I understood OP's situation to be), or if you actively seek out to hack a competitor's infrastructure and mess with them (not what OP was doing from my understanding).
"and have a lawyer working on all this drama."
I'd say the main mistake here was, after finding the vulnerability, handing off the reporting responsibility to people who couldn't handle that responsibility rather than handling it personally.
And people wonder why even in the future nothing works.
Admittedly this is from a small sample of Seattle-area coffee shops but most of my experiences with non-home non-work WiFi is at coffee shops that provide the WiFi but expect you to bring your own device (laptop, phone, etc).
Is it still common to go someplace and rent time on a computer provided by the owner (i.e., at an internet cafe?)
I live in a capital city and am aware of at least three of these still kicking around.
I don't know about internet cafes specifically, but pretty much all cafes have internet these days.
> Using anonymisation proxies just makes it all the more suspicious, by using a normal connection and disclosing any findings it's quite clear you're using your real name, have no malintent, nobody needs to try and dig for your identity...
But yeah it all depends on the circumstances. Given how these companies are handling it, it couldn't have gone much worse I suppose. On the other hand, if the company suspects it was a black hat then you have to be very sure you can hide all tracks completely and, if found out, you have a lot more to explain.
That’s what you call an inaccurate cynical view.
Using anonymisation proxies just makes it all the more suspicious, by using a normal connection and disclosing any findings it's quite clear you're using your real name, have no malintent, nobody needs to try and dig for your identity...
So you think but you might be very wrong.
Also note that I'm not in the USA and it's not this 2 weeks' notice wild west style employment (from my point of view).
If you're referring to the author's use of Charles Proxy, it's *not* an anonymizer or anything of the sort, it's just the macOS equivalent of Fiddler: a localhost HTTP/HTTPS proxy that lets you decrypt TLS traffic (provided the client software isn't using certificate-pinning, which it wasn't).
From TFA:
> Wondering how I could feed them to the app, I set up Charles Proxy and pointed my phone to it. I honestly thought this wouldn’t work – who at this time doesn’t have SSL Pinning?
https://www.telerik.com/fiddler
As a curious user of other applications I've done the same thing the the author has described, so this kinda stuff isn't uncommon - except in my case I've never had an opportunity to stumble across anything as bad the author.
As for phone-app' insecure back-end web-services: that's about par for the course thesedays, even for banking and other "secure" services. It's depressing. I have plenty of my own pet-theories as to why things seem worse today than they were 10 years ago, but that's another discussion.
I am not, I was referring to the suggestions broadly shared elsewhere in the thread of doing this anonymously instead.
Assuming you're in the USA (might be an incorrect assumption) I'd strongly recommend familiarizing yourself with the CFAA and how "improper access to a computer" has been legally interpreted.
Can't speak for other European countries, I'm not familiar with their practices, but I haven't heard in recent years that anyone got prosecuted for responsible disclosure. A few months back a company started a civil case: that was unusual enough that it made the news (and it was dropped). About a year or so ago, someone was convinced while claiming to be white hat, but they emailed the company something like "pay me and I'll tell you what the problem is. Wouldn't want reputation damage now would we?" Again, unusual enough that it makes the news, and in neither case was a legit white hat "serving time".
Germany is way worse.
Scrum incentivizes waiting for bug reports from production.
Low tenures for employment mean there is no reason to care much about maintainability or security.
The pay difference between excellence and mediocrity is 2%.
What a world we live in.
> I haven’t made any transaction with those card numbers, told anyone specifics on how to get them, nor took any kind of advantage of this data.
Well, he just did. With this sloppy (forgivable if naïve), curiosity driven approach, I wouldn't be surprised ongoing exploitation wasn't simply the result of not cleaning up the test rig. Did he at least clear this with his lawyer before posting? Given the 404, I'm thinking not. Sheesh...
The write up is pretty confusing and doesn't read like an expert.
A company that wasn’t any kind of direct competitor announced they’d start issuing credit cards (then turning into direct competitors), and I started to became more and more curious about what they were building as I knew some (pretty good) people working there.
After reading that they had launched some card stuff on their production app, I downloaded it and looked for card-related assets (it was something really simple, unzipping a .ipa file and looking for images/texts)
Setting aside the data access issues, at a bare minimum your employer couldn't any longer guarantee that code you wrote wouldn't just get them sued.
The mock I used specified a card ID… the app then requested the number for that.
Something that I, logged in as a user without any credit cards, should be denied access to. But… There it was. And… in plaintext.
Having worked on some projects regarding credit cards and such I first thought they were running some kind of test environment on production, as this was a pilot that only employees (of a small team of them) should have access to.
“Maybe it’s even a static file being served on this route”. Couldn’t help myself but do one more request changing the ID. Brought another card number and name.
Regarding the rest of your outcome, I have two reads.
Assuming you're truthful, it's entirely possible someone else noticed the exact same issue at the same time and exploited this maliciously and it's going to be incredibly difficult for you to convince people it wasn't you, given you already have the track record of doing this same thing.
Assuming you're being deceitful here, there's a few warning signs along the path of the story.
Firstly, you write from the perspective of someone who believes themselves to be superior to the developers of the app you exploited. On the one hand, given what you found, I kind of get it, some of that seems like pretty basic security failings. On the other hand, in my experience this is what people who turn out to be guilty of the thing they're being charged/sued over tend to do as a way of explaining things.
Secondly, that you are communicating this at all suggests you're trying to prove you were "technically right" to do these things. Courts aren't going to care about that. Your lawyer was generally right to advise you against these things. This is now out there and will likely be used against you in a court of law.
I'm passing no judgements on whether or not it is right that you face this kind of litigation for reporting security issues; I work in security doing exactly this kind of work and the thing that often saves me is documentation, documentation, documentation. Agreements, in writing, signed by all parties, etc. Even that doesn't work sometimes.
Most likely illegal.
Don't do this.
Companies, this is what the rest of us recommend when YOU don't have a responsible disclosure program with $$$.