Wednesday, July 9, 2014

Initial network analysis of stray BitTorrent traffic

In my previous blog post I detailed a basic installation of ntopng. Interestingly, I was able to detect odd traffic destined to one of my desktops in my network ‒ no less than a day after I had setup ntopng on a development server. Network forensics and analysis is a domain I've been meaning to level up, so this was a perfect opportunity quest to explore.

In the ntopng web interface under the Flows section, ntopng had identified an active flow with a duration of over 4h, 14 min originating from the IP address 82.207.24.165, which resides in Kiev, Ukraine. There was a nice little Ukraine flag by the IP in the web interface, so it quickly caught my eye. In addition, the flow was identified as the BitTorrent protocol.

Example screenshot of Active Flows section inside web interface

Foreign IP addresses are to be expected, especially in regards to the BitTorrent protocol. The problem, however, was that my desktop wasn't running a BitTorrent client at the time and BitTorrent almost always connects to several peers at once for both (sometimes simultaneously) uploads and downloads. So my immediate questions were how was this traffic getting through the router firewall and why was it only this single IP address? Seeing a bunch of foreign flags in the web interface at once would have actually worried me less.

Since the flow was still active, I decided to see what it looked like on the wire with tcpdump by using a BPF to match any traffic to or from that Ukraine host:

root@trustytahr:/var/tmp# tcpdump -v -n -i eth0 not tcp port 22 and ip host 82.207.24.165
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:14:49.233184 IP (tos 0x0, ttl 107, id 5434, offset 0, flags [none], proto UDP (17), length 129)
    82.207.24.165.6881 > 192.168.0.7.31369: UDP, length 101 
13:14:49.356179 IP (tos 0x0, ttl 107, id 5449, offset 0, flags [none], proto UDP (17), length 129)
    82.207.24.165.6881 > 192.168.0.7.31369: UDP, length 101 
13:14:49.438760 IP (tos 0x0, ttl 107, id 5460, offset 0, flags [none], proto UDP (17), length 129)
    82.207.24.165.6881 > 192.168.0.7.31369: UDP, length 101 
13:14:49.544598 IP (tos 0x0, ttl 107, id 5470, offset 0, flags [none], proto UDP (17), length 129)
    82.207.24.165.6881 > 192.168.0.7.31369: UDP, length 101 
13:14:49.583587 IP (tos 0x0, ttl 107, id 5475, offset 0, flags [none], proto UDP (17), length 129)
    82.207.24.165.6881 > 192.168.0.7.31369: UDP, length 101 
13:14:49.735788 IP (tos 0x0, ttl 107, id 5489, offset 0, flags [none], proto UDP (17), length 129)
    82.207.24.165.6881 > 192.168.0.7.31369: UDP, length 101 
13:14:49.804994 IP (tos 0x0, ttl 107, id 5498, offset 0, flags [none], proto UDP (17), length 129)
    82.207.24.165.6881 > 192.168.0.7.31369: UDP, length 101 
13:14:49.839829 IP (tos 0x0, ttl 107, id 5502, offset 0, flags [none], proto UDP (17), length 129)
    82.207.24.165.6881 > 192.168.0.7.31369: UDP, length 101 
13:14:49.926611 IP (tos 0x0, ttl 107, id 5512, offset 0, flags [none], proto UDP (17), length 129)
    82.207.24.165.6881 > 192.168.0.7.31369: UDP, length 101 
13:14:49.965995 IP (tos 0x0, ttl 107, id 5516, offset 0, flags [none], proto UDP (17), length 129)
    82.207.24.165.6881 > 192.168.0.7.31369: UDP, length 101 
  • UDP packets were being sent several times a second by 82.207.24.165 with random source ports.
  • All of these packets were being sent to the same UDP port, 31368, on 192.168.0.7.
  • -v specifies verbose mode, and -n prevents tcpdump from doing a reverse DNS lookup on the IP addresses.

Seeing that the traffic was identified as BitTorrent and destined to 192.168.0.7:31369, I checked three things on 192.168.0.7 (a desktop running Windows 7):

  1. Find any connections matching port 31369, and also see if there were any interesting or malicious processes using the port.
  2. C:\Windows\system32>netstat -nabo | findstr "31369"
    C:\Windows\system32>
    
    • No connections found.
  3. Double-check if µTorrent was running. A quick check in the system tray and Windows Task Manager verified it wasn't.
  4. See what random port µTorrent was using; µTorrent assigns itself a random UDP port for incoming connections.

  5. 31389 is indeed the randomly assigned port for incoming connections
    Also take note how Enable UPnP port mapping and Enable NAT-PMP port mapping were enabled

For further exploration, I re-ran tcpdump and included the -w switch which outputs the captured network traffic to a named .pcap file. I then opened it in Wireshark and clicked Follow UDP Stream.

Screenshot of Follow UDP Stream in Wireshark

Searching Google for strings in the output lead me to For Developers section on the BitTorrent.org website (not to be used with BitTorrent.com). On the page it describes the find_node packets:

Find node is used to find the contact information for a node given its ID. "q" == "find_node" A find_node query has two arguments, "id" containing the node ID of the querying node, and "target" containing the ID of the node sought by the queryer. When a node receives a find_node query, it should respond with a key "nodes" and value of a string containing the compact node info for the target node or the K (8) closest good nodes in its own routing table.

Also, it shows an example packet for a find_node Query, which is the type of packet that I was receiving from the Ukraine host:

find_node Query = {"t":"aa", "y":"q", "q":"find_node", "a": {"id":"abcdefghij0123456789", "target":"mnopqrstuvwxyz123456"}}
bencoded = d1:ad2:id20:abcdefghij01234567896:target20:mnopqrstuvwxyz123456e1:q9:find_node1:t2:aa1:y1:qe

Alternatively, the find_node Response packet looks like so (though my desktop never replied to a query in the time it was an active flow listed in ntopng):

Response = {"t":"aa", "y":"r", "r": {"id":"0123456789abcdefghij", "nodes": "def456..."}}
bencoded = d1:rd2:id20:0123456789abcdefghij5:nodes9:def456...e1:t2:aa1:y1:re

UPnP, NAT-PMP and BitTorrent

UPnP stands for “Universal Plug and Play.” Using UPnP, an application can automatically forward a port on your router, saving you the hassle of forwarding ports manually. We’ll be looking at the reasons people recommend disabling UPnP, so we can get a clear picture of the security risks. — http://www.howtogeek.com/122487/htg-explains-is-upnp-a-security-risk/
NAT-PMP allows a computer in a private network (behind a NAT router) to automatically configure the router to allow parties outside the private network to contact it. NAT-PMP runs over UDP port 5351. It essentially automates the process of port forwarding. — Wikipedia

UPnP and NAT-PMP, though different protocols, essentially do the same thing. UPnP or NAT-PMP run as a service on many home-based routers, and is usually enabled by default. BitTorrent often relies on these protocols to allow traffic through networks behind a NAT, which is nearly every home network. All of the major BitTorrent applications support support UPnP and NAT-PMP, which allows these clients to map ports on the router.

Turning off UPnP or NAT-PMP is as simple as going into the router web interface and looking for the checkbox to disable it.

Monitoring

Though the flow eventually stopped after a few hours, before I could test to see if turning off UPnP and NAT-PMP made a difference, I've been using ntopng to continually monitor and analyze other anomalous traffic.

No comments:

Post a Comment