It has been brought to our attention that recent versions of Mail on OS X (perhaps starting with 10.10, but definitely since 10.11), will re-download all of your email from your email server. And since your server doesn’t encrypt your email, that’s a serious concern.

This means that the following attack is possible to bypass Espionage’s protection of your email:

While Mail’s folder(s) are locked and empty, open Mail.

Follow the dialogs and allow Mail to import your messages.

Wait for a while as your email is re-downloaded.

We do not believe this behavior existed in older versions of OS X, but we still should have noticed earlier. Our sincere apologies for not having done so ourselves, and our sincere thanks to the customer who reported this issue!

During our investigations, we were not able to find any folder that could be encrypted to prevent this from happening. This has lead us to conclude that Mail must be fetching account information directly from OS X’s keychain.

Mitigation

Unless Apple changes their code for Mail.app, there doesn’t appear to be a way to prevent it from using the credentials in OS X’s Keychain to re-download all messages—where, we should emphasize, they are unencrypted.

There are at least three mitigations:

Option #1: Move messages to the “On My Mac” section

In the sidebar on the left that shows all of your accounts and mailboxes, there should be a section that says “On My Mac”:

If this section is missing you can make it to appear by creating a new “local” folder via the Mailbox menu: Mailbox > New Mailbox… and then: Location: On My Mac.

All folders in this section correspond to folders only on your Mac (and not the server). Therefore, any messages moved into these folders should disappear from the server and won’t be re-downloaded by Mail.

You can use Mail’s Inbox Rules (via the Preferences) to automatically move messages to one of these local folders. The downside is these messages will not be synced to your other devices.

Option #2: Use GPGTools to encrypt messages

You can use the wonderful GPGTools software to store, send, and receive messages that are encrypted even on the server. However, this approach isn’t for everyone as it may be somewhat less user-friendly, and it requires that the recipient also be using GPG.

Option #3: Don’t use Mail.app

Use an email app that either does not store its credentials in the Keychain, or (if it does) does not re-download everything if its primary data folder is missing.

You can verify this yourself by encrypting the data folder of an app like Thunderbird and then opening the app while its folder is locked. If it does not re-download everything, then at least the messages on your computer should be safe. The messages on your email server or on your friend’s computers… are a different story.

Conclusion: Email Must Die

I have spent a good portion of my life attempting to fix email and on the general problem of secure messaging. You’d think this would be easy, right? Wrong!

Here’s what my quest has involved so far:

Started a company to support the development of a generic folder encryption product (Espionage).

Yet here I am, 8 years later… Email is still an unsolved problem and it is only getting worse. The complexity of self-hosting means more people are relying on companies like Google and Microsoft, and this has led to a centralization of the entire system. These entities are now using their position to further discourage self-hosting by (possibly illegally) dropping or junkingemail from correctly setup email servers, using spam as an excuse to secure their monopoly.

It’s because of this that I’ve come to the conclusion that email must die.

EDIT February 17, 2016: 3.6.4 and 3.6.5 release notes included here as there are only minor changes.

We’re momentarily back from our break in cryptocurrency-research-land (where we’ve been advancing our goal of sustainably open-sourcing Espionage) to bring you the immediate release of Espionage 3.6.3!

“But wait! This doesn’t seem like such an exciting release! What is this business about dropping support for three operating systems? Are you trying to screw us over?! Bad Tao Effect, bad!”

*ahem*

Our dear customers, we love you, we only want what’s best for you, and we will never try to screw you over. ^_^

10.7, 10.8, and 10.9 Are All Insecure. Stop Using Them.

Although we will keep Espionage 3.6.2 available for download here, we strongly recommend that all users upgrade to at least 10.10 (preferably 10.11), and here’s why:

Problem #1: Internet connections are not secure on 10.7 and 10.8

While investigating a seriousvulnerability in Sparkle (the software update framework Espionage uses), we discovered that Sparkle did not work at all on our 10.7 test machine.

It turns out that neither Mac OS 10.7 nor 10.8 are capable of handling secure SSL/TLS connections! TLS is the protocol behind the S in HTTPS, and it’s responsible for securing almost all Internet connections.

