Project: WASC Threat Classification
Threat Type: Attack
Reference ID: WASC-45
The most common methodology for attackers is to first footprint the target's web presence and enumerate as much information as possible. With this information, the attacker may develop an accurate attack scenario, which will effectively exploit a vulnerability in the software type/version being utilized by the target host.
Multi-tier fingerprinting is similar to its predecessor, TCP/IP Fingerprinting (with a scanner such as Nmap) except that it is focused on the Application Layer of the OSI model instead of the Transport Layer. The theory behind this fingerprinting is to create an accurate profile of the target's platform, web application software technology, backend database version, configurations and possibly even their network architecture/topology.
Accurately identifying this type of information for possible attack vectors is vitally important since many security vulnerabilities (SQL injections and buffer overflows, et al) are extremely dependent on a specific software vendor and version number. Additionally, correctly identifying the software versions and choosing an appropriate exploit reduces the overall "noise" of the attack while increasing its effectiveness. It is for this reason that a web server/application, which obviously identifies itself, is inviting trouble.
We will outline fingerprinting techniques for the following categories:
It is advantageous to an attacker to accurately identify any intermediary web-based systems such as proxy servers, load-balancers or web application firewalls. With this information, an attacker may be able to alter their attack payload to attempt to bypass the security filtering of these systems or they may even become targets themselves (such as with HTTP Response Splitting attacks).
There are different approaches to the typical web server architecture. Surrogate or reverse proxy accelerators are gateways co-located with an origin server. They delegate the authority to operate on behalf of one or more origin server, and typically working in close co-operation with them. Responses are typically delivered from an internal cache. http://www.ietf.org/rfc/rfc3040.txt
The Via general-header field must be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server on requests, and between the origin server and the client on responses.
Proxies and gateways used as a portal through a network firewall should not, by default, forward the names and ports of hosts within the firewall region.
Note: Comments may be used in the Via header field to identify the software of the recipient proxy or gateway, analogous to the User-Agent and Server header fields. However, all comments in the Via field are optional and may be removed by any recipient prior to forwarding the message. http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
In the following example, we are using netcat to connect to the web-surrogated website. Notice the "Via:" token portion of the HTTP Response Headers reveals the exact version of gateway server software being used:
$ nc www.surrogated.com 80 GET / HTTP/1.0 HTTP/1.0 400 Bad Request Server: Squid/2.5-DEVEL Mime-Version: 1.0 Date: Wed, 14 Mar 2008 09:18:26 GMT Content-Type: text/html Via: 1.0 proxy.surrogated.com:65535 (Squid/2.5-Devel) Proxy-Connection: close
Correctly identifying the web server version can be accomplished through the following steps:
The quickest and easiest way for attackers to identify the target web server software is to simply review the information returned by the target webserver in the "Server:" token. In fact, the HTTP RFC 2616 discusses this exact issue and urges web administrators to take steps to hide the version of software being displayed by the "Server" response header:
Note: Revealing the specific software version of the server may allow the server machine to become more
vulnerable to attacks against software that is known to contain security holes. Server implementers are
encouraged to make this field a configurable option.
In the following example, we are using netcat to connect to the Microsoft website. Notice the "Server:" token portion of the HTTP Response Headers reveals the exact version of web server software being used:
$ nc www.microsoft.com 80 GET / HTTP/1.0 HTTP/1.1 302 Found Cache-Control: private 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 C NT COM INT NAV ONL PHY PRE PUR UNI" X-Powered-By: ASP.NET Date: Sat, 14 Jul 2007 15:22:26 GMT Connection: keep-alive Content-Length: 136
Most current web servers now have functionality that will allow Administrators to alter this information. It is for this reason that attackers must use these other techniques to confirm the platform information.
The lexical characteristics category covers variations in the actual words/phrases used, capitalization and punctuation displayed by the HTTP response headers.
For the error code 404, Apache reports "Not Found" whereas Microsoft IIS/5.0 reports "Object Not Found".
Apache 1.3.29
# nc target1.com 80 HEAD /non-existent-file.txt HTTP/1.0 HTTP/1.1 404 Not Found Date: Mon, 07 Jun 2004 14:31:03 GMT Server: Apache/1.3.29 (Unix) mod_perl/1.29 Connection: close Content-Type: text/html; charset=iso-8859-1
Microsoft-IIS/5.0
# nc target2.com 80 HEAD /non-existent-file.txt HTTP/1.0 HTTP/1.1 404 Object Not Found Server: Microsoft-IIS/5.0 Date: Mon, 07 Jun 2004 14:41:22 GMT Content-Length: 461 Content-Type: text/html
The header "Content-Length" is returned vs. "Content-length".
Netscape-Enterprise/6.0
# nc target1.com 80 HEAD / HTTP/1.0 HTTP/1.1 200 OK Server: Netscape-Enterprise/6.0 Date: Mon, 07 Jun 2004 14:55:25 GMT Content-length: 26248 Content-type: text/html Accept-ranges: bytes
Microsoft-IIS/5.0
# nc target2.com 80 HEAD / HTTP/1.0 HTTP/1.1 404 Object Not Found Server: Microsoft-IIS/5.0 Date: Mon, 07 Jun 2004 15:22:54 GMT Content-Length: 461 Content-Type: text/html
Per the HTTP RFC, all web communications are required to have a predefined structure and composition so that both parties can understand each other. Variations in the HTTP response header ordering and format still exist.
Apache servers consistently place the "Date" header before the "Server" header while Microsoft-IIS has these headers in the reverse order [2].
Apache 1.3.29
# nc target1.com 80 HEAD / HTTP/1.0 HTTP/1.1 200 OK Date: Mon, 07 Jun 2004 15:21:24 GMT Server: Apache/1.3.29 (Unix) mod_perl/1.29 ...
Microsoft-IIS/4.0
# nc target2.com 80 HEAD / HTTP/1.0 HTTP/1.1 404 Object Not Found Server: Microsoft-IIS/4.0 Date: Mon, 07 Jun 2004 15:22:54 GMT ...
When an OPTIONS method is sent in an HTTP request, a list of allowed methods for the given URI are returned in an "Allow" header. Apache only returns the "Allow" header, while IIS also includes a "Public" header. [3]
Apache 1.3.29
# nc target1.com 80 OPTIONS * HTTP/1.0 HTTP/1.1 200 OK Date: Mon, 07 Jun 2004 16:21:58 GMT Server: Apache/1.3.29 (Unix) mod_perl/1.29 Content-Length: 0 Allow: GET, HEAD, OPTIONS, TRACE Connection: close
Microsoft-IIS/5.0
# nc target2.com 80 OPTIONS * HTTP/1.0 HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Date: Mon, 7 Jun 2004 12:21:38 GMT Content-Length: 0 Accept-Ranges: bytes DASL: <DAV:sql> DAV: 1, 2 Public: OPTIONS, TRACE, GET, HEAD, DELETE, PUT, POST, COPY, MOVE, MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, SEARCH Allow: OPTIONS, TRACE, GET, HEAD, DELETE, PUT, POST, COPY, MOVE, MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, SEARCH Cache-Control: private
Besides the words and phrases that are returned in the HTTP Response, there are obvious differences in how web servers interpret both well- formed and abnormal/non compliant requests.
A server has a choice of headers to include in a response. While some headers are required by the specification, most headers (e.g. ETag) are optional. In the examples below, the Apache server's response headers include additional entries such as: ETag, Vary, Expires, et cetera, while the IIS server does not.
Apache 1.3.29
# nc target1.com 80 HEAD / HTTP/1.0 HTTP/1.1 200 OK Date: Mon, 07 Jun 2004 15:21:24 GMT Server: Apache/1.3.29 (Unix) mod_perl/1.29 Content-Location: index.html.en Vary: negotiate,accept-language,accept-charset TCN: choice Last-Modified: Fri, 04 May 2001 00:00:38 GMT ETag: "4de14-5b0-3af1f126;40a4ed5d" Accept-Ranges: bytes Content-Length: 1456 Connection: close Content-Type: text/html Content-Language: en Expires: Mon, 07 Jun 2004 15:21:24 GMT
Microsoft-IIS/5.0
# nc target2.com 80 HEAD / HTTP/1.0 HTTP/1.1 404 Object Not Found Server: Microsoft-IIS/5.0 Date: Mon, 07 Jun 2004 15:22:54 GMT Content-Length: 461 Content-Type: text/html
Even though the same requests are made to the target web servers, it is possible for the interpretation of the request to be different and therefore different response codes generated. A perfect example of this semantic difference in interpretation is the "Light Fingerprinting" check which the Whisker scanner utilizes. The section of Perl code below, taken from Whisker 2.1's main.test file, runs two tests to determine if the target web server is in fact an Apache server, regardless of what the banner might report. The first request is a "GET //" and if the HTTP Status Code is a 200, then the next request is sent. The second request is "GET/%2f", which is URI Encoded - and translates to "GET //". This time Apache returns a 404 - Not Found error code. Other web servers - IIS - do not return the same status codes for these requests.
my $Aflag=0; $req{whisker}->{uri}='//'; if(!_do_request(\%req,\%G_RESP)){ _d_response(\%G_RESP); if($G_RESP{whisker}->{code}==200){ $req{whisker}->{uri}='/%2f'; if(!_do_request(\%req,\%G_RESP)){ _d_response(\%G_RESP); $Aflag++ if($G_RESP{whisker}->{code}==404); } } } m_re_banner('Apache',$Aflag);
After running Whisker against a target website, it reports, based on the pre-tests that the web server may in fact be an Apache server. Below is the example Whisker report section:
----------------------------------------------------------------------- Title: Server banner Id: 100 Severity: Informational The server returned the following banner: Microsoft-IIS/5.0 ----------------------------------------------------------------------- Title: Alternate server type Id: 103 Severity: Informational Testing has identified the server might be an 'Apache' server. This Change could be due to the server not correctly identifying itself (the Admins changed the banner). Tests will now check for this server type as well as the previously identified server types. -----------------------------------------------------------------------
Not only does this alert the attacker that the web server administrators are savvy enough to alter the Server banner info, but Whisker will also add in all of the Apache tests to its scan which would increase its accuracy.
After the web server platform software has been identified, the next step is to confirm what web application technologies are being used such as ASP, .NET, PHP and Java. There are many methods that can be used to identify the specific language's usage and most of them revolve around inspecting the URL components.
The first portion of the URL to inspect would be the file extensions used. The following list maps the most common file extensions to their corresponding scripting language and web server platform.
Extension Technology Server Platform --------- ---------- --------------- .pl Perl CGI script Generic; usually web servers running on Unix .asp Active Server Pages Microsoft IIS .aspx ASP+ Microsoft .NET .php PHP script Generic; usually interfaced with Apache .cfm ColdFusion Generic; usually interfaced with Microsoft IIS .nsf Lotus Domino Lotus Domino server .jsp Java Server Page Various platforms .do Java Struts Various platforms
There are many HTTP Response Headers that are unique to the web application software being used. For example, the following example shows that the target web server is running ASP .NET and even provides the exact version information in the X-AspNet-Version:
and X-Powered-By:
headers:
$ nc www.microsoft.com 80 GET / HTTP/1.0 HTTP/1.1 302 Found Cache-Control: private 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: Sat, 14 Jul 2007 15:22:26 GMT Connection: keep-alive Content-Length: 136
The naming conventions used in Cookie headers can often reveal the type of web application software being used:
Server Cookie ------ ------ Apache Apache=202.86.136.115.308631021850797729 IIS ASPSESSIONIDGGQGGCVC=KELHFOFDIHOIPLHJEBECNDME ATG Dynamo JSESSIONID=H4TQ0BVCTCDNZQFIAE0SFFOAVAAUIIV0 IBMNet.Data SESSION_ID=307823,wFXBDMkiwgAnRyij+iK1fg87gsw8e/ TUDq2n4VZKc+UyjEZq ColdFusion CFID=573208, CFTOKEN=86241965
Not only are the error pages generated by the various web applications unique in their text and formatting but the default configurations also often times reveal exact version information.
Server Error in '/' Application. -------------------------------------------------------------------------------- SQL Server does not exist or access denied. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Exception Details: System.Data.SqlClient.SqlException: SQL Server does not exist or access denied. Source Error: An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below. Stack Trace: [SqlException: SQL Server does not exist or access denied.] System.Data.SqlClient.ConnectionPool.GetConnection(Boolean& isInTransaction) +472 System.Data.SqlClient.SqlConnectionPoolManager.GetPooledConnection(SqlConnectionString options, Boolean& isInTransaction) +372 System.Data.SqlClient.SqlConnection.Open() +386 optCorp.Global1.Application_Error(Object sender, EventArgs e) System.EventHandler.Invoke(Object sender, EventArgs e) +0 System.Web.HttpApplication.RaiseOnError() +157 -------------------------------------------------------------------------------- Version Information: Microsoft .NET Framework Version:1.1.4322.2300; ASP.NET Version:1.1.4322.2300
Determining the database engine type is fundamental if an attacker is to attempt to successfully execute an SQL Injection attack. Most times this will be easy if the web application provides detailed error messages (as shown in the previous section). For example, ODBC will normally display the database type as part of the driver information when reporting an error.
In those cases where the error message is not an ODBC message that can also be useful. First, you know you are most probably not on a Windows box. By knowing what operating system and web server we are connecting to it is easier sometimes to deduce the possible database. Using specific characters, commands, stored procedures and syntax we can know with much more certainty what SQL database we have injected into.
The differences from one database to another will also determine what we can or cannot do. To notice, MySQL is the only one that does not support subqueries in its current release. Nevertheless, beta version 4.1 has implemented subqueries and will soon be released. The UNION statement was implemented in MySQL version 4.0. Batch queries are not very common and stored procedures are only available in MS SQL and Oracle. The more complete, flexible and OS integrated a database is, the more potential avenues of attack.
The following table shows some capability differences that can be used to determine what db is in use if there is no other easier way. By trying out conditions using the 'and condition and '1'='1
statement we can determine what type of database we have connected to.
CAPABILITIES MSSQL/T-SQL MySQL Access OraclePL/SQL DB2 PostgresPL/pgSQL _____________________________________________________________________________________________________ Concatenate Strings ''+'' concat("","") ""&"" ''||'' ""+"" ''||'' Null replace Isnull() Ifnull() Iff(Isnull()) Ifnull() Ifnull() COALESCE() Position CHARINDEX LOCATE() InStr() InStr() InStr() TEXTPOS() Op Sys interaction xp_cmdshell select into #date# utf_file import Call outfile/ from/ dumpfile export to
By adding a simple string concatenation to the sql query, we determine the database type. Text strings can even be added before and after the single or double quote. For example, by including the string te'||'st
in a query, a valid oracle query should be executed using the word “test” as input. Database specific functions can then be concatenated within the statement to further determine the database type.
More database differences (based on capabilities) are shown below and each of these could be used in sql testing probes to determine which DB is in use:
CAPABILITIES MSSQL MySQL Access Oracle DB2 Postgres ________________________________________________________________________________ UNION Y Y Y Y Y Y Subselects Y N4.0 N Y Y Y Y4.1 Batch Queries Y N* N N N Y Default stored procedures Many N N Many N N Linking DBs Y Y N Y Y N Cast Y N N N Y Y
Web services fingerprinting and enumeration begins with inspecting the target Web Services Definition Language or WSDL. A WSDL file is a major source of information for an attacker. Examining a WSDL description provides critical information like methods, input and output parameters. It is important to understand the structure of a WSDL file, based on which one should be able to enumerate web services. The outcome of this process is a web services profile or matrix. Once this is done, attack vectors for web services can be defined.
As we mentioned in a previous section, it possible to infer the technology being used by the file extensions. As an example, let us consider the following two discovery URLs:
This is part of .Net/J2EE frameworks resource for web services and web services can be developed/deployed using this type of resource. Hence, by just glancing at the set of characters containing the .asmx extension we can fingerprint this resource to .Net.
WSDL(web services definition language) is the file in which web services’ access information resides. To access web services, it is important to get a hold of this WSDL file. A URL can have wsdl extension as a file extension or can be part of a querystring. Examples underlining this fact are listed below.
Example:
http://example.com/servlet/customer.access.wsdl http://example.com/customer.asmx?wsdl http://example.com/customer.asmx/wsdl
Under normal conditions, web applications sit in between clients and the web service and only utilize the necessary functionality to perform the needed task. If a client were to bypass the web application and get direct access to the WSDL interface, then they could possibly discover capabilities that were not intended for normal client usage.
By manipulating the input data types that are sent to the WSDL, an attacker can enumerate sensitive information. In this example we are injecting meta-characters into the "id" parameter:
<?xml version="1.0" encoding="utf-16"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <soap:Body> <getProductInfo xmlns="http://tempuri.org/"> <id>"</id> </getProductInfo> </soap:Body> </soap:Envelope>
The response includes fault code information indicating that SQL Injection may be possible. These error messages will oftentimes provide details as to the version of backend database.
<?xml version="1.0" encoding="utf-16"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <soap:Body> <soap:Fault> <faultcode>soap:Server</faultcode> <faultstring>Server was unable to process request. --> Cannot use empty object or column names. Use a single space if necessary.</faultstring> <detail /> </soap:Fault> </soap:Body>
HMAP: A Technique and Tool for Remote Identification of HTTP Servers
[1] http://seclab.cs.ucdavis.edu/papers/hmap-thesis.pdf
An Introduction to HTTP fingerprinting
[2] http://net-square.com/httprint/httprint_paper.html
Identifying Web Servers: A first-look into Web Server Fingerprinting
[3] http://www.blackhat.com/presentations/bh-asia-02/bh-asia-02-grossman.pdf
Web Hacking: Attacks and Defense
[4] Stuart McClure, Saumil Shah, Shreeraj Shah, Addison-Wesley Publishing, 2002, ISBN 0-201-76176-9
Mask Your Web Server for Enhanced Security
[5] http://www.port80software.com/support/articles/maskyourwebserver
Advanced SQL Injection
[6] http://www.owasp.org/images/7/74/Advanced_SQL_Injection.ppt
Web Services - Attacks and Defense, Information Gathering Methods: Footprints, Discovery & Fingerprints
[7] http://www.net-square.com/whitepapers/WebServices_Info_Gathering.pdf
Behavioral Discrepancy Information Leak