In my experience, an often overlooked topic / attack surface is DNS. Everyone uses DNS, meaning everyone has a potential vulnerability that might be missed. This post is meant to dig up information on DNS and attack techniques.
Starting from ground level, DNS is the Domain Name System. Put simply, it is how we get to websites by remembering "bestestredteam.com" instead of the associated IP address. There are several types of DNS records, each containing a different piece of information about a network.
- The Start of Authority (SOA) record contains administrative info about a zone. Things like name, email address, serial number.
- The A record is the IP address (IPv4) and the AAAA record is the IPv6 address associated with the domain name.
- The MX record determines the mail server that accepts email for a domain name.
- The NS record lists name servers.
- The PTR record contains pointers for reverse DNS lookups.
- The CNAME record defines domain name aliases.
When you try to browse to a website, your computer will try to resolve the name itself. In this case, your system is working as a system resolver. If the resolver can't find the name, it will ask a DNS server. This DNS server will likely be a recursive DNS server. Meaning it will keep passing on the query to another DNS server until the name is resolved.
Companies will set up their own private DNS for their internal systems. Their DNS server will likely be it's own server and ideally, will be entirely separate from the external DNS server. That is to say, the internal DNS server is unaware of the external one.
Now that we've covered what DNS is, let's dig into how we can learn more about specific DNS name servers. One quick way is to use SecurityTrails, which pulls info from the various records as well as subdomains and historical data. There are also several tools we can use:
To find more information, we can use the dig tool. Dig stands for domain information groper, and it does just that. A typical dig command will have some of the following:
dig [@server] [-b address] [-c class] [-f filename] [-k filename] [-m] [-p port#]
[-q name] [-t type] [-x addr] [-y [hmac:]name:key] [-4] [-6] [name] [type]
Since that looks a little overwhelming, let's break it down:
@server- The name or IP of the name server to query. Example - 188.8.131.52
-b address- The source IP of the query. This would set the source to the address of one of the host's network interfaces. Example - 0.0.0.0
-c class- This defaults to IN (for Internet) but you can enter any valid class.
-f <filename>- A list of lookup requests, read from the file.
-k <filename>- A file which contains a TSIG key.
-m- Memory usage debugging.
-p <port>- Allows you to specify a non-standard port.
-q <name>- Assigns a name to the query.
-t <type>- Specifies the type of DNS record to obtain.
-x <address>- Tells dig to perform a reverse lookup. You would supply an IP address. You would not need to supply the name, class, or type.
-y- Specification for a TSIG key itself. These can be generated by dnssec-keygen.
-6- forces dig to only use IPv4 or IPv6 query transport.
name- Resource to be looked up. Example - bestestredteam.com
type- Specifies the type of DNS record to obtain.
class- This defaults to IN (for Internet) but you can enter any valid class.
queryopt- Allows options that can change what is looked up and/or what is displayed in the results.
Similar to Dig, we can use another enumeration and scanning tool called DNSrecon. A typical command will look something like:
dnsrecon [-h] [-d DOMAIN] [-n NS_SERVER] [-r RANGE] [-D DICTIONARY] [-f]
[-t TYPE] [-a] [-s] [-g] [-b] [-k] [-w] [-z] [--threads THREADS] [--lifetime LIFETIME]
[--tcp] [--db DB] [-x XML] [-c CSV] [-j JSON] [--iw] [-v]
Let's once again look at what these command flags mean. I'll skip over the ones that are similar to Dig and focus on the ones that are unique.
-r <range>- Allows reverse lookup brute force.
-D <dictionary>- A file with sub-domains and hostnames to use for brute force.
-f- Filters out brute force results that resolve to the wildcard defined IP address.
-a- Attempts a zone transfer with standard enumeration
-g- Google enumeration.
-b- Bing enumeration.
-k- crt.sh enumeration
-w- Deep whois record analysis
-z- DNSSEC Zone Walk
-j <file>- Allows you to save found records in SQLite 3, XML, CSV, or JSON respectively.
--iw- Continue to brute force even if a wildcard record is discovered.
-v- Show attempts during brute force.
A zone transfer is a DNS transaction typically used for easily replicating DNS databases across DNS servers. However, if a sever is vulnerable, it can also be used as part of your information gathering phase. With a successful zone transfer, you obtain whatever records are stored in that zone. There are multiple tools we can use for to perform a zone transfer. We've already talked about Dig and DNSrecon, both of which can attempt a zone transfer by setting the type to AXFR. So the commands would be:
dig axfr @nsztm1.digi.ninja zonetransfer.me
dnsrecon -d zonetransfer.me -a
Another tool, and a quick way to test for zone transfers is DNSenum. The command would be
dnsenum zonetransfer.me. DNSenum also enumerates records making it a good "one stop shop" tool for DNS investigations.
The above commands utilize zonetransfer.me, a "domain which is easy to remember and which will always have zone transfer enabled." This site can be a great way to demonstrate the risk associated with the information gained from a zone transfer.
DNS Cache Poisoning
Also known as DNS spoofing, this attack is used to direct users to a different server than the expected host. This means a penetration tester (or attacker) could redirect legitimate traffic to their own controlled server. From here, they could harvest credentials or deploy a payload.
Citation and inspiration: