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.

To enable the administration of your various virtual machines, storage, clusters, datacenters, and the like, you can now use the vSphere 5 Web Client. Before it can be used, it must be authorized; the best instructions I found for this are here. Follow the steps in the “Authorizing the vSphere Web Client (Server)” section. This is a one-time configuration necessary to enable the vSphere Web Client.

Once authenticated, you will see something that looks very similar to the Windows-based vSphere Client running in your browser.

This will satisfy most of your management needs, but it leaves out an all-important capability; the ability to remotely view the console of the systems. There’s a Console button, but it won’t work on a Mac. Once you’ve installed a machine, you can typically enable some sort of remote desktop capability in the operating system, but what do you do before then? If you’re running Windows, you use the vSphere client and open a console, but on a Mac, you’re out of luck. Right? Wrong.

There is an under-documented feature of vSphere that allows the capability of opening up VNC connections from the host directly to the console of the virtual machine. To perform this, we first have to enable incoming connections to your vSphere server, as vSphere 5 has an integrated firewall. This is the one step you will actually need to use the Windows vSphere Client; everything else can be done using the Web Client. This step needs to be executed once for each vSphere or ESXi host running virtual machines you want to access using VNC.

In the Windows vSphere client, choose the host you wish to enable VNC connections on. Choose the Configuration tab and on the left choose Security Profile. On the right, next to Firewall click Properties… As VMWare does not include VNC as a protocol, it is not listed as an available option. However the ports allowed by the gdbserver protocol will suit our purposes. Check the box next to gdbserver. (It is also wise to highlight the gdbserver line and click the Firewall… button and lock down where you will allow these VNC connections to take place from; in ours I restricted this to our intranet.) Click OK and you’ve now enabled the incoming ports to be used for VNC.

Finally, enabling VNC access to the console machines is a matter of setting advanced configuration parameters on each virtual machine, which can only be done when the virtual machine is off. To open up the advanced configuration:

• In the Windows vSphere client, choose the machine, click Edit Settings…, click the Options tab, choose Advanced->General on the left, and click Configuration Parameters… on the right.
• In the Web client, choose the machine, click Edit Settings… under the VM Hardware section, click VM Options, click Advanced, and click Edit Configuration….

In both cases, you now want to add three rows by clicking the Add Row button.

Once you’ve added these rows and click OK, you can now use a VNC client to connect to the console of the machine. Power up the machine, and then using Finder on the Mac, choose Go->Connect to Server (or hit Command-K), and type the following:

vnc://<ip or name of esxi host>:<port chosen in configuration settings>/

and click Connect. You will be prompted for your password, and depending on your client/version of OSX you may receive a warning about how keystroke encryption is not enabled. Accept the warning, and you will see the console of the virtual machine! (And note, since Macs don’t already use the three-finger salute, you can safely just press Ctrl-Alt-Del in that VNC-window to log into Windows systems!)

Once you’ve installed the operating system of choice, and enabled that OS’ remote desktop capability, you may want to disable this VNC access. Just shut down the VM, go back into the advanced options and change the RemoteDisplay.vnc.enabled setting to false.

Hopefully at some point soon, VMWare will enable a true web-based console application (which doesn’t require host-specific plugins to be installed) to go with their nice new web client. Until then, this is a reasonable workaround for accessing virtual machines using a Mac.

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.

One example of script-less cross-site scripting affected some high-profile MySpace users in 2007. Attackers were able to inject HTML into celebrity MySpace pages, but the service filtered out typical <script> payloads. Seemingly innocent <a> links were allowed, though, and adding a bit of CSS allowed one to create an invisible link that covered the entire page. In this case, clicking anywhere on an infected profile led to a malware download.

This attack could be one of the first prominent cases of clickjacking, though the term is usually applied to attacks that hijack clicks with malicious inline frames (iframes). Allowing <iframe> elements in user-controlled HTML opens up a range of issues more broadly known as UI redressing. For instance, an iframe that covers the entire page could render a fake login form that appears to be legitimate given the site’s address, leading to a powerful phishing attack. Frames and forms can also be used to bypass CSRF protections.