Versions of TLS prior to 1.2 are afflicted by a serious vulnerability, making the lock icon in your web browser even less meaningful than it already is. It seemed silly to support these insecure systems when they can’t even load Espionage’s homepage (because it only allows TLSv1.2).

This seems like a good moment to reiterate that everything less than TLS 1.2 with an AEAD cipher suite is cryptographically broken.

Problem #2: 10.7, 10.8, and 10.9 are all vulnerable to root privileges escalation

Your Mac has various user accounts on it besides the one you use, and the most powerful of these accounts is called root. Up until 10.11, this account could do anything (and even in 10.11 it can do almost anything). It can delete anything and install anything, including key loggers that would break Espionage’s protection.

Normally it is not possible for a program to gain these “root powers” (privileges) unless you, the user, manually type in your admin password. However, sometimes a bug is discovered that will allow a program running under any account to gain these privileges without any intervention from the user. This is extremely dangerous, and this will forever be the reality all the way up to Mac OS 10.9.

Combine Problem #1 with Problem #2 and you have a recipe for total disaster. Therefore we want to do everything we can to discourage the use of these insecure operating systems, especially given that our customers want security.

The #1 thing users can do to keep themselves secure is keeping their software up-to-date.

Sparklegate

Speaking of keeping software up-to-date, Espionage 3.6.3 includes an updated version of Sparkle, the popular OS X software-update framework.

Sparkle had a vulnerability that made it possible for anyone on your network (a malicious attacker) to execute arbitrary code on your machine.

This problem is mitigated somewhat for apps that use HTTPS to check for updates (as Espionage does), but it is still a serious problem, especially on OS X 10.7 – 10.8 because HTTPS is broken on those operating systems (as described above), and even then it’s still possible (though rare) for someone to compromise HTTPS for TLSv1.2 (the latest version).

So just to be on the safe side we’ve updated Espionage’s version of Sparkle and we’ve dropped support for all the compromised operating systems that Apple is no longer updating.

However, you still most likely have compromised apps, so read this:

Sparkle is a very commonly used framework. Almost every app you have that you did not get from the App Store will be using it, and this vulnerability is ultimately due to a fundamental flaw in OS X, so there may be other affected other apps out there.

Until Apple fixes this flaw, we recommend taking these steps to protect your Mac.

We strongly recommend that all users use the latest version of OS X.

OS 10.11 El Capitan is great. Apple did a good job of addressing many of the performance and stability issues that were plaguing 10.10, and since it’s a free upgrade you really don’t have much of an excuse for not using it. Especially if you want to keep your Mac safe and secure.

After trying and failing to reproduce Sparklegate, I arrived at the conclusion that Gatekeeper and Quarantine did in fact protect OS X users from the Remote Code Execution (RCE) attack.

What I Missed

Radek, the discoverer of the vulnerability, insisted that I was mistaken and that Gatekeeper really did get bypassed. So today I attempted to reproduce the attack using a fresh account on a different machine.

It turns out, if you’ve ever opened Firefox, you are not vulnerable (to the FTP version of the attack), even if Firefox is not running and you’ve manually set the Finder as the default FTP handler.

Resetting the protocol handler via duti -s com.apple.finder ftp has no effect for some reason. Firefox will still launch in response to the attack and the FTP handler is magically reset back to Firefox!

However: if you’ve never run Firefox on your account, then you are vulnerable (and you should pay attention even if you have used Firefox).

How To Protect Yourself From Sparklegate

Sparklegate is a fundamental flaw in OS X, not Sparkle. It is a flaw in Finder (foremost) and WebView (second most). You almost certainly have several apps that are vulnerable to this attack, and even if every app updates its Sparkle framework there still might be others that are vulnerable.

So here are 3 ways to protect yourself from getting owned, and I recommend you do all of them:

If Firefox is not installed you’ll need to change org.mozilla.firefox to com.apple.Safari like the others. I recommend Firefox because unlike Safari it does not auto-mount anything and it’s a great browser in its own right.

Just in case there are other protocols that could be used in this attack, you may also want to:

