4 Things You Need to Do to Make Your iOS Apps Bulletproof

PUBLISHED:
September 2, 2021
|
BY:
Amulya Miriam

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

[caption id="attachment_6830" align="aligncenter" width="620"]

iOS threat model

Sample Threat Model 1 : Authenticate the User and display Bank Balance[/caption]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.[caption id="attachment_6832" align="aligncenter" width="690"]

Securing an iOS app from various security attacks

Securing an iOS app from various attacks[/caption]This table depicts how various threats are controlled through different surface attacks: Assets ControlsThreats Application Data Certification Verification Malicious App Users Application Functionality Cache Malicious Websites Cookies Browser Processes Physical access to Device DOM Objects User AuthN/AuthZMalicious 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 BrowserUsers’ private data Device functionality 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 User Defaults, and reuse them before it expires. But this has a flip side too, since User Defaults stores as aplist file, totally readable. The solution is to store any data/file in an encrypted form, using Encrypted Shared Preferences.

Basic Testing Operations

  1. Accessing the Device ShellOne of the basic ways to test an app is by accessing the device shell either remotely from your computer or from the device.
  2. Remote ShellOn iOS devices, you can access the remote shell viw SSH. This means the device should be jailbroken.
  3. iOS App StructureTo 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 root@192.168.197.234 root@192.168.197.234's password: iPhone:~ root# 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.
  4. Acquiring the App BinaryFrom 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 :

  1. Man-in-the-middle
  2. 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. 
  3. Sensitive Data
  4. 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. 
  5. Improper implementation of URL Schemes used to perform sensitive actions.
  6. 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 Bundle IDs of trusted applications. 
  7. No SSL or Improperly Configured SSL
  8. Many iOS application use HTTP over SSL or prevent MIM attacks, using NSURL Connection class and warns the user if the certificate used is invalid. Developers push code daily without proper validations. Implement a fail-safe mechanism using NSURL Connection class's did Fail With Error delegate to avoid connections with invalid SSL certificates. 
  9. Data Leakage via Screenshot Backgrounding
  10. 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. 
  11. Unprotected UIWebView
  12. This feature is used to embed web content in an application. This object renders the HTML and also executes JavaScript. This can be used to attack the device which is similar to conventional XSS attack. The application should validate and sanitize the incoming data before passing it to the UIWebView class object. The input should be validated to check if it contains any special characters which can be used to build XSS attack vectors. 
  13. Weak Authentication
  14. 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:

  1. 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.
  2. 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.
  3. Providing full protection for iOS apps also requires that communication keys, API locations, and critical in-app data should be encrypted.
  4. 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.
  5. Ensure that Data Authz & Encryption are through latest tools and Codified Security.
  6. 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.
  7. Connect to ONLY Secure networks and download only form the official APP Store and have Improved Security Antivirus installed.
  8. Use in-built and privacy protections provided by iOS.
  9. Control app tracking and check privacy settings before you download.
  10. Protect you SIM, by putting a pin lock. Harder for thieves to crack.
  11. 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.
View all blogs