B-Sides San Francisco

Why are we still vulnerable to side-channel attacks? (and why should I care?)

2013 B-Sides San Francisco Talk Summary Series B-Sides San Francisco

This was a great talk given by Jasper Van Woudenberg, from Riscure.

Whenever I attend these talks, I always include a couple that are pure indulgence to keep me awake, sustain my enthusiasm, and broaden my knowledge. At DefCon there was one about using quantum physics for random key generation and another one using GPUs for massively parallel password cracking. Schuyler Towne’s locks talks are always a joy, and this talk fits nicely into that category.  I really should say, “pure indulgence” is not entirely correct. While it is true that there will never be a one-domino causality chain from any of these indulgence talks I mentioned here to any security assessment code I might write for NTO, the stimulation of thought does seep into product and some things oblique to a particular software product like physics and numerical analysis do have a way of popping up in algorithms I write for the product.

What are side-channel attacks?

side channel attack

So first things first… I expect at least some of you, like me, had to look up “side-channel attacks.”  There have been side channel attacks in the news recently, like the one last year where, as published in ThreatPost, a side channel attack was used to steal a cryptography key from co-locoated virtual machines. Wikipedia defines a side channel attack as “any attack based on information gained from the physical implementation of a cryptosystem, rather than brute force or theoretical weaknesses in the algorithms(compare cryptanalysis).” Side channel attacks have to do with measuring fluctuations in hardware and then intuiting the behaviour of an algorithm running on that hardware. Or, monitoring something related to the information you are pursuing and then doing further analysis of the monitored information to tease out the desired information.

Obtain RSA key by monitoring power usage, Passive methods

The first example the speaker addressed was ascertaining an RSA key by monitoring power usage of the CPU executing the algorithm. The RSA encryption algorithm bottom lines to a sequence of squares and multiplies. But the multiplies are executed only for 1-bits in the key.  So what you see in the power graph is a sequence of spikes with time differentials between them that are proportional to whether or not a multiply was executed in that iteration and from this one can piece together the key.  The countermeasure is to do a dummy multiply when the key bit is zero so each iteration does a square and multiply. This of course increases the execution time of the algorithm but it is also not a sure thing; the dummy multiply is still slightly different from the actual multiply though you do have to try harder to get the data.  With this and other approaches the speaker discussed, a common denominator is that if you have alot of time with the device in question, you can simply do massive amounts of iterations and overwhelm subtleties with statistics.

Clarifying Statistics and Algorithms

Interesting related side note:  I knew a guy on a previous job who did astronomical photography involving multiple all-night exposures of the subject being photographed (a galaxy in his case).  It turns out that the more pictures you take of the same subject and then combine later, the more purturbances like atmospheric distortion are averaged out and the image becomes clearer.  Statistics in general works like this. The persistent factors become ever more emergent and pronounced and the error ever smaller the more samples you take.  Sometimes the algorithm such as ECDSA may power spike in such a way that you do not directly get the variable you are after but you get one of the variables in the formula and so with a bit of algebra and several iterations you can get what you are after. Also such things as the algorithm using 24 bit numbers and dealing with them 8 bits at a time can be used to analyse the power profile of the algorithm. Interestingly, the speaker said that even if the algorithm used 16 bit numbers, using an 8 bit approach gets you not as good but still usable correlations.

Side channel attacks – Active methods

That fairly accounts for the passive methods he discussed.  He then went on to discuss active methods.  These include glitching supply voltage, glitching the clock, and glitching the chip itself using powerful optical spikes.  A well placed supply glitch introduces errors in the execution of the algorithm that can yield information as to the data it was dealing with when it errored.  Clock glitches can cause the algorithm to skip instructions such as branches that can also produce useful data in the power signature.  Optical glitches target specific parts of the chip with electromagnetic interference (light is an EM wave) which, again, can yield information via how they affect the running of the algorithm.  Countermeasures to these techniques include inserting random waits before comparisons and doing multiple comparisons and requiring the results to be the same (being wary of compiler optimizations, i.e. turn them off).

