Recent Attack Types Against Cloud Infrastructures

Overview of Cloud Security

Cloud security, in short, is the application of the best technology and best practices aimed at objectives such as data and brand protection, preventing disruption of services, and protecting the infrastructure within the cloud service. Cloud security can be configured to meet the needs of businesses, from authentication for systems to traffic filtering and Web Application Firewall.

Cloud security also encompasses processes and tools that strengthen the security of cloud systems, detect harmful events, and include business continuity and data backup plan in case of a security breach.

With the development of cloud systems, traditional security solutions have been replaced by a modern security approach that is more contemporary, easy to manage, does not contain system difficulties, and does not require maintenance activities.

How Secure Are CSPs’ Default Security Measures?

Innovative solutions for cloud environments in many areas of cybersecurity go faster than traditional cybersecurity solutions and help create more robust architectures.

Human errors and improperly designed systems constitute the basis of security problems. One of the most common security vulnerabilities is that misconfigured cloud services become available on the Internet. Even if an application or service is protected, there is always a risk when it is opened to the Internet. Although some protocols and services are designed for users to access through the Internet, some (SMB, database services, etc.) may not need to be opened to the Internet.

Default security measures are insufficient in cloud environments, and various security measures must be used in related systems specific to user accounts.

Shared Responsibility

Cloud service providers (CSPs) use the shared responsibility model. The shared responsibility model determines what CSPs and cloud users are responsible for. This model may vary depending on the CSP and the cloud services used, so it is necessary to define what cloud users and CSPs are responsible for.

Cloud service providers offer default and simple security measures. For example, they cannot force any user to use a public key instead of a password for SSH authentication on a newly created server, nor can they force other strict security measures. They can only come up with recommendations.

Initial Access

Phishing attacks, RDP and SSH protocols with weak passwords, publicly accessible buckets, storage, database, etc. services, outdated web applications, leak credentials, and hardcoded passwords in repository management are the most common methods used by attackers to gain initial access.

Thousands of employees share cloud infrastructure and work together. If an attacker takes over an employee’s computer or a system, they can access other cloud services using over-authorized configurations and user accounts and gain administrator-level authority.

According to the Checkpoint 2022 Cloud Security Report, the factors that cause incidents are as follows:

• Wrongly configured resource or account – 23%
• Data or files inappropriately shared by a user – 15%

• Account compromise – 15%
• Vulnerability exploits – 14%

1. Misconfigurations

>

Public Access to Storage Services

Cloud services are designed to be easy to use. One of the negative consequences is insufficiently structured data storage. Sharing services such as AWS S3, Azure Blob, etc., are made publicly available, and sensitive data is accessible to everyone.

Data storage services are available on Azure, other cloud platforms, and AWS. AWS S3 is one of the most popular cloud services. With this service, you can easily store data for mobile applications, websites, backups, archives, IoT applications, and any other services. However, without a security measure, these S3 buckets can be accessed by typing the correct URL address, as a regular user would do via a browser to access any website. 

To prevent this, AWS makes public access disabled while creating the bucket and shows some warnings. However, this setting could not prevent the buckets in which sensitive data is stored from being opened to the internet environment and data from leaking.

The MITRE-based Threat Matrix for Azure Storages shared by Microsoft reveals the approaches of threat actors.

Public Bucket Detection

You can use SOCRadar External Attack Surface, GrayHat Warfare, S3Scanner, and MicroBurst to detect public buckets.

Case Studies

Socialarks

The personal information of more than 200 million Facebook, LinkedIn, and Instagram users was exposed when Chinese social media management company Socialarks exposed its misconfigured, passwordless ElasticSearch database to the internet.

Artwork Archive

The disclosure of personal data and information such as purchase details, contracts, and owned artworks affects approximately 7 thousand customers due to the misconfigured, passwordless, open S3 bucket of Artwork Archive, an online art platform.

US Municipalities

Information about more than 100 US cities and people living in them was exposed in S3 buckets that were misconfigured, passwordless, and accessible from the internet. The documents that emerged included various sensitive personal data, such as the following.

• Business licenses
• Land registry, residential records
• Tax information
• Resumes for government jobs applicants
• Building and city plan information

2. Accidental Exposure of Credentials, Data Breaches

An attacker targeting a company can communicate with the employees over social media and obtain their passwords through methods such as phishing. An attacker can easily gain initial access if employees use the same passwords on their personal and work accounts. However, with accounts that are leaked, sold, or shared in underground forums, attackers can access the system like a regular user by bypassing security products without performing any exploitation for initial access.

An attacker who recently obtained the Gmail address of a Cisco employee also obtained the password for the employee’s VPN account, as the passwords saved in the victim’s browser were synchronized. It also managed to bypass multiple authentications using various voice call phishing methods. Ultimately, he had the victim validate login verification and gain access to Cisco’s internal network, capturing sensitive information.

We can give examples of hardcoded, forgotten API, access and secret keys, and user accounts on platforms such as GitHub that developers use actively. One credential information forgotten on GitHub may endanger the entire company’s system and data.

3. Insider Threat

