4

There're a number of security tools out there that enumerate the subdomains of a given domain. I wonder:

  1. What's the purpose of that in terms of security / hacking?
  2. Is there any way to do that other than by brute-force with a dictionary of the most popular subdomain names?
  3. How to protect my domain against subdomain enumeration?
The Illusive Man
  • 10,587
  • 16
  • 58
  • 89
Oskar K.
  • 149
  • 1
  • 5

2 Answers2

18

What's the purpose of that in terms of security / hacking?

The hostname(s) of resources can provide valuable information to narrow the scope of an attacker's task by providing information about available machines and resources. The underlying space of network (IP) addresses is sparsely populated (and IP:port combinations even more so), so narrowing down the addresses at which the organization hosts machines significantly reduces the preparatory work necessary to locate machines, map the topology, and launch an attack.

For example, the presence of a name ssh.company.com in the DNS provides hints of machines which probably host an SSH daemon. In the first instance, it is reasonable to suppose that daemon runs on its default port, significantly reducing attack overhead and advancing to the stage of probing for vulnerabilities. By contrast, scanning the large IP ranges of an organization (if known a priori) is slower, more time consuming, and more likely to trigger early alerts in firewalls and IDS devices of port scan attempts.

Is there any way to do that other than by brute-force with a dictionary of the most popular subdomain names?

Yes, there are alternative methods, which might be available depending upon the degree of (mis-)configuration of the relevant infrastructure. Here is a list of common methods:

  • A dictionary attack operates passively by sending standard DNS queries for common hostnames. By definition, it cannot guarantee to provide a full enumeration of a zone, but it will always find any resources with common hostnames. This attack vector cannot be mitigated without impeding the proper functioning of the DNS.

  • A brute-force attack also operates passively, but generates all possible combinations of hostnames. Such an attack can be exhaustive, as RFC 1035 limits the maximum permissible length of a DNS label and the overall length of an FQDN (§2.3.4). However, this would be extremely time-consuming, especially given the sparse population of the DNS namespace.

  • A zone transfer attack attempts to request a zone transfer from an authoritative DNS nameserver for a given domain. A zone transfers represents a dump of the entire zone contents, which is typically used by slave servers to update their locally cached copy of a zone. A successful zone transfer provides an enumeration of an entire zone.

    Most sysadmins provide some security-by-obscurity by restricting the source IP addresses which may submit zone transfer requests. Hence, this attack can only succeed if: a server has an open zone transfer policy (anybody may submit a zone transfer), the attacking party can observe a zone transfer in progress, or the attacking party gains the ability to issue packets from one of the trusted IP addresses, perhaps by traffic interception in the network.

  • An NSEC walking attack can enumerate DNSSEC-signed zones. DNSSEC must assert the non-existence of records in a zone to prevent attackers spoofing NXDOMAIN responses in an attempt at denial-of-service. The provision of a denial-of-existence proof is commonly achieved by sorting the zone records and linking them in a chain of NSEC records (each signed). It follows that the intervening namespace between each NSEC record contains no valid resource records.

    However, this technique necessarily allows the NSEC space to be trivially walked to enumerate a DNS zone.

    Various alternative mechanisms for minimizing this risk are proposed:

    • Online signing, in which the NXDOMAIN responses are generated ad-hoc and iteratively restrict a smaller and smaller subset of the namespace (e.g. restricting a.domain.com, then aa.domain.com, then aaa.domain.com). However, this approach requires a signing key to be distributed to slave servers, which spreads keying material further than perhaps desired.

    • NSEC3 records introduce hashes into the denial-of-existence proofs. The hashes are signed statically, obviating the need for slave servers to be provided with a copy of the signing key. As the hostnames are hashed, walking the chain of NSEC3 records is no longer trivial and attracts significantly greater overhead, although some claims exist that this is still not sufficient.

    Wikipedia has a good view on the whole issue.

How to protect my domain?

Protecting against the above attacks should be your first line of defense, through properly configured nameservers and carefully considering any deployment of DNSSEC. However, you cannot fully eliminate the threat of a dictionary or brute-force attack without breaking proper DNS functionality.

You should remain cognizant of the fact the DNS is public information; although it is perhaps good practice not to give up your zonefile to anybody who requests it, this is just security-by-obscurity. Defense-in-depth security techniques should still be adopted through appropriate security precautions in your network topology, training your system users against social attacks, properly tightening any public-facing daemons you might operate, and whatever else your written security policy dictates.

