]HackingTeam[ rject Mass interception of connec?ons What? interception TOR interception MackingTeami thorny path ]Hacki?gTeam[ Common Issues Public Key Pinning avoids rogue CA sign certs Wacki?gTeami Common Issues Google and Facebook actively search for rogue CA signed certs (no more governmental signing: France, India) Common Issues HSTS enforces on a variety hardcoded website (no more SS strip) Wacki?gTeami Common Issues HTTPS Everywhere enforces https and could send rogue certificates to the EFF SSL Observatory Common Issues No solution for snif?ng TOR availal by now on the market ]HackingTeam[ The Solution ]Hacki?gTeam[ How? Place an in-Iine Active Probe in the network ]Hacki?gTeam[ How? Exploit the target transparently by injecting a browser-based exploit while he’s surfing the web (http) How? Insert a trusted root CA certi?cate(s for MITM Redirect ?rst TOR hop ]Hacki?gTeam[ How? and Decode the traf?c! ]Hacki?gTeam[ More in depth ]Hacki?gTeam[ Deployment phases Identification Inoculation/Marking SSL MITM (only for SSL) Decoding Maintenance Identification Phase Uniquely identify a target on the internet (cookies, browser strings, etc.) Create a profile for each target to know if it’s exploitable Avoid exploiting the same target “too much” Avoid exploiting a target with “problematic” AV Inoculation Phase HTTP man-in-the-middle (transparent proxy) Browser based exploits (all platforms) Local to root exploits (sandbox escape) Methods to insert root CA cert(s) into the keystore Methods to divert TOR first HOP Marking Phase Insert a “watermark” in target’s environment to uniquely identify “inoculated” targets during SSL connections Setting different TOR’s SOCKS password SSL MITM Phase Transparent proxy performing SSL MITM only on “marked” targets Serve the right certificate Avoid exposing fake certs Avoid checks to detect fake certs Decoding Phase A good partner with a consolidate decoding technology ]Hacki?gTeam[ Maintenance Phase Automatic test to check if the certs invalidated (Customer side) ]Hacki?gTeam[ Maintenance Phase Automatic check for exploits effectiveness Automatic check for inoculation phase (HT side) ChaHenges ]Hacki?gTeam[ Identification Phase Targets using multiple browsers Targets behind routers (NAT) Targets behind a TCP Proxy Targets changing IP address often Inoculation Phase Build or Buy exploits for several platforms Write shellcodes to insert root CA certs Write shellcodes to modify TOR environment Marking Phase Marking the target cipher suites list Using client-side certificate (both good but fragile) Marking Phase lP-to-Target Mapping Less reliable Same problems as Identi?cation WackipgTeaml Marking Phase Mixed approach is possible fake https image request host file modification Marking must survive browser/os upgrades! SSL MITM Phase Find an appliance to handle the inlii traf?c (no single point of failure) MackingTeaml SSL MITM Phase Pay attention to Extended Validation certificate Pay attention to EFF SSL Observatory Pay attention to Trust Assertion for Cert Keys (TACK) Decoding Phase Where do we send sniffed traf?c? ]Hacki?gTeam[ Feasibility Matrix Windows Exploit IE FF Chrome OSX Linux iOS Android Safari Firefox Safari Browser Chrome Chrome Chrome Chrome Not needed (per user) Root Cert Finger (hello) Finger (client cert) IE FF Chrome IE FF Chrome Safari Firefox Safari Browser Chrome Chrome Chrome* Chrome Safari Firefox Safari Browser Chrome Chrome Chrome** Chrome * Does not trust local CA certs ** Does not support client certs Weak Points Heavily relies on browser remote-toroot exploit availability TOR manipulation is possible only through clear-text traffic Browser/OS vendors may change parameters we use for identification Weak Points Certificate revocation leads to target loss (impact reduced by using several certificates) AV may detect our shellcodes (…btw no target loss) Mass deployment increases the risk of leaking And ]Hacki?gTeam[ Strengths Our solution bypasses certificate pinning since it uses a custom CA “manually” installed!!! Our solution bypasses HSTS Strengths Our solution bypasses active MITM detection (France should have known it) Our solution is the only way to intercept TOR traffic at the moment Decisions ]Hacki?gTeam[ Hardware for the probe iBypass TAP General purpose server Modifying an existing SSL appliani MackingTeami Decoding the traffic Once decrypted the traffic must be decoded: Forwarding to an existing monitoring center using standard protocols Create a turn-key solution with a “passive” partner Resources ]Hacki?gTeam[ Time First Minimal Demo: 2 months First POC: 9 months First Deployment: 15 months ]HaokingTeam[ Human 2 Exploit/Shellcode Developers 1 Network/Probe Developer 1 ISP SysAdmin (consultancy) 2 Backend/Logic Developers 1 Tester In house but allocated Future development ]Hacki?gTeam[ Other over-SSL protocol Support for imaps, pops, etc. ]Hacki?gTeam[ RCS integration Keep a DB of exploitable targets Exploit them again to install RCS Integration through the RCS Console (…or HT Monitoring Center) Layer 3 MITM Just mangle the handshake and forward the rest of the connection to improve performances SSL TLS key dump Just save the SSL keys and pass it to an SSL offload decrypter for maximum performances Technical details ]Hacki?gTeam[ General Architecturl I J?