Since the global launch of AppSolid® in 2016, the mobile app security solution has been hard at work protecting various Android and iOS applications. These hardened applications are distributed across different industries, such as finance, gaming, healthcare, and enterprise-class customers. It has been 3 years since AppSolid® emerged on the mobile application scene, and we thought it’s about time we share the savings our customers have realized thanks to damage prevention by AppSolid®.
In this article, we share the results of our mobile application incident analysis. For the analysis, we sanitized over 10 million tampering records by 1 million unique devices, taken from over 30 customers applications with 973 versions where the amount of MAUs (Monthly Active Users) exceeds 100,000. This is to ensure the study focuses only on commercially distributed application versions. We analyzed them by comparing the total number of activations by unique device identifiers and the number of unique MAUs as each application version has its own unique identifier. We then examined the patterns of usage, traced the ratio of each app access count, and each app’s unique monthly user count in correlation with the incidents.
Understanding the Risks
Our data shows the mobile app attack attempts tracked in 2018 across the globe. The US showed the biggest number of unique devices used for such attempts, 238,149, followed by China, 144,556, and Brazil, 119,241.
The pie chart below shows 4 tampering categories, aggregated from the over 20 types of tampering events categories that AppSolid® detects.
According to the data, code tampering is the most frequent type of attacks, followed by memory tampering and privileged execution. Hooking is used the least as it is under 1% of the total tampering attempts. In the next section, we will review each category and the nature of such attacks. We will also analyze the estimated number of damages for the applications. Further, we will also discuss reversing, an incident category that’s not on the pie chart but can severely impact applications.
1. Code Tampering
As shown, code tampering is the most common type and accounts for over 49% of the total tampering attempts. There are different methods of code tampering, such as dex manipulation, asset replacements, binary code injection on native libraries, editing dex, ELF, MACH-O files, or any other original manifests.
Our detection history indicates most of the code tampering events tried to modify a library or an asset in an application package. Often times, such attempts were wrapped in fake apps that impersonate the original ones with different assets and libraries. The incidents tried to override billing features or enable certain product features that require a payment.
Under the code tampering category, 27.6% of the attempts used tools, both well-known and customized ones, while 1% of them tried re-wrapping the original application in a forgery attempt. Offline tampering incidents were very rare, less than 0.08% of the category, which targeted popular financial and travel applications.
The purposes of code tampering are included below:
- Re-wrapping applications as a vehicle to distribute potentially harmful applications
- Replacing the original payment and ad settings
- Bypassing the in-app billing process.
2. Memory Tampering
This category includes both direct and indirect memory tampering methods. Some of the detected incidents show if binary patchers were used, or if the identified device attempted to directly modify the process memory in runtime, or to change or inject data values from external applications.
93% of the category originated from a debugging shell session on a device using command line tools that try to analyze targeted apps’ memory and logs. The rest of the memory tampering attempts used patchers for the billing process on device. In-app purchase patching is one of the most common use cases, and AppSolid® has blocked over 50 variants of the LuckyPatchers packages. The most popular patchers in 2018:
- com.android.vending.billing.InAppBillingService.COIN: 0.5% of the incidents in this category
- com.android.vending.billing.InAppBillingService.CRAC: 0.25% of the incidents in this category.
Overall, the billing patchers take up over 1% of the attacks in this category, while using direct memory patchers was less than 1%. This category also includes multiple variations of RootCloak/XPosed, which are mostly used by game and hax patchers.
It is unclear what the revenue model is for developers behind application patchers because most patchers are free while some offer premium versions at a low cost. However, it is not surprising to find such patchers being connected to known C&C servers and install potentially harmful applications or malware on the hosting device.
3. Privileged Execution
This category indicates attack attempts through privileged access from rooted or jailbroken devices. 23% of the recorded incidents show that rooted Android devices or jailbroken iOS devices were used. It allows attackers to directly inject a dynamic library or a shared object. It also permits tampering app data, files, containers, and the memory process.
To get detailed ideas on the used devices, we collected over 20,000 variations of device identifiers that ran over 23,000 operating system versions that are related to the recorded attempts. The charts below show Android and iOS versions that attackers used.
4. Hooking incidents
Although the ratio of hooking incidents is relatively low compared to code tampering and memory tampering, however it is still worth noting hooking incidents. We noticed that even after the initial attempt failed to inject a module into the running process, attackers persist and try again sometimes as often as 100 times per session from the same device utilizing different parameters and values, such as targeted methods, classes, modules, and functions. Most of the discovered fuzzing attempts are discussed in the reversing section, but some notable incidents suggest a combination of Frida and Radare in an attempt to break the application’s protection.
In this category, we tracked over 8,000 incidents from almost 1,900 unique devices where hooking attempts were made on various operating systems, devices, and platforms. On iOS, runtime hooking was detected on various iPhone versions and iOS emulators from version 9.2.1 to 12.1. Runtime hooking utilizes known research tools and techniques, but may also involve novel ideas and methods to inject or replace functionality of running applications.
5. Reversing attempts
Reversing was a very small share of all incident attempts – it wasn’t even included in the overall incident pie chart above. However, the impact of a reversing session on an application has the most damaging impact on customer revenue and the users of the targeted app. This is why we are dedicating a separate section for reversing.
In this category, less than 0.2% used debugging tools and methods. Also, there are recorded attempts to bypass the AppSolid® protection layer by using fuzzers mostly on Android (AFL, Trinity, Syzkaller). Virtual machines were used as we saw some attempts to perform dynamic analysis or execution on our customers’ applications. Most of the incidents were originated from Android applications, but debugging attempts were a common incident type on iOS applications.
According to our database, over 52% of the debugging attempts were made on financial and banking apps. Also, about 24% of the reversing attempts tried to break a commercial framework license. Other targeted industries include DRM (Digital Rights Management), healthcare, IoT, gaming and even cybersecurity mobile threat defense applications.
Calculating the Cost of Damages
According to the data shared by App Annie on Tech crunch, the Android and iOS app markets continue to grow, and global customer spending surpassed $76 billion in 2018. Considering the high volume of spending in the app market, how much would these attacks have cost if the recorded incidents above succeeded?
Of course, our records do not represent the entire market, but we thought it would be interesting to measure the cost of what we have. We also took it into consideration that one compromised application version may indirectly affect other versions of the same application due to existing users’ online interactions.
We quantified each attack type to have a better understanding on the motives and financial benefits of attackers. However, in the process of the cost estimation, we did not include potential reputation and credibility damages as those are rather qualitative attributes.
We calculated the potential damage cost by using estimated SLE (Single Loss Expectancy) per incident type, and created the value of ALE (Annual Loss Expectancy). ALE was quantified by the total number of incidents per year multiplied by SLE.
1. Code Tampering
The major targets in this incident category were productivity, gaming, and smart home apps. The calculated cost here is done from the perspective of application vendors, even though in-app purchase tampering can potentially harm OS vendors, such as Google and Apple.
Considering that code tampering is not a complicated attacking method, we conservatively set the value for SLE as $5. There were 863,153 unique devices used for code tampering, and the total recorded number of the incident attempts was 3,040,460. The total number includes Android tampering, Android dex tampering, iOS tampering, and offline tampering.
Total Code Tampering ALE = 3,040,460 x $5
With the above formula, the code tampering damage could have costed $15,202,300 if the attempts were successfully. Thankfully, AppSolid® prevented them.
2. Memory Tampering
The motives behind memory tampering are unclear, and it can result in major impacts on the app business as all of the released versions can be compromised. The potential damages are in the areas of program constraint removal, bypassing payment, and looting in-app purchase revenue.
Memory tampering tools are widely available on the web, making them easy to access. Using them also does not require much of technical expertise, so we estimate each SLE to be $5. Our data shows that 505,678 unique devices were used for memory tampering. Moreover, the total number of the incident attempts are 5,414,771.
Total Memory Tampering ALE = 5,414,771 x $5
If all the recorded memory tampering attempts were successful, the total damage could have been $27,073,855.
3. Privileged Execution
We identified several attempts of privileged execution attempts where non-traditional methods, such as confused deputy, which system services act on behalf of the compromising actor, were used.
Rooting or jailbreaking devices does not require a complicated process, and anyone can easily tweak devices. Some early adopters keep their devices rooted or jailbroken for research purposes, as well. For these reasons, we keep the SLE for this incident low at $1. A total of 423,632 unique devices were used for this incident category, and a total of 1,892,808 attempts were made in 2018.
Total Privileged Execution ALE = 1,892,808 x $1
The damage cost for privileged execution in 2018 could have been $1,892,808, which is still calculated in a conservative way.
When a hooking attempt succeeds, it compromises the targeted app and its users. Hooking bypasses the constraints of the app that are designed to encourage in-app purchase. In addition, it infiltrates and extracts information from apps, steals credentials and user information, and alters the app behavior.
Some hooking attempts lead to patch development for offline and online code patching. Hooking is not the easiest method, and requires some hacking knowledge to execute successful attacks. We value SLE as $20 for this incident type, and our records show that there were 2,518 unique devices used in 2018. In total, there were 8,588 incident attempts combining both hooking and iOS runtime hooking efforts.
Total Hooking ALE = 8,588 x $20
It is estimated that $171,760 could have been the damage cost for app hooking incidents in 2018.
5. Reversing attempts
A successful reversing attack can lead to compromising application versions and developing cracks. Reversing incidents are not done in a massive scale, but they are precise and surgical. During the recorded reversing attempts, AppSolid® intercepted debugging, virtualization, and other indicators, which helped us calculate the risk of the released versions along with the cost of mitigations when bypassing becomes successful. Interestingly, based on our data, AppSolid® prolonged the process of reversing attempts to take even 3-6 months, which resulted in attackers giving up and moving on.
Reversing is a complicated and sophisticated hacking method that requires a lot of expertise. This may be one reason why reversing attempts take such a small share compared to other incident types. When reversing succeeds, it impacts the targeted app version entirely, and compromises app users. The damages associated with each successful reversing incident can cost millions of dollars for R&D, operations, and revenue. This is because a remediation has to be deployed to the market, which is the same with a regular mobile app development and release process. Due to the cost that it takes for application development, we estimate $25,000 for reversing SLE. According to our database, there were 808 unique devices used, and total 33,231 reversing attempts were made.
Total Reversing ALE = 33,231 x $25,000
The damage prevented by AppSolid® for reversing attempts is $830,775,000.
The total ALE for all incident types is $875,115,723.
Total ALE = Code Tampering ALE ($15,202,300) + Memory Tampering ALE ($27,073,855) + Privilege Execution ALE ($1,892,808) + Hooking ALE ($171,760) + Reversing ALE ($830,775,000)
The cost is quite high even with the conservatively set SLEs. However, it could be even worse when considering that some of the targeted apps are in finance, healthcare, and smart home industries.. The damages can lead to a snowball effect, spreading from the mobile app attack to web breaches.
Furthermore, as this analysis only captures 30 applications and it does not represent the entire mobile market, we believe that there would be more costs associated to damages than what our ALE indicates.
Cybersecurity has become an important element that business cannot disregard anymore. We have seen many cases how a lack of proper security measures result in financial and reputational harms to businesses. Equifax, Yahoo, Amazon, and Facebook are just a few examples how hacking attacks can affect businesses. With the growing number of victims, It has been stated numerous times that it’s best to invest in cybersecurity in advance, rather than wait until incidents happen. The potential damage cost calculated here strengthens the idea further. We hope that our data provides further insight on why it is important to have security measures in place.