Is it urgent to revoke the access to a private repo once a person has been mistakenly granted it and become aware of this?

Question

There has been a post on Niebezpiecznik.pl, a popular InfoSec blog, describing an interesting situation.

A company mistakenly granted access to their BitBucket repo to a a random programmer. This programmer subsequently alerted various employees of the company, urging them to revoke access ASAP. He found these employees sluggish (for example, one said he would only revoke the access once he was back from his vacation), so alerted the Niebezpiecznik blog, which subsequently contacted the company. Only then was access revoked.

It is clear that the programmer considered the lack of prompt revocation of access to be a very grave oversight on behalf of the company's security policy. And here is where I'm surprised.

So, let's consider this from the company's point of view. Someone contacts them, claiming that he has been spuriously granted access to their private repo and urging them to revoke this access. Now this person either is or is not interested in the contents of this repo; he also either has or has not strong enough moral values to refrain from downloading it. If he's willing to inspect the contents of the repo, he's already had ample time to do this; and if he hasn't done this yet, then he will likely still not have done this by the time the employee is back from his vacation. In other words, the milk has already spilled and nothing worse than what has already happened is likely to happen in the future.

As a result, I would think, the situation is no longer urgent and can soundly wait until the employee is back from his vacation.

Where am I wrong?

Answer 1

There's a number of reasons:

• If it has happened to one person, it might have happened to more. These other people might not be as kind.
• Who knows, this person might change their mind. When they made the effort to contact you, and just gets a "meh" in return, they might be a bit annoyed and decide to punish you for it.
• Or maybe they just want to poke around a bit for fun, and accidentally break something.
• You probably want to check the logs to see that this person is telling the truth. Maybe they silently stole your encryption keys before contacting you. You probably want to rotate all your secrets just to be sure.
• And most importantly, this is a Big F*cking Deal™. Anyone who is not reacting with shock and horror, but instead orders another piña colada, clearly doesn't understand the gravity of the situation.

There's some very good points in comments and this answer that all might be fine under certain circumstances (e.g. read only access, no secrets in the code, etc.). That is correct, but I would still argue that this should be taken more seriously. Are you really 100% sure there are no secrets in some old commit in your repo? The very fact that someone who shouldn't have access to your systems got it anyway is in itself a bad omen.

Answer 2

While it's impossible to read the minds of the people at play - I'd think that the independent programmer

A) Doesn't want to be accused of impropriety - It's much harder to be accused of IP theft if you kick and scream to have your access revoked post-haste.

B) Is aghast at the security posture of the company that controls the private repository and knows that if he was responsible he'd want to be informed.

Answer 3

One thing to note is that giving an additional user access to a repository opens up a whole new possible attack vector. If someone else with malicious intentions has access to the account which has been granted access to the repo without the original account holder being aware, that person could easily download your entire source code.

Answer 4

To provide a different point of view than the majority, it really shouldn't be a security risk iff the project is well handled.

There's basically two things that have to be fulfilled. First, that

• You cannot introduce code into release branches without other people having to sign off on it. That's usually achieved by requiring pull requests and code reviews on any code that gets into a release branch. In this case if the person only got read access to the repository you do not have to worry about this. But still, you should have this in place anyhow.

and second that

• Nobody includes secrets in the repository. Yes you might have secret API keys, code signing certificates and what not, but the real ones should NEVER be in your main repository accessible to everyone. If some secrets are required for the code to work, include some dummy development/test versions in your repository. But the real ones should be kept separately with only a small number of people having access, preferably so that your build system includes them automatically without manual involvement.

If both of these are true I don't really see any harm from a security point of view. Whether there's some valuable trade secrets in the code that might leak to a competitor is a different topic.

Or another way to think about this: The situation here is nothing special. You have to deal with the same issues, every time an employee quits! If your repository contained any secrets an external person now knows all of them.

Answer 5

If stuff gets stolen, you go look first at which people have a key to the safe.

I've kicked and screamed in the past, not to have that key so if (when) something got stolen they wouldn't be looking at me as a possible perpetrator.

So this might just have been the same for that programmer. He didn't want to have that key.

Answer 6

You are right that the situation might not be urgent at all, and the lax reaction of the employees could be justified. Maybe the employee didn't bother with the issue because the code in question was not in use anymore or they have no secrets in there.

Answer 7

I've once worked for a startup where everybody was using the same SSH-keys because somebody thought it would be easier to delete/replace one key if somebody does something stupid.

Also there is the possiblity that developer has his key stored in a public accessible machine like a computer at the university. This may sound very unsecure, but is suitable for "Hello World" and "Practice Papers".

In this case, as you've stated, the company can be relatively sure, that the person who reported the incident won't try to hurt the company. But you can never be sure who has access to the account/keys of the person who was reporting the incident.

Answer 8

I don't read Polish, so forgive anything already addressed:

Bitbucket hosts git and mercurial repo's -- both are distributed CVS; these are generally incompatible with technological controls for protecting Intellectual Property/preventing IP egress; any existing clone/fork could be cloned without central audit trail visibility.

Proper security controls should be in place for modifying any repo, eg.

• PKI signoff for all commits
• read-only repo w/pull requests

Thus any damage possible is already done.

Answer 9

Security—at the end of the day—is a set of processes and procedures and a mindset. It is not a hard and fast set of rules. If you believe a system is vulnerable due to one measly breach, then your whole security mindset is flawed at best and might be useful only to Henny Penny/Chicken Little.

• If Credentials are Not Exposed, Who Cares? In my experience as a coder, Linux systems administrator and a security cleanup/fixer guy, the biggest issue with code being exposed in a repo is simply the risk of credentials being exposed. The reality is most sane coders know how to code without hard coding credentials into their code. But most coders are just lazy and have know idea why—or how—someone can architect a system with credentials being separated from core code.

  So if this system was run by sane coders, and the repo does not expose credentials then you know what? Who cares. But—as many of us already know—there are crappy “mall cop”-level coders out there who just shove credentials into core code and that’s that. You have to play it by ear.

• Trade Secret Exposure is a Risk. This depends on the industry and requirements the code was created under. If the code is for a blog or simple website? Whatever. Even if it is an e-commerce site, if it were a localized copy of something like Magneto, it’t not really a risk since that is open source software. But if this software were something proprietary and risky to expose—like something that could expose financial records and maybe even hot new code to a game—then it is a risk.

But at the end of the day the job of a “white hat” hacker is to inform others about the issues. If they are going to take a “Who cares?” attitude towards exposure, that is their problem. Maybe they genuinely see no risk? Maybe they genuinely don’t care and the exposure will hurt others? Maybe they are idiots? Maybe they are so smart code exposure would only mean—maybe—a few days of refactoring to limit risk? But at the end of the day there is just so much one can do to stop someone from hurting themselves.