xatar
05-01-2007, 11:01 AM
hi all,
I just though I would post a quick tutorial on fingerprinting web servers including servers running over SSL. I'm sure that this is all old news to most of you, but the newbies may appreciate it. Nothing here is dangerous and should not affect the server in any way.
Disclaimer: The information in this tutorial is not intended to be used for illegal activities. It is for informational purposes only.
As I'm sure you all know, web servers use Hyper-Text Transfer Protocol (HTTP) to transfer the data required to allow web pages to be displayed on your browser. Secure Sockets Layer (SSL) encrypts this data with a 128 bit key by default (this tut is not about attacking SSL!).
To fingerprint a web server, you should connect to it with a number of different tools and take make a decision based on the results. On easy method of fingerprinting a web server is to use netcat or Telnet.
telnet www.victim.com 80
Note that there is a space and the target port number after the DNS name of the victim server, whatever that may be. This will get Telnet to connect to the web server service on port 80. Great, now you can type directly into the Telnet session certain commands that are recognised by the web server and will illicit a response.
HEAD / HTTP/1.0
This should suffice for most fingerprinting needs. The HEAD command will return to the Telnet screen the header of the victim server. In the header will most likely be a line starting with Server:. After that should be the type of server it is:
Server: Microsoft IIS/5.0
Server: Microsoft IIS/6.0
Server: Apache (Win32) 2.0.32
Server: Apache (Redhat) 1.3.39
And so on.
Example:
telnet www.victim.com 80
Trying www.victim.com...
Connected to www.victim.com.
Escape character is '^]'.
HEAD / HTTP/1.0
HTTP/1.1 200 OK
Content-Length: 323
Content-Type: text/html
Content-Location: http://192.168.1.1/index.html
Last-Modified: Tue, 24 Feb 2006 16:06:30 GMT
Accept-Ranges: bytes
ETag: "40215623c60b71:37a"
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Tue, 01 May 2007 09:12:48 GMT
Connection: close
Connection closed by foreign host.
Also notice other information that may be in the header such as the Content-Location: line which in this case reveals the internal IP address of the server. This may help an attacker in constructing other attacks, but for this tutorial is just further information on the victim server.
Other commands worth trying are:
OPTIONS / HTTP/1.0
This will show you what OPTIONS, or commands you can execute against the server such as HEAD, GET, POST etc.
Example:
telnet www.victim.com 80
Trying www.victim.com...
Connected to www.victim.com.
Escape character is '^]'.
OPTIONS / HTTP/1.0
HTTP/1.1 200 OK
Connection: close
Date: Tue, 01 May 2007 09:13:16 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
MS-Author-Via: DAV
Content-Length: 0
Accept-Ranges: none
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, COPY, PROPFIND, SEARCH, LOCK, UNLOCK
Cache-Control: private
Connection closed by foreign host.
It is the Allow: line that is important for an external attacker. The above example tells us that we can execute the OPTIONS, TRACE, GET, HEAD, COPY, PROPFIND, SEARCH, LOCK and UNLOCK commands. Should that have said that the PUT or DELETE commands are allowed, then we can possibly create pages on the site or delete them!
PROPFIND / HTTP/1.0
The PROPFIND command is required to WebDAV operations in which you can remotely manage and update a web site. If the server does not forbid this command, you can attempt to connect to it with FrontPage (File | Open Site and enter http://www.victim.com)
Other information that may be returned by a PROPFIND command could be the internal IP address of the server again.
Great, so you can use Telnet quite easily to do this. Using netcat is just as easy. Create a series of text files that contain the above listed commands followed by two Control-Line Feeds (press the Enter key to get one CLF). It is vitally important to have the two CLF's at the end as that executes the command. Once you have the files created, use the following netcat syntax to send them to the server:
nc www.victim.com 80 < HEAD.txt
nc www.victim.com 80 < OPTIONS.txt
nc www.victim.com 80 < PROPFIND.txt
You could also redirect the response to a text file by appending > response.txt at the end of the above commands.
So, that's how to fingerprint web servers. But what if the server is running over SSL? Telnet and netcat will no longer work as they cannot negotiate the encryption used by HTTPS servers. You will need to use another tool to handle the encryption and then use Telnet or Netcat to transfer the data.
BackTrack has Stunnel installed, but I find it a little unstable. I prefer a tool called SSLProxy (http://www.obdev.at/products/ssl-proxy/index.html) which is freely available. Just download the zipped tar file to a suitable location on your BackTrack, I used /pentest/web/.
Unzip it:
gunzip sslproxy.2000_Jan_29.tar.gz
Untar it:
tar -xf sslproxy.2000_Jan_29.tar
This now creates a directory called sslproxy.2000_Jan_29. Enter that directory and execute:
make
This should work perfectly and create the sslproxy executable in that directory.
To use sslproxy, simply enter the directory and execute sslproxy to read the syntax help screen. If we are fingerprinting the web server at the fictitious www.victim.com web site, we would configure sslproxy like this:
sslproxy -L 127.0.0.1 -l 443 -R www.victim.com -r 443
You now have a personal proxy running on your local IP of 127.0.0.1 on port 443 which has connected to the victim server.
Now simply use the above Telnet or Netcat commands but point them to the sslproxy instead of the vicitm, remember that the proxy will forward all of the commands on to the victim for you!
Telnet 127.0.0.1 443
HEAD / HTTP/1.0
etc, etc, etc.
Banner grabbing, which is what you are doing with these commands is a pretty effective fingerprinting technique, but it is not the only option. Servers can be configured so that the Server: line in the header returns false information. So a blend of manual banner grabbing and automated fingerprinting tools should be used. Tools like nmap (nmap -sV -p 80,443 www.victim.com) or amap (amap www.victim.com 80) or HTTPprint which is now part of Wikto for the Windows guys.
I hope this tutorial has helped people. I do professional penetration testing for a living and I can guarantee you that the more time and effort you spend on scanning and fingerprinting, the better position you will be in later in the test.
later,
xatar.
I just though I would post a quick tutorial on fingerprinting web servers including servers running over SSL. I'm sure that this is all old news to most of you, but the newbies may appreciate it. Nothing here is dangerous and should not affect the server in any way.
Disclaimer: The information in this tutorial is not intended to be used for illegal activities. It is for informational purposes only.
As I'm sure you all know, web servers use Hyper-Text Transfer Protocol (HTTP) to transfer the data required to allow web pages to be displayed on your browser. Secure Sockets Layer (SSL) encrypts this data with a 128 bit key by default (this tut is not about attacking SSL!).
To fingerprint a web server, you should connect to it with a number of different tools and take make a decision based on the results. On easy method of fingerprinting a web server is to use netcat or Telnet.
telnet www.victim.com 80
Note that there is a space and the target port number after the DNS name of the victim server, whatever that may be. This will get Telnet to connect to the web server service on port 80. Great, now you can type directly into the Telnet session certain commands that are recognised by the web server and will illicit a response.
HEAD / HTTP/1.0
This should suffice for most fingerprinting needs. The HEAD command will return to the Telnet screen the header of the victim server. In the header will most likely be a line starting with Server:. After that should be the type of server it is:
Server: Microsoft IIS/5.0
Server: Microsoft IIS/6.0
Server: Apache (Win32) 2.0.32
Server: Apache (Redhat) 1.3.39
And so on.
Example:
telnet www.victim.com 80
Trying www.victim.com...
Connected to www.victim.com.
Escape character is '^]'.
HEAD / HTTP/1.0
HTTP/1.1 200 OK
Content-Length: 323
Content-Type: text/html
Content-Location: http://192.168.1.1/index.html
Last-Modified: Tue, 24 Feb 2006 16:06:30 GMT
Accept-Ranges: bytes
ETag: "40215623c60b71:37a"
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Tue, 01 May 2007 09:12:48 GMT
Connection: close
Connection closed by foreign host.
Also notice other information that may be in the header such as the Content-Location: line which in this case reveals the internal IP address of the server. This may help an attacker in constructing other attacks, but for this tutorial is just further information on the victim server.
Other commands worth trying are:
OPTIONS / HTTP/1.0
This will show you what OPTIONS, or commands you can execute against the server such as HEAD, GET, POST etc.
Example:
telnet www.victim.com 80
Trying www.victim.com...
Connected to www.victim.com.
Escape character is '^]'.
OPTIONS / HTTP/1.0
HTTP/1.1 200 OK
Connection: close
Date: Tue, 01 May 2007 09:13:16 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
MS-Author-Via: DAV
Content-Length: 0
Accept-Ranges: none
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, COPY, PROPFIND, SEARCH, LOCK, UNLOCK
Cache-Control: private
Connection closed by foreign host.
It is the Allow: line that is important for an external attacker. The above example tells us that we can execute the OPTIONS, TRACE, GET, HEAD, COPY, PROPFIND, SEARCH, LOCK and UNLOCK commands. Should that have said that the PUT or DELETE commands are allowed, then we can possibly create pages on the site or delete them!
PROPFIND / HTTP/1.0
The PROPFIND command is required to WebDAV operations in which you can remotely manage and update a web site. If the server does not forbid this command, you can attempt to connect to it with FrontPage (File | Open Site and enter http://www.victim.com)
Other information that may be returned by a PROPFIND command could be the internal IP address of the server again.
Great, so you can use Telnet quite easily to do this. Using netcat is just as easy. Create a series of text files that contain the above listed commands followed by two Control-Line Feeds (press the Enter key to get one CLF). It is vitally important to have the two CLF's at the end as that executes the command. Once you have the files created, use the following netcat syntax to send them to the server:
nc www.victim.com 80 < HEAD.txt
nc www.victim.com 80 < OPTIONS.txt
nc www.victim.com 80 < PROPFIND.txt
You could also redirect the response to a text file by appending > response.txt at the end of the above commands.
So, that's how to fingerprint web servers. But what if the server is running over SSL? Telnet and netcat will no longer work as they cannot negotiate the encryption used by HTTPS servers. You will need to use another tool to handle the encryption and then use Telnet or Netcat to transfer the data.
BackTrack has Stunnel installed, but I find it a little unstable. I prefer a tool called SSLProxy (http://www.obdev.at/products/ssl-proxy/index.html) which is freely available. Just download the zipped tar file to a suitable location on your BackTrack, I used /pentest/web/.
Unzip it:
gunzip sslproxy.2000_Jan_29.tar.gz
Untar it:
tar -xf sslproxy.2000_Jan_29.tar
This now creates a directory called sslproxy.2000_Jan_29. Enter that directory and execute:
make
This should work perfectly and create the sslproxy executable in that directory.
To use sslproxy, simply enter the directory and execute sslproxy to read the syntax help screen. If we are fingerprinting the web server at the fictitious www.victim.com web site, we would configure sslproxy like this:
sslproxy -L 127.0.0.1 -l 443 -R www.victim.com -r 443
You now have a personal proxy running on your local IP of 127.0.0.1 on port 443 which has connected to the victim server.
Now simply use the above Telnet or Netcat commands but point them to the sslproxy instead of the vicitm, remember that the proxy will forward all of the commands on to the victim for you!
Telnet 127.0.0.1 443
HEAD / HTTP/1.0
etc, etc, etc.
Banner grabbing, which is what you are doing with these commands is a pretty effective fingerprinting technique, but it is not the only option. Servers can be configured so that the Server: line in the header returns false information. So a blend of manual banner grabbing and automated fingerprinting tools should be used. Tools like nmap (nmap -sV -p 80,443 www.victim.com) or amap (amap www.victim.com 80) or HTTPprint which is now part of Wikto for the Windows guys.
I hope this tutorial has helped people. I do professional penetration testing for a living and I can guarantee you that the more time and effort you spend on scanning and fingerprinting, the better position you will be in later in the test.
later,
xatar.