Intrusion Detection 1

Section 4.2.5

Vulnerabilities

SSL / TLS

What is SSL / TLS?

2

Transport Layer Security protocol, ver 1.0

De facto standard for Internet security“The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications”

In practice, used to protect information transmitted between browsers and Web servers

Based on Secure Sockets Layers protocol, ver 3.0

Same protocol design, different algorithmsDeployed in nearly every web browser

History of the Protocol

3

SSL 1.0Internal Netscape design, early 1994?Lost in the mists of time

SSL 2.0Published by Netscape, November 1994Badly broken

SSL 3.0Designed by Netscape and Paul Kocher, November 1996

TLS 1.0Internet standard based on SSL 3.0, January 1999Not interoperable with SSL 3.0

History of the Protocol

4

TLS 1.0Internet standard based on SSL 3.0, January 1999Not interoperable with SSL 3.0

On September 23, 2011 researchers Thai Duong and Juliano Rizzo demonstrated a "proof of concept" called BEAST (using a Java Applet to violate "same origin policy" constraints) for a long-known Cipher block chaining (CBC) vulnerability in TLS 1.0.

Practical exploits had not been previously demonstrated for this vulnerability, which was originally discovered by Phillip Rogaway in 2002.

Google included a patch in development version of their Google Chrome web browser to mitigate BEAST-like attacks.

The TLS 1.0-specific BEAST attack can be prevented by removing all CBC ciphers from your list of allowed ciphers—leaving only the RC4 cipher, which is still widely supported on most websites.

Microsoft is releasing tools to support TLS 1.1 (which fixes this CBC attack vulnerability) on Microsoft servers and browsers.

History of the Protocol

5

TLS 1.1 (SSL 3.2)TLS 1.1 was defined in RFC 4346 in April 2006. It is an update from TLS version 1.0. Significant differences in this version include:

Added protection against Cipher block chaining (CBC) attacks.The implicit Initialization Vector (IV) was replaced with an explicit IV.Change in handling of padding errors.Support for IANA registration of parameters

History of the Protocol

6

TLS 1.2 (SSL 3.3)TLS 1.2 was defined in RFC 5246 in August 2008. It is based on the earlier TLS 1.1 specification. Major differences include:

The MD5-SHA-1 combination in the pseudorandom function (PRF) was replaced with SHA-256, with an option to use cipher-suite specified PRFs.The MD5-SHA-1 combination in the Finished message hash was replaced with SHA-256, with an option to use cipher-suite specific hash algorithms.The MD5-SHA-1 combination in the digitally-signed element was replaced with a single hash negotiated during handshake, defaults to SHA-1.Enhancement in the client's and server's ability to specify which hash and signature algorithms they will accept.Expansion of support for authenticated encryption ciphers, used mainly for Galois/Counter Mode (GCM) and CCM mode of Advanced Encryption Standard encryption.TLS Extensions definition and Advanced Encryption Standard CipherSuites were added.

TLS 1.2 was further refined in RFC 6176 in March 2011 redacting its backward compatibility with SSL such that TLS sessions will never negotiate the use of Secure Sockets Layer (SSL) version 2.0.

History of the Protocol

7

Internet SSL Survey 2010 Black Hat USA 2010Ivan Ristic, Qualys, July 29, 2010http://blog.ivanristic.com/Qualys_SSL_Labs-State_of_SSL_2010-v1.6.pdf

TLS In Online Retailing

8

Most Internet retail sites use TLS 1.0 to secure online payments.

Online merchants purchase digital certificates from CAs (e.g., Verisign) to authenticate itself to the browser software.

TLS is NOT an electronic payment protocol. It is used to safely transmit sensitive financial information (e.g., credit card number , personal address, etc.)

It means online merchants using TLS (e.g., Amazon.com) do not process the credit cards in real-time. A traditional mail order/telephone order (MOTO) protocol is used after for payment processing later,

TLS provides security in authentication and communication. It does not address other security issues: it is up to the individual to trust a name linked to a certificate, and in its ability to protect and not misuse its database.

TLS in the Real World

9

TLS in the Real World

10

TLS in the Real World

11

TLS in the Real World

12

Real TLS: Handshake (1)

