Side-Channel Data Leaks and Software-as-a-Service
Security Architect, IntraLinks
POSTED ON May 19, 2010
What can be inferred from this headline that an IT trade publication recently ran about a study conducted by Microsoft and Indiana University: “SaaS Apps May Leak Data Even When Encrypted, Study Says”?
1. There was a study conducted on SaaS apps leaking data.
2. The study stated that SaaS apps leak data.
3. The study says SaaS apps do not sufficiently protect data.
4. A combination of options one, two and three.
5. The study primarily pinpointed security threats to misconfigured Web applications depending on data they process.
The correct answer, according to most people, would naturally be option four. However, the answer would change if you actually read the recent research paper from Microsoft and Indiana University on side-channel data leaks. In this post, I will address the confusion that this paper may cause. It describes how all Web apps, when they operate on data with low entropy (or Shannon entropy, which quantifies the information contained in a message, usually in bits) may leak data despite information being encrypted. A crude example of low entropy data is the selection of months on a Web page as there are only 12 pre-defined choices.
This particular paper starts: "With software-as-a-service becoming mainstream, more and more applications are delivered to the client through the Web." As this follows the headline at the top of the research, which refers to side-channel leaks in Web applications, it can easily lead to the conclusion that the issue is related to the SaaS model.
The paper, however, subsequently goes on to show that the issue is not specific to SaaS as a delivery mechanism. The following statement later on in the research makes that clear: "The root cause of the side-channel vulnerability in Web applications is actually some of their fundamental features, such as frequent small communications, diversity in the contents exchanged in state transitions, and stateful communications." Essentially, researchers use some advanced math to show that if you know what to expect from the Web server in response to user action on the browser, it is possible to infer the content of encrypted data flow.
The threat of side-channel leaks is real but I will comment on the assumptions of the research and leave room for conclusions to the reader. For starters, an attacker would need to have access to the HTTPS traffic, which is not trivial but is also certainly not impossible. Furthermore, an attacker would need to know or, at least be able to easily deduct, how a specific response would look on encrypted form.
Another generalization that, in my opinion, does not apply to most business-class Web applications, is the assumption of low entropy in data that those applications process. This assumption is particularly wrong for IntraLinks since the critical data we process consists of file names and file content — hardly low entropy information. The threat of side-channel data leaks is inherent to Web application since both data flows and control flows are open to eavesdropping on public networks. In my opinion, it is, however, extremely unlikely to be exploited, given the level of familiarity required with the application under attack.
The answer to this threat was in the study itself, but for reasons unknown to me, the authors did not propose it. The problem, as they state it, is the predictability of the encrypted data when streaming ciphers are used in SSL communications. Configuring the SSL to support only block ciphers will address the issue without a single code change. Best of all, this solution is application-agnostic and can be applied overnight. So, if one is concerned with side-channel data leaks, they should disable support for streaming ciphers either in their user browser or on the web servers of the business applications they use to address the issue once and for all.
In conclusion, the answer to the question that I posed at the beginning of my blog is number five — the study primarily pinpointed security threats that some Web applications are susceptible to. It is unfortunate that the upfront part of Microsoft and Indiana University’s research was misleading and could be construed as the SaaS model introducing a high security risk in leaking data even when encrypted communication channels are used. I believe that there is a minimal risk of side-channel data leaks in the Web applications, SaaS or not, when there is high entropy and properly configured SSL is used.
January 27, 2012 09:10 AM
Thanks, Mushegh, for elaborating on the SaaS issue. After reading your post, I thought you might be interested in our Hype or Ripe blog. We post about industry news/topics, and ask IT leaders to share if they think the issue is "ripe" or just "hype." http://www.ict-log.us/8IsGk
January 15, 2012 05:37 AM
zdn2Fd , [url=http://owqdgihsuxsb.com/]owqdgihsuxsb[/url], [link=http://habnzuwzshsy.com/]habnzuwzshsy[/link], http://qrrdlsnhpmpn.com/
May 28, 2010 11:38 AM
Dear Robin, thank you for the time and interest you have taken to review my blog post and provide insightful comments. My main point was, and you seem to agree with it, that SaaS delivery model does not introduce the side channel data leak as a new threat - it is inherent to all web applications. I have not tried to trivialize the threat as I agree with you that it is real and serious. The issue is that after the clever articles with catchy titles a whirlwind of activity usually ensues that does not improve the security for certain applications. As I stated - the combination of high entropy and proper encryption effectively addresses the issue and there is no need to spend resources (or, as some like to refer to it poetically - ’scarce security buck’) modifying applications that are not susceptible to the threat. Maybe I was too happy that the application I am responsible for is immune to this particular threat because of the nature of the data it processes and the proper configuration of the in-transit encryption. Your comments are to the point about some consumer-oriented applications that process sensitive data. It is extremely difficult to bolt on security for applications that were designed without data confidentiality as a primary requirement. Using technologies, like AJAX you mentioned, without fully considering security implications, only exacerbates the issues. I have not mentioned these issues on purpose to keep the size in check. Your comments fill in for that omission and for that I am appreciative.
Lastly, allow to respectfully disagree with your minor point (6) as I never made the mistake you are attributing to me. The title you refer to as incorrect for the research paper is the catchy headline that prompted me to start typing. There is a direct link (from the University of Indiana site) to the research paper in the next paragraph in case people would be interested to read the full publication. Please keep reading and commenting – your insights are very interesting.
May 21, 2010 07:15 PM
Unfortunately, the problem is much more nontrivial than it appears to be, as concluded by this blog.
(1) Eavesdropping indeed is a limitation of the threat. However, it IS the adversary model taken by most secure web app: otherwise, one does NOT need HTTPS.
(2) Switching to block cipher does not solve the problem, as indicated in the paper. More often than not, the traffic features are simply too distinctive to be hidden by rounding individual packets to a certain size.
(3) Low entropy inputs often come from the practice of using AJAX to input sensitive data, which become increasingly a trend: e.g., check Google Health. Also, some low entropy inputs seem hard to avoid: think about online tax app:
if your income goes above some value, your browser needs to get a new form from the server; otherwise, it makes no network connection. Unless you decide to move the whole program logic to the client side, this is hard to avoid.
(4) Fundamentally, the problem comes from the gap between the traffic features of web app, which links to the app's internal states, and the encryption, which does not care about the app's semantics. If this problem is not taken care of, the problem will haunt the SaaS and cloud computing for the years to come. Just for example, the current online health IT systems and Tax software obviously are subject to the attackers they are supposed to defend against (online eavesdroppers).
(5) The fundamental solution is to fix the problem during the program development process, which needs a lot of efforts.
(6) Finally, a minor point: "SaaS Apps May Leak Data Even When Encrypted, Study Says" is not the title of the research. Check here: http://oakland31.cs.virginia.edu/program.html, under Session 4.