Last week, Apple released a security update for iPhones and iPads. Typically, when there's a software update, there's some detailed information on the issue it fixes. This one came with a message that was downright terrifying to computer security folks:
Impact: An attacker with a privileged network position may capture or modify data in sessions protected by SSL/TLS
Description: Secure Transport failed to validate the authenticity of the connection. This issue was addressed by restoring missing validation steps.
What is a "privileged network position"? In security terms, that might just mean, "I'm on the same Starbucks WiFi network as you." And how bad is, "failed to validate the authenticity of the connection"? It's the security equivalent of telling someone your debit card number just because they called, complimented your shoes, and said they're from your bank.
Some background: an SSL connection relies on the server presenting a certificate that's signed by a trusted authority such—you've probably seen "VeriSign" all over the place, one example of a certificate authority. The authority issues a company (say, your bank) a tamper-proof file containing information that your web browser or mail client can use to verify that it's communicating with the actual certificate owner. These files correspond to a private key, a secret piece of information which prevents random people from stealing the SSL certificate and pretending to be the owner.
Not long after Apple released their security update, some cursory sleuthing of the code changes in the update led to the root of the problem. It turns out the flaw was very small—one line of code was duplicated. This tiny problem had enormous consequences, however. The result skipped over an entire section of the code responsible for verifying that a secure connection was made with the server. In practical terms, this meant that the lock icon in your browser's URL bar indicated little more than a false sense of security.
The truth is, mistakes happen. We just don’t expect mistakes of this magnitude from tech giants like Apple, and we certainly don’t expect them to sit around for so long. This vulnerability has apparently been around since September 2012, meaning that almost every one of your iPhone, iPad or Mac's secure connections for the past year-and-a-half has been largely academic in nature. Apple may have discovered the problem just this month, would-be attackers may have known about it as early as October 2012. It's relatively impossible to find out who knew what when, and what stunts they might have pulled with that knowledge in the interim.
The exploit made it trivial to launch what's widely known as a "man in the middle attack," in which a nefarious party sits in between your communications with a so-called "trusted" website. If they can fool your browser into thinking it's secure, as this bug allowed, then they're free to collect details such as your username and password, or to redirect you to a malicious website.
To make matters worse, this bug was present even on the most recent releases of the OS X operating system. While an iOS update was announced last Friday, an update for OS X wasn't released until earlier this week, leaving legions of Mac users exposed to a highly-visible, and easily exploitable, security flaw.
This is a Bad Thing™.
To illustrate how easy this vulnerability is to exploit, I wrote some code to show it in action. My proof-of-concept was a proxy server, a piece of software which sits between your web browser and a network. Proxy servers are extremely common on the web, often used in high-traffic areas to prevent users in the same location (at a school, for example) from tying up an internet connection by requesting the same resources over and over again. When your browser tries to talk to Facebook, what can happen is that a proxy server intervenes, often serving up data from a local cache without the request ever going all the way through.
My code acts like a normal (but useless) proxy server most of the time—that is, until it sees an SSL request from a known-vulnerable piece of software. When it spots these opportunities, it steps in and makes the secure connection to the requested site, just long enough to obtain a copy of its certificates. It then serves these stolen certificates to the browser in such a way as to trigger the bug, causing the browser to accept the connection without performing any actual verification. For the sake of example, my proxy just redirects you to a joke page asking for your credit card number and SSN. Probably not the page you were trying to hit, but your browser is convinced that it's on a secure connection.
My code demonstrates how easy it was to exploit this bug, and just how vulnerable your connections have been:
https://github.com/gabrielg/CVE-2014-1266-poc
But, we’re supposed to trust the Big Guys like Apple. What security lessons can we learn from this mess?
- Make sure you stay on top of your software updates. Reboot! Don’t lag behind—you never know when something like this could be out in the wild.
- When possible, activate multi-factor authentication for online services. This means that your bank, for example, will send you a text when you try to access their site, to verify that you are who you say you are. It may be an added step and a little more hassle, but it's better to be safe than sorry.
- Remember that everything can be broken. Society grows increasingly reliant on devices and machines, but the software running on these devices is written by humans—and humans are flawed. Assess the risks you're taking online accordingly. Do you have an idea or secret that's world-shatteringly important to you? Consider not putting it online at all.
What happened at Apple was a flaw in process at multiple levels. There are testing methodologies, both automated and manual, which would have detected this issue early on, or prevented it altogether. At Table XI, we review and test all of our code thoroughly—even more so when security is involved. Our tests run every time that so much as a single line of code is changed, and we run additional analysis tools to help identify problems the tests may have missed. Before any change gets released to customers, it's reviewed by at least one developer other than the original author.
The extra time and effort involved up front is still far less troublesome than the time and effort involved in explaining to customers how all their credit card information ended up being sold for a dollar on some shady internet forum. Apple has a major public relations disaster on their hands here, especially after selling customers on the security of Macs and iPhones for years. They're obviously big enough to weather this storm, but an error of this scale would be devastating to the businesses and brands of many small companies, including the ones we work with.