CompTIA PenTest+ Certification: Basics of Specialized and Fragile Systems

In this guide, you will learn about
- Common attacks and vulnerabilities for specialized systems
- Mobile attacks, vulnerabilities, and tools
- Special considerations, vulnerabilities, and attacks for Internet of Things (IoT) and SCADA systems
- Data storage system vulnerabilities for on-premises and cloud configurations
- Vulnerabilities that apply to virtualized and containerized environments

Topics:
- Mobile Devices
- Testing Concepts
- Mobile Hardware
- Mobile Operating Systems Overview
- Mobile Applications Overview
- Testing iOS
- Testing Android
- Virtual and Containerized Systems
- Other Nontraditional Systems
- SCADA and Industrial Control Systems
- Embedded Systems

Specialized systems, including mobile, IoT, SCADA, and virtualized/containerized systems, have revolutionized the way people interact with each other and the Internet. Most tasks that required a home computer like e-mail, online banking, video chat, or watching movies can now be done from the convenience of a tablet or smart phone through mobile software applications. Automation for everything from factories to agriculture can now be managed over a network. With virtualization and containerization, enterprises have forever changed the paradigm for systems management and portability.

What each of these has in common is device specialization. These devices serve dedicated purposes and often operate under constraints that differentiate them from traditional devices. This could be a need to run for prolonged periods on battery power, to accommodate a smaller form factor, to conform to other industrial operating conditions, or to accommodate the operating parameters of providing an entirely virtualized stack. In turn, the operating systems and software are often customized to match. This means that traditional penetration testing methods that rely on OS-level access or that follow the rules of traditional networks may not apply in quite the same ways.

In this guide, we will discuss some of the concepts you may see on the CompTIA PenTest+ exam regarding mobile systems, virtualized devices, and other nontraditional systems at a high level. Please note, this is a wide area of expertise. To prep for the exam, we highly recommend using the resources provided in this guide for further reading.

Mobile Devices
When we talk about mobile devices, we’re typically talking about phones and tablets. The hardware is customized for a handheld form factor, long battery life, limited local storage, and security features that facilitate wireless and cellular communication. Generally, these devices will run either Android or iOS operating systems. Android is an open-source operating system, but iOS is proprietary. In either case, pentests tend to focus on security of local device storage, authentication and authorization, the ways applications interact with each other and the OS, communications, and anti-tampering or anti-reversing controls that exist on the device.

Note: : For more information about the Apple mobile platform’s hardware and its security model, check out the 2021 Apple Platform Security guide: https://manuals.info.apple.com/MANUALS/1000/MA1902/en_US/apple-platform-security-guide.pdf. Similarly, you can read more about the Android platform at https://developer.android.com/training/articles/security-tips.

Testing Concepts
Before we go into details about specific mobile operating systems, there are a few concepts that mobile testing platforms have in common. Mobile testing provides challenges not only surrounding what testing tools you use but how you install testing tools and applications, how you access devices, and even what environment you are able to use to perform your testing. We’ll talk about these in terms of four key concepts, including application sideloading, jailbreaks, emulators and simulators, and special test hardware.

Sideloading
Most mobile ecosystems limit application installation to a store. The Apple Store, as an example, is the only way to install an application on an iOS device. Android implements Google Play. If you need to test an application that isn’t available in these stores, you will either need to modify the device to allow sideloading (Android), or you will need special privileges, either as a developer or on the device itself (iOS). Sideloading is the process of installing applications that are unapproved for the device or that come from a source that is unapproved. For mobile devices, sideloading is typically accomplished via USB.

Jailbreaks
Without privileged operating system access, you can’t rely on logs, process monitoring, or other inputs you might normally have in order to evaluate functionality. You may not be able to install applications or other custom tooling. These limitations also prevent you from evaluating encrypted code or communications. Pentesting these devices often means working around that.

Jailbreaking, or “rooting,” is the process of exploiting a software vulnerability in a mobile OS that enables low-level execution with elevated privileges (i.e., root) to bypass the security mechanism in a mobile OS. Jailbreaking a device is useful when you do not have another way to sideload an application or need device-level access to evaluate application security. Both Android and Apple devices can be jailbroken, but available jailbreaks change over time.

There are four classifications of jailbreaks:
- Untethered  The device can be powered on and off without the help of a computer.
- Tethered  A computer and software are required to boot the jailbroken device each time.
- Semi-tethered  If the device is rebooted, you will need to jailbreak the device again to patch the kernel using a computer.
- Semi-untethered  This is the same as semi-tethered but can be accomplished using the jailbreak app that is already installed on the device.

