2

If a box is using a weak SSH host key (lets say 1024-bit RSA), what kind of attacks is the box vulnerable to?

Jakuje
  • 5,229
  • 16
  • 31
Buffalo5ix
  • 2,636
  • 12
  • 18
  • Also somewhat relevant is http://security.stackexchange.com/q/143152/16960 . – Xiong Chiamiov Dec 22 '16 at 17:37
  • 1
    I'm not sure this is a duplicate of [In what ways does increasing SSH host key length increase security](https://security.stackexchange.com/q/45193/2138) as that question appears to be about the OpenSSH `ServerKeyBits` configuration value, which is only relevant to the SSH protocol version 1 ephemeral key, whereas this question is asking about the host key (which is customarily stored on disk as something like `/etc/ssh/ssh_host_*_key` and is anything *but* ephemeral in most setups, as replacing that key leads to "fingerprint has changed" warnings for every connecting client). – user Dec 22 '16 at 21:20

3 Answers3

2

In short, the Man In The Middle Attack. If the host key is too small and the attacker would be able to factor the number, re-create private key and possibly make a user send his password (or forward public key authentication) and get the access of respective user on that server.

Though we are not there yet and 1024 bits were not yet officially factorized (recently 768 bits were factorized in 2009), but the gap is close and we can expect that there are agencies with similar computation power to factorize 1024 bits or so.

Jakuje
  • 5,229
  • 16
  • 31
  • That's this: http://www.reuters.com/article/us-usa-security-nsa-rsa-idUSBREA2U0TY20140331 I'm sorry but it's compromised. – Shritam Bhowmick Dec 22 '16 at 19:49
  • 1
    @ShritamBhowmick Um, you do realize that there's a huge difference between *RSA the company* and *RSA the algorithm*, right? And let's not get into the BSAFE DUAL_EC_DRBG debacle again; that was a *programming toolkit default* for when the programmer relying on it made no explicit choice. Remember that back in 2004 or thereabouts, which is the relevant timeframe for BSAFE, the NSA (which in turn NIST relies upon) was not considered to be a part of most peoples' threat models. I suggest reading https://en.wikipedia.org/wiki/RSA_Security#Relationship_with_NSA; it has a decent summary. – user Dec 22 '16 at 21:17
  • 4096-bit key is vulnerable? no? http://securityaffairs.co/wordpress/20637/hacking/acoustic-cryptanalysis-attack.html Enlighten me, I might just miss tho - not perfect. – Shritam Bhowmick Dec 22 '16 at 21:23
  • 1
    @ShritamBhowmick Yes, but this is completely different attack than I am talking about. Usually you can't "listen around the server" to carry out this attack. Yes, it is a threat, but not a general attack vector you would be facing every day in normal environment. – Jakuje Dec 22 '16 at 21:28
  • The OP never described his environment. That's exactly what I wanted him to describe in the first place. – Shritam Bhowmick Dec 22 '16 at 22:24
2

There is a possibility that an attacker factorize your key and is able to spoof the identity of your server.

The server key is the primary defense against MITM attacks perform by an adversary who is either able to attack DNS or routing infrastructure between client and server or an adversary who legitimately controls some of that infrastructure.

In case a MITM attacks happens the most significant threat is the possibility of passwords being sniffed. If you are using key based authentication (and the key used by authentication is not equally weak), the threat is much less severe.

An attacker would still be able to hijack your connection and direct them to a server controlled by the attacker. Thus the attacker could see commands that you attempt to run on the server and capture files you try to upload.

But if you are using key based authentication the attacker will not be able to authenticate to the real server, thus your chance of noticing the attack early will be much improved as none of the attempted commands or uploaded files intercepted by the attacker will reach the real server.

kasperd
  • 5,402
  • 1
  • 19
  • 38
0

It's informational. Try using nmap and obtain the hostkey using ssh-hostkey, it would try to figure out the hostkey - although this in itself isn't a vulnerability since hosts should share different hostkeys if invoked.

The informational concern would be when the ssh-hostkey finds out that same hostkeys were being distributed when invoked. This however doesn't show that attacks were surely possible. Therefore it doesn't denote the pentester that there's a sure vulnerability in that particular system.

Shritam Bhowmick
  • 1,602
  • 14
  • 28