Doing it Passively
First Published: SC Magazine

An important phase of any security assessment is passive information gathering. During this phase, information is gleaned from a variety of external (non-client) sources and through data gathering techniques directed against the infrastructure such that they would not normally be identified as anything beyond typical network traffic. Unfortunately the security benefits associated with this phase of an assessment are the least understood by many organisations and are consequently dropped for cost saving reasons.

However, a lot of important information can be passively harvested and subsequently used in a direct attack or to reinforce other attacks targeted at the organisation. Depending upon the source, information such as current service patching levels, internal network architecture layout and account details can be easily obtained. Just as importantly, with a little insight as to where this information is obtained and the level of detail to the information, an organisation can often rectify this information leakage easily and quickly.

There is a popular saying in the underground when it comes to passive information gathering – “Google is my friend”. It is surprising what can be unearthed using an advanced public search engine, particularly one as sophisticated as Google. Not only will Google allow you to search for specific text strings, it also caches page content. Even after an offending or insecure page has been withdrawn from an organisations website, the attacker can still call up and analyse the cached page content. This is particularly useful when searching for key phrases such as “script error”, “server side error” or other development language error responses confined to the organisations domain – all used to identify the backend mechanics of the web site and provide potential routes for later exploitation.

Quite often other information gems appear through conventional searching techniques. In the past I have discovered client firewall configuration manuals, internal auditing manuals and confidential financial analysis documents just by searching for different permutations of the organisations name, and restricting the search to .doc and .xls file extensions. Searching newsgroups and other public posting areas often reveals infrastructure details as the organisations administrators pose or answer questions relating to specific components of their network or software.

For example, one client had a posting providing advice on getting a new security patch for AIX systems to work – telling the group that the only way they managed to do it was by removing certain other “less likely to be exploited” security patches. Not only did this describe the type and patch level of their server, but also went on to explain what patches they had removed. In other cases, while not gaining information about the client’s infrastructure, the information can be used for social engineering or extortion purposes. An example that springs to mind was when an administrator was involved in a personal flame war and made use of plainly sexist comments, all from his corporate mail account.

Another important aspect of passive information gathering is the harvesting of email accounts. Most organisations follow one of two naming models for their users email addresses; either the address contains the users full name, or an abbreviated version that directly maps to their logon ID. Consequently, the full name is useful for social engineering attacks, and the abbreviated name forms half of the user-name/password pair needed to log into corporate resources. These addresses may be extracted from the organisations web sites or purchased from various spam mail lists. Of most value are the names and email addresses of staff with technical administrative authority, and they can often be gained from domain registration entries - including billing address information.

A frequently overlooked source of information lies within the headers of an organisations sent email. Email headers are great for providing insight into internal server naming, IP numbering schemes, the type and version of content filter or anti-virus solution, service patch levels and even the version of the clients mail client. This information can then used to build a network map of the organisations DMZ and LAN structure, complete with IP addressing information.

The actual naming of the organisations servers can also be beneficial. Utilising information contained within the email headers or obtained from domain lookups or sometimes even zone transfers from insecure DNS servers - an easily decipherable naming convention can further passively map the organisations network. Common mistakes include appending abbreviations for physical location of the server (e.g. LON for London), the operating system (e.g.W2K for Microsoft Windows 2000), the servers function (e.g. FW for firewall), the manufacturer (e.g. SUN or HP) and even network location (e.g. DMZ2).

To make the process of passively gathering information about a client even easier, there are a number of websites and online tools that bring together a lot of this information – including some “not-so passive” methods, such as limited port scans and banner grabbing (such as Central Ops Domain Dossier - The benefit of using these online resources includes complete anonymity and a guarantee that logs or IDS systems won’t alert the clients operational staff that the first phase of a penetration test by pentester.

Tips on Passive Protection

1. Use the search engines to examine the information already out there.
2. Be prepared to contact third-parties to ask them to remove copies or cached content.
3. Educate your staff not to post information to public forums and newsgroups.
4. Use email header filtering devices to remove internal email routing information.
5. Implement a non-obvious server naming convention.
6. Change the banners on all Internet visible services to something less informative.
7. Use role based email addresses on all Internet accessible information instead of personal email addresses (i.e.
8. Be wary of implementing email addressing schemes that make use of logon names.
9. Give away as little information as possible
    Copyright 2001-2007 © Gunter Ollmann