Module 7: Cloud, Mobile, and IoT Security

Researching Attack Vectors and Performing Attacks on Cloud Technologies

Many organizations are moving to the cloud or deploying hybrid solutions to host their applications. Organizations moving to the cloud are almost always looking to transition from capital expenditure to operating expenditure. Most fortune 500 companies operate in a multicloud environment. It is obvious that cloud computing security is more important today than ever before. Cloud computing security includes many of the same functionalities as traditional IT security, including protecting critical information from theft, data exfiltration, and deletion as well as privacy. The National Institute of Standards and Technology(NIST)authored Special Publication(SP)800–145 "The NIST Defination of Cloud Computing", to provide a standard set of definitions for the different aspects of Cloud computing. The SP 800–145 document also compares the different cloud services and deployment strategies. The advantages of using a cloud-based service include the following:

• Distributed storage
• Scalability
• Resource pooling
• Access from any location
• Measured service
• Automated management

According to NIST, the essential characteristics of cloud computing include the following:

• On-demand self service
• Broad network access
• Resource pooling
• Rapid elasticity
• Measured service

Cloud deployment models include the following:

• Public Cloud: Open for public use.
• Private Cloud: Used just by the client organization on premises or at a dedicated area in a cloud provider.
• Community Cloud: Shared between several organizations.
• Hybrid Cloud: Composed of two or more clouds(including on-prem services)

Cloud computing can be broken into the following three basic models:

1. Infrastructure as a service(IaaS) — IaaS is a cloud solution in which you rent infrastructure. You purchase virtual power to execute your software as needed. This is much like running a virtual server on your own equipment, except that you run a virtual server on a virtual disk. IaaS is similar to a utility company model in that you pay for what you use.
2. Platform as a Service(PaaS) — PaaS provides everything except applications. Services provided by this model include all phases of systems development life cycle(SDLC)and can use application programming interfaces(APIs), websites portals, or gateway software. These solutions tend to be proprietary, which can cause problems if the customer moves away from the provider's platform.
3. Software as a Service(SaaS) — SaaS is designed to provide a complete package solution. The software is rented out to be the user. The service is usually provided through some type of front end or web portal. While the end user is free to use the service from anywhere, the company pays a per-use fee.

Note — NIST Special Publication 500–292, "NIST Cloud Computing Reference Architecture", is another resource for learning about cloud architecture.

Many attacks against cloud technologies are possible, and the following are just some of them:

