To improve performance, particularly for mobile users, many websites have started caching app logic on client devices via HTML5 local storage. Unfortunately, this can make common injection vulnerabilities even more dangerous, as malicious code can invisibly persist in the cache. Real-world examples of this problem have now been discovered in third-party “widgets” embedded across many websites, creating security risks for the companies using such services – even if their sites are otherwise protected against attacks. Striking a balance between security and performance can be difficult, but certain precautions may help prevent an attacker from exploiting local storage caches.

Background

Throughout the history of web development, people have found ways to use and abuse various technologies beyond their intended purposes. Before CSS gained widespread support, many developers created complex layouts with HTML tables. Now that browsers provide far more presentation-layer tools, one can recreate complex images using only CSS. Such tricks can at times be very helpful in overcoming the limits of a browser-based environment, but they can also inadvertently create security issues.

One feature commonly classified as part of HTML5 is local storage, a method for saving content on a visitor’s device that offers more space and flexibility than previous options (such as cookies). While intended as a client-side analogue to database storage, local storage has increasingly served another purpose: code caching. If a web app routinely requires large blocks of JavaScript, it can avoid downloading those chunks every time a visitor returns to the app by saving a copy of them in local storage. This can provide a significant performance boost, particularly on mobile devices, where bandwidth and typical caches can be much more limited.

Local Storage Attacks

However, this approach opens new possibilities for attacking the app. If the local storage can be compromised, an attacker could inject malicious code that persists in the client-side cache. This payload would then be executed by the web app each time a user opened the site – even if they’d previously closed the browser. In fact, eradicating such code can be quite difficult, and the victim website might not even be able to detect an ongoing attack. Artur Janc, a security engineer at Google, outlined these issues in a talk last December (video) detailing many of the dangerous ramifications they present, but as Janc notes, such an attack was also previously described by a paper from researchers at Berkeley (PDF) in May 2010.

Given the restrictions on access to a site’s local storage, modifying code saved there would nearly always require another vulnerability in the app as an initial attack vector. However, just one entry point for injecting code in a page would be enough to change the cache, and such problems tend to be quite common across the web. Many of these vulnerabilities (described as cross-site scripting, or XSS) are “reflected”, in that they only change a particular request for content, but using local storage automatically makes them capable of launching persistent attacks. Essentially, caching code in HTML5 local storage actually makes any existing cross-site scripting vulnerabities more dangerous.

And as influential researcher Michal Zalewski also noted a few months before Janc’s presentation, “if content from the compromised origin is commonly embedded on third-party pages (think syndicated ‘like’ buttons or advertisements), with some luck, attacker’s JavaScript may become practically invincible”. In this age of mash-ups, data from a variety of sources are often mixed together, creating implicit trust relationships that may have significant effects on the security of an app. When a developer includes third-party JavaScript on his or her site, that code has the same capabilities as any other script on the page. Of course, modifying a static file on a remote server is generally not possible, even if cross-site scripting issues are present. But what if a third-party script from a site with XSS problems also stored code in local storage?

Vulnerabilities in the Wild

As it turns out, this is no longer a hypothetical situation. Apture was a start-up that provided pop-up boxes for exploring content related to highlighted terms in a page. The service garnered praise from various tech media outlets, and the company was bought out by Google a few months ago. Just over a week ago, Google shut down the embedded search functionality, which was still in use by several sites after the acquisition. Apture is one example of a third-party “widget” service that used local storage code caching – and a page on the same domain as those scripts had a reflected XSS vulnerability which could be used to inject malicious code in the cache. This code would then be executed in the context of the site using Apture, meaning the problem with Apture’s service affected the security of many sites across the web.

And while Apture’s widgets are now offline, another service still operating on high-profile sites was recently found to have a similar issue (though in this case, scripts were not executed from the original site’s origin). This problem has been reported and is currently being addressed by the service’s engineers.

Reducing Risk