13

Purpose

Server authentication

Negotiation: agree on crypto algorithms

Establish keys

Client authentication (optional)

Real TLS: Handshake (2)

14

Client sends list of algorithms it supports, along with client nonce

Server chooses algorithms from list; sends back: choice + certificate + server nonce

Client verifies certificate, extracts server’s public key, generates pre_master_secret, encrypts with server’s public key, sends to server

Client and server independently compute encryption and MAC keys from pre_master_secret and nonces

Client sends a MAC of all the handshake messages

Server sends a MAC of all the handshake messages

Real TLS: Handshaking (3)

15

Last 2 steps protect handshake from tampering

Client typically offers range of algorithms, some strong, some weak

Man-in-the middle could delete the stronger algorithms from list

Last 2 steps prevent this

Last two messages are encrypted

TLS Basics

16

TLS consists of two protocols

Handshake protocol

Use public-key cryptography to establish a shared secret key between the client and the server

Record protocol

Use the secret key established in the handshake protocol to protect communication between the client and the server

TLS Handshake Protocol

17

Two parties: client and server

Negotiate version of the protocol and the set of cryptographic algorithms to be used

Interoperability between different implementations of the protocolAuthenticate client and server (optional)

Use digital certificates to learn each other’s public keys and verify each other’s identity

Use public keys to establish a shared secret

The TLS Handshake

18

Client hello

Server hello

Present Server Certificate*Request Client Certificate

Server Key Exchange

Client Finish

*Present Client CertificateClient Key Exchange

*Certificate VerifyChange Cipher Spec

Server Finish

Change Cipher Spec

Client

Server

Application Data

Client (Browser)

Server

1. Client sends ClientHello message

2.Server acknowledges with ServerHello message

.Session Key

Server Certificate

Client Certificate

3. Server sends its certificate

(4. Server requests client’s certificate)

(5. Client sends its certificate)

Server’s public key

6. Client sends “ClientKeyExchange” message

Server’s private key

Session key

Digital signature

(7. Client sends a “Certificate Verify” message)

8. Both send “ChangeCiperSpec” messages

Digital envelope

..X

9. Both send “Finished” messages

The TLS Handshake

Credit Card Processing

20

4. Buyer’s bank authorizes/rejects

2. Seller transmits payment data to seller’s bank

10. Buyer’s bank sends bill to buyer

3. Seller’s bank asks buyer’s bank for authorization

BUYER’SBANK

SELLER’SBANK

BUYER

5. Seller’s bank notifies seller

6. Seller ships goods to buyer

11. Buyer pays buyer’s bank using some other method of payment, e.g. writes the bank a check

7. End of day processing – seller uploads completed transactions to bank

SELLER

8. Seller’s bank credits seller’s account

1. Buyer gives credit card info to seller to purchase an item

9 End of day processing

Exploits

21

Blunders expose huge cracks in net's trust foundation11th April 2011

Analysis Every year or so, a crisis or three exposes deep fractures in the system that's supposed to serve as the internet's foundation of trust. In 2008, it was the devastating weakness in SSL, or secure sockets layer, certificates issued by a subsidiary of VeriSign.

In 2009, it was the minting of a PayPal credential that continued to fool Internet Explorer, Chrome and Safari browsers more than two months after the underlying weakness was exposed.

In 2010, it was the mystery of a root certificate included in Mac OS X and Mozilla software that went unsolved for four days until RSA Security finally acknowledged it fathered the orphan credential.

http://www.theregister.co.uk/2011/04/11/state_of_ssl_analysis/

Exploits

22

Moxie Marlinspike - New Techniques for Defeating SSL/TLS - Blackhat 2009

This presentation demonstrates new tools and techniques that allow attackers to silently alter, inject, and log traffic intended for secure transmission by SSL/TLS in common web applications such as online banking or secure webmail logins. It builds off of the SSL exploit tools and research on the failure of browsers to validate BasicConstraints that I published in 2002, and will include demonstrations of a new tool for exploiting current use patterns as well as some data gathered from field testing in the real world.

Video of the entire presentation:http://securitytube.net/Defeating-SSL-using-SSLStrip-(Marlinspike-Blackhat)-video.aspx

