Analyzing the Ipa like a pro
This blog explains the procedure to analyze and identify potential security vulnerabilities in the files present in the IPA file of an iOS application. In order to get an understanding of the things explained in this article, going through the previous article is recommended in order to understand the structure of the iOS application. Let’s get started
Info.plist — The entry point
This file is the manifest for an iOS application and is used to store configuration data of the application. It is an Apple property list file. It determines what icon to display for a bundle, what document types an app supports, and many other behaviors that have an impact outside the bundle itself.
- On a Mac, this file is opened in Xcode or using the command line tool plutil.
- On Linux, plistutil is the command for opening the plist file and converting it to XML.
Use Plistutil tool here
or else you can take help of python as well with plestlib
Reading the plist file, we can gather some basic information about the application like:
- Version information — The current version of the application. It is stored in the key ‘’.
- Display name of the application — The name of the application as displayed in the iPhone. It is stored in the key ‘CFBundleDisplayName’. If the name of the application is big for displaying the upper menu bar or the lower docker bar, ‘CFBundleName’ key has to be specified.
- .app directory name of the application — The directory which contains the Bundle Container of an iOS application. It is stored in the key ‘CFBUndleName’.
- Bundle Identifier of the application — The identifier that uniquely identifies an application from other applications on the device. It is stored in the key ‘CFBundleIdentifier’.
- Executable binary name — The executable file containing the machine code of an application. It is stored in the key ‘CFBundleExecutable’.
- Supported iOS version and devices — The specification of the iOS version and device models supported by the application. Devices are specified by the key ‘UISupportedDevices’ and the minimum iOS version by ‘MinimumOSVersion’.
- Icon and Launch image file names — The name of the image files to be used as icons and launch screen images for different models of iPhones. It is stored in the key ‘CFBundleIcons’.
- Application permissions — The description given by the application for usage of user’s sensitive permissions. It is specified in the keys ‘NS<requirement>UsageDescription’.
- Application Transport Security — The information regarding URLs/domains the application is allowed or disallowed to load. It is specified in the key ‘NSAppTransportSecurity’
Let us look at Info.plist file of Google Maps application.
Once we have got all the information we desired from the Info.plist file. From the security point of view, we need to check the following controls from this file:
- Unnecessary permissions requested by the application — An application may request permissions that are not essential for the functionality of the application and may be used maliciously by any other application or service on the device. Enabling permissions might make the user do some undesired things like sharing location to remote third parties or may be used for social engineering activity by using the device components like microphone, camera etc.
As we can see in the screenshot, the application requests sensitive permissions like Camera, Location, Motion and Bluetooth. The application provides the reason for the use of the permissions but it should be considered that even if the description is given, it does not mean that the permissions are used properly. Malicious use of permissions can harm the privacy of the user.
Misconfigured Application Transport Security — An application may be misconfigured to allow loading of Arbitrary URLs in the application which may cause security concerns causing malicious behaviour in the application
As seen from the screenshot, the application allows arbitrary loads. This does not mean that the application is vulnerable in all the cases. Google Maps application might need to load photos or URLs from some other location. As long as this functionality is being used properly, no malicious behaviour can be caused inside the application. Also, if there is a vulnerability, the exploitation is hard and the vulnerability takes up a low-level slot.
Extra Inputs
└── NSExceptionDomain key from the Info.plist exposes third-party domains
like CDNs, subdomains used by the organization which do not comply with App Transport Security.
└── Hardcoded domain names can be found by searching for URL schemes
inside the directory using grep or running strings on the executable.
cat Info.plist | grep NSExceptionDomains -A13 key>NSExceptionDomains</key> <dict> <key>stag.vulnsite.com</key> <dict> <key>NSExceptionRequiresForwardSecrecy</key> <false/> </dict> <key>dev-cdn.vulnsite.com</key> <dict> <key>NSIncludesSubdomains</key> <true/> </dict> <key>s3.amazonaws.com/vulnsite</key> </dict>[[email protected] ~] strings SampleExecutable | egrep -i 'http|https' http://vuln.domain.com https://examplevulnsite.com
Credentials
└── Accidentally, credentials are leaked by either hardcoding or placing
sensitive certificate files or keys inside the app folder and not removing it
before publishing to production. This can be done by searching for
key/secret/api/password either manually or in an automated way.
└── Usernames are some times hardcoded during the build time. This can be
later used in brute-forcing or to phish users if there is an open relay in the
SMTP servers. Executables can be disassembled using Hopper to inspect for
Executable revealing credentials on disassemblingConfiguration
└── File paths hardcoded in the executable can be useful to escalate an LFI
found in the application and also if lucky, we can find information about
backend technologies or third party libraries used
Executable leaking environment and usernames
└── API endpoints can be extracted from JS files using LinkFinder or
manually searching the executable after looking for the URL pattern from the network traffic analysis.
└── Domain whitelisting is a security model for apps built with Cordova that controls which servers your application can communicate to. Most of the time it is misconfigured to allow any domain by using
<access origin=”*” /> instead of the secure configuration <access origin=”https://example.com” />
└── App Transport Security enforces that the communication between the backend and the application is secure. It prevents accidental leakage of
sensitive information by allowing the app to communicate by using TLS
version 1.2 with perfect forward secrecy and rejecting HTTP
communications. It must be noted that NSAllowsArbitratyLoads key from the Info.plist set to YES is a misconfiguration and might trigger App Store review as stated by Apple. In case of any exceptions, ATS should be enabled globally and exceptions should be mentioned under the key NSExceptionDomains for
domains the organization doesn’t control.
Real World Example
From the Info.plist key NSExceptionDomains, we discovered that the app
communicates to an HTTP domain. On port scanning and running dirsearch,
found that there is a API help page publicly available at port 8080 accessible
without any authentication.
Unfortunately there wasn’t any documentation provided on what headers are mandated and if there is any format to send the data. After failed attempts of trial and error, we decided to check the iOS application’s traffic and replay the same request headers to fetch data from the callDownloadFile?DocId={DocId}
But, we still don’t have the DocId parameter and bruteforcing isn’t an option.
With the information found, continued with checking the logical flow of the application. Luckily, on registering for an account, I had to upload an ID proof for verification and the response gave an interesting message.
POST /ProfileDocument/Upload HTTP/1.1
Host: vuln.example.gov:8080
Accept-Charset: utf-8HTTP/1.1 200 OK
Server: IIS/7.5{"type":"pdf", "docId":"3332995"}
With the docId , we can start enumerating identifiers from the number we were assigned. It didn’t take much time for Intruder to find documents ranging from government ID cards, IT recovery plans and salary slips. Seems like the domain is used to download and upload documents from multiple instances.
POST /VulnAPI/ProfileImage/DownloadFile?DocId=3332975 HTTP/1.1
Host: vuln.example.gov:8080
Accept-Charset: utf-8HTTP/1.1 200 OK
Server: IIS/7.5
Content-disposition: attachment; filename=IT_Recovery.pdfPOST /VulnAPI/ProfileImage/DownloadFile?DocId=3332930 HTTP/1.1
Host: vuln.example.gov:8080
Accept-Charset: utf-8HTTP/1.1 200 OK
Server: IIS/7.5
Content-disposition: attachment; filename=ID-2910219201.pdf
Analyzing the application binary
The application binary of an iOS application is a file of type Mach-O binary. It is the actual executable file or the machine code that runs on an iPhone. It uses the files from the Bundle Container and produces what is visible to the user of the application. Complete reverse engineering of an iOS application to produce the source code is not possible. But specified parts of object files or libraries can be dumped using existing tools.
otool tool
otool is available with Xcode command-line utilities. It comes with numerous options that help to disassemble Mach-O binaries. By using otool, we can get to know the APIs that an iOS application uses. This can also help us to know classes and methods if the implementation is in Objective C.
nm tool
nm displays the name list (symbol table of nlist structures). This tool helps in getting the symbol table in different formats for binaries with different architectures
jtool
jtool was developed to meet and exceed the functionality of otool. One good thing about this tool is that it can run on Mac OS, iOS and even Linux
Using these tools, we would collect information about the application binary. Let us have a look into what information the application binary can provide us. We will discuss some controls and understand the ways for testing them out. Let us take the IPA file of Google Maps for demonstration.
From the security point of view, we would not be needing to view all the information we get from these tools. We would only be grepping for certain keywords in the output.
- Usage of Insecure Random Number Generator
APIs like _rand, _srand and _random are considered insecure for generating random numbers as the results can be predicted by an attacker. For more information refer to https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator
We can see that the Google Maps application makes use of Insecure Random Number Generator APIs. If they are being used to generate random numbers for sensitive information, an attacker can try to predict the random numbers and try to play malicious behaviour in the application. The attack complexity is very high and also many times developers combine these APIs with cryptographically strong APIs. So the vulnerability falls under the informational category.
- Usage of Weak Hashing Algorithms
APIs like MD5 and SHA1 are considered weak hashing algorithms due to collision issues. They can be cracked using websites using large databases or using a tool like hashcat. For further information refer to: https://www.sans.org/reading-room/whitepapers/authentication/dangers-weak-hashes-34412
We can see that the Google Maps application makes use of Weak Hashing APIs. The impact of the vulnerability depends on where the API is being used. If these APIs are being used to hash sensitive information, an attacker can try to crack those hashes and get crucial information about the user or application’s resources and then the impact caused to the application or user will increase. Many times developers combine these APIs with cryptographically strong APIs making it a low or an informational level finding.
- Usage of Banned/Deprecated APIs
In Objective C, APIs like strlen, memcpy, strcpy etc. have been deprecated as they might lead to memory corruption and should not be used anymore. The vulnerability can be exploited by causing buffer overflow which is very hard to exploit in the iOS ecosystem. Yet, it is considered ‘Best Practice’ not to use them.
For further information refer to: https://developer.apple.com/library/archive/documentation/Security/Conceptual/SecureCodingGuide/Articles/BufferOverflows.html
We can see that the Google Maps application might use banned APIs. If an attacker is able to find entry points to these functions, he can try to send malicious inputs at run-time and try to exploit the vulnerability by causing Buffer Overflow. But considering the complexity of the attack and the various security measures on the iOS platform, the vulnerability falls under informational category.
- Unencrypted Application Binary
Whenever an application is uploaded to App Store, it comes with Apple’s Fairplay DRM encryption. But it is important to check this as well.
The value of cryptid is 1 which shows that the application binary is encrypted. If for an application, the cryptid value is 0, it would mean that the application binary is unencrypted. An attacker would try to run class-dump on the application binary and further try to crack the application.
- Application binary compiled without fPIE-pie flag
ASLR (Address Space Layout Randomization) protects iOS application binary against memory corruption vulnerabilities by randomizing the application objects location in the memory each time the application restarts. It is implemented by compiling iOS application binary with PIE (Position Independent Executable) flag.
If ASLR is not enabled for an iOS application, offsetting of the location of modules and certain in-memory structures would not take place randomly and will hence open a gate for Buffer Overflow attack.
From the screenshot, it is clear that the Google Maps application has ASLR enabled on its binary. For the applications on which this is not enabled, a low level vulnerability is there for the application.
- Application binary compiled without fobjc-arc flag
ARC (Automatic Reference Counting) helps in automatic memory management in iOS applications by handling the reference count of objects automatically at compile time. It is implemented by compiling the iOS application binary with fobjc-arc flag.
Disabling ARC for an iOS application will stabilize the reference count for the objects and give the attacker a chance to corrupt the victim’s device memory and also exploit the Buffer Overflow vulnerability.
From the screenshot, it is clear that the Google Maps application has ARC enabled on its binary. For the applications on which this is not enabled, a low level vulnerability is there for the application due to high attack complexity.
- Application binary compiled without fstack-protector-all flag
Stack-smashing protection is implied to an iOS application by placing a known value or “canary” on the stack directly before the local variables to protect the saved base pointer, saved instruction pointer, and function arguments. The value of canary is checked on the event of function return and is reported if there is any change.
If the stack smashing protection is not enabled, the attacker would try to insert malicious payloads in the application and hence leading to the crashing of the application at run-time making the user experience for the application bad. The vulnerability is difficult to attack but not impossible.
From the screenshot, it is clear that the Google Maps application has stack-smashing protection enabled on its binary. For the applications on which this is not enabled, a low level vulnerability is there for the application due to a high attack complexity.
- Sensitive Data in Strings
The application might contain sensitive strings that might indicate an attacker about things like encryption/decryption logic, passwords and so on. Strings can be checked by running the UNIX command ‘strings’ on the application binary.
We get a long list of strings for the Google Maps application. We would need to traverse the list manually in order to find any sensitive data or we can use ‘grep’ command in order to look for specific patterns.
We can now check these controls for any application. This is the beginning of what is known as static analysis.
Recent Comments