Every month or so, someone contacts the Aruba Security Incident Response Team because their vulnerability scanner of choice reports that use of AES-CBC within SSH is a vulnerability. The vulnerability scanner vendors have been notoriously bad at understanding cryptography (example: interpreting HMAC-SHA1-96 as a 96-bit hash and flagging this as weak), so this is not surprising. I'm going to write this post so that in the future, I can refer people back to it when they ask the question.
The original vulnerability was described in http://www.isg.rhul.ac.uk/~kp/SandPfinal.pdf, published in 2008. A CERT database entry exists at http://www.kb.cert.org/vuls/id/958563.
Without forcing you to read the entire paper, the root of the problem was that an attacker could inject SSH packets into a session, and SSH would indicate whether or not the attacker had guessed a valid message length field. An attacker could guess this with probability of 1 in 2^14 (that is a very small number) and if he guessed wrong, the SSH session would terminate. So this by itself is already not a high risk for interactive SSH sessions - a user will notice if his SSH session resets over and over. But for automated sessions that reconnect automatically and have no mitigations in place to detect error conditions, it could be a legitimate concern. What's the problem with CBC? Each block of ciphertext gets used as part of the crypto operation for the next block. If an attacker can recover one block, that potentially lets him recover one additional block. So already in my mind, I'm thinking "Low probability of success, high probability of being noticed, and even if it does succeed, only 32 bits of plaintext are leaked. What's the big deal?"
Well, of course, any crypto leakage can potentially be a big deal. Fortunately, the OpenSSH team made two changes in OpenSSH 5.2:
- They no longer return different error messages upon a failure to find a valid message length field. That makes the attack much less effective.
- In the following release, they cause OpenSSH to continue reading up to the maximum message length even when an error has already been detected. This removes the clue that an attacker would need in order to find a successful attack (an attacker might get a valid message length, but is going to fail on the MAC). From the OpenSSH 5.2 release notes:
* This release also adds countermeasures to mitigate CPNI-957037-style
attacks against the SSH protocol's use of CBC-mode ciphers. Upon
detection of an invalid packet length or Message Authentication
Code, ssh/sshd will continue reading up to the maximum supported
packet length rather than immediately terminating the connection.
This eliminates most of the known differences in behaviour that
leaked information about the plaintext of injected data which formed
the basis of this attack. We believe that these attacks are rendered
infeasible by these changes.
In other words - in a post-OpenSSH 5.2 world, we do not need to worry about this attack.
As further evidence, the Common Criteria "Network Device Collaborative Protection Profile" (https://www.niap-ccevs.org/pp/cpp_nd_v1.0.pdf), which was written by an international technical community and adopted by the central governments of a wide variety of nations, requires AES-CBC to be supported. Excerpting from the document:
FCS_SSHS_EXT.1.4 The TSF shall ensure that the SSH transport implementation usesthe following encryption algorithms and rejects all other encryption algorithms:aes128-cbc, aes256-cbc, [selection: AEAD_AES_128_GCM, AEAD_AES_256_GCM, no otheralgorithms].
Common Criteria evaluated products are used to protect national security information. My interpretation: If use of CBC mode ciphers in SSH were still a problem, these people would have mandated that it not be used, rather than what we see above.
Conclusion: We at Aruba believe that the vulnerability scanner vendors are wrong on this, and have no plans to change our products to remove CBC support.
Questions? Please reply and let me know.
Does this apply to Airwave SSH as well?
Hi Jon, thanks for the hardening guide and this thread, very helpful. My customer is asking me if there is a way to restrict acces to ssh on the controllers and clearpass to 256 only? I could tell them they need to set their clients to 256 but it would be great if there was a way to restrict it on the host side to only 256. If not that is ok too I just need a hard yes/no on that particular functionality.
To be clear, the question about running 256 is more around "how do we know we verify we are running AES 256 or 128 even though the software being used by Security is reporting 96 bit?".
This is more around wanting to provide the security team with details they can sink their teeth into instead of simply saying "Hey security, your tool is broken & reporting wrong information. We're already compliant. Have a nice day", and potentially starting WWIII.
Hope that makes sense.
Cheers and thanks,
The specific ciphers in use are hardcoded on those two products and can't be edited by an administrator.
It's pretty easy to show them what's actually supported by an SSH server - just put a client into debug mode when you connect. SecureCRT for example has a "trace options" setting. OpenSSH will let you specify the -vv option, so "ssh -vv some.hostname" will give you a dump that shows what the server offered, like this:
debug2: kex_parse_kexinit: first_kex_follows 0debug2: kex_parse_kexinit: reserved 0debug2: kex_parse_kexinit: diffie-hellman-group14-sha1,ecdh-sha2-nistp256,ecdh-sha2-nistp384debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes256-cbcdebug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes256-cbcdebug2: kex_parse_kexinit: hmac-sha1,hmac-sha2-256,hmac-sha2-512debug2: kex_parse_kexinit: hmac-sha1,hmac-sha2-256,hmac-sha2-512debug2: kex_parse_kexinit: none,firstname.lastname@example.org: kex_parse_kexinit: none,email@example.com
Be careful that you look at the second set of "kexinit" output - the first set is what the client supports.
And by the way, regarding AES256.... you need to look at security as the sum of all the parts. Using AES256 when you're using a password for authentication is supreme overkill. An attacker will go after your password - they aren't going to break AES256. One is some amount of work, especially if you have a good password. The second is exponentially more difficult. Need to assign risk where it belongs. :)
Unable to negotiate with x.x.x.x port 22: no matching cipher found. Their offer: aes128-cbc,aes256-cbc
The ciphers are still compiled in the code and you can force ssh to use them, but they might be left out alltogether in the future. Perhaps it's time AOS supported other ciphers as well? Any recent piece of software that uses openssh is going to have issues connectiong to Aruba devices.
Any update on this?
Aruba has added aes128-ctr to ciphers it offers on recent AOS versions. At least 22.214.171.124, 126.96.36.199, 8.4.x and 8.5.x support it.
AirWave still uses cbc even on recent versions (at least on 188.8.131.52).
Hello... is there any updates on this post?
* This release also adds countermeasures to mitigate CPNI-957037-style attacks against the SSH protocol's use of CBC-mode ciphers. Upon detection of an invalid packet length or Message Authentication Code, ssh/sshd will continue reading up to the maximum supported packet length rather than immediately terminating the connection. This eliminates most of the known differences in behaviour that leaked information about the plaintext of injected data which formed the basis of this attack. We believe that these attacks are rendered infeasible by these changes.
What would be your question? What are you looking for?
© Copyright 2023 Hewlett Packard Enterprise Development LPAll Rights Reserved.