How you jailbreak a device varies based on the device and operating system version. While there are some online-only jailbreaks (for example, see https://www.theiphonewiki.com/wiki/Jailbreak_Exploits), in most cases, you must sideload a jailbreak application to the device. For mobile devices, this is typically done via USB. Once you run the jailbreak, you will be granted privileged access to the device. But this is not foolproof. You always run the risk of rendering the device unusable, or “bricking” it. Therefore, it is advisable that you use a dedicated test device rather than your personal device for testing.
An important consideration, if you do jailbreak a device, is the process of jailbreaking changes the security of the device. This process may enable services that are not normally enabled or set default passwords that can be exploited by network attackers who can see a jailbroken device. Be especially cognizant of these changes while testing, and be sure to secure the device yourself rather than introducing a customer to the risk of data loss or compromise as a result of your actions. This may also mean that finding other jailbroken devices within your client’s scope could be a valid target for you during your pentest. Fun!

Note: : iOS Jailbreaking is discussed in detail in this SANS blog post series: https://www.sans.org/blog/checkra1n---part-1---prep/. To learn more about other types of jailbreaks or get help with jailbreaking your devices, check out the iOS Jailbreak subreddit: https://www.reddit.com/r/jailbreakandtheAndroidRoot subreddit: https://www.reddit.com/r/androidroot/

Emulators and Simulators
Another alternative to jailbreaking or rooting a device is to use an emulator or a simulator. Apple’s XCode is an integrated development environment (IDE) that includes the Apple software development kit (SDK) containing tools for iOS development, as well as a simulator for iOS. Android’s SDK also includes an emulator. The difference between an emulator and a simulator is that an emulator will mimic the hardware and operating system for the application being tested, but a simulator will only mimic the software environment. When testing the security of a mobile application or operating system, you may want to make sure you are using the real thing or something close to the original to ensure your results.

Caution: The biggest benefit to using an emulator or simulator versus an actual device is that if the emulator virtual machine breaks, you can start another one. If you brick the hardware device, it likely won’t be so easy to recover. As an added precaution, always remember to back up your data first before rooting or jailbreaking the device.

Test Hardware
Due to the extensive hardware-based controls on Apple devices, Apple provides an Apple Security Research Device (SRD) for researchers. Apple SRD is designed to allow researchers to test iOS without having to defeat its protection mechanisms. It allows sideloaded content and runs it with platform-equivalent permissions. This uses variant boot software that will not run on consumer hardware. However, these devices are only available through a tightly controlled program (https://developer.apple.com/programs/security-research-device/).

Mobile Hardware
Most mobile pentesting will focus on applications and peripheral connectivity. However, it’s worth understanding some device basics. The platform’s hardware determines what authentication features are available, such as what cameras and touch sensors are available for biometric identification controls, encryption engines, storage, user input, and external device connectivity.

Mobile devices are typically built with a system on a chip (SoC). The SoC is a small, integrated circuit that connects together common components that make up a mobile device, such as the CPU, GPU, RAM, ROM, and modem. For cellular communications, a SIM (subscriber identity module) card is unique and required in order to identify and authenticate a user’s device on the cellular network. Once authenticated, the user’s communications are encrypted. Setting a SIM personal identification number (PIN) on the mobile device can help protect your data in the event the device is lost or stolen.

Android and Apple both have hardware security features, but Apple devices have distinct hardware-based standardizations due to the closed-source nature of the ecosystem. One of the biggest differentiators, from iOS 5 and later, is the Secure Enclave. The Secure Enclave is isolated from the main processor, and it uses a dedicated processor and memory region, secure boot ROM, and dedicated AES engine. The AES hardware engine decrypts and encrypts files as they are written or read, and keying material is not exposed to the application processor or operating system. Apple uses this to implement several security protections to prevent hardware tampering and to protect biometric authentication data and its encryption.
Start by understanding that Apple protects device-specific secrets by generating a unique ID (UID) root cryptographic key for each device, and it protects software-specific secrets with a group ID (GID) that is shared across all devices of that type. These are used to ensure that changes to sensitive hardware (such as the internal SSD storage or the touch sensor) render encrypted data inaccessible. These keys are not recoverable, even when using a JTAG or other debugging interface.

Note: : JTAG stands for Joint Test Action Group. A JTAG interface is a hardware mechanism used for debugging and connecting to embedded devices on a circuit board. JTAG is an industry standard recognized in IEEE Std 1149.1. You can read more about the standard from the IEEE digital library at https://ieeexplore.ieee.org.

Mobile Operating Systems Overview
As you might suspect, with differences in the hardware, there are differences in the OS. These differences will influence what tools you use, where you look for information, and how you evaluate security of the device. In order to understand these differences, let’s dig into the iOS and Android operating systems.

iOS Operating System Security
The iOS operating system is proprietary, and iOS and its variants run exclusively on Apple mobile devices (i.e., iPhone, iPad). iOS is based on Darwin (www.puredarwin.org). Apple includes numerous security measures in the OS. For example, Apple limits available services and tools and loads the entire OS partition as read-only on disk to protect the OS contents. iOS also marks memory locations as nonexecutable through the Execute Never (XN) feature. The kernel checks applications accessing memory locations that are writeable and executable for Apple-only dynamic code-signing entitlement before being allowed.

Most system files, resources, and third-party applications are run as a nonprivileged mobile user. System applications and daemons use digitally signed entitlements to perform privileged operations. Entitlements are key-value pairs that allow authentication for applications outside of normal runtime parameters. Third-party applications gain access to user information and extensions or other features by way of declared entitlements. If a user grants an application access, that grant confers to the extensions embedded in the application, but not to extensions activated by the application.
 

Extensions are special signed executables packaged with the app that provide functionality to other apps. These extensions are detected and mapped for use during application install. Extensions are sandboxed—they run in a separate memory space and container from the application. Communication between extensions and the application that activated them must be handled through interprocess communications managed by the system framework. Apps and extensions from the same developer can use a shared App Group, which will allow them to share content using a shared container, preferences, and keychain items.
Additionally, iOS verifies vetted accessories via the Made for iPhone (MFI) program. When an MFI device is connected using a Lightning, USB-C connector, or Bluetooth, iOS validates it with a challenge-response protocol using an Apple-provided certificate from the accessory. A custom integrated circuit (IC) in the iDevice handles this exchange. This IC ensures that only approved accessories get full access to the device. If this authentication isn’t supported, access is limited to a subset of audio controls and functionality.

Android Operating System
Android is an open-source mobile operating system based on the Linux 2.x and 3.x kernels (https://developer.android.com) developed by Google. Android runs on a variety of hardware such as mobile phones, televisions, tablets, and other technological items.

The figure below describes the major components of the Android platform. On a mobile Android device, users interact within the application layer. This layer is also home for the native system apps that are installed by default such as the calendar app, camera, and e-mail. Android applications are developed in Java or Kotlin. Applications run their own processes within a virtual machine (i.e., an instance of ART, which is short for Android Runtime) as if they were separate user accounts with separate home directories. This provides isolation among all the other applications running on the device. The Java application programming interface (API) framework exposes features of the Android OS to simplify access to application data and other system components.

The primary components of an Android application are:

Figure:   The Android platform

- Activities  Parts of the application the user can see
- Fragments  A behavior that is placed in an activity
- Intents  Used for sending messages between other components
- Broadcast receivers  Allow an application to receive notifications from other apps
- Content providers  A SQLite database to store data in the form of a flat file
- Services  Used to start intents, send notifications, and process data

The hardware abstraction layer (HAL) interfaces with built-in hardware components of the device. The native C and C++ libraries provide support for applications developed in native code, such as HAL and ART. The kernel provides foundational services to other components within the platform, such as drivers, memory management, and display functionality.

Note: ART is the successor of the original runtime, the Dalvik Virtual Machine (DVM). Android versions 5.0 (API level 21) or higher no longer use DVM.
Android partitions are broken out on either the internal memory of the device or external storage. The following table describes common partitions created on most Android operating systems.




Mobile Applications Overview
For this guide, we will focus on mobile application testing, as it is the broadest area of knowledge. The OWASP Mobile Security project is an effort to provide resources and guidance for the secure development of mobile applications. As with web applications, OWASP has provided a Mobile Top Ten Risks, as illustrated below.

OWASP also provides security checklists, testing guides, and other information about testing and developing secure mobile applications. Within this project, mobile applications are categorized as native, web, hybrid, or progressive web applications.



Figure:   OWASP Mobile Top Ten Risks (2016)

Native applications can be closely coupled with the OS and have direct access to cameras, sensors, and other device components. To create these applications, developers use SDKs that are specialized for the OS. For Android, this means using Java or Kotlin, and for iOS, this means using Objective-C or Swift. As native apps are developed with close coupling to the OS, they will only work for a single OS unless they are ported using special development tools.
Web applications, on the other hand, look like native applications, but run like a web page in the device’s browser. These are often written in HTML5 and enjoy cross-platform portability. However, their functionality relies on communicating to an online back-end. As such, these can generally be tested with the same methodologies in this guide.
Hybrid and progressive applications are not as simple. Hybrid apps are a combination of web and native applications. Their components use a web-to-native abstraction layer to use both web and native features. On the other hand, progressive web apps load like web pages, but allow offline use and can access limited device functions, depending on the platform. These often have local components, including storage and application configurations in the form of a Web Application Manifest.

Note: : The OWASP Mobile App Security Checklist (https://github.com/OWASP/owasp-mstg) describes common areas of concern to be evaluated during mobile pentests, while the OWASP Mobile Security Testing Guide (MSTG, https://owasp.org/www-project-mobile-security-testing-guide/) elaborates on internals of the various platforms, defines standards for security testing of mobile applications, and outlines procedures and tools to perform various testing activities against mobile devices.

Each platform implements its own application format. Applications developed for Android are stored in the Android Package Kit (APK). Since Android applications are Java-based, an APK is in a Java Archive (JAR) format and includes a manifest file (AndroidManifest.xml), which embeds the contents in a binary XML format.

iOS applications are stored in the iOS App Store Package archive (IPA) format. The IPA is a ZIP-compressed archive containing all the code and resources needed to run the application. The built-in directory structure includes the Application.app, which resides inside the Payload folder and contains all the application code and resources; the application icon, stored in the iTunesArtwork folder; the iTunesMetadata.plist, which contains developer identification information, the bundle identifier, and other application identifying data; and extensions bundles, which are stored in directories named for the kit used to create them.
When applications run, they are sandboxed to prevent them from accessing data from other applications or making changes to the device. Each application has its own container, and if it needs to access device data or data from other applications, it must use services provided by the OS.

In iOS, this container includes
- The Bundle container, a read-only, signed container where the app and all of its resources reside
- The Data Container, which usually includes the Documents directory (for user-created and user-accessible content); the Library directory (a top-level directory for storing any files that are not user accessible, usually including an Application Support subdirectory for files the app needs to run but should be hidden from the user); and a tmp directory (for nonpersistent files)
- An iCloud container for cloud enablement

To test an application, you will either need to install and run it, or you will need a device with it already installed to observe. As mentioned earlier, mobile applications are frequently web clients that interface with other web services and APIs. Therefore, you can use many of the techniques we discussed in here and here in the mobile space. For example, the best way to evaluate the use of communication channels is to intercept the traffic and conduct network analysis. Use OWASP ZAP or Burp Suite to inspect and manipulate web traffic, search for weak or deprecated encryption algorithms, or use Postman to evaluate API abuse. In some cases, you will need to bypass certificate pinning in order to observe the traffic. 

Note: : OWASP’s article “Certificate and Public Key Pinning” explains what certificate pinning is and how it works within the context of mobile platforms: https://owasp.org/www-community/controls/Certificate_and_Public_Key_Pinning

Testing iOS
The OWASP Mobile Security Testing Guide recommends testing application input (including IPC, URL schemes, and user input), WebView-loaded content, back-end communication security, local data storage protection, and defense against reversing/repackaging to evaluate the security of iOS applications. To do this, you need either a copy of the application or access to a device that has the application installed.

Apple uses code signing to ensure only approved applications are run in iOS. Code can be signed by certificate validation, which requires registration and identity verification through the Apple Developer Program or the Apple Developer Enterprise Program. Verification is also done using code signature validation, which ensures all the libraries linked at launch have a valid Team ID extracted from Apple-issued certificates. The latter is a protection measure against loading third-party code by existing applications. If you have an Apple Developer account, you can sign iOS applications. Be aware, your account may be revoked if your actions are perceived as malicious, so use an account separate from your personal use account if you plan on any security research. As you might imagine from the extensive iOS security controls, testing iOS applications without jailbreaking the device is difficult.

Cydia Impactor
The Cydia Impactor tool (http://www.cydiaimpactor.com) is a GUI used to install IPA files to an iDevice. Jailbreaks, for example, are packaged as an IPA, and the Impactor tool is used to transfer the jailbreak over to the device for installation.

Follow these steps to install an app to your device:
1.: On your laptop, download the latest Cydia Impactor installation file for your appropriate operating system.
2.: Connect the mobile device to your laptop.
3.: On your laptop, open up the Cydia Impactor application. If Cydia recognizes the device, it will be displayed in the top drop-down menu box.



4.: Download the app for your device and iOS version to your laptop.
5.: On your laptop, open your favorite file manager GUI and drag the application file into the Cydia Impactor window. You will be asked for your Apple ID and password to continue. Enter the correct e-mail and password when prompted, then click the OK box to continue.
6.: If successful, Cydia Impactor will install the IPA to the device and you will see the app on the mobile device desktop.

Cydia Package Manager
The Cydia Package Manager is the app store for “jailbroken” iDevices. Jay Freeman (saurik) is the initial creator of Cydia, which is typically installed by default after a successful jailbreak, like the ones provided from Yalu and Pangu. The Cydia home screen provides access to features including user guides, themes that can be installed to the device, repositories (repos) for useful packages, and the ability to search for a package you want to install from a repo.

The figure below provides an example of what the Cydia home screen will look like. Some basic tools you may want to search for and install from the preconfigured repos are Class Dump, Wget, OpenSSH, and IPA Installer Console.



Figure:   Cydia Package Manager

Frida for Dynamic Analysis
Frida is a modular framework designed for assessing the security of mobile apps. Frida is not only an iOS testing tool. It can also be used for Android, Windows, Linux, macOS, and QNX testing. Frida has three modes of testing: Injected mode, where you spawn into a running program or are testing a device where frida-server is running; Embedded mode, which uses a shared library (frida-gadget) embedded into your app to interact remotely; and Preloaded mode. Frida includes a number of useful tools for testing, including a code tracing engine called Stalker for tracing threads and capturing functions and instructions that are executed. But it’s not a debugger. It doesn’t modify code at runtime or pause execution, for example. It’s also not a disassembler. Let’s look at a use case.

To install Frida, you should have Python 3.x and PyPI installed on your laptop. Then run:
$ pip3 install frida-tools

Assuming that you are using macOS, you can use Frida version 12.7.12 or above (github.com/frida/frida/releases/latest) to target a USB-connected iOS 13 device. Using Cydia, go to Manage | Sources | Edit | Add, and enter https://build.frida.re to add Frida’s repository.

You can now enter the command frida-ps to list all installed apps.
$ frida-ps -Ua

It should prompt you to connect your device via USB. When you connect it, you should see a list of all processes running on the jailbroken device. Now you can launch the application you want to test and connect to it with Frida using frida-trace.

Start by using frida-discover to look for calls to trace:
$ frida-discover -U MyApplication

Once you find an interesting API to follow, you can use frida-trace:
$ frida-trace -U MyApplication -i "TargetFunction"

The -i  flag tells it to hook a C function. For Objective-C functions, you would use the -m  flag. You can look at processes, trace APIs in a specific process, or inject into your application using the -l  flag to specify your injected script. Frida handles this with supplied tools like frida-ps and frida-trace; however, you can write your own or use community contributed code from repos like the Frida CodeShare (codeshare.frida.re/).

Note: : To read more about Frida, including other use cases, tips on writing scripts for injection, and documentation about Frida APIs, visit their documentation trove at https://frida.re/docs/home/.

Using Objection to Bypass SSL Pinning
Applications that communicate to external server back-ends will sometimes use SSL pinning to secure the connection. If it’s all encrypted and it’s pinned to the server’s certificate, even an on-path attack won’t help you test the traffic. You can use the Objection tool (https://github.com/sensepost/objection) to bypass SSL pinning.

Just like Frida, you should have Python3 and PyPI installed on your laptop and install objection using pip3:
$ pip3 install objection

You can then explore your USB-connected device by typing:
$ objection -g AppName explore

The objection command ios sslpinning disable will then attempt to bypass the SSL pinning, allowing you to inspect traffic using a tool such as Burp.




Using MobSF for Static Analysis
The Mobile Security Framework (MobSF) (https://github.com/MobSF) is an all-in-one, automated pentesting framework for mobile applications for Android, iOS, and Windows platforms. During this exercise, we will take the DVIA IPA (https://github.com/prateek147/DVIA-v2) and see what is under the hood.

Note: : You can read more about MobSF, including install instructions, requirements, and how-to’s, at https://mobsf.github.io/docs/#/.
With MobSF installed and running, open your web browser and go to https://127.0.0.1:8000, which is the default navigation page. Then, click on the Upload & Analyze button and locate the IPA file for DVIA and select it to upload the file into MobSF and start the static analysis process. In the terminal window where you launched MobSF, you will notice general logging and error messages while processing the file. Once analysis is complete, you will be taken to the Static Analysis page, where you can navigate the findings from the static analysis.

The figure below shows the Information and Options features for the DVIA application.



Figure:   Static analysis using MobSF
 

Property Lists: Every iOS application uses a property list (plist) file, which is typically encoded using the Unicode UTF-8 encoding and the contents are structured in XML.

The figure below provides an example plist file recovered by MobSF during static analysis. A plist is used to store configuration data about the app. These files are subject to information disclosure attacks and can be modified to bypass application restrictions.



Figure:   DVIA plist file
 

Binary Analysis  MobSF evaluates the DVIA application for potential vulnerabilities using security development best practices. Software assurance testing helps provide assurance that the software is free and clear of bugs, and binary analysis is a way to evaluate bugs in compiled software.

In the figure below, MobSF identified potentially insecure APIs used by DVIA. These APIs could pose an unnecessary security risk to the user.



Figure:   DVIA binary analysis vulnerability

Note: : MobSF does provide a dynamic analysis option for your Android device; however, this capability is not currently supported for iOS devices. You can find out more information from the MobSF GitHub page.

Testing Android
We talked earlier in this guide about jailbreaking or rooting a device in order to get broader access for testing. When you have physical access to your Android device, the most reliable way to connect is using the Android Debug Bridge (ADB).

Once you root the device, you can install and configure SSH and ssh to the device as “root.” ADB comes with the installation of Android Studio (https://developer.android.com/studio) and has many options. To see a list of command options, execute the command adb in a terminal window by itself. Once you have the device connected to the laptop, you can list the presence of the device or emulator using the following command:

To drop into a shell, use the command syntax adb shell. If you have multiple devices and emulators connected at the same time, you can specify which one to use:
adb -s <device name> shell

Once you are connected to a shell, you can elevate privileges on the device if it is rooted by using the su command. Then you can navigate the file system, similar to being in a standard Linux environment. The operating system has limited commands. For instance, if you wanted to see the kernel version and release date, you couldn’t use uname, as the command doesn’t exist. You could, however, find that information in the /proc/sys/kernel directory and read version and osrelease, as shown below.



Figure:   ADB: Identify kernel version and release date in Android

APK and DIVA
You can download the source file for DIVA from https://github.com/payatu/diva-android and compile it in Android Studio. Instructions for compiling inside of Android Studio are as follows:
 

1.: Download the source file and unzip the project file.
2.: Launch Android Studio from your laptop and import the project file.
3.: Install any Android Gradle missing dependencies.
4.: Next, build the APK from the menu bar and select Build, then Build APK. If successful, the APK will be downloaded to the apk directory, where you unzipped the source files. For me, the location was diva-android-master\app\build\outputs\apk. The file should be named something like app-debug.apk.
5.: Then we can use ADB to install the APK to the rooted device:
adb -s <device name> install app-debug.apk

Static Analysis
The APK Studio application is a reverse-engineering framework for disassembling and rebuilding Android applications. It provides a graphical user interface, code editor, and APK signing feature so you can modify code and repackage it if necessary.

APK Studio can be downloaded from https://github.com/vaibhavpandeyvpz/apkstudio and requires the latest versions of the following software products:
- Java Development Kit (JDK)
- Apktool
- Uber-apk-signer
- adb (optional) and zipalign (linux_x86 only)


Tip: If you receive an “Unsupported major.minor version…” error in the APK Studio console window when opening an APK, the likely reason is that you are running an older version of the JRE. You should try installing a newer version of the Java SDK to correct this issue.

Once APK Studio is successfully installed and configured, follow along as we investigate “Hardcode Issues - Part 1” from the DIVA mobile application.
 

1.: Start APK Studio and open the DIVA .apk file we built in the previous exercise using Android Studio.
2.: The objective is to find hardcoded information within the source. Sometimes developers will hard-code sensitive information for ease, such as a password. CWE-798 describes the issue a little further where attackers can leverage this weakness to bypass authentication.
3.: Click down through the folder structure until you find the diva folder, then click on HardcodeActivity.smali.
4.: Press ctrl-f and search for “secret.” You should land on a const-string value in quotes that you can plug into the equation and answer the exercise. If you are using macOS, use the command key command-f to search. This shows the hidden secret:




Note: Smali is a type of assembler, and Smali files are created when disassembling Dalvik executables (DEX), which are included in APKs.

Drozer
Drozer is a security auditing framework for Android that can help pentesters identify vulnerabilities and validate them with exploitation. The Drozer agent is installed on the Android device, and the console is installed on your laptop. You can download the community version of Drozer from https://github.com/mwrlabs/drozer. The user guide, which provides installation instructions and examples of how to use Drozer, can be downloaded from https://labs.mwrinfosecurity.com/tools/drozer.

The following exercise will examine some of the use cases documented in the Drozer user guide. After you have successfully installed the Drozer agent and console, follow along as we use Drozer to assess the DIVA mobile application.

Tip: Unfortunately, as of the time of this writing, in the latest version of Drozer the PATH detection issue is still a problem. In addition, make sure the display on the Android device stays active and that the device does not go to sleep to prevent the Drozer agent from terminating the connection prematurely.
 

1.: Put the Java path in the .drozer_config file in your home directory. Replace the <jdk ver> to match the Java install path you used for the updated JDK. For Windows it will be:



 

2.: Start the Drozer agent on the Android device. This can be done in “infrastructure mode,” where you provide a remote endpoint that can service multiple connections for exploitation, or “direct mode,” where you can connect to the agent’s embedded server using adb  and port forwarding. For this exercise, we will connect using the direct mode. This can be accomplished by opening up the Drozer agent from the Android device and clicking the “off” button in the bottom-right corner of the app window. This will start a TCP listener on port 31415. If it’s already “on,” then you can skip this step.
 

3.: Next, set up TCP forwarding to the Drozer agent from your laptop, using adb:
adb -s <device name> forward tcp:31415
 

4.: Then, execute the drozer.bat command to connect to the agent from the console:
drozer.bat console connect
 

5.: If the console connection was successful, your cursor should be blinking next to a dz> console prompt. Use the list command to display a full list of supported commands, and use the help command> to see arguments and help information for a specific command. To get a full list of packages installed on the device, execute the following command:
dz> run app.package.list

Tip: Android packages follow a similar naming convention as Java. The Android package name uniquely identifies the application (e.g., com.[company name].[package]). On the internal file system, these packages can be found in /data/data.
 

6.: The package we are looking for is called jakhar.aseem.diva. Now run the package info utility, as shown next. This will extract useful information about the app such as version information, where the application stores its data (i.e., external or internal), and the application permissions, like what the app can do.



 

7.: Next, let’s look at the attack surface for the application to see what is exposed to other applications on the device. The following illustration shows the Drozer command for identifying the attack service.

Android applications operate in a sandbox, like iOS applications. However, vulnerabilities exposed through the Android built-in interprocess communication (IPC) mechanisms could leak sensitive data and be at risk of compromise. The IPC mechanisms in Android include intents, binders, and broadcast receivers. The output shows one content provider, which we can investigate further to find out how it is organized to see if we can extract any information from it.



 

8.: Next we can run scanner.provider.finduris to find out the content uniform resource identifiers (URIs) we can query. Then we can try and query the content using app.provider.query with the --vertical flag, which displays the results up and down. Some content providers may share information over external storage, which could provide a means to access data outside the Android sandbox environment.

The following illustration provides the command syntax and results from executing the scanner and provider query.



 

9.: Android applications use SQLite databases for storing data, which can be queried using typical SQL query commands. SQLite databases (.db) are flat files stored on the file system. Content providers can be susceptible to SQL injections just like any other database. The app.provider.query command can be used to evaluate the SQL statement used to query the database. The --projection or --selection command option can be used to test for SQL injection in either the “projection” or “selection” fields in the query. The first command, shown in the following illustration, produces an error when injecting a “'” into the projection field used to select data from the notes table. The second command exploits the injection vulnerability to retrieve the SQLITE_MASTER table, which discloses all tables from the database. Now you can alter the SELECT statement to retrieve data from other tables in the database. If this app stored e-mail addresses, passwords, or other sensitive information in another table of the database, that data could be susceptible to compromise.



 

10.: Drozer also includes a command to scan for injection vulnerabilities in content providers called scanner.provider.injection. The vulnerable content provider we just exploited in the previous step is shown here.




Capturing API Requests with Postman
Postman (https://www.postman.com/) is a free tool for building and interacting with APIs. The tool simplifies many of the tasks necessary to intercept, manipulate, and send API requests that mobile applications may generate during the mobile app testing process. You will need to create an account to use Postman. Similarly to Burp Suite, Postman is used as an interception proxy and can work independently or with Burp Suite to enumerate and attack API endpoints.


Tip: For exam questions, read about Postman’s features and become more familiar with its interface by reading the tutorials on the Postman website: https://learning.postman.com/docs/getting-started/introduction/

First, let’s intercept requests from a mobile device.
1.: Connect your mobile device and your laptop or other testing platform to the same wireless network.
2.: In Postman, open a workspace, then click on the Proxy Settings button in the top menu bar.



 

3.: In the pop-up, you can supply a proxy port, or use the default port and choose the destination for saving your requests and responses. The default is port 5555 and saving requests only to History. You can also opt to exclude requests with images or CSS and apply URL-specific filters if you like.
4.: Set up the device to use your laptop IP and port 5555 as the proxy. This is usually under the wireless settings under the Modify Networks option.
5.: Now, when you open a browser on the mobile device or execute a mobile web application, you should see calls populate inside Postman.

Postman has several components, including request collections, a script runner, scriptable variables, Environments for context, pre-requests, and tests. Collections allow you to group similar API requests. When you run a collection, with Runner, you essentially send all of those requests in series. You can use this with variables for fuzzing GET or POST parameters in an API, for example. Additionally, Runner lets you build scripted test suites and workflows and send data between API requests. Variables in Postman are similar to variables in programming. You can reference variables in the body, URL, or headers of a request. Environments are key-value pairs that let you associate variables with a specific context (e.g., a specific user) in your test. You can use pre-request scripts to test API responses or set up variables or other test data. Once you receive an API response, Postman runs tests. Test scripts can parse response components and return boolean results. Therefore, Postman runs pre-request scripts, sends a request, gets a response, and then runs tests.

Note: : More documentation about built-in modules for JavaScript in Postman can be found at https://www.getpostman.com/docs/v6/postman/scripts/postman_sandbox_api_reference.

To build an API request from scratch (https://learning.postman.com/docs/getting-started/sending-the-first-request/), you need to specify an endpoint (the request URL), authorization details (Basic, OAuth, etc.), and any headers or body details that are required. Body details can be form data, raw data, binary data, or form-url-encoded data. Postman shows the response to an API request in the bottom of the app, as shown below. You can also take an API request you have captured and run it with manipulations instead.

Simply click on the observed request to load it on the right-hand side, manipulate it before running it, and go.



Figure:   Postman response

Virtual and Containerized Systems
Testing of virtual and containerized systems often evaluates the ability of a tester to break out of a container or guest system. In these cases, tests are limited by what is available within the container or guest, rather than what is available in the hypervisor or host. This may involve a reduced set of functionality with additional restrictions on operation. In other cases, testers may seek insecure stored credentials in setup or deployment scripts for those containers.

Note: : Microsoft maintains documentation about the difference between virtual machines and containers that will help contextualize the differences in pentesting approach: https://docs.microsoft.com/en-us/virtualization/windowscontainers/about/containers-vs-vm.

Also of note is Mike Coleman’s blog post “Containers are not VMs” on the Docker blog: https://www.docker.com/blog/containers-are-not-vms/
Hyper-V, vSphere, ESXi, and Citrix are all names you might hear in association with virtualized solutions. Virtualization solutions run a hypervisor—or virtual machine monitor (VMM)—which can run in a parent OS or on the hardware itself. The hypervisor handles hardware virtualization and resource management for each guest machine it hosts. Breaking out of a guest system and gaining access to the hypervisor (or its parent OS) may enable control over other systems being virtualized, depending on how host isolation is implemented and bypassed.

In the container world, you will hear names like Docker and Kubernetes (or K8). These run within an operating system and provide abstraction at the software level, rather than simulating or emulating hardware component interactions. In these cases, looking for unsecured tokens or other sensitive information in container setup scripts, finding ways to break out of the container (container escape), and finding ways to abuse software abstraction to affect other containers may be targeted.

In both cases, this requires that the tester gain privileged access within the virtualized system or container, and then find an exploit that allows escape from that container or guest to the hosting OS, and then gain elevated privileges within the parent or hosting OS in order to gain control over additional running virtual systems or containers. If the container or virtualized guest is run with elevated privileges on the parent or base OS, escape from the isolated environment will result in significantly more compromise. This run as root scenario is very common in Docker environments especially. Docker implements this with the --privileged  flag, e.g., docker run --rm -it --privileged ubuntu bash.
Docker uses Linux cgroups (https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt) as one of its methods of container isolation. In cgroups version 1, the notify_on_release feature executed the release_agent file with root privileges. This is designed to clean up abandoned cgroups, but can be abused for container escape.

This is one of many examples of container abuse. You can read a full writeup from Trail of Bits here: https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/

Note: : There are several good blog posts about attacking Kubernetes and Docker environments, including this one, “Hacking Containers Like A Boss” from Practical DevSecOps: https://www.practical-devsecops.com/lesson-4-hacking-containers-like-a-boss/ and the “Kubernetes Pentest Methodology” series from CyberArk: https://www.cyberark.com/resources/threat-research-blog/kubernetes-pentest-methodology-part-1

Other Nontraditional Systems
Pentesters may be called upon to evaluate the security of consumer devices (this is also referred to as Internet of Things, or IoT), such as smart home automation; smart devices; or specialized systems that are only used in industrial, health care, or other commercial settings. Some of these devices may be tested in the same way as mobile devices or other wireless devices. Network and wireless replay attacks, (in)secure channel testing, abuse of default or hardcoded credentials, and known weaknesses in firmware are all possible avenues of attack.
A good example of commercial systems that fall into this category are management systems that use the Intelligent Platform Management Interface (IPMI) protocol. These systems are high-value targets, because these embedded controller systems may have direct control over the hardware of their host systems. A successful compromise of a baseboard management controller (BMC), for example, will allow a tester to reboot, reinstall, or even monitor traffic from the host system with no visibility to the OS being observed. An Nmap scan may show these devices with Dropbear sshd on TCP port 22, lighthttpd on TCP ports 443 and 80, and TCP and UDP on port 623 (IPMI RMCP) enabled. Being able to recognize these devices and identify exploits to gain access to them may be important if you encounter these devices.

Note: : You may want to familiarize yourself further with IPMI exploitation so that you can recognize it on the exam. Rapid 7 has a good writeup on their blog: https://www.rapid7.com/blog/post/2013/07/02/a-penetration-testers-guide-to-ipmi/
Other specialized systems can only be attacked through hardware reverse engineering or custom attack methodologies. Two types of systems that bear special consideration as it pertains to attack methodology are SCADA and ICS systems and embedded systems using real-time operating systems (RTOSs). We’ll break these down a bit further next.

SCADA and Industrial Control Systems
Industrial control systems (ICSs) are systems that relate to industry automation of all types, including manufacturing, power generation (power plants), water treatment, and distribution systems.

Supervisory control and data acquisition (SCADA) systems pull data from ICS systems, coordinate transferring that data to a central place, and present it in a human-usable format so that components of the ICS can subsequently be controlled. A significant benefit of SCADA networks is alarm handling. Sensors deployed through the network will monitor conditions to ensure proper functionality. If the sensor indicates a change in normal operation, it can fire off an indicator and generate an alert in the system, and a human operator can manage the response.

As shown below, a SCADA system can be made up of multiple components, including:



Figure:   System concept of SCADA

- Supervisory workstation: A computer or console, which is the core of the system that gathers data and sends commands to connected devices, such as RTUs and PLCs.
- Remote terminal unit (RTU): Strategically placed on the network, close to the process being managed, and converts sensor signals and relays digital data back to the supervisory system.
- Programmable logic controller (PLC): Similar to RTUs, but with more sophisticated logic and configuration capabilities.
- Communication infrastructure: Connects devices and facilitates communications using popular SCADA protocols such as DNP3 (UDP based) and ModBus (TCP based).
- Human-machine interface (HMI): Operator application (typically a graphical user interface) installed on the supervisory system that is used to monitor and manage the supervisory control system.

Unfortunately, SCADA systems are not typically developed with security in mind and may be fragile as a result of their specialized implementation. SCADA networks typically operate under the “if it ain’t broke don’t fix it” mentality and are not patched nearly as often as corporate networks. These environments are often very expensive to retrofit, and some are required to follow stringent certification requirements for even the most minor change due to the potential for damage should unauthorized changes result in system failure. Therefore, many ICS and SCADA owners will require preapproval of tools to be used during a pentest and may have extensive limitations on writing files, installing tools, or even conducting network discovery on these networks. For some, even a single TCP or UDP port scan against a single component can cause catastrophic failure.

A report detailing the results of a survey conducted by the Idaho National Laboratory (INL) (www.inl.gov) and sponsored by the USDOE Office of Nuclear Energy, called “A Survey of Security Tools for the Industrial Control System Environment,” identifies existing tools that should be considered when investigating and testing for security weaknesses in an ICS environment. The report can be found on the U.S. Department of Energy Office of Scientific and Technical Information website at https://www.osti.gov. SCADA networks should typically be isolated from the corporate domain. They can fall victim to the same threats and attack vectors that affect typical IT systems. NIST Special Publication 800-82, “Guide to Industrial Control Systems (ICS) Security” (https://csrc.nist.gov), provides common weaknesses and vulnerabilities found in SCADA and ICS systems and how to apply necessary safeguards to the environment.

Tip: There is an Nmap NSE script that enumerates SCADA modules and collects device and vendor information available, called modbus-discover. ModBus typically operates on port 502/tcp.

As a result of the mind-set that these systems are better isolated than retrofitted, there are a few common weaknesses you should expect to see among ICS systems. In a traditional pentest cleartext protocols may not be desirable. In some of these environments, they may be unavoidable. Modbus, for example, is a cleartext protocol that is vulnerable to interception and replay. However, the costs and realities of trying to fix something like this are unrealizable for some of these environment owners. High-performance requirements may provide another reason these systems should be segmented from other networks. Other devices may have known weaknesses but are mission critical and have no viable replacement option. Manufacturers sometimes go out of business, and the specialized niche has not been taken up by other manufacturers. The same is true of legacy applications. In some cases, there are no other solutions that will run on the specialized operating systems in place, and there are simply no fixes available for the current solution. Hardcoded passwords, which cannot be changed by systems owners, may even be in use, or default passwords used by installers have not been changed. Password lists for these devices circulate freely online.
Pentests may need to focus on evaluating network segmentation and device isolation in the context of other devices in order to protect networks on which industrial Internet of Things (IIoT) or ICS and SCADA devices run. Remember that traditional risk concerns may not be as applicable to these environments as safety to personnel or the environment, impacts to the process, or regulations.

Embedded Systems
Embedded systems are made up of a combination of computer hardware and software designed and programmed for a specific purpose.

Microcontrollers and microprocessors are embedded systems built with processors and memory and are commonly found in home appliances and smart home automation, as well as health care devices, point-of-sale systems, vehicles, and multifunctional devices (printers and scanners). Some embedded systems provide a user interface that closely resembles modern-day operating systems, called a real-time operating system (RTOS), which is a stripped-down version of commonly deployed operating systems, such as Linux and Microsoft Windows.

An RTOS is required to adhere to deadlines associated with tasks, regardless of what happens in the system.

Some common RTOSs are LynxOS, OSE, QNX, Real Time (RT) Linux, VxWorks, and Windows CE (WinCE).

There are three classifications of RTOSs: hard, firm, and soft.

A hard RTOS must strictly adhere to time constraints for the associated task. Availability and time to react are extremely important in the design of these systems. In a medical application, such as a pacemaker, the device stimulates the heart muscle at just the right time. If the task is completed too late or too soon, the patient’s life could be at risk. Firm and soft RTOSs are still time sensitive; however, they offer some flexibility, as missing a deadline may cause undesirable effects but nothing catastrophic. Since most of the RTOSs are built from recycled code or existing operating systems, they are not exempt from known vulnerabilities.
RTOSs are difficult to patch and are typically in the form of a firmware update or upgrade and are not released as often by many vendors. Some of these systems run web-based applications and are configured with default credentials (i.e., admin/admin, admin/password), which make them easy targets for attacks. A pentester’s approach to assessing these devices over the network would be similar to the approach taken against a corporate IT system. The Nmap fingerprint database contains thousands of entries, which includes IoT network services and operating systems. IoT and embedded devices have been around for a while now and are growing in popularity each year. The Internet of Things Security Companion to the CIS Critical Security Controls, published by the Center for Internet Security, provides best practices for protecting embedded operating systems from common types of attacks.

Review

- In this guide, we’ve examined mobile pentesting and pentesting of specialized and fragile systems at a high level.
- There should be enough information in this guide to enable you to recognize questions about these devices, address some of the basic considerations about attack types and special considerations, and think about common weaknesses and vulnerabilities that apply to these devices.
- However, this is a very broad area of expertise, and you should do additional research into the topics by using the resources provided to help prepare yourself for the exam.
- Familiarize yourself with some of the tools in the exercises we have provided, and take time with their interfaces and outputs so that you can identify them and manipulate them if asked during the exam.