Ultimately, there isn’t a simple way of avoiding this type of vulnerability while still getting the performance gains of client-side code caching. Another new HTML feature, application cache, is actually geared towards precisely this use case and would be harder to compromise, but it can create UI warnings in some browsers, such as Firefox. (Such warnings are a good practice, but may be unwanted for third-party widgets.) Ideally, any data in local storage should be treated as untrusted, even if it’s just content instead of code. But if local storage is used for scripts, it should be accessed from a domain that only serves static files. This will help reduce the likelihood of an XSS vulnerability that would have direct access to local storage, though the overall structure of an app should be taken into account to prevent indirect access as well. Newer browsers also support features such as sandboxed inline frames and Content Security Policy that could help limit the impact of embedded widgets if they became compromised.

I think it’s important to note that many smart people, including those behind Apture, have used local storage for caching app logic – even Google and Bing use a similar technique on their mobile sites – and that in theory, this method should not make a website less secure. And for many web developers, it may not be immediately obvious why local storage data should not be trusted. This is another case where a clever trick that serves its primary goal very well has unintended consequences when considered in a broader context. It’s also an example of possibly making trade-offs which balance usability with risk. Understanding these conflicts and connections is part of what information security is all about – and what we do at Gemini every day. As browser features continue to expand and sites continue to integrate services from other domains, it’s likely we’ll see many more examples of security issues evolving in complexity – and organizations will need to adapt to such changes while still reducing risk.

Special thanks to @0x6D6172696F, @lcamtuf, @theKos, and @kkotowicz for their help with this research!

Technical Details

For a site to use Apture widgets, the owner included a bit of JavaScript on their pages:

<script id="aptureScript">
(function (){var a=document.createElement("script");a.defer="true";
a.src="http://www.apture.com/js/apture.js?siteToken=XXXXXXX";
document.getElementsByTagName("head")[0].appendChild(a);})();
</script>

This dynamically loaded an external script hosted on apture.com with a site token specified. The external script included various parameters, such as title, logo, and search URLs that are associated with the account identified by the token. This code then loaded another script based on the user’s browser which actually began setting up the framework for Apture to integrate with the site’s content.

For browsers that support it, HTML5 cross-document messaging then came into play. The Apture script inserted an inline frame into the page that loaded a file from cdn.apture.com. A callback function allowed this iframe to pass messages back to the original window context where the script is running (the non-Apture site). This iframe then loaded the actual app logic and passed the code back to the original site via the cross-document messaging interface.

At this point, you’re probably wondering why Apture didn’t simply load the app logic as another script in the original page; in fact, that’s precisely what Apture did if the browser didn’t support newer HTML5 features. But Apture’s iframe setup allowed them to take advantage of another HTML5 innovation that made their service load much faster. Web storage functionality provides the localStorage object, a place to save key/value data on the client which allows for more space and flexibility than cookies. This storage is persistent across browser sessions, but is specific to each domain and access to it is restricted by a same-origin policy.

Apture used a localStorage object for cdn.apture.com not only to save data, such as an ID for tracking users, but to actually cache their app logic code. If the cdn.apture.com iframe detected that this cache already existed, it would simply load the code from localStorage rather than issue another HTTP request for the 272KB worth of JavaScript – saving time and bandwidth. Apture introduced this functionality in January 2011.

But how does one load code from localStorage? For Apture, with this line in the cross-domain callback function:

window.execScript ? window.execScript(f) : window.eval(f);

Seeing code such as this should immediately raise red flags in the mind of any web developer. Those familiar with browser security may have heard the adage that “eval is evil”, and it certainly applies here. The eval function (or the analogous execScript function also seen above) treats its input as valid JavaScript and simply executes it in the current window’s global context. If an attacker can send malicious code to the function, that code will also be executed – a class of vulnerabilities known as cross-site scripting (XSS).

