CompTIA Pentest+ PT0-002 – Section 13: Cloud Attacks Part 1

123. Cloud Attacks (OBJ 3.4)

In this section of the course, we’re going to discuss the different types of cloud attacks that we can use for assets hosted using cloud service providers like Amazon Web Services, Microsoft Azure and the Google Cloud Platform. As more and more organizations move their servers, systems and services into the cloud, more and more of our penetration tests and engagements are becoming more focused on cloud-based vulnerabilities and the exploits we can use to attack them. So, as you can probably guess, we’re going to continue looking at various attacks and exploits that we can use during the third stage of our engagement throughout this section of the course. Now, as we move through this section, we’re going to be focused on covering objective 3.4 for the exam.

This objective states that given a scenario, you must research attack vectors and perform attacks on cloud technologies. Now, as we move through this section of the course, we’re going to begin by discussing some basic cloud-based attacks such as malware injection attacks, side channel attacks and direct to origin attacks. Then, we’re going to look at methods to conduct credential harvesting against a cloud service in order to steal usernames and passwords. Once you gain those passwords, you can then conduct an account takeover or you can conduct a privilege escalation, depending on your goals during that engagement.

After that, we’re going to move into discussing the different ways that cloud assets may be misconfigured that will make more vulnerable to attack. This includes misconfigurations involving identity and access management, identity Federation, object storage and containerization technologies. Then, we’re going to move into our discussions of resource exhaustion which can be caused by many different types of denial of service attacks or stress testing. Next, we’re going to cover SDKs or software development kits and how those are going to be used by cloud engineers so that you can better understand how to exploit them. Finally, we’re going to move into our coverage of how you can audit a cloud service using tools like ScoutSuite, Prowler, Pacu, CloudBrute and Cloud Custodian during your engagements. All right. It’s time to continue our coverage of domain three, attacks and exploits with cloud attacks in this section of the course.

124. Attacking the Cloud (OBJ 3.4)

In this lesson, we’re going to explore a few different methods of attacking the cloud. This includes malware injection attacks, side-channel attacks, direct-to-origin attacks, and denial of service attacks that are caused by resource exhaustion. When we discuss different types of cloud attacks, we are going to be focusing our studies on the different attack vectors. An attack vector is a path or method by which an attacker or penetration tester can gain access to a cloud-based server or service to deliver some kind of malicious outcome. The first type of cloud attack vector that we’re going to cover is known as a malware injection attack. Now a malware injection attack is conducted to take over control of a user’s information in the cloud by attempting to add an infected service implementation module to the cloud service by injecting it into an application. This could occur using an SQL injection, an XML injection, a cross-site scripting attack, or other attack vectors to insert malicious code or a malicious module into the cloud-based application or service. If the attacker is successful in inserting that malicious code, the code can then be used to redirect the end user’s request to the malicious code or module to execute that malicious logic code that was inserted into that cloud service.

The end goal in this type of an attack can vary from engagement to engagement, but the overall concept is the same, the attacker’s attempting to insert malicious code into a cloud service or server, and then have it execute that malicious code when the end user makes request to that cloud service. The second type of cloud attack vector we need to cover is known as a side-channel attack. A side-channel attack is a type of attack that aims to measure or exploit the indirect effects of a system instead of targeting the code or program directly. A side-channel attack is also referred to as a sidebar attack or implementation attack. There are many different types of side-channel attacks, depending on your actual target. For cloud-based targets, the most common type of side-channel attack is going to attempt to exploit the shared nature of the cloud structure in order to gain sensitive information that may be leaking out of the infrastructure such as cryptographic keys that are used by cloud-based servers. Side-channel attacks often attempt to compromise an Infrastructure as a Service cloud-based architecture by placing a virtual machine on the same physical server as their targeted virtual machine. Then the attacker attempts to extract useful information from the target virtual machine using a covert channel by identifying sensitive details from that targeted virtual machine. To prevent a side-channel attack from occurring, all data stored in a cloud should be encrypted and strong multi-factor authentication checks need to be enabled.

