Hack Lab Part 4: Compromising a Home Router on a Local Area Network

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: 

1. sudo runs the command as a privileged user. This is necessary for Ettercap to conduct the packet capture.
2. ettercap tells the shell to run the Ettercap program.
3. -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".
4. -Tq tells Ettercap to run in text mode (-T), meaning it will print out any text characters found in its capture.
5. -M tells Ettercap to run a man-in-the-middle attack.
6. arp specifies that Ettercap should run an ARP poisoning man-in-the-middle attack.
7. /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!

Source:http://blog.agupieware.com/2014/10/hack-lab-part-4-compromising-home_6.html