Let's consider two attacks conducted against mobile applications, one looking to identify and exploit issues with the application itself while the other attempts to use the application in order to target its server-side component.
The first attack is where an attacker directly looks for vulnerabilities or weaknesses in a mobile application in order to achieve their goal. In this scenario, the attacker has moved through the steps within the following high-level methodology, similar to Lockheed Martin's Cyber Kill Chain:
The attacker has conducted reconnaissance to identify the vulnerability, created a piece of malware to exploit it during weaponisation and then delivered the malware to the victim users.
The second attack is where the attacker uses the mobile application in order to carry out further attacks against the server the application speaks to. The attacker in the second scenario will follow a very similar set of steps when attacking the server, however, a few steps are added at the beginning where they assess and modify the mobile client:
Since the first two steps of both methodologies are mutual to both attack paths and are near the beginning of this chain, it is an ideal place to stop or slow an attacker down.
Let's consider an attack against a hypothetical Android application, MWR Pay. MWR Pay is a reasonably secure application, which features controls such as SSL pinning, two-factor authentication and makes use of the client-server model. This attack will be similar to the one described in scenario two.
During the reconnaissance stage, our attacker will be reverse engineering and debugging the application. As our attacker moves into the weaponisation stage, they are likely to need elevated permissions on the device in order to start carrying out modifications such as hooking and patching. As such, the attacker is likely to root their device, which is easily done on many devices due to publicly available code which is available for this purpose.
Once the device has been rooted, the application can now be hooked in order to have its program flow modified during runtime, which is particularly useful when circumventing existing protections within the application.
Finally, it is possible to directly modify the application binary to achieve the same effect as the previously described hooking. Patching an application may often be seen as a last resort to an attacker, but is certainly a possible avenue of attack if runtime hooking doesn't do the job. Directly modifying the binary requires some detailed and intricate knowledge on the part of the attacker, whereas runtime hooking can be achieved relatively easily using well-documented, publicly available tools.
At this stage our attacker has gained an intimate knowledge of MWR Pay's internals, has modified it to remove security controls and can send specially crafted messages to the server. The attacker is now in a position to start assessing MWR Pay's server.
MWR Pay 2.0 features a series of protections to guard against being debugged, hooked, modified and run on a rooted device. It also features code level obfuscation.
Reverse engineering is carried out in the same manner as described during the previous attack however, this time the attacker cannot convert the Java bytecode into human readable Java code due to the obfuscation that is in place. The application still functions in the same way, so it is entirely possible to determine how the app works just as before, however, now it requires hours of scrutiny in order to extract even the smallest information regarding program flow.
When the attacker attempts to run the application on a rooted device, debug it or hook it as it runs, the application now crashes. This is because MWR Pay's protections are detecting that the execution environment should not be trusted and is halting.
MWR Pay now queries the operating system to determine if it is being debugged and halts execution if this test is positive. MWR Pay's guard against being run on a rooted device is to check the file system for files or packages which are associated with a root user. Finally the last of MWR Pay's new protections concerns maintaining the applications integrity, which is achieved by runtime verification of code segments against known values.
Many of these protections are somewhat simple and can be bypassed by the attacker, however at a significant cost. It is not easy for the attacker to know how each protection has been implemented within the application due to the various ways they can each be achieved, and as such bypassing protections is often a process of slowly and blindly eliminating each possibility. The difficulty of circumventing a single protection is also greatly increased due to the presence of other protections.
These kinds of protections are not designed to make an application secure and free of vulnerabilities, but they are designed to slow and frustrate attackers such that they cannot progress along their methodology and identify that the application is vulnerable. A large amount of time and effort has to be spent just to start finding weaknesses within the application and as such, an application without any vulnerabilities would have no use of these protections. Since it is impossible however to make such a statement about any application, these protections should be considered as part of a defence in depth approach which aims to thwart attackers at every stage of their attack, including reconnaissance.
