rbsec/dnscan

Wildcard scan

drakylar opened this issue · 11 comments

Hello, there is a bug inside dnscan.py at line 114: add_target(domain) # Recursively scan subdomains

This function must be run only when wildcard = get_wildcard(domain) is empty, so it is needed to add a condition if not wildcard:, or wildcard domain will be added to recursive subdomain scan.

And the same at 508 string

rbsec commented

Hi @drakylar,

This isn't actually a bug. The recursive scanning is intentionally run even when a wildcard is present, because a wildcard record doesn't meant that there are no other records for a domain. In fact, most domains that have wildcards will also have other records.

github.com is a good example of this: it has a wildcard record that returns four IP addresses (185.199.109.153, 185.199.111.153, 185.199.110.153 and 185.199.108.153), but then has subdomains such as www.github.com (140.82.121.3) or api.github.com (140.82.121.5) with different IPs.

Any records that return the same IP as the wildcard are ignored, and the only ones that are returned at those with different IP addresses. It's not perfect (as it won't pick up VHOSTS), but it's the best we can do at a pure DNS level.

Hi @drakylar,

This isn't actually a bug. The recursive scanning is intentionally run even when a wildcard is present, because a wildcard record doesn't meant that there are no other records for a domain. In fact, most domains that have wildcards will also have other records.

github.com is a good example of this: it has a wildcard record that returns four IP addresses (185.199.109.153, 185.199.111.153, 185.199.110.153 and 185.199.108.153), but then has subdomains such as www.github.com (140.82.121.3) or api.github.com (140.82.121.5) with different IPs.

Any records that return the same IP as the wildcard are ignored, and the only ones that are returned at those with different IP addresses. It's not perfect (as it won't pick up VHOSTS), but it's the best we can do at a pure DNS level.

Hello, yes, it's true. But I have several domains when this utility went into recursion and scanned up to 6th wildcard subdomain level. That was because of bad detection of wildcard ip-addresses. I will check later detection algorythm.

rbsec commented

@drakylar you can set the max recursion depth with -m or --maxdepth, which should stop it getting stuck for ever. Would that solve your issue?

@drakylar you can set the max recursion depth with -m or --maxdepth, which should stop it getting stuck for ever. Would that solve your issue?

Think this will help, but I wanted to minimize false-positive results.

rbsec commented

I'm not really clear what false positives you're seeing.

So if you scan example.org, and it has a wildcard domain, that gets flagged. Is the issue that if it has recursive wildcards (*.*.example.org that those are being returned? Are they returned as wildcards or actual records?

I'm not really clear what false positives you're seeing.

So if you scan example.org, and it has a wildcard domain, that gets flagged. Is the issue that if it has recursive wildcards (*.*.example.org that those are being returned? Are they returned as wildcards or actual records?

The issue was that if subdomain was wildcard (*.example.org) it returned non-existed domain a.example.org and started to scan wildcard subdomains *.a.example.org. So, I thought that there had been some problems with wildcard subdomains enumeration which leads to a lot of false-positive subdomains.

P.S. May be it will be better to add an option to ignore wildcard subdomains bruteforce?

rbsec commented

Ah, I understand where you're coming from. While I don't think it's technically incorrect to recursively scan a domain that we know has wildcards (as there's nothing stopping it also having default entries), this will be quite slow for domains that have a lot of them. I've added a --recurse-wildcards option to enable that (it's not performed by default) - does that solve the issue?

Thanks! Will check it later.

One new problem - sometimes DNS server from NX can stuck with response, so it is needed to add to dns.query.udp timeout parameter + I think it will be better to add several retries (line ~ 499).

dns.query.udp(request, nameserver, timeout=5)

Two more suggestions

  1. Add availability to make TCP dns requests (cli argument) due to some strange NX-servers with stucked response.
  2. Add availability to select a dictionary for -a alterations argument.