The revelation of WireLurker ends the era of innocence for mobile software platforms. Today, mobile applications provide more than fun and entertainment. Day by day, applications are integrating tightly with our jobs, health, and finance. Jailbroken phones have long faced the malware threat, and WireLurker is a prime example of how the security of any app on any device is at risk. Organizations providing mobile applications invest in perimeter and infrastructure protection. WireLurker illuminates that mobile applications expand the perimeter to include new risks that may be neglected.
Mobile application developers employ best practices to engage in a range of application security activities across the SDLC. Threat modeling, architectural risk assessment, source code review, penetration testing, application monitoring, and more mitigate a whole range of software vulnerabilities before the app even leaves the development environment. Traditional software security methodologies assume that the attacker is on the outside looking in. Mobile applications are encrypted to prevent an attacker from analyzing the code. Unfortunately, the reality is that with just a few seconds and freely available tools an iOS application is easily decrypted. That shouldn’t be surprising, after all, the device must execute the code! Once the decrypted binary is revealed, the reverse engineering process begins. The attacker is now looking at the application from the inside out.
WireLurker demonstrates that even if the traditional methods are implemented perfectly and the code is believed to be vulnerability-free, the application’s binary code is still at risk. As a result, the impact of all the other security investments could be jeopardized as well. The perception that binary code is inherently more secure is giving way to the reality that attackers have an arsenal of tools at their disposal. For instance, several tools automatically decompile binary code to nearly perfect source-code. Attackers will always choose the path of least resistance, and there is another way to attack in iOS.
Until Apple fully replaces Objective-C with Swift, much of the iOS SDK carries another risk that is trivial to exploit. An interesting feature, provided by the Objective-C language, is called dynamic programming. Essentially, the programming language allows a programmer to redirect or “swizzle” an API at run-time. Attackers use this to intercept APIs and understand the data and control flow of the app. Wirelurker uses the swizzling attack, combined with a dynamic library, to exfiltrate user data without even modifying the code.
For a long time, Apple has prohibited an App Store app from loading dynamic libraries. On the other hand, the enterprise provisioning profile attack enables the attacker to bypass this restriction. The attack requires that the user trust the profile, but that’s about to change. At WWDC14, Apple announced that iOS 8 permits developers to deploy apps with Frameworks. Inside a framework is binary code, which could provide a vehicle repeat this attack with even less effort. The inadvertent acceptance of a bogus provisioning profile is no longer required!
Not all is lost. The difficulty to reverse engineer an app is dependent on three things; the attacker, the code, and time. The attacker is independent of the application developer. However, the developer can influence the code complexity and time availability. Mobile software is unique with the ubiquitous App Store approach. Updates are readily available, and can be applied without any user intervention. If the software is difficult to understand and updates are frequent, the attacker will fail and likely move on to an easier target.
To change the complexity of the code, obfuscation and “run time” checks can increase the time required to analysis. The obfuscation converts normal operations into a network of code that executes quickly, but require orders of magnitude more time to understand. The inclusion of “run time” protection that checks the fidelity of the environment, an app can determine if an API is swizzled, or if the phone is jailbroken. Open Source and commercial solutions are readily available that extend protection beyond the perimeter.