What occurs whenever you leak AWS credentials and the way AWS minimizes the injury
I heard a number of occasions that AWS scans public GitHub repositories for AWS credentials and informs its customers of the leaked credentials.
So I’m curious to see this for myself, so I made a decision to deliberately leak AWS credentials to a Public GitHub repository. And present you the steps I took and the way I bought knowledgeable in regards to the leaked credentials.
I created a IAM consumer in my AWS account named test-user and generated an entry key and secret for this consumer and connected a really restricted coverage to this consumer.
{
"Model": "2012-10-17",
"Assertion": [
{
"Sid": "ListBucket",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::aws-leaked-credentials"
}
]
}
I then pushed the AWS entry key and secret to GitHub see the commit right here: Commit: 33b4d387e94e16b1c8b9277056299bdb02de3a4b.
In a short time after pushing the credentials to GitHub varied issues occurred which I’ll present under.
Timestamps and occasions after leaking the credentials to GitHub
Right here you’ll find all of the occasions that occurred after pushing to GitHub.
12:33:12 – Pushed the credentials to GitHub
12:34:19 – The AWSCompromisedKeyQuarantineV2 coverage is connected to the IAM consumer test-user by AWS
12:34:32 – Varied Listing and Describe calls are made utilizing the leaked credentials
12:35:08 – Acquired an e mail from AWS with the topic ‘ACTION REQUIRED: Your AWS Entry Secret’s Uncovered for AWS Account 12345678’
As you possibly can see 1 minute and seven seconds after leaking the credentials AWS added the AWSCompromisedKeyQuarantineV2 coverage. As a result of AWS IAM is finally constant the malicious actor was in a position to carry out varied API calls even after the AWSCompromisedKeyQuarantineV2 coverage has been added. Fortunately this was short-lived as a result of IAM has little delay for adjustments to take impact. 2 minutes after leaking the credentials I acquired an e mail from AWS informing me of the occasion and offering directions on safe the account.
Beneath you’ll find detailed details about each occasion.
Coverage connected by AWS
The AWSCompromisedKeyQuarantineV2 is connected to the IAM consumer test-user. This coverage denies crucial actions. But when the leaked credentials have lots of permissions the malicious actor might nonetheless do injury to techniques operating within the AWS account.
See the coverage under:
{
"Model": "2012-10-17",
"Assertion": [
{
"Effect": "Deny",
"Action": [
"cloudtrail:LookupEvents",
"ec2:RequestSpotInstances",
"ec2:RunInstances",
"ec2:StartInstances",
"iam:AddUserToGroup",
"iam:AttachGroupPolicy",
"iam:AttachRolePolicy",
"iam:AttachUserPolicy",
"iam:ChangePassword",
"iam:CreateAccessKey",
"iam:CreateInstanceProfile",
"iam:CreateLoginProfile",
"iam:CreatePolicyVersion",
"iam:CreateRole",
"iam:CreateUser",
"iam:DetachUserPolicy",
"iam:PassRole",
"iam:PutGroupPolicy",
"iam:PutRolePolicy",
"iam:PutUserPermissionsBoundary",
"iam:PutUserPolicy",
"iam:SetDefaultPolicyVersion",
"iam:UpdateAccessKey",
"iam:UpdateAccountPasswordPolicy",
"iam:UpdateAssumeRolePolicy",
"iam:UpdateLoginProfile",
"iam:UpdateUser",
"lambda:AddLayerVersionPermission",
"lambda:AddPermission",
"lambda:CreateFunction",
"lambda:GetPolicy",
"lambda:ListTags",
"lambda:PutProvisionedConcurrencyConfig",
"lambda:TagResource",
"lambda:UntagResource",
"lambda:UpdateFunctionCode",
"lightsail:Create*",
"lightsail:Delete*",
"lightsail:DownloadDefaultKeyPair",
"lightsail:GetInstanceAccessDetails",
"lightsail:Start*",
"lightsail:Update*",
"organizations:CreateAccount",
"organizations:CreateOrganization",
"organizations:InviteAccountToOrganization",
"s3:DeleteBucket",
"s3:DeleteObject",
"s3:DeleteObjectVersion",
"s3:PutLifecycleConfiguration",
"s3:PutBucketAcl",
"s3:PutBucketOwnershipControls",
"s3:DeleteBucketPolicy",
"s3:ObjectOwnerOverrideToBucketOwner",
"s3:PutAccountPublicAccessBlock",
"s3:PutBucketPolicy",
"s3:ListAllMyBuckets",
"ec2:PurchaseReservedInstancesOffering",
"ec2:AcceptReservedInstancesExchangeQuote",
"ec2:CreateReservedInstancesListing",
"savingsplans:CreateSavingsPlan"
],
"Useful resource": [
"*"
]
}
]
}
CloudTrail occasion
Within the us-east-1 CloudTrail logs you possibly can see {that a} AttachUserPolicy API name is made to connect the AWSCompromisedKeyQuarantineV2 coverage. Within the occasion file it clearly states that this has been invoked by AWS "invokedBy": "AWS Inner".
CloudTrail occasion:
{
"eventVersion": "1.08",
"userIdentity": {
"sort": "IAMUser",
"principalId": "AIDAxxxxxxxxx",
"arn": "arn:aws:iam::xxxxxxxxx:consumer/test-user",
"accountId": "xxxxxxxxx",
"accessKeyId": "ASIAxxxxxxxxx",
"userName": "test-user",
"sessionContext": {
"sessionIssuer": {},
"webIdFederationData": {},
"attributes": {
"creationDate": "2023-03-21T11:34:19Z",
"mfaAuthenticated": "false"
}
},
"invokedBy": "AWS Inner"
},
"eventTime": "2023-03-21T11:34:19Z",
"eventSource": "iam.amazonaws.com",
"eventName": "AttachUserPolicy",
"awsRegion": "us-east-1",
"sourceIPAddress": "AWS Inner",
"userAgent": "AWS Inner",
"requestParameters": {
"userName": "test-user",
"policyArn": "arn:aws:iam::aws:coverage/AWSCompromisedKeyQuarantineV2"
},
"responseElements": null,
"requestID": "7b163d6c-xxxxxxxxx",
"eventID": "c3eda312-xxxxxxxxx",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "xxxxxxxxx",
"eventCategory": "Administration"
}
Malicious actor?
I discovered it shocking how rapidly the malicious actor made some automated API calls with the leaked credentials. Which means that they scan GitHub public repositories continually for leaked credentials.
The consumer agent used was aws-sdk-go-v2/1.17.1 so that they in all probability have an automatic software that detects leaked credentials and begin scanning the AWS account for sources. Within the picture under you see the assorted API calls they made, fortunately with none luck as a result of they didn’t have the permissions for these API calls.
Beneath you’ll find the CloudTrail log of the ListCertificates API name:
{
"eventVersion": "1.08",
"userIdentity": {
"sort": "IAMUser",
"principalId": "AIDAxxxxxxxxx",
"arn": "arn:aws:iam::xxxxxxxxx:consumer/test-user",
"accountId": "xxxxxxxxx",
"accessKeyId": "AKIAYUBS5O3BYC7WBJWO",
"userName": "test-user"
},
"eventTime": "2023-03-21T11:34:36Z",
"eventSource": "acm.amazonaws.com",
"eventName": "ListCertificates",
"awsRegion": "eu-west-1",
"sourceIPAddress": "3.xxx.xx.xxx",
"userAgent": "aws-sdk-go-v2/1.17.1 os/linux lang/go/1.18.10 md/GOOS/linux md/GOARCH/amd64 api/acm/1.15.2",
"errorCode": "AccessDenied",
"errorMessage": "Person: arn:aws:iam::xxxxxxxxx:consumer/test-user just isn't licensed to carry out: acm:ListCertificates as a result of no identity-based coverage permits the acm:ListCertificates motion",
"requestParameters": null,
"responseElements": null,
"requestID": "b83e5733-xxxxxxxxx",
"eventID": "37d59144-xxxxxxxxx",
"readOnly": true,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "xxxxxxxxx",
"eventCategory": "Administration",
"tlsDetails": {
"tlsVersion": "TLSv1.3",
"cipherSuite": "TLS_AES_128_GCM_SHA256",
"clientProvidedHostHeader": "acm.eu-west-1.amazonaws.com"
}
}
E mail from AWS
Inside two minutes of leaking the credentials I acquired an e mail from AWS informing me that the credentials have been leaked. See the primary a part of the e-mail under:
Hi there,
We have now change into conscious that the AWS Entry Key AKIAYUBS5O3BYC7WBJWO , belonging to IAM Person test-user , together with the corresponding Secret Secret’s publicly obtainable on-line at https://github.com/tiborhercz/aws-leaked-credentials/blob/33b4d387e94e16b1c8b9277056299bdb02de3a4b/credentials.txt.
Your safety is necessary to us and this publicity of your account’s IAM credentials poses a safety threat to your AWS account, might result in extreme expenses from unauthorized exercise, and violates the AWS Buyer Settlement or different settlement with us governing your use of our Companies.
To guard your account from extreme expenses and unauthorized exercise, we have now utilized the “AWSCompromisedKeyQuarantineV2” AWS Managed Coverage (“Quarantine Coverage”) to the IAM Person listed above. The Quarantine Coverage utilized to the Person protects your account by denying entry to excessive threat actions like iam:CreateAccessKey and ec2:RunInstances. You’ll be able to view all of the actions denied by the coverage by going right here: https://console.aws.amazon.com/iam/dwelling#insurance policies/arn:aws:iam::aws:coverage/AWSCompromisedKeyQuarantineV2$jsonEditor?part=permissions.
Within the e mail in addition they give steering on safe the account. They do that in 4 steps: 1. Rotate and delete the uncovered AWS Entry Key AKIAYUBS5O3BYC7WBJWO 2. Test your CloudTrail log for unsanctioned exercise 3. Evaluate your AWS account for any unauthorized AWS utilization 4. You will need to reply to the prevailing Help Case or create a brand new one to verify completion of the steps above with the intention to restore entry to your account, stop suspension, and apply for a billing adjustment, if relevant.
How does AWS reply this quick when credentials are leaked is one thing I’m not 100% positive about, as a result of I don’t have affirmation from AWS itself.
How they might obtain that is by utilizing GitHub ‘Secrets Scanning’ service and utilizing the ‘Secret scanning alerts for companions’. GitHub will then report leaked secrets and techniques to those companions, when receiving this report AWS has some automated system that provides the AWSCompromisedKeyQuarantineV2 coverage, sends the e-mail and opens a assist ticket.
When leaking AWS credentials to GitHub, AWS has safeguards in place to guard you. AWS and the malicious actors act impressively quick on the leaked credentials each taking motion instantly. AWS informs the foundation consumer and provides a Deny coverage to the IAM consumer. The malicious actor begins to scan the account for sources they will exploit.
It is rather good that AWS protects its customers on this approach, however we might higher stop the leaking of the credentials. There are numerous methods of stopping leaking the credentials.