The mobile application ecosystem is a big, complicated place. You have all these incredible features like web support, plugins, and extensions. But with each new functionality come new security vulnerabilities, which—one way or another—hackers find a way to exploit.
With this blog, I want to specifically talk about vulnerabilities in the iOS app ecosystem. Apple has a pretty solid track record with security on their devices and apps, and they boast extensive computing power and increasingly feature-rich & complex frameworks.
That said, their prominence in the world of tech also makes them a particularly high-value target for attackers. Exploits like Information Gathering, Bypass Techniques, and Privacy Breaches are just a few in the long list of iOS attacks.
One of the latest exploits to be featured in the news was the zero-click attack on a Bahraini human rights activists who was hacked with NSO’s Pegasus spyware. It’s called ‘zero-click’ because it doesn’t require any user interaction to infect a victim’s device. If that sounds disconcerting, that’s because it is.
The attack took advantage of a previously unknown security vulnerability in Apple’s iMessage app, which was exploited to push the Pegasus spyware, developed by Israeli firm NSO Group, to the activist’s phone.
But while there’s no such thing as an ‘unhackable’ software, you can still make your application so hard to crack, hackers won’t even want to bother trying. Sure, it doesn’t roll off the tongue quite as nicely, but at least you’re being realistic.
So here are the 4 steps you can take to make your iOS app bulletproof:
Step 1: BUILD
Design a Threat Model against various attack scenarios
Step 2: BREAK
Learn from the mistakes of various exploits and build a stronger fortification
Step 3: EXPLOIT
Employ tools & methods that work to block these attacks for stronger applications
Step 4: MITIGATE
Implement best practices to create awareness and a secure ethos
Step 1: Build a Threat Model — Combat the Enemy
Threat Modeling is like designing an application and the various scenarios built around it. It’s an exercise that helps to identify potential risks and loopholes in the iOS application. You can learn more about we45’s threat modeling services here.
Threat modeling helps identify security concerns such as:
- Assets that require extra protection layers
- Monitors, if security controls are provided by the technology in use
- Controls needed for the application to implement itself
- Threat agents that may create attack scenarios
- The relationship between user and key risk components
Mobile operating systems implement controls like sandboxing and permission enforcement to limit malicious application access
Web Applications on iOS Devices
Web applications are accessible from iOS devices using mobile browsers. When accessing web apps in this manner, some controls and threat agents are different.
This table depicts how various threats are controlled through different surface attacks:
|Application Data||Certification Verification||Malicious App Users|
|Application Functionality||Cache||Malicious Websites|
|Cookies||Browser Processes||Physical access to Device|
|DOM Objects||User AuthN/AuthZ||Malicious Attackers|
|User’s Private Data||Application Permissions|
|Device Functionality||Same Origin Policy|
This table represents a few of threat concerns and the mode of attack:
|Threat Agent||Attack Surface||Target Assets||Controls|
|Malicious app users||Browser||Users’ private data
|Sandbox the browser and application
Enforce app permissions
|Malicious app (sandboxed) App sandboxing||Mobile device||Application data Application functionality Cookies
Users’ private data Device functionality
|Store verification Enforce app permissions|
The controls listed reduce the likelihood of the malicious apps accessing the user’s private data stored on the device. Mobile operating systems like iOS implement controls like sandboxing and enforcing permissions to limit malicious application access. It’s important learn from your mistakes (or better yet, someone else’s)!
Break: Security Flaws in an iOS Application
Getting Privileged Access
iOS jailbreaking is often compared to Android rooting, but the process is quite different. Here’s an explanation of how it works on Android.
Rooting: This involves installing the binary on the system or replacing the whole system with a rooted custom ROM.
Flashing custom ROMs: This allows you to replace the OS that’s running on the device after you unlock the bootloader. The bootloader may require an exploit to unlock it
But for on iOS devices, flashing a custom ROM is impossible because the iOS bootloader only allows Apple-signed images to be booted and flashed. This is why even official iOS images can’t be installed if they aren’t signed by Apple, and it makes iOS downgrades only possible for as long as the previous iOS version is still signed.
This makes it more complicated because Apple keeps hardening the system and patching the exploited vulnerabilities.
1. Outdated Cryptography
Use SHA-2 or SHA-3 for hashing and AES for two-way encryption. Pick the best solution that provides your application with safety and security without any compromise.
2. Insecure Runtime Storage
When apps connect to a remote server, there are usually some short-lived access tokens generated to talk to the API’s. A good habit would be to store these tokens, using UserDefaults, and reuse them before it expires. But this has a flip side too, since UserDefaults stores as aplist file, totally readable. The solution is to store any data/file in an encrypted form, using EncryptedSharedPreferences.
Basic Testing Operations
- Accessing the Device Shell
One of the basic ways to test an app is by accessing the device shell either remotely from your computer or from the device.
- Remote Shell
On iOS devices, you can access the remote shell viw SSH. This means the device should be jailbroken.
- iOS App Structure
To enable SSHaccess, you can install the OpenSSH package and connect both devices to the same Wi-Fi network and note the device IP address, which you can find in the Settings -> Wi-Fi option. You can now access the remote device’s shell by running ssh root@<device_ip_address>, which will log you in as the root user:
$ ssh email@example.com
Press Control + D or type exit to quit.Remember to change the default password for both users root and mobile as anyone on the same network can find the IP address of your device and connect via the well-known default password, which will give them root access to your device.
- Acquiring the App Binary
From an IPA: If you have the IPA (probably including an already decrypted app binary), unzip it and you’re good to go. On macOS’s Finder, .app directories are opened by right-clicking them and selecting “Show Package Content”.
From a Jailbroken device: If you don’t have the original IPA, then you need a jailbroken device where you will install the app. Once installed, you need to extract the app binary from memory and rebuild the IPA file.
Exploit: Every Application to Itself
There are numerous ways that an app can be exploited for its data, usage, user coverage, etc. As many apps exist, so do exploit tools. These can be used both for malicious purposes or for securing applications.
Some of the most common attacks :
Most iOS apps communicate with a server and use TLS for privacy and integrity to exchange/retrieve information. They also rely ONLY on iOS certification with total trust. Using this as a ploy, attackers, tamper and setup MIM attacks using hacked or self-signed certificates and capture data from your app.
You can use SSL Certificate Pinning to mitigate this risk.
Data can be stored in SQL databases or plain files. Store data on the device only if absolutely necessary. Encrypt the data and use Data Protection API provided by iOS.
Improper implementation of URLSchemes used to perform sensitive actions.
Native iOS applications and web applications running on Mobile Safari can use these schemes to integrate with system applications and provide a more seamless experience to the user. Use the iOS APIs provided to identify the Bundle ID of the invoker app and do not blindly trust the data sent. The application that is being invoked should maintain a whitelist of BundleIDs of trusted applications.
No SSL or Improperly Configured SSL
Many iOS application use HTTP over SSL or prevent MIM attacks, using NSURLConnection class and warns the user if the certificate used is invalid. Developers push code daily without proper validations. Implement a fail-safe mechanism using NSURLConnection class’s didFailWithError delegate to avoid connections with invalid SSL certificates.
Data Leakage via Screenshot Backgrounding
iOS uses features to improve OS performance, which could lead to data leakage. To optimise iOS takes a screenshot of the application before moving it to background. When this gets relaunched the background screenshot is swiftly displayed over the background one. The application takes a screenshot of the current screen before moving it to the background, even if the screen contains an input field where you have entered your Credit Card Number or other secrets. This should be avoided by clearly sensitive data before sending it to the background.
Attackers exploit weak authentication measures to impersonate a user, bypass authentication to submit requests to an app’s backend services, or hijack a session to perform actions on behalf of the user within the app itself. Implement 2FA, configure session-management cookies and perform authentication requests on the server side.
These are some of the best practices to implement over tools and bypass techniques to secure your application and safeguard the user’s data. However, not everything is feasible to implement, depending on business requirements and other constraints.
Some of my favourite bypass/exploit tools:
Objection (root detection), SSL Pinning bypass, Nmap, Openvas, Directory Listing, Nikto, subdomain find/enumeration, SSL Scan/Testssl/Qualys_SSL labs, CSP Evaluator/Security Headers, Burp suite- Spidering, OWASP ZAP, Active scans.
Mitigate: Only as Strong as the Weakest Link
As strong as Apple can make its security measures, the surface attacks on their applications and devices are stronger. Almost every app stores some kind of data on the device. With integrated threat detection and alerting, we should work to close the loop between protecting iOS apps and understanding their real-time threat pressure.
Protecting iOS applications is critical to managing risk in a zero-trust world.
Ways to mitigate attacks:
- Cybercriminals can reverse engineer iOS apps by exposing code to steal customer identities, intellectual property, or by gaining access to back office systems. This can be overcome by hardening technology, enabling runtime protection against reverse engineering, code tampering.
- Equally important is to code protection is threat detection. The ability to detect and alert on reverse engineering or tampering attacks is essential to getting in front of iOS app attacks and stop them from going viral.
- Providing full protection for iOS apps also requires that communication keys, API locations, and critical in-app data should be encrypted.
- Maintain additional protection and security by encrypting static and dynamic keys with white-box cryptography that utilizes mathematical techniques and transformations to blend together app code and keys to secure cryptographic operations.
- Ensure that Data Authz & Encryption are through latest tools and Codified Security.
- Protect your account – the lowest hanging fruit are your login credentials. Use strong and unique passphrases that are hard to decipher and not related to your personal information.
- Connect to ONLY Secure networks and download only form the official APP Store and have Improved Security Antivirus installed.
- Use in-built and privacy protections provided by iOS.
- Control app tracking and check privacy settings before you download.
- Protect you SIM, by putting a pin lock. Harder for thieves to crack.
- Don’t Auto join Wifi Networks, which makes it easy for an attacker to conduct a MIM attack from the rogue network. If this feature is turned off, it will prevent the hacker from using the same SSID.