Early this morning, The Intercept posted several documents pertaining to CIA’s research into compromising iOS devices (along with other things) through Sandia National Laboratories, a major research and development contractor to the government. The documents outlined a number of project talks taking place at a closed government conference referred to as the Jamboree in 2012. The projects listed in the documents included the following pieces.
Rocoto, a chip-like implant that would likely be soldered to the 30-pin connector on the main board, and act like a flasher box that performs the task of jailbreaking a device using existing public techniques. Once jailbroken, a chip like Rocoto could easily install and execute code on the device for persistent monitoring or other forms of surveilance. Upon firmware restore, a chip like Rocoto could simply re-jailbreak the device. Such an implant could have likely worked persistently on older devices (like the 3G mentioned), however the wording of the document (“we will discuss efforts”) suggests the implant was not complete at the time of the talk. This may, however, have later been adopted into the DROPOUTJEEP implant, which was portrayed as an operational product in the NSA’s catalog published several months ago. The DROPOUTJEEP project, however, claimed to be software-based, where Rocoto seems to have involved a physical chip implant.
Strawhorse, a malicious implementation of Xcode, where App Store developers (likely not suspected of any crimes) would be targeted, and their dev machines backdoored to give CIA injection capabilities into compiled applications. The malicious Xcode variant was capable of stealing the developer’s private codesign keys, which would be smuggled out with compiled binaries. It would also disable securityd so that it would not warn the developer that this was happening. The stolen keys could later be used to inject and sign payloads into the developer’s own products without their permission or knowledge, which could then be widely disseminated through the App Store channels. This could include trojans or watermarks, as the document suggests. With the developer keys extracted, binary modifications could also be made at a later time, if such an injection framework existed.
In spite of what The Intercept wrote, there is no evidence that Strawhorse was slated for use en masse, or that it even reached an operational phase.
NOTE: At the time these documents were reportedly created, a vast majority of App Store developers were American citizens. Based on the wording of the document, this was still in the middle stages of development, and an injection mechanism (the complicated part) does not appear to have been developed yet, as there was no mention of it.
Secure Key Extraction
Secure Key extraction involved research to pull the GID key by physical de-processing of A4 processor. De-processing appears to be an involved physical process where the chip is chemically broken down in ways that would allow the raw data to be read directly off the chip. The GID key is shared across an entire chip architecture (therefore, across a product line) and used to decrypt the low level boot loader portion of the firmware. This, too was a speculative, citing ongoing research, and not an actual deliverable ready to be put into operation.
In spite of what The Intercept wrote, the key being targeted by CIA could not be used for individual user data extraction on any level, but was used exclusively for boot loader / jailbreak research.
Smurf, a series of projects that outline different forms of embedded surveillance and counter-surveillance for iOS devices, is the only document that claims capabilities. The slide claims “if it’s on the phone, we can get it”, specifically referring to file retrieval. The slide is very broad, however, and does not mention what limitations existed (such as a jailbreak); prior documents imply that a jailbreak or trojan of some sorts would be required.
The most troubling part is the revelation that CIA has targeted App Store developers – a vast majority of whom were US citizens in 2010, when the project appears to have started – to compromise their computers and install a back door. This back door would be used to steal the developer’s private signing keys and provide an injection point back to command and control servers. This would allow for potentially malicious modification (or post-facto automated modification) of the developer’s products, such as adding a trojan, watermark, or other payload, then re-sign the binary using the stolen developer credentials. The project even went so far as to disable the securityd daemon so that it would not warn the developer that their private keys were being expored.
This is very direct evidence of the government seeking to weaken commercial technologies and likely violate a number of laws by attacking complete innocents under no suspicion of a crime. The injection stage could be done a number of different ways:
Compromising the developer’s computer (or computer network) directly to infect Xcode
Performing a MiTM attack to swap the user’s Xcode download with their own
A rogue insider at Apple quietly embedding CIA’s malware directly into the Xcode gold master
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.
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.
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.
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.