In Apture’s case, though, the code came from the cdn.apture.com storage, so one might assume it can be trusted – in theory, only pages from cdn.apture.com can modify the localStorage cache. But once again, the power of cross-site scripting demonstrates that many seemingly trustworthy data sources are still potential avenues of attack. The presence of any XSS on a cdn.apture.com page, including reflected XSS, would allow an attacker to execute code in that domain’s context and thus modify the localStorage object.

As it turns out, Apture did have an exploitable XSS vulnerability. The cdn.apture.com domain actually mirrored www.apture.com, including a topic page that loaded a topic title from the URL path and a YouTube video ID from a GET parameter. Both of these values were included in the page without being escaped to prevent XSS. This example URL includes a script that appends “alert(document.cookie)” to the app logic in localStorage:

http://cdn.apture.com/search/xss?yt=%22%3E%3Cscript%3Eif%28
window.x%21%3D1%29%7BlocalStorage%5B%27app-49971756%27%5D
%3DlocalStorage%5B%27app-49971756%27%5D%2b%22alert%28
document.cookie%29%3B%22%7Dwindow.x%3D1%3C%2fscript%3E

The window.x logic ensures that the code only executes once, since the parameter appears in the topic page multiple times. In an actual attack, more code would likely be needed, as the specific localStorage key includes a version number that could change depending on the user. This does not stop the attack, however, as the correct version can be loaded by the script before making changes to localStorage.

Once this vulnerability is used to insert attack code into localStorage (e.g. if the above URL were loaded in an invisible iframe on an attacker’s site), visiting any site that had Apture’s widgets would cause the attack code to be loaded from the Apture iframe and executed in the context of the non-Apture site. And since this is essentially an example of DOM-based XSS (the code is loaded dynamically on the client side), requests sent to those sites’ servers would not include any XSS fingerprints, such as <script> in a GET or POST parameter. In summary, the localStorage code caching turned one reflected XSS vulnerability on Apture’s site into persistent, client-side XSS across all domains using their service.

One trick was to hide the variable in a closure. In JavaScript, every function has its own local scope. If you define a variable within a function block, that variable is distinct from one defined in the global scope. In a way, the variable is hidden from code executed in the global scope, though the function can provide a gatekeeper method to access it. Consider this block of code:

document.cookie = "secret";

var Safe = function() {
    var cookie = document.cookie;
    this.get = function(magicWord) {
        if (magicWord === "please") {
            return cookie;
        }
        return null;
    }
}
window.Safe = new Safe();

document.cookie = "";

alert(document.cookie);
alert(Safe.get(""));
alert(Safe.get("please"));

The first alert returns nothing – document.cookie has been set to an empty string. The second alert only returns null, given the if statement in the definition of Safe.get. But with the third alert, the statement return cookie gets executed – and that statement is in the local scope of the function, so it returns the cookie variable defined in that scope, which is “secret”. This is the concept of a closure – the local variable of the function lives on as it was defined in that context.

Initially, this may seem to be a good defense against cross-site scripting, since the power of XSS comes from all a page’s scripts executing in the same scope. But as entries in the challenge demonstrated, a script has many resources for attacking itself. For instance, the challenge included code that checked whether a function requesting the secret variable was a mouse click event initiated by the user. That last bit came from checking the isTrusted property on the event, which should tell you whether the click came from a script or from the user.

But in JavaScript, new objects are created by cloning a model object called a prototype. If you change a particular prototype, any new variety of that object will inherit the changes you made. In this case, changing the isTrusted property of a mouse event’s prototype to always be true meant any spoofed clicks generated automatically by a script would fool the protective code and retrieve the secret value.

With each new bypass, Mario updated the code with new protections to block them. Eventually, he created a Firefox-specific version that essentially rewrote the entire page to get rid of the original Document Object Model and all its loopholes. If you’re interested in reading more about other bypass techniques and the challenge’s implications for client-side filtering, researcher Krzysztof Kotowicz has an excellent write-up that covers more details. But the challenge is also worth studying as a way of understanding more about web scripting and XSS. I certainly learned more about closures and event spoofing by tackling the puzzle, and it helps illustrate the difficulties of trying to protect against code running in the same origin and same scope. We may be moving towards DOM features that provide enough security to block even client-side attacks, but for right now, any untrusted script has myriad ways of overcoming client-side protections.

