CloudFront Domain Hijacks under Attack
Update: To my attention in April, it appears that Mindpoint may have been behind the automated assigning of the hijackable instances. See https://www.mindpointgroup.com/blog/pen-test/cloudfront-hijacking/ This is great, but CloudFront’s engineers definitely missed a whole lot, so I’m not sure if they actually see the problem. Given that they have access to an internal DB of all instances they can easily run queries for it. They wouldn’t need to scan for hijackable states externally like an attacker would, so why would they miss some?…
TLDR; As of 27th March 2018, I found that an entity or malicious actor has exploited the following vulnerability that allows for subdomain hijacking at a large global scale. This post is here to inform the public so that they may ensure that they are not leaving their domains open to control by this third party. I am not sure on the exact date that the hijack started.
Note: I am not putting you at further risk that you already are by putting it on GitHub to help you identify it. The attackers / third party have already taken control over an instance that can control your domain name. If you want your domain removed, get in contact with me.
What is the attack or issue?
CloudFront domain hijacking has always been under the radar of bug bounty hunters. CloudFront does not require domain validation whatsoever when specifying a CNAME, this means that anyone can say that they own the domain pointed to by the CNAME record.
An attacker can discover abandoned CloudFront instances by fingerprinting the response from the CloudFront server when attempting to visit a domain but the resource is not available. This tends to indicate that the domain is hijackable and that the attacker can create a new CloudFront instance, and assign a CNAME of that domain to be able to serve content under that domain name.
For example, you use CloudFront and you set up the following record:
After a certain amount of time, you no longer want to use CloudFront here, so you delete the CloudFront instance. Either that, or your “Cloud” management team have decided to go and remove any unnecessary CloudFront instances to save resources and money. After doing this, your “Cloud” management team had not informed your DNS management team to delete the CNAME records. This means that the attacker can register a new instance on CloudFront with a CNAME of cdn.contoso.com and serve content under your domain.
How are you so sure that Amazon did not just reserve these themselves to protect their customers?
If Amazon had performed these actions to protect their customers, more obscure domains would not be hijackable still. I was still able to perform a hijack on a domain that was DNS proxied through another provider. This meant that it was not as trivial for the third party or attacker to identify this particular hijack.
If Amazon were to fix it, they would be already have logs of all previous CNAME records attached and would be able to notify customers if they had not removed the CNAME record after deleting the instances.
How do I know if we have vulnerable subdomains?
Look through all of your subdomains to see if you use CloudFront. If you do, make sure all of those instances are attached to an actual instance on CloudFront with a CNAME record set to that subdomain you found.
If you don’t have access to that instance with the CNAME record you found, then you should try and create an instance with that CNAME record (THAT YOU OWN). If it’s not possible and it says that it is in-use, someone else has control over your subdomain and is able to **flip the switch **at anytime and serve content under your domain name. This means issuing SSL certificates, phishing users or even using this as a watering hole to attack visitors.
You put your CNAME in the following location when creating a new instance:
When registering an instance with your “suspected” hijacked CNAME, and you get the following error, you know that someone else has control of your CNAME on CloudFront:
You can also check if you exist on a list of hijacks that I enumerated and made public on https://github.com/vysecurity/CloudFrontHijacks. I do not believe that any of these can be further hijacked at this time as the third party entity appears to have automated the process and mass-reserved all of the hijacks. I do not have the ability to report 1 by 1 to 2000 CloudFront users, whether they even care about their domain being hijacked or not. This is as good as I can do in terms of responsible disclosure to ensure that everyone has the ability to easily check if they are immediately vulnerable.
How do I fix it?
Remove the CNAME record if you don’t use the instance anymore
Obtain access to the CloudFront instance, you might be able to contact Amazon, and prove that you own the domain so that they can switch ownership back to you— who knows?
If you need any more help, just ask me on Twitter DM @vysecurity
How do I stop this from happening?
Don’t delete CloudFront instances after you use them, just disable them.
If you want to delete the instance, make sure that you remove the CNAME record pointing to Amazon CloudFront edge nodes.
Further references to known use in bug bounty and offensive demonstrations
Last updated