As you would expect, these too can be circumvented but they make the attacker’s job harder.  The data one gets from glitched execution of a crypto algorithm can in some cases be analysed by lattice methods.  As the speaker said, he didn’t have time to fully elucidate this but in summary, one calculates a lattice and then calculate closest vector within that lattice (this is admittedly a glossover paraphrase of an admitted glossover to begin with) and it can be used to reconstruct crypto keys from the glitched and power-signatured algorithm.

This talk was most enjoyable to someone like me.  In security, it is always valuable to be made to think about unexpected ways to acquire information since of course the more clever of the attackers are doing that.  We have all noticed how computers have become orders of magnitude faster and more efficient.  What once took hundreds of dollars worth of Cray time and about as much electrical power can now be done on a $300 computer for “too cheap to meter” electrical power.  If you have ever designed anything around a 6502 chip, you know those old chips consume whatever power they consume nearly constantly regardless of what they are doing.  This is not to say the methods elucidated in this talk would not work on a 6502 but modern chips that throttle themselves according to what they are doing greatly help these methods along compared to the old chips.  The biggest software threat to security in the Apple-II days was getting a virus.  On a computer that was not connected to the internet or any other communications net, not running services that listen for commands to execute, and barely fast/capacious enough to run the one program it was running, one didn’t worry about security much.  But as we obsess on CSRF, XSS, SSL, SQLI, etc., we must remember that hardware has evolved with software and therefore hardware vulnerability has also evolved with software vulnerability.


Twitter SSL

Secure SSL, “Tales of Transport Layer Security at Twitter” from 2013 B-Sides San Francisco

SSL++; Tales of Transport Layer Security at Twitter

I am happy to have attended this talk, at 2013 B-Sides San Francisco, by @jimio, a Twitter employee, on SSL security and how to create a secure SSL site. The title was  “SSL++ : Tales of Transport Layer Security at Twitter” and it was definitely a good way to wake up and start the day. Twitter was able to switch to exclusive-SSL and netted out to a faster site with SSL. In this talk, he discussed why and how.

Twitter SSL


First point:  I am indebted to the speaker for prompting me to do a bit of reading about the CRIME and BEAST SSL/TLS attacks. I am primarily a software architect but of course at each job on my resumé I have picked up very interesting domain knowledge and crypto is full of things like CRIME and BEAST that do not occur to you as you use or design a crypto algorithm.  To summarize for the benefit of those who need it (and presage a little some of the similar inject-then-diagnose approaches to acquiring crypto keys I will be writing about w.r.t. other talks I attended), the CRIME attack works by injecting content into TLS compressed headers (or indeed it is useful for any encrypted compressed information) and then observing the resulting size of the compressed information relying on the fact that the compression algorithm economizes on repeats.  That is, if your injected content causes the size to increase then it is probably not in the original content.  If the size does not increase (or very little), it probably is in the content.  So one can guess and hone in on the compressed content without having to know the crypto key.  BEAST works by injecting content that is 15 bytes, then 14, then 13, … down to zero so that at each iteration the last byte of the content is the only unknown byte and one only has to brute force 256 combinations rather than 2^128.  This reminds me of Schuyler Towne’s talk about how to get into those Base-10 suitcase locks.  Typically a session cookie is being pursued with this attack.

Transport Layer Security at Twitter

