Check if the domain has a CNAME record pointing to a known provider.
Ony If it does, make an HTTP request to the subdomain and look for the string that indicates it can be taken over (providers-data.csv -> string column).
So if a domain points to a provider indirectly (vuln.example.com -> foo.example.com -> bucket.s3.amazonaws.com), tko-subs won't check if it's vulnerable.
Also, a domain doesn't have to be pointing to something.s3.amazonaws.com to be vulnerable. If you have an A or AAAA record pointing to an IP used by S3, you can claim it too.
So the new workflow should be:
Make an HTTP request to the subdomain and check if it looks vulnerable.
Check if there is a CNAME and include it in the output (backward compatibility).
Note: The usage of S3 in the examples above is for explanatory purposes - the issue applies to all providers.
Thanks to Nick Jenkins for pointing out the issue.
The current workflow is:
CNAME
record pointing to a known provider.So if a domain points to a provider indirectly (
vuln.example.com -> foo.example.com -> bucket.s3.amazonaws.com
), tko-subs won't check if it's vulnerable.Also, a domain doesn't have to be pointing to something.s3.amazonaws.com to be vulnerable. If you have an
A
orAAAA
record pointing to an IP used by S3, you can claim it too.So the new workflow should be:
Note: The usage of S3 in the examples above is for explanatory purposes - the issue applies to all providers. Thanks to Nick Jenkins for pointing out the issue.