[ELECTRONIC BEEPING AND BUZZING]
[MUSIC PLAYING]
Welcome to the Hacker House Hands-On Hacking DNS Practical
module.
We're now going to walk through some
of the practical steps that are necessary for taking advantage
of vulnerabilities in DNS servers,
and we're going to look at how to target a DNS server as it
would appear in the wild.
So what you've got here is, hopefully, you've
gone through the Getting Started guide and Getting Started video
and you have set up a host-only network,
and you have your Kali Linux, or similar, VM
with a host-only adapter.
And I'm now going to click Play on my Hacker House lab.
If you review your lab, just make sure
that you've got the correct ISO set.
Once my lab is booted up, should be presented
with an IP address that can be used to probe
and see whether that server is alive and functioning.
You can see that mine is on 192.168.56.3.
Don't worry if yours is different.
And what I do is make sure that we can actually
ping that address.
So first things first, when we're targeting new systems
and servers we'd obviously want to do something like Nmap
to actually query against a server.
So I'm going to do a very basic Nmap port scan.
It's quite likely we would have learned
about the details of where a DNS server was
during our open source intelligence phase,
because we could query DNS records,
we could query DNS servers and find out
where our name server is.
But as an example here, we've done a quick port scan,
and what we can see is we can see that this is a name server.
It has a single open CCP port, which is CCP port 53.
That gives me the impression of a footprint
of a very standard name server.
So that's just a common footprint
that you would see if you were coming
across something that was DNS, you'd see this 53 open.
So that's an Nmap against the IP address like that.
Of course, DNS is typically run over UDP.
So if you wanted to scan via UDP,
you would also use Nmap minus SU,
and that will just limit the number
of ports it will scan to see whether or not
the ports are open there.
So you can see now when I've done Nmap minus SU, I've
told Nmap to do a UDP scan, provided
the port numbers of 53 and 123 are common UDP services.
And we can see, again, it says open for UDP on 53.
So that's an example of a DNS server's footprint.
So we can see that this server might be a DNS server, just
by port scanning it, or we've learned the location of the DNS
server by querying it.
So how would we query it?
OK.
Well, let's say I was to do NS lookup.
I could do set query type equals start of authority NSA.gov,
and I can actually look up and see what is the authority name
server for the NSA.gov.
So let me just do set query type equals MX, and then do NSA.gov.
And we can see here we've got the MX record for NSA.gov.
If I was to do a set query type equals start of authority
for Hacker.House, we can see here
that we've got the start of authority record
for Hacker House.
This ns1.live.dns, for instance, we
could query that, and that would be the domain
server responsible for DNS for that zone
file for that Hacker.House zone, for instance.
So we can see here we can query for the DNS service
just by querying DNS itself, and we can also look
at different kinds of tools.
So if we were to query a DNS server once we've
learned the location of one, and in our example,
we're going to ensure that we run
our attacks against the labs in our host-only environment,
because we don't want to send packets across the internet
and start trying to hack other people's DNS servers because we
don't want to cause any complications or problems.
So we're going to do Dig@192.56.3 and query
what information we can get about the server.
So if I was to do Dig@any, and then
I'll do NSA.gov as an example.
So here we can say I've done a DNS query using Dig,
which is a DNS querying tool.
I've queried this server.
I've asked it for the resource record
of type any, so I'm saying, give me any resource
records that you can for the domain NSA.gov.
And what we can see here is that the server has responded,
it's given us the start of authority record.
It says, hey, the NSA server, NS1.NSA.gov
is the start of authority, it's responsible for the zone file
NS1.NSA.gov.
These two name servers are responsible for handling
requests for resources in that known zone file.
MX records-- here we can see we've got two MX records.
These are servers that are responsible for looking up
email addresses and handling information related to email.
So looking at these different other responses
down here in the additional section,
we can see that a number of A records
have also been returned that correspond back
to these servers that we've just identified.
So we've identified the start of authority, the name servers,
and the MX servers just by querying a DNS server
and asking it for any records that we had around the NSA.gov.
That's an example of how you could
use Dig to look up a query against a particular server.
As an example here, I'll do Dig at the IP address again.
And we can see for an A record now,
we're looking up www.NSA.gov.
We can see here in the answer section
we've got some information, like the CNAME fedora.NSA.gov,
which then maps back to an A record, so it's using an alias.
The alias then maps back to this IP address here.
So this is how DNS can be used to look up information, look up
resource records, look up information inside of that zone
file we discussed.
So another thing that we could use DNS
for is to begin querying information of that chaos net
subclass we mentioned.
So typing chaos then version.BIND
and then supplying text will query the DNS server,
look up the chaos net subclass, query the version information,
and try to return what information that
is in a text record.
And I actually provided the wrong IP, so it's 192.168.56.3.
And I've looked at my text record here for chaos net,
and you can see that the response has come back.
And instead of it giving an internet address or an IN
address, it's come back with a chaos record of a text subclass
version 9.8.1.
So you can actually see what version of BIND
it is based on the version number that's
returned inside of there.
So when we've got a version number for a piece of software
I like to make a note of it, and I'll say,
OK, well, I'm doing DNS, so I'll do DNS server BIND 9.8.1.
I'll just make notes of things as I go along
in a file called Notes, because maybe that might
be useful to me later on.
So we know a version of the DNS server
by querying that chaos net subclass.
As an example, what other things you could query from there,
and these are little lesser known trick,
is you can actually query for hostname.BIND--
apologies, I appear to have pasted unwanted characters
onto the screen, and again--
chaos hostname.BIND, and that would actually
return back to the internal hostname of the server.
So we can see here that this server's called, imaginatively,
name server 01.
So you can actually query back, what's
the local hostname of the server?
And other things you can actually query as well
include authors.BIND, which is the number
of the people of the individuals who
are involved in authoring that particular piece of software.
So, in fact, even if somebody suppresses the version
information, you could look up which authors were involved
in that particular version of BIND,
and then try to work out which version of BIND
it is based on when these programmers joined or left
the project.
So you can also get other bits of information there.
Another thing you can also do is do ID.BIND, learn
a little bit of extra information from there.
But nothing in this query.
So don't forget, you can query chaos net records,
it's not just internet addresses.
You may be able to query a hidden subnet
classing or a network class classification chaos
net or similar.
So always have a look through code,
see if there's any extra resource
records or kinds of classes that you
could query that may contain information leaks.
Another thing that we saw on this DNS server,
if we look back at its ports scan output,
we saw that it had TCP port 53 open.
And we know that when we see TCP port 53 open,
that means that that server may support zone transfers
because I can actually make use of the required ports
to conduct the transfer from the DNS server.
So what I would do then is to Dig
at the IP address of the server, do transfer,
and then I'll just query it for NSA.gov.
And although this isn't a reality,
here is an example of a name server--
a DNS zone transfer being done, and it's
returning back now all of these systems and inputs, records
from the NSA.
We can see, actually, the resource
records that were installed into that zone file
or were created into that zone file.
So we can see, for instance, the start of authority record,
and here we can see additional text records.
So this is unusual, the black sparrow password.
I've seen things like this, where
people have used text records to make human readable notes just
for their own memory or to store some information in a zone
record.
So finding things like this, this here,
this text record is an example of a Sender Policy Framework,
which is a machine parsable record used for determining who
can and cannot send email through a mail server.
You've got all of these other A records.
Again, that's an extension of a text record--
C name, start of authority, knock twice to enter,
and as we can see here, Snowden.NSA.gov, sigint,
prison.NSA.gov, keyscore.NSA.gov, et
cetera, all of these different systems that maybe
in that network.
So that's an example of a DNS zone transfer request.
Remember, it operates over TCP ports
53 and the types of information you
would see there are IP addresses, potentially
internal network configuration.
A lot of these IP addresses would
be internal and not something that you
would hope to have exposed to the internet.
But, however, if you couldn't do a zone transfer,
there are alternatives to you.
You could actually use something like Fierce--
I think Fierce supports it.
You can actually--
Fierce-- I'm going to clear my clipboard as well.
So Fierce minus minus help.
So we're going to use the Fierce command.
So if you do Fierce minus minus help,
you'll actually get the arguments
that you can use to supply to Fierce.
So Fierce will take, for instance,
a DNS server as an example and it will actually
try and do a number of these probes for you.
So if I was to do Fierce and then DNS server,
the IP address of the server I'm targeting,
and then I'll do NSA.gov, and then
I'll go minus DNS-- sorry-- to give it the NSA.gov,
and what that'll do is it'll actually
query against that DNS server, try to work out
what those DNS servers are.
And interestingly, it will get them from the web interface
and then it will actually try and do
a zone transfer against those DNS servers,
and then it will also check for wildcard DNSs.
And then after that, it will do some brute forcing
and it will actually try to look up
if it can find any IPs for common hostname.
So, for instance, x key score sigint VPN web mail.
You see it's just done a brute force
attack to try and find these.
Another tool that you could use is tool called Host.
Host will take IP addresses and reverse them back.
So host.west to the web address there.
And then you could, of course, look up those IP addresses
in your open source intelligence and query it.
In fact, a lot of open source intelligence
will also encompass a DNS review because there'll
be so many systems linked together from DNS and mapping
that this would be part of that exercise as well.
But here we've got-- you can see various bits of information
from the IPs that we found.
We were able to do that zone transfer.
We did some DNS brute forcing.
And we're not going to do one more.
We'll look at the traffic amplification attacks
and some other elements of the attack as well.
And I'll just see if we've got DNS recon, for instance,
is another tool we could use.
And DNS recon is a DNS reconnaissance tool
that can be used for doing--
similar to Fierce, we'd supply it with a domain name
and then we'd give it a name server as an IP address,
and it does very similar concept where it'll actually
go and look up the files, it will look up
for the name servers, and it will
try to do the DNS zone transfer and obtain as much information
as it can from a DNS server.
So that's an example of DNS recon.
There's other tools, such as dnsenum.
And for some reason, I'm going to have to exit this terminal
and restart this terminal-- dnsenum minus minus help.
There we go.
dnsenum read subdomains from this file to brute force.
So this is a tool for doing the brute force attacks.
So we do dnsenum DNS server, provide
it the IP address of the server that you
want to do your brute force attacks against.
We've got 56.3.
Use this DNS server.
And then the brute force switch minus F
to provide it with a file of subnames to brute force,
and that would be list of files or domain names.
I'll put echo VPN DNS.text.
So dnsenum minus minus DNS server, the IP address
of the server that you want to target minus F DNS.text,
and then the domain name.
And it would actually then try and do that kind of DNS zone
transfer again, do the similar--
automate that process for you, undo that brute forcing,
try and guess those common mnemonics
that might be being used on the network.
So those are examples of common DNS query tools.
We've used DNS now to do host enumeration
attacks, query information, query common resource records.
Now what we want to do is see if we can misuse that DNS server.
So when we can use a DNS server to actually make
queries and use it to look up external resources,
one of the other things we would do
is then try and probe it, see if there's
any common misconfigurations or weaknesses
that we could maybe use.
And a way we might do that is by using a tool like Metasploit.
We're going to use Metasploit quite
a lot throughout this course, so this
is the first time we use it.
But if you simply type MSF console in Kali,
it will effectively load up the Metasploit console,
which will give you a unified framework
interface for interacting with various kinds
of exploit scripts.
Very similar to how the recon ng framework worked
from the previous module.
So as you can see here, it's booted up.
And if your prompt doesn't look like mine, don't worry.
There's various msf console rc set options
that are specified here that allow
me to keep track of things, like timestamps,
and turns on logging and various other options
when I start Metasploit.
The reason I do that is I like to be accountable
when I'm targeting systems.
So I keep a very detailed, itemized recording
of most of my actions when I'm targeting any kind of system
or network, so it allows me to distinguish
between my activity and benign activity
and those of a legitimate attacker.
If anybody was to query what I was doing Tuesday at 10
past 3:00, I'd be able to say, oh,
I was running these commands against this server.
So it's a way of me giving accountability for my actions
on a network as well.
So I just turn on all these various options
every time I run it.
So again, when you're in Metasploit,
you've got all the various common commands
that we saw earlier, this help output, which
will give you an example of how to use
some of those various commands.
And once you've got the things like help
and various other options in there,
you could do show modules, list through all
the various modules--
or show exploits, sorry, to list out
various exploits or various things
that you might want to use within Metasploit.
So simply typing show exploits would list all of the exploits
that it might know about, and obviously there's
going to be quite a lot there.
Another thing I would do is not just
using the Metasploit framework, we
could also download from our stuff directory
from stuff a tool called nse discover.py.
This nsc discover.py is on static.Hacker.House/stuff.
nsc discover.py is a little utility
for working with Nmap scripts.
So Nmap contains a nice little scripting engine.
So as you're doing your port scans
and you're using enumeration, you
can actually use Nmap as a scriptable engine
to conduct some kind of fingerprinting and probing
and similar for you.
And if you were to simply just run Python nsc discover.py,
you'd actually find that-- or just
list all of the Nmap discovery scripts that it can use,
allow you to browse through those scripts
and select ones which are relevant to your target
platform.
So for an example, you could scroll down and look
for things like DNS, and here you
can see there are various scripts that it supports
running, including cache snoop, check zone, DNS fuzz,
DNS recursion, various service enumeration.
There's various DNS probes that we could run along
with Nmap to see what kind of information we might get back.
One of those we could see is, perhaps
we're doing things like traffic amplification
or similar kinds of probing.
So you can see there recursion, service discovery, DNS updates,
and brute force.
So for instance, you could use this one to try
and brute force DNS.
So you do that by simply supplying
the name of the script.
In fact, if you wanted to run every DNS script
against the target, you could simply do with DNS star,
and then tell it to actually run the DNS
probes against that server once it's come back.
So that's an example of just running
Nmap with one of the scripts.
And I've told it to run all matching DNS scripts
against that DNS server.
I wouldn't really recommend you do that in the wild
because you'd be running a lot of unnecessary queries,
but that's just an example of how you would do that.
So going back to here, we can now see our Metasploit module,
and we're going to do a search now for DNS_amp.
And this DNS_amp, you can see it says it's a DNS amplification
scanner.
And what we can do is use this auxiliary module,
it's an extra module, not part of the exploit framework,
that's designed to do a specific task.
So if we were to type use in the module name,
you can see the prompt has now changed
to show us that we've selected that module,
and we can now do various things, including show info.
And show info will give us various bits of information.
We can see it'll give us the name--
very similar to the way that we saw in the previous recon ng
framework, it's given us the name of the module,
it's given us a ranking, which we'll explain later,
and then it's given us various other options,
the different options that need to be set for this module
to work.
So the required is the ones that have to be set for this module
to function.
So we can see here, you've got things like filter
is not required.
And if you were to just type show options,
it will actually just show you the options
that are needed for the module.
So we can see here any required options that are specified
and the one that's missing is the r host option,
so we can actually provide r host
and see whether that would then satisfy all of the arguments
necessary.
And you see that, indeed, all of the arguments that say yes
are specified.
And if you were to look at the description,
you can see here it says it will do recursive name
lookups, which can be used in an amplification
attack against a third party.
And I will set the domain name to NSA.gov
to ensure that we get the correct query back,
as this query response on its own
may not work on our lab environment.
So if I now send that exploit to the server
by simply typing exploit or run, you
can see that it sends DNS probes,
and then it's actually responded back to the probe
and worked out how much amplification has come back
from that DNS server.
So this particular DNS server is also a good candidate for us
to use in a DNS Smurf attack.
So we could actually try to use a DNS attack
against that particular server.
And the way that we could do that
is actually to download another tool.
If we were to go to our stuff directory--
go to stuff.Hacker.House/stuff-- oh, static, sorry,
.Hacker.House/stuff, you'll see that there's various modules
in here that we can use.
And one of the tools I'm going to use
is DNS doctor dos, a tool by a friend
of mine called Nop Tricks.
And this tool allows you to use DNS servers.
You provide them in a list format,
and it actually allows you to use them for a traffic
amplification attack.
So if you have a look through the code here,
you can see that it's DNS reflection dos, a denial
assertive technique that you can use to use these name servers
and actually do this traffic amplification
attack against a DNS server.
So you need to compile that code by doing GCC DNS doctor dos,
and I'll output to DNS doctor dos.
And then if you were to simply run
DNS doctor dos with a minus H, you
can see that there are various options that it needs.
And one of those options is it takes a list of a name server.
So you've got a DNS server and you've
got an IP address that you want to send the spoof
responses from and the requests that it should be looking up
to send those attacks through.
So what I would do is I'll do echo
and I will add my IP address of my DNS server
into a file called name server.lst.
And these names server.lst files would then contain--
[INAUDIBLE] server minus one-- and these names server.lst
files would then be used to feed into Doctor DNS Dos, like this.
So I'll do DNS Doctor Dos minus F name server
list minus source IP address.
Well, I want it to DDoS an IP on the network.
So I will get it to DDoS me--
I'll get to DDoS myself as an example,
so I'll use my IP address of 104.
And you see now that if I do minus L 10
just to loop over it and see how many loops it will do,
and this will actually then spoof a DNS query,
look up the DNS name I provide.
So I'm going to put NSA.gov.fullstop,
and then I'll do minus L and tell it
to do a million DNS requests.
And actually, if you were to then look
at this in a tool like wireshark,
we would actually see that this is now
doing a traffic amplification.
It's sending lots of packets to the DNS server, which is then
amplifying back the responses and sending back
much more traffic.
So it is, in effect, conducting a denial of service attack
against myself.
So if I was to then run start and actually observe traffic
on the network and do capture-- make sure that I capture
on the right interface--
capture options and I'll put on interface ETH1,
you can actually see all of these DNS queries
that are being sent to the DNS server,
flooding my connection with amplified traffic.
So this is what attackers would do, is they would find as many
of these systems as they can allow them
to use traffic amplification.
So that's why if you are responsible for a DNS server
or if you're responsible DNS security,
you need to ensure that you can't have your server misused
as part of these traffic amplification attacks.
Because this is actually what happens,
some hacktivists might use these name servers to overload a web
server with DNS requests, but the requests
will appear to come from your DNS server.
So therefore, you would then end up
on blacklists or with abuse complaints and various others.
So this is an example of how you could actually use DNS Doctor
Dos, and obviously, it would hack
a bunch of different computers, use this tool
with a big list of DNS servers so they
send lots of packets, overwhelming, say,
number 10 or Westminster because they're upset over animal
rights or something like that.
So just as an example there of how you could use a DNS Smurf
attack, and Nmap and Metasploit both
contain scripts that help you with probing for that.
Another thing that you might want to use
are looking for the bailiwick attack,
if you were to do for the bailiwick
or bailiwick So in Metasploit, you
could find some modules to actually exploit
the domain start of authority exploit that we mentioned
before, you could actually trying to use this module
if you wanted to find a vulnerable DNS server
and try to actually use this module to do that injection
and poison the cache of a server and cause it
to-- anyone who looked up Example.com
or a similar website like that would subsequently
get a different response.
So what I'll do is I'll do set domain NSA.gov set
interface set new DNS the hostname of the replacement DNS
server, 192.168.56.104, set reconnaissance.
The DNS server to query will be the actual DNS
server I want to query itself.
And then the target server to see whether or not that's done.
And then that should be it, it should set up all the options.
Once it's set and you then try to do that,
the following options is source port,
and I'll set source port to 0.
And what it would try to do is then actually
try to do that bailiwick attack by querying against that DNS
server.
And it'll fail in this example, but it would then
try to do that 1.NSA.gov, 2.NSA.gov, 3.NSA.gov,
and try to spoof back the responses
so that it would poison the cache on that DNS server,
giving you back some information.
Likewise, if I wanted to simply look
at the cache of a DNS server, we could
look in things like Dig or NS lookup.
And what I'll do is I'll do set recursive equals 0,
so that we disable the recursive bit.
And then I'll set the server to be the remote server.
Then if I was to simply look up Google.com,
we can see that this server doesn't have Google.com in its
cache, so we know that Google.com has not been used--
nobody who is using that DNS server
is using Google.com, which is very unlikely.
However, we can see that if we were to look up NSA.gov,
we also don't get an answer for there.
So there's actually nothing in this DNS server's cache,
but because it's not doing recursive lookups,
that's how it should be looking, just in the local server cache.
So remember, DNS cache snooping is
disabling the recursive lookup, measuring the time
or the responses coming back from a server
to see what information is contained in it.
So likewise, another attack that you might want to do
is perhaps maybe leverage some exploits.
And we know from our notes file, we actually
have a version of DNS BIND that's in use on this server,
so we can actually begin profiling it
for vulnerabilities.
So what I would do to profile it for vulnerabilities is I would
go to SecurityFocus.com/bid, and this is a database known as bug
track.
It's provided by the Security Focus website.
And you can actually select a vendor.
So let's say I selected ISC, which is the Internet Software
Consortium.
And then you could do title and then you could select BIND.
And then, of course, you could try and select
the version of BIND that was in use,
and for this we've got 9.8, so we could actually select 9.8.
So we can actually see then known vulnerabilities
listed with CV numbers that might apply
to that particular version of BIND
that we could then click on and look up and see
is there any information in there that's of use to us.
So if I was to simply click on this one, recursive queries,
we could see discussion, find some more information,
and whether or not there's an exploit available for it.
And this one says there's an exploit in the wild,
and it looks like it has a remote denial of service
condition.
And then there's various references,
which include advisories and other things.
You could also look at exploit.db,
and simply do a search for exploit.db or other websites,
like Packet Storm.
And if you were to simply go to exploits,
you could actually do a search in the exploit page--
unless I am blind--
and you can actually do a search in here for the search.
Search the exploit database here.
And then you could do something like ISC BIND, for instance.
I am not a robot.
Street signs.
Not true, I may be a robot.
And then we can see here clicking all the vehicles.
And once we've got rid of these annoying captures,
it would actually search through that web page.
And I'll do a search there for ISC BIND,
and we can see we could actually look for any kind of exploits.
We know 9.8.1, so we'd look for, OK, 9--
is there anything here?
Is this one?
We'd actually have a look and say, OK, well, this one here,
and then we could read through what that vulnerability does.
Maybe there'd be some information there
as to which version it targets and similar.
So that's an example of one vulnerability, which
says it impacts version 9.
So we can have a look for other vulnerabilities.
And again, we would look for exploits
now for any of these known vulnerabilities.
Another place I would check is the home page.
I would actually go to the home page of the project
and have a look through the change log,
have a look through, look for the bug report,
look for the security page, look at the previous advisories
and try to find out--
this is basically what's known as vulnerability analysis.
You know a piece of software's name, you know the version.
You want to go and find all the known problems in there
before you start looking for unknowns or 0 days--
zero days.
You want to look for the known vulnerabilities.
Once you know what these known vulnerabilities are,
has somebody written an exploit?
Can you just use their exploit instead of writing your own?
So in this example here, we know it's BIND 9.8.1,
and we saw a number of issues in there.
And instead of going to exploit.db
and doing that [INAUDIBLE] every time,
you can actually just do search spoilt,
and then you could actually just type on the command line.
It will actually just search through all those exploits,
as they're all locally stored on Kali as well.
They're actually in /user share exploit db.
And then in there, you'll find platforms
and you'll find all of these different exploits
are stored there based on the multiple dos
37721, the file name that we saw from the command search sploit.
So here, we can see actually that same file we just looked
out on the web page in a .C file.
So that's maybe one place we could do.
Equally, Metasploit is a framework
which unifies a lot of those exploits into one place.
So you could also just do a search through there
and see if you could find anything
for ISC BIND or similar.
And in fact, if you just search BIND,
you'll find that you'll get a lot of things
back because it's referring to BIND payloads.
But if I was to go back to exploit
or whatever, do maybe search for a known vulnerability,
you can see search tiki, you can see
there's an auxiliary denial of service, tiki query
denial of service.
And again, you could use that module in Metasploit.
Simply type use, use the Metasploit module,
show options.
And we can see here these various options
that are required to be set.
So we'll set the r host option, which is the target
address that we want to target.
And once we've got the option set
and we've checked that everything
that says it's required is set, we can actually simply type run
and it will run that attack against the server.
And if we were to now try to use that DNS server
to query that DNS server, we would actually
find that it will no longer respond to our queries
because, in fact, the DNS service has crashed
because this tiki attack is a denial of service attack, which
is used to cause the server to crash.
And I wouldn't ever like to do that against a client network
without their permission.
Certainly taking out DNS would be a big deal for them.
But if you identify vulnerable DNS servers
and you can crash DNS, then this is the implication
that it can have.
So this is how you do that.
So that's looking up a known vulnerability
and exploiting it.
Likewise, we could have also used
the exploit that was from exploit.db instead
of using Metasploit, and we could have just compiled
that using minus O tiki, and then
we would have a file for doing t kill.
We could actually try to Dos a DNS server just by simply
giving it the IP address.
But this host isn't actually replying now.
So if I go back to this DNS server, what I'm going to do
is I'm going to reset it.
If you want to just get your DNS servers
or your devices back to a default state,
you can simply reset them and it should
bring it back alive for you.
So now I'm going to demonstrate just one more attack,
only this time I'm going to do it with a fuzzing utility
as well running in the background.
And I'm going to use the Nmap script instead of Metasploit,
but there's a fuzzer in Metasploit
as well, if you were to do search DNS fuzzer.
You could also use a fuzzer from here.
They both use effectively the same kind of logic.
But if you were to do minus Nmap SU script equals DNS hyphen
fuzz, you can then give it some scripts arguments.
And you'd get these by reading through that script
that we identify with nse discover,
and then supply it with the target IP address range
here that we want to actually launch the attack on.
What you'll see is if we were to actually look at this through--
I'll add in the argument minus p 53 and 123
so that it's only running the scripts.
And if we were to actually just caption now on the wire
and restart that, we'd actually see that what's
happening on the DNS query is it sending lots of malformed DNS
queries to the server, looking up different kinds of resource
records, trying to fuzz that server
to respond in a way that isn't expected,
and it effectively tries to cause the server to crash.
So even if it doesn't have a known vulnerability,
running fuzzing attacks against a DNS server
can often cause it to become unresponsive
and that can have the same impact of disabling internet
connectivity to an organization.
So that's an example of how you would run a DNS fuzzing script.
And finally, with that running in the background, what
I'm going to do is I'm actually going to crash the server
and simulate an actual attack, as though the fuzz had actually
worked.
So we'll now run that other exploit,
the tiki exploit that we know is a vulnerability that
impacts on 9.81.
We knew that because it said 9 in the version number.
And if we were to go back to our Metasploit output
here, in our show info argument, which we didn't actually run,
you would have seen that it told you which versions of BIND
it supports as well.
So this tiki attack is a known vulnerability
that impacts 9.8.1.
And I'll just run this attack now.
You see it's queried the version number,
it sent a denial of service attack, and it's then come back
and says it's probably succeeded.
But if we were to also look at our Nmap output,
you can see that this DNS fuzz packet now
believes that it might have crashed the server
and it's then spat out the offending packet's details,
so you can actually replay that attack back at the server
and see whether you can crash it again.
So that's a way of fuzzing DNS services,
causing denial of service attacks.
And again, the implications of crashing a DNS server
result in internet downtime, very critical bits of code.
So that's something to avoid.
And we have a lot of code execution
and a couple things like that in a later module.
If you ever did want to go on and just debug and experiment
with this module, you'll see the username and password
have been left on the terminal.
It's the only module we give you the username and password for.
You are expected to hack your way to root on everything else.
So that's how DNS and DNS modules, how
you can query and enumerate.
What you're looking for is network endpoints,
looking for IP addresses, looking for information,
look for software type, software version
so you can profile and find vulnerabilities.
So that concludes the Hands-On Hacking DNS module,
and I look forward to seeing you all in the next module.