Active Subdomain Enumeration (Part 2)

Uncategorized
0
Avatar
Author

You can read part-1 (Passive Subdomain Enumeration) here.

Active sub-domain enumeration techniques

Brute force or Dictionary Attacks

Brute force means guessing possible combinations of the target until the expected output is discovered. So, in the subdomain context, the brute-forcing is to try the possible combination of words, alphabets, and numbers before the main domain in order to get a subdomain that is resolved to IP address. Sometimes subdomains are not indexed on search engines and are not available on online DNS aggregators sites in that case brute forcing is the best way to find out the subdomains which may have been forgotten by the organization. It is like a treasure for an adversary.

Two techniques for subdomain enumeration using brute force:

  • Dictionary brute force
  • Permutation brute force

 

Dictionary brute force:

In the dictionary brute force, we directly use the wordlist to a brute force domain name to find valid subdomains.

Tools:

 

Permutation brute force:

In permutation brute force, we create a new resolved subdomain list from already known subdomains/domains by using permutation, mutation, and alteration with a wordlist.

Tool:

 

By Zone Transfer

DNS zone transfer is the process of replication DNS database or DNS records from the primary name server to the secondary name server.

The DNS zone transfer functionality used by an adversary only when the primary name server is configured to replicate the zone information to any server. An adversary acts as a slave and asks the master for a copy of the zone records.

 

Why we need DNS zone transfer?

Availability

If the primary name server goes down, then the secondary server handles all DNS requests.

Load Balancing

If many DNS name resolution requests occurred, then the secondary name server load balances these requests.

Faster Resolution

If the primary name server is located on the slow WAN link, then the secondary name server handles the name resolution requests.

 

Types of information gathered by zone transfer 

  • Subdomain
  • Email address (Could help in phishing)
  • Current serial number (Change in serial no. may indicate changes in the organization)
  • Email server (Could help in phishing)
  • Name server
  • Location may be disclosed by LOC record
  • The IP address of the website
  • Services running in the organization by SRV record

Command to check zone transfer

dig ns zonetransfer.me +noall +answer

dig axfr @nsztm1.digi.ninja zonetransfer.me


host -t ns zonetransfer.me

host -t axfr zonetransfer.me intns1.zonetransfer.me


nslookup -type=ns zonetransfer.me

nslookup -query=AXFR zonetransfer.me nsztm2.digi.ninja

By Domain Name System Security Extensions (DNSSEC)

Domain Name System Security Extensions (DNSSEC) is used to protect the integrity and authenticity of the data in DNS by establishing a chain of trust.

 

Before an understanding of DNSSEC, we first need to understand the basics of DNS:

What are the DNS functionalities?

  • DNS is used to translate a domain name to IP address or vice-versa.
  • DNS works on both TCP and UDP but normally works on UDP port 53.
  • TCP port 53 is used when a very large request and response is sent, for example zone transfer.

www.example.com à 192.168.1.10

192.168.1.10 à www.example.com

Why DNS?

Domain names are alphabet and they are easier to remember that is why we use domain names.

Before DNS the host.txt file was required to be regularly updated, which was distributed to all hosts on the Internet.

Issues with this are:

  • The host file usually was huge after prolonged usage
  • Regular manual updating was required
  • Name uniqueness maintenance was required, which proved a difficult task.

 

How does it work?

When you enter a domain name in the browser (www.google.com), it first tries to resolve from the system host file, then passes the request to the ISP DNS server, then passes to another DNS server and this process continues until the request is not resolved. When the request resolves the response flow back to the DNS servers to the original requester that is a browser and then the requested website becomes accessible.

 

Basic DNS terminologies:

  • Name servers
    • Authoritative Servers
    • Non-Authoritative/Caching Servers
  • DNS Query
    • Recursive DNS Query
    • Non-Recursive or Iterative DNS Query
    • Inverse Query

 

Name servers 

Authoritative Server

  • An authoritative name server is the official name server that is authorized to provide an answer for a domain you are querying for.
  • The authoritative name server can be more than one name server.
  • There are two types of authoritative name servers based on the management method primary (master) and secondary (slave).
  • Changes are done in the primary name server and the secondary name server/s will retrieve the copy of the zone file from the primary name server.

 

