We're excited to tell you about Nuclei Templates release v9.8.5! This new version includes newly added AWS cloud review templates. In this blog post, we'll discuss automating cloud misconfiguration review, creating custom AWS checks, and sharing results on the PDCP Cloud for review.
The AWS Cloud Security Configuration Review, also referred to as AWS Cloud Config Review or AWS Cloud Audit in pentesting circles, is a vital procedure for assessing the security posture of Amazon Web Services (AWS). It involves a meticulous examination of AWS configurations to verify that they are optimally configured to safeguard data and services. This comprehensive analysis encompasses various facets of AWS infrastructure, including storage, databases, and applications, to ensure compliance with established security protocols. By identifying potential vulnerabilities and areas for enhancement, this review aids in fortifying defenses, thereby mitigating the risk of unauthorized access and data breaches.
If you're only interested in using the AWS cloud review templates, skip to the end of the blog
Some common key activities involved in an AWS Cloud Security Configuration Review:
We believe that the AWS cloud configuration review is unnecessarily complex, often presenting more challenges than it should in practice. Hence, we've opted to simplify the process by crafting security checks for AWS cloud using the straightforward YAML format employed by Nuclei. These templates are designed to execute all essential checks, encompassing configurations, logging, compliance, and best practices. By leveraging these templates, we can effortlessly generate a comprehensive report on our cloud platform, complete with remediation measures. This streamlined approach facilitates smoother reviews for companies and penetration testers alike.
Before we get started with the scanning, let's talk a little bit about the AWS code review nuclei-templates. We have used code protocols to write AWS cloud configuration review templates.
Nuclei empowers users to execute external code on the host operating system, granting security researchers, pentesters, and developers the flexibility to expand its capabilities beyond standard protocol-based testing. This functionality enables interaction with the underlying OS, facilitating the execution of custom scripts or commands for a diverse array of tasks including system configurations, file operations, and network interactions. Such control and adaptability empower users to customize their security testing workflows to meet precise needs. Explore the Code protocol templates in our documentation for more details.
Because code templates can execute commands on hosts, users must first sign the template using their keys, and these are not included in default scans. To use these templates, you need to sign them using the-sign
flag. After signing, you can run the templates by providing the-code
flag.
In the example below, you'll notice that we can easily run an aws-cli
command directly into the template. However, unlike other templates that execute on target hosts, this one will run the command on our own host.
id: aws-config-review
info:
name: AWS Cloud Config Review Example
author: princechaddha
severity: info
description: |
Checks if AWS CLI is set up on the environment.
reference:
- https://aws.amazon.com/cli/
tags: cloud,devops,aws,amazone,aws-cloud-config
self-contained: true
code:
- engine:
- sh
- bash
source: |
aws sts get-caller-identity --output json
matchers:
- type: word
words:
- '"UserId"'
extractors:
- type: json
name: account
internal: true
json:
- '.Account'
In this example, we will create a template that detects publicly exposed S3 buckets, a common cause of big data breaches.
self-contained: true
because, unlike typical Nuclei templates that require a host to target, code templates run independently of any host.source
section.flow
, which is a recently added feature that controls the execution flow of the template. Initially, we added code(1)
, meaning the first code block will execute. This block includes an extractor that extracts the names of all available S3 buckets and stores them in the buckets
array. Following that, a for
loop iterates through all the buckets and executes the second code block, replacing the bucket variable in the second command.aws s3api get-bucket-acl --bucket $bucket --query 'Grants[?(Grantee.URI==http://acs.amazonaws.com/groups/global/AllUsers)]'
, replacing the bucket name using $bucket
variable extracted using first command.matcher
, we check if the bucket has READ permission.id: s3-public-read
info:
name: S3 Bucket with Public READ Access
author: princechaddha
severity: critical
description: |
Verifies that Amazon S3 buckets do not permit public 'READ' (LIST) access to anonymous users, protecting against unauthorized data exposure
reference:
- https://docs.aws.amazon.com/cli/latest/reference/s3api/get-bucket-acl.html
tags: cloud,devops,aws,amazon,s3,aws-cloud-config
flow: |
code(1)
for(let bucketName of iterate(template.buckets)){
set("bucket", bucketName)
code(2)
}
self-contained: true
code:
- engine:
- sh
- bash
source: |
aws s3api list-buckets --query 'Buckets[*].Name'
extractors:
- type: json # type of the extractor
internal: true
name: buckets
json:
- '.[]'
- engine:
- sh
- bash
source: |
aws s3api get-bucket-acl --bucket $bucket --query 'Grants[?(Grantee.URI==`http://acs.amazonaws.com/groups/global/AllUsers`)]'
matchers:
- type: word
words:
- '"Permission": "READ"'
extractors:
- type: dsl
dsl:
- '"The S3 bucket " + bucket +" have public READ access"'
Similarly, in the following template we are checks for public RDS snapshots.
id: rds-public-snapshot
info:
name: RDS Public Snapshot Exposure
author: princechaddha
severity: high
description: |
Checks if AWS RDS database snapshots are publicly accessible, risking exposure of sensitive data.
impact: |
Public snapshots can expose sensitive data to unauthorized users, leading to potential data breaches.
remediation: |
Modify the snapshot's visibility settings to ensure it is not public, only shared with specific AWS accounts.
reference:
- https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ShareSnapshot.html
tags: cloud,devops,aws,amazon,rds,aws-cloud-config
variables:
region: "ap-northeast-1"
flow: |
code(1)
for(let RDPsnaps of iterate(template.snapshots)){
set("snapshot", RDPsnaps)
code(2)
}
self-contained: true
code:
- engine:
- sh
- bash
source: |
aws rds describe-db-snapshots --region $region --snapshot-type manual --output json --query 'DBSnapshots[*].DBSnapshotIdentifier'
extractors:
- type: json
name: snapshots
internal: true
json:
- '.[]'
- engine:
- sh
- bash
source: |
aws rds describe-db-snapshot-attributes --region $region --db-snapshot-identifier $snapshot --query 'DBSnapshotAttributesResult.DBSnapshotAttributes'
matchers:
- type: word
words:
- '"all"'
extractors:
- type: dsl
dsl:
- '"RDS snapshot " + snapshot + " is public"'
Similar to the above template, users can create their own custom AWS cloud checks for their environment.
Here are a few more use cases for AWS Nuclei templates:
To use cloud configuration review templates, first we need to set up the environment. This setup is similar to using the aws-cli, where you either add aws_access_key_id
and aws_secret_access_key
to the ~/.aws/credentials
file or export them as environment variables.
In Nuclei-Templates, we've introduced the concept of profiles, which allow users to run a specific set of templates tailored for a particular use case. For running AWS templates, we have a profile named aws-cloud-config
.
Once the environment is properly configured, users can execute the following template to ensure everything is set up correctly before running the profile.
nuclei -id aws-code-env -code
If the template matches, this indicates that the environment has all the necessary tools installed and the CLI is set up. Users can then run the following command to execute all the AWS cloud config templates.
Currently, the region is hardcoded to us-east-1
in the templates for region-specific services. Users have the option to pass a different region variable via the CLI when running a template or update the region directly in the profile file itself.
Now, we'll run a scan using our AWS config scan profile. Before we start, it's very useful for pentesters or companies to save the scan results for reporting or remediation purposes. To facilitate this, you can use the -cloud-upload
flag to upload the results to PDCP.
To upload results to the cloud, you need to obtain an authentication token. Here are the steps to follow:
nuclei -auth <your-api-key>
.Now you're all set to run the templates!
nuclei -config ~/nuclei-templates/profiles/aws-cloud-config.yml -cloud-upload
Now that we have numerous results, it would be very convenient to view these on the Cloud. Simply log into PDCP Cloud, and you will find a scan created with the results.
We have added over 95+ templates for services like ACM, CloudTrail, EC2, RDS, VPC, CloudWatch, IAM, and S3, and we invite the community to share their feedback. We expect this number to grow as the security community continues to contribute and collaborate.
The Nuclei templates for AWS provide users with significant creativity and flexibility, enabling them to craft checks that cater to their particular workflow and environment. This approach can not only assist in identifying and resolving security misconfigurations but also facilitate the monitoring of their overall AWS environment, such as optimizing costs, achieving compliance, or enhancing performance.
You can also join our Discord server. It's a great place to connect with fellow contributors and stay updated with the latest developments. Thank you, once again!
By leveraging Nuclei and actively engaging with the open-source community, or by becoming a part of the ProjectDiscovery Cloud Platform, companies can enhance their security measures, proactively address emerging threats, and establish a more secure digital landscape. Security represents a shared endeavor, and by collaborating, we can consistently adapt and confront the ever-evolving challenges posed by cyber threats.