- “Do I Know This Already?” Quiz
- Researching Attack Vectors and Performing Attacks on Cloud Technologies
- Explaining Common Attacks and Vulnerabilities Against Specialized Systems
- Review All Key Topics
- Define Key Terms
- Q&A
This chapter is from the book
This chapter is from the book
This chapter is from the book
Explaining Common Attacks and Vulnerabilities Against Specialized Systems
In this section, you will learn about a variety of attacks against mobile devices, Internet of Things (IoT) devices, data storage system vulnerabilities, vulnerabilities affecting VMs, and containerized applications and workloads.
Attacking Mobile Devices
Attackers use various techniques to compromise mobile devices. These are some of the most common mobile device attacks:
Reverse engineering: The process of analyzing the compiled mobile app to extract information about its source code could be used to understand the underlying architecture of a mobile application and potentially manipulate the mobile device. Attackers use reverse engineering techniques to compromise the mobile device operating system (for example, Android, Apple iOS) and root or jailbreak mobile devices.
Sandbox analysis: iOS and Android apps are isolated from each other via sandbox environments. Sandboxes in mobile devices are a mandatory access control mechanism describing the resources that a mobile app can and can’t access. Android and iOS provide different interprocess communication (IPC) options for mobile applications to communicate with the underlying operating system. An attacker could perform detailed analysis of the sandbox implementation in a mobile device to potentially bypass the access control mechanisms implemented by Google (Android) or Apple (iOS), as well as mobile app developers.
Spamming: Unsolicited messages are a problem with email and with text messages and other mobile messaging applications as well. In Chapter 4, you learned about SMS phishing attacks, continue to be some of the most common attacks against mobile users. In such an attack, a user may be presented with links that could redirect to malicious sites to steal sensitive information or install malware.
The following are some of the most prevalent vulnerabilities affecting mobile devices:
Insecure storage: A best practice is to save as little sensitive data as possible in a mobile device’s permanent local storage. However, at least some user data must be stored on most mobile devices. Both Android and iOS provide secure storage APIs that allow mobile app developers to use the cryptographic hardware available on the mobile platform. If these resources are used correctly, sensitive data and files can be secured via hardware-based strong encryption. However, mobile app developers often do not use these secure storage APIs successfully, and an attacker could leverage these vulnerabilities. For example, the iOS Keychain is designed to securely store sensitive information, such as encryption keys and session tokens. It uses an SQLite database that can be accessed through the Keychain APIs only. An attacker could use static analysis or reverse engineering to see how applications create keys and store them in the Keychain.
Passcode vulnerabilities and biometrics integrations: Often mobile users “unlock” a mobile device by providing a valid PIN (passcode) or password or by using biometric authentication, such as fingerprint scanning or face recognition. Android and iOS provide different methods for integrating local authentication into mobile applications. Vulnerabilities in these integrations could lead to sensitive data exposure and full compromise of the mobile device. Attacks such as the objection biometric bypass attack can be used to bypass local authentication in iOS and Android devices. OWASP provides guidance on how to test iOS local authentication at https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06f-Testing-Local-Authentication.md.
Certificate pinning: Attackers use certificate pinning to associate a mobile app with a particular digital certificate of a server. The purpose is to avoid accepting any certificate signed by a trusted certificate authority (CA). The idea is to force the mobile app to store the server certificate or public key and subsequently establish connections only to the trusted/known server (referred to as “pinning” the server). The goal of certificate pinning is to reduce the attack surface by removing the trust in external CAs. There have been many incidents in which CAs have been compromised or tricked into issuing certificates to impostors. Attackers have tried to bypass certificate pinning by jailbreaking mobile devices and using utilities such as SSL Kill Switch 2 (see https://github.com/nabla-c0d3/ssl-kill-switch2) or Burp Suite Mobile Assistant app or by using binary patching and replacing the digital certificate.
Using known vulnerable components: Attackers may leverage known vulnerabilities against the underlying mobile operating system, or dependency vulnerabilities (that is, vulnerabilities in dependencies of a mobile application). Patching fragmentation is one of the biggest challenges in Android-based implementations. Android fragmentation is the term applied to the numerous Android versions that are supported or not supported by different mobile devices. Keep in mind that Android is not only used in mobile devices but also in IoT environments. Some mobile platforms or IoT devices may not support a version of Android that has addressed known security vulnerabilities. Attackers can leverage these compatibility issues and limitations to exploit such vulnerabilities.
Execution of activities using root and over-reach of permissions: Application developers must practice the least privilege concept. That is, they should not allow mobile applications to run as root and should give them only the access they need to perform their tasks.
Business logic vulnerabilities: An attacker can use legitimate transactions and flows of an application in a way that results in a negative behavior or outcome. Most common business logic problems are different from the typical security vulnerabilities in applications (such as XSS, CSRF, and SQL injection). A challenge with business logic flaws is that they can’t typically be found by using scanners or any other similar tools.
In Chapter 10, “Tools and Code Analysis,” you will learn details about many tools used in pen testing engagements. At this point, let’s look at some of the tools most commonly used to perform security research and test the security posture of mobile devices:
Burp Suite: In Chapter 10, you will learn about proxies and web application security tools such as Burp Suite. Burp Suite can also be used to test mobile applications and determine how they communicate with web services and APIs. You can download Burp Suite from https://portswigger.net/burp.
Drozer: This Android testing platform and framework provides access to numerous exploits that can be used to attack Android platforms. You can download Drozer from https://labs.f-secure.com/tools/drozer.
needle: This open-source framework is used to test the security of iOS applications. You can download needle from https://github.com/FSecureLABS/needle.
Mobile Security Framework (MobSF): MobSF is an automated mobile application and malware analysis framework. You can download it from https://github.com/MobSF/Mobile-Security-Framework-MobSF.
Postman: Postman is used to test and develop APIs. You can obtain information and download it from https://www.postman.com.
Ettercap: This tool is used to perform on-path attacks. You can download Ettercap from https://www.ettercap-project.org. An alternative tool to Ettercap, called Bettercap, is available at https://www.bettercap.org.
Frida: Frida is a dynamic instrumentation toolkit for security researchers and reverse engineers. You can download it from https://frida.re.
Objection: This runtime mobile platform and app exploration toolkit uses Frida behind the scenes. You can use Objection to bypass certificate pinning, dump keychains, perform memory analysis, and launch other mobile attacks. You can download Objection from https://github.com/sensepost/objection.
Android SDK tools: You can use Android SDK tools to analyze and obtain detailed information about the Android environment. You can download Android Studio, which is the primary Android SDK provided by Google, from https://developer.android.com/studio.
ApkX: This tool enables you to decompile Android application package (APK) files. You can download it from https://github.com/b-mueller/apkx.
APK Studio: You can use this tool to reverse engineer Android applications. You can download APK Studio from https://github.com/vaibhavpandeyvpz/apkstudio.
Attacking Internet of Things (IoT) Devices
IoT is an incredibly broad term that can be applied across personal devices, industrial control systems (ICS), transportation, and many other businesses and industries. Designing and securing IoT systems—(including supervisory control and data acquisition (SCADA), Industrial Internet of Things (IIoT), and ICS—involves a lot of complexity. For instance, IoT solutions have challenging integration requirements, and IoT growth is expanding beyond the support capability of traditional IT stakeholders (in terms of scalability and the skills required). Managing and orchestrating IoT systems introduces additional complexity due to disparate hardware and software, the use of legacy technologies, and, often, multiple vendors and integrators. IoT platforms must integrate a wide range of IoT edge devices with varying device constraints and must be integrated to back-end business applications. In addition, no single solution on the market today can be deployed across all IoT scenarios.
The IoT market is extremely large and includes multiple platform offerings from startups as well as very large vendors. In many cases, IoT environments span a range of components that include sensors, gateways, network connectivity, applications, and cloud infrastructure. The unfortunate reality is that most IoT security efforts today focus on only a few elements of the entire system. A secure IoT platform should provide the complete end-to-end infrastructure to build an IoT solution, including the software, management, and security to effectively collect, transform, transport, and deliver data to provide business value. This is, of course, easier said than done.
Analyzing IoT Protocols
Analyzing IoT protocols is important for tasks such as reconnaissance as well as exploitation. On the other hand, in the IoT world, you will frequently encounter custom, proprietary, or new network protocols. Some of the most common network protocols for IoT implementations include the following:
Wi-Fi
Bluetooth and Bluetooth Low Energy (BLE)
Zigbee
Z-Wave
LoraWAN
Insteon
Modbus
Siemens S7comm (S7 Communication)
For instance, Bluetooth Low Energy (BLE) is used by IoT home devices, medical, industrial, and government equipment. You can analyze protocols such as BLE by using specialized antennas and equipment such as the Ubertooth One (https://greatscottgadgets.com/ubertoothone/). BLE involves a three-phase process to establish a connection:
Phase 1. Pairing feature exchange
Phase 2. Short-term key generation
Phase 3. Transport-specific key distribution
BLE implements a number of cryptographic functions. It supports AES for encryption and key distribution exchange to share different keys among the BLE-enabled devices. However, many devices that support BLE do not even implement the BLE-layer encryption. In addition, mobile apps cannot control the pairing, which is done at the operating system level. Attackers can scan BLE devices or listen to BLE advertisements and leverage these misconfigurations. Then they can advertise clone/fake BLE devices and perform on-path (formerly known as man-in-the-middle) attacks.
In some cases, IoT proprietary or custom protocols can be challenging. Even if you can capture network traffic, packet analyzers like Wireshark often can’t identify what you’ve found. Sometimes, you need to write new tools to communicate with IoT devices.
IoT Security Special Considerations
There are a few special considerations to keep in mind when trying to secure IoT implementations:
Fragile environment: Many IoT devices (including sensors and gateways) have limited compute resources. Because of this lack of resources, some security features, including encryption, may not even be supported in IoT devices.
Availability concerns: DoS attacks against IoT systems are a major concern.
Data corruption: IoT protocols are often susceptible to input validation vulnerabilities, as well as data corruption issues.
Data exfiltration: IoT devices could be manipulated by an attacker and used for sensitive data exfiltration.
Common IoT Vulnerabilities
The following are some of the most common security vulnerabilities affecting IoT implementations:
Insecure defaults: Default credentials and insecure default configurations are often concerns with IoT devices. For instance, if you do a search in Shodan.io for IoT devices (or click on the Explore section), you will find hundreds of IoT devices with default credentials and insecure configurations exposed on the Internet.
Plaintext communication and data leakage: As mentioned earlier, some IoT devices do not provide support for encryption. Even if encryption is supported, many IoT devices fail to implement encrypted communications, and an attacker could easily steal sensitive information. The leakage of sensitive information is always a concern with IoT devices.
Hard-coded configurations: Often IoT vendors sell their products with hard-coded insecure configurations or credentials (including passwords, tokens, encryption keys, and more).
Outdated firmware/hardware and the use of insecure or outdated components: Many organizations continue to run outdated software and hardware in their IoT devices. In some cases, some of these devices are never updated! Think about an IoT device controlling different operations on an oil rig platform in the middle of the ocean. In some cases, these devices are never updated, and if you update them, you will have to send a crew to physically perform a software or hardware upgrade. IoT devices often lack a secure update mechanism.
Data Storage System Vulnerabilities
With the incredibly large number of IoT architectures and platforms available today, choosing which direction to focus on is a major challenge. IoT architectures extend from IoT endpoint devices (things) to intermediary “fog” networks and cloud computing. Gateways and edge nodes are devices such as switches, routers, and computing platforms that act as intermediaries (“the fog layer”) between the endpoints and the higher layers of the IoT system. The IoT architectural hierarchy high-level layers are illustrated in Figure 7-4.
)
FIGURE 7-4 IoT Architecture Layers
Misconfigurations in IoT on-premises and cloud-based solutions can lead to data theft. The following are some of the most common misconfigurations of IoT devices and cloud-based solutions:
Default/blank username/password: Hardcoded or default credentials are often left in place by administrators and in some cases by software developers, exposing devices or the cloud environment to different attacks.
Network exposure: Many IoT, ICS, and SCADA systems should never be exposed to the Internet (see https://www.shodan.io/explore/category/industrial-control-systems). For example, programmable logic controllers (PLCs) controlling turbines in a power plant, the lighting at a stadium, and robots in a factory should never be exposed to the Internet. However, you can often see such systems in Shodan scan results.
Lack of user input sanitization: Input validation vulnerabilities in protocols such as Modbus, S7 Communication, DNP3, and Zigbee could lead to DoS and code execution.
Underlying software vulnerabilities and injection vulnerabilities: In Chapter 6, you learned about SQL injection and how attackers can inject malicious SQL statements after “escaping input” with a single quote (by using the single quote method). IoT systems can be susceptible to similar vulnerabilities.
Error messages and debug handling: Many IoT systems include details in error messages and debugging output that can allow an attacker to obtain sensitive information from the system and underlying network.
Management Interface Vulnerabilities
IoT implementations have suffered from many management interface vulnerabilities. For example, the Intelligent Platform Management Interface (IPMI) is a collection of compute interface specifications (often used by IoT systems) designed to offer management and monitoring capabilities independently of the host system’s CPU, firmware, and operating system. System administrators can use IPMI to enable out-of-band management of computer systems (including IoT systems) and to monitor their operation. For instance, you can use IPMI to manage a system that may be powered off or otherwise unresponsive by using a network connection to the hardware rather than to an operating system or login shell. Many IoT devices have supported IPMI to allow administrators to remotely connect and manage such systems.
An IPMI subsystem includes a main controller, called a baseboard management controller (BMC), and other management controllers, called satellite controllers. The satellite controllers within the same physical device connect to the BMC via the system interface called Intelligent Platform Management Bus/Bridge (IPMB). Similarly, the BMC connects to satellite controllers or another BMC in other remote systems via the IPMB.
The BMC, which has direct access to the system’s motherboard and other hardware, may be leveraged to compromise the system. If you compromise the BMC, it will provide you with the ability to monitor, reboot, and even potentially install implants (or any other software) in the system. Access to the BMC is basically the same as physical access to the underlying system.
Exploiting Virtual Machines
A VM is supposed to be a completely isolated system. One VM should not have access to resources and data from another VM unless that is strictly allowed and configured. Figure 7-5 shows three VMs running different applications and operating systems.
)
FIGURE 7-5 VM Example
The hypervisor is the entity that controls and manages the VMs. There are two types of hypervisors:
Type 1 hypervisors (also known as native or bare-metal hypervisors) run directly on the physical (bare-metal) system. Examples of Type 1 hypervisors include VMware ESXi, Proxmox Virtual Environment, Xen, and Microsoft Hyper-V.
Type 2, or hosted, hypervisors run on top of other operating systems. Examples of type 2 hypervisors include VirtualBox and VMware Player or Workstation.
These virtual systems have been susceptible to many vulnerabilities, including the following:
VM escape vulnerabilities: These vulnerabilities allow an attacker to “escape” the VM and obtain access to other virtual machines on the system or access to the hypervisor. In Figure 7-6, an attacker finds a VM escape vulnerability in the underlying hypervisor and uses that vulnerability to access data from another VM.
FIGURE 7-6 VM Escape Attack
Hypervisor vulnerabilities such as hyperjacking: Hyperjacking is a vulnerability that could allow an attacker to control the hypervisor. Hyperjacking attacks often require the installation of a malicious (or “fake”) hypervisor that can manage the entire virtual environment. The compromised or fake hypervisor operates in a stealth mode, avoiding detection. Hyperjacking attacks can be launched by injecting a rogue hypervisor beneath the original hypervisor or by directly obtaining control of the original hypervisor. You can also launch a hyperjacking attack by running a rogue hypervisor on top of an existing hypervisor.
VM repository vulnerabilities: Attackers can leverage these vulnerabilities to compromise many systems and applications. There are many public and private VM repositories that users can leverage to deploy VMs, including different operating systems, development tools, databases, and other solutions. Examples include the VMware Marketplace (https://marketplace.cloud.vmware.com/) and AWS Marketplace (https://aws.amazon.com/marketplace). Attackers have found ways to upload fake or impersonated VMs with malicious software and backdoors. These ready-to-use VMs are deployed by many organizations, allowing the attacker to manipulate the user’s systems, applications, and data.
)
Vulnerabilities Related to Containerized Workloads
As shown in Figure 7-7, computing has evolved from traditional physical (bare-metal) servers to VMs, containers, and serverless architectures.
)
FIGURE 7-7 The Evolution of Computing
Vulnerabilities in applications and in open-source software running in containers such as Docker, Rocket, and containerd are often overlooked by developers and IT staff. Attackers may take advantage of these vulnerabilities to compromise applications and data. A variety of security layers apply to containerized workloads:
The container image
Software inside the container
The host operating system
Interaction between containers and the host operating system
Security in runtime environment and orchestration platforms such as Kubernetes
Figure 7-8 shows three key security best practices that organizations should use to create a secure container image.
)
FIGURE 7-8 Securing Container Images
Often software developers run containers with root privileges. These containers are one vulnerability away from full compromise.
A number of tools allow you to scan Docker images for vulnerabilities and assess Kubernetes deployments. The following are a few examples of these tools:
Anchore’s Grype: Grype is an open-source container vulnerability scanner that you can download from https://github.com/anchore/grype. Figure 7-9 demonstrates the use of the Grype scanner to find vulnerabilities in a Docker image.
Clair: Clair is another open-source container vulnerability scanner. You can download it from https://github.com/quay/clair.
Dagda: This set of open-source static analysis tools can help detect vulnerabilities, Trojans, backdoors, and malware in Docker images and containers. It uses the ClamAV antivirus engine to detect malware and vulnerabilities. You can download Dagda from https://github.com/eliasgranderubio/dagda/.
kube-bench: This open-source tool performs a security assessment of Kubernetes clusters based on the CIS Kubernetes Benchmark. You can download kube-bench from https://github.com/aquasecurity/kube-bench.
kube-hunter: This open-source tool is designed to check the security posture of Kubernetes clusters. You can download kube-hunter from https://kube-hunter.aquasec.com/.
Falco: You can download this threat detection engine for Kubernetes from https://falco.org/.
)
FIGURE 7-9 Scanning Container Images with Grype
Another strategy that threat actors have used for years is to insert malicious code into Docker images on Docker Hub (https://hub.docker.com). This has been a very effective “supply chain” attack.
Exam Preparation Tasks
As mentioned in the section “How to Use This Book” in the Introduction, you have a couple choices for exam preparation: the exercises here, Chapter 11, “Final Preparation,” and the exam simulation questions in the Pearson Test Prep software online.