/Android-Pentest-Guide

Android Pentesting Guide

Table of Content

I. General Testing Guide

1. Mobile Application Taxonomy

Native app

Mobile OS come with a Software Development Kit (SDK) for developing apps specific to the OS. When an app is developed using the SDK, it is called a native app. For example, Android apps are developed using Java, Kotlin and Objective-C, Swift for iOS apps. Native apps are installed on the device and run on the device itself. Native apps are fast and responsive. They can access the device hardware and OS features due to their close integration with the OS. Native apps are also easy to distribute and update.

The downside of native apps is that they are developed for a specific OS. To develop an app for both Android and iOS, two separate apps need to be developed or introduced using a cross-platform framework. For example, React Native, Xamarin, Flutter

Apps developed using these frameworks internally use the APIs native to the system and the performance is the same as native app. These apps can make use of the device hardware. Therefore, these apps are considered native apps.

Web app

Web apps are websites that are designed to look like a native app. These apps run on top of a device's browser and are usually developed using HTML, CSS and JavaScript like a webpage

The advantage of web apps is that they are cross-platform and can be accessed from any device with a browser. The

The downside of web apps is that they have limited integration with the general components of the device and usually lack in performance compared to native apps.

Hybrid App

Hybrid apps are a combination of native and web apps. They executes like a native app, but a majority of the processes rely on web technologies, meaning a portion of the app runs in an embedded web browser,

Framework: Apache Cordova, Framework 7, Ionic, jQuery MobileNative Script, Onsen UI, Sencha Touch

Progressive Web App (PWA)

A progressive web app (PWA) is a website that looks and behaves as if it is a mobile app. PWAs are built to take advantage of native mobile device features, without requiring the end user to visit an app store, make a purchase and download software locally. Instead, a PWA can be located with a search engine query and accessed immediately through a browser.

PWAs are supported by Android and iOS, but not all hardware features are yet available.

2. Mobile Application Security Testing

2.1. Priciple of Testing

  • Black Box Testing: The tester doesn't have any information about the app being tested
  • White Box Testing: The tester has full knowledge the app being tested
  • Gray Box Testing: Some information about the app being tested is available to the tester

2.2. Vulnerability Analysis

Static Analysis

  • Manual Code Review

    Identifying key security vulnerability indicators by searching for certain APIs and keywords, such as database-related method calls like "executeStatement" or "executeQuery".

    Manual code review is very good for identifying vulnerabilities in the business logic, standards violations, and design flaws, especially when the code is technically secure but logically flawed.

  • Automated Source Code Analysis

Dynamic Analysis

The focus of DAST is the testing and evaluation of apps via their real-time execution. The main objective of dynamic analysis is finding security vulnerabilities or weak spots in a program while it is running.

Dynamic analysis is usually used to check for security mechanisms that provide sufficient protection against the most prevalent types of attack, such as disclosure of data in transit, authentication and authorization issues, and server configuration errors.

Penetration Testing

A typical security test is structured as follows

  • Preparation

    • Defining the scope of security testing, including identifying applicable security controls, the organization's testing goals, and sensitive data.
    • Includes all synchronization with the client as well as legally protecting the tester

  • Intelligence Gathering: Analyzing the environmental and architectural context of the app to gain a general contextual understanding.

    • Environmental: The organization's goals for the app, the relevant industry, stakeholders and investors, internal processes, workflows, and organizational structure
    • Architectural: The mobile app, The OS, Network, Remote Services

  • Mapping the application

    • Automated scanning and manually exploring the app: identifying its entry points, features, and data.
    • Mapping provides a thorough understanding of the app, its entry points, the data it holds, and the main potential vulnerabilities.

  • Exploitation

    • The security tester tries to penetrate the app by exploiting the vulnerabilities identified during the previous phase

    • The exploitation must be confirmed with respect to five axes:

      • Damage potential - the damage that can result from exploiting the vulnerability
      • Reproducibility - ease of reproducing the attack
      • Exploitability - ease of executing the attack
      • Affected users - the number of users affected by the attack
      • Discoverability - ease of discovering the vulnerability

  • Reporting

    • The security tester reports the vulnerabilities. This includes the exploitation process in detail, classifies the type of vulnerability, documents the risk if an attacker would be able to compromise the target and outlines which data the tester has been able to access illegitimately.

3. Mobile App Authentication Architectures

3.1 Stateful vs Stateless Authentication

With stateful authentication, a unique session id is generated when the user logs in. In subsequent requests, this session ID serves as a reference to the user details stored on the server.

With stateless authentication, all user-identifying information is stored in a client-side token. The token can be passed to any server or micro service.

3.2 Supplementary Authentication

Authentication schemes are sometimes supplemented by passive contextual authentication, which can incorporate:

  • Geolocation
  • IP address
  • Time of day
  • The device being used

4. Testing Network Communication

4.1 Server Trust Evaluation

Certificate Authorities (CAs) are an integral part of a secure client server communication and they are predefined in the trust store of each operating system

Both Android and iOS allow the user to install additional CAs or trust anchors.

Extending Trust

It might be necessary to avoid trusting any certificates added to the user trust store or even go further and only trust a pre-defined specific certificate or set of certificates

Restricting Trust: Identity Pinning

Pinning is the process of associating a remote endpoint with a particular identity, such as a X.509 certificate or public key, instead of accepting any certificate signed by a trusted CA. After pinning the server identity (or a certain set, aka. pinset), the mobile app will subsequently connect to those remote endpoints only if the identity matches.

  • General Guidelines

    Both Android and iOS recommendations match the "best case" which is:

    • Pin only to remote endpoints where the developer has control.
    • At development time via (NSC/ATS)
    • Pin a hash of the SPKI subjectPublicKeyInfo.

Verifying the TLS Settings

Recommend TLS Settings: TLS 1.2 and TLS 1.3

Cipher Suites Terminology

Cipher suites have the following structure:

Protocol_KeyExchangeAlgorithm_WITH_BlockCipher_IntegrityCheckAlgorithm

This structure includes:

  • A Protocol used by the cipher
  • A Key Exchange Algorithm used by the server and the client to authenticate during the TLS handshake
  • A Block Cipher used to encrypt the message stream
  • A Integrity Check Algorithm used to authenticate messages

Tools:

Intercepting HTTP(S) Traffic: Burp Suite, OWASP ZAP

Intercepting non-HTTP Traffic