60

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?

Alexander O'Mara
  • 8,774
  • 6
  • 34
  • 38
gaazkam
  • 5,607
  • 11
  • 24
  • 37
  • 34
    What if someone hacked that random programmer? There goes your intellectual property. Good luck getting uber'd. – Mark Buffalo Nov 22 '17 at 16:55
  • 12
    The being on vacation issue is a non-sequitur - if the company has only a single person capable of making that change and that person is on vacation, that is the real problem. – Nacht Nov 22 '17 at 22:09
  • 10
    By reaching out to revoke his access, he implied "and evaluate whether any secrets could have been compromised" . By checking whether his access still works, he knows that nobody has probably looked at the issue at all. – pmf Nov 23 '17 at 09:58
  • 1
    Remember me of a classical hacker "legend" when [Motorola guys found a security issue in a xerox system](http://catb.org/jargon/html/meaning-of-hack.html) – jean Nov 24 '17 at 19:01
  • Did the blog comment on the qualitative aspects of the repository, e.g. size or content? For example, do we know if this repository contained the entirety of the company's massive code base complete with trade secrets, or if it was potentially some minor, unimportant content? – Nat Nov 26 '17 at 04:52
  • I would restore the repo from a backup before the permission error if this happened. – trognanders Nov 26 '17 at 23:12
  • Not getting ridiculed on popular infosec blogs is a pretty good reason in itself to act quickly, and one that really shouldn't require the benefit of hindsight. It's one issue whether there is an actual vulnerability that's exacerbated by taking your time. But they should have also thought about how it affects the company's image if they react in a very laid back manner. If you want to be trusted by your users, it's not enough to be professional, you should also look professional. – Tgr Nov 27 '17 at 05:48
  • The random programmer does not want to have anything to do with them. What if something bad happens? The programmer doesn't want to be on the suspect list – Mario Trucco Nov 27 '17 at 10:11
  • Here's [a perspective](https://panic.com/blog/stolen-source-code/) from a developer about what happens when your source code gets pwn'd. It explains why a breach may not be considered the end of the world. – Wes Toleman Nov 29 '17 at 03:23

9 Answers9

109

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.

Anders
  • 64,406
  • 24
  • 178
  • 215
  • Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/69189/discussion-on-answer-by-anders-is-it-urgent-to-revoke-the-access-to-a-private-re). – Rory Alsop Nov 23 '17 at 22:53
  • 12
    "*Are you really 100% sure there are no secrets in some old commit in your repo?*" If the repo is private, then by definition it contains secrets. – Simba Nov 24 '17 at 14:14
  • 14
    @Simba i have lots of private repos that contains no secrets - they're just private because i never bothered to share them, usually because they wouldn't be of interest to anyone but myself. – user1067003 Nov 25 '17 at 12:04
  • 2
    Also: As long as they have access to the repo, they can be accused of leaks and hacks made with info from the repo. (This doesn't completely end when access is revoked, but it does limit the potential damage.) – ikegami Nov 25 '17 at 21:38
58

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.

Monica Apologists Get Out
  • 4,021
  • 1
  • 14
  • 21
  • 28
    A, A, and again A. And a bit of B. But mostly a whole lot of A. – Wayne Conrad Nov 22 '17 at 15:23
  • He probably knows exactly how much trouble he can get if he kept silent. They obviously know his contact information to have given him access. – Nelson Nov 23 '17 at 19:31
  • 1
    I don't understand why this got 40 upvotes. The question asks about the administration actions. Discussion of the programmer's motivation doesn't belong in an answer. – Acccumulation Nov 23 '17 at 22:55
  • @Harry Johnston if you have a point, then make it. The third paragraph isn't about the programmer's actions, it's about the programmer's attitude. – Acccumulation Nov 25 '17 at 19:20
  • @Acccumulation, I don't understand why you think that distinction is relevant, which makes me think my previous comment wasn't clear, so I'll rephrase: the question is premised on the dubious assumption that the programmer's "attitude" as you put it is based entirely on an objective assessment of the risk to the company. The consensus on Stack Exchange is that explaining why a question's premise is flawed is a valid answer. This is sometimes referred to as a "frame challenge". – Harry Johnston Nov 25 '17 at 22:53
  • @HarryJohnston Given that the last sentence of the paragraph in question is "And here is where I'm surprised.", I don't see how the question can taken as assuming that the programmer's position is valid. – Acccumulation Nov 25 '17 at 23:40
  • @Acccumulation, I interpreted that sentence as meaning "I found this surprising, and that's why I'm asking this question" since otherwise there'd be little point in mentioning it. If you interpreted it differently, I can see why this answer would appear to you to be irrelevant. – Harry Johnston Nov 25 '17 at 23:48
  • 1
    I appreciate this answer. It gives me better understanding of the topic. – gaazkam Nov 26 '17 at 13:48
19

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.

Nzall
  • 7,313
  • 6
  • 29
  • 45
  • 2
    Yes +1, one can never know if the credentials of an unknown third party are strong. Or compromised. – Mindwin Nov 22 '17 at 17:24
  • 3
    Which is why you never store any API keys or sensitive info in your repo because repos get leaked all the time. – Qwertie Nov 23 '17 at 04:32
10

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.

Voo
  • 651
  • 5
  • 14
  • 2
    If the company store some trade secret or valuable IP in those repose it is most likely that the leaving employee will have a kind of NDA clause in his contract and will be liable for any use of those information. Random person that was granted access has no contractual obligation to not use those information as far as the law allows it. – Zefiryn Nov 23 '17 at 23:35
  • 4
    +1 even though I think it is urgent, it is urgent for the reasons you highlight - the stranger _may_ have been granted authority to commit and deploy code, and _secrets_ might be in the repo, perhaps hidden in old commits, because no-one is perfect, and security needs multiple layers of vigilance. – Qsigma Nov 24 '17 at 09:20
  • @Anders Yeah I was thinking purely from a security point of view. If business considerations or legal requirements are to be considered this gets much more complicated and I don't feel I'm qualified to give a complete answer on that. – Voo Nov 24 '17 at 23:01
  • @Zefiryn NDAs are not worth the paper they are printed on. – emory Nov 27 '17 at 00:28
7

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.

Pieter B
  • 665
  • 5
  • 8
  • If you have a private repo, then you can decide to grant me access without telling me. (You can fetch my public ssh keys from github without my knowledge or consent and then add them appropriately to .ssh/authorized_keys.) I have the keys to make changes in your private repo. Will I abuse this? Probably Not. Do I care? NO. – emory Nov 27 '17 at 00:31
4

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.

Anders
  • 64,406
  • 24
  • 178
  • 215
Booser
  • 141
  • 2
3

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.

Felix
  • 173
  • 4
1

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.

CGretski
  • 151
  • 6
1

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.

Community
  • 1
Giacomo1968
  • 1,185
  • 5
  • 16