5

We have a continuous integration server, for which a recent coworker who joined the team has put details (login name and server address) in his public Github repository.

The server ssh configuration only allows public key authentication and the coworker refuses to take down his information from the public Github repo, saying it is not a threat because the security of ssh is good enough.

I know that since we have disabled password authentication, it does not immediately result in a vulnerability, but still I did not want to give a potential adversary the following information:

  • The login username on our CI server
  • The ip of the CI server itself
  • The fact that coworker is using lastpass to store his secret keys
  • The fact that he has published his lastpass login address to his public repo itself

(The public repo is basically his configuration repo which he uses to set up his machine).

Since he refused to take down the info, I proposed to at least make sure that our CI server is behind a VPN server and we have done that. However I still believe that it is a violation of security in depth to provide this info to an attacker.

Am I being extra paranoid, or could there be real consequences of having this information publicly available? I am aware that some of this is security through obscurity, but I am thinking it would not hurt hiding this info anyway. I am assuming it could be useful in case of a directed attack, since it gives the attacker some info that he did not probably have access to.

4

You are not being paranoid. Getting internal information like usernames and passwords are part of information gathering which is done before breaking into systems. And especially with usernames and passwords it is common (but not recommended) to use the same or similar names and passwords to protect other resources, so these are valuable information.

But apart from that it is hard to take such published information back. The information are still in the git repository, even if they are not in the current HEAD. So you should at least make sure that none of these information or variations of these are in use on any of your systems.

  • Thank you for the response. I actually will treat the usernames and the server name compromised and try to have them changed. My guess is, since github exposes all public events, people are running scrapers to detect lines in commits in the username@hostformat in addition to other stuff like AWS_SECRET_KEY etc. – Sec Noob Aug 28 '16 at 11:07
  • @SecNoob: yes, see also the story I found Prezi’s source code. – Steffen Ullrich Aug 28 '16 at 11:12
  • In our case, coworker argues that just the username, not password or private key is out in the open though. Does that affect your response? – Sec Noob Aug 28 '16 at 11:31
  • @SecNoob: if this is an uncommon username (i.e. not root, admin...) this still might be valuable information that such user exist. Maybe the same user exists on a different system too but accessible with a password from outside: in this case one could try to SSH brute force the account. Information gathering is not necessarily to immediately get the secrets, but to make it easier to get the secrets. Or knowledge of a specific name and its role could be used in social engineering attacks, especially if the other party is not aware that the internal name is public accessible information. – Steffen Ullrich Aug 28 '16 at 11:36
  • 2
    As this answer states, taking down the git repo is no longer sufficient, it's now considered OSINT (Open Source Intelligence) and can be retrieved via network caches, etc. When we do penetration tests against companies, searching for this information is one of the first steps we take, and regardless of whether or not the credentials can be used just knowing those details is useful. – Michael Aug 29 '16 at 2:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.