Welcome to the Hacker House Hands On Hacking DNS theory
module.
We're now going to talk about DNS, what DNS is,
and how it relates to an attacker.
So the current vantage point for you
as the adversary is to be thinking
from the external perspective.
You are outside a company.
You're trying to work your way in.
You're doing your open source intelligence.
Most companies, almost every company out there,
is using the internet.
Will make use of domains or have a domain name, something
that you use like www.company.com or whatever.
So this is about DNS and how we can leverage
DNS to identify information about our targets
and take advantage of it.
So first, what is DNS?
Well, DNS is the domain name system.
It's a service and system used to translate IP addresses
into readable human domains or mnemonics domain names
that are easy to read.
Things like example.org could have the address
193.184.something.
And the reverse of that, 93.184, has the host name example.org,
the idea of looking up an IP to its domain reverse DNS.
And domains-- this company, example.org, is a zone.
It's defined as a zone.
And inside of that zone is a resource record.
So try to think of it a little bit like a database.
You've got a database that you can
query that has different kinds of records inside of it.
And these are described as zones.
They're actually these flat files,
but these records have different types of purposes.
Each of these records are stored in their resource records.
So it might be records for looking up
the IP to the domain, such as the A record.
You look up the domain to the IP, an A record.
Others could be something like a service record.
And each of these different records,
they have a different purpose.
So DNS is commonly, and mostly, used over TCP and UDP ports 53,
primarily over UDP ports 53.
And we'll get into why it uses both in a moment.
When we're talking about DNS, there's
a lot of different kinds of software over the years
that's been written.
But overwhelmingly, one of the most widely used pieces
of DNS software is something called Berkeley Internet Name
Domain, or BIND.
It was originally created at the University of California
as a project known as JEEVES.
And it exists in various provisions.
There's been versions BIND4, BIND8, BIND9.
The newer version is BIND10, which is nicknamed as Bundy.
And BIND has been considered to be fairly critical internet
code.
It's quite critical code, because it powers this DNS
system, which we've come to rely upon for how we access the web
and how we remember example.org or company.com.
So it became quite critical internet code.
And because of that, there was a very big push
after around 1999 and 2000, when it
was discovered that people were actually hacking
into the root name servers.
There was a big push to secure this code.
A lot of auditing went, and a lot of the code
was read and reviewed and error handling and others
added to try and reduce the severity of vulnerabilities
inside of BIND.
So it's considered internet critical code.
It definitely will make your eyes
bleed if you try to read it, particularly
some of the older versions.
It's very, very hard to follow.
But just like all software, there's
been numerous versions of it.
And it's been found to contain bugs.
There have been bugs.
There have been vulnerabilities.
There have been mistakes made.
Alternatively, there's not just BIND.
There's other pieces of software.
We have DJBDNS, PowerDNS, MaraDNS.
All kinds of different--
DNSmasq, et cetera.
And these are widely-used software packages
that also provide DNS services or DNS
servers and clients, et cetera.
So DNSmasq.
Berkeley Internet Name Domain, or BIND.
When we think about DNS, then we think about example.org that
example.org is part of a tree-like hierarchical
structure, which is how DNS is constructed so that we can use
these top-level domains, which are defined in a tree-like
structure, for things like .co.uk.
And then these zones are described inside
of these name servers that can allow you
to basically traverse from the root name servers
down a tree to try and find out who
is responsible for a particular domain
to do this reverse lookup as well.
Recursive lookup.
Look back up that tree to find the next entry.
So it's a recursive tree-like structure
that you can traverse.
And you can also download the root zone files.
If you have a look, you can actually
download them from this FTP site there and see who's responsible
and which servers and things are actually available.
These are the actual zone files that are running there.
The root name servers listed here, 13 of them, I believe.
So you've got the different IP addresses and the host
names of the name servers.
And you can actually see whereabouts they are located
and who is responsible for them.
And we can see overwhelmingly, actually,
that the United States is pretty much largely
in control of the internet.
largely because it has such a monopoly on these root name
servers.
As you can see, they're owned predominately
by American based companies.
So America pretty much holds the keys
to the internet at the moment.
So when it comes to DNS resource records,
these are the different kinds of records
that can be stored inside of a zone file.
So if you think of this like a zone, like a database file,
we can actually query these records.
It's actually just a flat file.
But they have different resource records stored inside of them.
And these are an example of some of the records.
You would have an A record, which points to an IP version 4
address, an AAAA record, which points to an IP version 6
address, a C name record, which is just an alias.
An MX record, which is the Mail Exchanger
used for identifying where email is delivered for a domain,
and we'll come to that in a moment.
A Name Server, which identifies who is responsible
for a particular zone or a Start of Authority record,
which is who's responsible for the zone.
And a Name Server, which also can respond
to the records in the zone.
You'd have things like a SRV record
for information on services.
If you ever launched a chat program
like Office Communicator, and it says,
what company do you work at?
And you put mycompany.com, and then
it automatically starts trying to log in,
it's probably doing that through service records.
It's looking up in DNS.
It's asking DNS, where is the office communicator service?
And it's getting that back.
And obviously, that's advantageous to us
as attackers, because we could ask, where is the communicator
service?
And learn details of where are end
points we can communicate with?
So DNS records, resource records.
We want to dig through those and find information in them.
TXT records are human or machine readable text.
And you often find that these have
been used to add additional security features
and enhancements to other technologies
through these TXT records.
And we'll look at some of those.
The concept of a DNS Resolver Cache is important now.
Because when you've got your computer--
and if you think about it, zone files
are these little databases that are returning records.
If you've got a database and your local machine,
it actually contains all your recently requested DNS records.
It's called your DNS Resolver Cache.
And each of your workstations or laptops
will have this DNS Resolver Cache in there.
And even sometimes, the DNS Name Servers
themselves will contain a Cache or allow you to look it up.
Or will be used as Cache-only name servers.
And these are often complemented with things like /etc/hosts
files, which have static entries for different domains.
So the way this works is, if you look up a website like
example.org, and the DNS server comes back and says, oh,
example.org is--
A record is here, it'll also have a time-to-live value.
This time-to-live value determines
how long your computer should keep
that information in the Cache.
So instead of every time you go to example.org's home page,
you're not looking up example.org every time.
You look it up once, store in your Cache,
and after a day or so, when your time-to-live has expired,
you ask the network again, where is example.org?
And it will cache it there.
So Caching DNS servers are commonly used in home networks.
So if you think about your network at home,
probably you've been provided a little box by your ISP.
Inside of there is probably a Caching-only,
non-authoritative domain name server that will look up--
it will go and query the internet,
store information in its cache, and then return that back
to you.
It's not authoritive for any domains,
as in, it doesn't host any domain zone files.
You don't query anything from it other than using it to look up
information in its cache.
If you think about that, if I was to query that little home
rooter of yours and say, well, query example.org
and turn off the recursive bit so that it doesn't ask
for the next DNS entry in the tree,
it would actually just get the information
from the local cache.
And if it knew about that entry, it would return it back to me
and say, example.org is here.
And that would tell me that this target has browsed example.org.
So somebody connected to your home network
could actually work out every website
you've browsed just by querying the rooter in your home.
So this is cache snooping.
It's a type of attack that lets you
learn browsing habits, lets you learn things about a target.
What I like to use it for is learning what kind of software
maybe a target's using.
I like to look up update servers of things like Java,
lookup update services of Flash and things like that,
and see whether or not my target has been making
use of these third-party services
before I try to attack their system.
So cache snooping attacks and how you can use them.
As an example here, this is an example of a DNS query
as it goes over the wire.
If you've not seen the output of this,
it's from a tool called Wireshark.
But this is an example of a DNS query.
So we can see here some IP-related information
and destination port related to the DNS query
from this server to that server to that destination.
And we can see that it's a standard query that
contains different bits.
And these flags, you can see, it's got a recursion bit set.
And that recursion bit tells it to walk
that tree-like structure for the answer.
And the question it's asking is-- here
you can see the resource records.
It's got one question.
And it's query is, tell me what the IP address of the NSA.gov
website is.
What is the NationalSecurityAgency.gov's IP
address?
And that's what it's doing there.
It's just making a request to try and find out,
what is that IP address from a server?
And what's important here to remember
is we've got a source port, and we have here also there's
transaction ID and various of the flags and things.
And if we were then to look at the packet response,
this is the information that's been returned back
from the server.
We can see that a domain name system has responded.
It's given the time that it's taken to respond.
But also here, we've got the authority resource
records, which is that the DNS server didn't know about it,
but it knew the query that you were asking for needed
the authoritive name server.
So it didn't know the answer, but it
could tell you to look the answer up
on this authoritative name server, NS1.NSA.gov.
It didn't have a record for NSA.gov,
but it had an authoritative name server.
So perhaps there's no record for that one there.
But just as an example, it's given that.
It's returned back.
It's found something, and it's given you
the star of authority, which is important.
So what goes in a DNS hacking tool box?
What tools do we actually use for hacking on DNS?
So we have tools like dig, nslookup.
These are two query tools that you
can use for looking up information in those data
stores.
And it's information in those zone
files that you can then query using those two tools.
Things like dnsrecon, dsnenum, these
are different reconnaissance and enumeration scripts
that we can use to identify different vulnerabilities
and information in those systems.
Fierce is a DNS scanning utility.
And there are others there as well.
Host, dnsspoof, dsniff, hping3, scapy.
And again, nmap and metasploit.
We'll come across these tools fairly frequently.
But these are tools as well that we
could use for learning exploits, packet injection,
or indeed doing some kind of spoofing attack.
As an example, this is how to make
use of some of those tools.
So we could use dig.
Dig is a way-- or nslookup--
to query a DNS resource record.
So let's say we wanted to run a query at a particular name
server.
We would use dig @ the nameserver, the type
of resource record we want, and then the domain.
So if we were interested in learning which computers
are responsible for email at the National Security Agency,
we would do dig @ the IP address of the server we're querying.
Query the MX record type for the NSA.gov,
and we would then get a response for which servers
are responsible for handling email at that address.
As an alternative, you could do the same query type.
You could do set querytype equals ANY,
and request any resource records from the server using something
like nslookup.
Two tools that do effectively the same job.
And it's down to your preference, really.
I quite like dig.
Some people prefer nslookup.
Information leaks in DNS.
So when you're using these tools to query servers,
you're querying DNS resource records.
You're learning information about a network
and how it is put together from these zone files.
You can also query the software for different types of version
and information that they might hold,
which can include what software is running and powering
the DNS configuration.
And this is due to something called CHAOSNET.
Now CHAOSNET is actually a legacy network type
defined in DNS.
The CHAOS subclass existed pre-internet protocol,
pre-modern internet.
And it's actually a very legacy protocol
from the early days of the internet,
around the ARPANET era.
And this CHAOS subnet class is actually
now used by software like BIND to keep
details of the software.
It just keeps information inside of this subnet class that's
no longer used.
It's kind of depreciative.
So you can actually query--
instead of just querying DNS for internet addresses,
you could query it for this subclass of CHAOS addresses
and learn information about the DNS software.
So you can learn things like the host name, version information,
authors, and some of the IDs.
So you can actually get information like internal IP
information and things from it.
So dig @ IP address, chaos to determine
that you're querying the CHAOS class or the CHAOS net,
and then the version.bind and a TXT record
to return back that text-based response.
It would actually tell you what software
was powering that DNS system.
And then you can profile that for vulnerabilities.
And we'll do some of that in the practical.
Another thing that we should be aware of
is this thing called a zone transfer.
So if you have a couple of DNS servers,
let's say example.org and mycompany.com, these two
websites, they have resources.
And let's say that they want to transfer one server.
They've switched hosting provider,
and mycompany.com wants to move to example.org's server,
because they get a better service level agreement.
And the companies again, are going to swap.
They're going to transfer this zone records.
They're going to copy them over.
Now because UDP, user datagram protocol,
which is usually how DNS works, is using UDP most commonly--
because it's not connection orientated,
because it's not reliable, it's not a good way
to transfer something like a full zone
file between two servers.
So DNS would then use TCP port 53
to allow the two servers to communicate that information.
So it was in a connection orientated protocol,
thus making it more stable and more secure.
Sorry, not more secure.
More reliable.
Less likely to be error prone and cause corruption.
So it makes use of the transfer record
to request all of the records for a zone.
So if it just tries to request this resource record called
transfer, or AXFR, it will try to request
all of the records for a zone.
And obviously, if that's permitted,
it can expose internal network configuration,
sensitive information, and you can
use those two tools we discussed to get that information
from the server.
And one thing I also wanted to cover
that I didn't mention before-- when we looked at that DNS
query, an important thing to remember
is that destination port from that client query
and that transaction ID are the same from the original query.
I just want you to keep that in the back of your mind,
that the source port on the transaction
ID for the query and the response
have to be identical for it to be valid.
Because that's UDP.
It's not using TCP.
So those two numbers are how it distinguishes the query.
So looking back at this zone transfer request,
another thing you might be able to do--
if you can't see TCP port 53 on a DNS server--
and there's no point checking a DNS server for zone transfers
if it doesn't have TCP port 53, because it
won't be able to do the transfer even if it was supported.
And so what you want to do is, make
sure that it supports TCP port 53 before trying that attack.
And then what you would do with that is,
you could host enumeration attacks.
If you're not able to just transfer the whole zone file,
which would be amazing, and sometimes it
does happen, so worth checking for.
In fact, there's been leaks of North Korea's entire top level
domains due to misconfigurations of their DNS servers,
which were obtained by doing these kinds of queries.
So host enumeration attacks is another attack
that you can use that allows you to use predictable naming
conventions.
And that is, we as people, we like easy things to remember.
We like words like firewall and web server and www and VPN.
So we do things like firewall.target.com
or VPN.company.com or www.company.com.
And because we pick these common names
for hosts and from network engineers
and common engineering backgrounds,
we can actually try to brute force
and just guess what these are using probe tools.
So we do some enumeration attacks
just by guessing what the DNS might
be for a particular system and target.
Another thing that you can do with DNS
and is particularly popular and prevalent
with hacktivist groups and others,
is to use traffic amplification.
So it's important now to understand how this works.
If you are an attacker, and you're using UDP,
and you spoof a UDP packet to a DNS server that's
on the internet that allows anyone
to query it to make it look up other requests,
and it can do recursive lookups, and it can query elsewhere,
it's an open DNS resolver.
And if you send a spoof packet to that DNS resolver
and spoof the IP address, that DNS server
will then respond to the IP address
that it thinks has sent the UDP query, which
is of course, not you.
And that would be your target, your destination.
And what would happen is, they send a small amount of traffic
to the DNS server.
And because the response that will come back from the DNS
server-- they get it to come back with a big amount
of data--
will cause the response to go to the victim.
It will cause an amplification.
And then what they do is, they basically find as many servers
as they can that allow this behavior.
And then they send as much traffic at them
as they can to cause the systems to overwhelm the intended
victims.
And this is known as a DNS amplification
attack, or a traffic amplification attack.
Commonly used by hactivist groups
and political orientated attackers
or people who are seeking to cause
hacktivist-related activity.
Because it's very effective at bringing systems offline.
Traffic amplification attacks.
Widely used to perform DDoS attacks, otherwise
known as a DNS Smurf attack.
Not the lovable blue characters, but yes, named after them.
So the DNS Smurf attack.
Nmap and metasploit contain various scripts
that allow you to test amplification
and test for this kind of behavior and try to leverage
it.
And you can see there, you've got
domain name system at 26 bytes.
And then getting a response back of 251
bytes using one of these probes.
And then in metasploit, we actually
see that you've got four times the traffic amplification.
So you can effectively use this to boost a weak internet signal
and overpower somebody else and knock them
off their online video game, et cetera.
DNS spoofing, which is what we briefly were touching on there,
is an attacker who can observe DNS requests.
So if I see your computer sending a UDP DNS request,
then I could actually just reply with a forged response.
Because as long as I've got the transaction ID, and as
long as I've got that source port, which
I can get if I see the packet, and then it's
just a simple case of who replies first.
Because I could then just send a spoof packet back.
And if mine is responded to by the computer first,
then I would be the one stored in the Cache.
And you can also try to do that blind.
You could actually just try to guess
what those two numbers were by just sending a blind responses
all the time.
Are they looking up Google?
And trying to flood them.
But because you would have to get
two numbers right at exactly the same time as the lookup,
it would be quite difficult to just blind brute force
those magic numbers and spoof a DNS response.
It's because UDP is not connection orientated,
because it's not using a full three-way handshake,
because it's just a datagram.
It's a broadcast.
It's not a connection orientated protocol.
It doesn't have any of that nicety to it.
So the attacker only needs to know the DNS request, UDP
source port, and the transaction ID
to basically spoof a response.
So with those two bits of information,
you can spoof a response.
It's implemented by a tool called dnsspoof
by a very talented hacker called Dug Song.
And you can actually go and download his toolkit, dnsspoof.
And actually, you can use that on a line.
Just run it, and it will do this action for you.
It will also respond and make everyone
think you are Google.com.
Another attack you could do is something called a Cache
Poisoning attack.
The reverse of a Cache snooping attack
is actually trying to poison the DNS Cache that
could cause the clients of that DNS server to be impacted.
And if you ever recall in 2008, there
was a big news story around the internet being broken.
And this was because of a security researcher
called Dan Kaminsky, who found CVE-2008-1447, which
is the so-called bailiwick attack, which
is a Cache Poisoning attack.
And the way that this works was, the attacker
would send many DNS requests to a server
to cause it to do lookups on a domain.
I would query DNS server to make it look up 1.victim.com.
The DNS server would go to try and find out,
what is the answer to 1.victim.com?
And in the response, it would get the answer
for victim.com's start of authority.
And I can force it to look it up again by doing 2.victim,com,
3.victim.com, et cetera.
And what you would then do is actually try
to flood the server.
And because the internet's got faster,
because we could connect faster, we could send more information
quickly, these two numbers were considered
sufficient and difficult to guess.
But because you could use this 1.victim.2, 2.victim.2,
3.victim.com, until you got those two numbers correct,
that would then cause the server to cache an incorrect start
of authority.
It would make your DNS server responsible for victim.com's
DNS requests whenever anyone looked it up in future.
So you could actually try and do this Cache Poisoning
and actually poison the DNS server's cache
so that anyone looking up that DNS server
would then get redirected back to yourself.
So a DNS Cache Snooping attack is the opposite
of this, where you are using a timing
measurement on the same cache.
Instead of poisoning the cache by putting
a bad entry in there, you would use a timing attack.
Or you would request non-recursive information
so you don't get it to woke up the next entry.
Just look up the Cache and see whether information
exists in that Cache.
A Cache Snooping attack.
And again, we would for things like updates
or update.adobe.com or update.java.com or something
like that.
Try and find out what software they might use.
So again, DNS Cache Poisoning.
Massively, server Cache Poisoning attacks
improved by CVE-2008-1447.
And a big story, as the internet was broken.
Here's a brief history of various useful DNS exploits.
You can see around 1999 to 2001, there
were a couple of vulnerabilities,
which were kind of awesome and a lot of fun.
And it was found out that these exploits
were being used to compromise the root name servers.
And it was quite an alarm for everybody,
as unknown computer hackers were able to redirect microsoft.com
to any website they wanted.
People were understandably concerned
that the name servers had been compromised.
So there was a big push then on security of them.
And that's why we have this gap, really,
from around the 2000 periods.
There was less interesting bugs, because a lot of things
was fixed silently, behind closed doors.
There was a lot of big push, a lot
of big government, a lot of big bucks
spent trying to secure these bits of software.
And again, you have know the DNS Cache Poisoning bug
or bailiwick attacked, or bailiwicked attack,
that can be used to poison the DNS Cache,
improving your spoofing.
And you've got there also some denial of service attacks.
There was a big vulnerability, a glibc vulnerability, that
impacted a lot of DNS lookups.
And then again, more later vulnerabilities.
A lot of denial of service attacks.
And in fact, DNS is one of the few things
that I would actually ever consider denial of service
to be very relevant on, because if you can crash a DNS server,
you're taking out the internet, effectively, for a company.
So if their domain name server crashes and no longer
functions, email won't work.
Web browsing won't work.
It will drive productivity down, and it will cause harm
to the organization, and indeed, probably
financial implications as well.
So you need to understand the denial of service attacks.
Very important to find out if a server is vulnerable to them.
Not necessarily to exploit it.
Just because when they are at risk,
they can have quite a detrimental effect.
As an example, if you were to exploit
one of those vulnerabilities, you would see here,
there is an example of a stack trace or an error.
You can see, there's some assertion.
If you were a system administrator looking
as someone hacked my DNS server, you
might see things like this in the error log
when exploits and things are run against it.
So this is just an example of what kind of thing
you might want to look for if you're reviewing such log
files.
While there's been not too many code execution vulnerabilities,
there have been a number of them recently.
There's been one or two in dnsmasq.
And there has been some increase in recent vulnerabilities
in that.
However, historically, we haven't had too many good code
execution bugs in name server technology for some time.
So DNS-SEC.
Once everybody realized that DNS was broken,
engineers got together, much smarter engineers than I,
and they decided we will harden DNS.
They decided to create something called DNS-SEC, which
provides authentication and not encryption,
which is most commonly construed, of the DNS protocol.
And that what that does is it uses public key infrastructure,
adds a new resource record for supporting
public key infrastructure, and then these records
are signed with public keys.
And it's implemented in these RFCs.
RFC-2535, and then these various--
4033, 4034, and 4035, which describe it
in much more detail.
As an example, it adds two new resource records,
the DNS key record and the RRSIG record.
And these two records, of course,
when they were added to DNS servers,
it was found that some of them implemented them badly
and there were vulnerabilities looking up these new resource
records.
So every time somebody introduces new features,
they could also introduce new bugs.
So it's worth looking at new features
as they're put into browsers, if that's your bug hunting
adventure.
And so yes.
RRSIG and DNS key resource records added to DNS.
RFC-3833 is actually a really interesting RFC.
And if you don't want to read through all
the RFCs in the world, I don't blame you.
Some of them are quite dull.
But if you do want to read one in particular I found
interesting, have a read through RFC-3833,
because it documents all known DNS attacks
and preventative steps that DNS-SEC was intending
to step and implement.
So when they implemented DNS-SEC, they
got some smart engineers together and they said,
what are all the problems in DNS?
And they said, RFC-3833.
So RFC-3833 will document all of the known problems in DNS.
And it's worth having a read through.
So worth having a look through that one.
So Fuzzing DNS and DNS-SEC.
Fuzzing is a method for finding new vulnerabilities.
So again, when DNS-SEC was pushed out
and people started to implement this in software,
a lot of people fuzzed those new resource
records and in fact, found a number of vulnerabilities.
So fuzzing is a way of creating a pseudo-random input
to something, a pseudo-random input to a character system.
And do this kind of DNS queries and try and malform
those queries to result in things like denial of service
conditions and possibly more.
And most DNS implementations today have been heavily fuzzed.
So I only tend to use this on custom DNS services.
Or if I'm querying an organization and their DNS
servers, and I find that those DNS servers have my first DNS
software, then I might use fuzzing to probe that system
and see if it's got any unknown vulnerabilities.
And you could do that with nmap, or you
could do that with metasploit to actually run
these kind of probes and fuzzing against these services.
And then I would not recommend doing
it live against the client's DNS implementation
without their prior knowledge.
Because if they do crash and there
is some vulnerability found, it could, of course,
take down their capability to use the internet, which
would upset them.
But using these kinds of fuzzes, vulnerabilities
were found in various DNS software.
So it's always important, if you see an unusual DNS software
package, it may be worth running these against them
to see if it handles different kinds of resource queries
correctly.
So that brings us to the conclusion
of the theory for this module.
I'm now going to walk through the practical demonstration
of the Hands On Hacking DNS server.
And you're going to need a couple of files from this.
You're going to need to make sure you've got your resource
guides and your reference books to be able to download tools
from.
And you're also going to need to download our name server
ISO to be able to complete the practical elements
of this module.
So you're going to need hh-nameserver's ISO,
and you're going to need to have access
to your references and reference guides.
So that concludes the theory module for DNS,
and thank you for listening.