45

A friend of mine managed to expose both id_rsa and id_rsa.pub file from his server via apache. I mentioned to him that this is serious security issue but he brushed this off like it was no big deal. Since I don't possess enough security knowledge to explain to him why this is bad can someone help me out here? Or maybe my friend is right and it is not as bad as I imagine it to be?

dkns
  • 531
  • 4
  • 9
  • 29
    I'm not a security expert by any means, but I'm pretty sure anybody who manages to get that private key will be able to pretend to be him, make fake ssh keys in his name that are indistinguishable from legitimate ones, etc. So, pretty much, all his security is COMPLETELY gone, this is pretty much as bad as it gets as far as security is concerned, as far as I know – markasoftware Jul 29 '15 at 18:41
  • 27
    "He brushed this off like it was no big deal." even after you explained it to him? Then he´s an idiot, period. But ... If this is his own server without involvement of anyone else (including customers or anything), you can´t do anything [legally] other than let him fail. – deviantfan Jul 29 '15 at 19:45
  • 3
    If he brushed it off as no big deal, it could be because he he's planning on wiping the server and rebuilding it anyway, or because he he doesn't think anyone actually retrieved the key before he removed it (theoretically you could check logs to determine this.) – barbecue Jul 29 '15 at 20:47
  • 38
    Your "friend".... riiiight – Abe Miessler Jul 29 '15 at 22:54
  • 6
    I can't imagine someone who uses private keys and understands what they are being nonchalant at the disclosure of their private key. – March Ho Jul 29 '15 at 23:24
  • 8
    Perhaps your friend was inspired by [xkcd](http://imgs.xkcd.com/comics/public_key.png). – mhwombat Jul 30 '15 at 16:51
  • Can you tell me what website this is? So I can block it using my hosts file please. – Alec Teal Aug 01 '15 at 00:38
  • @deviantfan *Since I don't possess enough security knowledge to explain to him why this is bad...* - OP didnt explain why. – Loko Aug 03 '15 at 12:24
  • `cat /var/log/apache2/access.log | grep id_rsa` and you'll know how serious it is unless the logs got wiped already. – Nomad Nov 23 '18 at 10:44

3 Answers3

60

I suppose that these files are for "his SSH key" as a client.

Revealing the public key (id_rsa.pub) has no consequence: when we call it a public key we mean it. The private key (id_rsa) is of course the problem.

The way you use, as a client, your private key, is to push the corresponding public key into the server, in the .ssh/authorized_keys of the target account. When the public key is in this file, then whoever knows the private key may log into the server under that name. That's how the public/private keys work on the client side in SSH.

So there are basically three possible, rational reasons that would allow your friend to disregard the disclosure of his id_rsa file:

  1. Maybe he never pushed the public key anywhere. When he logs into a server, he does it by typing his account password for that server, always. If his key pair is never used, then revealing the private key is harmless. But then, why would he have such a key pair?

  2. Possibly, all the servers he connects to, with private key authentication, are located on a private network, with only non-hostile users, and strong isolation from the outside world.

  3. It is conceivable that the private key is protected by a password (or "passphrase" in SSH terminology), which means that it really is encrypted with a key derived from the password; and your friend has great trust in the strength of his password.

Note that even if the private key is unprotected (or protected with a guessable password) and grants access to some servers reachable by attackers, then what the attackers can do is log in to these servers in the name of your friend (which is already a big problem). This does NOT grant to attackers the power to do a Man-in-the-Middle attack (MitM is double-impersonation, so a MitM attacker must know the private keys on both client and server); they cannot either decrypt past or future sessions that they eavesdrop on, or alter data of ongoing sessions (notably, the asymmetric keys in SSH are used for authentication, but the key exchange uses Diffie-Hellman).

Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • I meant ssh keys stored on his server. Basically he set /var/www (or whatever the apache root was) as his $HOME directory. We were checking if any .git file is unprotected and available by typing fullurl/.git into browser when he remembered that he set /var/www as his $HOME. He typed fullurl/.ssh/id_rsa and private key in plain text was displayed. Sorry for not being clear. – dkns Jul 29 '15 at 20:03
  • 8
    You were checking for a .git directory? So, he probably uses something like GitHub or BitBucket. In turn, that means that his private key might enable an attacker to gain access (possibly read-only, possibly read-write) to his code. – Soron Jul 29 '15 at 22:29
  • @EthanKaminski He might use a different key for each site. – user253751 Jul 30 '15 at 09:27
  • 1
    @EthanKaminski Fortunately git is versioned to such access cannot do unrepairable damage to the codebase (but it can to his reputation). – gerrit Jul 30 '15 at 10:33
  • 1
    @James_pic: Yes, but only if you don't catch it within 30 days. Otherwise, you can recover it from the reflog. – Kevin Jul 30 '15 at 16:32
  • @Kevin also, since it's a distributed repository, anyone who has downloaded the sources can restore it. – o0'. Jul 30 '15 at 20:29
  • @Kevin Unless, for some crazy reason, you decide to run `git reflog --expire=all` the night before. – JAB Jul 31 '15 at 13:53
23

- Authentication / Access Control

People who possess his credentials might be able to login into systems impersonating him.

- Non-Repudiation

Others will be able to sign messages as him, and he will not be able to deny sending them.

- Confidentiality

All his private communications can be decrypted and leaked.

- Integrity

Previous documents can be already and re-signed / re-hashed being no longer integer as in the last version prior to the incident.

Long story short – he has to get it revoked ASAP and get a new one.

Scott - Слава Україні
  • 297
  • 1
  • 10
  • 3
    Can you clarify your fourth point? I think you might be missing some words; I'm finding it pretty hard to understand. – Schism Jul 29 '15 at 21:21
  • 3
    @Schism The last point isn't really applicable here. The key in question appears to be an SSH key; signatures made using these keys are always verified on the spot. –  Jul 29 '15 at 21:25
  • 3
    "he cannot deny he was not the one sending it." I think there's a misnegation there. Shouldn't it be either: "he cannot claim [that] he was not the one sending it" or "he cannot deny [that] he sent it"? After all, he'd *want* to deny sending it; he wouldn't want to deny *not* sending it. – Joshua Taylor Jul 29 '15 at 22:06
0

SSH private keys are usually (by default) encrypted with a strong symmetric cipher. In some circumstances (not production use, of course) it may be viable to have those keys in an accessible shared location for ease of operation. This barely reduces the strength of the key to the strength of the password it is encrypted with, which may be tolerable, depending on the use pattern of the aforementioned keys and servers they belong too.

Just had to play the devil's advocate here.;)

oakad
  • 327
  • 1
  • 3