Non-Authoritative/Caching Server

The non-Authoritative name server is the cache server, which cache the domain information for faster response to the domain you are querying.

 

DNS Query

DNS query is configured on the DNS server and accordingly, the DNS server works.

Recursive DNS Query

When a recursive query is configured on the DNS server then the DNS server does all the job on behalf of you to fetch the answer to your query. During this process, the DNS server might query other DNS servers on the internet for the answer.

 

Non-Recursive or Iterative DNS Query

When a non-recursive query is configured on the DNS server then the DNS server does not fetch the complete answer of the query on behalf of you but will give the address of other DNS servers, which might have the answer of the query. During this process, the DNS server might provide the IP address of other DNS servers on the internet for the answer and the operating system resolver will query until the domain name does not resolve.

 

Inverse Query

Inverse DNS query works opposite to normal DNS query. Inverse DNS query or reverse DNS query is used when the user wants to resolve an IP address to the fully qualified domain name (FQDN).

 

DNS Protocol Vulnerability

The original DNS protocol was not designed with security in mind, as the Internet grows, it becomes less trustworthy. There was no DNS data protection mechanism available which caused the below vulnerabilities:

  • DNS data can be corrupted as it was transferred between primary server, secondary server, resolver or forwarder, cache server.
  • DNS data transaction could be compromised as the primary server may send DNS records data to a wrong secondary server which could be in adversary control.
  • There was no way to check the integrity of the DNS data.

 

Basic DNS Security Practices

  • Run the updated version of DNS software.
  • Restrict queries
  • Prevent unauthorized zone transfers
  • Run BIND with the least privilege (use chroot)
  • Randomize source ports
  • Secure the box
  • Implement TSIG and DNSSEC

 

Two protection mechanism “Transaction Signature (TSIG) and DNS Security Extension (DNSSEC)” use for DNS data protection

 

Transaction Signature (TSIG)

  • TSIG secure the transaction to protect zone transfer and dynamic update.
  • TSIG make sure that DNS query (Ex: AXFR) come from right place and are not modified in transit.
  • Work on shared secret key, which is configured on both master and slave DNS servers.
  • TSIG is configured in DNS server (named.conf) file, not in zone file.
  • A wrong key does not allow for the zone transfer and will be logged on the server log.
  • Command: dig @<server> <zone> AXFR -k <TSIG key file>

dig @localhost example.com AXFR -k Key-ns1.net.+200+1337.key

 

DNS Security Extension (DNSSEC)

  • DNSSEC is used to secure the zone data by making sure that the resource records are those records that are signed by the administrator of the zone.
  • It protects the integrity and authenticity of the zone data by establishing the chain of trust.
  • It uses digital signature to verify the zone data.

 

For signature validation DNSSEC add new DNS record types:

 

Resource Record Full Form Function
RRSIG Resource Record Signature It contains a cryptographic signature
DNSKEY DNS Key It contains public key which is needed for verifying the RRSIG
DS Delegation Signer It contains the hash of the DNSKEY record
NSEC/NSEC3 Next Secure It indicates which name is the next one in the zone and it is for explicit denial-of-existence of a DNS record

 

RRset and RRSIG

The first step for securing the zone with DNSSEC is to group all the same type of records which is called resource record set (RRset).

RRset Example:

Bundle into a single A RRset

 

www.example.com. 7200 IN A 192.168.1.10

blog.example.net. 7200IN A 10.0.1.1

admin.example.net. 7200IN A 172.16.2.20

 

RRsets are digitally signed with the private key of the zone server and signature are published in DNS as RRSIG. Public DNSKEY is also published to verify the RRSIG signature.

 

RRSIG Example:

 

www.example.com.                4 IN A  149.20.64.69

