OpenSSL Heartbleed Vulnerability Reference

    What can an attacker know


    Private key of the TLS server, private key of the TLS client (if the client is vulnerable), cookies, logins, passwords and any other data exchanged between the server and its clients. In this case, it is not necessary to listen to the communication channel, it is enough to send a specially formed packet, and this cannot be detected in the server logs.

    The vulnerability is two-way: if the vulnerable client connects to the attacker server, the attacker could read the client process memory. Example of vulnerable clients: MariaDB, wget, curl, git, nginx (in proxy mode).

    How to test a vulnerability


    Web services:
    - filippo.io/Heartbleed ,
    - www.ssllabs.com/ssltest ,
    - rehmann.co/projects/heartbeat ,
    - possible.lv/tools/hb .
    Client test: reverseheartbleed.com
    Python script: gist.github.com/sh1n0b1/10100394 , gist.github.com/mitsuhiko/10130454
    Go script: github.com/titanous/heartbleeder Website
    statistics: gist.github.com / dberkholz / 10169691

    Which systems are vulnerable?


    - Vulnerabilities OpenSSL 1.0.1 - 1.0.1f, 1.0.2-beta1, the vulnerability is fixed in OpenSSL 1.0.1g and 1.0.2-beta2 ( secadv ).
    - OpenVPN, including for Windows - fixed in version I004 ( download )
    - Any programs that are statically linked to a vulnerable version of OpenSSL.
    - Tor ( blog ).

    - Debian Wheezy (stable) - fixed in OpenSSL 1.0.1e-2 + deb7u5 and 1.0.1e-2 + deb7u6 ( security )
    - Ubuntu 12.04.4 LTS - fixed in OpenSSL 1.0.1-4ubuntu5.12 ( USN )
    - CentOS 6.5 - fixed in openssl-1.0.1e-16.el6_5.7 ( centos-announce )
    - Redhat 6.5 - fixed in openssl-1.0.1e-16.el6_5.7 ( solutions ,errata , bugzilla )
    - Fedora 19 and 20 - fixed in openssl-1.0.1e-37 ( announce )
    - Gentoo - fixed in openssl-1.0.1g ( GLSA )
    - Slackware 14.0 and 14.1 - fixed in openssl-1.0.1g ( slackware -security )
    - OpenSUSE 12.3 and 13.1 - fixed in openssl-1.0.1e ( opensuse-security-announce )
    - FreeBSD 10.0 - fixed in 10.0-RELEASE-p1 ( advisories )
    - OpenBSD 5.3 and 5.4 ( patch )
    - NetBSD 5.0.2
    - Amazon - fixed in OpenSSL 1.0.1e-37.66 ( security-bulletins )
    - Android 4.1.1 - other versions without vulnerability.

    Usually they depend on the vulnerable library and require a restart:
    - Web servers: Nginx, Apache, mail servers: Postfix, Dovecot, Jabber and other IM: ejabberd,
    - MySQL if TLS is used for authorization and it depends on OpenSSL: on CentOS, RedHat (including Remi), Percona Server ( blog ).

    What is not vulnerable


    - Windows (no OpenSSL), MacOS (old version of OpenSSL), Firefox, Thunderbird (defaults to NSS ), Chrome / Chromium (defaults to NSS ), Android (heartbeat is disabled).
    - Root and intermediate certificates that signed the keys of the TLS server (there are no private keys for them on the server)
    - OpenSSH (uses OpenSSL only for key generation)
    - OpenVPN if it uses static keys (not x509) or if it uses a key in the configuration like “tls -auth ta.key 1 "
    - Method for distributing updates to Unix-like OS (most often GnuPG is used for signing).

    How to update the system


    Debian, Ubuntu

    # aptitude update
    # aptitude -VR full-upgrade
    

    After that, completely restart the services that use TLS. The update installer will prompt you to restart automatically, or you can manually:
    # service nginx restart
    # service apache2 restart
    

    A complete list of services that need to be restarted and may be vulnerable:
    # lsof -n | grep -iE 'del.*(libssl\.so|libcrypto\.so)'
    или
    # checkrestart
    

    If you are not sure, it is better to completely reboot the server.
    Version Check:
    # dpkg -l | grep -i openssl
    # aptitude changelog openssl
    


    CentOS, RedHat, Fedora


    # yum update
    

    After that, completely restart the services that use TLS, for example:
    # service nginx restart
    # service httpd restart
    

    A complete list of services that need to be restarted and may be vulnerable:
    # lsof -n | grep -iE 'del.*(libssl\.so|libcrypto\.so)'
    или
    # needs-restarting
    

    If you are not sure, it is better to completely reboot the server.
    Version Check:
    # yum list openssl
    # rpm -q --changelog openssl
    


    Freebsd


    # freebsd-update fetch
    # freebsd-update install
    

    After that, completely restart the services that use TLS, for example:
    # service nginx restart
    # service apache22 restart
    

    If you are not sure, it is better to completely reboot the server.
    Version Check:
    # freebsd-version
    


    Revoking TLS keys and changing passwords


    - If the attacker was able to collect a completely private key, then he can use it to create a fake site, or to decrypt eavesdropped sessions. Therefore, it is recommended to revoke certificates, the keys of which could reach the attacker.

    - If the client browser passed passwords to the site without hash + salt, but in a pure form, then these passwords can also be compromised.

    For the future


    - You need to make sure that the browser checks to see if the certificate of the site it is visiting has been revoked.
    Firefox checks OSCP by default, and recent versions also support OCSP Stapling; Safari checks by default with Mac OS X 10.7 (Lion); Chrome does not check by default (in the settings section HTTPS / SSL), OCSP Stapling is not supported; Internet Explorer checks OSCP by default, but does not support OCSP Stapling; Opera checks OSCP by default; Safari does not check OSCP by default. Settings for different browsers .

    - On the server, it is desirable to enable Perfect forward secrecy (PFS). In this case, even if the private key is compromised, the attacker will not be able to decrypt past or future eavesdropped traffic. To do this, enable the Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) or Diffie-Hellman Ephemeral (DHE). Server setup , testing .

    Also popular now: