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.
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.
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.
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.
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.
Not that ignorance of the law is an excuse, but when are software developers not in infosec supposed to be taught these limits?
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.
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.
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*.
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)?
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.
What's disappointing is that his company didn't stand by him during the investigation, especially since he reported it.
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-...
Get protected status as a whistleblower.
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.
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."
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Maybe doing approved bug-bounty research in a competitors webapp is a safer proposition.
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.
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.
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
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.
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.
...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).
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.
"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?)
Germany is way worse.
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".
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.
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...
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.
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).
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.
> 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.
> 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 $$$.