AWS Increases Security Scan Freedom

Thanks to a recent change to the AWS penetration testing policy, AWS customers now have more freedom when performing security scans against their AWS resources. At Auth0 we’re leveraging this policy change to better understand and protect the cloud resources we expose to the world.

Before the policy was updated, AWS customers were required to submit a penetration testing authorization request and wait for approval before being permitted to perform a scan. This policy change allows penetration testing of many AWS services without the need for pre-approval.

What This New Policy Means for Security Teams

Almost every cloud security engineer has had the experience of filling out an AWS penetration testing request and waiting on a response. This manual process greatly reduced the velocity at which you could perform vulnerability scans. For organizations that push code to production often this left security teams playing a constant game of “catch-up”.

Or maybe you’ve been the security engineer tasked with performing an external vulnerability scan of your AWS environment and were left guessing what Internet-facing resources even exist. Cloud providers like AWS make it so easy to put services on the Internet making it even harder to control what ports and protocols you’re exposing to the world.

Daniel Miessler said it well in his recent blog post on this topic, ./getawspublicips.sh: Know the Public AWS IPs You Have Facing the Internet:

"The biggest problem I see however — by a wide margin — is companies not having any idea what ports, protocols, and applications they are presenting to the world." (Daniel Miessler)

Or you could be the security engineer receiving an alert or a vulnerability report with a public IP address that is almost impossible to track down inside your dynamic cloud environment. That IP could be long gone, released from your load balancer, and now associated with something and someone else entirely. The updated penetration testing policy opens the door to solving these problems.

“What greater @awscloud security scan freedom means for security teams. (Hint: reduced workload).”

Tweet This

What We Are Doing at Auth0

The Auth0 Cloud Security team is taking advantage of this policy change to improve the way we track and protect our Internet footprint. In the past, we’ve relied on scheduled external scans of our AWS environment to validate what services, ports, and protocols we were exposing. We typically were left performing these scans monthly or quarterly, simply due to the manual overhead of getting approval and scanning our entire environment within the allotted time window. Since we have over 120 AWS accounts and operate out of several regions, this was a real challenge.

The first step to enabling continuous external vulnerability scans was getting a full view of our public IP footprint. With the dynamic nature of public IP assignment to things like ELBs and CloudFront distributions, this required some engineering work. Fortunately, we already had internal tooling that continuously crawls our AWS environment to capture the public IPs being used. This tool consists of some simple Lambda functions that store public IP data in a DynamoDB table.

To make this data easily consumable we built a small REST API with a few query endpoints. This is a great tool to have at our fingertips when performing network forensics or investigating potential vulnerability findings that refer to public IP addresses. An example DynamoDB record is shown below.

{
 “ipAddress”: “x.x.x.x”,
 “resourceId: “xyz.us-east-1.elb.amazonaws.com”,
 “resourceName”: “load-balancer-01”,
 “resourceType”: “AWS::ElasticLoadBalancingV2::LoadBalancer”,
 “account”: “12345678”,
 “region”: “us-east-1”
 “lastDiscovered”: “2019-03-14T20:00:44.160144”
}

Next, we identified how we could use this public IP data to continuously scan our Internet footprint for unwanted services and vulnerabilities. We added some logic to our public IP discovery Lambda to feed a Simple Queue Service (SQS) queue with each discovered IP. Another Lambda function picks up that SQS message and does a few things:

• It executes a Network Mapper (NMAP) scan against that IP address. We achieved this by crafting a Lambda Layer that contains the NMAP binary and supporting files allowing Lambda itself to execute the NMAP command.
• It then feeds the IP address into other vulnerability scanning tools we use to run longer, more in-depth assessments against services listening at that IP address.

Here is a high-level view of how the solution is put together.

We’ve set this up to run continuously across all the accounts and regions we utilize. Getting this outside-in view of our cloud infrastructure provides many benefits:

• We can continuously detect potential vulnerabilities in our Internet-facing services
• We can be alerted when a new Internet-facing resource is provisioned
• We can detect overly permissive security groups which expose more ports than necessary to the Internet
• We are enabled to better perform forensics knowing our public IP footprint at any point in time

“How Auth0 is leveraging the recent change in @aws penetration policy.”

Tweet This

Moving From Manual to Automated

The latest AWS penetration testing policy update is great news for security teams. At Auth0 we’ve been able to convert a once-manual and time-consuming process into an automated and continuous defensive control. After running our solution for a week we collected over 3,800 public IP addresses used by our AWS resources. We are continuing to enhance our tooling and hope to open source much of what we have built in the near future.