Of these options, option 1 and option 3 would make the most sense, as option 2 would require a prolonged delay in waiting for the user to upgrade or reinstall Xcode. Option 3 would likely have been noticed, but still possible, leaving direct infiltration and infection of a developer as the most likely possibility. Again, however, the document made no mention of a method used, therefore it’s plausible that the all important injection method may not have even existed yet.

We don’t know how many developers were compromised, or if the project even made it to the operational stage. Some speculate that only small, third-world remote developers may have been targeted, however such a framework could be used on a large scale. There is, however, no evidence to suggest it was ever used or even ever fully developed.

We also don’t know what products in the App Store were patched to include malicious payloads in them, as that’s not revealed in the slides. What is also unclear is whether the App Store binaries would have been patched prior to submission, or after the fact. Both have their advantages.

It would make sense that more popular paid and free apps would be targeted with larger audiences, if the goal were broad based surveillance. Prior Snowden slides refer to Angry Birds as a target, so it is feasible this may have been one such app, but that’s just speculation. Many free flashlight apps, and other such free apps, have been flagged by many as containing tracking code by the manufacturer, and would also make ideal targets. The sandbox in 2012 wasn’t what it is now, and there were plenty of techniques that could have broken out of the sandbox to capture private user data; in addition to that, Mac desktop apps (which generally have far more access) were allegedly targeted for back doors. Today, such vulnerabilities have been resolved by Apple, however others could exist.

Jailbreak Research

Another interesting document to mention is secure key extraction. Attempts to extract the GID keys out of iOS devices, with no mention of the UID keys. This is significant. The difference here is that the UID key would have allowed CIA more-or-less a “forensic” level access to the encrypted data on one phone, at least prior to iOS 8. The UID key is what you’d want to get if you made an arrest and were looking to scrape data off of a suspect’s device. Instead, what CIA was trying to get instead was the GID, which is a key shared across an entire chip architecture (e.g. product line), that’s used for decrypting the low level boot firmware on a device. The document outlined the need for private exploit development across the entire A4-based product line. What that tells us is that CIA was NOT interested in getting forensic level access to personal data on a seized device in physical custody, but is instead more interested in cooking their own low level boot firmware to potentially deploy across an entire product line of device. With a private cache of exploits and/or cooked boot loader firmware, CIA could potentially infect millions of devices with malicious firmware to give them persistent access to monitor or surveil devices worldwide. This presentation, however, only appears to be in the research stages, and did not claim any capabilities or deliverables suitable for an operation. Again, likely ongoing research.

This entire archive of recent slides is important to consider, even though it is not much information, because it underscores the targeting of innocent Americans, specifically with the goal of widespread mass surveillance instead of the targeted surveillance that has been claimed thus far. In other words, the goal of these projects were not to use only against known enemies of the state, but rather to target innocents in a much larger dragnet.

Moving forward

Knowing that App Store developers may have been targeted by CIA (me potentially being one of them), I recommend that all devs conduct a full audit internally. If you suspect your devices may have been compromised, consider replacement hardware, and not simply device wipes. At the very least, it’s not a bad idea to perform a complete wipe and reinstall from fresh and trusted gold masters, if hardware replacement is not viable. Download and install OS X and Xcode from a trusted network that is not at your place of business or personal residence. Ensure that the SSL certificates match Apple’s. You can use Gibson Research’s online SSL fingerprint tool to obtain a fingerprint for Apple’s servers. There is no evidence that any of these were deployed operationally, however it’s important to check.

In general practice, isolate your development computers from your personal ones so that no dev machines are connecting back to Apple (or anywhere else) with personally identifying account information, or any other information that could identify the machine as a development machine. Consider isolating the development and build process to an isolated machine that is not connected to the Internet, and perform all testing and distribution on a separate machine.

I personally recommend against using GitHub or any other publicly reachable repository to store source code. Given what the Snowden documents have already revealed about the targeting of private industry, it is highly likely (in my opinion) that the encrypted traffic to these systems may have been compromised by any number of prior SSL vulnerabilities, or that the systems themselves may be compromised without even knowing it. NOTE: This is just my opinion and personal advice; I have no evidence to believe that GitHub or other similar systems have been compromised.

A full audit of the Xcode gold master should be performed by Apple to ensure that it hasn’t been tampered with by an insider at Apple. At the moment, it does not appear that the latest version of Xcode is actively compromising machines, however this does not guarantee that code wasn’t injected somewhere at some point.

The Implications

If this project ever made it to active operation, the implications of this would be very serious. We are talking about violating Apple’s core mechanism for trusting binary code from developers. Compromising this system makes it impossible to fully trust developer code running on current iOS 8 devices, and cleaning up after such a compromise would require Apple to revoke and re-issue all developer certificates. Such a weakness in Apple’s mechanism would warrant a complete redesign, which could cost millions of R&D dollars to rectify in future versions of OS X and iOS.

At the same time, language in the slide suggests this project may have been in its research stages, and never fully operational. For example, the phrase “we discuss our explorations of the Xcode SDK”. They do not claim “exploitation” or discuss a specific deliverable here, suggesting it is still in the research phase. The classification level was also established to “Secret” and “No Foreign” (S//NF), rather than “Top Secret” (TS); in my experience, Secret is a common clearance level for projects that are being actively pursued by the government, but not yet operational. Typically, after projects show progress and merit, they can be classified as secret, however only up until they become recognized as important to national security do they receive a TS classification. The project was likely coming along well enough to achieve any classification at all, and the existence of the NF classification (preventing them from releasing it to foreign nations) suggests that CIA’s use of the project likely extended to target foreign nations, as you’d expect.

Sandia National Labs is a federally funded research and development facility. As such, projects are individually funded based on merit, and undergo an almost “sales-like” pitch approach to secure future funding, both internally within Sandia and externally to federal agency customers. It is possible that this project may never have advanced beyond mere research, as evidenced by phrases in the slide such as, “we discuss our exploration of the Xcode SDK”. Language such as “exploitation”, or discussing a deliverable payload is not included. This could amount to nothing more than an over-hyped presentation to get more funding. It’s possible, however, that given the age of this document, the project may have progressed to a fully operational state.

Given the level of technical detail and its classification, my best educated guess is that the project was probably in its middle stages of development, likely had a working prototype, and may have been working on payload delivery. Otherwise, it wouldn’t have been the topic of a talk at a research conference, but rather an operational tool put into use.

In any case, not only Apple, but individual development teams, need to audit their systems. Apple needs to give some fresh thought to the design of their codesign platform that would resist a nation state as an adversary. Just the fact that government research dollars were funding this effort underscores the importance of redesigning it to be more resistant.

How to Tell if You’re Compromised

How do you test for a backdoor you’ve never seen before? Here’s a preliminary litmus test to test for the Strawhorse backdoor. There’s no guarantee this will work, but it would be good to test anyway.