3: Use Little Snitch (or similar) to disable LAN & Finder connections

Open Little Snitch Configuration and make sure that you are looking at All Rules. Use the search field to search for Finder and delete any rules that appear in the search results.

Next, clear the search field and scroll to the top. Uncheck the rules that allow “Any Process” to make outgoing connections to the local network and click “Disable Anyway” when prompted:

Doing this will mean that you will get prompted more frequently. Prompts will happen when, for example, iTunes tries to sync with your iPhone over Wifi, or if you try to access a network volume, or for other reasons. Generally you’ll want to allow them unless they mention something about “ftp” or “smb” or “afp” and you aren’t trying to access a network volume.

Something like this might appear if you’re being attacked via FTP, but it’s not necessarily the only prompt to watch out for:

Click Deny in such instances to prevent the attack. You’ll then be greeted with an error like this:

Finally, Make Sure Gatekeeper Is Enabled

While Gatekeeper won’t protect users who have not done at least one of the things above, it will provide additional protection in case the AFP or SMB protocols are used:

Open System Preferences

Go to Security & Privacy

Make sure that “Allow apps downloaded from:” is *NOT*set to “Anywhere”

If you must open an unsigned app while Gatekeeper is on (not recommended unless you know what you’re doing): right-click on the app and choose “Open” from the contextual menu.

Conclusion

This is a devastating vulnerability that affects many OS X users. Since both WebView and the Finder are at fault, the attack goes beyond apps that haven’t updated their Sparkle framework.

Until Apple fixes this problem, you can protect yourself by doing at least one of the three things mentioned above, and preferably all of them.

Sparklegate is the term I’ve coined for the recent discovery that, allegedly, every OS X machine out there is vulnerable to RCE (remote-code-execution) attacks because the widely used Sparkle framework, along with OS X’s standard WebView component, allow webpages to mount FTP volumes and run arbitrary programs on your computer.

The first report of this insane vulnerability restricted itself to the use of a terminal settings file to achieve this feat. Shortly after followed a second post, this time alleging that any executable could be run without need for the intermediate step of a .terminal file. This second post also came with a proof-of-concept exploit that anyone can use to attack people with.

The fix that’s suggested in the original post is for app developers to serve their update feeds over HTTPS and to update to the latest version of Sparkle in case that’s not enough. Espionage already checks for updates over HTTPS and therefore it is not particularly affected by this issue, but there is still the very remote chance that someone could obtain a legitimate-yet-fraudulent HTTPS certificate and conduct this attack. Also, the idea that this attack is even possible suggests a severe failing on Apple’s part, one that affects not just apps that use Sparkle but any app with a WebView (and every OS X user has at least several such apps).

So I decided to look into this further and attempt to reproduce the attack. Here’s what I found:

Cannot Reproduce (Mostly)

I ran Simone Margaritelli’s bettercap with the osxsparkle.rb module and tried to reproduce both of the alleged scenarios: attack-by-terminal-settings and attack-by-arbitrary-executable.

In order to MITM yourself locally, you must also set your system-wide HTTP proxy settings to the LAN IP and port that’s shown in the output from bettercap. So I did that and then proceeded to Check for Updates in VLC.

Indeed, there was a flurry of activity, but something unexpected happened. Instead of being shown a terminal window with the output of `ls` I was taken to Firefox and a web page with this directory listing:

Well that’s not very threatening.

So I realized that apparently I was immediately, without going further, seemingly immune to this attack just because Firefox was somehow the default handler for ftp:// URLs.

OK, I thought, what happens if we remove Firefox as the handler?

After some digging I discovered a handy tool called duti (available via Homebrew). Setting the handler to com.apple.Finder didn’t work, but setting it to com.apple.Safari did. Here’s what happened when I tried it again with Safari as the default FTP handler:

Excellent! Just as I would expect, Quarantine prevents the file from automatically executing. Although it is a bit disturbing that Safari chooses to automount an FTP volume instead of handling the protocol itself (like Firefox), still no RCE.

Maybe the terminal settings file will bypass Quarantine and Gatekeeper (as the original post alleges)?