Cyber security professionals all also need to ensure that they verify all of their cloud service configurations through routine monitoring and auditing to ensure that their virtual servers are patched, hardened, and resistant to a side-channel attack. The third type of cloud attack vector that we need to discuss is known as a direct-to-origin attack or D2O. Now in most cloud-based architectures, organizations have enabled reverse proxies that sit in front of any public-facing web servers to reduce the possibility of an attack occurring. A direct-to-origin attack is going to attempt to bypass the reverse proxies in order directly attack the original network or IP address of that cloud-based server. Now, if an attacker can identify the IP address of the origin server or network, they can then attack that origin directly in a direct-to-origin attack. To conduct a direct-to-origin attack, an attacker is first going to launch their attack against the cloud-based service through the normal reverse proxy. This reverse proxy should block the attack, but during this attempt, the attacker can try to use multiple techniques to disclose the origin IP or network addresses of the origin servers. If they’re able to gather that information about the origin servers, the attack can then be launched directly against that origin and completely bypass the reverse proxy or other forms of distributed denial of service protection that may be enabled for that cloud service. This brings us to our fourth type of cloud attack that we need to discuss, denial of service attacks.

Now denial of service attacks, also known as a DoS, are used to attack any protocol, device, operating system or service to try and disrupt the services that it provides to the users. Denial of service attacks are usually caused by resource exhaustion where a given system or service is exploited by an attacker who is attempting to consume all of the CPU, memory, disk space, or allowed client connections in order to prevent the server or service from providing service to its legitimate users. If all of those resources are exhausted, then the system could have a failure or even fully crash. There are many different resource exhaustion techniques that are used in trying to create a denial of service condition in cloud-based systems and services. This includes amplification or volumetric attacks and the fragmentation of request. An amplification or volumetric attack is used to saturate the bandwidth of a given network resource. For example, if an organization is using a 10-megabit per second elastic file system connection for any data being sent from its mounted and shared EFS drive over to its cloud servers, an attacker can quickly overwhelm this connection by continually requesting large files from that EFS or elastic file system resource as part of their attack.

As that 10-megabit per second link becomes saturated, the entire web application is going to slow down or even stop working due to resource exhaustion. The fragmentation of requests can also be used to create resource exhaustion by sending multiple fragmented HTTP requests over to a server. Since the requests are fragmented, the server has to manage these fragmented pieces that are coming in until it can match up those fragmented requests fully to capture the full request that’s being made. Similar to a puzzle, the server can’t see the big picture yet and answer the request until all those fragmented pieces are reassembled into a complete request. During the time the server is holding all these fragmented pieces, waiting for the final parts of the request to come in, this requires a server to allocate resources to it. And if those resources are not freed up by completing those requests, it can become possible that resource exhaustion could occur, and this creates a denial of service condition. Other common types of denial of service attacks can also be used against cloud-based servers, and this includes things like packet floods, SYN floods, HTTP floods, DNS floods, DNS amplification attacks, and NTP amplification attacks just to name a few. Really, any type of attack that can lead to using up resources on the server or service, including its CPU, memory, storage, or network bandwidth can be classified as resource exhaustion or a denial of service attack.

125. Credential Harvesting (OBJ 3.4)

In this lesson, we’re going to discuss credential harvesting in the cloud. Credential harvesting is any attack designed to steal usernames and passwords. And this can be accomplished using social engineering and phishing attacks, the installation of malware, an on-path attack, DNS poisoning attacks, and many other methods. By far, though, the most common method of credential harvesting is going to occur against an organization’s cloud-based email services. This normally occurs through some form of social engineering attack, such as a phishing, spear phishing, whaling and smishing campaign, where the attacker tries to trick the user into entering their login details on a website that’s masquerading as the organization’s own legitimate user portal. Now, once the employee enters their username and password, the attacker now has a set of values or credentials that they can use for other exploits and attacks.

With those credentials, the attacker can log into the system as if they were a legitimate user and conduct an account takeover. Now, an account takeover is a strategy used by attackers to silently embed themselves within an organization to slowly gain additional access and infiltrate new organizations over time. Advanced persistent threats are especially adept at conducting account takeovers in cloud-based systems, which can let them remain undetected for weeks, months, or even years. Once the attacker has taken over an account, they can use that account to perform a business email compromise with the attacker who is now acting as a trusted insider, can ask for additional details and information as they expand their access.

Account takeovers are very dangerous because they’re really hard to detect. Once an attacker has a valid set of user credentials, they’re going to be considered a legitimate user by that system and its services. This means that the attacker can now gain access to the user’s email, the company shared drive, and other resources that contain sensitive information. Another form of account takeover that you need to be aware of in this world of cloud computing is where an attacker can take control of your overall cloud service provider account.

