Why Mobile Application Security?
With the ever increasing penetration of Mobile apps into our day to day life, it’s imperative that Mobile Applications will be at the behest of hackers and Security professionals likewise.
Thanks to phenomenal advances in mobile device capabilities, everything from shopping, banking, recharge, booking tickets and many such activities are performed with the help of a smart phone alone. Hackers are finding more ways to steal data through mobile applications.
Mobile apps can be broadly classified into 3 types:
- Native Mobile App – installed on the device, is developed specifically for one platform and can work offline. Some native apps are calendars, calculators, built-in browsers and office applications.
- Web-Based Mobile App – is an actual website that gives the look and feel of native apps but is implemented differently. They are run by a browser and are typically written in HTML5. Some web-based mobile apps are popular social networks (the versions that are accessed through the browser), email and chatting applications and online mobile games.
- Hybrid App – is a combination of both Native and Web App. Discovery health and fitness app is an example of an hybrid app that redirects to the website to complete some requests.
In Part – 1 of this article we will be discussing about iOS application security Testing and the different tools available for the same.
An iOS application typically runs on an iPad, iPhone, or an iPod touch and is written in Objective-C programming language. The iOS app is stored in an .ipa file that is an iOS application archive file.
REQUIRED TOOLS:
The first requirement to start the security testing of an iOS app is that the device on which the app is installed should preferably be a jailbroken device. The other tools that will be required are:
- Itunes
- iPhone explorer
- iPhone config utility
- hex editor
- Charles proxy
- class dump-z.0.2
OWASP TOP 10 MOBILE RISKS:
The OWASP top 10 mobile risks should be kept in mind while testing any mobile app. These risks are as follows:
- M1: Weak Server Side Controls
- M2: Insecure Data Storage
- M3: Insufficient Transport Layer Protection
- M4: Unintended Data Leakage
- M5: Poor Authorization and Authentication
- M6: Broken Cryptography
- M7: Client Side Injection
- M8: Security Decisions Via Untrusted Inputs
- M9: Improper Session Handling
- M10: Lack of Binary Protections
The entire security testing of an iOS application can be divided into the following phases:
- Interception of traffic from and to the mobile application and server
- Local storage – Data stored locally on the device
- Logging – Data stored in the logs generated
- Decompilation – Getting the code from the .ipa file by reverse engineering
Interception
To intercept traffic from and to the mobile application and the server any proxy tool like Burp, Fiddler or Charles can be used. Interception is generally done to view / modify requests going from the mobile app to the server and check if these modified requests are accepted and executed by the server.
There are a few settings that need to be done in order to intercept traffic. They are:
- Make sure that the iOS device and the proxy tool (Burp, Charles) are on the same network
- Check the proxy settings in Charles and make a note of the port number it is listening on ( For eg. 8080)
Fig: Charles proxy settings
- Check the proxy settings in the iOS device – Manual proxy should be set where the Server will be the IP address of the system that the proxy is running on and the Port should be the same port that the proxy is listening on ( For eg. 8080)
Fig: Proxy settings on iOS device
- Install Charles certificate as trusted root, in order to capture the traffic going from and to the app and server
Once these settings are done any request going from the mobile app to the server can be intercepted by the proxy tool used and the testing can then be done in a manner similar to testing a web application.
An example of performing an attack (Parameter tampering in this example) by intercepting the requests and modifying it before it reaches the server is as shown in the snapshots below.
Step 1: Perform some action (edit details of a user in this example) after logging in to the mobile app and capture the request using Charles or any other proxy tool.
Fig: Original request of performing an action
The above request is made from the user whose unique number is xxxxxxxxxxx76.
Step 2: Modify this parameter to another unique number (xxxxxxxxxxx70) which belongs to another user, as shown in the following snapshot.
Fig: Modified Request
Step 3: Forward this modified request to the server. The server replies with “SUCCESS” response showing that the details of user with the unique number (xxxxxxxxxxx70) are modified instead of the 1st user (xxxxxxxxxxx76). This is shown in the snapshot below.
Fig: Response from the server showing the attack of parameter tampering was successful
Apart from Parameter Tampering that can be performed as intercepting the traffic is possible, there are many other attacks take can be launched if interception is possible. To mention a few of these type of attacks – authentication bypass, client side injections, improper validation of session token, session hijaking, session fixation and other session related attacks can be exploited.
Recommended Mitigation:
Depending on the kind of attack that is being launched due to the possibility of interception of traffic the mitigations will vary. If the mobile app is vulnerble to paramter tampering then the mitigation would be to implement server-side mapping of the user to the respective accessibility so that the features applicable to different privilege levels are accessible strictly to those level users only. If the mobile app is using a guessible session id/token which might lead to session management related attacks, then the mitigation would be to generate and issue a complex and random session token whenever a user has been authenticated successfully. Also, this session token should be properly invalidated when the user logs out. These mitigations will be similar to the ones suggested during the testing of a web application.
Certificate pinning is another method that can be implemented which will prevent the interception of traffic and hence prove to be a combined solution for any of the Man-in-the-middle attacks.
Local Storage
A lost device can provide access to a lot of sensitive data that is stored on the device. This is because mobile apps store some amount of data locally on the device. Since data is being stored on the device it should be stored securely in such a manner that it cannot be misused by unintended users. With respect to an iOS device, a tool called “iExplorer” is used to fetch all the data that is stored locally on the device. App related data can be extracted to the system that the iOS device is connected to, and once extracted can be viewed at anytime. The below screenshot shows the data present locally on the device that is viewed using the tool “iExplorer”.
Fig: Local storage – text files containing sensitive information like password.
As seen in the above snapshot, a text file containing the password in clear text was obtained. This text file was present in the local storage of the device and was extracted to the system. This file stored the password in clear text and was readable irrespective of having access to the app.
Fig: Local storage – pdf files
As seen in the above screenshot, a PDF file and a folder tmp was seen in the local storage of the device and was extracted to the system. The pdf file that was extracted to the system could be opened and read irrespective of having access to the app.
Recommended Mitigation:
The IOS applications should be built in a way such that it does not store vital sensitive data on the device’s memory. In case there is a need to store the same, strong encryption algorithms should be implemented to encrypt the same.
Encryption can be used to protect a user’s secret from others, either during data transmission or when data are stored. Mac OS X provides a variety of encryption-based security options, such as:
- FileVault
- Keychain
- Encryption of Email
Logging
From the time the app has been installed on the iOS device logs are generated on the device. These logs might have confidential app/user related data that can be accessible by anyone who has physical access to the device. To view the logs generated on an iOS device a tool called “iPhone Configuration Utility” is used. Once the device is connected to a laptop/computer that has this tool installed, the “Console” option shows all the logs generated on that device. This is depicted in the screenshot below:
Fig: Logs generated at the device revealing sensitive information
As seen in the snapshot above, the logs reveal user specific and sensitive information like CustomerName, agreementid, sessionid and userid. These details can be viewed at anytime just by having physical access to the iOS device.
Recommended Mitigation:
Do not log sensitive data like username, password, unique identifiers or any vital user related information to system logs.
Decompilation
Decompiling comprises of getting the code from .ipa file by reverse engineering. This is done with the help of a decompiler “class dumpz” by changing the .ipa extension to .zip extension and extracting the contents of the file. The following steps should be followed to decompile an iOS app:
- Open class dump-z
- Paste .ipa file in the same folder
- Rename the .ipa file extension to .zip extension
- Extract the file
- Then search for the file with the biggest size which has the same name as the application
- Copy the same file and paste it in the “win-x86” folder
- Go to command prompt and type the following command: Classdump-z.exe AppName > decompile.txt
The above file decomiple.txt has part of the code and can contain sensitive information related to the application.
Recommended Mitigation:
First, the application must follow secure coding techniques for the following security components within the mobile app:
-
- Jailbreak Detection Controls
- Checksum Controls
- Certificate Pinning Controls
- Debugger Detection Controls
Next, the app must adequately mitigate two different technical risks that the above controls are exposed to:
-
- The organization building the app must adequately prevent an adversary from analyzing and reverse engineering the app using static or dynamic analysis techniques.
- The mobile app must be able to detect at runtime that code has been added or changed from what it knows about its integrity at compile time. The app must be able to react appropriately at runtime to a code integrity violation.
With this basic knowledge about testing an iOS app a mobile security enthusiast/professional can test for vulnerabilities in an iOS app.