An employee who does not like the company or whose sole motivation is money can sell system access or user information to threat actors, causing a security vulnerability that is difficult to detect. It may be more challenging to notice this in environments with low-security settings and accessed from the Internet environment such as the cloud.

It is necessary to keep track of your company’s user accounts or sensitive data (API, secret keys) in dark web environments.

If there is a leaked, shared account regarding your e-mail address or your domain, you can check it with SOCRadar Account Breach.

4. Attacks on User Accounts

The more services we use, the more passwords are used. Using different or solid passwords for each system may not be possible. Passwords seized and used in more than one system are one of the security vulnerabilities that do not lose their importance today. For systems that do not use MFA, the danger is much greater.

Passwords can be obtained in multiple ways, some of which are as follows:

• Phishing: Capturing passwords with phishing attacks by simulating screens where users can enter their passwords, such as Outlook or a corporate VPN.
• Malware: Retrieving passwords saved in the browser by infecting the user’s computer with malware.

• 3rd party systems: Hacking a website to which the user is a member, leaking the database, and seizing passwords by threat actors.
• Brute force attacks: Guessing passwords based on the user’s hobbies, favorite things, or reusing leaked passwords.

5. API Security

Misconfigured APIs are at the forefront of data leaks and security incidents. APIs should be checked for misconfiguration, incomplete or unsafe coding standards, and insufficient authorization. One of the most common vulnerabilities is leaking sensitive data through APIs that are opened without proper authorization.

• Shadow APIs: Controllers can overlook unused or hidden APIs in applications, causing them to remain insecure.

• API Parameters: API parameters used to grant authorization could allow attackers to change their profile to “administrator.” Threat actors can escalate their privileges to seize sensitive data and access other malicious purposes.
• Sensitive Data Exposure: Returning sensitive data in API requests or error messages to the user in the response can be a reconnaissance stage for an attack by threat actors.

6. Vulnerabilities

Suppose a web application that should not be opened to the Internet is accidentally opened and has a Server Side Request Forgery (SSRF) vulnerability. The SSRF vulnerability is a vulnerability that allows an attacker to create requests from the vulnerable server to the internal network or wherever. In the Capital One case in 2019, the attackers first used the SSRF vulnerability to access AWS EC2 metadata to obtain Access and Secret Keys. Afterward, they misused the authorized credentials he had obtained, accessed the AWS S3 (Simple Storage Service) service, and captured sensitive information there.

Cloud service providers provide metadata about their services through the address 169.254.169.254 (dynamically configured link-local addresses). This feature allows us to quickly obtain some information without using AWS APIs. The relevant metadata service may contain various information such as security group, user, access key, and secret key.

SSRF security vulnerability is one of the major vulnerabilities affecting public cloud servers.

Let’s assume that we have an application with SSRF vulnerability over 18.188.6.254. Although it may seem like a basic HTML page without any input fields at first, the SSRF vulnerability in the ssrfhills?url= parameter allows attackers to connect from the server to other company services, access sensitive data, and make requests to systems they want outside the company. The MS Exchange SSRF vulnerability, released in 2021, is one of the vulnerabilities that attackers actively exploit.

When we test the ssrfhillsparameter by sending a request to Google, we can see that Google is opened and verify the SSRF vulnerability’s existence.

Attackers use the metadata API to access and collect EC2 information through the metadata service.

The attacker first learns the relevant instance name by sending a request to hxxp://169.254.169.254/latest/meta-data/identity-credentials

After accessing the instance name, they can obtain the AccessKeyID and SecretAccessKey information by sending a request to hxxp://169.254.169.254/latest/meta-data/identity-credentials/ec2-instance and access other services by connecting to AWS via the AWS CLI using the information they get from there.

How can attackers who obtain Access/Secret Key information or access the internal network by phishing method escalate their privilege?

AWS Identity and Access Management (IAM) allows you to securely control access to AWS resources. IAM provides the necessary infrastructure to manage authentication and authorization according to the principle of least privilege, which can determine who can access resources and services and under what conditions. Initially, users are created without any permissions, and permissions are defined according to needs. You can also regularly check the permissions you have given to resources and services with IAM.

While it sounds great in theory, it takes much time and effort to practice. For example, developers may not be able to take the time to individually extract the accesses of all API calls in the application they have developed, or they may create IAM policies with very broad authorizations to resolve an error and make the application operational as soon as possible. While these policies resolve bugs or access issues, they leave a system open to the internet vulnerable to attackers who begin scanning very soon after booting.

“What can IAM service cause in the hands of threat actors?” To answer this question, we used the CloudGoat tool of Rhino Security Labs, which contains AWS vulnerabilities.

If a user has the iam:SetDefaultPolicyVersion privilege, they can change the current policy to another version of this policy. Let’s think about it, we first created the v1 version of the policy in the system and defined additional authorizations until the authorizations that users should have were determined. As time went on, we started to take unnecessary privileges and created v2, v3, and v4 versions of the policy. But if a user has the iam:SetDefaultPolicyVersion privilege, they can change it to v1 and have more comprehensive privileges, even if the v5 version of the policy has been applied.

