WindowSecurity.com Newsletter of April 2011 Sponsored by: Entrust
Welcome to the WindowsSecurity.com newsletter by George Chetcuti, BSc in Computing & IS (Honors), CISA, MCP, HP Certified. Each month we will bring you interesting and helpful information on the world of Security. We want to know what all *you* are interested in hearing about. Please send your suggestions for future newsletter content to: firstname.lastname@example.org
1. How an attacker gather information about your web servers
For more than a hundred years, fingerprints have been used to identify a person. Tiny pieces of information used as evidence can lead an investigation to an individual of whom characteristics can be later explored. Forensic science has made major advancements and now DNA samples can be extracted in a methodology known as DNA fingerprinting where further characteristics can be revealed. But letís leave forensic science for CSI and move on to Web fingerprinting. As human fingerprints are used to identify a human being, web fingerprinting is used to identify web applications. The evidence resides in banners, default files, protocol anomalies, and a whole slew of methods which are available to the public.
As soon as web fingerprinting reveals the type and version of a running web server attackers can determine any known vulnerabilities related to that particular server. They can identify potential security weaknesses based on the version of the web application or framework. It is this information hat attackers use to exploit such weaknesses and break into our machines. In this newsletter I will guide you through the process of fingerprinting your web resources so as to determine if your software is up-to-date, what information is available to the public and what steps you need to take to disguise your web resources.
I suggest getting your hands dirty and leveraging the benefits of fingerprinting tools before someone does it for you! Your version may be vulnerable. A word of caution is a must at this point; make sure you know what youíre doing before running thee tools against your production systems unless youíre looking for a new job ?
The HTTP response header
The simplest and most basic form of identifying a web server is to view the HTTP header response or perform a banner grabbing exercise using Telnet. Just look at the Server field in the HTTP response header and voila you have the first piece of information. Within the response the web server sends information like web server application and version, content type and other information. Many fingerprinting tools exist both as command-line and online utilities. I find the online tools more productive and easier to use. Searching the web will provide you with a comprehensive list of tools; however, to show you a typical test result I will be using an online tool called web-sniffer.net and a local tool called netcat which can be downloaded here. I ran these tools against different web applications so as to show the different outputs as shown below:
As you can see from the netcat output, this http response allows us to identify both the web server and version it is running plus additional web modules and their respective versions.
You can confirm the netcat results by using the online tool as shown above. Furthermore, web-sniffer.net is able to give us additional critical info such as, the web application framework which in this case is Joomla 1.5!
Obfuscating the server banner string
Obfuscation helps make communications confusing and more difficult to interpret and is therefore used to hide server banner strings. Most web server software allows you to configure different banner strings.
For example, in the well-used open source web server Apache, you can hide version details by modifying ServerSignature and ServerTokens directives in Apacheís configuration file. Server signatures contain valuable information about your installed software and can be read by Internet worms and hackers. Setting up these directives instructs the server to display just Apache as server name in the http response and no version number is sent back to the clients. There are also commercial products that perform obfuscation on http responses and these are needed for non-open source servers such as IIS, although in IIS one could edit the banner string using a hex editor. These products modify the HTTP headers so as to make the responses appear to be those of another server.
As you can see from the netcat output, with the help of a simple modification we can now hide Apache server version details.
When the server field in the HTTP response header is either hidden or replaced so as to fool attackers they then may search elsewhere for evidence of a vulnerability. Clever hackers do not stop here with their web-based reconnaissance drills.
HTTP header arrangement
Another technique used in fingerprinting is the HTTP header arrangement. If you observe the order of the fields in each response and compare them against known outputs then you can find the matching server. Ordering may differ in different versions of the same web server software. It is recommended to test with malformed requests as well, as this may give the required evidence not achieved in the previous step. These tests involve sending malformed requests or requests of nonexistent pages to the server and match the replies against known outputs.
A very powerful tool that fingerprints web servers quite accurately is httprint which can be downloaded here. Evidence that we were unable to collect with the previous tools is now available. So whatís special about this tool? Httprint has a signature dictionary that allows it to recognize the type and the version of the web server in use. The banner string may be obfuscated but such tools manage to get information from the web server characteristics. It also rates web serversí security using intelligent techniques and statistical analysis.
As you can see from the httprint output, the tool managed to extract the Apacheís version even though it is hidden.
Actually, there are many more tools that can help you collect critical information about your web servers and I suggest that you get acquainted with tools like WhatWeb, Nmap, Blind Elephant, Wappalyzer, and Netcraft.
Finally, if you want to take your web security a step further, you can implement a reverse proxy in front of your web server. For example, the open source project Squid has some features that can help anonymize connections, such as disabling or changing specific header fields in a client's HTTP requests and can drop malformed requests. In addition, reverse proxies support SSL, improve performance through caching and introduce load balancing and application-level firewall features.
The technique of system fingerprinting is not yet as foolproof as human fingerprinting. It is possible to disguise and customize HTTP servers quite sufficiently to ensure that they give unexpected results for all HTTP tests.
Should you have any ideas for content in future editions of the WindowSecurity.com newsletter or would like to ask questions, youíre more than welcome to e-mail me at email@example.com.
See you next month! - George
2. WindowSecurity.com Articles of Interest
3. Tip of the Month
The free IISlockdown tool from Microsoft which includes URLScan can be used to change or remove the banner from your IIS web server. The links below describe how to prevent the Internet Information Server (IIS) or Internet Information Services (IIS) version information that the server header contains from being displayed either in a network trace or in the results of a telnet command.
4. Latest Security Exploits and Concerns
5. Ask George a question
I followed carefully the newsletter you sent me on DISCOVERING IT RISKS, it was quite helpful!
I write to suggest that in your next newsletter, if you could add some parts of remote desktop connections, how to launch it, its major risks, and how to control it. If you can also send me details on telnet, how i can control it on my servers and how it works, like after connecting to a telnet server what commands are used to delete, copy, amend files on the server and how to restrict them manually and automatically.
I hope you are ok. With regards to how setting up a remote desktop connection and telnet services I suggest that you visit WindowsNetworking.com, perform a specific search for Remote Desktop and Telnet where I am pretty sure that you will get all the information you need about these tools. However, I would like to comment about the security implications of these tools. First of all, I would try to avoid giving remote desktop and telnet access permissions to external users where possible as these services magnify the security risks for your organization. I would use these tools within the organizationís internal network only.
Given that you may need to provide these services to external users then you can change the default port by securing RDP with an SSH tunnel. To setup RDP over SSH you need to have a capable firewall or SSH server located at your office or destination location. This setup is not straight forward but it makes your RDP connection encrypted. RDP is quite unsafe especially if you allow administrator logins! Limit the users who can log on remotely, set an account lockout policy and go through the Group Policies to set security features such as, encryption, require password and others. Check this excellent article here.
Again, the native telnet service is highly insecure and I suggest that you should use other clients such as, SSH if this is possible. However, you can secure the connection using SSL, that is, secure the Telnet server with SSL. You need to do some work on the server side such as, configuring the telnet server with a certificate. As with RDP you can telnet over SSH and if you are running a Windows environment then you need to find a third-party product. There are free and commercial products out there but I recommend this great article if youíre interested in a free SSH Windows based server.