iOS Application Security | Part 6 | Analyzing the IPA file of an application

Forensics
1

Introduction

This article 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 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 macOS, 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.
  • The task can also be performed cross-platform using plistlib in python.





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’.
  • Firebase project URL - The URL of the application’s firebase project.

    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 a 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.
    • Misconfigured firebase - Suppose we find that the value of the of the key firebase[‘dbUrl’] in the Info.plist is https://abc.firebaseio.com. If the firebase is not configured properly, then on navigating to the URL https://abc.firebaseio.com/.json would disclose the whole database to us in a single go. How cool!

    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.

    Some of the popular tools are:

    otool


    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

    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 a 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.

        1. 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.

        2. 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.

        3. Usage of Obsolete Methods/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 a 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 a Buffer Overflow. But considering the complexity of the attack and the various security measures on the iOS platform, the vulnerability falls under informational category.

        4. Unencrypted Application Binary

    Whenever an application is uploaded to the 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.

        5. 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.

        6. 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.

        7. 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.

        8. 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.



    Other data in the IPA

    By now we have analysed the important components from the IPA file. But we should not forget that there might be other components as well which might expose some vulnerabilities to an attacker. To cover that part, we should analyse other files that are packed with the IPA. There might be plists, database files or other custom files. We must scan all these files for sensitive data like encryption keys. Once this is done, we can say that we are done with analyzing the IPA file of the iOS application in question.

    Conclusion

    In this article, we have made an attempt to start the analysis of the IPA file of an application. We can now check these controls for any application. This is the beginning of what is known as static analysis. In the next article, we would look at the analysis of the Local Data storage of an application.

    Article Link: https://blog.lucideus.com/2019/04/ios-application-security-part-6.html