Sorting policies and permissions is a critical step when evaluating the security of an IAM user (users, user groups, or roles).

The attacker can list the policies attached to Raynor, an AWS IAM user, on the system they compromised:

After checking the current policy version, they may want to check other policies used and investigate whether excess access or authorization has been granted.

The attacker checks the versions of the current policy and sees that policies from v1 to v5 are available.

When the attacker checks the v1 version of the current policy, they see that has the iam:SetDefaultPolicyVersion privilege.

When looking at policies v1 through v5, the attacker notices the v3 policy, which allows access to all AWS resources, where they can act with administrator privileges on the AWS account.

The attacker will have administrator rights by choosing the v3 policy instead of the currently used v1 to access all resources and increase authority.

First of all, the current policy version is displayed with the following command.

•  aws iam get-policy –policy-arn arn:aws:iam::221658042718:policy/cg-raynor-policy-iam_privesc_by_rollback_cgidld7s4mi11r –profile raynor

 The current policy is changed to v3 using the command below.

• aws iam set-default-policy-version –policy-arn arn:aws:iam::221658042718:policy/cg-raynor-policy-iam_privesc_by_rollback_cgidld7s4mi11r –version-id v3 –profile raynor

When we recheck the current policy, we see that the v3 policy, allowing administrator rights successfully, is activated.

We need to explore and examine in detail the features that will allow abuse in cloud platforms such as AWS, which are developing day by day, and new features are added and have a broad attack surface. After changing the policy version, we used the enumerate-iam script to determine the attacker’s permissions. With this script, you can see your permissions by API requests to the services.

We can see that we successfully have administrator privileges by using the enumerate-iam script to verify our privileges and permissions.

This is one of the situations that can be experienced with the iam:SetDefaultPolicyVersion authorization. You can also see other permissions that can be abused in the table below.

MITRE has created a matrix to map specific tactics, techniques, and procedures (TTPs) that threat actors can use in their attacks against cloud environments.

Most Exploited Vulnerabilities in Cloud Environment

As we explained above, the vulnerabilities used by attackers against cloud infrastructures are not different from top vulnerabilities; only post-exploitation activities differ.

Since CVSS for vulnerabilities is insufficient for organizations today, you can use SVRS (SOCRadar Vulnerability Risk Score) to prioritize personalized vulnerabilities/threats.

You can also review the open-source project Cloudvulndb to examine all known cloud vulnerabilities and security issues with CSPs.

Critical Vulnerability List for Cloud Environment (Last 1 Year):

• https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• CVE-2021-3156
• CVE-2021-44228
• CVE-2022-22963
• CVE-2022-29149
• CVE-2021-38647
• CVE-2021-41773
• CVE-2021-42013

Conclusion

According to the Checkpoint 2022 Cloud Security Report, the reasons behind attacks on cloud environments are:

• Lack of visibility into infrastructure security – 35%
• Can’t identify misconfigurations quickly – 33%
• Implementing continuous and automated security controls in the cloud – 31%

One hundred percent security is nearly impossible, but due diligence is essential to reduce security risks and increase visibility. Security in the cloud is a shared responsibility between the CSP and users, even though cloud customers are often unaware of their security responsibilities. As the adoption and use of cloud systems increase, threat actors will come across more different attacks.

You Can’t Protect What You Can’t See

Nobody wants system administrators and software developers to create unauthorized (Shadow IT) and/or incorrectly configured systems with security vulnerabilities and attackers to detect them first. In this context, “External Attack Surface Management for Cloud Security” is essential for a robust security posture. EASM, DRPS (Digital Risk Protection), and CTI (Cyber Threat Intelligence) together become much more powerful and minimize potential risks in modern Cloud Architectures.

You can get a general insight into this topic by examining the Cloud Security for EASM model by SOCRadar security researchers.

You can only make controls/tests on known assets. You should use EASM (External Attack Surface Management) products to monitor your assets constantly and receive an early warning.

Recommendations for Cloud Security:

• Reducing the use of long-term credentials.
• Making MFA mandatory for APIs with critical importance and privileges.
• Defining the necessary authorizations and permissions for each user aligns with their work definition.
• Blob versioning. You can enable Blob storage versioning to maintain previous versions of an object automatically. When blob versioning is enabled, you can access earlier versions of a blob to recover your data if it is modified or deleted.
• Activating deletion protection for the database.
• Using the lock feature for Resources.
• Regularly backing up critical information and systems, testing these backups, and checking their accuracy.
• Implementation of the zero-trust model.

You can create your EASM report here for free.

References:

1. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html
2. https://blog.talosintelligence.com/2022/08/recent-cyber-attack.html
3. https://aws.amazon.com/tr/compliance/shared-responsibility-model/?nc1=h_ls
4. https://docs.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility
5. https://www.tenable.com/blog/cve-2021-26855-cve-2021-26857-cve-2021-26858-cve-2021-27065-four-microsoft-exchange-server-zero-day-vulnerabilities
6. https://owasp.org/www-community/attacks/Server_Side_Request_Forgery
7. https://portswigger.net/web-security/ssrf
8. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_DeleteInstance.html
9. https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/lock-resources?tabs=json