Of course, you can sometimes launch simple CSRF attacks using only images. By setting the “src” attribute of an <img> element to another page, the browser will still execute a GET request to that page when it tries to load the image. Without proper CSRF protections, such an attack may be possible without XSS to begin with. But images can also be a source of information leakage or tracking, since GET requests to a malicious server will also likely include a “Referer” header.

While most XSS payloads do capitalize on the power of JavaScript, keep in mind that a browser can load scripts from many places besides within script tags. Event attributes for other elements and certain CSS properties are just two examples of places a script could slip in. And don’t forget about the risks of browser plug-ins – Flash 0-day issues or malicious PDF files can also be sources of trouble.

Finally, an issue this week served to remind that XSS is no longer just a concern within the context of a web browser. As HTML and JavaScript become a greater part of developing apps built outside the browser, XSS may pop up on other platforms. On Monday, a security researcher with the handle superevr disclosed an XSS vulnerability in Skype for iOS. By inserting HTML into the “Full Name” of a user, one could send messages that when viewed would launch code capable of stealing the phone’s address book. And this wasn’t the first time XSS has been a problem for Skype – a vulnerability in desktop versions was found a few months ago, and XSS with shared content could lead to problems back in 2008.

Alternate labels, such as “HTML injection” or “web content injection,” have been proposed to describe cross-site scripting, but the established term is likely here to say. Still, remember that protecting against XSS does not simply mean blocking script tags, and keep in mind the power of XSS when integrating web technologies with other platforms.

1. HttpFox: I’ve blogged about this one in the past; it lists for you every HTTP request made during a given browser session, with details on headers, cookies, parameters, responses, and more. Very handy to monitor traffic when you’re browsing around an app.
2. HackBar: Another one I’ve mentioned before, the HackBar is a swiss-army knife that gives you some space for notes, common commands (such as base64 encoding or MD5 hashes), and perhaps best of all, an easy way to execute manual POST requests.
3. FireBug: Perhaps one of the best-known Firefox plug-ins, FireBug is a powerful tool for inspecting a page’s DOM, debugging scripts, and investigating script variables.
4. Cookies Manager+: As you can guess, this add-on lets you view and edit browser cookies to your heart’s content. Useful in tracking and spoofing session information.
5. Modify Headers: Many web apps use special headers in various ways; this tool lets you set such headers manually when making requests. Spoofing XMLHttpRequest commands is one use case.
6. User Agent Switcher: I’ve seen apps with vulnerabilities that only affected mobile versions of the site. This extension lets you imitate just about any browser, allowing you to test different site interfaces.
7. JavaScript Deobfuscator: This is one add-on I only recently discovered, but I can already tell it will be quite useful. It logs JavaScript functions as they’re compiled or executed by the browser, which is particularly useful in dealing with obfuscated scripts.

This list is by no means exhaustive and is geared towards manual testing, but it certainly provides a solid line-up for anyone looking to experiment with web app security. It also shows how easy it can be to get started tinkering with web apps. While I use Chrome for my everyday browsing, I use my tricked-out Firefox setup when I want to dig deeper. If you’re starting out, try using these add-ons against an educational app, such as WebGoat, Gruyere, or DVWA.

Crockford on JavaScript: The Early Years

Enabling S/MIME

There’s a setting I missed in the previous post was pointed out by a commenter. After getting iOS 5 on the device and putting your certificates on there, you need to edit your email settings. Click Settings->Mail, Contacts, Calendars->Your email account->Account->Advanced. Scroll down to the S/MIME section and turn on S/MIME. (Note that this wasn’t required in order to read S/MIME encrypted email.) Enabling S/MIME causes two new options to appear, Sign and Encrypt. Selecting these will cause your iOS device to try and sign and/or encrypt each outgoing message. Make sure you enable the Encrypt option at this point to make your iOS device attempt to encrypt outgoing messages when possible.

