DEF CON Safe Mode - Joshua Maddux - When TLS Hacks You

Lots of people try to attack the security of TLS. But what if we use TLS to attack other things? It's a huge standard, and it turns out that features intended to make TLS fast have also made it useful as an attack vector.
Among other things, these features provide a lot of flexibility for Server-Side Request Forgery (SSRF). While past work using HTTPS URLs in SSRF has relied upon platform-specific bugs such as SNI injection, we can go further. In this talk, I present a novel, cross-platform way of leveraging TLS to target internal services.
Uniquely, these attacks are more effective the more comprehensively a platform supports modern TLS, so won't go away with library upgrades. It is also unlikely that the TLS spec will change overnight at the whim of a random security researcher. Instead, we need to walk through scenarios and dispel common assumptions so the audience can know what to look out for. Of course, the best way to do so is with demos!

[@eklypzn]

Thanks. I'm a student and I just did a report about using tls and certificates to circumvent IDS logs. This is definitely kicking it up a notch on the demo that I did. Cool stuff man. The more I hear about SSRF the more I wanna dive into it's implementation.

[@wrongtarget3015]

Lmaooooo. I just put my phone on gumchewing asmr playlists for hours

[@strikeout5]

Best name of the year! Also, amazing technique for blind ssrf.

[@denvercoulter]

Great talk!! This was very informative.

[@Philbertsroom]

Really impressive! Good job :)

[@pilvar1977]

Insane technique, love it!

[@mmr9216]

hi,when i reproduce it with curl/memcached,i got a curl error:SSL received a record that exceeded the maximum permissible length.How can i fix it

[@damienstevens4678]

Great talk thanks for sharing!

[@johndododoe1411]

I'll remember to key by IP+port in my next TLS client...

[@prakashvenkatraman6564]

First off, really cool discovery. I enjoyed the talk. But I don't get some things... 1. So the session id isn't used to key the TLS session in the session cache? 2. To return 35.x.x.x from the DNS server, wouldn't that mean the DNS cache already needs to be poisoned? Or does this mean the attacker needs to maintain a DNS resolution node themselves? 3. Finally, to have the rogue DNS server resolve localhost for subsequent request, doesn't the attacker need to either wait for the TTL to expire or poison the cache again? Also, why would the target box send the payload to itself if the session isn't keyed by session id? How does it know to use the payload from the previous session?

[@beaulac3215]

My understanding (pls correct if I'm wrong

[@ukcybercommand3373]

this is great 👍🏻

[@Sound_.-Safari]

Nice 👍🏼

[@automata8973]

dope.

[@kof2002x]

Nice technique