Apple is currently taking measures to eradicate hundreds (potentially thousands) of malicious apps recently discovered in the iOS App Store. It has come to light that hackers distributed a modified version of Apple’s developer toolkit, Xcode, which embedded malware known as XcodeGhost into iOS apps as they were being compiled.
While developers know they shouldn’t use unverified tools, it still happens. The infected software was tracked to a server in China and may have been chosen by developers because downloads were faster than the software available on Apple’s U.S. servers.
Before this attack, only five apps containing malicious code had ever been found in the iOS App Store.
Attacks such as this aren’t only relevant for modified build tools such as the malicious version of Xcode discussed above. Many app developers around the world trust 3rd party plugins which have full access to the compile process. Developers rarely consider the fact that they may be using unauthorized and potentially malicious plugins/tools that may inject malicious code into binaries. This lack of awareness is a serious concern.
This particular type of attack was discovered in 1974 by Paul Karger and Roger Schell, and was described in 1984 by Ken Thompson. Thompson showed how a Trojan horse could be injected into a compiler that would insert a backdoor whenever the source code for the UNIX “login” command was compiled using it; on systems using the resulting “login” binary, the Trojan horse’s author could log in using a known password. The Trojan horse also knew when it was compiling the original source code for the compiler and would inject the Trojan horse into the compiler binary which it was creating. Now, on systems using the modified compiler binary, whenever the “login” command or the compiler itself were compiled, Trojan horses would be injected into them. The source code for the “login” command or the compiler showed no evidence of either virus, making remediation efforts daunting at best.
Analyzing binaries once they are built, or conducting penetration testing on apps once they have been released, provides limited assurance against many vulnerabilities. Secure software begins earlier in the software development life cycle (SDLC). Recognize that there is no such thing as a security meter to measure how secure a piece of software is. Similarly; there is no tool to simply wipe away vulnerabilities.
Since developers were targeted in the iOS attack, this should be a wake-up call. Developers have the power to cross-check the build environment to mitigate their risk. All software in build environments should be obtained from authorized sources, and its integrity must be verified. Now is the time to increase these safeguards, because with one successful breach, copycats are sure to follow suit in due time. Stick to the authorized tools and build processes. Follow best practices to double and triple check that software in your build environment is trusted.
Ensure that everything you’re using comes from a trusted source.
Developer attention to detail and initiating a software security initiative (SSI) early in the development process is critical. Software security strategy begins with an understanding of your current security state, goals for the future, and a roadmap to achieving those goals.