Immediately below the S/MIME section is a section called Certificates, which contains the certificates for which your device has private keys. You can select one of these certificates (clicking it puts a checkmark next to it) and this is the certificate that will be used to sign all outgoing messages (if you’ve turned on signing). Note: you can select certificates that are not valid for the digitalSignature key usage value. I submitted a bug report (ID 9601006) to Apple about this today.

Sending Encrypted Email With Exchange

If you are connecting to a Microsoft Exchange Outlook Web Access server, and you have an enterprise public key infrastructure that publishes encryption certificates to users’ global address list (GAL) entries, you are in luck. Sending encrypted email could not be easier.

Simply enable the account and ensure Contact syncing is being performed for the account for email and enable S/MIME (thanks, Allan). When you choose a contact, the iOS device will automatically attempt to download the recipient’s certificate from the GAL. If it considers it valid, you will see a lock icon displayed next to the “To” address like this:

If it can’t find a valid certificate for your recipient, you’ll see something more like this:

Sending Encrypted Email Without Exchange

If you are not connecting to Exchange, there will need to be a bit more manual process to get certificates on to your device. If you’ve used S/MIME at all, you’re likely familiar with the “send me a signed email so I can send you an encrypted email” dance. iOS 5 is no exception. In order to send encrypted emails to recipients you will need their certificates, and as far as I can tell the only way to make that happen (aside from using Exchange) is through an exchange of signed emails.

Once your desired recipient has sent you a signed email, if the iOS device trusts the certificate used to sign it, you will see their name in the From field appear like this:

If your device doesn’t trust them, it will look more like this:

Click the sender’s name. If they are untrusted, you will see a reason why, and have a “Trust” button available to you to choose to trust this certificate from now on. In either case, you will see a “View Certificate” button. Click it.

Click the “Install” button to install this certificate to your iOS device. Now when you reply to the sender’s email (or send them emails in the future), you will see a lock by their name indicating you will be encrypting the email to that individual.

Hopeful Future Improvements

I’d like to see some improvements. I’m filing bug reports with Apple on each of these items, and I hope others will too.

First thing would be an improvement to the signing certificate selection, enabling you to (a) not choose encryption certificates for signing, and (b) make it clear what that selection is for anyway. The certificate selection option is enabled even when you choose Encrypt, which makes the setting user interface very confusing. (On a related note, on my device I could not see a Key Usage value for any certificate by looking at its details. I have also filed this as a bug.)

The second thing would be a capability to import certificates into the device which does not require Exchange or the signed email dance. I created a configuration profile containing public certificates for every user at my company. Unfortunately, iOS Mail did not have the capability to use these certificates for sending encrypted email. In fact, iOS could not even send me an encrypted email until I first sent the device a signed email and imported it, even though my encryption certificate was on the device being used to read encrypted emails. Hopefully Apple will improve this in a future release.

Lastly, there should be a way to look in the contacts of the device to determine whether or not you have a (valid) encryption certificate for a user. If I am going to leave on a trip but I know I want to interact with a few people using encryption, I won’t know until I try to send them an email. The Address Book feature on my Mac already has this, it displays a little checkmark next to email addresses I can encrypt to.

Again, please let me know if you have any additional suggestions or feedback by entering a comment below!

During the 2011 Apple Worldwide Developer Conference keynote address, Scott Forstall indicated that iOS 5 would have support for S/MIME encrypted email. (Skip to 63:10 in the presentation.) This morning I successfully upgraded to the iOS 5 Beta and started being able to read my S/MIME encrypted email. Here is how I did it.

What you need:

-       Xcode 4.2 and iOS SDK 5 beta (requires iOS Developer Program account)

-       iOS 5 beta for your iOS device’s platform (requires iOS Developer Program account)

-       iTunes 10.5 beta (requires iOS Developer Program account)

-       iPhone Configuration Utility 3.3

-       Your S/MIME encryption and signature certificates exported in PKCS12 (.p12) format

(Note there is some discussion about not needing to pay for a developer program account to install iOS 5. I went the legitimate route.)

Click to read the whole walk-through of how I did it.

Installing iOS 5 Beta

To install the iOS 5 Beta, make sure you have a backup; this will wipe your device. I used Apple’s guide. First, install Xcode 4.2. Launch Xcode and plug in your iOS device. You should see a window similar to the following:

