To illustrate this point in my talk, I used the crossdomain.xml file at www.sears.com:
What I found in my research is that there are plenty of crossdomain.xml files that trust sites that are available for purchase. As far as I know, every single security assessment tool out there would pass right over these sites, missing the fact that a vulnerable configuration could be in place.
In the case of www.sears.com, they are trusting the domain: searstestsite.com. For the purpose of demonstrating the vulnerability, I purchased this domain. This means that I can now host a malicious SWF at www.searstestsite.com, a domain that I own and operate, and anyone who is authenticated with www.sears.com, who also navigates to my site, will execute my malicious SWF.
When I realized this is actually somewhat common, I wrote a nmap script to parse crossdomain.xml files and help you (the tester) determine if any of the trusted domains are available for purchase:
You can then paste the results into https://www.dynadot.com/domain/bulk-search.html, like so:
At the time of my talks, I still had not yet found a domain service that allows you to make automated requests without an API key. Since then, while it is still not a 100% perfect solution, I have found a site that will give us what we need for the 10-15 most common TLDs: instantdomainsearch.com.
So now, if you run my nmap script with --script-args=liveLookup, the script will attempt look up the domain availability for every domain that has a TLD that can be checked. For ones that are not available, there is no need to tell the user about them. For the ones that are available, the script makes it very clear that the domain is available for purchase. Lastly, the script falls back to the original method for any domain that has a TLD unsupported by instantdomainsearch.com.
Here is http-crossdomain.nse in action, using the liveLookup script argument