Hacker News Reader

Comment by asdfasgasdgasdg | Hacker News Reader

TBH I definitely wouldn't want my employees going around and hacking competitors in their free time. Too much potential liability. I can see giving a star performer a chance if it's their first time doing it and if they'd already come clean about it to the other party, but otherwise I'd probably cut my losses.

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.

View on HN

If this (not infosec) person was doing this type of security probing during work hours using work equipment, I could see them being fired even if they are hacking on the company’s own product.

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.

This is the part I’m stunned about. So many in this thread don’t see the liability of unpacking a competitors app and poking around their APIs.

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.

Personally I don't think what he did was wrong.

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.

But also don't do work related things on your non-work computer. Investigating the source code of your company's competitor's products is absolutely work related.

The thing that is kind of baffling to me about so many people in this comment section is that they think their personal opinion about the ethics of what he did has any bearing on anything. That's not how the legal system works at all.

To quote Tom Scott, a youtuber, "I'm not telling you how it should be, I'm just telling you how it is."

Precisely. Any corporate lawyer reading this thread is probably hoping none of the engineers in their company think this way.

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.

All the actions here were decisions made by a private company.

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)

> 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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

Otherwise any niche activity would be de facto illegal.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Obviously, this is not how the law sees it.

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

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

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

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

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

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

> I can see giving a star performer a chance

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.

> 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?

Cover up is never the solution.

It’s literally the least painful solution for the individual involved.

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.

It literally just takes someone to do an log inspection, and then he’s super screwed.

Until it is uncovered and the individual is now screwed twice; once for doing it, and once for covering it up, at which point the company can now potentially claim gross negligence if they become liable.

If he was doing it from the company network and company devices, almost surely, unless he got extremely lucky and their internal monitoring is pretty bad (unlikely at a bank).

I'm not saying I'd give them a chance to hack. I'm saying there's a chance I wouldn't have fired a star performer immediately on hearing they had been hacking. If it was someone I could afford to part with, I would, without a warning. The behavior in this blog post shows extremely poor judgment.

But you have to fire them. You especially have to fire the star performer.

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.

I'm interested to hear what real-world experiences have lead you to think this way.

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.

If your point is that some people will accept some rule breaking, then rule breaking is okay, I simply don’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 get the impression that your argument seems to be strongly motivated by your own moral values.

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 I went to my manager telling them I was hacking a competitor's infrastructure and accessing competitor PII & proprietary IP, I'd fully expect to be fired on the spot. And they're the most laissez faire manager I know.

Depends on how you raise it right? “I was trying to research how X built their app, to see if there was anything we could or should do in there, and I think I found a huge security vulnerability.”

This is still problematic. This runs the risk of IP theft claims.

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.

Well, chances are that I’m not trying to use their app in the first place if I’m working at their competitor, so I’m not sure if that should bother you.

> to see if there was anything we could or should do in there

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.

Yeah aside from the hacking there are potential copyright issues if he’s digging too deep in reverse engineering the competitor’s app.

Also when none of it ever leaves their own computer? It seemed to me like they were poking around for curiosity, not to publish any dirty laundry substantial enough to be a reverse engineering or copyright issue.

Yes, also then. If company A's app and company B's app happen to have some code in common, but one of company A's employees is found to have reverse engineered company B's app, then company B has a very nice case for suing company A for copyright violations.

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.

You're probably correct from a liability perspective, but from a hiring perspective in that space, you probably want the kind of personality that is driven to do such things working for you.

If by "such things" you mean trying to see how your competitor implements their product, no, that is certainly not the kind of personality you want to work for you (assuming you are not some unethical hack like Uber, of course).

And what makes you think you have or should have any control over what your employees doing in their free time?

Imagine not wanting curious people on your staff.

Curiosity is very important, but it is not the most important quality a person can have in all contexts. Wisdom comes to mind as one that is more important sometimes.

Wisdom is knowing stuff. Politics is something else.

Unfortunately, you gotta have the wisdom to recognize the politics and thereby protect yourself. To know when it's just not worth it. Sad but true

Knowledge is knowing stuff wisdom is knowing when and when not to apply that knowledge.

You can be curious without being reckless.

Agreed, use a trusted VPN.

I'm sure you meant it in jest, but yeah, if you are going to do something illegal at least try to cover your tracks. Naivety is not a virtue.

It was only half in jest.

Do you want staff to be curious enough to... Let's see... Run queries on your customer database to find out their friends' account balances?

Why did you immediately jump to a malicious scenario? Is that what you imagine curious people do?

No. My point is that curiosity is valuable, but so is integrity. The scenario I presented is around the same level of malicious as pen testing a competitor's new credit card API. Specifically, both are potentially criminal acts of illegal computer access (by current laws in the US), and both have negligible impact on their victims.

The kinds of assignments involved with GPZ also shy away from server-side applications ran by other companies.

Maybe doing approved bug-bounty research in a competitors webapp is a safer proposition.

> I definitely wouldn't want my employees going around and hacking competitors in their free time.

Where do you work? Just so I know where not to apply.

Hey now, they said they wouldn't want their employees doing it, not that they'd forbid employees doing what they will with their free time.

This is both a conflict of interest and could bring the employer into disrepute. Many employment contract rightfully forbid such actions, free time or not.

Please name a company where you would expect such behavior to be encouraged. Genuinely curious.

Uber? They care little for other laws, so I would be surprised if they cared for this one ethical standard.

"Encouraged" is different from prohibited / it being a firing offense.

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.

Reply on news.ycombinator.com