Comparing Firefox reported connections to OS reported sockets in order to detect malicious behavior

In firefox release 52 (Mar 2017), a new feature was added, about:networking . This local-only accessible URL permits the user to see the currently established HTTP connections

As well as the underlying TCP connection (including server IP address).

Now that firefox exposes the active connections that it knows about, I might be able to create a tool I have thought up:

One performing analysis of a system to determine whether or not it is compromised (malware, otherwise connected intruder, etc…) might use the tool netstat (or its new replacement, ss) to answer the question of what network connections (ie, TCP sockets) are currently active and from which program.

The following screenshot shows a query using this tool to determine according to the OS what TCP sockets are established from firefox.

netstat -antp

The idea behind my tool is that some malware may inject code into a web browser to piggy-back on the legitimate use-case that a browser would have reason to have active internet connections. This imagined tool would query Firefox for the connections it knows about and query the OS for the same, and thus perform a comparison. Most likely, malicious code injected into the browser would not properly populate the database that Firefox uses to report its legitimate connections. Those connections that show up in netstat but not from the Firefox report would be suspicious.

Current approaches:

  1. Use Greasemonkey or the likes to parse the about:networking and write to disk. This approach does not appear to have legs as Greasemonkey is unable to access the useful about: pages.
  2. Another approach is to use the Network logging function of the about:networking and write a parser for the logs. I don’t prefer this option, but may explore it.

Ideally firefox would offer an API accessible method to retrieve this information. Maybe there is another way to get this done, for now this project is just a thought.

One can read more about the about_protocol from Mozilla.

SonicWall Firewall (ethernet/IP interfaces) capturing Fibre Channel

Recently a good friend of mine asked about some interesting traffic he observed in a packet capture. The capture was obtained on a SonicWall firewall and he mentioned that it looked like a bunch of Fibre Channel packets. My friend informed me that Fibre Channel was not present in the environment where the capture was performed. Let’s have a look.

FC_pcap

The first 2 non-zero bytes are 0x45. From having analyzed IP packets before this struck me as possibly being IPv4 (0x40) with a 20 byte header (0x05) which is very common. I also noticed (as did Wireshark) that there were just enough 0x00 bytes preceding this signature to fit an Ethernet header. There are 14 bytes (6 DST MAC, 6 SRC MAC, 2 EtherType) before the IP signature that are zeroed out.

Thus I hypothesized that this frame wireshark was showing as Fibre Channel was actually an Ethernet frame carrying IP, with the Ethernet header zeroed out. To prove this theory, I had wireshark decode it as such.

  1. Select the entire IP payload (click on “MDS Header” in the center pane).
  2. Right click on the highlighted payload and select ‘Decode As’.
  3. Select IPv4 from the list of protocols and click Apply.

The resulting view shows that this is an IP packet carrying Encapsulating Security Payload (ESP, IP protocol 50). This seems likely as ESP is used to carry traffic for VPN tunnels, which firewalls are often an endpoint of.

ESP_pcap

The IP checksum and packet length matched up, thus it’s pretty clear this is the correct interpretation (You can enable IP checksum verification under Edit -> Preferences -> Protocols -> IPv4 -> Validate the IPv4 Checksum if possible).

My friend confirmed that the IP addresses in the newly interpreted packet were correct VPN endpoints, thus I am confident we have a good explanation of the mystery Fibre Channel packets in a non Fibre Channel network.

How does that work – Communications to a cable modem on Private IP

This post is to document a behavior that may have made you stand back and ask, How does that work?

Scenario:

An internet connection consists of a coax cable plugged into a Cable Modem (CM) in turn connected to the WAN port of a Small Office/Home Office (SOHO) router, via a CAT5 cable. A person is able to access their cable modem on the IP address 192.168.100.1 using a web browser in order to view diagnostic details.

So what would be confusing about that? Nothing at first glance; but if you are familiar with networking then you realize that WAN interface of the router, has a public IP address and yet somehow is able to communicate with a private IP address which is on the “outside” of the router.  Furthermore, there are likely other users on the same ISP that use the same IP address to reach their own modems.

Equipment:

Dlink DIR-825 router running OpenWRT
Motorola Surfboard SB6121

MAC Addresses:

00:01:11:00:00:d8       Home router WAN
00:01:5c:ab:cd:ef       ISP default Gateway
94:cc:b9:fe:dc:ba       Cable Modem

IP Addresses:

1.1.1.23          Home router WAN
1.1.1.1           ISP default gateway
192.168.100.1     Cable Modem

Packet Capture:

09:31:30.072256 00:01:11:00:00:d8 > 00:01:5c:ab:cd:ef, ethertype IPv4 (0x0800), length 74: 1.1.1.23 > 192.168.100.1: ICMP echo request, id 1, seq 688, length 40

09:31:30.072594 94:cc:b9:fe:dc:ba > 00:01:11:00:00:d8, ethertype IPv4 (0x0800), length 74: 192.168.100.1 > 1.1.1.23: ICMP echo reply, id 1, seq 688, length 40

Finding:

When attempting to deliver communications to the IP address 192.168.100.1, the router uses its default gateway.  This is because the IP address 192.168.100.1 does not belong to any of the known routes for the router.  The first line in the capture shows the router sending the packet to the ISP (the default gateway’s MAC address).  As can be seen in the second line, the cable modem responded to the ping.  Essentially the cable modem intercepted the packet destined for the gateways MAC address and responded.