IoT has an identity problem. Here’s how to solve it

Listen to post: Getting your Trinity Audio player ready...

Successfully Identifying operating systems in organizations has become a crucial part of network security and asset management products. With this information, IT and security departments can gain greater visibility and control over their network. When a software agent is installed on a host, this task becomes trivial. However, several OS types, mainly for embedded and IoT devices, are unmanaged or aren’t suitable to run an agent.

Fortunately, identification can also be done with a much more passive method, that doesn’t require installation of software on endpoint devices and works for most OS types. This method, called passive OS fingerprinting, involves matching uniquely identifying patterns in the network traffic a host produces, and classifying it accordingly. In most cases, these patterns are evaluated on a single network packet, rather than a sequence of flows between a client host and a server.

There exist several protocols, from different network layers that can be used for OS fingerprinting. In this post we will cover those that are most commonly used today. Figure 1 displays these protocols, based on the Open Systems Interconnection (OSI) model. As a rule of thumb, protocols at the lower levels of the OSI stack provide better reliability with lower granularity compared to those on the upper levels of stack, and vice versa.

Figure 1: Different network protocols for OS identification based on the OSI model

Starting from the bottom of the stack, at the data link layer, exists the medium access control (MAC) protocol. Over this protocol, a unique physical identifier, called the MAC address, is allocated to the network interface card (NIC) of each network device. The address, which is hardcoded into the device at manufacturing, is composed of 12 hexadecimal digits, which are commonly represented as 6 pairs divided by hyphens. From these hexadecimal digits, the leftmost six represent the manufacturer’s unique identifier, while the rightmost six represent the serial number of the NIC. In the context of OS identification, using the manufacturer’s unique identifier, we can infer the type of device running in the network, and in some cases, even the OS.

In Figure 2, we see a packet capture from a MacBook laptop communicating over Ethernet. The 6 leftmost digits of the source MAC address are 88:66:5a, and affiliated with “Apple, Inc.” manufacturer.

Figure 2: an “Apple, Inc.” MAC address in the data link layer of a packet capture

Moving up the stack, at the network and transport layers, is a much more granular source of information, the TCP/IP stack.  Fingerprinting based on TCP/IP information stems from the fact that the TCP and IP protocols have certain parameters, from the header segment of the packet, that are left up for implementation, and most OSes select unique values for these parameters.

Cato Networks SASE Threat Research Report H2/2022 | Download the Report

Some of the most commonly used today for identification are initial time to live (TTL), Windows Size, “Don’t Fragment” flag, and TCP options (values and order). In Figure 3 and Figure 4, we can see a packet capture of a MacBook laptop initiating a TCP connection to a remote server. For each outgoing packet, The IP header includes a combination of flags and an initial TTL value that is common for MacOS hosts, as well as the first “SYN” packet of the TCP handshake with the Windows Size value and the set of TCP options. The combination of these values is sufficient to identify this host as a MacOS.

Figure 3: Different header values from the IP protocol in the network layer

Figure 4: Different header values from the TCP protocol in the transport layer

At the upper most level of the stack, in the application layer, several different protocols can be used for identification. While providing a high level of granularity, that often indicates not only the OS type but also the exact version or distribution, some of the indicators in these protocols are open to user configuration, and therefore, provide lower reliability.

Perhaps the most common protocol in the application level used for OS identification is HTTP. Applications communicating over the web often add a User-Agent field in the HTTP headers, which allows network peers to identify the application, OS, and underlying device of the client.

In Figure 5, we can see a packet capture of an HTTP connection from a browser. After the TCP handshake, the first HTTP request to the server contains a User-Agent field which identifies the client as a Firefox browser, running on a Windows 7 OS.

Figure 5: Detecting a Windows 7 OS from the User-Agent field in the HTTP headers

However, the User-Agent field, is not the only OS indicator that can be found over the HTTP protocol. While being completely nontransparent to the end-user, most OSes have a unique implementation of connectivity tests that automatically run when the host connects to a public network. A good example for this scenario is Microsoft’s Network Connectivity Status Indicator (NCSI). The NCSI is an internet connection awareness protocol used in Microsoft’s Windows OSes. It is composed of a sequence of specifically crafted DNS and HTTP requests and responses that help indicate if the host is located behind a captive portal or a proxy server.  In Figure 6, we can see a packet capture of a Windows host performing a connectivity test based on the NCSI protocol. After a TCP handshake is conducted, an HTTP GET request is sent to http://www.msftncsi.com/ncsi.txt.

Figure 6: Windows host running a connectivity test based on the NCSI protocol

The last protocol we will cover in the application layer, is DHCP. The DHCP protocol, used for IP assignment over the network. Overall, this process is composed of 4 steps: Discovery, Offer, Request and Acknowledge (DORA). In these exchanges, several granular OS indicators are provided in the DHCP options of the message. In Figure 7, we can see a packet capture of a client host (192.168.1.111) that is broadcasting DHCP messages over the LAN and receiving replies from a DHCP server (192.168.1.1). The first DHCP Inform message, contains the DHCP option number 60 (vendor class identifier) with the value of “MSFT 5.0”, associated with a Microsoft Windows client. In addition, the DHCP option number 55 (parameter request list) contains a sequence of values that is common for Windows OSes. Combined with the order of the DHCP options themselves, these indicators are sufficient to identify this host as a Windows OS.

Figure 7: Using DHCP options for OS identification

Wrapping up

In this post, we’ve introduced the task of OS identification from network traffic and covered some of the most commonly used protocols these days. While some protocols provide better accuracy than others, there is no ‘silver bullet’ for this task, and we’ve seen the tradeoff between granularity and reliability with the different options. Rather than fingerprinting based on a single protocol, you might consider a multi-protocol approach. For example, an HTTP User-Agent combined with lower-level TCP options fingerprint.