{"id":694,"date":"2016-11-25T21:21:51","date_gmt":"2016-11-26T04:21:51","guid":{"rendered":"http:\/\/www.mjblythe.com\/hacks\/?p=694"},"modified":"2022-01-04T12:33:18","modified_gmt":"2022-01-04T19:33:18","slug":"packet-sniffing-for-fun-and-profit","status":"publish","type":"post","link":"http:\/\/www.mjblythe.com\/hacks\/2016\/11\/packet-sniffing-for-fun-and-profit\/","title":{"rendered":"Packet sniffing for fun and profit"},"content":{"rendered":"

\"wireshark-capture\"<\/a><\/p>\n

I have a commercial IOT product that I want more control over. Sure, I can control it with the free Android app, but I want my home server to be able to control it, too. This means trying to understand how the app controls it over the network, and attempting to replicate that communication.<\/p>\n

This means I have to do some packet sniffing.<\/p>\n

<\/p>\n\n

Simple probing<\/h2>\n

First thing first, we’ll want to figure out what IP address the router has assigned it. This should be as simple as logging on to your router’s configuration web page & finding the device that you don’t recognize. If you happen to run DD-WRT on your router, it might look something like this:<\/p>\n

\"wireless-clients\"<\/a><\/p>\n

It just so happens that my target device is listed first: 192.168.1.119<\/code><\/p>\n

The next thing we can do once we know the IP address is do a port scan using nmap<\/code>. We might get lucky and find that some useful service is exposed.<\/p>\n

By default, nmap scans the most common TCP ports:<\/p>\n

> nmap 192.168.1.119<\/code><\/p>\n

<\/code><\/code>Starting Nmap 7.12 ( https:\/\/nmap.org ) at 2016-11-25 21:27 MST
\nNmap scan report for 192.168.1.119
\nHost is up (0.0015s latency).
\nAll 1000 scanned ports on 192.168.1.119 are closed<\/p>\n


\n<\/code>Nmap done: 1 IP address (1 host up) scanned in 7.07 seconds<\/code><\/p><\/blockquote>\n

Alternatively, we can specify which ports to scan. Here, I’m asking it to scan TCP ports 1 thru 10,000:<\/p>\n

> nmap 192.168.1.119 -p 1-10000<\/code><\/p>\n

<\/code><\/code>Starting Nmap 7.12 ( https:\/\/nmap.org ) at 2016-11-25 21:28 MST
\nNmap scan report for 192.168.1.119
\nHost is up (0.0023s latency).
\nNot shown: 9999 closed ports
\nPORT STATE SERVICE
\n1932\/tcp open unknown<\/p>\n


\n<\/code>Nmap done: 1 IP address (1 host up) scanned in 53.59 seconds<\/code><\/p><\/blockquote>\n

We managed to get lucky, and find an open TCP port! Let’s connect to it with netcat<\/code> & see what happens:<\/p>\n

> nc 192.168.1.119 1932<\/code><\/p><\/blockquote>\n

Unfortunately, it presented no welcome message, and any commands I tried got no response.<\/p>\n

Next, let’s scan the UDP ports to see what pops out. This requires root permissions, and it takes a while. By default, it will increase the time between port probes since it’s not receiving any responses, so we need to add some additional options<\/a> to speed things along:<\/p>\n

> sudo nmap 192.168.1.119 -sU -p 1-20000 --max-scan-delay 150ms --max-retries 2 --max-rtt-timeout 150ms --min-rate 200<\/code><\/p>\n

<\/code><\/code>Starting Nmap 7.12 ( https:\/\/nmap.org ) at 2016-11-25 22:09 MST
\nWarning: 192.168.1.119 giving up on port because retransmission cap hit (2).
\nNmap scan report for 192.168.1.119
\nHost is up (0.0048s latency).
\nNot shown: 19995 closed ports
\nPORT STATE SERVICE
\n25\/udp open|filtered smtp
\n80\/udp open|filtered http
\n4096\/udp open|filtered bre
\n10619\/udp open|filtered unknown
\n13450\/udp open|filtered unknown
\nMAC Address: 38:2B:78:00:EB:B3 (ECO Plugs Enterprise)<\/p>\n


\n<\/code>Nmap done: 1 IP address (1 host up) scanned in 199.26 seconds<\/code><\/p><\/blockquote>\n

Again, we can try to connect to these UDP ports with netcat:<\/p>\n

> nc -u 192.168.1.119 25<\/code><\/p><\/blockquote>\n

No welcome messages, and no interesting responses to anything I sent.<\/p>\n

Time to move along to…<\/p>\n

Intercepting traffic out to the wider Internet<\/h2>\n

High-end routers have a “monitor port” feature. Basically, any traffic that flows through the router will be copied to this port so that the traffic can be analyzed. Unfortunately, consumer-grade routers don’t often have anythign like this.<\/p>\n

However, some consumer routers (like the ancient Linksys WRT54GL that I use) can run custom Linux firmware, which can approximate this feature. This post<\/a> (cached here<\/a>) describes how to set up some firewall rules so we can observe traffic flowing through our router. The main limitation of this is that we’ll only monitor traffic that’s entering or leaving the internal network, not any traffic that stays on the subnet (because this local routing happens in a dedicated routing chip; it isn’t touched by any Linux software).<\/p>\n

An aside: my DD-WRT install is really old, and only supports a weak ssh key exchange protocol. It must be manually enabled like this: ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 root@192.168.1.1<\/code><\/p>\n

Before adding our rules, there will probably be nothing:<\/p>\n

# iptables -t mangle -L
\nChain PREROUTING (policy ACCEPT)
\ntarget prot opt source destination <\/code><\/p>\n

<\/code><\/code>Chain INPUT (policy ACCEPT)
\ntarget prot opt source destination<\/p>\n

<\/code><\/code>Chain FORWARD (policy ACCEPT)
\ntarget prot opt source destination<\/p>\n

<\/code><\/code>Chain OUTPUT (policy ACCEPT)
\ntarget prot opt source destination<\/p>\n


\n<\/code>Chain POSTROUTING (policy ACCEPT)
\ntarget prot opt source destination <\/code><\/p><\/blockquote>\n

Add our rules, then make sure they’ve been applied:<\/p>\n

# iptables -t mangle -A POSTROUTING -d 192.168.1.119 -j ROUTE --tee --gw 192.168.1.102
\n# iptables -t mangle -A PREROUTING -s 192.168.1.119 -j ROUTE --tee --gw 192.168.1.102
\n# iptables -t mangle -L
\nChain PREROUTING (policy ACCEPT)
\ntarget prot opt source destination
\nROUTE 0 -- 192.168.1.119 anywhere ROUTE gw:192.168.1.102 tee<\/code><\/p>\n

<\/code><\/code>Chain INPUT (policy ACCEPT)
\ntarget prot opt source destination<\/p>\n

<\/code><\/code>Chain FORWARD (policy ACCEPT)
\ntarget prot opt source destination<\/p>\n

<\/code><\/code>Chain OUTPUT (policy ACCEPT)
\ntarget prot opt source destination<\/p>\n


\n<\/code>Chain POSTROUTING (policy ACCEPT)
\ntarget prot opt source destination
\nROUTE 0 -- anywhere 192.168.1.119 ROUTE gw:192.168.1.102 tee<\/code><\/p><\/blockquote>\n

Aside #2: in order to run wrieshark as an unprivileged user, do the following:<\/p>\n

> sudo dpkg-reconfigure wireshark-common
\n#Select Should non-superusers be able to capture packets? \"yes\"
\n> sudo usermod -a -G wireshark your-username-here<\/code><\/p><\/blockquote>\n

Group settings only take effect at the nest login. So, either log out and in again, or run su your-username-here<\/code> to get a single terminal with the new group applied.<\/p>\n

With that in place, we can launch wireshark now. The starting screen should look something like this:<\/p>\n

\"wireshark-startup\"<\/a><\/p>\n

Select the interface you want to monitor (eth0<\/code> for me), and enter in an appropriate capture filter (host 192.168.1.119<\/code> will capture the packets to and from that IP), then hit enter. It should start capturing packets:<\/p>\n

\"wireshark-capture\"<\/a><\/p>\n

Once you’ve done some interesting activities (restart the unit to observe its initial connections, perform come operations, etc), you can press the red square to stop the capture. At this time, you can dig into the individual packets, or save the capture off to analyze later.<\/p>\n

Now that we’re done with the monitoring, we should delete the firewall rules (and confirm that they have been deleted):<\/p>\n

# iptables -t mangle -D POSTROUTING -d 192.168.1.119 -j ROUTE --tee --gw 192.168.1.102
\n# iptables -t mangle -D PREROUTING -s 192.168.1.119 -j ROUTE --tee --gw 192.168.1.102
\n# iptables -t mangle -L
\nChain PREROUTING (policy ACCEPT)
\ntarget prot opt source destination <\/code><\/p>\n

<\/code><\/code>Chain INPUT (policy ACCEPT)
\ntarget prot opt source destination<\/p>\n

<\/code><\/code>Chain FORWARD (policy ACCEPT)
\ntarget prot opt source destination<\/p>\n

<\/code><\/code>Chain OUTPUT (policy ACCEPT)
\ntarget prot opt source destination<\/p>\n


\n<\/code>Chain POSTROUTING (policy ACCEPT)
\ntarget prot opt source destination <\/code><\/p><\/blockquote>\n

Intercepting WiFi traffic<\/h2>\n

Of course, you may want to see more of the traffic that’s being sent by the device. How is it interacting with other devices on your home network? How does it communicate with the cell phone app when the “cloud” feature is disabled?<\/p>\n

This one is tricky, mostly because we’ll need a WiFi adaptor that allows us to capture packets that aren’t intended for us. I tried a few laptops that I had laying around, and none of them seemed to work as well as I had hoped. However, I found that this USB WiFi adaptor<\/a> works pretty well for me.<\/p>\n

Unfortunately, I don’t think there’s a way to directly capture with wireshark<\/code> (if there is, please let me know!). I’ll use airodump-ng<\/code> to dump the traffic, then use wireshark<\/code> to analyze it afterwards.<\/p>\n

First, we should check if there are any programs running that might interfere with our capture:<\/p>\n

> sudo airmon-ng check
\nFound 2 processes that could cause trouble.
\nIf airodump-ng, aireplay-ng or airtun-ng stops working after
\na short period of time, you may want to kill (some of) them!<\/code><\/p>\n


\n<\/code>PID\tName
\n1005\tavahi-daemon
\n1020\tavahi-daemon<\/code><\/p><\/blockquote>\n

If you want, you can use sudo airmon-ng check kill<\/code> to terminate these processes. I’ve found that these avahi-daemon<\/code> processes don’t cause problems. If you’re running NetworkManager<\/code>, you will want to stop that with this command: sudo service NetworkManager stop<\/code><\/p>\n

Next, we need to put the WiFi adaptor into monitor mode<\/a>, so it will just listen to all packets:<\/p>\n

> sudo airmon-ng start wlan0
\nFound 2 processes that could cause trouble.
\nIf airodump-ng, aireplay-ng or airtun-ng stops working after
\na short period of time, you may want to kill (some of) them!<\/code><\/p>\n

<\/code><\/code>PID Name
\n1005 avahi-daemon
\n1020 avahi-daemon<\/p>\n


\n<\/code>Interface\tChipset\t\tDriver
\nwlan0\t\tUnknown \trtl8192cu - [phy0]
\n(monitor mode enabled on mon0)<\/code><\/p><\/blockquote>\n

This creates a virtual mon0<\/code> interface which is actually the one we’ll capture on (instead of wlan0<\/code>)<\/p>\n

Now, we’ll need some information about our WiFi network. Specifically, the BSSID (hardware address of the access point), and which WiFi channel it’s using. DD-WRT gives me this information on the “Wireless” tab:<\/p>\n

\"wifi-settings\"<\/a><\/p>\n

Using that information, we’ll run the following command<\/a>:<\/p>\n

sudo airodump-ng -c 6 --bssid xx:xx:xx:xx:BD:E1 -w dumpfile mon0<\/code><\/p><\/blockquote>\n

Where:<\/p>\n