Understanding Timing Vulnerabilities in Computing Systems
Explore the evolution of timing attacks in computing systems, from traditional crypt-analysis to modern web-focused techniques. Discover the gap in implementing security measures and how universities can bridge this disparity. Delve into the history, challenges, and implications of timing vulnerabilities, emphasizing the need for collaborative efforts between academia and industry.
Uploaded on Oct 01, 2024 | 0 Views
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
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 www.sensepost.com/blog
Agenda Who we are What this talk is about Background Timing vulnerabilities Timing channels Developers need our help Conclusion / Questions
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 :)
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
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
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 s onerror 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 <img onerror=xxxxx>
All that research == solved, right? In a perfect world, the pioneer work on timing should be reflected in today s systems
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?
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
Timing and 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. Felten s 2000 Timing Attack on Privacy.
X.S.R.T Cross Site Request Timing.. Simply: 1. Victim visits attackers website 2. JavaScript causes Victims browser to surf to http://www.facebook.com/friends.php?r 3. 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!)
X.S.R.T We introduced the concept of a base-page 1. Fetch page available to both Logged-in and Logged-out users (base-page) (X Seconds) 2. Fetch the page available only to Logged-in users (Y Seconds) 3. Calculate X/Y This gives us a latency resistant method of determining logged-in/logged-out status SquirrelMail - Login-1.jpg shell-1.jpg
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?
Web app provides an interface A secure box from a network hardening point of view.. Only a single search page exposed $search_term = $user_input; if($recordset =~ /$search_term/ig) do_stuff(); Picture 1
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)'`;}) Picture 1 shell-1.jpg
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)
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
Why are devs hurting so much? Deficient dev lifecycle Security testing != secure software Inadequate design Crypto Data flow Knowledge Spot the bug Fixing takes clue Crypto != basic knowledge Security fail
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
Prioritised wishlist for undergrads Secure coding techniques Never trusting user input Exposure to common attack vectors Realising the power of the return code 2. Threat modeling (attack trees etc.) Powerful pen-and-paper technique for exposing design flaws 3. Destructive testing Reward resilient applications 4. 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 5. Security libraries Introduction to common libs 1.
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)
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.
Questions ??? marco@sensepost.com www.sensepost.com/blog
