WeirdAAL (AWS Attack Library) Basics from the Authors

The cloud is everything. Organizations have either moved completely to the cloud, have a hybrid approach, or are actively planning a cloud strategy. Penetration testers have always had to provide their services anywhere the client’s environment takes them. This often leads to finding vital information and credentials for their cloud provider of choice. With Amazon Web Services (AWS) being the number one player, finding AWS keys has become very common. But how does one utilize that recon information to further their attacks? Pivoting into these machines or querying the exposed services would make for a much more thorough assessment, but what type of access is available once there? That’s why we created an AWS Attack Library (WeirdAAL).

WeirdAAL has two goals related to the AWS keys you find, procure, or need to test. First, answer the “what can I do with this AWS key pair” from a blackbox perspective. Secondly, be a repository of useful functions, both offensive and defensive, to interact with AWS Services. This article is meant to be a basic tutorial to get you started.

Background on WeirdAAL

With fancy web GUIs, APIs and scripting, cloud providers have made it incredibly easy to spin up new virtual machines. So much so that it has allowed for organizations to massively increase their DevOps capabilities, often without the proper controls in place to manage this new attack surface. Ken Johnson and I have given a few talks [1][2][3] around common DevOps mistakes that can be made. Each of these talks contained sections on how AWS keys can become compromised.

The problem with finding yourself with an AWS key pair is that it can be quite difficult to have a full accounting of what AWS services the key pair has access to without privileges for the client’s Identity and Access Management (IAM) system. During a penetration test (especially black box), you’ll most certainly not have this level of access, therefore answering the “what can I do with this key” question becomes important. WeirdAAL is designed to answer this question.

The Basics of WeirdAAL

Boto3, the AWS SDK for Python, currently supports 136 AWS services. WeirdAAL uses python3 and the boto3 library to ask each service the “do I have permissions to interact with this service” question against functions that take no arguments. Of the 136 services, approximately 125 have at least one of these types of functions.

Getting started is fairly straightforward. Clone the repository, create your python3 virtual environment and install the requirements. Once things are installed, copy the env.sample file to .env and populate it with the AWS key pair you’re testing. The file expects the same format as a normal .aws/credentials file.

Figure 1: sample AWS key in .env file

WeirdAAL overwrites the local AWS_SHARED_CREDENTIALS_FILE environment variable with the contents of the .env file. By using the .aws/credentials file format and boto3, WeirdAAL also natively supports all types of AWS key pairs including key pairs with STS tokens.

After you have set the key, it’s fairly easy to get going. WeirdAAL has two command line requirements: –m for the module you want to run and –t for the target name. Multiple keys can exist under the same target.

$ python3 weirdAAL.py 
usage: weirdAAL.py [-h] -m MODULE -t TARGET [-a ARGUMENTS] [-l] [-v]

weirdAAL.py: error: the following arguments are required: -m/--module, -t/--target

There are currently 28 modules from which to choose, and all are listed in the Wiki section of the GitHub repo. Some modules take arguments, and those can be passed with the –a flag. The first module you’ll want to run is the recon_all module. This module will attempt to interact with those aforementioned AWS services and attempt to enumerate what services the key has access to.

Examples

If the key pair is invalid, WeirdAAL will let you know.

$ python3 weirdAAL.py -m recon_all -t demo
The AWS Access Keys are not valid/active
Check the above error message and fix to use weirdAAL

If the key is a root key, you’ll have access to everything. If you have IAM access, WeirdAAL will also attempt to check the Multi-Factor Authentication (MFA) status on accounts, whether they have IAM console access, and if it looks like those accounts can be reset or not (if you want to get heavy handed).

$ python3 weirdAAL.py -m recon_all -t demo
Account Id: 54889XXXXXXX
Root Key!!! [or IAM access]
Printing Account Summary
{ 'AccessKeysPerUserQuota': 2,
 'AccountAccessKeysPresent': 1,
 'AccountMFAEnabled': 0,
 'AccountSigningCertificatesPresent': 1,
 'AssumeRolePolicySizeQuota': 2048,
 'AttachedPoliciesPerGroupQuota': 10,
 'AttachedPoliciesPerRoleQuota': 10,
 'AttachedPoliciesPerUserQuota': 10,
 'GroupPolicySizeQuota': 5120,
 'Groups': 1,
 'GroupsPerUserQuota': 10,
 'GroupsQuota': 300,
 'InstanceProfiles': 3,
 'InstanceProfilesQuota': 1000,
 'MFADevices': 0,
 'MFADevicesInUse': 0,
 'Policies': 1,
 'PoliciesQuota': 1500,
 'PolicySizeQuota': 6144,
 'PolicyVersionsInUse': 20,
 'PolicyVersionsInUseQuota': 10000,
 'Providers': 0,
 'RolePolicySizeQuota': 10240,
 'Roles': 12,
 'RolesQuota': 1000,
 'ServerCertificates': 0,
 'ServerCertificatesQuota': 20,
 'SigningCertificatesPerUserQuota': 2,
 'UserPolicySizeQuota': 2048,
 'Users': 5,
 'UsersQuota': 5000,
 'VersionsPerPolicyQuota': 5}