The presentationhttp://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf

Exploits

23

Blunders expose huge cracks in net's trust foundation11th April 2011

In 2011, it was the March revelation that unknown hackers broke into the servers of a reseller of Comodo, one of the world's most widely used certificate authorities, and forged documents for Google Mail and other sensitive websites. It took two, seven and eight days for the counterfeits to be blacklisted by Google Chrome, Mozilla Firefox and IE respectively, meaning users of those browsers were vulnerable to unauthorized monitoring of some of their most intimate web conversations during that time.

http://www.theregister.co.uk/2011/04/11/state_of_ssl_analysis/

Exploits

24

“Beast”

September 23, 2011

Man-in-the-Middle Attack Against SSL 3.0/TLS 1.0

Exploits - Beast

25

September 23, 2011It's the Browser Exploit Against SSL/TLS Tool, or BEAST:

The tool is based on a blockwise-adaptive chosen-plaintext attack, a man-in-the-middle approach that injects segments of plain text sent by the target's browser into the encrypted request stream to determine the shared key. The code can be injected into the user's browser through JavaScript associated with a malicious advertisement distributed through a Web ad service or an IFRAME in a linkjacked site, ad, or other scripted elements on a webpage.

Using the known text blocks, BEAST can then use information collected to decrypt the target's AES-encrypted requests, including encrypted cookies, and then hijack the no-longer secure connection. That decryption happens slowly, however; BEAST currently needs sessions of at least a half-hour to break cookies using keys over 1,000 characters long.

Exploits - Beast

26

The attack, according to Duong, is capable of intercepting sessions with PayPal and other services that still use TLS 1.0 which would be most secure sites, since follow-on versions of TLS aren't yet supported in most browsers or Web server implementations.

While Rizzo and Duong believe BEAST is the first attack against SSL 3.0 that decrypts HTTPS requests, the vulnerability that BEAST exploits is well-known; BT chief security technology officer Bruce Schneier and UC Berkeley's David Wagner pointed out in a 1999 analysis of SSL 3.0 that "SSL will provide a lot of known plain-text to the eavesdropper, but there seems to be no better alternative." And TLS's vulnerability to man-in-the middle attacks was made public in 2009. The IETF's TLS Working Group published a fix for the problem, but the fix is unsupported by SSL. http://www.schneier.com/blog/archives/2011/09/man-in-the-midd_4.html

Exploits - Beast

27

http://netifera.com/ Beast Demo: http://vnhacker.blogspot.com/2011/09/beast.html So we gave a talk and a live demo at ekoparty last week to show how BEAST exploits a weakness in SSL to decrypt secret cookies.

Please note that BEAST does not do any harm to remote servers. In fact, no packet from BEAST has ever been sent to any servers. We chose PayPal because they do everything right when it comes to server-side SSL, and that is good to demonstrate the power of BEAST, which is a client-side SSL attack. We reported the vulnerability to browser, plugin and SSL vendors several months ago (CVE-2011-3389).

New JavaScript hacking tool can intercept PayPal, other secure sessionshttp://arstechnica.com/business/news/2011/09/new-javascript-hacking-tool-can-intercept-paypal-other-secure-sessions.ars

http://www.theemailadmin.com/2011/09/keep-calm-and-carry-on/ http://www.theemailadmin.com/2011/10/vendors-respect-the-beast/

Exploits - Beast

28

How is Firefox Handling Beast

Oracle updates Java to stop SSL-chewing BEAST19th October 2011

Firefox developers said October 18, that they have no plans to keep the browser from working with the Java software framework now that Oracle has released a patch that prevents it from being used to decrypt sensitive web traffic.

In a blog post published in late September and updated on October 18, Mozilla recommends that Firefox users update their Java plug-in to lower their chances of falling victim to attacks that silently decrypt data protected by the SSL, or secure sockets layer, protocol used by millions of websites. Firefox developers had said previously that they were seriously considering disabling the Java plug-in as a way of preventing the exploit.

Exploits - Beast

29

How is Firefox Handling Beast

Oracle updates Java to stop SSL-chewing BEAST19th October 2011

