This is part four in our tutorial series on
how to set up a home hacking and security testing lab. In
part three, we set up a completely virtual network
inside VirtualBox in order to use Kali to test the (in)security of the
Metasploitable2 virtual machine. In the present article, we'll set up a
local area network similar to one you might find in any home, and then
walk through a
man-in-the-middle attack against an everyday router.
Here's
our hypothetical scenario: there is a malicious individual on a local
area network listening in on the network traffic (sniffing it, as they
say) using
ARP poisoning
in an attempt to steal login credentials from the router's
administrator so as to hijack the device, and by extension, the network.
In this scenario, Kali will once again function as the attacker but the
host computer will be the victim.
This configuration
will require a router specifically for the purpose of hosting our home
lab's local area network. This could also be accomplished virtually, but
having the external network will allow us to test the security of other
external networked devices moving forward.
Configuring the Local Area Network
For
the present test, which was successful, I picked up one of those
ubiquitous Netgear WNR 2000 series home routers at a local flea market
for ten dollars. You might even have an old router just lying around
collecting dust. Plug the router in, turn it on, and configure it as
desired. An online manual for this router stated that once you have
connected your computer to it, you can navigate to the URL
routerlogin.net or the device's ip address in a web browser to log in
for administrative purposes. They further provided the factory default
login credentials: 'admin' for the login name, and 'password' for the
password. The first thing I did upon logging was to change the password
using the router's so-called "Smart Wizard".
I prefer
to hook up devices to the lab router through ethernet, and turn off
wireless networking in the router when I'm feeling paranoid. Log into
the router, and adjust settings as necessary. It should have DHCP, to
provide ip addresses to hosts on the network. Keep it completely
isolated from your actual home LAN that is connected to the internet, at
the very least because connecting a second dhcp server to your main
home network would cause a fair amount of chaos. We'll soon see whether
this sort of interaction with the router is secure in any way. (Spoiler
alert: in the case of the WNR 2000, it is not.)
Once
your router is setup, open the Network settings in your Kali machine and
change the attachment from the internal network to bridged mode, and
attach it to the appropriate interface. (People who are more comfortable
with managing multiple interfaces on Linux could just add a second
adapter and switch between the two inside Kali.) Under the Advanced
section of Kali's Network settings, notice the drop down menu for
Promiscuous Mode. This setting is important for our test. There are
three options here: Deny, Allow VMs, and Allow All. Set it to Deny. This
means that Kali will not be privy to any traffic directly to or from
its host machine or other VMs that may be on the network.
Why have we set Promiscuous Mode to Deny?
Abstinence-Only Networking and the IP Stack
When
Kali is running in bridged networking mode, so as far as the rest of
the hosts on the network are concerned, it is a completely independent
host. But it's not, it's a virtual machine, it shares its network
interface with its host computer, and by extension with any other VMs
that might also access that interface.
If we set
promiscuous mode to Allow All, the Kali machine will pick up all traffic
going over the network interface, to which it has access because it is
itself bridged over this interface. That obviously includes the given
network's traffic sent to and from the host computer on which the
virtual machine is running, as well as any other virtual machines it
might be running on that interface. If the host computer pings the
router, Kali will pick up the traffic.
When promiscuous
mode is set to Deny, on the other hand, Kali networks with the host
computer (and any other virtual machines that might be on the network)
as if they were all on completely separate physical devices. If the host
computer pings the router, Kali will not pick up the traffic.
If
there is a secondary computer on the network, even if Kali is in
promiscuous mode, it will not be able to capture a ping from that
computer to the router, or any other such traffic between them, for that
matter, such as an http session.
When we run the
man-in-the-middle attack against the router and the host machine,
however, we'll see that we can pick up traffic between them. One might
wonder whether this is a true man-in-the-middle attack, because as we
already know, the Kali guest and the host computer share an interface.
Kali already has access to the host machine's traffic. Setting up the
sniffer is basically just enabling promiscuous mode on the adapter
setting.
However, we are not conducting a physical
layer attack. ARP poisoning is conducted between the link layer and the
network layer of the
IP stack.
This could be demonstrated with a secondary host on the network. An ARP
attack by Kali against the secondary computer will still work even
though Kali does not share a physical network interface with the victim,
and could not detect such traffic even in promiscuous mode.
Reconnaissance and Scanning the Network
There
should now be three hosts on the lab LAN: 1) the router, 2) the host
computer (our victim), and 3) the Kali virtual machine (our attacker).
Let's begin by conducting some passive monitoring of the network
traffic.
Open up Wireshark on your Kali instance and
conduct a live capture, to see what kind of traffic you can pick up on
this network. (See part two in the series for info on how to properly
configure Wireshark to conduct a live capture, if you haven't already.)
Let the scan run for about half an hour. My capture picked up:
- SSDP broadcasts from the router, alerting hosts as to its existence
- ARP broadcasts from the victim computer and the Kali host machine,
seeking out the router's hardware address from its ip address.
- DNS requests to external websites for services running on Kali and
the host machine, these are obviously unresolvable, since the network is
not connected to the internet. (I would also like to shut down these
services later if they are not system critical, as I don't like the idea
of my machines contacting random services on the internet without my
say so.)
Nothing really seems out of the ordinary here, so let's run a
scan of the network. Here's the topology graphic produced by Zenmap from
a default nmap scan of my lab network:
The
router is at 192.168.1.1, the primary host computer is at 192.168.1.2
and the Kali machine is at 192.168.1.5. As you can see, Zenmap's color
coding indicates that there may be some vulnerabilities in the router.
This
scan discovered three open ports on the router, and found no open ports
on any of the other hosts. Ports 23 (telnet) and 80 (HTTP) were found
open by default on the router. We would expect port 80 to be open since
you can log into the router with a web browser for administrative
purposes. It seems a bit odd that the telnet port is open as well, as it
is unlikely anyone today would be telnetting into the router on their
home network. This is a security vulnerability, but, fortunately, this
router does not actually allow simple telnet access to its
administrative interface. Any basic attempts to connect to it via telnet
are rejected, which makes one wonder why it is open to begin with.
Now
let's attempt to systematically determine what traffic on the network
the Kali instance is able to capture. All packets sent from or to the
Kali VM will be captured in Wireshark, since the capture is running on
that system: ex. ping requests to the router from Kali, ping requests to
Kali from the host computer, HTTP traffic if you use a Kali web browser
to navigate to the router's admin page, and so on.
As
noted above, if your Kali virtual machine's network settings were in
promiscuous mode, Wireshark would also capture any packets directly sent
to or from the host computer. But this is not the case here as we have
set promiscuous mode to Deny.
With promiscuous mode set
to Deny, if you ping Kali from the host computer, the Wireshark capture
will pick up all of these packets, since they are being sent directly
to and from the Kali machine. However, if you ping the router from the
host computer, none of the request or reply packets will be picked up by
your Wireshark capture in Kali, nor will any other such traffic. For
example, if you use a web browser on the host computer to navigate to
the router's login interface, the capture will not detect any of this
traffic.
With this observation, we have acquired our
target. What we would like to do is two-fold: 1) pick up any direct
traffic at all between the host computer and the router, 2) pick up any
sensitive traffic (and any correspondingly sensitive information) sent
between these devices.
Running a Man-in-the-Middle Attack with Ettercap
To
compromise the traffic between the host computer and the router, we are
going to use a program called Ettercap. As noted in its manual page,
Ettercap
is a "multi-purpose sniffer/content filter for man in the middle
attacks." Ettercap can be run from the command line or through its
graphical interface. To launch the graphical interface, type the
following command into a terminal:
sudo ettercap -G. The Ettercap graphical interface:
However, we're
going to run Ettercap from the command line, as this conserves more
resources on the host machine since it does not require excess RAM. Our
plan is to use arp poisoning to capture traffic between the victim and
the router. Reading through the
Ettercap manual pages allows us to determine that
we can use the following command to conduct our attack:
sudo ettercap -i eth0 -T -M arp /192.168.1.1/ /192.168.1.2/
Before we run the command, let's take a closer look at what's going on here:
- sudo runs the command as a privileged user. This is necessary for Ettercap to conduct the packet capture.
- ettercap tells the shell to run the Ettercap program.
- -i eth0 tells Ettercap to run the capture on the eth0
interface inside Kali. This may be different for you depending on how
you have your network adapters set up. If you try to run arp poisoning
on an interface that is not enabled, Ettercap will likely complain that
"No such device exists". If you run it on an interface that is enabled,
but not connected to a network, Ettercap will complain that "ARP
poisoning needs a non empty hosts list".
- -Tq tells Ettercap to run in text mode (-T), meaning it will print out any text characters found in its capture.
- -M tells Ettercap to run a man-in-the-middle attack.
- arp specifies that Ettercap should run an ARP poisoning man-in-the-middle attack.
- /192.168.1.1/ and /192.168.1.2/ specifies the two specific hosts we want to target.
Let's see if we can capture any traffic between the victim and
the router. Start a Wireshark live capture on Kali. Now ping the router
from your host computer, and just let it ride (ex.
ping 192.168.1.1)
. If
you are running in non-promiscuous mode, Kali will not pick up any of
the ping requests and replies between the victim and the router.
Now
run the Ettercap command above (with any necessary substitutions for
your own network configuration) from a terminal in Kali. If successful,
the Wireshark capture should now begin picking up the echo requests and
replies between the victim and the router (as well as any other packets
passing between them), and Ettercap will print to the terminal any text
picked up in those packets. You can now stop the live capture, quit
Ettercap and stop the ping from the host machine to analyze the
results.
The next question is whether we can pick up
any sensitive information, such as login credentials, passing between
the victim and the router. For this, we'll slightly modify our Ettercap
command:
sudo ettercap -i eth0 -Tq -M arp /192.168.1.1/ /192.168.1.2/
As you can see, everything is the same here, except I've added a
q to the -
T
option. This tells Ettercap to run in quiet mode, which means that it
will not print any and all text it picks up in captured packets, but
rather only text of potential significance, such as login credentials.
For our test, we want to see if we can capture the victim's credentials
when logging into the router.
Start a new Wireshark
live capture in Kali. Run the Ettercap quiet mode command in a terminal.
Now, on the host computer, use a web browser to navigate to the router
and log in to the administrative interface. Here's the result in
Ettercap when I ran this attack against the WNR 2000 router:
As
you can see, Ettercap picked up the victim's user name (here: 'admin')
as well as the password (here: 'supersecretstring'). Moreover, the
router passed the login credentials over the network in plaintext six
times when the victim logged in to the device! Obviously,
'supersecretstring' is not a very good password, but in the present case
it doesn't really matter how secure the password is, since the router
passes it over the network in plaintext.
The login credentials
can also be found in the Wireshark packet capture run alongside the
Ettercap ARP poisoning attack. My Wireshark capture picked up a lot of
packets, so let's do a search for 'credentials':
Inspecting the first packet returned from this search, reveals the following under the HTTP section of the packet view:
And
there they are, the user name and password, conveniently located under
the authorization heading: 'admin:supersecretstring'. In fact, it
turns out the login credentials are sent in plaintext every time the
victim loads another page in the router web interface!
The
victim's router admin account has now been compromised. After the
victim logs out of the router, the attacker can immediately log in with
admin privileges, change the password and lock out the victim, or make
changes to the system's settings, turning it off, etc. The "Smart
Wizard" on the WNR 2000 router isn't so smart or wizardly after all!
Now the question is: does this attack work against the router on your home lab? Let us know in the comments.
Reflecting
on this attack, one would probably ask: Can't we detect this attack as
it was going on? Does it not create a whole load of excess traffic on
the network? Wouldn't it be clear from a packet capture on the victim
machine that the intrusion took place? Wouldn't it even identify the ip
and hardware addresses of the attacker? The answer to all those
questions is in the affirmative, but you'd need to have been monitoring
the network traffic over the whole course of the login session to know
that. A simpler solution for the potential victim is to check the
system's ARP cache before logging in to the router. This will identify
whether there are two hosts on the network with the same hardware
address. Since hardware addresses are supposed to be universally unique,
this is a tell-tale sign that ARP spoofing is in progress.
Moving Forward
Now
that you have your lab's local area network set up, what can you do
with it moving forward? Well, that's up to you! At the very least, you
can use it to test the security of any given networked device you like,
whether it's your main computer, a secondary computer, a cell phone, a
tablet, a network drive or fileserver, a television or gaming console,
and so on. Do you know what precise information your cell phone or
laptop broadcasts to the entire local area network when you connect to
any wireless device?
That concludes part four of our
tutorial series on setting up a home hacking and security testing lab.
If you've followed along from the beginning, you now have a virtual
network you can use to explore the vulnerabilities in Metasploitable, an
isolated local area network to test the security of any device you
wish, and some familiarity with a handful of the many tools that are
bundled with Kali.
As always, questions, comments, suggestions and criticism are welcome in the comments. Happy hacking!