Printing Users
[ { 'Arn': 'arn:aws:iam::5488XXXXXXXX:user/bin',
 'CreateDate': datetime.datetime(2018, 5, 27, 19, 43, 53, tzinfo=tzutc()),
 'PasswordLastUsed': datetime.datetime(2018, 5, 27, 19, 44, 48, tzinfo=tzutc()),
 'Path': '/',
 'UserId': 'AIDA-REMOVED',
 'UserName': 'bin'},
 { 'Arn': 'arn:aws:iam::54889XXXXXXX:user/s3',
 'CreateDate': datetime.datetime(2018, 2, 3, 1, 5, 26, tzinfo=tzutc()),
 'PasswordLastUsed': datetime.datetime(2018, 6, 2, 3, 46, 8, tzinfo=tzutc()),
 'Path': '/',
 'UserId': 'AIDA-REMOVED',
 'UserName': 's3'}]
Checking for console access
User bin likely has console access and the password can be reset :-)
Checking for MFA on account
[]
User s3 likely has console access and the password can be reset :-)
Checking for MFA on account
[]
### Enumerating ACM Permissions ###
ListCertificates IS allowed

[+] acm Actions allowed are [+]
['ListCertificates']


### Enumerating AWS Certificate Manager Private Certificate Authority (ACM-PCA) Permissions ###
ListCertificateAuthorities IS allowed

[+] acm-pca Actions allowed are [+]
['ListCertificateAuthorities']

…
SNIP

Generally you’ll find accounts that have access to a handful of services like this one:

$ python3 weirdAAL.py -m recon_all -t demo
Account Id: 1928XXXXXXXXX
AKIAIG7-REMOVED : Is NOT a root key
### Enumerating ACM Permissions ###
An error occurred (AccessDeniedException) when calling the ListCertificates operation: User: arn:aws:iam::1928XXXXXXXXX:user/python is not authorized to perform: acm:ListCertificates

[-] No acm actions allowed [-]


### Enumerating AWS Certificate Manager Private Certificate Authority (ACM-PCA) Permissions ###
An error occurred (AccessDeniedException) when calling the ListCertificateAuthorities operation: User: arn:aws:iam::1928XXXXXXXXX:user/python is not authorized to perform: acm-pca:ListCertificateAuthorities

[-] No acm-pca actions allowed [-]
… SNIP …
### Enumerating Autoscaling Permissions ###
DescribeAccountLimits IS allowed
DescribeAdjustmentTypes IS allowed
DescribeAutoScalingInstances IS allowed
DescribeAutoScalingGroups IS allowed
DescribeLaunchConfigurations IS allowed
DescribeScheduledActions IS allowed
DescribeTags IS allowed
DescribeTerminationPolicyTypes IS allowed
DescribePolicies IS allowed

[+] autoscaling Actions allowed are [+]
['DescribeAccountLimits', 'DescribeAdjustmentTypes', 'DescribeAutoScalingInstances', 'DescribeAutoScalingGroups', 'DescribeLaunchConfigurations', 'DescribeScheduledActions', 'DescribeTags', 'DescribeTerminationPolicyTypes', 'DescribePolicies']

…SNIP…

### Enumerating DynamoDB Permissions ###
ListTables IS allowed
DescribeLimits IS allowed
ListBackups IS allowed
ListGlobalTables IS allowed

[+] dynamodb Actions allowed are [+]
['ListTables', 'DescribeLimits', 'ListBackups', 'ListGlobalTables']


### Enumerating DynamoDBStreamsPermissions ###
ListStreams IS allowed

[+] dynamodbstreams Actions allowed are [+]
['ListStreams']
…SNIP…
### Enumerating Amazon WorkMail Permissions ###
An error occurred (AccessDeniedException) when calling the ListOrganizations operation: User: arn:aws:iam::1928XXXXXXXXX:user/python is not authorized to perform: workmail:ListOrganizations

[-] No workmail actions allowed [-]

Once recon_all is complete, you can list the identified services with the list_services_by_key module.

$ python3 weirdAAL.py -m list_services_by_key -t demo

