[<prev] [next>] [day] [month] [year] [list]
Message-ID: <48236F33.80706@computec.ch>
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