SSL overview
•Transferir como PPTX, PDF•
1 gostou•2,682 visualizações
A quick overview of SSL cipher suites, common vulnerabilities associated with them and how to remediate.
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (9)
Semelhante a SSL overview
Semelhante a SSL overview (20)
Mais de Todd Benson (I.T. SPECIALIST and I.T. SECURITY)
Mais de Todd Benson (I.T. SPECIALIST and I.T. SECURITY) (9)
Último
Último (20)
SSL overview
- 2. Introduction • • • • • SSL communication review Common SSL vulnerabilities Remediation recommendations Testing Demo
- 4. Secure Communications • • • • • Using SSL (SC-8, SC-9) Proper SSL Certificates (SC-17) Strong SSL Ciphers (SC-13) Secure implementation of SSL (SC-13) Forcing SSL for sensitive data and forms (SC-8, SC-9) • Disallowing mixed mode HTTP and HTTPS
- 5. SSL Cipher Suites • SSL configuration issues appear in Host Assessments, Application Assessments and Validation Reports • Usually a systems administrators’ issues, not a developer • Lately there is no clear solution • Pick your poison
- 6. SSL Versions • SSL V1 – Never publicly released • SSL V2 – Released 1995 – Not secure • SSL V3 – Released 1996 – Can almost be made secure – Is not FIPS compliant (FIPS 140-2) • TLS 1.0 – Released 1999 – Can almost be made secure – Better than SSL V3 • TLS 1.1 – Released 2006 – Still thought to be secure • TLS 1.2 – Released in 2008 – Still thought to be secure
- 7. Handshake
- 8. Handshake Details 1. ClientHello • TLS Protocol Version, Random Number, List of CipherSuites, Suggested Compression Method, sessionID 2. ServerHello • TLS Protocol Version, Random Number, CipherSuite, Compression method, sessionID 3. Certificate 4. ServerHelloDone 5. ClientKeyExchange • PreMasterSecret, public key or nothing 6. ChangeCipherSpec 7. ChangeCipherSpec 8. Application Data
- 10. Cipher Suites • Key exchange/agreement – RSA, Diffie-Hellman, ECDH, SRP, PSK • Authentication – RSA, DSA, ECDSA • Bulk Ciphers – RC4, Triple DES, AES, IDEA • Message Authentication – MD5, SHA, MD4
- 11. Part 2 Common SSL Vulnerabilities
- 12. ATTACK! Common vulnerabilities • Weak Ciphers Suites Supported – Key length > 128 bits • TLS Compression – CRIME • SSL v3 and TLS v1.0 – BEAST • RC4 Cipher Suite Supported – Theoretically broken • Padding Attacks – Lucky Thirteen
- 13. Ciphers Suites Supported with key lengths less than 128 bits • Description: SSL ciphers with key lengths of less than less than 128 bits are considered to be easier to exploit than ciphers with key lengths greater than 128 bits. • Impact: A successful exploit could compromise the confidentiality of user credentials and allow an attacker to gain unauthorized access to the web application.
- 14. TLS CRIME Vulnerability • Description: Compression Ratio Info-leak Made Easy (CRIME) is an attack on SSL/TLS. CRIME is a side-channel attack that can be used to discover session tokens or other secret information based on the compressed size of HTTP requests. • Impact: An attacker can make the client generate compressed requests that contain attacker-controlled data in the same stream with secret data.
- 15. Browser Exploit Against SSL/TLS (aka BEAST) • Description: BEAST is short for Browser Exploit Against SSL/TLS. This vulnerability is an attack against the confidentiality of a HTTPS connection. That is, it provides a way to extract the unencrypted plaintext from an encrypted session. The initialization vector includes a random string that is XORed with a plaintext message prior to encryption. • Impact: The BEAST provides an attack vector for stealing user session cookies.
- 16. SSL RC4 Cipher Suites Supported • Description: The RC4 algorithm, as used in the TLS protocol and SSL protocol, has many single-byte biases, which makes it easier for remote attackers to conduct plaintext-recovery attacks via statistical analysis of ciphertext in a large number of sessions that use the same plaintext. If plaintext is repeatedly encrypted (e.g. HTTP cookies), and an attacker is able to obtain many (i.e. hundreds of millions) ciphertexts, the attacker may be able to derive the plaintext. The average running time for this attack is on the order of 2000 hours. • Impact: For an authenticated HTTP session, the unknown value which the attacker is trying to get is the session ID or cookie. This value is preceded by standard HTTP header information. If the cookie value is in the first 256 bytes of plaintext it will be exposed during the attack.
- 17. Padding Attacks: Lucky Thirteen • Description: A cryptographic timing attack against MAC to break the CBC algorithm. Affects all versions of TLS at the time of it’s release (February 2013). • Impact: This is a highly complex attack that does not require authentication. It would allow for unauthorized disclosure of information.
- 19. Remediation: Weak Cipher Suites • Weak Ciphers Suites Supported – Disable Cipher Suites with keys < 128 bits, NULL, Export keys and Anonymous Diffie-Hellman • Set Apache directive SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:!LOW
- 20. Remediation: CRIME • TLS Compression (CRIME) – Disable Compression • Set Apache (2.2.4) directive SSLCompression off
- 21. Remediation: BEAST • SSL v3 and TLS v1.0 (BEAST) – Enable Cipher Suite Ordering • Add Apache directive SSLHonorCipherOrder On – Negotiate RC4 Cipher Suite first • Set Apache directive SSLCipherSuite RC4SHA:ALL:!ADH:!EXPORT:!SSLv2:!LOW
- 22. Remediation: RC4 • Weak RC4 Cipher Suite Supported – Disable RC4 Cipher Suites • Set Apache directive SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:!LOW:-RC4-SHA:-RC4-MD5
- 23. Remediation: Lucky Thirteen • Padding Oracle Attacks – Switch to using RC4 CipherSuites • Set Apache directive SSLCipherSuite RC4SHA:ALL:!ADH:!EXPORT:!SSLv2:!LOW – Dude, seriously, WTF???
- 24. TLS Browser Support Browser TLS 1.0 TLS 1.1 TLS 1.2 Chrome 0–21 Yes No No Chrome 22–current Yes Yes No Chrome 29 (dev) Yes Yes Yes Firefox 2–current IE 6 IE 7–8 IE 8–9 IE 9 IE 10 Yes Disabled Yes Yes Yes Yes Disabled No No Disabled No Disabled No No No Disabled No Disabled Opera 5–7 Yes No No Opera 8–9 Yes Disabled No Opera 10–current Yes Disabled Disabled Safari 4 Yes No No Safari 5 Yes No No Safari 5–current Yes Yes Yes
- 25. Part 4 Testing
- 26. Testing NMAP!!!! nmap –sV <IPADDRESS> nmap --script ssl-enum-ciphers -p <PORT> <IPADDRESS> And Nessus too, of course
- 27. Test Cases for developers • How developers can test for it – Ciphers on the client openssl ciphers|sed ‘s/:/nr/g|sort – CipherSuites ./cipher.sh | grep YES – Compression openssl s_client -connect 156.132.142.11:12321 -tls1 – Protocol use browser and enable TLS 1.1 and TLS 1.2
- 28. Part 5: And now… Demo Time!!!!!!!
- 29. Overview When testing SSL-TLS • Test that SSLv2 is disabled • Test that SSLv3 is disabled (And Possibly TLS 1.0) • Test that compression is disabled • Test that cipher suites with key lengths of less that 128 bytes, ADH, NULL or EXP are disabled • Test that MD5 hash is disabled
- 30. Questions?
- 31. What’s coming up? • • • • Sept 24: SAR writing examples - Ryan Oct 8: Benchmark Wizardry - Eric Oct 22: Python for pentesting- Philip Nov 5: All your ssh are belong to us, pwning with proxychains - Anthony & Frank • Nov 19: Application context & discovering XSS without <script> - Todd • Dec 3: Vulnerability database solutions - Derek • Dec 17: Clickjacking
Notas do Editor
- This presentation will cover SSL communications, some common SSL vulnerabilities, remediation recommendations and easy ways to test web sites for these vulnerabilities. It will conclude with a short demo of how to test and how to remediate on Apache web servers.
- Part one will be a review of SSL communications. First a brief history of SSL. Second we will cover the steps of an SSL handshake when communication is initiated by the client. Lastly will be a quick overview of cipher suites and how they are used in SSL.
- Strong SSL ciphers are a vital part of secure web communications and the focus of this presentation. While some of what we cover will also be secure implementation of SSL, the focus is the testing and proper implementation of SSL cipher suites. The three areas of focus for strong SSL cipher suites are the SSL Version, the algorithms used and the use of strong cipher suites.
- SSL cipher strengths are issues that we test for in both host assessments and web application assessments. SSL is not usually configured in a secure manner by default and are commonly identified vulnerabilities during assessments. These are always a result of improper configuration of SSL on the web server.Lately SSL vulnerabilities have grown, as if often the case with security vulnerabilities. As we will discuss later, sometimes the remediation for the vulnerabilities are the opposite of each other. Until such a time that wide-spread use of TLS 1.2 and/or fixes by developers, we will have to “pick our poison” when it comes to remediation.
- Shortly after the World Wide Web came into existence (1990) and it was embraced beyond academia, it became apparent that there was a need for secure communications between web clients and web servers. In 1994 SSL v1 was developed by Netscape but never released. In 1995 SSL v2 was released but had a number of security flaws, which lead to the quick release of SSL v3 in 1996.TLS 1.0 was defined in 1999 as an upgrade to SSL v3. TLS 1.1 was released in 2006 to add protection against CBC attacks. In 2008 TLS 1.2 was released, mainly to replace MD5-SHA-1 with SHA-256. Today, roughly 27% of web servers support SSLv2, 99% support SSLv3 and TLS 1.0 while only 11% and 13% support TLS 1.1 and 1.2 respectively.
- When a client initiates contact with a web server, it performs a handshake. This establishes an agreement between the client and the server on how to communicate securely. The communication begins with the typical SYN -> SYN/ACK -> ACK where the client indicates the desire to communicate over SSL. Then, using SSL the client Introduces herself indicating how she would like to communicate. The server responds, taking suggestions from the client and chooses one, and introduces himself. He then shows his ID and indicates that he is done. The client provides a codebook for their secret language and signals that all further communication will be in that secret language. The server responds in kind.
- What really happens is this: The client sends a ClientHello, which includes the highest SSL protocol version it supports, a random number (later used in generating the secret key), a list of cipher suites, a suggested compression method and, if it a resumed handshake, a sessionID. The server responds with a ServerHello, which includes the SSL version that will be used, a random number, the cipher suit that will be used, the compression method and, if it is a resumed handshake, the sessionID. If it is not a resumed handshake, the server also may send it’s certificate followed by a ServerHelloDone. If it is not a resumed handshake the client then initiates the ClientKeyExchange. This concludes the asymmetrical encryption portion. The server sends a ChangeClientSpec, indicating that everything will now but done using the ”master secret”. The client sends a ChangeClientSpec, indicating that it too will now use the “master secret” from now on. The web page is now sent to the client.
- Within the initial ClientHello is a list of cipher suites that the client supports. It is from this list that the server will choose a suite to communicate.What is a “cipher suite”? Glad you asked.
- A cipher suite is a suite of encryption algorithms used for secure communications. It includes an algorithm for key exchange, such as RSA and Diffie-Hellman, authentication, such as RSA and DSA, bulk ciphers, such as RC4 and AES and message authentication, such as MD5 and SHA.It is the algorithms that the server supports where we often find weaknesses. IN some cases it is because of known weak ciphers, such as DES and in others it may weak because the HTTP/SSL implementation of that cipher is weak, such as CBC ciphers.
- In part 2 we we will cover common cipher suite and SSL configuration vulnerabilities and attacks that are just recently being discovered.
- Part 3 covers remediation recommendations for the common vulnerabilities. As we will discover, some of the recommendations are in direct conflict with others. Meaning if you remediate for one, you will make yourself vulnerable for the other. In these instances the system owner will have to decide which risk she is willing to live with.
- While some vulnerabilities are present in all versions of TLS, some are specific to TLS 1.0. As we can see from the matrix above, on the client-side implementation is slow for TLS 1.1 and TLS 1.2. Only two browsers support TLS 1.2 by default, the development version of Chrome and Safari 5 on OS X, a vast majority of modern browsers have TLS 1.1 and 1.2 disabled by default.On the server side it seems to me more drastic, with many popular web servers not yet supporting TLS 1.1 and 1.2 by default.
- Part 4 will cover how to test for the vulnerabilities we covered. Included are both automated tools and more “manual” methods of discovery.
- Both NMAP and Nessus will check for the vulnerabilities previously described. NMAP is sometimes favored for it’s ease of use, quickness and cost.But Nessus is great too.
- For developers who do not have or can not install third party software such as NMAP or Nessus, there are a couple of options using tools already at their disposal…provided they have a version of Linux/Unix/OS X on hand.First it is a good idea to enumerate the cipher suites on the local system. The host can only test against ciphers that it has present. List the ciphers on the host in a nice, readable format, type opensslciphers|sed ‘s/:/\n\r/g’|sort at the command line.Once you know the suites you will be testing from, you can list ciphers on the web server by running the cipher.sh script (located from us) by typeing ./chiper.sh <ipaddress>:<port>|grep YES. This will list the cipher suites enabled on the web server.To check for compression, use openssls_client –connect <ipaddress>:<port>|grep CompressionTo test the protocol version, you must use a browser that supports TLS 1.1 and 1.2 and has them enabled and browser the web site. Click on the padlock and verify the version of TLS that is being used. (Remember, web servers will use the highest version that is supported by both the browser and the server)