Menu
In the final (?) part of our investigation into dangling DNS records and the risk that they present to organisations, we’ll review ‘elastic’ IP addresses as supported by the various cloud providers including AWS, Azure and Google Cloud. For the most part (because we’re most familiar with it) we will be using AWS as our reference cloud platform.
Elastic IPs (in AWS terminology; they’re called static public IPs in Azure and GCP nomenclature) are ‘floating’ IP addresses which can be assigned to a compute node or (possibly) a load balancer or NAT gateway. Elastic IPs are typically bound to a particular geographic region, but not ‘availability zone’, so a single IP address can be assigned to instances in any of the availability zones defined in your Virtual Private Cloud (VPC).
Why would you want to assign a specific public IP address to a compute node instead of using load balancers or random platform-assigned host names ? Some possible reasons are that you:
Whatever the reason, elastic IP addresses are commonly used by organisations in their cloud portfolio. Of course, client applications and human users rarely address endpoints using (hard-coded) public IP addresses, so it is common for the organisation to set up A records in their organisation’s DNS records, mapping a human-readable hostname to that elastic IP address.
Just as was described in Part 1, organisational risks arise when the resources being pointed to by these records are later decommissioned, but the records themselves are not. Just like hand-me-down clothes, unused elastic IP addresses can be recovered and handed out to other users of the cloud platform at a later date. Attackers who obtain an elastic IP address in this way and can discover the host name that maps to their new IP address can use that address to mount fairly realistic phishing (or other) attacks.
Note that these Elastic IPs can appear in different types of DNS records such as A or MX records. If an organisation loses control of an elastic IP address appearing in one of their A records, then an attacker can use that IP address not only to host a malicious web application at that IP address, but also to conduct realistic phishing attacks using the organisation’s own domain!
Recall that RFC 5321 specifies that, if a domain associated with an email address does not have an MX record, then Mail Transfer Agents (such as Exchange or O365) should use the A record for that domain as a fallback. This is historical behaviour which pre-dates the existence of MX records and which continues to this day for compatibility reasons.
Let’s look at an example: Say a record for sub.example.com.au points to an elastic IP that an attacker controls; the attacker can then send email to potential victims using the “From” address of [email protected]. If the victim replies, the attacker will receive that response at the elastic IP address they control (assuming there is no MX record for sub.example.com.au which is a reasonable assumption).
Why go to the bother of performing Business Email Compromise scams by hacking O365 mailboxes and performing man-in-the-middle attacks with malicious INBOX filter rules when you can just send an email from a legitimate subdomain and get the reply sent straight to your inbox!
Very! We have built a tool that will continually allocate and release Elastic IP address in AWS, and that will also look up newly allocated Elastic IP address in the Project Sonar data to see if there are one or more A records pointing to that IP. If there are no A records pointing to that elastic IP address, the address is released back into the pool.
The tool is designed to operate within some limits:
Even within these limits, our tool allows us to consistently get several elastic IPs in the ap-southeast-2 region per hour. “That’s not many!”, you may say, but run the tool over a couple of weeks and you’ll have your hands full of abandoned A records! Of course, you have no control over which A records are pointing to your elastic IP, but for most attackers, that probably doesn’t matter: If a business is pointing its DNS records to a cloud provider (IAAS) IP address, it’s likely to be a big (read: lucrative) enough to make it worth the attackers time.
Of course, it would be great to show you some example sites that can be built in order to take advantage of the corresponding abandoned records but we can’t…
…since doing so would leave the discovered records open to misuse. We have found that even after we inform domain owners that they are at risk, the records are tend to be left dangling indefinitely, so providing any further details would just contribute to an already long-term problem.
To begin with, it may seem we are picking on AWS here, but rest assured that the same risk lies in static (recycled) IP addresses offered by other cloud providers. Some providers offer a BYO service for IP addresses which should eliminate this particular risk.
Whatever the provider, the root cause of this issue is the fact that DNS records for cloud provider-provided IP addresses are not cleaned up after resources are decommissioned. Such a clean-up process should be part of your Change Management document (you do those, right?) which describe the decommissioning process for unused cloud resources.
For an organisation’s existing DNS records, the easiest way to check if you are affected by this issue is to iterate through the records in your DNS zones (using whatever API your DNS provider offers) and search for any AWS (https://ip-ranges.amazonaws.com/ip-ranges.json) or Azure (https://www.microsoft.com/en-au/download/details.aspx?id=56519) IP addresses therein. Once you have your target list, you will then need to manually confirm that the record points to an existing resource managed by your organisation. If it doesn’t, you should delete the record to mitigate this kind of risk.
Until next time, feel free to drop us a line!
PS: And of course, if you missed the first installations in this series, you might like to give Part One and Part Two a browse!