Okay, there’s the preamble. The balance of this talk was about not so much about exotic SSL vulnerabilities like those discussed above, but simply vulnerabilities stemming from not thoroughly using SSL.  Sometimes this can mean the login page is in SSL (lovely, protects password) but the cookie is in cleartext (bollocks).  So it needs to be SSL everywhere.  Twitter instituted such a change at one point and gave customers the ability to opt out and about 1% did.  However, even when you think you are fully SSL, there are still CSRFish things people can do like <img src=”http://twitter.com”> which can prompt GETs over HTTP thereby revealing the user’s cookie even if the response is innocuous.  The speaker discussed man in the middle attacks though not of what you the reader are likely to have been hearing about lately but the simpler variety of intercept the SSL and broker it as HTTP to the server and thereby read all the content unencrypted.  Again, the countermeasure here is absolutely airtight SSL on the site.  And then there are things like #!/dir or anything similar where everything past the # does not get sent to the server and is instead processed with client side script.  That one actually transcends the thesis of this talk.  Certainly it is an SSL issue but it is a whole-bunch-of-other-things issue as well.  Prior to working in information security, I worked at a company where we were doing loads of this kind of stuff in a web application and also calculating cookies in client-side jsp (!)… 13 years ago… more naive times.  The management hired a security firm to audit and that is how we found out about this stuff.  We weren’t developing an E-commerce site, it was more of an internal-use site but of course one wants to be secure even in that environment.

Every request should be SSL

The overall goal is to get all requests internal and external to your site to be SSL.  Obviously you can control the former but not fully the latter.  So you can do the best you can on the latter.  For example, canonical linkrel always with an https.  Google’s crawlers respect this but Bing and Yahoo don’t.  There is some partisanship apparently that it is unseemly to use linkrel in this fashion (it is not canonical to use canonical this way :-)?) but as you can imagine, the speaker rejects such arbitrary religious arguments as do I.  Then there is the issue of people not typing fully qualified links with protocol into their browsers (it’s been a while since 1992 after all).  Of course you expect any browser to GET http://www.twitter.com but interestingly Twitter apparently convinced Chrome developers to put an “if (it is twitter) {assume HTTPS}” line in their code.  More measures to encourage clients to request nothing but SSL include the <strict-transport-security> tag and CSP.

Pros & Cons of Cert-Pinning

At this point he spoke about cert-pinning which I wrote up extensively with regard to another talk so suffice to say, it is a good idea wherever feasible.  Mobile apps were the focus of that other talk and the disadvantage to cert pinning was redeployment of all in-the-field apps to use the new baked-in cert when the cert needs to be changed.  These would be things like standalone games that communicate with a server.  So if you are building a web application that is exclusively used as such and is therefore inherently self-deploying, that concern is lessened though I suppose it requires savvy users/browsers to maintain client-side trusted  certs and not capriciously ok new ones.

Performance issues with encrypted SSL, Not Really

The speaker concluded by addressing performance considerations of going exclusively encrypted.  In short, he said optimize other areas of your website to buy back the performance lost by going SSL, which is not that significant to begin with.  The advantages far outweigh the liabilities of performance.  Further, his company (Twitter) is a case in point.  They cleaned up their code as part of the switch to exclusive-SSL and netted out to a faster site with SSL.

I’m finding that a common denominator in a lot of these talks is “the more things change the more they stay the same” and possibly “there is one (web developer) born every minute.”  The exotic sexy (in the nerd sense) vulnerabilities command our attention as we want to stay ahead of the bleeding edge but the old vulnerabilities (particularly as they combine with new ones) keep resurfacing and constant vigilance implies remembering them as much as it does staying abreast of new developments. Our CEO, Dan Kuykendall likes to refer to it as Where’s Waldo (link to blog post) or Leisure Suit Larry. They same old things just keep popping up in new places.

Is your scanner like the emperor's new clothes?

New Report: SQL Injection vulns are hidden in web services (learn how to find them)

In this new report, The Widening Web Application Security Scanner Coverage Gap in RIA, Mobile and Web Services: Is Your Scanner like the Emperor’s New Clothes?, Dan Kuykendall and Matthew Cohen of NT OBJECTives cover the nine new technologies most overlooked by automated scanners. These technologies are hiding common vulnerabilities like SQL Injection. This report details each technology: what they are, why it is hard for automated scanners to find vulnerabilities in them and what you can do about it.

Read this report to learn how to secure these technologies:

  • AJAX
  • AMF – Flash remoting
  • Google Web Toolkit (GWT)
  • JSON
  • REST
  • XSRF/CSRF Tokens
  • Web services that power mobile applications

Download this research paper now to get all the facts and start finding & remediating vulnerabilities in these technologies!