Comment by iancarroll
12 hours ago
How do you suggest I determine the information is bad, if the domain is hosted on tesla.com, and Tesla says I am authorized to test it? Should I inspect all 1,368 subdomains on tesla.com by hand, and then do the same for 400+ bug bounty programs?
Maybe i'm old fashioned, but personally I think the onus should be on the person sending out unauthorized malicious requests to figure out how to not do that.
Any responsible bug bounty researcher reviewing the DNS zone by hand would spot the CNAME and remove it from the target list. You don't get to wash your hands of that because your chatbot did it.
Even before AI, I can't imagine a single bug bounty researcher doing that. Pre-AI, everyone ran a tool like subfinder to enumerate subdomains, httpx to resolve them, nuclei to scan them, etc. There's no human review involved there at the subdomain level.
And I don't know anyone that would really look at the intermediary of a CNAME even during a manual test. Maybe if it was obviously a third party service.
Yes, unless you think that trying to do a bug bounty is a good excuse to participate in DoS.
The OP says they have received 50,000 requests in about a month. What service is being denied by 0.01 requests per second?
You're now confident that the other 399+ domains you mentioned are not under any sort of duress because they're controlled by people who are away of what's happening?
5 replies →
When I engage a security assessor on behalf of a client, I am required to provide detailed scope and attest to in scope assets (including IP blocks and public hostnames), as well as that I have legal authority for them to be tested. This is validated by my executive sponsor.
It is your responsibility to do your due diligence as a security researcher versus “spray and pray” to ensure you are not exceeding the scope beyond your intended target.
Dump the subdomains, resolve them, and review where they resolve to in order to understand the footprint and attack surface boundaries before engaging scanning or agentic red team harnesses. Automate as much as possible for building the state graph of the target, but a human must remain in the loop to sanity check. To not do this means you could be attacking hyperscaler object storage, a CDN, a partner SaaS frontend, ticketing systems, mail systems, etc (ie anything someone may CNAME off the root domain but that is outside of their organization’s control).
I reckon there's a decent argument to be made that an authorization to scan *.tesla.com definitively does NOT extend to any hosts resolved via a CNAME chain that goes foo.tesla.com -> bah.not-tesla.com -> host-that-never-authorized-attacking.
Pretty hard to implement in practice!
% dig www.tesla.com +short
www.tesla.com.edgekey.net.
e1792.dscx.akamaiedge.net.
<akamai IP>
[dead]