8

A friend of a friend received an email from a security researcher that looks legit. Researcher submitted several vulnerabilities, one of the them reads like this

Vulnerability # ...

Title : Lack of wildcard DNS Entry!

Description : The risk of attackers knowing the wildcard which could thus result in DNS Hijacking and further threats. There are several issues related to this. The most common i can think of is phishing. Wildcard DNS is a handy feature, and phishers are apparently using it to bypass filtering. Phishers use wildcard DNS to get around filtering since filtering, in many cases, is based on exact host name and domain name combinations. With wildcard DNS Phishers can generate any number of differing URLs on the fly and often evade filtering technology.

On the Web server side, a simple bit of code can parse the URL to find which hostname was used to land on a site, and then redirect the visitors as necessary.

And there is no wildcard entry so attacker easily enumerate your secret and Public Subdomains.

Then comes a proof of concept with an output from DNS brute-force tool knock.

Just to clarify, the website in question does not have a wildcard (*) in the DNS entry and recursive sub-queries to the DNS are not allowed (e.g. AXFR query doesn't work). The website treats DNS sub-domains as public information anyway. IMO, this is not a vulnerability - it's by design, just want to cross-check with the community.

Question: is lack of a wildcard entry in the DNS a security vulnerability?

  • Security by obscurity is not real security though, so it shouldn't matter if the entire domain file is available online. The entire IPv4 range is now nmap'ed on a daily basis, so it's no longer possible to hide a service. Might as well not bother with wildcards. – billc.cn Dec 1 '15 at 11:04
4

This boils down to subdomain enumeration:

Say you have a wildcard DNS entry and the attacker tries the following subdomains:

admin
cms
email
ssh
rdp
secure

If you have a wildcard DNS entry then the following results will be returned.

admin.example.com - Exists
cms.example.com - Exists
email.example.com - Exists
ssh.example.com - Exists
rdp.example.com - Exists
secure.example.com - Exists

If you do not then the attacker could determine which private sites and services may exist:

admin.example.com - No entry
cms.example.com - No entry
email.example.com - No entry
ssh.example.com - No entry
rdp.example.com - No entry
secure.example.com - Exists

That is, the attacker has managed to determine you have a secure.example.com FQDN that may be hosting some type of sensitive service. However, even with the first example the attack could find out whether each entry resolves to the same IP or not. It is only really an issue with services that include a hostname in their protocol, such as http with host header and https with Server Name Indication (SNI). This means that an attacker would have to discover such a service and then make a valid request to the domain to determine if you have any service there (such as requesting cms.example.com in the first example and setting the correct host header or SNI field).

4

Based on the context you've provided I don't see a significant threat.

I'm assuming you're running a pretty typical internet facing web service and from that perspective the explanation your security researcher provided seems a bit muddled.

The most common i can think of is phishing. Wildcard DNS is a handy feature, and phishers are apparently using it to bypass filtering.

I don't see how this is a direct threat to you seeing as presumably an attacker can't modify your DNS records. I can see how it might be a threat to your users (being a subset of internet users in general) who might be vulnerable to DNS poisoning or phishing in general, but this is far beyond your control.

With wildcard DNS Phishers can generate any number of differing URLs on the fly and often evade filtering technology

Again, this is true... but only on an arbitrary domain they control, not on your domain.

And there is no wildcard entry so attacker easily enumerate your secret and Public Subdomains.

I guess maybe there's some validity here if an attacker found it difficult to distinguish between a legitimate service and a fake/honeypot one. In practice you would need a lot of fake servers running fake services to make it significantly more difficult for an attacker to identify the legitimate one.

Plus, there's more effective ways of protecting public facing services besides simply obscuring them more.

There may be additional attack vectors to consider if your scenario is not what I assumed. For example if you're running an internal network with private DNS that serves records for publicly resolvable domains that someone else might control. This doesn't sound like the case though.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.