Think Like a Threat Actor: A Series

Motivation Behind This Series

Taking the first steps into application security can be daunting. There are endless cybersecurity blogs and dozens of open-source and free attack tools available. However, there is very little information that helps break down the important pieces that are a real threat to application developers. Much of the existing information consists of research or proof of concepts.

This series will dive into the most significant threats, explain how to reproduce the applications’ attacks, provide the foundations that a penetration tester will use when testing your application, and give recommendations for protecting against the most significant threats. Learning the best methods to stop threat actors starts with understanding their behavior and goals. This series will focus on iOS application security. All operating systems have similar threats and attack vectors. Still, iOS has unique characteristics because it has a restrictive application sandbox, and the hardware and operating system source code is more locked down than many other systems. This first article will review the high-level background for what makes iOS application security unique and dive into iOS IPA file formats, application signing, and application sideloading, which are fundamental pieces needed to follow the attacks described in later parts of this series.

Threat Actor’s Motives

Threat actors can have any number of motivations for attacking an application. They could just want to blog about it and spread information ;). Threat actors could be doing it to show they can. In general, threat actors have a goal to benefit themselves financially or damage their targets financially. As a starting point, a threat actor might want to reverse engineer and understand sensitive algorithms, communication protocols, APIs, or business logic to reimplement the logic in their applications. However, this process can quickly escalate to bypassing the DRM or licensing mechanisms, potentially leading to a free distribution of the application. The foundations of reverse engineering, code modification, and application analysis for these attacks are the same. Understanding the attacks, and the threat actors, leads to better defense against them.

Difference Between Desktop and Mobile Application Security

Every platform and operating system leaves different attack vectors exposed. Desktop operating systems like Windows, Linux, and Mac provide the least security at the operating system level. This makes developing attack tools or modifying applications easy to take advantage of the reduced security. Applications that run on mobile operating systems like iOS and Android tend to have a more restricted sandbox than typical desktop applications. However, just because the operating system has built-in security features, it does not mean the applications running on top of them will always be safe. There are still attacks against applications that run on every operating system.

Let’s dive into what makes iOS different for threat actors:

1. iOS does not provide users with root or admin-level access at all. Desktop operating systems will allow users to escalate their permissions.
2. Many attack tools must run on the same device as the software under attack. Building and running attack tools on mobile targets can be more difficult.
3. Attack tools against iOS often run on a paired desktop instead of on the iOS device itself, making them more difficult to use and develop.
4. Apple actively makes it challenging to gain escalated permissions. Apple patches security vulnerabilities that lead to Jailbreaks and has weakened and restricted jailbreaks over time. See our blog for a more detailed history. The Android operating system for most devices does not provide root permissions by default, but it is less difficult for a threat actor to escalate permissions.
5. Fewer software development debugging capabilities exist on iOS. Development is primarily done in Xcode or using Xcode build tools under the hood. Most debugging tools are tied to Xcode and have limited capability for an already compiled application.
6. iOS devices do not have SSH or a direct terminal connection by default.
7. End users quickly update iOS devices with rapidly changing operating systems, hardware, and applications, including security patches. This breaks attack tools and malware, forcing threat actors to spend more on maintenance.
8. iOS devices are more expensive, require Apple developer accounts, and have limited simulator or emulator capabilities to save on cost.

iOS Binary Packaging

iOS IPA files are compressed in a zip format that contains everything needed to run the application. IPA files can be simply unzipped to access the app’s binary files. This is the first step to reverse engineering the application through static analysis. The below example looks at the Job Dispatcher application, which will be the sample application attacked in later parts of this series. The application is available at https://github.com/digitalai-opensource/job-dispatcher.

% unzip Job\ Dispatcher.ipa

Archive: Job Dispatcher.ipa

creating: Payload/

creating: Payload/Job Dispatcher.app/

creating: Payload/Job Dispatcher.app/_CodeSignature/

inflating: Payload/Job Dispatcher.app/_CodeSignature/CodeResources

inflating: Payload/Job Dispatcher.app/AppIcon60x60@2x.png

inflating: Payload/Job Dispatcher.app/Assets.car

inflating: Payload/Job Dispatcher.app/AppIcon76x76@2x~ipad.png

inflating: Payload/Job Dispatcher.app/Job Dispatcher

inflating: Payload/Job Dispatcher.app/embedded.mobileprovision

inflating: Payload/Job Dispatcher.app/Info.plist

inflating: Payload/Job Dispatcher.app/PkgInfo

This is a small application, and large applications will contain many binary code files and numerous assets, frameworks, and other application content. This application only contains a single executable binary file named the same as the top-level IPA “Job Dispatcher.” We can check that this is an executable file using the “file” command.

% file Job\ Dispatcher

Job Dispatcher: Mach-O 64-bit executable arm64

Mach-O is the binary file format that Apple operating systems use, and all recent iOS devices use ARM64 CPUs.

We now have access to the file we want to reverse engineer and modify in future parts of this series. When we are done attacking the application, we can zip up all its contents and rename the zip back to a .ipa file to create the IPA file. If the files are changed, we must properly resign or sideload the application to install it.

Signing Modified iOS Applications

Signing applications for iOS is typically done through the Xcode GUI when building an application or using the codesign command line tool when using the command line. These tools have limitations when resigning an application after modifying compiled and signed binaries, which is the typical use case for a threat actor. To resign a modified application, a tool like iOS App Signer can recursively go through all the files in an IPA and resign them all. This approach requires an Apple developer account, and Xcode will throw an error when installing an application that has been resigned with a different certificate on a jailed device. Note that attacking iOS applications often requires downloading and running potentially dangerous code. Caveat Emptor!

Sideloading Modified iOS Applications

An alternative approach for resigning and installing modified applications is to use a sideloading tool. Sideloading bypasses security restrictions with resigning applications and can be used to bypass supported devices and iOS version limitations. A powerful tool for sideloading iOS applications is Sideloadly. Be careful downloading and installing pre-built applications where you cannot review the source code.

Take Away

Understanding threat actors and their attack vectors will help you understand how to build more secure applications. Over the next few months, watch this space for a series of articles detailing different attack vectors. In many cases, the attacks will build off each other. For example, threat actors need to Jailbreak their device before they can install and run the full capabilities of Frida. Threat actors also must resign or sideload applications to test modifications. The first offensive article (coming soon!) will show how to modify a sample application to bypass an authentication function.

Click here for a free threat assessment of your app.