Top 3 AWS Critical Cloud Misconfigurations and How to Remediate

By Nathaniel "Q" Quist, Sr. Threat Researcher, Public Cloud Security

It’s no secret that cloud adoption yields tremendous business benefit — increased agility, reduced cost, flexibility, ease-of-use, the list goes on. The problem is, companies have adopted cloud faster than they’ve been able to adopt security processes and practices to support it.  Developer teams are enthusiastically spinning up cloud workloads and standing up new AWS infrastructure, while security teams may feel they are left to mop up.

Some of the major, headline-grabbing cloud breaches we saw over this past year reflect basic security configuration mistakes: allowing traffic to Port 22 from the public internet, leaving the remote desktop protocol (RDP) exposed. We wouldn’t perform these actions within on-prem infrastructure, so why are we seeing this in cloud? A bird’s eye view of what’s going on would look much like a repeat of what we saw in the 90s: developers excitedly leveraging the newest technologies and acting with little to no thought about the security implications of their latest project.

Novice configuration mistakes transform the cloud into a Wild West for hackers, full of gold mines of opportunity for them. This helps explain the rapid emergence of cybercrime groups, like Rocke, that specialize in targeting the public cloud. The good news is, hackers are looking for easy money, so if you make it difficult for them by using proper configurations, they will look elsewhere.

My team and I have spent the past few years collecting data from hundreds of cloud environments in order to learn about the biggest threats to the public cloud. We found that within the last year, 65% of attacks were due to misconfiguration. Our research has identified the top three critical misconfigurations that are most common in organizations’ AWS environments. For each of these, following a set of simple recommendations will help organizations better secure their clouds and avoid becoming the next easy targets for attackers.

• Security Group Allows Internet Traffic

A security group acts as a virtual firewall that controls the traffic from and to one or more instances. Security groups should have restrictive access control lists (ACLs) to allow only incoming traffic from specific IPs and to specific ports where the application is listening for connections. While the major three cloud service providers (CSPs) block all ingress traffic by default, they allow all egress traffic by default. It is highly recommended that security teams review all security groups on a regular basis to ensure they are properly configured and unwanted changes have not been applied. One of the checks that should be made is to make sure that your current security group policies only allow traffic to and from appropriate addresses, based upon the nature of your organization’s requirements.

Recommendations

If you find a security group allows all ingress traffic, to prevent this inbound action:

1. Log in to the AWS console and navigate to the 'VPC' service.
2. Click on the 'Security Group' link located on the left side of the screen.
3. Click on the 'Inbound Rules' tab and remove any row with a source value containing ‘0.0.0.0/0’ or ‘::/0’.

If your organization, or a particular subnet, does not need to communicate with every country or system worldwide:

1. Log in to the AWS console and navigate to the ‘VPC’ service.
2. Click on the 'Security Group' specific to the alert.
3. Click on 'Outbound Rules' and add a row with the correct protocol (e.g., TCP, UDP, ICMP) and IP address/net range, which should only receive the appropriate network connections.

• AWS Security Groups Allow Internet Traffic to SSH Port (22)

AWS security groups that allow inbound traffic on SSH port (22) from the public internet significantly increase the risk to an organization’s security landscape. Research has found that vulnerabilities contained within out-of-date SSH services are some of the most heavily targeted vulnerabilities for malicious actors. Unit 42 research has shown that 56% of organizations have at least one cloud-based SSH service exposed to the internet. Leaving this port open may allow a bad actor to compromise the SSH service itself, or brute force the service, and potentially gain access to your organization’s cloud environment.

Recommendation 

If the security group needs to restrict SSH traffic:

1. Log in to the AWS Console and navigate to the 'VPC' service.
2. Select the 'Security Group' link and click on the 'Inbound Rule' tab.
3. Remove any rule that has a 'Port Range' value which includes port 22.

• AWS Security Groups Allow Internet Traffic from the Internet to RDP Port 3389

Security groups should not allow RDP port 3389 traffic from or to the public internet. Doing so may allow a bad actor to compromise the RDP application through the use of an exploit, or to brute force the application and potentially gain access to your organization’s cloud environment.

Recommendation

If the Security Groups are found to allow RDP port 3389 traffic:

1. Log in to the AWS Console and navigate to the 'VPC' service.
2. Select the 'Security Group' reported in the alert, and click on the 'Inbound Rule' tab.
3. Remove any rule that has a 'Port Range' containing port 3389.

Removing easy targets

The bottom line: These are three policy violations you should aim to never see in your environment. To ensure success, you will want to automate guardrails so that developers can continue to run freely in the cloud without compromising your organization’s security.

To learn more about our threat intelligence research on the public cloud, read the full Unit 42 Cloud Research Report.