Click “Use for Development”. If it doesn’t automatically bring you to the device organizer, click Window->Organizer. Your device should appear there in a Summary view. Under “Software Version”, click Other Version… and then choose the .ipsw file relevant to your device. Once you see the 5.0 (9A5220p) choice under Software Version, click “Restore”. This will erase the contents of your iOS device including all pictures, music, videos, and apps. Make sure you have a backup. Allow the restore to complete. Once it is complete, Xcode will again display the “New Device Detected” dialog, and you should click “Use for Development”. To complete the installation, launch iTunes 10.5 beta and set up the device.

Once you’ve set up the device, and either synced your Mail settings or manually configured them, go ahead and try and open up an encrypted email message. Here’s one that Joey sent me:

As you might guess, going to Settings > General > Profiles doesn’t do you much good. On my system, the only profile installed was the Provisioning Profile put there via my Developer account. So, we need to create one.

Create and Install Configuration Profile

Note: If you don’t wish to deal with a configuration profile, you can also email yourself the .p12 file containing your certificate. Thanks to Oleg for the tip.

If you don’t already have it installed, install the iPhone Configuration Utility and launch it. Make sure your iOS device is plugged in.

On the left side of the iPhone Configuration Utility, click on “Configuration Profiles”. Then click the “New” button at the top.

In the general section, it would be good to give your configuration profile a name. You will definitely need to provide a unique identifier for your configuration profile, so they are not confused across devices. While you can set a number of other required configurations on the device using this tool, the important one for S/MIME is the “Credentials” configuration. On the left scroll down to “Credentials” and click it.

Click “Configure” on the right-hand side to add your encryption certificate to the device. You will be prompted with a file selection dialog where you can choose your PKCS12 file containing your encryption certificate and private key.

Once your certificate appears in the window, you can scroll down and enter the password used to protect the PKCS12 file, or not. If you enter it, you will not be prompted to enter it when inputting the certificate on the device, but there will be a copy of your password stored with the profile. I chose not to enter my password at this time.

You should repeat this process for your signing certificate as well; click the + button toward the upper right to add a second certificate. In my experience, I could not read signed and encrypted emails unless I put both my signing and encryption certificates into the profile.

To install the configuration profile on your device, click your device on the left-hand side of the window, and go to the “Configuration Profiles” tab.

You should see the profile you just created. Click “Install” and your iOS device will beep or click at you. Look at the screen and you will see:

Click the “Install” button on your iOS device. You will get a warning that it will change settings on your device, click “Install Now”. You will then be prompted to enter the password used to protect your PKCS12 file if you didn’t save it as part of the configuration profile. Enter it, click “Return” and then “Done”.

Now when I re-launch Mail I can read Joey’s message:

Hooray! I’m reading encrypted email on an iOS device!

Hopeful Future Improvements

First, there is no indication on this encrypted email that it had been encrypted. Note: See follow-up post for how to fully enable and see these UI changes, thanks to Allan for pointing this out. So, I don’t know if the sender thought it was sensitive. I think this will be changed in a future release. In the below still image I took from the keynote address, you can see a lock and the word “Secure” in the title bar of the message. Obviously it’s important that Apple provides this visual cue.

Second is of course sending encrypted and signed email. Note: Again, see follow-up post for how to fully enable S/MIME. Despite my best efforts (installing my CA as a root on the device, installing certificates for my co-workers, installing certificates for other email addresses of mine) I could not get the little lock icon to appear next to anyone’s name in the “To” field of any emails, nor could I get it to send encrypted emails.

I look forward to a future beta from Apple which has these features enabled. Stay tuned here, because once I figure them out I’ll document them.

Let me know if it worked for you, and please provide any other comments below!

The example that reminded me of this relates to Bitcoin, a somewhat controversial form of digital currency that’s recently been discussed by several high-profile media outlets. I’m not going to talk about any specific merits or problems associated with Bitcoin, but note that it relies on mathematically solid encryption schemes to allow transactions while preventing theft.