Services enumerated for AKIAIG7-REMOVED
autoscaling:DescribeAccountLimits
autoscaling:DescribeAdjustmentTypes
autoscaling:DescribeAutoScalingInstances
autoscaling:DescribeAutoScalingGroups
autoscaling:DescribeLaunchConfigurations
autoscaling:DescribeScheduledActions
autoscaling:DescribeTags
autoscaling:DescribeTerminationPolicyTypes
autoscaling:DescribePolicies
cloudwatch:ListMetrics
cloudwatch:DescribeAlarmHistory
cloudwatch:DescribeAlarms
datapipeline:ListPipelines
dynamodb:ListTables
dynamodb:DescribeLimits
dynamodb:ListBackups
dynamodb:ListGlobalTables
dynamodbstreams:ListStreams
ec2:DescribeInstances
ec2:DescribeInstanceStatus
ec2:DescribeImages
ec2:CreateImage
ec2:DescribeVolumes
ec2:CreateVolume
ec2:DescribeSnapshots
ec2:DescribeAccountAttributes
ec2:DescribeAddresses
---SNIP---
elasticbeanstalk:DescribeApplications
elasticbeanstalk:DescribeApplicationVersions
elasticbeanstalk:DescribeEnvironments
elasticbeanstalk:DescribeEvents
elb:DescribeLoadBalancers
elb:DescribeAccountLimits
elbv2:DescribeLoadBalancers
elbv2:DescribeAccountLimits
elbv2:DescribeTargetGroups
emr:ListClusters
emr:ListSecurityConfigurations
iam:ListRoles
lambda:ListFunctions
lambda:GetAccountSettings
lambda:ListEventSourceMappings
lex-models:GetBots
lex-models:GetIntents
opsworks:DescribeStacks
rds:DescribeDBInstances
rds:DescribeDBSecurityGroups
rds:DescribeDBSnapshots
rds:DescribeDBClusters
rds:DescribeDBClusterSnapshots
rds:DescribeAccountAttributes
rds:DescribeEvents
rds:DescribeReservedDBInstances
route53:ListGeoLocations
s3:ListBuckets
sns:ListSubscriptions
sns:ListTopics
sts:GetCallerIdentity

Getting Creative

At this point, you can start to pivot and enumerate more services using the additional WeirdAAL modules. In this case the account has EC2 privileges, DynamoDB, RDS, S3, etc. permissions, and you’d want to start running those additional modules against the various services to see what data or access those services can provide to you. For example we might check out the S3 portion of the wiki to see what functionality exists.

Listing buckets seems like a good place to start:

$ python3 weirdAAL.py -m s3_list_buckets –t demo
 #### Trying to list s3 bucketsfor AKIAIG7-REMOVED ####

1234cloudtrail1234
 bucketwithpolicy1234
 config-bucket-192854696198
 subdomain-takeover-poc

Further peeking into one of the buckets:

$ python3 weirdAAL.py -m s3_list_bucket_contents -a "subdomain-takeover-poc" -t demo

#### Attempting to list s3 bucket contents for subdomain-takeover-poc ####
 index.html
 subdomain-takeover-POC.html
 upload.txt

We might even want to download a file:

$ python3 weirdAAL.py -m s3_download_file -a 'subdomain-takeover-poc','upload.txt' -t demo
 file downloaded to: /Users/CG/Documents/pentest/weirdAAL-updated/loot/upload.txt

lookupfailed-2:weirdAAL-updated CG$ more loot/upload.txt
 hello from the internet

At this point, you might be thinking why is this better than the AWS CLI? Excellent question! Because WeirdAAL uses python and boto3, doing things across multiple regions or multiple instances becomes much easier than piping awscli output to other things.

To back up this claim, I’d suggest you check out the ec2_get_console_output_all and ec2_get_console_output_all_region modules to get an idea of what you can do when you need to run a command against all instances in a region or all instances against all regions.

Example output is below:

Figure 2: Running the get_console_output_all_region module against all instances in a specific region

If you are unsure what modules exist you can check out the WeirdAAL Wiki.

All the modules are documented to include sample command line usage including the potential arguments required. Similar to the following screenshots:

Figure 3: EC2 module documentation

Figure 4: EC2 module documentation showing modules that require arguments

Use It

After consuming the content of this new article, hopefully it was enough to pique your interest. Once again, you can check out WeirdAAL at the GitHub Repository. Issues, comments and suggestions are welcome.

The most recent presentation on WeirdAAL that shows many more examples and awesome Weird Al memes can be found on SlideShare.

We’d also love to hear your feedback on the article and ways in which WeirdAAL has helped you during your own pen tests. Please add your comments below and also consider contributing to the project.

Chris Gates, Sr Security Engineer, has been breaking things professionally for over a decade via Network & Web Application Penetration Testing, Red Teaming & Adversarial Simulation.  These days Chris splits his time being both a breaker and fixer. Chris is the author of Metta, a tool for adversarial simulation and contributes to other open source projects. In the past he has spoken at the United States Military Academy, BlackHat, DefCon, Wild West Hacking Fest, Toorcon, Brucon, Troopers, SOURCE Boston, Derbycon, LasCon, HashDays, HackCon, Bsides ATL, IT Defense, OWASP AppSec DC, and Devops Days. Chris is also a cofounder of NoVAHackers.  Blog: carnal0wnage.attackresearch.com Twitter: @carnal0wnage Talks: https://www.slideshare.net/chrisgates/

All Articles by Chris Gates