- “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
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 (CapEx) to operating expenditure (OpEx). 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 Definition 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:
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.
Platform as a service (PaaS): PaaS provides everything except applications. Services provided by this model include all phases of the systems development life cycle (SDLC) and can use application programming interfaces (APIs), website portals, or gateway software. These solutions tend to be proprietary, which can cause problems if the customer moves away from the provider’s platform.
Software as a service (SaaS): SaaS is designed to provide a complete packaged solution. The software is rented out to 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.
Many attacks against cloud technologies are possible, and the following are just some of them:
Credential harvesting
Privilege escalation
Account takeover
Metadata service attacks
Attacks against misconfigured cloud assets
Resource exhaustion and denial-of-service (DoS) attacks
Cloud malware injection attacks
Side-channel attacks
Direct-to-origin attacks
The following sections provide details about each of these attacks against cloud-based services and infrastructures.
Credential Harvesting
Credential harvesting is not a new attack type, but the methodologies used by attackers have evolved throughout the years. Credential harvesting (or password harvesting) is the act of gathering and stealing valid usernames, passwords, tokens, PINs, and any other types of credentials through infrastructure breaches. In Chapter 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 so 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.
Many cloud services and cloud-hosted applications use single sign-on (SSO), and others use federated authentication. Sometimes cloud-based applications allow you to log in with your Google, Apple, or Facebook credentials. Attackers could redirect users to impersonated websites that may look like legitimate Google, Apple, Facebook, or Twitter login pages. From there, the attacker could steal the victim’s username and password. Figure 7-1 shows an example of a common credential harvesting attack in which the attacker sends to the victim a spear phishing email that includes a link to a fake site (in this example, a Twitter login).
)
FIGURE 7-1 Credential Harvesting Attack Using Social Engineering and Spear Phishing Emails
In Chapter 4, you learned about the Social-Engineer Toolkit (SET). In the following examples, you will see how easy it is to perform a social engineering attack and instantiate a fake website (in this case, a fake Twitter login site) to perform a credential harvesting attack:
Step 1. Launch SET by entering the setoolkit command.
Step 2. Select 1) Social-Engineering Attacks from the main menu, as shown in Example 7-1.
Example 7-1 Starting the Social Engineering Attack
Step 3. In the menu that appears (see Example 7-2), select 2) Website Attack Vectors.
Example 7-2 Selecting Website Attack Vectors
Step 4. In the menu and explanation that appear next (see Example 7-3), select 3) Credential Harvester Attack Method.
Example 7-3 Selecting the Credential Harvester Attack Method
Step 5. In the menu that appears next (see Example 7-4), select 1) Web Templates to use a predefined web template (Twitter). As you can see, you also have options to clone an existing website or import a custom website. In this example, you use a predefined web template.
Example 7-4 Selecting a Predefined Web Template
Step 6. In the menu shown in Example 7-5, enter the IP address of the host that you would like to use to harvest the user credentials (in this case, 192.168.88.225). In this example, SET has recognized the attacking system’s IP address. If this occurs for you, you can just press Enter to select the attacking system’s IP address.
Example 7-5 Entering the Credential Harvester’s IP Address
Step 7. Select 3. Twitter, as shown in Example 7-6.
Example 7-6 Selecting the Template for Twitter
You can then redirect users to this fake Twitter site by sending a spear phishing email or taking advantage of web vulnerabilities such as cross-site scripting (XSS) and cross-site request forgery (CSRF). Figure 7-2 shows the fake Twitter login page, where the user enters his credentials.
)
FIGURE 7-2 Fake Login Page
Example 7-7 shows how the attacking system harvests the user credentials. The username entered is santosomar, and the password is superbadpassword. You can also see the session token.
Example 7-7 Harvesting the User Credentials
Attackers have been known to harvest cloud service provider credentials once they get into their victims’ systems. Different threat actors have extended their credential harvesting capabilities to target multiple cloud and non-cloud services in victims’ internal networks and systems after the exploitation of other vulnerabilities.
Privilege Escalation
Privilege escalation is the act of exploiting a bug or design flaw in a software or firmware application to gain access to resources that normally would have been protected from an application or a user. This results in a user gaining additional privileges beyond what the application developer originally intended (for example, a regular user gaining administrative control or a particular user being able to read another user’s email without authorization).
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 to gain access to protected areas of operating systems or to applications (for example, reading another user’s email without authorization). Buffer overflows are used on Windows computers to elevate privileges as well. To bypass digital rights management (DRM) 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. Malware also attempts to exploit privilege escalation vulnerabilities, if any exist on the system. Privilege escalation can also be attempted on network devices. Generally, the fix for this is simply to update the device and to check for updates on a regular basis.
The following are a couple different types of privilege escalation:
Vertical privilege escalation: This type of privilege escalation, also called privilege elevation, occurs when a lower-privileged user accesses functions reserved for higher-privileged users (for example, a standard user accessing functions of an administrator). To protect against this situation, you should update the network device firmware. In the case of an operating system, it should again be updated. The use of some type of access control system —for example, User Account Control (UAC)—is also advisable.
Horizontal privilege escalation: This type of privilege escalation occurs when a normal user accesses functions or content reserved for other normal users (for example, one user reading another’s email). 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 (or log off) 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. Some of the biggest differences are the organization’s ability to detect a cloud account takeover, find out what was impacted, and determine how to remediate and recover.
There are a number of ways to detect account takeover attacks, including the following:
Login location: The location of the user can 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.
Failed login attempts: It is now fairly easy to detect and block failed login attempts from a user or an attacker.
Lateral phishing emails: These are phishing emails that originate from an account that has already been compromised by the attacker.
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.
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 (such as Amazon Web Services [AWS]) 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 (VM)—such as an Amazon Elastic Compute Cloud or AWS EC2 instance—and configure the application during instantiation.
As you can probably already guess, metadata services are some of the most attractive services on AWS for an attacker to access. If you are able to access these resources, at the very least, you will get a set of valid AWS credentials to interface with the API. Software developers often include sensitive information in user startup scripts. These user startup scripts can be accessed through a metadata service and allow AWS EC2 instances (or similar services with other cloud providers) to be launched with certain configurations. Sometimes startup scripts even contain usernames and passwords used to access various services.
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, including the following:
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).
Federation misconfigurations: Federated authentication (or federated identity) 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.
Often application developers misconfigure the implementation of the underlying protocols used in a federated identity environment (such as SAML, OAuth, and OpenID). For instance, a SAML assertion—that is, the XML document the identity provider sends to the service provider that contains the user authorization—should contain a unique ID that is accepted only once by the application. If you do not configure your application this way, an attacker could replay a SAML message to create multiple sessions. Attackers could also change the expiration date on an expired SAML message to make it valid again or change the user ID to a different valid user. In some cases, an application could grant default permissions or higher permissions to an unmapped user. Subsequently, if an attacker changes the user ID to an invalid user, the application could be tricked into giving access to the specific resource.
In addition, your application might use security tokens like the JSON Web Token (JWT) and SAML assertions to associate permissions from one platform to another. An attacker could steal such tokens and leverage misconfigured environments to access sensitive data and resources.
Object storage: Insecure permission configurations for cloud object storage services, such as Amazon’s AWS S3 buckets, are often the cause of data breaches.
Containerization technologies: Attacks against container-based deployments (such as Docker, Rocket, LXC, and containerd) have led to massive data breaches. For instance, you can passively obtain information from Shodan (shodan.io) 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 applications. 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. You could, for example, download the base image for NGINX or Apache HTTPd from Docker Hub, and that Docker image might include a backdoor that the attacker can use to manipulate your applications and underlying systems.
Resource Exhaustion and DoS Attacks
One of the benefits of leveraging cloud services is the distributed and resilient architecture that most leading cloud providers 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), and 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. Figure 7-3 illustrates the key metrics used to identify volumetric DDoS attacks.
)
FIGURE 7-3 DDoS Attack Metrics
However, attackers can launch more strategic DoS attacks against applications hosted in the cloud that could lead to resource exhaustion. For example, they can leverage a single-packet DoS vulnerability in network equipment used in cloud environments, or they can leverage tools to generate crafted packets to cause an application to crash. For instance, you can search in Exploit Database (exploit-db.com) for exploits that can be used to leverage “denial of service” vulnerabilities, where an attacker could just send a few packets and crash an application or the whole operating system. Example 7-8 shows how to search for exploits using the searchsploit tool.
Example 7-8 Using the searchsploit to Search for Exploits
Another example of a DoS attack that can affect cloud environments is the direct-to-origin (D2O) attack. In a D2O attack, threat actors are able to reveal the origin network or IP address behind a content delivery network (CDN) or large proxy placed in front of web services in a cloud provider. A D2O attack could allow attackers to bypass different anti-DDoS mitigations.
Cloud Malware Injection Attacks
Cloud deployments are susceptible to malware injection attacks. In a cloud malware injection attack, the attacker creates a malicious application and injects it into a SaaS, PaaS, or IaaS environment. Once the malware injection is completed, the malware is executed as one of the valid instances 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 (or cloud environment) 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 a 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.
Side-channel attacks can be used against VMs and in cloud computing environments where a compromised system controlled by the attacker and target share the same physical hardware.
Tools and Software Development Kits (SDKs)
In Chapter 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.
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 applications (on premises or in the cloud). SDKs often include compilers, debuggers, and other software frameworks.
CDKs, on the other hand, help software developers and cloud consumers deploy applications in the cloud and use the resources that the cloud provider offers. For example, the AWS Cloud Development Kit (AWS CDK) is an open-source software development framework that cloud consumers and AWS customers use to define cloud application resources using familiar programming languages.