User:Grobinson/Notes Black Hat 2013

TLS Secrets

Introduced with a history of SSL/TLS and discussed confusion over using terms interchangeably. Unless you're still using IE 6, you're using some version of TLS to secure your browser communication.

Mythbusting for not deploying TLS:

1. Performance cost (is not a good excuse)
   1. "Handshaking is expensive"
      1. For symmetric encryption, cipher choice is of paramount importance, but good ciphers add negligible performance costs.
      2. Asymmetric crypto will always be expensive regardless of cipher (RSA/DSA/ECDSA). Can optimize somewhat with smaller keys, it's not smart to do that too much.
         1. Solution: handshake once... and resume sessions.
         2. Interesting note: TLS handshake has 4 steps (could do it in 3) as a DoS mitigation - client has to do something expesnive before the server does.
   2. If there's a high packet loss it adds a significant amount of latency (more round trips, since packets need to arrive in order for a security protocol)

One solution for session resumption was Session IDs. We can make this stateless (better for servers with lots of traffic) with TLS Session Tickets (RFC 5077). This stores an arbitrary-size, encrypted blob on the client side.

Forward Secrecy

• Attacker cannot decrypt a conversation even if he records the entire session and subsequently steals the associated long-term secrets
• The session keys are not derivable from information stored after the sessions concludes
• Achieved with Diffie Hellman. 2048-bit DHE has significant performance overhead, but ECDHE is neglibible especially considering the benefits.

Problems with the RFC:

1. Key exchange used to protect the tickets is underspecified ("beyond the scope of this document")
2. Ticket lifetime is not given a maximum, may be > 24 hours

This leads to major flaws in various implementations. For example, in OpenSSL (used by Apache and nginx):

• tickets are enabled by default
• encrypted using AES128-CBC
• Integrity protected using HMAC-SHA (128 bit key!)
• Keys are stored in the SSL_CTX
• No rekeying

Conclusion:

• No point in using a ciphersuite better than AES128-CBC
• Your PFS interval is the program's lifetime! That could be months or even years.

Apache actually makes things even worse than the OpenSSL default by allowing the user to save the ticket keys to a file, so it's actually possible to do worse for the PFS interval than the default of the program lifetime.

Demo of toolsthat can be used to attack running server processes with ptrace to extract the master encryption keys; this in turn can be used to decrypt individual user's session tickets on the wire, which in turn contain the Master Session Keys that can be used to recover plaintext.

Whitepaper, Slides

PDF Attack: A Journey from the Exploit Kit to the Shellcode

Exploit kits! Attack vectors in descending order of popularity: Java > PDF > Flash

Uses PythonV8 to step through malicious JS and output whenever code is eval'ed.

Slides, Code

Tor... All the Things!

"Firefox might not be the best browser to use with Tor... had 6x the number of reported vulnerabilities than IE in the past two years." Source was not given in talk, but I found it in the whitepaper.

Ideal Solution:

1. Transparently route all TCP and DNS traffic through Tor
2. Do not allow any network traffic onto the Internet unless it goes through Tor
3. Do not require typical user to install an unfamiliar OS
4. Do not allow malware to circumvent Tor tunnel and communicate directly with the Internet (heavily implies that this is somehow more likely to happen with Firefox)
5. Do not require extra hardware or extra VM's

Existing non-ideal solutions:

1. Hardware based transparent proxies.
   1. require extra hardware
2. Software-based transparent proxy. Tor doesn't support it on windows since it requires /dev/pf.
3. Tails (non-windows)
4. Torcap (windows-based)

Their software, "Tortilla", creates a virtual machine, then creates a new virtual network adapter that runs everything through Tor. It also has some nice features, like blocking all traffic that can't be proxied over Tor.

Whitepaper, Slides

Truncating TLS Connections to Violate Beliefs in Web Applications

Use previously understood TLS truncation attack against several well-known web applications and demonstrate resulting logical flaws that can be exploited. They attack:

1. Helios e-voting systems
2. Microsoft Live Accounts
3. Google Accounts

While TLS provides integrity guarantees for individual connections (packets are not tampered with, and arrive in the order they were sent), it does not provide integrity guarantees across multiple connections. Hence, it is possible to exploit packet ordering issues between connections. Browsers commonly maintain multiple connections for each active site (to load content in parallel).

Adversary model: full control of the network

Whitepaper, Slides

Pixel Perfect Timing Attacks

Twitter: @pdjstone

Timing information to discover info in a "black box"

Browser Black Boxes

• Same Origin Policy: Site A cannot read or modify data from site B
• Can still make requests to other sites
  • <img src="">
  • <script src="">
  • XHR
• But cannot (usually) read results

This talk:

• Link colors (private info from browser history)
• Iframes - load 3rd party site inside your own

Browser restrictions stop Javascript from "seeing" this info.

Example timing attack: page requests Is the user logged in to Gmail? Time request to <img src="mail.google.com">.If logged in, there are more redirects until you land in your inbox vs. just getting a login page.

Timing Attack Problems:

• Network latency, jitter
• Unknown baseline
  • How long does the server take to respond?
  • How fast is the user's connection?
  • How fast is the user's computer?
• Unstable local environment
  • Other running programs
  • Other open browser tabs
  • Other network traffic

To overcome:

• take multiple measurements and average
• calibrate against known target
• wait until idle

Part 1: Sniffing History

Long long ago... set styles on a and a:visited. Check getComputedStyle Fuss at "history sniffing" because used in wild by adult sites, ad networks.

Bring it back with a timing attack.

requestAnimationFrame

