• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Ssl attacks
 

Ssl attacks

on

  • 7,004 views

null Mumbai Chapter October 2013 Meet

null Mumbai Chapter October 2013 Meet

Statistics

Views

Total Views
7,004
Views on SlideShare
6,683
Embed Views
321

Actions

Likes
0
Downloads
16
Comments
0

2 Embeds 321

http://null.co.in 311
http://staging.null.co.in 10

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Ssl attacks Ssl attacks Presentation Transcript

    • SSL ATTACKS Asif H. Balasinor Security Analyst NII Consulting
    • SSL ATTACKS • BEAST • CRIME • BREACH
    • BEAST •Browser Exploit Against SSL/TLS. •BEAST is a client side attack. It does not affect servers. •The BEAST mounts a chosen plain text attack on the data transmitted from a client to a SSL enabled web server. •The attack only works on Block ciphers such as AES, DES . Stream ciphers are unaffected by the attack
    • SSL BEAST PREREQUISTES • The SSL enabled web server must be running version of SSL 3.0 or lower or TLS 1.0. • It must support Block ciphers CBC. • The attacker must be able to mix his content with the SSL content. • The attacker must implement a Man-in-themiddle(MITM) so that he can observe the SSL traffic.
    • CIPHER BLOCK CHAINING
    • BEAST in action Consider the block x: • Cx-1 ⊕Tx Cx-1 is the cipher text of the previous block x-1 and the IV of the current block. Tx is the plain text password of the user. Cx = E(Cx-1 ⊕Tx) Cx is the resulting cipher text after encryption This will be the IV of the next block, say IV2.
    • The attacker injects the following in the SSL traffic in block (x+1) • IV2⊕ Cx-1 ⊕ P IV2 is the IV of the current block and the cipher of the previous block Cx Cx-1 is the IV of the previous block P is the attacker’s guess of the plaintext password of the victim.
    • • The XOR function looks like this (IV2⊕ Cx-1 ⊕ P)⊕IV2 • The two IV2s are XORed and cancel each other giving Cx-1⊕P Cx+1 = E(Cx-1⊕P) If, Cx= Cx+1, then P=Tx the attacker has successfully guessed the password.
    • BEATING THE BEAST • The most preferred way is to use TLS 1.1 or TLS 1.2. • If using a lower version of TLS or if the server is using SSL then use a stream cipher such as RC4.
    • CRIME • Compression Ratio Info-leak Made Easy • CRIME exploits the data compression feature of SSL and TLS. • CRIME attack works only when both the browser and server support TLS compression.
    • PREREQUISITES FOR ATTACK • The server must support SSL/TLS compression • The attacker must be able to mix his content with the SSL/TLS traffic • The attacker must be able to do a Man-in-themiddle(MITM) attack on the victim
    • CRIME INTERNALS • SSL/TLS compression use an algorithm called DEFLATE • DEFLATE compresses the HTTP requests by eliminating duplicate strings • Every instance of a duplicate string is replaced by a pointer to the first occurrence of the string • More redundant data will lead to more compression and thus smaller will be the length of the HTTP request
    • CRIME in action • Cookie: secret=341267 • The attacker knows that the session token contains Cookie: secret= • The attacker will keep changing the string after secret= and try to brute force the value
    • POST / HTTP/1.1 Host: importantserver.com Cookie: secret=341267 ... Cookie: secret=1 • DEFLATE recognizes that there is more than one occurrence of Cookie: secret= part and replaces the second instance with a small token that points to the location of the Cookie: secret= of the first string
    • The length of the request changes by 15 bytes
    • Brute forcing the session token:Byte1, Iteration 1 POST / HTTP/1.1 Host: importantserver.com ... Cookie: secret=341267 ... Cookie: secret=1
    • No additional change in length
    • Brute forcing the session token:Byte1, Iteration 2 POST / HTTP/1.1 Host: importantserver.com ... Cookie: secret=341267 ... Cookie: secret=2
    • No additional change in length
    • Brute forcing the session token:Byte1, Iteration 3 POST / HTTP/1.1 Host: importantserver.com ... Cookie: secret=341267 ... Cookie: secret=3
    • The length of the request decreases by 1 more byte. Thus we have successfully guessed the first byte of the session token. The attacker can repeat the process to guess the second byte of the request keeping the first byte constant.
    • Mitigations • CRIME can be defeated by preventing the use of compression
    • BREACH • Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext • BREACH happens to be more powerful than CRIME as it is not really possible to turn off HTTP compression.
    • PREREQUISTES FOR ATTACK The prerequisites of the BREACH attack are as follows: • The application must support HTTP compression • User input should be reflected in the response • The attacker must be able to do a Man-in-themiddle(MITM) attack on the victim • The HTTP response should have some secret information like CSRF token
    • RESPONSE NOT REQUEST • The attack works by injecting data into the HTTP request and analyzing the length of the HTTP responses • Any variation in length of the response indicates a successful guess
    • BREACH IN ACTION REQUEST: GET /stuff/form.php?id=token=attacker's_guess RESPONSE: <a href=“form2.php?token=csvfd123”>Go to form 2></a> …………………… <form target=https://example.com:443/stuff/everything.php? id=token=attacker’s_guess”>
    • The length of the request changes by 6 bytes.
    • BREACH IN ACTION REQUEST: GET /stuff/form.php?id=token=a RESPONSE: <a href=“form2.php?token=csvfd123”>Go to form 2></a> …………………… <form target=https://example.com:443/stuff/everything.php?id= token=a”>
    • No additional change in length
    • BREACH IN ACTION REQUEST: GET /stuff/form.php?id=token=b RESPONSE: <a href=“form2.php?token=csvfd123”>Go to form 2></a> …………………… <form target=https://example.com:443/stuff/everything.php?id= token=b”>
    • No additional change in length
    • BREACH IN ACTION REQUEST: GET /stuff/form.php?id=token=c RESPONSE: <a href=“form2.php?token=csvfd123”>Go to form 2></a> …………………… <form target=https://example.com:443/stuff/everything.php?id= token=c”>
    • The length changes by 1 extra byte. We have successfully guessed the first byte of the token
    • MITIGATIONS • Disabling HTTP compression • Separating secrets from user input • Randomizing secrets per request • Masking secrets (effectively randomizing by XORing with a random secret per request) • Length hiding (by adding random amount of bytes to the responses) • Rate-limiting the requests
    • Demo Video Links • Beast: http://www.youtube.com/watch?v=BTqAI DVUvrU • Crime: http://www.youtube.com/watch?v=gGPh HYyg9r4 • Breach:http://www.youtube.com/watch?v=pIKIX QNFplY&hd=1 •