The security status of mobile applications is not strong; the vast majority of Android and iOS applications in each industry and industry do not even have the most basic security protection measures. As a result, they can be compromised with very little time and energy. For example, the “Verizon Mobile Security Index 2021” found that 76% of respondents are under pressure to sacrifice mobile security for expediency.
At our company, we regularly analyze applications from Fortune 500 companies to help evaluate their security vulnerabilities through black box penetration testing. Almost all applications we see can be destroyed within 15 minutes. It is not that the developers did not implement any security measures, but that they took measures. But in most cases, using freely available tools can easily circumvent the limited protection measures we encounter. Generally speaking, security flaws can be divided into three categories.
1. Insufficient or incomplete application enhancement
The first line of defense in any mobile application security strategy should include the implementation of basic runtime application self-protection (RASP) measures (such as anti-tampering, anti-debugging, anti-reversal, and jailbreaking/rooting prevention. Our security team rarely encounters The application is an application with one of the above protection measures, and we often find that these protection measures are implemented on the surface (for example, tamper-proofing is only checked once when the application is initialized) or hard-coded as mostly-obfuscated source code.
2. Lack of confusion
Code obfuscation makes it difficult for an attacker to understand the source code and control flow of the application. Hackers use open source, freely available disassemblers, decompilers and debuggers to reverse engineer mobile applications and understand the source code. Using this information, they can conduct more successful attacks.
Even more skilled cybercriminals can use dynamic toolkits such as Frida to attach to running processes, remotely hook into applications, and dynamically inject code into memory at runtime, allowing attackers to Change the behavior, function, logic and state of the application throughout the process. The application is running. In addition, these tools can help them cover their tracks so as not to be discovered.
For example, Facebook recently announced that malware embedded in Chinese hackers was found in many popular Uyghur-themed Android apps distributed in the online app store they established. These apps target, track, and monitor activists and journalists from Uyghur groups living abroad.
3. Insufficient or insufficient encryption
The third major area is the lack of data protection. Most applications use weak encryption or insufficient encryption, and some applications completely ignore the encryption of the data stored in the code. For example, in our security audits, our security researchers almost always have access to highly sensitive API keys and secrets stored as strings in the application. When usernames and passwords traverse the network, such as when users log in to a mobile banking application, we can also intercept them. Other places where we find a lot of unprotected data are application preferences, XML strings, and application resources.
You may want this data to be encrypted by default. In short, this is not the case. Encrypting data can complicate the sharing of authentication and authorization with back-end servers and other applications, and if encryption corrupts the data, it can degrade the user experience. In addition, there are many dizzying options in terms of key size/strength, key derivation technology, password strength, and encryption algorithm. If the wrong choices are made, then each choice will have a huge impact on performance and safety.
As a result, in the name of rapid application release and smooth user experience, these key areas of mobile application security often appear to be out of reach. However, the consequences can be dire. These security flaws enable hackers to take over accounts, disrupt financial transactions, perform screen coverage and man-in-the-middle attacks, remotely inject code, and create Trojan horses that look and feel like real things.
Make sure these vulnerabilities are difficult to exploit
To bridge such a huge security hole, a multi-layer application defense composed of complementary and self-reinforcing functions is required. To this end, developers need to implement a variety of application shielding technologies, such as anti-tampering, anti-debugging, anti-reversal, checksum verification, and application integrity checking, all of which can be used in different native and non-native API layers of the application Run on. The data stored in the application sandbox and any other data in the application must be encrypted using a dynamic key generation method using a static key to encrypt the data at rest. The data in transmission must be protected from man-in-the-middle (MitM) attacks by implementing certificate verification, certificate authority verification, and secure certificate fixation. Developers must obfuscate native and non-native code, libraries, frameworks, classes and objects, as well as application logic and debugging information.
Encryption and obfuscation are both difficult and complex, but implementing them is not as painful as major hacking attacks, which may cause countless losses to the company’s IT infrastructure, finances, and brand. It’s worth taking the time to do the right thing.
Alan is the vice president of security products at Appdome. Alan is a long-term product executive and serial entrepreneur, having previously served as the product leader for Palerra (acquired by Oracle) and Arcsight (acquired by HP).View the complete bio