Amazon GuardDuty recently added the detection of EC2 instance credentials being used by other AWS accounts. This improves upon the previous state where only credentials being used by IP addresses outside of the AWS network were reported on. This new detection is available within all regions.
Amazon GuardDuty is a threat detection service that continuously monitors for malicious or unauthorized behavior within AWS accounts and workloads. The service can be centrally managed across multiple AWS accounts and requires no additional software or hardware to be installed.
The new threat detection responds to EC2 instance credentials being used from another AWS account. EC2 instance credentials are temporary credentials that are made available from the EC2 instance metadata service (IMDS). These can then be provided to applications running on the EC2 instance to authorize activities permitted by the attached AWS IAM role.
If the credentials are used from an affiliated account, as in an account monitored by the same GuardDuty admin account, then the alert is labeled as medium severity. All other detections are labeled as high severity.
These credentials could be compromised if, for example, an application running on the EC2 instance has an open exploit. A malicious actor could leverage that application to access the IMDS and extract the credentials. Those credentials have permissions as granted by the attached IAM role, meaning the actor now can act as if they are the application on the EC2 instance.
There are a number of possible ways that the credentials can become compromised, including leveraging a remote code execution (RCE) vulnerability. Application-level vulnerabilities can also be exploited such as server side request forgery (SSRF) or XML external entity (XXE) injection.
Mark Ryland, director, Office of the CISO at AWS, recommends a number of best practices to mitigate these potential vectors. First off, if the IMDS isn't needed then it can and should be disabled. If it is in use, Ryland recommends limiting local access to the service via local firewall rules. For EC2 instances that are accessible broadly, he recommends limiting open ports and using an access broker model to communicate with the IMDS.
Ryland notes that leveraging IMDSv2 will prevent most known misconfiguration and SSRF vulnerabilities. Version 2 moves the model from being a stateless request and response approach to a session-oriented model. The application creates a session token using a PUT request and all subsequent requests must include this token. The token is only usable by that EC2 instance.
Version 1 of the service can be disabled and there is a CloudWatch metric, Amazon EC2:MetadataNoToken, to track usages of IMDSv1. There are also condition keys that can be used within IAM and Organizations Service Control Policies (SCPs) to prevent usage of IMDSv1. For example, the following condition could be used to deny RunInstances requests made using version 1 of the metadata service:
"StringEquals": {"ec2:MetadataHttpTokens": "required"}
This would require that RunInstances be called as followed:
https://ec2.amazonaws.com/?Action=RunInstances
&ImageId=ami-1a2b3c4d
&Count=1
&InstanceType=c3.large
&KeyName=MyKeyPair
&SecurityGroups=MySecurityGroup
&MetadataOptions.HttpTokens=required
&AUTHPARAMS
The new threat detection is available now within all regions at no additional cost; it is enabled automatically when GuardDuty is enabled. More details on Amazon GuardDuty can be found on the AWS site with pricing information available on the pricing page.