• Credential harvesting — Credential harvesting is not a new attack type, but the methodologies used by attackers have evolved throughout the years. Credential harvesting is the act of gathering and stealing valid usernames, passwords, tokens, PINs, and any other types of credentials through infrastructure breaches. In Module 4, "Social Engineering Attacks," you learned all about phishing and spear phishing attacks. One of the most common ways that attackers perform credential harvesting is by using phishing and spear phishing emails with links that could redirect a user to a bogus site. This "fake site" could be made to look like a ; legitimate cloud service, such as Gmail, Office 365, or even a social media site such as Twitter, LinkedIn, Instagram, or Facebook. This is why it is important to use multifactor authentication. However in some cases, attackers could bypass multifactor authentication by redirecting the user to a malicious site and stealing a session cookie from the user's browser.
• Privilege escalation — Privilege escalation is the act of exploiting a bug or design flaw in a software or firmware application to gain access to resource that normally would have been protected from an application or a user. This results in a user gaining administrative privileges beyond what the application developer originally intended. The original developer does not intend for the attacker to gain higher levels of access but probably doesn't enforce a need-to-know policy properly and/or hasn't validated the code of the application appropriately. Attackers take advantage of this gain access to protected areas of operating systems or to applications. Buffer overflows are used on Windows computers to elevate privileges as well. To bypass digital rights management on games and music, attackers use a method known as jailbreaking, which is another type of privilege escalation, most commonly found on Apple iOS-based mobile devices. The following are a couple different types of privilege escalation: 1. Vertical Privilege Escalation — This type of privilege escalation, also called privilege elevation, occurs when a lower-privileged user accesses functions reserved for higher-privilege users. To protect against this situation, you should update the network device firmware. 2. Horizontal Privilege Escalation — This type of privilege escalation occurs when a normal user accesses functions or content reserved for other normal users. This can be done through hacking or by a person walking over to someone else's computer and simply reading their email. Always have your users lock their computer when they are not physically at their desk.
• Account takeover — The underlying mechanics and the attacker motive of a cloud account takeover attack are the same as for an account takeover that takes place on premises. In an account takeover, the threat actor gains access to a user or application account and uses it to then gain access to more accounts and information. There are different ways that an account takeover can happen in the cloud. The impact that an account takeover has in the cloud can also be a bit different from the impact of an on-premises attack. There are a number of ways to detect account takeover attacks….. 1. Login location — The location of the user clue you in to a takeover. For instance, you may not do business in certain geographic locations and countries. You can prevent a user from logging in from IP addresses that reside in those locations. Keep in mind, however, that an attacker can easily use a VPN to bypass this restriction. 2. Failed login attempts — It is now fairly easy to detect and block failed login attempts from a user or an attacker. 3. Lateral phishing emails — These are phishing email that originate from an account that has already been compromised by the attacker. 4. Malicious OAuth, SAML, or OpenID Connect connections — An attacker could create a fake application that could require read, write, and send permissions for email SaaS offerings such as Office 365 and Gmail. Once the application is granted permission by the user to "connect" and authenticate to these services, the attacker could manipulate it. 5. Abnormal file sharing and downloading — You might suspect an account takeover attack if you notice that a particular user is suddenly sharing or downloading a large number of files.
• Metadata service attacks — Traditionally, software developers used hard-coded credentials to access different services, such as databases and shared files on an FTP server. To reduce the exposure of such insecure practices, cloud providers have implemented metadata services. When an application requires access to specific assets, it can query the metadata service to get a set of temporary access credentials. This temporary set of credentials can then be used to access services such as AWS Simple Cloud Storage(S3)buckets and other resources. In addition, these metadata services are used to store the user data supplied when launching a new virtual machine. By using tools such as nimbostratus (https://github.com/andresriancho/nimbostratus), you can find vulnerabilities that could lead to metadata service attacks.
• Attacks against misconfigured cloud assets — Attackers can leverage misconfigured cloud assets in a number of ways: 1. Identity and Access Management(IAM)Implementations — IAM solutions are used to administer user and application authentication and authorization. Key IAM features include SSO, multifactor authentication, and user provisioning and life cycle management. If an attacker is able to manipulate a cloud-based IAM solution in an IaaS or PaaS environment, it could be catastrophic for the cloud consumer (that is, the organization developing, deploying, and consuming cloud applications). 2. Federations Misconfigurations — Federated authentication is a method of associating a user's identity across different identity management systems. For example, every time you access a website, a web application, or a mobile application that allows you to log in or register with your Facebook, Google, or Twitter account, that application is using federated authentication. 3. Object Storage — Insecure permission configuration for cloud object storage services, such as Amazon's AWS S3 buckets, are often the cause of data breaches. 4. Containerization Technologies — Attacks against container-based deployments have led to massive data breaches. For instance, you can passively obtain information from Shodan or run active recon scans to find cloud deployments widely exposing the Docker daemon or Kubernetes elements to the internet. Often attackers use stolen credentials or known vulnerabilities to compromise cloud-based them in Docker Hub. Similarly, attackers use methods such as typosquatting to create malicious containers and post them in Docker Hub. This attack, which can be considered a supply chain attack, can be very effective.
• Resource exhaustion and denial-of-service(DoS)attacks — One of the benefits of leveraging cloud services is the distributed and resilient architecture that most leading cloud provides offer. This architecture helps minimize the impact of a DoS or distributed denial-of-service(DDoS)attack compared to what it would be if you were hosting your application on premises in your data center. On the other hand, in recent years, the volume of bits per second(bps), packets per second(pps), HTTP(s)requests per second(rps) have increased significantly. Often attackers use botnets of numerous compromised laptops and desktop systems and compromise mobile, IoT, and cloud-based systems to launch these attacks.
• Cloud malware injection attacks — Cloud deployments are susceptible to malware injection attacks. In a cloud malware injection attack, the valid instance running in the cloud infrastructure. Subsequently, the attacker can leverage this foothold to launch additional attacks, such as covert channels, backdoors, eavesdropping, data manipulation, and data theft.
• Side-channel attacks — Side-channel attacks are often based on information gained from the implementation of the underlying computer system instead of a specific weakness in the implemented technology or algorithm. For instance, different elements-such as computing timing information, power consumption, electromagnetic leaks, and even sound can provide detailed information that can help an attacker compromise system. The attacker aims to gather information from or influence an application or a system by measuring or exploiting indirect effects of the system or its hardware. Most side-channel attacks are used to exfiltrate credentials, cryptographic keys, and other sensitive information by measuring coincidental hardware emissions.

Tools and Software Development Kits (SDKs)

In module 6, "Exploiting Application-based Vulnerabilities" you learned that documents such as Swagger and the OpenAPI Specification documents can help you greatly when you're assessing API implementations. Swagger is a modern framework of API documentation and development that is the basis of the OpenAPI Specification(OAS). Additional information about Swagger can be obtained at https://swagger.io. The OAS specification is available at https://github.com/OAI/OpenAPI-Specification. Software development kits(SDKs) and cloud development kits(CDKs)can provide great insights about cloud-hosted applications, as well as the underlying infrastructure. An SDK is a collection of tools and resources to help with the creation of application. SDKs often include compilers, debuggers, and other software frameworks. CDKs, on other hand, help software developers and cloud consumer deploy applications in the cloud and use the resources that the cloud provider offers.

Explaining Common Attacks and Vulnerabilities Against Specialized Systems

1. Attacking Mobile Devices

Attackers use various techniques to compromise mobile devices. Select ach of these common mobile device attacks for more information.

• 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 and root or jailbreak mobile devices. NOTE OWASP has different "crack-me" exercises that help you practice reverse engineering of Android and iOS applications. See https://github.com/OWASP/owasp-mstg/tree/master/Crackmes.
• Sandbox analysis — iOS and Android apps are isolated from each other via sandboxes 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 inter-process 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 as. In Module 4, you learned about SMS phishing attacks, which continue to be some of the most common attacks against mobile users. In such 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
• Passcode vulnerabilities and biometrics integrations
• Certificate pinning
• Using known vulnerable components
• Execution of activities using root and over-reach of permissions
• Business logic vulnerabilities

In Module 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. Select each of the following tool for more information.

• Burp Suite
• Drozer — provides access to numerous exploits that can be used to attack Android. platforms.
• needle
• Mobile Security Framework(MobSF) — an automated mobile application and malware analysis framework.
• Postman — used to test and develop APIs.
• Ettercap — used to perform on-path attacks.
• Frida — dynamic instrumentation toolkit for security researchers and reverse engineers.
• Objection
• Android SDK tools
• ApkX — decompiles Android application package files.
• APK studio

"Mobile application developers must practice the least privilege concept. That is, mobile applications should not be able to run as root and should be only given the access necessary to performing required tasks."

Attacking Internet of Things (IoT) Devices

IoT is an incredibly broad term that can be applied across personal devices, industrial control system(ICS), transportation, and many other businesses and industries. Designing and securing IoT systems- including supervisory control and data acquisition(SCADA), Industrial Internet of Thing(IIoT), and IoT growth is expanding beyond the support capability of traditional IT stakeholders. 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.

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 S7 comm(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

TIP Tools such as GATTacker (https://github.com/securing/gattacker) can be used to perform on-path attacks in BLE implementations. BtleJuice (https://github.com/DigitalSecurity/BtleJuice) is a framework for performing interception and manipulation of BLE traffic.

"Three factors that add complexity to managing and securing IoT systems are additional complexity due to disparate hardware and software, the use of legacy technologies, and multiple vendors and integrators can operate in a single system."

IoT Security Special Considerations

There are a few special consideration to keep in mind when trying to secure IoT implementations.

1. Fragile Environment — Many IoT devices have limited compute resources. Because of this lack of resources, some security features, including encryption, may not even be supported in IoT devices.
2. Availability Concerns — DoS attacks against IoT systems are a major concern.
3. Data Corruption — IoT protocols are often susceptible to input validation vulnerabilities, as well as data corruption issues.
4. 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.

1. Insecure defaults — Default credentials and insecure default configuration are often concerns with IoT devices. For instance, if you do a search in Shodan.io for IoT devices, you will find hundreds of IoT devices with default credentials and insecure configuration exposed on the Internet.
2. 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.
3. Hard-coded configuration — Often IoT vendors sell their products with hard-coded insecure configuration or credentials.
4. 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.
5. "To ensure that the video surveillance equipment, and other IoT devices, are secure, the devices should be capable of encrypted communication, default credentials and configurations should be changed, and the device software should be updatable as needed."

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 to intermediary "fog" networks and cloud computing. Gateway and edge nodes are devices such as switches, routers, and computing platforms that act as intermediaries between the endpoints and the higher layers of the IoT system. 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 :

1. 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.
2. 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.
3. 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.
4. Underlying software vulnerabilities and injection vulnerabilities — In Module 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.
5. 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.

"The BMC component of IPMI, which has direct access to the system's motherboard and other hardware, may be leveraged to compromise the system. If the BMC is compromised, it will allow an attacker to monitor, reboot, and install implants (or any other software) in the system. Access to the BMC is 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.

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

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.

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

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. Select each tool for more information.

• Anchore's Grype — Grype is an open-source container vulnerability scanner that you can download from https://github.com/anchore/grype.
• 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/.