1 / 26

On Timing and Teaching

On Timing and Teaching. marco slaviero SensePost 2009. Who we are. SensePost Formed in 2001 Security assessment services to finance, industrial, mining, telecoms Written a few papers.. Spoken at a number of conferences Contributed to a handful of books Done some Training

carsyn
Download Presentation

On Timing and Teaching

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. On Timing and Teaching marcoslaviero SensePost 2009

  2. Who we are.. • SensePost • Formed in 2001 • Security assessment services to finance, industrial, mining, telecoms • Written a few papers.. • Spoken at a number of conferences • Contributed to a handful of books • Done some Training • www.sensepost.com/blog

  3. Agenda Who we are What this talk is about Background Timing vulnerabilities Timingchannels Developers need our help Conclusion / Questions

  4. Main thrust • Message from users • There is a gap between what implementers know, and what they face with respect to security • Industry is failing to address this • Universities are uniquely positioned to help • For fun, let’s frame it with with respect to timing attacks • Received significant academic attention • Allows for new demos :)

  5. Stepping Back a Little An illustrious history of side channel attacks on computing systems • differential power analysis • hardware • EM radiation emission analysis • hardware • timing analysis • software/hardware

  6. Traditional Timing • Timing has received lots of attention over the years in the area of crypt-analysis • Kocher [1996] • 1st local results against RSA and DH • Brumley & Boneh [2003] • Derived partial RSA over network due to weaknesses in OpenSSL • Bernstein [2004] • Derived full AES key across custom network clients • Percival [2005] • L1 cache access times could be used on HT processors to derive RSA key bits

  7. Web Time • Felten & Schneider [2000] • early results on timing and the web • focused on privacy • browser cache snooping • dns cache snooping • Grossman & Niedzialkowski [2006] • SPI Dynamics [2006] • Both released a JavaScript port scanner using JS’sonerror feature. Implicitly uses timing attacks (connection timed out, hence it is closed) • Bortz, Boneh & Nandy [2007] • Direct timing (valid usernames, hidden gallery sizes) • Cross Site Timing • <imgonerror=xxxxx>

  8. All that research == solved, right? In a perfect world, the pioneer work on timing should be reflected in today’s systems

  9. Making the jump Username enumeration can be a significant issue *really* useful in certain circumstances But what if the application returns a standard error page?

  10. Happened last week… Application could authenticate users itself (local DB) or against a configured AD Local lookup is fast AD lookup is across the network

  11. Timing and Privacy • Felten’s2000 Timing Attack on Privacy. JavaScript portscanning Using CSS to determine if links were visited. Ed Felten in 2000 examined the dangers of Java and Timing to users Privacy by timing load times.

  12. X.S.R.T • Cross Site Request Timing.. • Simply: • Victim visits attackers website • JavaScript causes Victims browser to surf to http://www.facebook.com/friends.php?r • JavaScript determines load time, to decide if user is (or isnt logged in) (> 50ms - user logged in) • Problem: This doesn’t work the same for U.S victims and .ZA victims! (.za adds 100ms just by default!)

  13. X.S.R.T • We introduced the concept of a base-page • Fetch page available to both Logged-in and Logged-out users (base-page) (X Seconds) • Fetch the page available only to Logged-in users (Y Seconds) • Calculate X/Y • This gives us a latency resistant method of determining logged-in/logged-out status

  14. So serious? • C’mon, those are binary decisions, where’s the real harm? It’s inference only. • (Apart from SPAMmer mining) • They were timing *vulnerabilities* • What about using timing as a channel?

  15. Web app provides an interface A “secure” box from a network hardening point of view.. Only a single search page exposed

  16. Perl timing • Regex injection (?{`uname`;}) • We can also make execution pause (?{`sleep 20`;}) • Now vary the pause and infer data (?{`perl -e 'sleep(ord(substr(qx/uname/, 0,1)))'`;}) • Finally, pause in one branch of a conditional and extract a bit at a time (max 8*pause) (?{`perl -e 'sleep(substr((unpack('B32',pack('N',ord(s ubstr(qx/ls/, 0, 1))))), 24,1) * 2)'`;})

  17. So, for all the research, we still find timing issues and can communicate over timing channels (Of course, this IS NOT limited to timing work)

  18. Feel the application development pain (architect on down) • Not exposed to security thinking in formative years • Devs struggling to bolt-on the knowledge • Battling to counteract the latest exploit • Always one step behind • Fundamental knowledge clearly available in academic circles

  19. Why are devs hurting so much? Security fail • Deficient dev lifecycle • Security testing != secure software • Inadequate design • Crypto • Data flow • Knowledge • Spot the bug • Fixing takes clue • Crypto != basic knowledge

  20. Where security education should occur • Premise: • We depend on well-written programs • Security is fundamental to well-written programs • Not equivalent to learning libraries or frameworks • I argue: • Industry has failed at this • As important as compilers / graphics / AI • Undergraduate level • Defensive thinking techniques • Practical examples help, but goal is NOT to train hackers or push exploits

  21. Prioritisedwishlist for undergrads • Secure coding techniques • Never trusting user input • Exposure to common attack vectors • Realising the power of the return code • Threat modeling (attack trees etc.) • Powerful pen-and-paper technique for exposing design flaws • Destructive testing • Reward resilient applications • SDLC modifications • For the software engineers, realisation that a sole security check before deployment is like reading a manual on the Waltz on the morning of your wedding • Security libraries • Introduction to common libs

  22. How can we help? • Have a fair idea of what’s going wrong • Improving security education could be a joint effort • Your expertise is in security theory, education, curriculum development etc. • We (industry) break systems, giving current relevant insight • Contact us with ideas (we have a few of our own)

  23. Conclusion. Timing attacks received much academic attention We still find them day-to-day, something is missing Security not core to developer education Include security in undergrad! Really, talk to us, we want to get involved.

  24. Questions ???marco@sensepost.comwww.sensepost.com/blog

More Related