Zone transfer testing

It is easy to test (or experiment) with DNS zone transfers using the dig(1) utility under your favorite *nix environment. Finding a zone which allows you to transfer it is another matter, but digi.ninja provides the zonetransfer.me example for this purpose. The following command should demonstrate a successful zone transfer against the zonetransfer.me zone, which will provide you with a full enumeration of this demonstration zone:

dig @nsztm1.digi.ninja zonetransfer.me AXFR

You can test your own zones by replacing the relevant fields in the command. A failed attempt should elicit the response

; Transfer failed
Cosmic Ossifrage
  • 292
  • 3
  • 10
  • Great answer. I noticed one minor incorrect detail. You suggest that the introduction of IDN would make it more work to brute force an entire zone. But in reality such domains are still encoded using ASCII characters, and the 63 character length limit applies after encoding. Not that it matters since with a maximum length of 63 characters and 37 valid characters to choose from nobody is going to brute force it all. That it would be an on-line brute force attack makes it even more impossible. – kasperd Jun 28 '15 at 22:09
  • 1
    @kasperd, that's a good point, it shouldn't matter given the ASCII character encoding. I've updated the answer to remove that error. And as you say, it is not feasible in any case. Thanks! – Cosmic Ossifrage Jun 28 '15 at 22:13
  • Again, the question 2 isn't answered. My question wasn't how to perform an attack, it was "How to find the subdomains". – Oskar K. Jun 29 '15 at 02:43
  • 1
    @jawanam This answer gives you no less than four different approaches to enumerate the subdomains. – kasperd Jun 29 '15 at 09:25
  • 1
    @CosmicOssifrage Using an online attack to find all the NSEC3 hashes and offline computation to identify hostnames corresponding to those is certainly a feasible way to identify lots of subdomains using fewer queries than an online dictionary attack. My take on that is that the iterated hash in NSEC3 ought to be replaced with a hash-sign-hash approach. Then an offline dictionary attack on the collected hashes would not be possible to an attacker who has only the public key. – kasperd Jun 29 '15 at 09:30
  • 1
    @jawanam, the "attack" is precisely to enumerate the subdomains. Whether this is perceived as an "attack" depends on local security policy, but most would consider a third-party who obtains a full or partial zone listing unfavorably. – Cosmic Ossifrage Jun 29 '15 at 11:46
9

Subdomain enumeration techniques are passive methods used during a pre-attack phase or during information gathering phase of a pentest assignment.

  1. Enumerating subdomains is crucial as they may point to different parts of a web application or may lead to another website hosted on another server with a different IP address. This allows you to come up with an accurate public network profile for the target organization. This process can act as a precursor to a perimeter test just before the scanning begins. refer to How can I find subdomains of a site?

  2. The tools used for subdomain enumeration rely on a brute force approach using a wordlist. Another possible method is to attempt a DNS zone transfer. In this case the attacker pretends to be the slave DNS server and requests the master DNS for a copy of records. However this only works for insecurely configured DNS servers. In my opinion brute forcing is the most reliable technique available for enumeration. refer to DNS zone transfer attack

  3. As mentioned earlier, this is a 'passive method' of enumeration and hence AFAIK there is no way to prevent this. As long as your domain is accessible over the public internet it can be found using the brute force method.

Community
  • 1
Shurmajee
  • 7,335
  • 5
  • 28
  • 59
  • 2
    For 3, sure it's security by obscurity, but one could set up a wildcard domain record, so that every subdomain responds to an IP address. – ndrix Jun 28 '15 at 07:45
  • 1
    @m1ke I suppose that will work if you are using virtual hosts but may not work in environments where your services are scattered across hundreds of different IP addresses. – Shurmajee Jun 28 '15 at 09:27
  • 1
    Wouldn't that just resolve non-existing names to an IP address? Thereby making it more difficult to differentiate existing and non-existing ones. – ndrix Jun 28 '15 at 10:24
  • 1
    **2. Before trying to brute force subdomains** - I'm not saying I want to brute-force them, I'm asking how to find the subdomains of the domain? – Oskar K. Jun 28 '15 at 13:38
  • 1
    @jawanam It was the pentestor inside me..while performing an assessment the first thing I try is DNS zone transfer attack. If that does not work I would go with the brute force approach for finding subdomains. I will update the answer. – Shurmajee Jun 28 '15 at 16:09