DHCP Fingerprinting

DHCP Fingerprinting

DHCP Fingerprinting is a method of detecting the end device OS based on the dhcp exchange packets. In today’s network where we are talking about IoE , BYOD it is required to identify the devices in your network and mark them accordingly.

Why do we need Fingerprinting:

With BYOD personal devices are making their way into the workplace, and it is a tough job for the network administrators to dynamically detect these devices and make sure these devices are compliant and to enforce required polices on these devices. Detecting the devices type/OS is also part of the play.

Due to the proliferation of BYOD (Bring Your Own Devices)/mobile devices connecting mostly over the Wireless Network, it becomes difficult to identify and control the types of devices that can connect to the network, and once connected, to determine what access privileges they might have.

With DHCP Fingerprinting, DHCP Servers or devices like IPAM Controllers or Wireless Controllers, can use DHCP Fingerprinting to identify the device type, manufacturer name and OS of the clients/devices connecting to the network, categorize them into ACLs, and control which device can connect to the network and what it can do.

How it works:

DHCP Fingerprinting is one of the methods that help us in identifying the OS on the devices bases on the dhcp option.

The complete DHCP process is like this:

The DHCP packets contain multiple options. One of the most important option which is used for dhcp fingerprinting is the option : 55 called Parameter request list, this option is present in the packets sent from the client end i.e the Discover and Request Packets.

The option 55: Parameter Request list in the above capture is :

1,6,15,44,3,33,150 and 43

A DHCP discover request asks for DHCP options in a specific sequence. This makes DHCP Fingerprinting possible – identifying a device or OS requesting an IP address based on the requested DHCP options.

Fingerbank has got a repository of such fingerprints:

https://fingerbank.inverse.ca/

Some of the captured fingerprints in hex:

Android_device    3C64686370636420342E302E3135
Android 2.X           3c6468637063642034
Android 2.2           3701792103061c333a3b
Android 2.3.X        0c616E64726F69645F
Android 4.0.X        37012103060f1c333a3b
Android 4.0.X(2)    37012103061c333a3b
Blackberry 2          3C426C61636B4265727279
Blackberry(2)         370103060F775ffc2c2e2f
iOS Device             370103060F77FC
iPad                        37011c02030f06770c2c2f1a792a
OS X 10.6               370103060f775ffc2c2e2f
OS X 10.7               370103060f775ffc2c2e
Win Mobile            3c4d6963726f736f66742057696e646f77732043450
Win Mobile6          370103060f2c2e2f

Aruba implementation of DHCP Fingerprinting:

http://community.arubanetworks.com/t5/Unified-Wired-Wireless-Access/COTD-DHCP-Fingerprinting-how-to-ArubaOS-6-0-1-0-and-above/td-p/11164

http://community.arubanetworks.com/t5/Controller-less-WLANs/DHCP-FINGERPRINTING-WITH-Aruba-Instant/ta-p/183272

Happy Reading….

Understanding Browser’s user-agent

Understanding Browser’s user-agent

So basically the user-agent string is something which identifies your browser and provides certain system details to servers hosting the webpage you are visiting. When you visit a webpage, the browser sends the user-agent string to the server hosting the page that you are visiting. This string indicates which browser is being used, its version number, and details about your system, such as operating system and version. The web server can use this information to provide content that is tailored for your specific browser. 

You can see the user-agent in the wireshark captures when you machine sends out the GET request or on the browser itself.

You can also check the user-agent on the browser itself. Lets see how:

Chrome:

Type chrome://version in the address bar.

FireFox:

Type about: in the address bar.

Internet Explorer:

Type javascript:alert(navigator.userAgent) in the address bar, the user-agent string would show up in a dialog box. You can do CTRL+C to copy it.

While we might be considered user agent sniffing a horrible practice on the client side, however sniffing user agent is done quite a bit on the server side to serve up the appropriate page version of a site, or redirect to, for example, the mobile version of the site.  This can be a dangerous road but most large site with a separate mobile interface do it.

The following is the user agent for Firefox on a mobile device:

Mozilla/5.0 (Mobile; rv:18.0) Gecko/18.0 Firefox/18.0

History of User Agent:

I came across this blog which talks about the history of User-Agent.

