Download web security -cyber activity and more Lecture notes Computer Science in PDF only on Docsity!
HTTP FINGERPRINTING
HTTP Fingerprinting is a relatively new topic of discussion in the context of application security.
One of the biggest challenges of maintaining a high level of network security is to have a
complete and accurate inventory of networked assets. Web servers and web applications have
now become a part of the scope of a network security assessment exercise. In this paper, we
present techniques to identify various types of HTTP servers. We shall discuss some of the
problems faced in inventorying HTTP servers and how we can overcome them.
We shall also introduce and describe a tool, httprint , which is built using the concepts discussed
in this paper.
2. Theory of Fingerprinting
A fingerprint is defined as:
1. The impression of a fingertip on any surface; also: an ink impression of the lines upon the
fingertip taken for the purpose of identification.
2. something that identifies: as (a) a trait, trace, or characteristic revealing origin or
responsibility (b) analytical evidence that characterizes an object or substance.
The process of fingerprinting can be broken up into two sub processes, namely gathering and
classification of fingerprints, and comparision of unknown fingerprints with the stored database
of known fingerprints.
While gathering fingerprints, it is essential to capture all the key characteristics of the object
revealed in the fingerprint. Capturing more details and traits helps in the comparision process.
While comparing fingerprints, there may be chances that a fingerprint can be improperly
matched, because of subtle differences that can be easily mistaken.
Fingerprinting is a known technique in network security. [1]
3. Banner grabbing
The simplest and most basic form of identifying HTTP servers is to look at the Server field in the HTTP response header [2]. Using a TCP client like netcat [3], it is possible to send an HTTP request to return the HTTP response header of the server, as shown below: $ nc 202.41.76.251 80 HEAD / HTTP/1.
HTTP/1.1 200 OK Date: Mon, 16 Jun 2003 02:53:29 GMT Server: Apache/1.3.3 (Unix) (Red Hat/Linux) Last-Modified: Wed, 07 Oct 1998 11:18:14 GMT ETag: "1813-49b-361b4df6" Accept-Ranges: bytes Content-Length: 1179
Connection: close Content-Type: text/html
Three examples of the HTTP response header are shown below: From an Apache 1.3.23 server: HTTP/1.1 200 OK Date: Sun, 15 Jun 2003 17:10:49 GMT Server: Apache/1.3. Last-Modified: Thu, 27 Feb 2003 03:48:19 GMT ETag: "32417-c4-3e5d8a83" Accept-Ranges: bytes Content-Length: 196 Connection: close Content-Type: text/html
From a Microsoft IIS 5.0 server: HTTP/1.1 200 OK Server: Microsoft-IIS/5. Expires: Tue, 17 Jun 2003 01:41:33 GMT Date: Mon, 16 Jun 2003 01:41:33 GMT Content-Type: text/html Accept-Ranges: bytes Last-Modified: Wed, 28 May 2003 15:32:21 GMT ETag: "b0aac0542e25c31:89d" Content-Length: 7369
From a Netscape Enterprise 4.1 server: HTTP/1.1 200 OK Server: Netscape-Enterprise/4. Date: Mon, 16 Jun 2003 06:19:04 GMT Content-type: text/html Last-modified: Wed, 31 Jul 2002 15:37:56 GMT Content-length: 57
HTTP/1.1 200 OK
Server: Yes we are using ServerMask Date: Mon, 16 Jun 2003 02:54:17 GMT Connection: Keep-Alive Content-Length: 18273 Content-Type: text/html Set-Cookie: It works on cookies too=82.3S3.O12.NT2R0RE,4147ON3P,.4OO.; path=/ Cache-control: private
As we can see from the above examples, relying purely upon the contents of the server banner string is not enough for identifying the type of HTTP server.
6. Protocol behaviour
Almost all HTTP servers differ in the way they implement the HTTP protocol. In the case where the HTTP request is well formed and legitimate, the response returned by all HTTP servers is more or less compliant with the specifications laid out in the RFCs for HTTP[5]. However, when confronted with malformed HTTP requests, these servers differ in their responses. Differences in the way the HTTP protocol is handled by various HTTP servers forms the basis of the HTTP fingerprinting technique. Let us illustrate these differences with examples. We shall analyse the response to four HTTP requests, coming from an Apache 1.3.23 server, a Microsoft IIS 5.0 server and a Netscape Enterprise 4.1. The requests are: HTTP Test What to expect HEAD / HTTP/1.0 (^) Normal HTTP header response DELETE / HTTP/1.0 Response when operations such as DELETE aren't generally allowed GET / HTTP/3.0 (^) Response to a request with an improper HTTP protocol number GET / JUNK/1.0 (^) Response to a request with an improper protocol specification In each of these responses, we shall identify key differences between the responses of Apache 1.3.23, IIS 5.0 and Netscape Enterprise 4.1. We shall not take into consideration differences in customizable parameters such as the server banner string.
6.1 HTTP header field ordering
Taking the first request HEAD / HTTP/1.0 , we shall analyse the HTTP response header and inspect the order of appearance of the various fields returned within it. Response from Apache 1.3. $ nc apache.example.com 80 HEAD / HTTP/1.
HTTP/1.1 200 OK
Date: Sun, 15 Jun 2003 17:10:49 GMT Server: Apache/1.3. Last-Modified: Thu, 27 Feb 2003 03:48:19 GMT ETag: "32417-c4-3e5d8a83" Accept-Ranges: bytes Content-Length: 196 Connection: close Content-Type: text/html
Response from IIS 5. $ nc iis.example.com 80 HEAD / HTTP/1.
HTTP/1.1 200 OK
Server: Microsoft-IIS/5. Content-Location: http://iis.example.com/Default.htm Date: Fri, 01 Jan 1999 20:13:52 GMT Content-Type: text/html Accept-Ranges: bytes Last-Modified: Fri, 01 Jan 1999 20:13:52 GMT ETag: W/"e0d362a4c335be1:ae1" Content-Length: 133
Response from Netscape Enterprise 4. $ nc netscape.example.com 80 HEAD / HTTP/1.
HTTP/1.1 200 OK
Server: Netscape-Enterprise/4. Date: Mon, 16 Jun 2003 06:01:40 GMT Content-type: text/html Last-modified: Wed, 31 Jul 2002 15:37:56 GMT Content-length: 57 Accept-ranges: bytes
Server: Netscape-Enterprise/4. Date: Mon, 16 Jun 2003 06:03:18 GMT WWW-authenticate: Basic realm="WebServer Server" Content-length: 223 Content-type: text/html Connection: close
Apache responds with a 405 "Method not allowed" response, IIS responds with a 403 "Operation on resource forbidden" response, and Netscape responds with a 401 "Authorization credentials required" response. Each of the servers differs in their response to the DELETE request. 6.3 Improper HTTP version response The next test consists of sending an HTTP request with an improper HTTP version number, such as GET / HTTP/3.0 , to the server. HTTP 3.0 is not even in existence as of this writing, and none of the candidate servers implement it. Response from Apache 1.3. $ nc apache.example.com 80 GET / HTTP/3.
HTTP/1.1 400 Bad Request Date: Sun, 15 Jun 2003 17:12:37 GMT Server: Apache/1.3. Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-
Response from IIS 5. $ nc iis.example.com 80 GET / HTTP/3.
HTTP/1.1 200 OK
Server: Microsoft-IIS/5. Content-Location: http://iis.example.com/Default.htm Date: Fri, 01 Jan 1999 20:14:02 GMT Content-Type: text/html
Accept-Ranges: bytes Last-Modified: Fri, 01 Jan 1999 20:14:02 GMT ETag: W/"e0d362a4c335be1:ae1" Content-Length: 133
Response from Netscape Enterprise 4. $ nc netscape.example.com 80
GET / HTTP/3.
HTTP/1.1 505 HTTP Version Not Supported Server: Netscape-Enterprise/4. Date: Mon, 16 Jun 2003 06:04:04 GMT Content-length: 140 Content-type: text/html Connection: close
Apache responds with a 400 "Bad HTTP request" response, IIS ignores the improper HTTP protocol number, and responds with a 200 "OK" along with the contents of the HTML data for the root document, and Netscape responds with a 505 "HTTP version not supported" response. 6.4 Improper protocol response The next test involves observing the response to the request GET / JUNK/1.. Response from Apache 1.3. $ nc apache.example.com 80 GET / JUNK/1.
HTTP/1.1 200 OK
Date: Sun, 15 Jun 2003 17:17:47 GMT Server: Apache/1.3. Last-Modified: Thu, 27 Feb 2003 03:48:19 GMT ETag: "32417-c4-3e5d8a83" Accept-Ranges: bytes Content-Length: 196 Connection: close Content-Type: text/html
Response from IIS 5.
