lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Thu, 08 May 2008 23:22:59 +0200
From: Marc Ruef <marc.ruef@...putec.ch>
To: full-disclosure@...ts.grok.org.uk, pen-test@...urityfocus.com, 
	news@...uriteam.com, webappsec@...urityfocus.com
Subject: browserrecon project

I would like to present my new project named browserrecon. The framework 
provides the possibility of advanced web browser fingerprinting:

     http://www.computec.ch/projekte/browserrecon/

Most of todays tools for fingerprinting are focusing on server-side 
services. Well-known and widely-accepted implementations of such 
utilities are available for http web services, smtp mail server, ftp 
servers and even telnet daemons. Of course, many attack scenarios are 
focusing on server-side attacks.

Client-based attacks, especially targeting web clients, are becoming 
more and more popular. Browser-targeted attacks, drive-by pharming and 
web-based phishing provide a broad aspect of threats during surfing in 
the world wide web. Attacker might initialize and optimize their attacks 
by fingerprinting the target application to find the best possible way 
to compromise the client.

The browserrecon project is going to prove, that client-side 
fingerprinting is possible and useful too. In this particular 
implementation, currently available in php only, the given web browser 
is identified by the used http requests. Similar to the http 
fingerprinting provided within httprecon 
(http://www.computec.ch/projekte/httprecon/) the header lines and values 
are analyzed and compared to a fingerprint database.

The current implementation of browserrecon is provided as a php script 
and ready for live testing on the project web site. However, all 
web-based scripting languages that are able to access the http headers 
sent by the client are able to provide the same functionality. Further 
ports to ASP.NET, JSP and classic CGI are possible. Even the web server 
itself or an inline device (e.g. a sniffer or a firewall) might be able 
to do the same fingerprinting of the http request behavior.

A very similar approach for client-side application fingerprinting can 
be applied to other services and clients too. For example mail clients 
can be identified by their individual smtp and pop3 command chains. Or 
ftp clients might be determined by their specific command sequences.

During the analysis of the different fingerprints some very clear 
aspects could be found to divide the major web clients. A quick overview 
regarding the basic concepts shall be shown as an introduction to web 
browser fingerprinting:

* Microsoft Internet Explorer

The accept headers always begin with "image/gif" and do include 
"image/x-xbitmap" for Microsofts bmp images. Furthermore the extensions 
of Microsoft Office are included by default too (e.g. 
"application/vnd.ms-excel" for Word documents). The objects of the 
accept-encoding are delimited by a comma. Microsoft Internet Explorer is 
the only browser branch which also uses a space after the comma for the 
listing. The ua-headers were introduced by Microsoft with Internet 
Explorer 7.0 If one of them (ua-cpu, ua-os, ua-colors, ua-pixels) is 
used, you can tell which Internet Explorer version might be used. It 
seems like the current releases use "ua-cpu" only (e.g. x86 or AMD64).

* Mozilla Firefox

Most browsers do use a first letter capitalized "Keep-Alive" within the 
connection line. Mozilla Firefox uses the only implementation with a 
small "keep-alive" all the time. The clients of the Mozilla project 
usually involve a Keep-Alive value of 300. Such a value can never be 
found while using a Microsoft Internet Explorer.

* Opera

Most browsers do announce their preferred charset with a capitalized 
"ISO-8859-1". However, Opera is using a lower-case announcement of the 
form "iso-8859-1" within the accept-charset header. This only affects 
the ISO letters, no further encoding details (e.g. utf-8 is written 
non-capitalized only). Opera has usually the characteristic announcement 
of utf-8 and utf-16. The expected language defined in accept-language is 
usually written in small letters (e.g. de-ch for german/swiss). Opera is 
the only browser capitalizing the second definition (e.g. de-CH). And 
Opera is one of the few browsers which usually includes a te line.

* Netscape Navigator

The Netscape Navigator introduced the support for png images around 4.x. 
In the older versions of 3.x the accept line shows "image/gif, 
image/x-xbitmap, image/jpeg, image/pjpeg, */*". Later we can see the 
enhanced version including png: "image/gif, image/x-xbitmap, image/jpeg, 
image/pjpeg, image/png, */*". Furthermore, old Navigators 3.x did not 
announce the language of the operating system within the user-agent 
line. Within the 4.x series the language was written surrounded by 
brackets like [en] for english. The current release 9.x use the common 
syntax en-US as a remark.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