For example, if the attacker is able to conduct an account takeover of a cloud administrator or your domain’s representative, they can then create additional cloud servers and services and have them all build to your organization. In these cases, your organization and its data are not the real targets, but instead, your authorized cloud services account and your organization’s high credit limit is the real target. This allows an attacker to spin up new virtual servers that can be configured to do heavy compute loads for the attacker’s benefit. For example, let’s pretend that an attacker was able to take over your AWS account, and that account is tied to your corporate credit card that has a hundred thousand dollars limit. Using that account, the attacker can begin to spin up virtual servers and then have them mine for Bitcoin and other cryptocurrencies, allowing them to earn money by using up the compute resources that are being charged back to your credit card.

And those crypto earnings will be untraceable and fully liquid, unlike a credit card. Now, in addition to taking over a user’s account, though, an attacker can also try to escalate their privileges of that account up to a higher level so they can access other sensitive files and information, or they can conduct horizontal privilege escalation to access another user’s account and information. Basically, a privilege escalation occurs whenever an attacker is able to gain the rights of another user or an administrator. So, if an attacker can break into your cloud services as a standard user and then escalate up to the root or administrative level account, they can now more effectively take over that server or service. This is the idea of privilege escalation. Privilege escalation can occur either vertically or horizontally.

When it occurs vertically, it goes up from a user to an admin or root account. We call this vertical privilege escalation because the attacker is gaining higher rights than they initially had as that standard user. On the other hand, if we talk about horizontal privilege escalation, this involves moving from one user account to another user account. For example, let’s say that John and Mary both work for Big Corp. John works in the sales department and Mary works in the accounting department. If an attacker is able to get into John’s account, they’re only going to have access to his emails and the sales department’s shared drive, but they’re not going to be able to access the accounting files, so that attacker may want to do a horizontal escalation of their privileges and take over Mary’s account. That way, they can now have access to the accounting files as well.

Since both of these are considered regular users, this is considered a horizontal privilege escalation. Now, horizontal privilege escalation is a very common technique that’s used by attackers and penetration testers to allow them to conduct lateral movement throughout the network, until they can find a way to escalate their privileges vertically into a root or administrative account. As a penetration tester, you can attempt to exploit different vulnerabilities to conduct your privilege escalations.

This includes attacking the SAM file, bypassing the local Windows User Access Control, or UAC, exploiting weak process permissions, exploiting shared folders, hijacking DLLs, exploiting writeable services and exploiting missing patches or misconfigurations. The SAM file, known as the Security Account Manager, is going to contain the hashed passwords of every user on a given Windows system or domain. If you’re able to dump the contents of the SAM file, you can then crack those passwords for those different accounts offline using a brute-force attack, a dictionary attack, or using a pre-computed table of hashes known as a rainbow table. Remember, though, cracking passwords from the SAM file isn’t exclusive to cloud-based servers, but instead, this works on any Windows-based server or domain controller.

If you’re able to crack a user’s password, then you’re going to be able to use horizontal escalation of those privileges into that user’s account. If you can crack an administrative password, though, you now can do vertical escalation of privileges into that administrative user’s account. Another common privilege escalation exploit is to bypass the local Windows User Account Control, or UAC. As an attacker, you can attempt to use process injection to bypass the local UAC, which will effectively let you run applications as a privileged or administrative user on a Windows workstation or cloud-based service. Weak process permissions are another common vulnerability that can be exploited by an attacker. If you find a process with weak security controls, you can then inject malicious code into those processes and the malicious code is going to be run anytime that process is running. This is commonly used by the Metis Play Framework with its meterpreter payload to escalate privileges into a service or system account. Next, we have shared folders that may be an exploitable vulnerability that contains sensitive information. Many organizations do a really poor job of enabling their access controls on their files and folders on a shared drive.

So it’s always a good idea for an attacker to look at those shared folders and determine if they can access the information that they contain. Another exploit that we use to escalate privileges is the hijacking of Dynamic Link Library, or DLL, files. A DLL is a library file that contains code that can be used or referenced by more than one program. This means that if an attacker can hijack the DLL and insert their home malicious code into it, that code is going to be called or run by other legitimate programs, which can then allow the attacker to gain escalated privileges. This can occur by exploiting weak folder permissions, unquoted service paths, or exploiting applications that run from the organization’s network shares.

Writeable services are another vulnerability that can be exploited to gain escalated privileges. Writeable services and unquoted service paths can be used to inject a malicious application that is going to be launched during startup by a writeable service if the attacker edits the startup parameters for that writeable service. Finally, you can always attack a security vulnerability in a system that exists due to a missing patch or a possible misconfiguration in order to escalate your privileges. Define a vulnerability to exploit, you’re first going to run a vulnerability scan of that system and then find the appropriate exploit code to use to exploit the vulnerabilities that you found in that scan in order to gain root or administrative access to that system.

• Category: Uncategorized