Speculation About Goto Fail
Following the logic in my previous post, I don’t think that Apple’s goto fail was a deliberate attack. Suppose it was, though. What can we learn about the attacker?
The first point is that it very clearly was not the NSA or other high-end intelligence agency. As I noted, this is too visible and too clumsy. While they may not object to that, covertly tinkering with Apple source code is a difficult and risky operation. If an investigation by Apple shows that this was an attack, they’ll move heaven and earth to close the hole, whether it was technical, personnel, or procedural. In other words, using some covert access channel to install a back door effectively "spends" it; you may not get to reuse the channel. In that case, they definitely would not use this one-shot on something that is so easily spotted. (What could they have done? There are lots of random numbers lying around in cryptographic protocols; leak the session key—more likely, a part of it—in one of those numbers. Use convoluted code to generate this "random" number, complete with misleading comments.)
The next question is how this capability can be used. The vulnerability requires a so-called "man-in-the-middle" (MitM) attack, where an attacker has to receive all messages in each direction, decrypt them, reencrypt them, and forward them to the proper destination. If you’re intercepting a lot of traffic, that’s a lot of work. There are a number of ways to do MitM attacks; for technical reasons, it’s a lot easier on the client or the server’s LAN, or with the cooperation of either’s ISP. There are certainly other ways to do it, such as DNS spoofing or routing attacks; that’s why we need DNSSEC and BGPSEC. But ARP-spoofing from on-LAN is very, very easy.
We can narrow it down still further. If the main thing of interest is email and in particular email passwords, the odds are that the victim will be using one of the big "cloud" providers: Google, Yahoo, or Microsoft. You don’t want to tap those nets near the servers; apart from the technical difficulty (they’re good at running their machines securely, and they don’t invite random strangers onto their nets), and apart from the fact that you’d be trying to take a sip from a firehose, it’s hard to figure out where to put the tap. Consider gmail. I checked its IP address from my office, my house, and from a server I sometimes use in Seattle. The IP addresses resolved to data centers near DC, New York City, and Seattle, respectively. Which one should you use if you wanted my traffic? Note in particular that though my office is in New York City and my house is not, I got a New York server from when trying from home, but not when trying from my office.
(There’s another possible attacker vector: software updates. Apple’s updates are digitally signed, so they can’t be tampered with by an attacker; however, that isn’t true for all third-party packages. Tampering with an update is a way to get malicious code installed on someone’s machine.)
The conclusion is simple: go after the client LAN. If it’s a LAN the attacker and the target both have access to—say, an Internet cafe or the like—the problem is very simple. In fact, if you’re on-LAN with the target, you can home in on the target’s MAC address (which doesn’t go off-LAN), making your life very simple. Alternatively, hack into the wireless router or seek cooperation from the hotspot owner or the ISP. (Home routers are easily hacked, too, of course. If the attacker goes that route, there’s no need for MAC-spoofing.)
We can also speculate that the victim is using an iOS device rather than a Mac. If nothing else, Apple sells far more iPhones and iPads than it does Macs. There’s another reason to think that, though: Macs are expensive, and Internet cafes are much more popular in poorer countries where fewer people have broadband access at home. Of course, if they’re using an iPhone in cellular mode, there’s no LAN to camp on, but governments have little trouble gaining access to the networks run by their own telephone companies. Either way, it sounds very much like a targeted attack, aimed at a very few individuals.
My reasoning is, of course, highly speculative. If it was an attack, though, I conclude (based on this tenuous set of deductions) that it was a moderately capable government going after a small set of victims, either on a public net or via the local mobile phone carrier. Most of us had nothing to worry about—until, of course, the patch came out. And why a patch for just iOS, with MacOS waiting until later? Apart from the system test difficulties I mentioned last time, might it be because Apple was warned—by someone!—that this hole was being exploited in the wild? Again, I’m speculating…
Update: Nicholas Weaver notes that putting the exploit station on the victim’s LAN or router solves another problem: identifying which machines may be vulnerable to this exploit. It can look at other traffic from that MAC address to decide if it’s an Apple product, what browser it’s using, etc., and not tip off the victim by pulling this stunt against Firefox or Internet Explorer users.
In principle, this can be done from off-LAN, but it’s harder, especially if the hosts use strong sequence numbers and randomize the IPid field. (Some open source operating systems do that. I haven’t checked on Macs or Windows boxes in a long time.)
