Detecting Vulnerable Elastic IP's Realtime

Detecting Vulnerable Elastic IP's Realtime

ยท

3 min read

What is Elastic IP??

An Elastic IP address is a reserved public IP address that you can assign to any EC2 instance in a particular region until you choose to release it. ... When you associate an Elastic IP address with an EC2 instance, it replaces the default public IP address.

Problem Statement:

While working with Elastic IP, I came to know they can be taken over by anyone if we leave them misconfigured.

What I meant by Elastic IP misconfiguration?

Let's assume you have assigned elastic IP to your EC2 machine. And you also mapped the DNS entry for the same.

DNS entry for the Elastic IP.

{'Name': 'Domain.com.', 'Type': 'A', 'TTL': 300, 'ResourceRecords': [{'Value': 'elastic_ip'}]}

As some of you may know that, AWS has a set of IP addresses for every region that they assign from this

List: ip-ranges.amazonaws.com/ip-ranges.json

In the above list, all the Ip addresses are free to allocate to anyone. So If you allocate elastic IP in your AWS, Aws randomly choose the IP from the above pool and assign it to your AWS account.

Misconfiguration???

Let's suppose after some time you have decided not to use that ec2 machine. You disassociated the elastic IP from that machine. Now if you look at your elastic IP pool that particular IP has no resource attached. And you released it after some time from your pool and your elastic IP is released back into Amazon's pool of public IPv4 addresses. But unfortunately, you forgot to delete the DNS entry that is mapped to the elastic IP.

What's the catch here??

Now you have dangling DNS entry. Which is mapped to the unclaimed elastic IP. So now anyone can claim that Ip and can take over your domain.

Solution:

Detecting misconfigured elastic IP realtime:

My approach to detecting this in real-time is to use Cloudtrail events, Cloudwatch rule and Lambda.

Diagram.jpeg

So I am collecting DisassociateAddress events from cloudtrail and reading if from cloudwatch rule. Cloudwatch rule triggers the lambda.

Lambda parses that event to the function and pulls out the AssociationID of that elastic IP. Then lambda calls the boto3 and fetches the Elastic IP that is associated with the AssociationID. As soon as lambda gets the IP It searches in route 53 records if that IP exists in any DNS entry. If yes then alerts to Slack channel.

Any false positive???

Let's say if you disassociate an Elastic IP and you didn't release it from your pool. You saved it for later use. In this case, elastic IP is not vulnerable to takeover Because it is not available in AWS public IP pool. So no one can take over that.

You will also be receiving alerts for the above condition. But that's good because you will get to know that I have one elastic IP that is not associated with any resources. And someone from your team can cross-check that if anyone released it and do we have a dangling DNS entry for that.

This automation will only work if you are using non-default VPC( I know most of you guys are using non-default VPC ๐Ÿ˜›)

Link to the automation

ย