Hello All,
Welcome to this post
In this post, we will discuss the Server-Side Request Forgery (SSRF) vulnerability in the context of AWS Cloud. The primary goal of this post is to demonstrate how AWS Config can be used to automatically detect and remediate this issue.
SSRF Vulnerability is a server-side vulnerability that enables an attacker to exploit a vulnerable server to make requests to internal or third-party servers in order to access data. In the context of AWS Cloud, the attacker's main objective is to obtain the temporary credentials assigned to an EC2 instance by attempting to access the metadata URL.
For demonstration purposes, I hosted vulnerable code on an EC2 instance and attempted to retrieve the credentials. You can see how I successfully obtained the temporary credentials.
We were able to retrieve these temporary credentials because the image was Ubuntu, and it was using IMDSv1. To address this issue, we need to upgrade to IMDSv2.
Why IMDSv2 is Important?
IMDSv2 uses PUT requests and requires an authentication token in the header, as well as utilizing OPTIONS requests, which disrupts the SSRF chain flow.
As far as I know, there are lots of images that supported IMDSv1 by default, some images uses IDMSv2 by default. So we need a process to detect the weak configuration and automatically remediate it. Addressing this issue manually is gonna time consuming.
AWS Config
AWS Config is a managed service provided by AWS that detects non-compliance configurations. Based on these non-compliance configurations, remediations can be applied. One of the notable aspects of AWS is its granularity, allowing you to achieve the same task in multiple, cost-effective ways.
In this post, we will acheive the same task by using 2 methods.
1) AWS Config Auto-remediation
2) AWS Config with Event Bridge and Lambda
AWS Config Auto-Remediation
AWS Config not only helps to detect the misconfiguration but also provide us a feature to remediate the issue automatically. This method is straightforward. You select a rule and specify its remediation. In this case, we need to upgrade to IMDSv2 to remediate the use of IMDSv1 in instances. We choose the remediation 'AWSConfigRemediation-EnforceEC2InstanceIMDSv2'.
List of AWS Config rules supported.
We need two primary things -
1) Create roles that allow config to acccess EC2 instance.
2) Assign that role to the rule when you configuring.
That's all that's required. Now, whenever you create an instance with IMDSv1 enabled, this rule will detect it, mark it as non-compliant, and automatically run remediation to upgrade it to IMDSv2.
I created an EC2 instance with the default IMDSv1 support, as shown in the figure.
Once the instance is created, the Config rule will detect the configuration as non-compliant and run the auto-remediation automatically. The status tab will show 'Action Executed Successfully' after the auto-remediation. If there is any technical error in running the auto-remediation, it will mark it as red alert.
Upon refreshing, you will see the version updated automatically, as shown in the figure below.
AWS Config, Event Bridge, Lambda
In this approach, I removed auto-remediation from the rule and created an event in Event Bridge. I also created a Lambda function that lists all the instances and upgrades IMDSv1 to IMDSv2.
Created a Event Bridge Rule, that will trigger on event based on Non-Compliant issues detected by AWS Config. There is a bug in this screenshot, I am not defining any rule name, so basically it will trigger on the basis of any rule marked as non-compliant. But we can define any specific rule name, so it will trigger this event only when the specific rule marked as non-compliant.
Created Lambda that will list all the instances and will modify the IMDS version. Note this is working function but it could be improved in more ways but for now let it be.
import boto3
def lambda_handler(event, context):
ec2_client = boto3.client('ec2')
instances = ec2_client.describe_instances(
Filters=[
{
'Name': 'instance-state-name',
'Values': ['running']
}
]
)
for reservation in instances['Reservations']:
for instance in reservation['Instances']:
instance_id = instance['InstanceId']
ec2_client.modify_instance_metadata_options(
InstanceId=instance_id,
HttpTokens='required'
)
print("IMDSv2 activation initiated for instance ", instance_id)
return "IMDSv2 activation completed for all running instances."
As you can see, this code lists all the instances and updates the IMDS configuration by setting HttpTokens to 'required'.
It's crucial to create the required permissions and roles for this setup. We need to assign roles to lambda, config and setup a trigger to lambda.
With these steps in place, we can launch an EC2 instance that supports IMDSv1. After some time, the property will be updated to 'required,' effectively mitigating the weak configuration.
AWS Config supports lots of issues, this was just a tip of the ice berg thing.
A Question for you
How do you calculate the cost of the flow on AWS? Lets take the above example, I performed the same thing with two methods but I could not able to find out which is the cost effective, so how do you calculate?.
Please let me know on comment or you can DM me on linkedin. Would be great to know that.
Thanks for reading it, if you found any technical error please let me know.
Hope you have a great time.
Cheers.