Wireless Access

last person joined: 2 days ago 

Access network design for branch, remote, outdoor and campus locations with Aruba access points, and mobility controllers.
Expand all | Collapse all

SSH and AES-CBC

  • 1.  SSH and AES-CBC

    Posted Oct 08, 2015 09:03 AM

    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 uses
    the following encryption algorithms and rejects all other encryption algorithms:
    aes128-cbc, aes256-cbc, [selection: AEAD_AES_128_GCM, AEAD_AES_256_GCM, no other
    algorithms].

    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.

     

    -Jon



  • 2.  RE: SSH and AES-CBC

    Posted Apr 15, 2016 04:09 AM

    Hi,

    Does this apply to Airwave SSH as well?



  • 3.  RE: SSH and AES-CBC

    Posted Apr 16, 2016 08:56 AM
    It looks to me like AirWave's SSH is not locked down quite as restrictively
    - it appears to use the OpenSSH default configuration. As AirWave begins to
    incorporate a FIPS 140-2 validated crypto library, however, I think this
    will change.



    [LOCAL] : Available Remote Kex Methods =
    diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diff
    ie-hellman-group14-sha1,diffie-hellman-group1-sha1

    [LOCAL] : Available Remote Send Ciphers =
    aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,b
    lowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.l
    iu.se

    [LOCAL] : Available Remote Send Macs =
    hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripe
    md160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96





    Obviously you can control which ciphers you want to use from the client side
    too. Or, AirWave lets you login to a root shell and you can adjust the
    server side as well by editing /etc/ssh/sshd_config if you don't like what
    you see.



    -Jon


  • 4.  RE: SSH and AES-CBC

    Posted Jul 25, 2016 05:32 PM

    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.

     

    Thanks!

     

    Jon Prouty

    HarborTech



  • 5.  RE: SSH and AES-CBC

    Posted Jul 25, 2016 07:36 PM

    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,

    Kevin

     



  • 6.  RE: SSH and AES-CBC

    Posted Jul 26, 2016 12:59 PM

    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 0
    debug2: kex_parse_kexinit: reserved 0
    debug2: kex_parse_kexinit: diffie-hellman-group14-sha1,ecdh-sha2-nistp256,ecdh-sha2-nistp384
    debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
    debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes256-cbc
    debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes256-cbc
    debug2: kex_parse_kexinit: hmac-sha1,hmac-sha2-256,hmac-sha2-512
    debug2: kex_parse_kexinit: hmac-sha1,hmac-sha2-256,hmac-sha2-512
    debug2: kex_parse_kexinit: none,zlib@openssh.com
    debug2: kex_parse_kexinit: none,zlib@openssh.com

     

     

    Be careful that you look at the second set of "kexinit" output - the first set is what the client supports.



  • 7.  RE: SSH and AES-CBC

    Posted Jul 26, 2016 01:01 PM

    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. :)

     



  • 8.  RE: SSH and AES-CBC

    Posted May 28, 2018 05:39 AM

    FYI

    1. CBC ciphers have been deprecated in upstream openssh since version 7.3p1
    2. Ubuntu 18.04 uses openssh 7.6p1 and any attempt to log into an Aruba controller running AOS 6.5.3.5 or even 8.2.1 results in
    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.
     



  • 9.  RE: SSH and AES-CBC

    Posted Jul 11, 2019 05:11 AM

    Any update on this?



  • 10.  RE: SSH and AES-CBC

    Posted Jul 11, 2019 05:22 AM

    Aruba has added aes128-ctr to ciphers it offers on recent AOS versions. At least 6.5.4.12, 8.3.0.7, 8.4.x and 8.5.x support it.

     

    AirWave still uses cbc even on recent versions (at least on 8.2.8.1).