Book Image

Learning iOS Penetration Testing

By : Swaroop Yermalkar
Book Image

Learning iOS Penetration Testing

By: Swaroop Yermalkar

Overview of this book

iOS has become one of the most popular mobile operating systems with more than 1.4 million apps available in the iOS App Store. Some security weaknesses in any of these applications or on the system could mean that an attacker can get access to the device and retrieve sensitive information. This book will show you how to conduct a wide range of penetration tests on iOS devices to uncover vulnerabilities and strengthen the system from attacks. Learning iOS Penetration Testing discusses the common vulnerabilities and security-related shortcomings in an iOS application and operating system, and will teach you to conduct static and dynamic analysis of iOS applications. This practical guide will help you uncover vulnerabilities in iOS phones and applications. We begin with basics of iOS security and dig deep to learn about traffic analysis, code analysis, and various other techniques. Later, we discuss the various utilities, and the process of reversing and auditing.
Table of Contents (17 chapters)
Learning iOS Penetration Testing
Credits
Foreword – Why Mobile Security Matters
About the Author
About the Reviewer
www.PacktPub.com
Preface
Index

OWASP Top 10 Mobile Risks


To conduct a security assessment of the iOS application, you need to follow some standard criteria from industry. Open Web Application Security Project (OWASP) Top 10 Mobile Risks is the list of vulnerabilities that are usually found in iOS applications.

You can always find latest top ten list for mobile at https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks.

The major difference between the latest OWASP Top 10 Mobile Risks and its earlier versions is the introduction of a new vulnerability in the list, that is, the lack of binary protection, which is the replacement of sensitive information disclosure.

The latest OWASP Top 10 Mobile Risks, Year 2014 list covers the following vulnerabilities:

  • Weak server-side controls

  • Insecure data storage

  • Insufficient transport layer protection

  • Side channel data leakage

  • Poor authorization and authentication

  • Broken cryptography

  • Client-side injection

  • Security decisions via untrusted input

  • Improper session handling

  • Lack of binary protections

Weak server-side controls

Nowadays, most of the apps are hybrid apps where they use native app code or web view to design UI and in backend, they use web APIs to communicate with the server. As there are web apps in backend, so almost all attacks that target web applications are applicable to iOS apps as well. If you have never checked web attacks, I would encourage you to go through OWASP Top 10 Web Application Risks at https://www.owasp.org/index.php/Top_10_2013-Top_10.

In order to explain further, I found the stored XSS in one of the top company's iOS app. They were sanitizing the user input in their web application; however, while storing and displaying, the user input was not sanitized for the web APIs used for the mobile. Thus, it allowed the attacker to store malicious JavaScripts in the database and wherever it showed the records to the user from database, it allowed the execution of JavaScripts and hence it results in the stored XSS.

Insecure data storage

Insecure data storage is all about storing the data insecurely on the device. Many times, an application uses simple plist files or unencrypted database to store sensitive information such as passwords or other user-related information.

This is the most frequent and, sometimes, very easy-to-find vulnerability. An application should never store sensitive data such as the users' personal, financial, or healthcare information in plain text format. If app developers are storing sensitive information, it may be non-compliant with various compliance standards such as Payment Card Industry Data Security Standard (PCI DSS), Health Insurance Portability and Accountability Act (HIPAA), and so on. We will look into this vulnerability in detail, such as various formats of storage, and how to look into this data in the upcoming chapters.

Insufficient transport layer protection

Insufficient transport layer protection is all about how to send your data across the network. Mobile apps are frequent victims of coffee shop attacks and if an application is sending sensitive data, such as credentials, access tokens, and so on, over HTTP, then any attacker sniffing over the network can easily catch or modify it.

Even if the developer is sending data over HTTPS; however, if he does not validate the sever-side certificates, then it is vulnerable to SSL pinning such as attacks where the attacker performs man-in-the-middle (MITM) attacks with self-signed certificates.

Side channel data leakage

Side channel data leakage arises when a developer places sensitive information or data in a location on the mobile where it is easily accessible by other application. Thus, resulting in a side channel data leakage.

In one of my financial application assessment, the application was taking credit card details from the user and had not implemented any security mechanism to deal with side channel data leakage. Now, in iOS, whenever we background the app, it takes its screenshot and stores it on the device.

An attacker having physical access can easily download application files and access the screenshot that was revealing the victim's credit card details.

Similar to application screenshots, there are various ways such as device logs, pasteboard, cookies, and so on, where the application may leak sensitive data.

Poor authorization and authentication

In my security assessment, I have reported the login bypass vulnerability in many of the top applications, where the authenticating user was only at the client side. If you put proxy and change the server-side response, you are more likely to be logged in with wrong passwords.

So, as this case study suggests, never reply only on client-side controls for authentication. If you are using OAuth-like authentication schemas, make sure you store tokens on the client device securely. Attacker can easily bypass login on the victim device with leaked tokens.

Nowadays, most of the applications use web APIs to authenticate the users rather than storing credentials locally on the device. In such a scenario, all your web application security attacks are applicable, such as:

  • Brute forcing

  • CAPTCHA bypass

  • Flaws in password recovery

Broken cryptography

Broken cryptography is all about using insecure cryptographic functions to encrypt or hash user data on a device. Are you using MD5 to hash the user's password? Are you not adding any salt to the hashed data? Is your app leaking encryption keys somewhere in the local code? These are a few examples where we need to implement secure cryptographic functions with proper implementation schemas.

Client-side injection

Have you ever done SQL injection attack in web app? If yes, then you are good to go with similar attacks in an iOS application. If the developers are not sanitizing user input, then these apps are vulnerable to injection attacks as well. We will perform a SQL injection-like attacks on iOS application in Chapter 3, Identifying the Flaws in Local Storage.

Security decisions via untrusted input

Security decisions via untrusted input is about performing actions without proper validation or authorization check of the user. Does your application have functionality to call any number? Do you prompt the user before initiating a call? Are you checking whether the caller is a logged-in user? If not, you are more likely vulnerable to security decisions via untrusted input attack.

Improper session handling

Improper session handling is managing the user's session token insecurely. Many times, the developers do not invalidate session tokens at user logout. So, the attacker can reuse these tokens for unauthorized logins.

If an attacker is able to get the victim's token, he can use his credentials to login and can assign the victim's token using proxy to log in to the victim account.

Lack of binary protections

Lack of binary protections is about checking protections of binary. Checking whether the application allows attackers to reverse engineer the application source code is very important in case of application handling, as the user's sensitive data should not allow the attackers to entirely decompile the application. We can also check whether binary has implemented any protection for stack smashing attacks or implemented address space layout randomization (ASLR) in order to prevent memory corruption attacks.

We will study these concepts practically with more details in the upcoming chapters.