Hacking Android Notes

App's attack surface

Threats at the client side

• Application data at rest: With the introduction of mobile applications, the concept of storing data at the client side has been drastically adopted. Many mobile applications store sensitive data on the device without any encryption. This is one of the major problems of mobile applications. This data can be sensitive, confidential, and private. Data that rests on the device can be exploited in many different ways. An attacker who has got physical access to the device can gain access to this data almost without doing anything. A malicious application may gain access to this data if the device is rooted/jailbroken. It is important to make sure that apps do not store sensitive data such as usernames, passwords, authentication tokens, credit card numbers, and so on, on the device. If it cannot be avoided, it is required to encrypt it and keep it away from an attacker's control. We will explore more details about insecure data storage vulnerabilities in Chapter 5, Data Storage and Its Security.

• Application data in transit: Mobile applications that communicate with the backend are highly exposed to attacks that target the data in transit. It is quite common for end users to join publicly available networks at coffee shops and airports where an attacker may sit in and eavesdrop on the data using tools like burp proxy, MITM proxy, SSL MitM (short for Man in the Middle attack) proxy, and so on. With the introduction of smart phone apps, exploitability of such attacks became very easy as mobiles follow us wherever we go.

• Vulnerabilities in code: Mobile applications when developed with no security controls in mind can become vulnerable to various attacks. These coding mistakes in the app can lead to a serious vulnerability in the app, which in turn impacts the user/app data. Examples of such mistakes include, exported content providers, exported activities, client side injection, and so on. Attack scenarios include, an attacker who has physical access to the device may gain access to another user's session. A malicious app sitting on the same device can read the content of the other apps when they expose data due to coding mistakes. An attacker who has access to the binary may decompile the application and view the hardcoded credentials in the source code.

• Data leaks in the app: This is another issue in mobile applications in almost all the platforms. It is possible that an app may unintentionally leak sensitive data to an attacker. This requires extra attention from the developer. The code he uses for logging during the development phase must be removed and he must make sure that no data is prone to leaks. The main reason behind focusing on this is that application sandboxing will not be applicable to some of the attacks in this class. If a user copies some sensitive data such as a security answer from an application, this will be placed on the device clipboard, which is out of the application sandbox. Any other app sitting on the same device can read this data copied without the knowledge of the first app.

• Platform specific issues: When designing a threat model for mobile applications, it is important to consider the threats associated with the platform that this app is going to run on. Let us consider an example with Android, native apps that are developed for the android platform can be easily reverse engineered and the Java source code can be easily viewed. It allows an attacker to view the source code as well as any sensitive data that is hard coded in the code. It is also possible to modify the code in the application and re-compile it and then distribute the apps in third party markets. Performing integrity checks is something that has to be considered if the app is sensitive in nature or if it is a paid app. Though the above-mentioned issues are relatively less effective in a platform like iOS, it has got its own platform specific issues if the device is jail-broken.

Threats at the backend

• Authentication/Authorization: When developing backend APIs it is very common to build custom authentication. It is possible to have vulnerabilities associated with authentication/authorization.

• Session management: Session management in mobile platforms is typically done using an authentication token. When the user logs in for the first time, he will be given an authentication token, and this will be used for the rest of the session. If this authentication token is not properly secured till it's destroyed, it may lead to an attack. Killing the session at the client side but not at the server is another common problem that is seen in mobile apps.

• Input validation: Input validation is a known and common issue that we see in applications. It is possible to have SQL injection, Command Injection, and Cross Site Scripting vulnerabilities if no input validation controls are implemented.

• Improper error handling: Errors are attractive to attackers. If error handling is not properly done, and the API is throwing database/server errors specific to the crafted request, it is possible to craft attacks using those errors.

• Weak cryptography: Cryptography is another area where developers commit mistakes during their development. Though each platform has support for proper implementations to secure the data cryptographically, key management is a major issue at client side. Similarly, data storage at the backend requires secure storage.

• Attacks on the database: It is also important to notice that attackers may get unauthorized access to the database directly. For example, it is possible for an attacker to gain unauthorized access to the database console such as phpMyAdmin if it is not secured with strong credentials. Another example would be access to an unauthenticated MongoDB console, as the default installation of MongoDB doesn't require any authentication to access its console.

OWASP TOP 10 2014

M1: Weak Server-Side Controls

