How does a hacker use Web application fingerprinting to exploit a Web application? What measures can be put in place to help prevent Web application fingerprinting
Before an attacker can launch a successful attack against a Web application, he or she must gather information about the application and the system on which it resides. This is known as fingerprinting. By simply sending a request to the server on which the Web application resides, an attacker can usually discover the exact version of the Web server software. There are also tools like Nmap that use more sophisticated techniques such as port scanning to find out exactly what applications and services are running on a Web server.
Once an attacker has a reasonable profile of the application as well as the environment it is operating in, they can use a tool such as Nessus to detect the vulnerabilities associated with the fingerprinted system. Once the attacker has the results from this scan, they can select a targeted payload or exploitation technique. This is why attackers put such effort into researching and fingerprinting potential victim systems; they want to increase the chances of an attack being successful the first time by knowing which exploits are appropriate for the victim’s system. Hackers even use search engines such as Google to help find and fingerprint vulnerable machines. This is commonly known as Google hacking. By using Google's advanced search operators, hackers can retrieve fingerprint information from Google's cache without ever connecting to their intended target.
It is virtually impossible to stop all data leakage that can aid attackers in fingerprinting your application, but there are steps your security, application development and network administration teams can take to make it harder for potential attackers to build a complete picture of your system. To find out what hackers can discover about your site, check the Google Webmasters FAQ. This provides information about ways to properly protect and expose your site to Google.
You application developers should avoid HTML comments such as ToDo or FixIt that may be useful to an attacker; all comments should be kept within programming language control. File and folder restrictions can be used to block direct access to important files such as readme.txt type files that may make their way on to the production server by mistake.
deny from all
When an application error occurs, check that it is handled “gracefully” by your developers and doesn’t output any information that may be useful to a potential attacker. This goes for database errors as well. Running fuzzing tests is a good way to see how an application handles erroneous and unexpected data.
The security and network administration teams need to ensure your perimeter defenses can detect potential attempts to fingerprint your applications. This means tuning firewall and IDS rules to pick up abnormal and repeated requests from the same IP address. For example, SQL injection attacks can involve a lot of trial-and-error, which will show up in database and network logs, but these must be reviewed on a regular basis in order to spot them. Likewise, if local hostnames or MAC addresses show up in outbound traffic, it is probably down to system fingerprinting. Use Nmap to see what information you can gather about your own system before your IDS triggers an alarm. Use the tools an attacker does so you can see what they see. You can then take steps to remove, hide or monitor attempts to obtain any information of importance.
This was first published in November 2011