Firefox developers said October 18, that they have no plans to keep the browser from working with the Java software framework now that Oracle has released a patch that prevents it from being used to decrypt sensitive web traffic.

In a blog post published in late September and updated on October 18, Mozilla recommends that Firefox users update their Java plug-in to lower their chances of falling victim to attacks that silently decrypt data protected by the SSL, or secure sockets layer, protocol used by millions of websites. Firefox developers had said previously that they were seriously considering disabling the Java plug-in as a way of preventing the exploit. http://www.theregister.co.uk/2011/10/19/oracle_patches_java/

Firefox devs mull dumping Java to stop BEAST attacks29th September 2011 http://www.theregister.co.uk/2011/09/29/firefox_killing_java/

Exploits - Beast

30

How is Internet Explorer Handling Beast

Microsoft Security Advisory (2588513)Vulnerability in SSL/TLS Could Allow Information DisclosureSeptember 26, 2011https://technet.microsoft.com/en-us/security/advisory/2588513

Recommended that websites follow Google's lead to favor the RC4 cipher while Microsoft engineers develop a Windows update to patch the underlying weakness.

Exploits - Beast

31

How is Google Chrome Handling Beast

Google preps Chrome fix to slay SSL-attacking BEAST21st September 2011

Google has prepared an update for its Chrome browser that protects users against an attack that decrypts data sent between browsers and many websites protected by the secure sockets layer protocol.

The fix, which has already been added to the latest developer version of Chrome, is designed to thwart attacks from BEAST

http://www.theregister.co.uk/2011/09/21/google_chrome_patch_for_beast/

References

32

How is SSL hopelessly broken? Let us count the waysBlunders expose huge cracks in net's trust foundation11th April 2011

Analysis Every year or so, a crisis or three exposes deep fractures in the system that's supposed to serve as the internet's foundation of trust. In 2008, it was the devastating weakness in SSL, or secure sockets layer, certificates issued by a subsidiary of VeriSign.

In 2009, it was the minting of a PayPal credential that continued to fool Internet Explorer, Chrome and Safari browsers more than two months after the underlying weakness was exposed.

In 2010, it was the mystery of a root certificate included in Mac OS X and Mozilla software that went unsolved for four days until RSA Security finally acknowledged it fathered the orphan credential.

http://www.theregister.co.uk/2011/04/11/state_of_ssl_analysis/

References

33

How is SSL hopelessly broken? Let us count the waysBlunders expose huge cracks in net's trust foundation11th April 2011

In 2011, it was the March revelation that unknown hackers broke into the servers of a reseller of Comodo, one of the world's most widely used certificate authorities, and forged documents for Google Mail and other sensitive websites. It took two, seven and eight days for the counterfeits to be blacklisted by Google Chrome, Mozilla Firefox and IE respectively, meaning users of those browsers were vulnerable to unauthorized monitoring of some of their most intimate web conversations during that time.

http://www.theregister.co.uk/2011/04/11/state_of_ssl_analysis/

Intrusion Detection 34

Advanced method hacks SSL:http://resources.infosecinstitute.com/mitm-using-sslstrip/

OpenSSL Security Advisory [8 February 2011] OCSP stapling vulnerability in OpenSSLhttp://www.openssl.org/news/secadv_20110208.txt

Vulnerability Summary for CVE-2011-0014 Original release date:02/19/2011Last revised:05/04/2011 Source: US-CERT/NIST

Overviewssl/t1_lib.c in OpenSSL 0.9.8h through 0.9.8q and 1.0.0 through 1.0.0c allows remote attackers to cause a denial of service (crash), and possibly obtain sensitive information in applications that use OpenSSL, via a malformed ClientHello handshake message that triggers an out-of-bounds memory access, aka "OCSP stapling vulnerability.“http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-0014

SSH Vulnerabilities

Intrusion Detection 35

sslsniff v0.7 released

By mastermind on 24 April 2011 in Tools with No Comments

This tool was originally written to demonstrate and exploit IE’s vulnerability to a specific “basicConstraints” man-in-the-middle attack. While Microsoft has since fixed the vulnerability that allowed leaf certificates to act as signing certificates, this tool is still occasionally useful for other purposes.

