Cyber Strategy
Cyber Secure
Cyber Operations
Cyber Response
Cyber ResilienceAWS Security Assessment
What is a AWS?
Amazon Web Services (AWS) is a cloud service from Amazon, which provides services in the form of building blocks, these building blocks can be used to create and deploy any type of application in the cloud. These services or building blocks are designed to work with each other, and result in applications which are sophisticated and highly scalable.
Each type of service in AWS, is categorized under a domain, the few domains which are widely used are:
- Compute
- Storage
- Database
- Migration
- Network and Content Delivery
- Management Tools
- Security & Identity Compliance
- Messaging
AWS Security Assessment
What is a AWS?
Amazon Web Services (AWS) is a cloud service from Amazon, which provides services in the form of building blocks, these building blocks can be used to create and deploy any type of application in the cloud. These services or building blocks are designed to work with each other, and result in applications which are sophisticated and highly scalable.
Each type of service in AWS, is categorized under a domain, the few domains which are widely used are:
- Compute
- Storage
- Database
- Migration
- Network and Content Delivery
- Management Tools
- Security & Identity Compliance
- Messaging
Why AWS Security Assessment is different than VAPT Engagement?
The methodologies used to pentest traditional security infrastructure and the AWS Cloud differ in a multitude of ways. Most of these differences refer back to the ownership of the systems. Since Amazon owns the core infrastructure, the methodology used in traditional VAPT would violate the AWS acceptable use policies and potentially invoke incident response procedures by the AWS security team.
Amazon Cloud Penetration Testing Rules
Amazon Cloud Penetration Testing Rules
- AWS EC2 instance excluding tactics related to disruption of business continuity such as launching Denial of Service (DOS) attacks
- The implementation and configuration of Vendor Operated Services,
- AWS services such as Cloudfront and the API Gateway configuration may be pentested but the hosting infrastructure is off limits.
- Areas of the AWS Elastic Cloud Computing (EC2) service including:
- The Application Programming Interface (API) (e.g. HTTP/HTTPS)
- Various Web and mobile applications that hosted by your organization
- The application server and associated stack (e.g. programming languages such Python, React)
- Virtual machines and operating systems
Top 5 Vulnerabilities to Test for in AWS
While there are a number of common AWS-specific vulnerabilities we often see, some are more regular than others. Below are the top 5 vulnerabilities we see when testing against this architecture:
- Testing S3 bucket configuration and permissions flaws
- Targeting and compromising AWS IAM keys
- Cloudfront/WAF Misconfiguration Bypasses
- Establishing private-cloud access through Lambda backdoor functions
- Cover tracks by obfuscating CloudTrail logs
Why AWS Security Assessment is different than VAPT Engagement?
The methodologies used to pentest traditional security infrastructure and the AWS Cloud differ in a multitude of ways. Most of these differences refer back to the ownership of the systems. Since Amazon owns the core infrastructure, the methodology used in traditional VAPT would violate the AWS acceptable use policies and potentially invoke incident response procedures by the AWS security team.
Amazon Cloud Penetration Testing Rules
AWS permits security testing for User-Operated Services, which includes cloud offerings created and configured by the user. Here are a few examples:
- AWS EC2 instance excluding tactics related to disruption of business continuity such as launching Denial of Service (DOS) attacks
- The implementation and configuration of Vendor Operated Services,
- AWS services such as Cloudfront and the API Gateway configuration may be pentested but the hosting infrastructure is off limits.
- Areas of the AWS Elastic Cloud Computing (EC2) service including:
- The Application Programming Interface (API) (e.g. HTTP/HTTPS)
- Various Web and mobile applications that hosted by your organization
- The application server and associated stack (e.g. programming languages such Python, React)
- Virtual machines and operating systems
Top 5 Vulnerabilities to Test for in AWS
While there are a number of common AWS-specific vulnerabilities we often see, some are more regular than others. Below are the top 5 vulnerabilities we see when testing against this architecture:
- Testing S3 bucket configuration and permissions flaws
- Targeting and compromising AWS IAM keys
- Cloudfront/WAF Misconfiguration Bypasses
- Establishing private-cloud access through Lambda backdoor functions
- Cover tracks by obfuscating CloudTrail logs
WHAT STEPS SHOULD I TAKE BEFORE THE PENTEST?
Performing a pentest within the cloud requires adequate planning and expert knowledge. General steps and preparation that should be taken before the pentest begins include:
- Defining the scope, including the AWS environment and target systems
- Run your own preliminary
- Determine the type of pentest you would like conducted (e.g. black box, white box, gray box)
- Outline expectations for both internal stakeholders and the pentesting company
- Establishing a timeline for the technical assessment to occur, receive formal reports, and potential remediation and follow-up testing
- Developing the protocol and rules of engagement if the pentest reveals the client may already have been breached or is under an ongoing (live) attack
- Obtaining written approval to conduct the test by the client (and other third parties that may be involved)
DevSecOps Pipelines Considerations in AWS
Amazon clouds support multiple services which can be used in a DevOps environment like:
- Cloud9 SDK which is a cloud-based IDE where you can write, run and debug your code from a browser.
- AWS CodeCommit is a fully-managed source control service that hosts secure Git-based repositories. It makes it easy for teams to collaborate on code in a secure and highly scalable ecosystem.
- AWS CodeBuild is a service where developers can compile their source code , perform integration from multiple SCMs and create build artifacts.
- AWS S3 buckets are used for storing the final build artifacts and binaries.
- AWS CodeDeploy is a service that pulls the binary artifacts from S3 buckets and deploys them in pre-provisioned AWS environments like EC2, ElasticBeanstalk and ECS.
- Finally, we have the AWS CodePipeline which orchestrates the various builds and deploy stages defined in CodeBuild and CodeDeploy giving you a fully managed continuous delivery service.
Hence AWS provides a lot of security tools in native cloud format, however, those tools generally focus more on monitoring and reporting, thus, requiring us to deploy and use and our own tools to address other areas.
Integrating security in an AWS environment will take similar steps as required in an On-prem environment like integrating a code analyzer tool in SAST (static application security testing) or a dependency checker in the SCA (software composition analysis) however The configuration of various tools in AWS environment for execution will be different.
In an on-prem model tools can be downloaded at will and executed in a script or a docker container. However in cloud, as billing is generally on usage, download incurs extra charges and hence the strategy with using these tools in AWS would be to create a tools repository using an S3 bucket and referencing this S3 bucket in each build configuration file. Each stage will have its own build configuration file wherein the tools would be fetched from the internal S3 bucket and executed.
These tools will be needed to be updated regularly for which we can employ a Lambda function which would periodically check for new versions. If the tool is compatible with the AWS Lambda specifications, then converting the tool as a Lambda service would be an exceptionally great task and for vulnerability management. Refer to “Tools” section for suitable tools.
DevSecOps Pipelines Considerations in AWS
Amazon clouds support multiple services which can be used in a DevOps environment like:
- Cloud9 SDK which is a cloud-based IDE where you can write, run and debug your code from a browser.
- AWS CodeCommit is a fully-managed source control service that hosts secure Git-based repositories. It makes it easy for teams to collaborate on code in a secure and highly scalable ecosystem.
- AWS CodeBuild is a service where developers can compile their source code , perform integration from multiple SCMs and create build artifacts.
- AWS S3 buckets are used for storing the final build artifacts and binaries.
- AWS CodeDeploy is a service that pulls the binary artifacts from S3 buckets and deploys them in pre-provisioned AWS environments like EC2, ElasticBeanstalk and ECS.
- Finally, we have the AWS CodePipeline which orchestrates the various builds and deploy stages defined in CodeBuild and CodeDeploy giving you a fully managed continuous delivery service.
Hence AWS provides a lot of security tools in native cloud format, however, those tools generally focus more on monitoring and reporting, thus, requiring us to deploy and use and our own tools to address other areas.
Integrating security in an AWS environment will take similar steps as required in an On-prem environment like integrating a code analyzer tool in SAST (static application security testing) or a dependency checker in the SCA (software composition analysis) however The configuration of various tools in AWS environment for execution will be different.
In an on-prem model tools can be downloaded at will and executed in a script or a docker container. However in cloud, as billing is generally on usage, download incurs extra charges and hence the strategy with using these tools in AWS would be to create a tools repository using an S3 bucket and referencing this S3 bucket in each build configuration file. Each stage will have its own build configuration file wherein the tools would be fetched from the internal S3 bucket and executed.
These tools will be needed to be updated regularly for which we can employ a Lambda function which would periodically check for new versions. If the tool is compatible with the AWS Lambda specifications, then converting the tool as a Lambda service would be an exceptionally great task and for vulnerability management. Refer to “Tools” section for suitable tools.
Threat Landscape in AWS DevOps Environment
Here are the issues describing the complete AWS threat landscape
Access Control Security Misconfiguration
In AWS, access control is managed through the IAM Policies. A policy is an object in AWS that, when associated with an identity or resources, define their permissions. If an EC2 object needs to access an S3 bucket, specific permissions are needed. An oversight or granting of excessive privileges can lead to various scenarios where S3 buckets have public access leading to a possible leakage of sensitive information.
Network Security Misconfiguration
The diagram on the right shows a typical flow of network traffic and the different places where it can be tapped. Security Groups are like host-based firewalls for individual EC2 instances. Network Access Control Lists (NACL) can be configured for a group of EC2 instances. Route Tables are configured for routing traffic amongst different networks and finally we have VPC’s which are the final overarching network segmentation module connected to an Internet Gateway.
It is very much possible to have misconfiguration in such complex infrastructure.
Below section focuses on various tools offered by AWS as well as some other open source tools that can be utilized.
| Tool | Category | Description |
|---|---|---|
| AWS CloudWatch | Logging and Monitoring |
|
| AWS CloudTrail | Logging and Auditing |
|
| AWS Config | Compliance and Configuration Management |
|
| AWS Inspector | Security and Compliance |
|
| Prowler | Security Hardening |
|
| Security Monkey | Configuration Management |
|
| ScoutSuite | Security and Compliance |
|
| AWS Secrets Manager | Secrets Management |
|
| AWS WAF | Firewall |
|
AWS IAM Keys Leakage
AWS if an EC2 instance needs to access an S3 bucket, proper IAM roles needs to be configured. IAM roles are permissions between AWS services which are different than user permissions. Hence if a service needs programmatic access to AWS resources then it needs a set of AWS access keys which can be obtained from a metadata URL.
There are two ways in which these keys can be leaked/exposed
- If an application deployed on an EC2 instance is having an RCE or an SSRF vulnerability then an attacker can request the URL, obtain the AWS Access Keys and gain access to all available AWS resources.
- Accidentally committing source code containing the AWS Keys, exposed in publicly accessible folders etc.
AWS IAM keys leakage can be prevented by employing pre-commit hooks like Talisman which detect for such information before developers can commit changes into a repo.
Exploiting Billing Caps
If your AWS keys are compromised the very first thing that attackers would do is setup EC2 instances and start BITCOIN mining.
The key point to understand here is that it is not just storage costs, but also “Per Request” costs that need to be considered.
One of the best practices while using AWS is to create billing alerts for your AWS accounts so as to protect yourself from being overcharged.
Tools to help you secure your AWS clouds environment
Keep in mind the following tools are not the industry de facto and are subject to constant change.
- Archery, Open source vulnerability assessment and management tool which can be utilized in a DevOps CI/CD environment
- AWS Recipes by NCCGroup, helpful CloudFront and IAM templates and policies to lock down your environment
AWS Security benchmark by AWSLabs, contains benchmark governance rules
Threat Landscape in AWS DevOps Environment
Here are the issues describing the complete AWS threat landscape
Access Control Security Misconfiguration
In AWS, access control is managed through the IAM Policies. A policy is an object in AWS that, when associated with an identity or resources, define their permissions. If an EC2 object needs to access an S3 bucket, specific permissions are needed. An oversight or granting of excessive privileges can lead to various scenarios where S3 buckets have public access leading to a possible leakage of sensitive information.
Network Security Misconfiguration
The diagram on the right shows a typical flow of network traffic and the different places where it can be tapped. Security Groups are like host-based firewalls for individual EC2 instances. Network Access Control Lists (NACL) can be configured for a group of EC2 instances. Route Tables are configured for routing traffic amongst different networks and finally we have VPC’s which are the final overarching network segmentation module connected to an Internet Gateway.
It is very much possible to have misconfiguration in such complex infrastructure.
Below section focuses on various tools offered by AWS as well as some other open source tools that can be utilized.
| Tool | Category | Description |
|---|---|---|
| AWS CloudWatch | Logging and Monitoring |
|
| AWS CloudTrail | Logging and Auditing |
|
| AWS Config | Compliance and Configuration Management |
|
| AWS Inspector | Security and Compliance |
|
| Prowler | Security Hardening |
|
| Security Monkey | Configuration Management |
|
| ScoutSuite | Security and Compliance |
|
| AWS Secrets Manager | Secrets Management |
|
| AWS WAF | Firewall |
|
AWS IAM Keys Leakage
AWS if an EC2 instance needs to access an S3 bucket, proper IAM roles needs to be configured. IAM roles are permissions between AWS services which are different than user permissions. Hence if a service needs programmatic access to AWS resources then it needs a set of AWS access keys which can be obtained from a metadata URL.
There are two ways in which these keys can be leaked/exposed
- If an application deployed on an EC2 instance is having an RCE or an SSRF vulnerability then an attacker can request the URL, obtain the AWS Access Keys and gain access to all available AWS resources.
- Accidentally committing source code containing the AWS Keys, exposed in publicly accessible folders etc.
AWS IAM keys leakage can be prevented by employing pre-commit hooks like Talisman which detect for such information before developers can commit changes into a repo.
Exploiting Billing Caps
If your AWS keys are compromised the very first thing that attackers would do is setup EC2 instances and start BITCOIN mining.
The key point to understand here is that it is not just storage costs, but also “Per Request” costs that need to be considered.
One of the best practices while using AWS is to create billing alerts for your AWS accounts so as to protect yourself from being overcharged.
Tools to help you secure your AWS clouds environment
Keep in mind the following tools are not the industry de facto and are subject to constant change.
- Archery, Open source vulnerability assessment and management tool which can be utilized in a DevOps CI/CD environment
-
AWS Recipes by NCCGroup, helpful CloudFront and IAM templates and policies to lock down your environment
AWS Security benchmark by AWSLabs, contains benchmark governance rules
See also:
Dubai