• like setTimeout, but linked to refresh rate of display
• registers a fn that is called just before the next frame is painted
• will be called back ~60 times/second
• we can use this to determine the rate of animation

Slow motion video of searching google in IE. Blue.. frame frame frame... purple.

If there's a complicated text effect, like a text shadow, the frames with repaints should take longer.

(My laptop died at this point... but the second part of the talk was incredible! Timing attacks with SVG filters that can do OCR for sensitive information from pages)

Whitepaper

The Factoring Dead: Preparing for the Cryptopocalypse

Sets the stage by describing historic failure of tech industry to address large-scale, structural problems.

Thesis: huge leaps in solving Discrete Logarithm Problem (DLP) in last 6 months. These developments have parallels to the past. There is a small but real chance that both RSA and non-ECC DH will soon become unusable. Ecosystem currently cannot support a quick pivot to ECC.

"We want this room to become the seed of change." Comparison to huge asteriod hitting the earth with 10% chance.

Asymmetric Crypto 101 Common primitives:

1. Diffie-Hellman - 1976 - Secure key exchange
2. RSA - 1977 - encryption, signing
3. Eliiptic Curve Crypto
   1. Suite B (NSA)
   2. GOST (Russian)

Diffie Hellman overview

• establish shared secret over public, untrusted network
• relies on the hardness of discrete log

RSA

• Depends on the hardness of factoring

Elliptic Curve

• Depends on the hardness of the elliptic curve discrete logarithm problem (ECDLP) - not the same as the classic DLP

NIST Recommended Key Sizes: Symmetric < ECC < RSA (way larger) Corresponds to the difficutly of solving the underlying problems.

• Generic algorithms
• Specific algorithms (make use of group representation)

L(0) = polynomial L(1) = exponential

Rapid progress:

1. Joux published L(1/4) algorithm to solve DLP in small characteristic fields
2. Barbulescu et al (solves largest DLP so far)
3. Joux solves DLP in pseudo-polynomial time in small characteristic fields!

No new mathematics, just a pile of clever tricks.

There is no obvious jump which use finite fields with larger characteristic YET.

Discrete Log and Factoring problems are closely related, and historically have advanced mutually.

DLP solution breaks DH, ElGamal, and DSA If it jumps to factoring, RSA is broken too EC unaffected (still requires exponential time algorithms)

Scary because there's little implementation work required, short order from academic disclosure to real attacks.

• Widespread active and passive attacks against live and recorded TLS
  • PFS not necessarily the panacea
• Failure of code-signing and update mechanisms
  • How do you fix your software?
• Failure of PGP, S/MIME and most end-to-end encryption
• Almost total failure of trust on the Internet

We need to move to ECC, and quickly.

Right now it's all we have. We need more research into alternatives.

• Lattice cryptography (patent-encumbered)

In 2005, NSA released Suite B set of interoperable standards. Suite A - classified algorithms used for encrypting top secret algorithms. We know the names but nothing else.

Suite B:

• Encryption algorithm (AES-256)
• Key exchange algorithm (Elliptic Curve DH)
• Digital signature algorithm (Elliptic Curve DSA)
• Hashing algorithms (SHA-256 and SHA-384)

ECC is patent-encumbered! Certicom owns them. Recently sued Sony for using it in Bluetooth (we saw how well that worked for them).

DNSSEC Interestingly, Russian gov would not allow RSA to sign .ru, required ECC via GOST (their version of Suite B).

Recommendations:

• Make ECC easy to use
  • see NaCL's box() and unbox()
• Update documentation to push people away from RSA.
• Eat dogfood (use ECC yourself whenever possible).
• If you're a browser vendor, TLS 1.2 needs to be a P1 feature. Note: they said this in the talk, but this is not correct. TLS >= 1.0 supports EC.
  • Only IE 11 and Chrome 29 support (both pre-relesae)
• If you're a CA cert, let us buy an ECC cert.
• Blackberry - license the patents!

Slides

Dissecting CSRF Attacks & Defenses

Confused, session-riding deputy.

• Cross-origin requests are a core part of how the web works
• Effective CSRF only cares about generating a request that affects server-side context

Fundamentally, we want to distinguish between a user-intended actoin and a browser-initiated one.

Problems with current countermeasures:

HMAC requires a strong secret. People often use defaults, dumb secrets. You can search Github.

BH 2012 - PRNG: Pwning Random Number Generators openssl rand 32 -hex

CSRF cloaks bad design

• POST/GET method ignorance
• Password change mechanisms that don't require a password
• Missing barriers that rely on authentication to perform actions
• Loose coupling of authentication, authorization, and session.

Partial solution with AJAX and CORS - "XHR brokering with custom headers". If there's a custom header added, browser preflight (part of CORS) essentially prevents CSRF.

Doing CSRF with CSP report-uri. Can get a POST! But spec is pretty good at limiting what can go into the body. So you can POST with a specially crafted query string but no POST body.

SOS (proposal)

Syntax like CSP, behavior like CORS

• simple behavior with fewer chance of mistakes
• leverages preflight

With set-cookie, apply a CSP 3 policies:

1. 'self' - trigger pre-flight, cookie included only from same origin unless given exception
2. 'any' - trigger pre-fligt, cookie included unless given exception
3. 'isolate' - no pre-flight, no exceptions. Cookie only included from same Origin.

Same idea as CSP: you can craft a malicious URL, but the browser won't allow the session cookie to go along.

Summary:

• use HSTS
• use CORS
• maybe check out SOS

No links were provided on the Black Hat archive page.