Conclusion (& Precautionary Steps To Mitigate)

At least in my attempts to reproduce this vulnerability, it seems both Quarantine and Gatekeeper, together, prevent both signed and unsigned applications from being automatically run without the user’s consent.

To be clear, this is still a problem for several reasons:

Just because a random webpage loads shouldn’t mean that Safari (or the Finder) auto-mounts or auto-launches anything! That’s just crazy! Thank goodness for Gatekeeper and Quarantine because without them this would have been a total and complete long-lasting catastrophe. So make sure you haven’t disabled either of them!

As the original report indicates, this attack could still be used to exhaust a system’s memory because the way XML is handled is broken. Apps that check for updates over HTTP and haven’t updated to the latest version of Sparkle are still vulnerable to this.

How To Mitigate

Developers should update their apps and take care to:

Make sure they’re using at least Sparkle 1.13.1 and preferably a later version. Until a later version is released I would recommend being cautious and building the Sparkle framework yourself from source (the Makefile makes this easy).

Who knows what other crazy surprises like this are lurking undiscovered, so make sure your appcast is using HTTPS in addition to Sparkle’s built-in DSA signature verification.

Sparkle should require both HTTPS and the DSA check from here on out. Now that HTTPS certs are free, no more excuses.

Users can simply download, install, and run Firefox (it’s a feature not a bug :P!).

To be certain that Firefox is the default handler for FTP you can use Homebrew to `brew install duti` and then:

duti -s org.mozilla.firefox ftp

However, there are other protocols besides FTP that could be used (like smb), so even better would be to install Little Snitch and make sure that there are no permanent rules allowing the Finder to make outgoing connections. Thus, if you get a prompt asking you to allow the Finder to connect to something (and you didn’t do anything to initiate), block it.

We will still release a minor update to Espionage with an updated Sparkle just to be extra safe.

The good news though is that as long as your Gatekeeper & Quarantine settings haven’t been modified, Sparklegate should not harm you (as long as you don’t blindly click “Yes” to things), and users can still take precautionary steps (like Little Snitch) to protect themselves even in the worst case where Gatekeeper and Quarantine fail.

Finally, a request to Apple: please fix that whole visiting-a-webpage-automounting-&-autolaunching thing. I’ve opened rdar://24428066 for this.

It currently follows a “source code available” policy, but we think the right thing to do is to completely open source the product.

However, this comes with two significant challenges:

If we open source Espionage improperly, there is an extremely significant risk that it will face the same fate as TrueCrypt. More important than open sourcing the app is ensuring its health. A dead, unsupported app is useful to few, whether or not it’s open source.

We do not have control or ownership of one of the most critical underlying technologies: Apple’s encrypted sparsebundles. Therefore, we cannot open source that aspect of Espionage.

Your Mission, Should You Choose To Accept It

We’re looking for an excellent Cocoa developer who is also interested in solving the problem of funding beneficial, open source software, without resorting to advertisements or other nuisances.

You’ll work with us to open source the application in a way that is sustainable. This will involve making creative modifications and improvements to the UI, and novel cryptocurrency concepts.

Initially, we will simply focus on addressing Challenge #1 above. Later on we can move to Challenge #2.

Requirements

You have at least 2 years of experience working with Cocoa and Objective-C (or you are a genius who doesn’t need 2 years of experience).

You speak English well.

You’ve downloaded and played around with Espionage.

You have experience designing simple, elegant, and intuitive interfaces with Cocoa.

Ability to use GPG, or willingness to learn (GPGTools makes it simple).

Espionage 3.6.2 delivers an important security fix to address a plausible deniability issue with folders that were set to auto-lock, and it also brings important improvements and bug fixes:

Security

The path for folders set to auto-lock was leaked in previous versions, compromising their plausible deniability (PD). If you require PD for those folders make sure to change the mountpoint for the affected folders after updating to 3.6.2! If you have any questions about this please contact us.

Improvements!

If a folder fails to lock, Espionage will now tell you the application(s) that’s preventing it from locking.

Bug fixes

Fixed crash on renaming a folder.

Fixed issue where many critical notifications would be posted if a folder failed to auto-lock due to open item.

