New tools protect your AWS infrastructure

Properly testing your virtual infrastructure has been an issue almost since there were virtual machines (VMs) and Amazon’s Web Services (AWS). Lately, the tool sets have gotten better.

Part of the problem is that to adequately test your AWS installation, you need to know a lot about how it is constructed. You have to draw on typical vulnerabilities and attack methods, as well as understand the relationships among your various VMs and network components. That is a lot of knowledge, and if your developers are busy building stuff, they don’t want to devote much time to explaining how all the components are put together.  

Another part of the problem is that most penetration tests focus on on-premise applications, where the environments are more carefully defined and stable. An AWS configuration is more ephemeral, where CPUs can come and go, and storage blocks are created and destroyed in the blink of an eye. And “no one wants to test new attack techniques against their own professional environment,” as this post from Rhino Security starts out.

Last year, Skyhigh Networks found that 7 percent of all AWS S3 buckets were exposed to the overall Internet. Worse, a third of these public buckets were unencrypted, making it almost child’s play to review the data contained in them. 

Many of these are configuration errors that go undiscovered for months until an analyst or reporter tries to contact the firm involved, such as this summer’s leak of users of Honda’s Connect in-car control systems that came from a third party in India, or a huge list of voting records from an unsecured S3 bucket at Deep Root Analytics.

Fixing this flaw is the genesis behind several new tools from AWS itself and from others. Let’s look at the AWS tools first.

Zelkova and Tiros add to the AWS tool suite

Amazon has had a series of security-related services for many years, including:

• CloudTrail, which logs all API usage
• CloudWatch, which monitors resource usage
• Macie, which discovers sensitive data using machine learning techniques
• GuardDuty, which performs threat detection
• Config, which tracks changes to your configuration
• Trusted Advisor, which analyzes your environment and makes recommendations on best practices

AWS also provides ways to segregate groups of users and machines and to set up virtual private networks and virtual firewalls. If some of these services aren’t familiar to you, you might want to read the online documentation and to try them out with your AWS installation.

These tools certainly help you protect against many things inside AWS. What is missing, though, is a more holistic view of your entire operation.

That started to change last year when AWS added a series of S3 security checks, as Jeff Barr detailed. These include how you set up encryption by default, what happens when you move storage across Amazon regions, and showing the encryption status of each object in a simple dashboard.  These features made it easier to review the access status of your buckets, as shown with the “public” or “not public” icons in this screenshot below:

That’s still not enough, and that takes us to the most recent additions to the AWS pantheon: Zelkova and Tiros from Amazon’s Automated Reasoning Group. The two new tools can evaluate your access controls and map paths from the open Internet to your S3 storage buckets, as well as offering automated feedback on your various machine configurations.

They complement each other: Tiros handles access issues, such as configuration of virtual private clouds (VPCs) and access control lists, and also maps the network connections among your resources.  Zelkova looks at authorization issues such as roles, policies and resources. It also creates benchmarks so that developers can see how permissive their configurations are. The goal is to spot common mistakes before someone turns their environment into a live production release.

Think of both tools as very fast auditors that can compare two sets of AWS policies and find circumstances that aren’t secure or that fit a particular threat model. For example, which S3 instances allow for SSH access? That could be an issue and a developer should block that access.

Both were internal tools that Amazon has been working with beta testers to make them more user-friendly and available for public consumption. Indeed, Zelkova was the basis of the algorithms used in that screenshot above to make the public/not-public determination, along with other AWS services such as GuardDuty. That algorithmic process is explained in this blog post. The implications of how these are both set up can make the difference between your data being private and it being the subject of the next security data leak story.

Rhino CloudGoat and Pacu test for AWS vulnerabilities

Two tools from Rhino that are also worth looking at, called CloudGoat and Pacu. The former takes its name from the OWASP WebGoat that was created several years ago as a mechanism for testing web applications. CloudGoat is now freely available on GitHub. 

CloudGoat uses Python scripts to launch resources into a live AWS account that tests across more than a dozen different AWS services, including S3 buckets, an EC2 instance, a CodeBuild project, and CloudTrail and GuardDuty instances. The tool then tries to attack your setup with this collection of services and with a variety of pre-specified users. That could be a lot to get your arms around, so you probably want to make a copy of your production environment (which you should be doing anyway).

CloudGoat consumes AWS resources, which means you will pay a little for running its attack scenarios. Rhino estimates this will come out to a couple of dollars a day.

Pacu is another Rhino project, and the two work hand-in hand. It is also open-source and specifies an attack framework for AWS. CloudGoat was actually built in Pacu.

The idea is that you use these tools to deploy and terminate a variety of vulnerable AWS resources, so you can learn more about the inherent security risks in that environment so that you don’t make similar mistakes. It will explore such issues as privilege escalation, data exfiltration and persistent access across your infrastructure.

The goal of using any combination of these tools is to create a state of awareness of vulnerabilities in your AWS system. You don’t want to be the last person to know your company’s sensitive data is ungated and exposed on the web. These tools can help with early detection of potential problems or help prevent them from happening.