Weak Server-Side Controls talk about the attacks on the application backend. Most of the applications today use an Internet connection and they communicate with the backend servers using REST or SOAP APIs. Security principles associated with the traditional webservers and web applications will remain the same as we are simply using a different frontend (Mobile Client) and the backend is still the same. Typical attack vectors include finding out the entry points in the exposed APIs and fuzzing them for various vulnerabilities, exploiting misconfigured servers, and so on. Almost all the traditional OWASP top 10 vulnerabilities are applicable to this section.

M2: Insecure Data Storage

Developers assume that the data stored on a device's file system is not accessible to attackers. With this assumption, developers often store sensitive data such as usernames, Authentication tokens, passwords, PINs, and Personal Information such as DOB and Addresses on a device's file system using concepts such as shared preferences or SQLite databases. There are multiple ways to access this data stored locally on a device. The common techniques would be to root the device and access the data, use backup based attacks and so on. We will discuss these exploitation techniques in the next chapter.

M4: Unintended Data Leakage

When an application processes sensitive information taken as input from the user or any other source, it may result in placing that data in an insecure location in the device. This insecure location could be accessible to other malicious apps running on the same device, consequently leaving the device in a serious risk state. Code becomes vulnerable to serious attacks, since exploiting these side channel data leakage vulnerabilities is very easy. An attacker can simply write a small piece of code to access the location where the sensitive information is stored. We can even use tools like adb to access these locations. Here is the list of example scenarios where unintended data leakage flaws may exist:

• Leaking content providers

• Copy/paste buffer caching

• Logging

• URL caching

• Browser cookie objects

• Analytics data sent to third parties

M5: Poor Authorization and Authentication

Mobile apps, as well as devices, have different usability factors than what we have in traditional web applications and laptop computers. It is often required to have short PINs and passwords due to the mobile device's input form factor. Authentication requirements for mobile apps can be quite different from traditional web authentication schemes due to availability requirements. It is very easy for an attacker to brute force these shorter PINs in the application if no controls are enforced to prevent such attacks. We can test for poor authorization schemes by trying to access more privileged functions of the application by crafting malicious requests to the server and seeing if these requests are served.

M6: Broken Cryptography

Broken cryptography attacks come into the picture when an app developer wants to take advantage of encryption in his application. Broken cryptography in Android apps can be introduced due to various reasons. The two main reasons as mentioned in the OWASP Mobile Top 10 Project are as follows:

• Using a weak algorithm for encryption/decryption: This includes the usage of algorithms with significant weaknesses or are otherwise insufficient for modern security requirements such as DES, 3DES, and so on

• Using a strong encryption algorithm but implementing it in an insecure way: This includes storing keys in the local database files, hardcoding the keys in the source, and so on

M7: Client-Side Injection

Client-side injection results in the execution of malicious code on the mobile device via the mobile app. Typically, this malicious code is provided in the form of data that the threat agent inputs to the mobile app through a number of different means. The following are some of the examples of Client-Side Injection attacks in Android apps:

• Injection in WebViews

• Traditonal SQL Injection in raw SQL statements used with SQLite databases

• SQL Injection in content providers

• Path traversal in content providers

M8: Security Decisions via Untrusted Inputs

Developers should always assume that malformed inputs can be given by unauthorized parties to abuse the sensitive functions of an application. Specifically in Android, an attacker can intercept the calls (IPC or web service calls) and tamper with such sensitive parameters. Weak implementation of such functionality leads to improper behavior of an app and can even grant higher level permissions to an attacker. One example would be to invoke sensitive activities by using malformed intents.

M9: Improper Session Handling

Mobile apps use protocols like SOAP or REST to connect to services. These protocols are stateless. When a mobile client application is used with these protocols, clients get a token from the server after authentication. The token generated by the server will now be used during the user's session. OWASP's Improper Session Handling talks about attacking and securing these sessions. One common problem that is often seen in mobile apps is invalidating the token at the client side and not at the server side. Usually, the token received by the application will be placed on the client's file system using shared preferences or SQLite databases. A malicious user who gains access to this token, can use it at any time if the token is not properly invalidated at the server side. Other possible scenarios are session timeouts, weak token creation, and an expired token.

M10: Lack of Binary Protections

Reverse Engineering is one of the most common problems seen in the majority of Android apps. One of the first steps attackers perform when they get an app binary is to decompile or disassemble the application. This allows them to view the hardcoded secrets, find vulnerabilities, and even modify the functionality of the application by repacking the disassembled application. Though obfuscating the source code is not a hard thing to do, the majority of the apps do not appear to do it. When the code is not obfuscated, all an attacker needs is a nice tool such as apktool or dex2jar to get the work done. Some applications check for rooted devices. It is also possible to bypass such checks by reversing the app or by manipulating the application flow by hooking into it.