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?
9
-
29I'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– markasoftwareJul 29, 2015 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.– deviantfanJul 29, 2015 at 19:45
-
38Your "friend".... riiiight– Abe MiesslerJul 29, 2015 at 22:54
-
6I can't imagine someone who uses private keys and understands what they are being nonchalant at the disclosure of their private key.– March HoJul 29, 2015 at 23:24
-
8Perhaps your friend was inspired by xkcd.– mhwombatJul 30, 2015 at 16:51
|
Show 4 more comments
3 Answers
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:
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?
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.
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).
answered Jul 29, 2015 at 19:58
-
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.– dknsJul 29, 2015 at 20:03
-
8You 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.– SoronJul 29, 2015 at 22:29
-
-
1@EthanKaminski Fortunately git is versioned to such access cannot do unrepairable damage to the codebase (but it can to his reputation).– gerritJul 30, 2015 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.– KevinJul 30, 2015 at 16:32
- 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.
-
3Can you clarify your fourth point? I think you might be missing some words; I'm finding it pretty hard to understand.– SchismJul 29, 2015 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.– user82155Jul 29, 2015 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. Jul 29, 2015 at 22:06
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.;)