https://webaim.org/blog/user-agent-string-history/

In the beginning there was NCSA Mosaic, and Mosaic called itself NCSA_Mosaic/2.0 (Windows 3.1), and Mosaic displayed pictures along with text, and there was much rejoicing. And behold, then came a new web browser known as “Mozilla”, being short for “Mosaic Killer,” but Mosaic was not amused, so the public name was changed to Netscape, and Netscape called itself Mozilla/1.0 (Win3.1), and there was more rejoicing. And Netscape supported frames, and frames became popular among the people, but Mosaic did not support frames, and so came “user agent sniffing” and to “Mozilla” webmasters sent frames, but to other browsers they sent not frames.

And Netscape said, let us make fun of Microsoft and refer to Windows as “poorly debugged device drivers,” and Microsoft was angry. And so Microsoft made their own web browser, which they called Internet Explorer, hoping for it to be a “Netscape Killer”. And Internet Explorer supported frames, and yet was not Mozilla, and so was not given frames. And Microsoft grew impatient, and did not wish to wait for webmasters to learn of IE and begin to send it frames, and so Internet Explorer declared that it was “Mozilla compatible” and began to impersonate Netscape, and called itself Mozilla/1.22 (compatible; MSIE 2.0; Windows 95), and Internet Explorer received frames, and all of Microsoft was happy, but webmasters were confused.And Microsoft sold IE with Windows, and made it better than Netscape, and the first browser war raged upon the face of the land. And behold, Netscape was killed, and there was much rejoicing at Microsoft. But Netscape was reborn as Mozilla, and Mozilla built Gecko, and called itself Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826, and Gecko was the rendering engine, and Gecko was good. And Mozilla became Firefox, and called itself Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.7.5) Gecko/20041108 Firefox/1.0, and Firefox was very good. And Gecko began to multiply, and other browsers were born that used its code, and they called themselves Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040825 Camino/0.8.1 the one, and Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.8) Gecko/20071008 SeaMonkey/1.0 another, each pretending to be Mozilla, and all of them powered by Gecko. 

And Gecko was good, and IE was not, and sniffing was reborn, and Gecko was given good web code, and other browsers were not. And the followers of Linux were much sorrowed, because they had built Konqueror, whose engine was KHTML, which they thought was as good as Gecko, but it was not Gecko, and so was not given the good pages, and so Konquerer began to pretend to be “like Gecko” to get the good pages, and called itself Mozilla/5.0 (compatible; Konqueror/3.2; FreeBSD) (KHTML, like Gecko) and there was much confusion. Then cometh Opera and said, “surely we should allow our users to decide which browser we should impersonate,” and so Opera created a menu item, and Opera called itself Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; en) Opera 9.51, or Mozilla/5.0 (Windows NT 6.0; U; en; rv:1.8.1) Gecko/20061208 Firefox/2.0.0 Opera 9.51, or Opera/9.51 (Windows NT 5.1; U; en) depending on which option the user selected.

And Apple built Safari, and used KHTML, but added many features, and forked the project, and called it WebKit, but wanted pages written for KHTML, and so Safari called itself Mozilla/5.0 (Macintosh; U; PPC Mac OS X; de-de) AppleWebKit/85.7 (KHTML, like Gecko) Safari/85.5, and it got worse.

And Microsoft feared Firefox greatly, and Internet Explorer returned, and called itself Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0) and it rendered good code, but only if webmasters commanded it to do so. And then Google built Chrome, and Chrome used Webkit, and it was like Safari, and wanted pages built for Safari, and so pretended to be Safari. And thus Chrome used WebKit, and pretended to be Safari, and WebKit pretended to be KHTML, and KHTML pretended to be Gecko, and all browsers pretended to be Mozilla, and Chrome called itself Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13, and the user agent string was a complete mess, and near useless, and everyone pretended to be everyone else, and confusion abounded.

More on user-agent and how to modify it:

https://msdn.microsoft.com/en-us/library/ms537503.aspx#ViewingUA

https://www.howtogeek.com/113439/how-to-change-your-browsers-user-agent-without-installing-any-extensions/

http://www.howtogeek.com/howto/18519/how-to-change-the-user-agent-string-in-firefox/

https://www.maketecheasier.com/change-browser-user-agents/

Happy Reading…..