However, regardless of how strong your encryption, an insecure application using that encryption can introduce easily exploitable vulnerabilities. And Adam Baldwin of evilpacket has shown how this can happen with Bitcoin by creating a video demo of XSS/CSRF problems in a Bitcoin exchange site. These application-level issues could enable an attacker to steal Bitcoins without cracking the basic cryptography employed.

Using proven security technologies is important, but it’s only one part of securing your organization. I still remember my surprise when I first discovered that an “unbreakable” cipher did exist: the one-time pad. But using one-time pads is often impractical, and they are still susceptible to compromise from human factors. Building secure business operations requires understanding the risks at each level of a system and having a defense-in-depth response.

At Gemini, we can help you assess those risks, architect strategies to handle them, then apply those solutions in your organization to produce measurable security improvements. Don’t simply trust in “encryption” or WAFs to protect your data – let us help you understand the big picture of your company’s security today.

The main issue that was holding me up wasn’t anything to do with Android-OpenVPN port itself. It was simply to do with the Android device I was using (thanks Samsung for crapping on us with the Galaxy S devices). A recent ROM update finally put the final pieces I needed into motion for being able to utilize OpenVPN. The main holdback was the lack of tun in the kernel of my Android build.

Anyways, if you’ve been needing VPN access, or specifically need the OpenVPN variant they give it a shot. Outlined below is what you’ll need:

• A rooted Android device – You may also need an upgraded rom. The project is built using cynogen 6. If your device supports this ROM or one of its variants I highly recommend it. But if you’re like me and on a Samsung device or other unsupported device, look for upgrades at XDA-Developers.
• An OpenVPN configuration file. You’ll most likely have this along with your desktop client. (client.ovpn)
• Android-openvpn-installer – Available here or from the Android Market– this is mostly used to install the OpenVPN binaries onto your device.
• Android-openvpn-settings – This (and this) is what you’ll actually use in Android to start/stop/configure the VPN.
• A way to transfer files to your device’s SD card or internal storage (for those of you without expandable storage).

1. Begin by rooting your device if it’s not done already. Look towards XDA-Developers if you need help with this.
2. Install the OpenVPN-Installer either from the Google Code page, or directly from the Android Market.
   1. Run the installer and remember which path you choose to install OpenVPN into. I chose the “/system/bin” directory. You’ll need to enter this directory into OpenVPN-Settings later.
   2. If it installs correctly, it will show a green plus button and continue on.
3. You’ll now need to transfer your OpenVPN configuration file to your device’s external storage. Create a folder on the root of the storage called “openvpn” and place your configuration file here.
4. Install OpenVPN-Settings either from the Google Code page, or directly from the Android Market.
   1. Once installed, you’ll need to configure it. Menu (button) -> Advanced
   2. Now you’ll want to configure the two paths: “Path to configurations” and “Path to openvpn binary“
   3. Select them one at a time and enter the required paths. For me, the configurations path ended up being “/sdcard/openvpn” and the binary path was “/system/bin/openvpn“.
5. Now return to OpenVPN settings by using your back button and you should see a connection listed with the same name as your configuration file.
6. Enable the VPN by pressing the OpenVPN checkbox, once it’s enabled, press the checkbox for the connection you want to connect to.
7. You’ll need to enter your username and password, but the notification will most likely be in the top bar, so pull it down, click the notification, and enter your credentials. (You’ll have to do this every time you connect, no saving here).
8. Enjoy OpenVPN goodness!

They’ve made the process of using it pretty straight forward, especially for what it used to be. Feel free to check out the Google Code sites if you would like to contribute or have any issues.

One big caveat on all of this as Uncle Ben once said – “with great power comes great responsibility” so be sure to continue using safe (read secure) computing practices, as once you’re on the VPN, your device is now connected to your company’s VPN. In most cases, this is useful for communicating with exchange servers or shared file access. But be sure to disconnect when you’re done using it and ensure you keep a device password.

Links:

OpenVPN-Installer – Code | Market

android openvpn-installer

OpenVPN-Settings – Code | Market

android openvpn-settings