Application Fingerprinting: Banners | Active Scanning Technology

An important activity in a scan is to determine what applications make themselves known on the network. Similar to OS fingerprinting and IP stack fingerprinting, a vulnerability scanner can attempt to connect to a variety of possible applications on known or unknown ports, a process known as featureprinting. Among the best-known featureprinting methods is banner checking.

Some common applications on systems produce a banner whenever you attempt to connect. The contents of this banner can provide valuable information in determining the version of the OS and the software running on the host. This type of fingerprinting can often be performed by an individual using a simple program available on almost all OS platforms: Netcat.

Let’s take the example of a Web server. Figure 1 shows a typical Netcat session. When using Netcat, you can specify the TCP port to which you wish to connect. So, in the command line, we type “nc 10.1.1.10 80.” This will run the Telnet application and establish a connection to the server listening for connections on port 80.

$ nc 10.1.1.10 80 Apache Example HEAD / HTTP/1.0 HTTP/1.1 200 OK Date: Tue, 06 May 2008 23:32:00 GMT Server: Apache/2.2.8 (Unix) Last-Modified: Tue, 29 Apr 2008 21:52:29 GMT ETag: "ea9d61-48f6-44c0a0c71a140" Accept-Ranges: bytes Content-Length: 18678 Cache-Control: max-age=86400 Expires: Wed, 07 May 2008 23:32:00 GMT Vary: Accept-Encoding Connection: close Content-Type: text/html $_

(a)

$ nc 10.1.1.20 80 IIS Example HEAD / HTTP/1.0 HTTP/1.1 302 Found Cache-Control: private Content-Length: 142 Content-Type: text/html; charset=utf-8 Location: /en/us/default.aspx Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI" X-Powered-By: ASP.NET Date: Tue, 06 May 2008 23:58:41 GMT Connection: keep-alive $_

(b)

Figure 1: A typical Netcat session.

From here, we are able to issue a command to the remote server. Since this is port 80, it is likely a Web server; so we issue the command: “HEAD/HTTP/1.0” (Figure 1a). The server responds with some detailed header information, which tells the type of Web server software and OS. In this case, it is Apache^® running on a UNIX^® system. This eliminates the possibility of any version of Windows and makes searching for vulnerabilities much easier.

For security reasons, however, server administrators should conceal this header information, particularly that information which is in the “Server” section. But, that will not deter a good vulnerability scanner. The scanner may also be able to check for the type of Web server by making an invalid request. By using an invalid version type in the HEAD command, we can see different responses from the various Web server makers. Notice that the Apache Web server comes out with a “400 Bad Request” message (Figure 1b). The connection also gets closed; however, on IIS 7.0, the connection is not closed but the same “400 Bad Request” message is received. But, you will also notice that more server information is provided that was not found in the valid request. In earlier versions of IIS, you could distinguish it from a reaction of providing a message of “200 OK.” Similar methods are used where valid and invalid responses are captured and analyzed. In some cases, these are reported as vulnerabilities or simply information exposures.