This is a pretty sweet hard drive, but there are a few annoyances that I think can be improved upon. I was unable to test a few things just due to the time I could devote to this, the fact that I need to return the drive in working condition, and that I don’t have access to some specialized hardware to test timing attacks.

The drive is FIPS 197 validated – aka, uses AES according to NIST.

You can check out Apricorn’s site for the specs and details, but what you see on the product site is pretty much what you get. The drive draws power from your USB port, so you’ll need a powered port. The drive came with an adapter (1 USB to 2 USB) if one of your USB ports doesn’t provide enough power. I had no issues with power on my MacBook Air, but I did on my office desktop since all USB ports were already taken – easily solved with a powered USB hub.

The drive comes formatted for Windows, but my mac helpfully formatted it for me once I said “yes” to “Use this as a Time Machine drive?” The quick start sheet in the box also provides Mac formatting instructions. The actual manual is already on the drive, and my mac helpfully erased it for me during formatting. However, the “Support” section of the website has the full manual available for download. At first, you really want to have the full manual available (and not on the drive).

The drive has the capability to have an administrator PIN and up to 9 “user” PINs. Knowledge of the admin PIN can wipe the user PINs, but not change them – only users can change their PINs. The different PINs do not allow access to different parts of the drive. All PINs have access to the entire drive. PINs can be anywhere between 6 and 16 digits, the default admin PIN is 123456 and there are no user PINs. There is “drive wipe” protection, but it’s pretty lame, and wouldn’t meet most corporate policies (complaint #1). After 6 invalid PIN attempts, the drive needs to be unplugged before you can try 6 more attempts. Once you’ve gotten to 50 attempts, you have to type in a (hardcoded) PIN to try 50 more times (you still have to unplug every 6 tries). Only after 100 total attempts will the drive “wipe” itself. Given how long the wipe took during this testing, it’s probably only wiping the keys, not the whole drive (but the manual doesn’t say this is the case). While annoying, certainly not insurmountable for someone who’s really determined, but a brute force for a 6 digit PIN (the minimum) is 10^6 – well over 100, so unless the attacker has some prior knowledge, the drive will likely wipe first.

Basic operation is plug in drive, enter a valid PIN (user or admin) and the drive mounts – decrypted. When you’re done, unmount the drive from your OS, and unplug the drive. Until you unplug the drive, the data is still decrypted (complaint #2).

The administrative “interface” works, but it’s pretty complicated – hence my suggestion to keep the manual handy until you’ve got the hang of it. All commands are sent using a keypress combination or sequence. Granted, the primary interface is a keypad with a “cancel” and a lock icon in addition to the 10 digits, and you’re limited a bit. I had some trouble creating user PINs, but it seemed intermittent, so I blame it on user error instead of anything the drive did (or didn’t do).

If you forget your PINs, you’re SOL (which is as it should be – in most cases). You can reset the drive back to factory settings – again, the “wipe” is just a wipe of the keys and partition table based on the time it took. This is great for most uses, but I can see corporate folks leery about this because if a user forgets their PIN (or tries to reset their drive themselves), the company’s just lost a lot of data. The admin PIN is supposed to protect against that and as long as help desk/etc. keep that PIN, they’re safe from all but others resetting the drive.

The keypad is supposed to be wear resistant – but in the two weeks I had the drive, I can’t test that, but it feels sturdy, and the digits seem to be embedded in the rubbery keys.

The casing appears sturdy and no obvious screws (they’re probably under the rubber feet), but since I have to return it in working condition, I didn’t try too hard to break the case. There is no special padding or ruggedness to the case that you wouldn’t see in an unencrypted external drive case. However, the product page claims some protection from drops (I’ve found that most external drives can handle a small drop).

There’s also VTC (Variable Time Circuit) technology, which I’ve never heard of, but apparently helps to thwart timing attacks – again, not something I can test, because I don’t have the equipment (or time).

It’s pretty easy to use, and I used it almost daily for two weeks – mostly for play, since I don’t have a real need for external drives (except Time Machine). The drive is on my wish list, but until I get my house sold, we’re on a spending moratorium at home. It’s really not that expensive relative to unencrypted drives – the AES-256 250GB drive is listed at $109. There’s a 3 year warranty on the drive, which covers the drive and the casing.

The drive’s a bit slower than your typical external drive, but I expected that. An initial Time Machine backup of 198GB took 4.5 hours. I was using the computer while it was backing up, so that could have impacted the performance. For most uses, you won’t notice much of a difference – unless you’re moving a *lot* of data that has to be encrypted on the drive.

There are a few annoyances, but they’re really just annoyances.

1: Having to unplug the drive to lock it. There’s already a cancel button, why not use that for a “lock” button. As long as the drive is receiving power – say, while the computer has the screensaver turned on, the drive remains decrypted. Now, someone can’t easily read the drive if the screen is locked, but if someone doesn’t lock their screen? It’s available. There’s also no “timeout”. I can see why – as long as the OS has the drive mounted, it could be in use. I wonder if it’s possible for the drive to detect that it’s been unmounted and lock itself after a pre-determined time.

2: It’d be nice to have a configurable wipe after X attempts capability – or at least wipe after 10-15 attempts, which would cover most corporate policies.

3: I would love to see a Kensington style laptop lock on the drive case. The data may be protected if someone steals the drive, but it’s annoying. As I can see this drive going along to the library/coffee shop/etc. with the laptop, it’d be nice if there were some physical way to lock the drive either to the table or to the laptop. You should never leave your laptop/data/”stuff” unattended in public places, but a lot of people do it.

Crockford on JavaScript: The Early Years

The adapter essentially acts as a proxy between your computer and a USB drive, meaning it needs no software, has no operating system requirement, and works with everything from a flash memory stick to an external hard drive. All communication with the USB device is encrypted on the fly using 256-bit AES via a certified FIPS 140-2 Level 3 crypto module, but the key isn’t stored on the drive: at the front of the hiddn adapter is a smart card slot.

When you insert a smart card, you have to enter the corresponding PIN code to use it. (After three unsuccessful attempts, the card becomes locked until a longer PUK code is given.) The device does not appear as an active USB device in the OS until a card is verified, and becomes “unplugged” when the card is removed. The encryption key (or half of it in split-key mode) stays on the smart card, making an encrypted drive unusable without it.

Setting up and operating the hiddn system is very straightforward. You connect it to your computer with a USB cable, plug a drive into the top USB port, insert your smart card, and then enter your PIN. From there, the experience is no different than using a USB drive normally – there’s not even a difference in speed.

When I first connected an unencrypted drive on a Windows machine, it appeared as an unformatted drive. After formatting, it behaved just as it would when plugged in directly. (A few times I had to reconnect the adapter to get Windows to recognize a new drive if I didn’t “eject” the drive first or tried a bad PIN, but those were minor issues.) Trying to use the drive without the hiddn adapter after it had been encrypted brought up another prompt to format – Windows could tell there was a volume, but it was completely unreadable.

After using the hiddn Crypto Adapter for a short time, I started wondering why no one else had thought of it before – or at least why I’d never heard of it before. It’s a great tool for anyone wanting a no-hassle method to encrypt removable storage. The only potential drawback is pricing; two adapters and two sets of pre-configured smart cards can run almost $900. High Density Devices offers a few different packages of units and cards, ranging from one of each to ten, as well as an enterprise key management system for creating new cards. But while some users may find hiddn too expensive for personal use, its flexibility, ease-of-use, and high security make for a combination that’s hard to beat.

Not all services are affected equally, however; and some are not affected much at all. For example, protecting certain data fields stored in a distributed online database may be as common-practice as using strong encryption. However, more delicate services may not be as flexible…

How do you force the image data stored on a cloud image editor to be encrypted at their end? Or force a word processor to encrypt your latest holiday shopping list? Without the assistance of the service providers, the only solution is a customized technical workaround; colloquially known as a hack.

An example of precisely this kind of workaround was outlined in this paper (pdf) by Yan Huang and David Evans. In it, they describe a method (and a working example) by which a user can use Google Docs while maintaining both confidentiality and integrity.

It works by way of some very clever applications of incremental encryption, data structuring, and indexing to transparently handle all of the security operations. And although it interferes with some functional capabilities, it stands as an example of the kind of solutions needed to shine some light on the shady parts of the cloud.

Now, Google has expanded the program by offering similar bounties for vulnerabilities in their web-based applications. Hackers who find issues such as HTML injection or cross-site request forgery in important Google services can now report them and possibly qualify for rewards ranging from $500 to $3,133.70. As with the Chromium bounties, bug hunters have to follow a few rules and conditions, such as giving Google some time to fix the issue before public disclosure.

Given the success of the Chromium bounties, it’s likely this new experiment will be beneficial both for security researchers and Google’s users. It certainly adds an interesting new twist to the debate over how to handle outside bug discoveries – perhaps we’ll see more companies offering such compensation in the future.

1. Download the Firesheep .xpi file here.
2. Drag the .xpi file into your Firefox browser window to install it, then quit Firefox.
3. Move the extension folder from your user account to the application folder.  The /Users/[youraccount]/Library/Application Support/Firefox/Profiles/[yourprofile]/extensions/firesheep@codebutler.com folder should be moved into the /Applications/Firefox.app/Contents/MacOS/extensions folder.
4. Relaunch Firefox, and you should be good to go.  If you receive an error related to “–fix-permissions”, make sure you moved the folder (and didn’t copy it), and if it still didn’t work try running once as root (sudo /Applications/Firefox.app/Contents/MacOS/firefox-bin).

Enjoy. Use responsibly. And encourage your local coffee shop owner to turn on WPA2 to limit its usefulness.

One such spattering I recently came across is the online version of the Handbook of Applied Cryptography (not to be confused with the other book of similar appellation that is more-frequently used in college classes around the country).

Although it can get pretty nitty gritty at times with regard to the math and science involved in cryptography, sometimes that is exactly what you need to get the full picture and/or fill in the blanks that other resources gloss over in the interest of comprehensibility.

And best of all, the publishing company has released the chapters for free electronic distribution: http://www.cacr.math.uwaterloo.ca/hac/

Keep in mind, the last printing was in 2001, so some of the information may be a little aged. But if you’ve ever read any of our posts regarding public key encryption (Ch. 8, pdf), hash functions (Ch. 9, pdf), or digital signatures (Ch. 11, pdf), and wish we went a little further with the technical details, this just might satiate your thirst for knowledge.

I also hit up the talk on the American Bombe – yes, we had a few – a well researched and interesting discussion on how the US got started on that project and some of the stumbling blocks along the way. I also went to the HTTPS discussion, but it rehashed old SSL vulnerabilities and issues with the default CAs trusted in the browsers. One of the better talks I went to was the Locational Privacy and Wholesale Surveillance via Photo services talk by Ben Jackson. He discussed using the EXIF GPS data to stalk people. I promptly told my iPhone that the Camera app was not allowed to use location services.

For me, HOPE is more about the hallway track and meeting people and learning new things on the mezzanine level. This year, the lockpick village was so small that no one could fit in, so I didn’t stop by there – even if I did take my picks. There were more vendors on the M level as well, mostly books, with very little electronics as there have been in years past.

This year, I borrowed a friend’s ham radio and used my license for the first time in 10 years to get an N2H QSL card – along with my friend and several others. Just listening to the hams talk from N2H was interesting as well.