Misc.

Added Cynthia to credits for Tagalog localization.

Known Issue(s)

High CPU usage can occur if a folder gets auto-locked in a user-account that you’re not logged into (via Apple’s Fast User Switching feature).

How to change the “mountpoint” for a folder

The mountpoint is the location of your encrypted folder. It’s called a mountpoint because that’s the location where the decrypted data is “mounted” when the folder is unlocked. It’s a weird technical word… we didn’t come up with it. 😛

Remember that you only need to do this for folders that have auto-lock enabled (and only if you care about having plausible deniability for those folders).

Step 1: Click on the ‘i’ (info) icon for the folder to go to the folder details

Step 2: Click on the mountpoint and “Choose…” another location

In the Open Panel that appears, pick a new location for the folder. That’s it!

The signature for Espionage.dmg is here and also here. The SHA256 of the main binary is also noted below.

While Apple’s iMessages are designed to be “end-to-end encrypted”, Apple can still read them (if they wanted to).

That is not news. On October 17th, 2013, Quarkslab published iMessage Privacy, where they stated (correctly) that:

Apple can read your iMessages if they choose to, or if they are required to do so by a government order.

This is because Apple owns and operates the infrastructure that distributes the public keys between phones. At any point in time they are capable of giving out a public key of their invention (not belonging to the intended recipient), and decrypting/re-encrypting your messages as you send them to your friends and family.

A separate and more concerning issue was pointed out by Ars Technica a few months prior: if you enable iCloud backups, Apple will encrypt your data with keys that they generate themselves instead of using a key that’s based on your password (which they do not know). This is why Ashkan Soltani was able to restore his iMessages onto a completely different iPhone after resetting his iCloud password and answering Apple’s iForgot security questions.

Update July 27, 2015: A third issue, perhaps the most severe, is Apple’s use of weak encryption, only 1280-bits!

Has anything changed since then?

iMessages security (in transit)

Here Apple describes how their IDS and APN services act as MITM between users for the purpose of public key exchange and message delivery. As long as these services are honest, the communication actually is end-to-end encrypted. There’s nothing in the protocol forcing Apple to be honest, however.

iMessages security (when backed up to iCloud)

On the matter of iCloud backups, we have the following (for the infosec crowd; skip below if you find it overwhelming):

This gobbledygook says that for iCloud backups data like iMessages gets encrypted with Apple’s keys (not yours), while keychain entries (wifi passwords, credit cards, iMessage private keys[not messages], etc.) are stored in a way that (allegedly) Apple cannot read because it’s tied to a password (a “UID”) that Apple creates for each phone upon manufacture (but claims to not know). The iMessage keys are used for the so-called “end-to-end” encryption when sending data between phones. They are not used to encrypt the messages stored on the phone, nor the messages stored in iCloud.

Conclusion & Recommendations

It should be emphasized that Apple has gone to noble lengths to protect your data.

The technical shortcomings described above do not imply any sort of intentional failure or sneakiness on Apple’s part. IMHO, Apple has done fairly well (within the confines of a centralized system) when it comes to balancing communications security with easy of use. The award for “the best” job still goes to the Signal/TextSecure team. Apple’s iCloud backups, however, should be encrypted with the user’s keys, not Apple’s (at the very least this should be an option). Nate points out that Apple provides a way for users to delete old iCloud backups.

To address the rest of the shortcomings, we suggest that Apple (and other companies) explore decentralized key distribution mechanisms (like okTurtles’ DNSChain). Such mechanisms don’t require fingerprint verification between users and therefore would preserve the fantastic user experience that Apple is known for, while simultaneously protecting both Apple’s users and Apple itself from forms of coercion (like National Security Letters) that destroy Apple’s “end-to-end” encryption.

Apple should also be commended for the steps they’ve taken to be more transparent about the security of their systems. I enjoyed reading their iOS Security Guide and felt they did a fantastic job with it. Props to the team that made that happen! 🙂

A final remark: if Apple is to receive any criticism, it shouldn’t be for any technical shortcomings, but instead for the following misleading marketing claim on their website: