Information Disclosure is the ‘I’ threat in the STRIDE Threat Model.

Info Disclosure basically means that you give a user (and an attacker) more information about your system and infrastructure than needed.

One of the oldest anti Info Disclosure measures is the “wrong username or password” message. This leaves the attacker guessing which of the two provided inputs are wrong and is much better than “oh – the username is right – just try another password” :)

One example is the dreaded server header in HTTP. This header gives you information about what web server product (and often version and patchlevel) is used. This header is often used by automated attack scripts to find out which platform specific exploits should be fired against your IP. I usually demo www.netcraft.com to show how easy it is to retrieve this information (insert your favourite dns name in the ‘what’s that site running’ input box).

Google is your friend to find standard banners and error messages on the web, e.g. try to google for:

intitle:”microsoft certificate services” inurl:certsrv

This gives you machines on the internet with a default MS certificate services welcome banner. Given the fact that the CA private key is usually stored on such a machine – this would make an ideal attack target.

I found two interesting tools that check/google for suspicious standard banner/standard error messages – it is big fun to play with them – but also very alarming.

Athena
Foundstone SiteDigger (+ a good whitepaper about ‘google hacking’)

So – my advice – be careful what information you give your users.

• Don’t use standard banners, standard welcome messages, standard sub-directory names (like /admin, /secure, /secret) and standard error messages.
• Use obscurity (yes – security through obscurity does not work!) – but you are buying time
• Use strong authentication – only give information to users which have gone trough this authentication process
• Only give vague error messages to users – but be sure to log them detailed in your back end