It is designed to MITM all SSL connections on a LAN and dynamically generates certs for the domains that are being accessed on the fly. The new certificates are constructed in a certificate chain that is signed by any certificate that you provide. http://www.vulnerabilitydatabase.com/2011/04/sslsniff-v0-7-released/

SSL Vulnerability Tools

EFF Says At least Four Certificate Authorities Have Been Breached Since June(October 27, 2011)According to research from the Electronic Frontier Foundation (EFF), atleast four certificate authorities have been compromised since June2011. The information was gathered by examining publicly availabledocuments that are required to be completed whenever secure socketslayer (SSL) certificate is revoked. There are more than 600 authorities.

The breadth of the situation raises questions about the long termsecurity of the technology. EFF Technology Projects Director PeterEckersley wrote in a blog that, "as currently implemented, the Web'ssecurity protocols may be good enough to protect against attackers withlimited time and motivation, but they are inadequate for a world inwhich geopolitical and business contests are increasingly being playedout through attacks against the security of computer systems".http://www.theregister.co.uk/2011/10/27/ssl_certificate_authorities_hacked/ https://www.eff.org/deeplinks/2011/10/how-secure-https-today

SSL Vulnerability Tools

Intrusion Detection 37

[Editor's Note (Liston):

The entire SSL Certificate system is foundedon the faulty premise that we should trust a corporation simply becausethey claim to be trustworthy. These companies have taken on a hugeresponsibility as a part of their business model, and have simply nottaken the kinds of precautions one should take when voluntarilypositioning oneself as the basket containing all the chickens.

(Murray): We do not have to have a perfect system of key management butvendors who want to offer services in the security space have to havegood security. Their brands are essential to their viability and theyare very fragile.]

SSL Vulnerability Tools

Intrusion Detection 38

Hacker Tool Launches DoS Attack Against SSL Server With One Laptop(October 25, 2011)

A group called The Hackers Choice has released a tool that can launch adenial-of-service attack against an HTTPS web server with just onelaptop over a DSL connection. The tool exploits the SSL renegotiationfeature to overwhelm the server. The Hackers Choice members recommenddisabling SSL renegotiation. One of the members points to a series ofissues with SSL that have become evident over the past few years,including a very high percentage of SSL-based sites that are notproperly configured and the problems inherent in "giving hundreds ofcommercial companies (so-called Certificate Authorities) a master keyto ALL SSL traffic."

http://www.darkreading.com/authentication/167901072/security/vulnerabilities/231901641/index.html?itc=edit_stub http://www.h-online.com/security/news/item/New-denial-of-service-tool-knocks-out-encrypting-servers-1366564.html

SSL Vulnerability Tools

Intrusion Detection 39

Google enables SSL by default for search. This is a good thing.

http://www.theregister.co.uk/2011/10/19/google_default_ssl/ http://m.wired.com/threatlevel/2011/10/google-search-https/

SSL Vulnerability Tools

Intrusion Detection 40

EFF reports on the security of SSL:

https://www.eff.org/deeplinks/2011/10/how-secure-https-today

SSL Vulnerability Tools

Intrusion Detection 41

More SSL woes from Mikko Hypponen: "We found a malware sample. Which was signed. With a valid certificate. Belonging to the Government of Malaysia.“

https://twitter.com/#!/mikko/status/136090183857745920 http://www.f-secure.com/weblog/archives/00002269.html

SSL Vulnerability Tools

Intrusion Detection 42

Older Exploits

SSL TLS

Intrusion Detection 43

SSL Vulnerability

November 5, 2009

A zero-day flaw in the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols could be exploited to launch a man-in-the-middle attack.  The discovery of this authentication gap vulnerability means that all affected libraries will need to be patched.  Representatives from leading technology firms have been meeting since late September to develop a new standard to fix the vulnerability.

http://www.computerworld.com/s/article/9140362/Scramble_on_to_fix_flaw_in_SSL_security_protocol?source=rss_securityhttp://www.theregister.co.uk/2009/11/05/serious_ssl_bug/http://www.h-online.com/security/news/item/Vulnerability-in-SSL-TLS-protocol-851478.htmlhttp://www.scmagazineus.com/Serious-vulnerability-in-SSL-discovered/article/157173/http://news.zdnet.co.uk/security/0,1000000189,39860592,00.htmhttp://www.darkreading.com/security/vulnerabilities/showArticle.jhtml?articleID=221600523

