Continuing on our journey to understand the Top 10 most exploited mobile vulnerabilities, today we’ll have a look at Client Side Injection which, according to the OWASP Top 10 Project, is the 7th most exploited mobile vulnerability.
What is Client Side Injection?
The name is self-explanatory. Client side injection results in the execution of malicious code on the client side which is 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 data is malformed and is processed (like all other data) by the underlying frameworks supporting the mobile app. During processing, this special data is forces a context switch and the framework reinterprets the data as executable code. The code is malicious in nature and executed by the app.
In the “best-case” scenario, the code runs with the same scope and access permissions as the user that has unintentionally executed this code. In the “worst-case” scenario, the code executes with privileged permissions and much greater scope leading to much greater damage potential than in the “best-case” scenario.
There are other forms of client-side injection that involve direct injection of binary code into the mobile app via binary attacks. This brute-force approach to malicious code execution may lead to even greater potential for damage than data injections.
Are you vulnerable to Client Side Injection?
The best way to find out if an application is vulnerable to injection is to identify the sources of input and validate that user/application supplied data is being subject to input validation, disallowing code injection.
Checking the code is a fast and accurate way to see if the application is handling data correctly. Code analysis tools can help a security analyst find the use of interpreters and trace the data flow through the application. Manual penetration testers can confirm these issues by crafting exploits that confirm the vulnerability. Comprehensive security tools, like Appknox, can help serve both purposes to the best extent.
What kinds of Client Side Injections could happen?
Since data can come from many sources in mobile applications, it is important to list them delineated by what they are trying to achieve. In general, injection attacks on mobile devices target the following:
Data on the Device:
SQL Injection: SQLite (many phones default data storing mechanism) can be subject to injection just like in web applications. The threat of being able to see data using this type of injection is risky when your application houses several different users, paid-for/unlockable content, etc.
Local File Inclusion: File handling on mobile devices has the same risks as stated above except it pertains to reading files that might be yours to view inside the application directory.
The Mobile Users Session:
The Application Interfaces or Functions:
Several application interfaces or language functions can accept data and can be fuzzed to make applications crash. While most of these flaws do not lead to overflows because of the phone’s platforms being managed code, there have been several that have been used as a “userland” exploit in an exploit chain aimed at rooting or jailbreaking devices.
Binary Code Itself:
What is the impact of a Client Side Injection attack?
Technical Impact: Injection attacks such as SQL Injection on mobile devices can be severe if your application deals with more than one user account on a single application or a shared device or paid-for content. Other injection points are meant to overflow applications components but are less likely to achieve a high impact result because of the managed code protections of the application languages.
Business Impact: The business impact of client-side injection is dependent upon the nature of the malicious code executed by the adversary. Typically, malicious code steals sensitive information (passwords; session cookies; personally identifiable information; etc). Hence, the associated business impacts include:
- Fraud; and
- Privacy Violations.
How to prevent Client Side Injection?
OWASP does a great job in listing down the ways you can prevent this issue. If you remember, we discussed that all you need to do is check the input data for validation. While this might be easy in some cases, in some other cases it might be a little more complex.
More or less, following the best coding practices should help you out a lot:
iOS Specific Best Practices:
- SQLite Injection: When designing queries for SQLite be sure that user supplied data is being passed to a parameterized query. This can be spotted by looking for the format specifier used. In general, dangerous user supplied data will be inserted by a “%@” instead of a proper parameterized query specifier of “?”.
- Local File Inclusion: Use input validation for NSFileManager calls.
- XML Injection: use libXML2 over NSXMLParser
- Format String Injection: Several Objective C methods are vulnerable to format string attacks:(i) NSLog, [NSString stringWithFormat:], [NSString initWithFormat:], [NSMutableString appendFormat:], [NSAlert informativeTextWithFormat:], [NSPredicate predicateWithFormat:], [NSException format:], NSRunAlertPanel.(ii) Do not let sources outside of your control, such as user data and messages from other applications or web services, control any part of your format strings.
- Classic C Attacks: Objective C is a superset of C, avoid using old C functions vulnerable to injection such as: strcat, strcpy, strncat, strncpy, sprint, vsprintf, gets, etc.
Android Specific Best Practices:
- SQL Injection: When dealing with dynamic queries or Content-Providers ensure you are using parameterized queries.
- Local File Inclusion: Verify that File System Access is disabled for any WebViews (webview.getSettings().setAllowFileAccess(false);).
- Intent Injection/Fuzzing: Verify actions and data are validated via an Intent Filter for all Activities.