www. example.com.               4 IN RRSIG A 5 3 60 (

                                                20141029233238 20140929233238 4521 isc.org.

                                                DX5BaGVd4KzU2AIH911Kar/UmdmkARyPhJVLr0oyPZaq

                                                5zoobGqFI4efvzL0mcpncuUg3BSU5Q48WdBu92xinMdb

                                                E75zl+adgEBOsFgFQR/zqM3myt/8SngWm4+TQ3XFh9eN

                                                jqExHZZuZ268Ntlxqgf9OmKRRv8X8YigaPShuyU=

 

 Zone Signing Key (ZSK)

  • The private zone signing key is used to digitally sign each RRset and store them in RRSIG.
  • The public zone signing key is used by resolver to verify the digital signature that are stored in RRSIG.
  • The public zone signing key is stored in DNSKEY record.
  • When DNSSEC resolver ask for a DNS record (e.g. A), the name server also return the corresponding RRSIG and then DNSSEC resolver ask for the public ZSK from the name server.
  • If we trust the zone signing key, then we can trust all the records in the zone but what if zone signing key was compromised? So, to validate the public ZSK we used key signing key (KSK).

 

Key Signing Key (KSK)

  • The KSK validates the DNSKEY record for zone signing key in the same way the ZSK validate the RRSIG record.
  • The private KSK signs the public ZSK and public KSK, which is stored in DNSKEY record and create an RRSIG for the DNSKEY that stores the signature of the public ZSK and KSK.
  • The name server stores the public KSK in another DNSKEY record.
  • DNSSEC resolver uses the public KSK to validate the public ZSK.
  • To establish the trust within the zone.
  • The key signing key (KSK) is signed by itself, which does not provide any additional trust, an adversary may compromise the zone and alter all these keys. So, for complete trust we need parent child trust, for this delegation signer (DS) record is use.

 

Example:

 

example.com.             300 IN DNSKEY 256 3 8 (

                                                AwEAAclob7q+ccvDwaTVuMM2ddGIynWyMwaZlhFrU6cC

                                                0qknWoPpkq0gIwTrYf3DJY+eIKPVHxrM+o2AoRIVhubG

                                                jfv1bT5wTYrawZstS84ejCQ+ehA+8DxKyeWUEzW0ZMBe

                                                OhyeG0cuQVK/p6Z1E096JLu0DjgbabLspequkw4M+HT7

                                                ) ; ZSK; alg = RSASHA256; key id = 57009
example.com.             300 IN DNSKEY 257 3 8 (
                                                AwEAAdQ2ctHx8VmryndiOgpchXPdj3NwxMeUvAre6uYI

                                                5KELlFJUghTHrz+/CzEc8CXG8wwQ4ZvAey0FGV2nJAFC

                                                ENMxoRiCz0oSiQQxryNhACd3RnE2/D7G+ShwlOM6w53E

                                                wUJ/lsgu5UevSxFC+eA3fKeL3TWR44PH4iJQp9QmfW5v

                                                7qG8Sic/HQvBGBdOGfFtHAl0a4jDPBi57imS4YsHcUYD

                                                9bsWmhYWSHJKZ66+JnTiMS0nQM69YwBF43QfDKurs5R6

                                                qPUDiBlaMCzSxmlaBU6fsI1Mu/yIU8w1ewy26a42rUTU

                                                rPBC3Oa/zf9VQ8kpUrMZgJ7LEAA4xmR+qwWDh6U=

                                                ) ; KSK; alg = RSASHA256; key id = 28267

 

Delegation Signer (DS) Record

  • Delegation signer (DS) record allows the transfer of trust from the parent zone to the child zone.
  • The zone operator hashes the public KSK and gives it to the parent zone to publish the hash as a DS record.
  • Whenever the resolver connects with the child zone, the parent zone also shares its DS record, which makes the trust between parent and child.
  • The DS record in the parent zone helps the resolver to know that the child zone is DNSSEC enabled.
  • DS records should not be added in the child zone.

 

Example:

 

example.com.            86400 IN DS 8401 5 1 (

                        5248DB0EAE4E829924F19D33B005FBC8C4606058 )

 

Why do we use two keys?

So, now the question is what is the purpose of using two keys when both keys are from the zone itself.

We use two keys to protect the zone itself and to provide the parent-child trust, as making any modification in the key signing key (KSK) is a difficult process because we have to make a hash and change that hash into the parent delegation signer (DS) record. Changing the DS record is a multi-step process that can end up breaking the zone if it’s performed incorrectly. On the other side, changing the zone signing key (ZSK) is much easier. We just need a modification within a zone.

 

What if an adversary compromised the child and parent server then all the DS information would match. So, to trust the DS record first we need to understand the “Chain of trust”.

 

The Chain of Trust

  • The chain of trust works by signing the delegate signer (DS) records by ZSK like any other RRset for the child’s keys, which means it stores the signing data into the RRSIG in the parent.
  • The digital signature for DS stored is stored in the RRSIG record.
  • For the chain of trust, in example.com the validating resolver asks “.com” for the ZSK public key, DS, and signature to verify the hash in the parent zone of the child KSK key and to verify the KSK of “.com”. Then the resolver asks the root (.) for the DS, ZSK, and signatures. The same process is also followed for root. The whole validation process repeats until we get to the parent’s public KSK.

 

Till now, example.com and .com check out, but what about root? There is no parent DS record to validate against.

For completing the chain of trust cycle, we must trust the security procedure done by humans.

 

For signing the root, the Root Signing Ceremony is performed every quarter to verify the public and highly audited way. In this ceremony, some selected individuals from the international community agree and sign the root DNS zone’s RRset for the DNSKEY records. The ceremony produces an RRSIG record that can be used to verify the root name servers public KSK and ZSK. Instead of trusting the public KSK because of the parent’s DS record, DNS resolver assumes that it’s valid because we trust the security process in which the Root Signing Ceremony was performed.

 

NSEC/NSEC3 (Explicit Denial of Existence)

 

In traditional DNS setup, when we ask DNS for the IP address of a domain that does not exist, it returns an empty answer. So, how do we authenticate that the requested domain exists? As there is no message to sign. The fix for this issue was to add NSEC and NSEC3 record types that explicitly tell a DNS resolver that a given zone does not exist.

The NSEC record is used to prove that something really does not exist, by providing the name before it, and the name after it.

NSEC works by returning the “next secure” record. The NSEC record allows for proof of non-existence for record types. For every existing name, there is a corresponding NSEC record. This NSEC record states what types are available for the current name, as well as the next valid name, is in the sorted zone file. This brings us to the downside of NSEC: Since the NSEC records essentially chain through the complete zone, it is possible to do “zone walking”.

 

Example:

example.com

api.example.com

beta.example.com

 

Let’s assume a request is made for example.com

 

Request:

dig NSEC example.com

 

Response:

ANSWER SECTION:

example.com.     3600    IN      NSEC    api.example.com. A NS SOA MX TXT AAAA RRSIG NSEC DNSKEY

 

Request:

dig NSEC api.example.com

 

Response:

ANSWER SECTION:

api.example.com.     3600    IN      NSEC    beta.example.com. A NS SOA MX TXT AAAA RRSIG NSEC DNSKEY

 

In the same way, the adversary can use it for zone walking and enumerate all subdomains in the zone.

NSEC3 uses a hashing algorithm to list the next available domain in the “hashed” format. It is still possible for an adversary to do zone walking, although at a higher computation cost.

DNSSEC Process

  1. The user enters the example.com in the browser to access the website.
  2. DNS request transfer to resolver for the DNS resolution.
  3. Resolver query example.com nameservers for the A record and in this query, resolver add DNSSEC bit, which notifies the nameserver that resolver is DNSSEC enabled and DNSSEC Answers are desired.
  4. The name server is DNSSEC enabled, so the nameserver responds with the answer to the “A record” query with the RRSIG of “A record” which is the digital signature for the verification purpose.
  5. For digital signature verification, the resolver asks the nameserver for the public key which is DNSSEC (ZSK and KSK) records.
  6. Nameserver responds with DNSSEC (ZSK and KSK) and RRSIG of the DNSSEC records.
  7. The DNSSEC(ZSK) record is used to verify the RRSIG of the “A record”, the answer is received in step 4, and DNSSEC (KSK) record is used to verify the RRSIG of the DNSSEC (ZSK and KSK) record.
  8. For the chain of trust, the resolver queries the parent (.com) for the DS record that is hash of the of example.com KSK.
  9. Parent (.com) nameserver responds with the DS record and RRSIG of the DS record.
  10. The DS record is the hash value of the child KSK that is stored in the parent DS record. The resolver verifies the RRSIG record of the KSK in the child by decrypting the digital signature and comparing the hash of the DS record with the hash of the RRSIG KSK after decryption.
  11. Resolver query the .com nameserver for the DNSKEY to verify the RRSIG of the DS record.
  12. Parent (.com) nameserver responds with the DNSKEY (ZSK and KSK). The resolver decrypts the RRSIG of the DS record with the ZSK public key and verifies the result. RRSIG of KSK verifies by the KSK public key.
  13. For the chain of trust, the resolver asks the root (.) for the (.com) DS record, which is the hash of the .com KSK.
  14. Root name server responds with DS record and RRSIG of DS. The DS record is used to verify the KSK of the (.com).
  15. Resolver query for the DNSKEY of the root to verify the RRSIG record of DS.
  16. Root nameserver responds with the DNSKEY, resolver decrypts the RRSIG of the DS with the root ZSK and compares the DS values. Public root KSK is used to decrypt the RRSIG of the ZSK and compare the ZSK for the trust. If all the results are verified, then all zones and records are trustable.

Tools for NSEC subdomain enumeration

Subdomain Enumeration by DNS Records 

CNAME Record

In DNS zone file CNAME stands for a canonical name. CNAME is used in the domain name system (DNS) to create an alias or pointer for one domain name to another domain name.

For example:

example.com                 A             192.168.1.1

documents.example.com       CNAME         example.com

Let say, example.com is the domain name that connects with the file server, where you store all the personal files, but you want to access the same server with documents.example.com for better understanding. So, for accessing the domain with documents.example.com you have to create an alias or pointer that points to example.com.

Sometimes CNAME reveals an organization subdomain or reveals information about third-party services like Amazon.

 

SPF Record

SPF is the Sender Policy Framework as the name suggests. It is a policy that is used for whitelisting the IP address and domain names which are authorized to send an email on behalf of your domain. SPF is the list of IP addresses and domains that are allowed to send an email on behalf of your domain.

So, when you send an email let say from the example.com domain to the gmail.com domain. The Gmail that receives the email will check if the IP address of the mail server that sent the email is included in the SPF record of the example.com zone file.

If the sending IP address is in the list, the email will pass the SPF check and mail will likely be delivered.

If the sending IP is not on the SPF record, it likely not to be delivered.

An adversary uses this information to understand the organization’s infrastructure, IP addresses, third-party email services, internal netblocks, and subdomains. The SPF record is defined using the TXT record. So, whenever one searches for an SPF record, it should be searched by the TXT record.

Tool

Netblocks, ASN, and Domain names extractor from SPF Record

https://github.com/0xbharath/assets-from-spf

 

Subdomain Enumeration by HTTP Header

Content Security Policy (CSP) is a response header that tells the browser from what sources it is allowed to include and execute resources.

It is like a filter where sources are mentioned and in sources, the domains and subdomains are mentioned. An adversary may use this information to enumerate more subdomains and other domains that are allowed by the organization.

Tool

Curl

Domain extraction from CSP

https://github.com/0xbharath/domains-from-csp

CONCLUSION

The blog post covers different active techniques of subdomain enumeration. These techniques provide information regarding all the domains/subdomains of the target organization. The information contains all those subdomains that currently may or may not be in use by the organization. As these are active reconnaissance techniques, the adversary or tester gathers the information by directly probing the infrastructure managed by the organization. The detection of adversary or tester may be possible by the organization. Such kind of probing may raise alerts and/or flags. It also provides an understanding of the target organization’s infrastructure and web technologies which will be helpful for further attacks.

You can read part-1 (Passive Subdomain Enumeration) here.

Author

Leave a Reply

Your email address will not be published. Required fields are marked *