Intrusion Detection 44

SSL Vulnerability

July 29, 2009

Two researchers examining the processes for issuing web certificates have uncovered vulnerabilities that would allow an attacker to masquerade as any website and trick a computer user into providing him with sensitive communications. When a user visits a secure website, the browser examines the website’s certificate to verify its authenticity.

However, IOActive researcher Dan Kaminsky and independent researcher Moxie Marlinspike, working separately, presented nearly identical findings in separate talks at the Black Hat security conference on Wednesday. Each showed how an attacker can legitimately obtain a certificate with a special character in the domain name that would fool nearly all popular browsers into believing an attacker is whichever site he wants to be.

The problem occurs in the way that browsers implement Secure Socket Layer communications. “This is a vulnerability that would affect every SSL implementation,” Marlinspike said, “because almost everybody who has ever tried to implement SSL has made the same mistake.”

Intrusion Detection 45

SSL Vulnerability

Certificates for authenticating SSL communications are obtained through Certificate Authorities (CAs) such as VeriSign and Thawte and are used to initiate a secure channel of communication between the user’s browser and a website.

When an attacker who owns his own domain — badguy.com — requests a certificate from the CA, the CA, using contact information from Whois records, sends him an email asking to confirm his ownership of the site. But an attacker can also request a certificate for a subdomain of his site, such as Paypal.com\0.badguy.com, using the null character \0 in the URL.

The CA will issue the certificate for a domain like PayPal.com\0.badguy.com because the hacker legitimately owns the root domain badguy.com. http://www.wired.com/threatlevel/2009/07/kaminsky/

Trust Thy Certificate? New SSL Vulnerabilities Revealed At BlackHat 2009http://exchangepedia.com/blog/2009/07/trust-thy-certificate-new-ssl.html

Intrusion Detection 46

SSL Vulnerability

January 5, 2009

On December 30, 2008 a group of security researchers reported that by exploiting a known weakness in the MD5 hashing algorithm, they were able to create a rogue intermediate CA certificate under the "Equifax Secure Global eBusiness CA-1" root certificate, belonging to GeoTrust's RapidSSL brand.

Because all certificates issued by DigiCert use the SHA-1 standard, we are happy to reassure all our past, present, and future customers that these findings do not present any reason for them to worry about the integrity of their DigiCert SSL certificates.

The recent findings also highlight the problems inherent in the practice of issuing domain validated certificates, which can be issued automatically, with no human element in the verification process. Though frequently the companies that issue these "rapid," "instant," "low assurance," or "automated" certificates tout the speed with which SSL certificates can be issued, these certificates provide no assurance that the certificate belongs to a real company. http://www.digicert.com/news/2009-01-05-md5-ssl.htm

Intrusion Detection 47

SSL Vulnerability

Windows IE malicious SSL vulnerabilities

Windows, IE: incorrect validation of X.509

Description of the vulnerability

Internet Explorer uses the CryptoAPI of Windows to manage SSL/TLS certificates. Other applications use this CryptoAPI, which is impacted by two vulnerabilities. http://www.dslreports.com/forum/r23156194-Windows-IE-malicious-SSL-vulnerabilities

http://vigilance.fr/vulnerability/Windows-IE-incorrect-validation-of-X-509-9060

Intrusion Detection 48

SSL Vulnerability

September 28, 2007

A fix for a security flaw in OpenSSL that was released last year evidently did not go far enough. The update addressed a critical buffer overflow flaw in OpenSSL versions 0.9.7k and 0.9.8c; it limited the extent of the overflow but did not completely close the hole. The flaw could still be exploited in versions 0.9.7m and 0.9.8e to execute arbitrary code. The date on which updated versions of OpenSSL will be released is uncertain. http://www.heise-security.co.uk/news/96733

[Editor's Note (Ullrich): The OpenSSL library is widely used and probably one of the better reviewed pieces of open source software. This problem just shows how incredibly hard it is to identify and fix bugs late in the development process. ]