TechnicalInfoBannerA
TechnicalInfoBannerB
TechnicalInfoBannerC

Whitepapers

  The Pharming Guide (part 1)

Understanding & Preventing DNS-related Attacks by Phishers  

Goto Part (2): DNS Attacks

Section 1:  Background

This paper focuses upon a recent group of attack vectors used by criminals to target an organisation’s customers for identity theft and financial fraud.  Closely related to Phishing attacks, this new attack manipulates the ways in which a customer locates and connects to an organisation’s named hosts or services through modification of the name lookup process.  The attack vectors, commonly referred to as Pharming, have the ability to bypass many traditional Phishing attack prevention tools and affect larger segments of an organisations customer-base.

Given the apparent complexity of this attack vector, this paper seeks to carefully explain many of the background processes all Internet-based customers use on a daily basis to connect to an organisations commercial service, and examines how frailties in them can be exploited by an attacker to conduct a Pharming attack.

Readers should ensure that they fully understand how traditional Phishing attacks are conducted and the defensive strategies that have been adopted in the past to protect against them.  Ideally the reader should be familiar with the author’s previous paper “The Phishing Guide” as several sections of this paper reference information contained within the earlier whitepaper.

1.1.      Pharming History

While the term Phishing has been around since early 1996, it wasn’t until the later stages of 2003 that email-based phishing attacks began to become a popular attack vector for cyber criminals as a means to conduct financial fraud and identify theft.  By mid 2004, Phishing attacks were headline news around the world and most customers of online financial services or retailers were deeply concerned that they too could fall victim to an attack.  Indeed, most customers still feel that way today.

During this time, numerous software vendors and managed service providers developed sophisticated tools and techniques to help protect against the threat of Phishing.  Providing solutions for the customer’s desktop, the organisations servers and enterprise gateways, they helped protect against many popular forms of Phishing attack.

As has been the case for many years, the thrust and parry between attacker and protector has led to a cyber arms war.

The latest attack vectors being exploited by criminals to achieve identity theft and fraud exploit frailties within the way customers locate and connect to an organisations online service.  While Phishers tended to make use of obfuscation methods to disguise the true destination reached by the customer, Pharming attacks manipulate various components of core domain and host naming systems to misdirect the customer to an alternative destination – one completely under their control.  When an attack is carried out at this level, many of the security solutions devised for protecting against Phishing attacks are also deceived.

Pulling from a pool of well known exploit techniques – such as DNS hijacking, DNS spoofing, cache poisoning, etc. – Pharmers have been able to alter the DNS resolution information that customers need to resolve (and consequently reach) an organisations online services.

In March 2005 the well known and respected SANS security organisation issued a warning about new attacks by attackers that corrupted some DNS servers so that requests for a number of “.com” sites were directed to alternative servers maintained by the Phishers.  Using a rogue DNS server posing as an authoritative DNS server for a particular .com domain, Pharmers were able to cache poison several ISP-level DNS servers and requests for more than 900 unique Internet addresses and more than 75,000 email messages were redirected.

Using even less complex techniques, in January 2005 the domain name for a large New York ISP (Panix) was hijacked to a site in Australia while earlier, in 2004, a German teenager hijacked the eBay.de domain name.  Through simple social engineering and a good telephone manner, an attacker can often fool a domain registrar and gain control of a domain.  Such a thing happened on the 24th April 2005 when users of the secure webmail service - Hushmail - were redirected to a “defaced” webpage.

Section 2:  Understanding Host Resolution

2.1.      Connecting to Hosts

The attack vectors exploited in Pharming abuse the name associations a customer has with a particular service they wish to connect to.  While Phishing attacks typically rely upon interception of traffic destined for a particular host or URL through obfuscation mechanisms, Pharming attacks manipulate the underlying processes used by web browsers (and almost all other Internet services) to identify and connect to a named host.

This section focuses upon the underlying mechanisms used by customers to locate and connect to an organisations online service through name resolution services.  Whilst the majority of Pharming attacks currently manipulate the DNS service, in the future alternative resolution services such as autocompleters and search engines are also likely to succumb to attack.

In order to understand how Phishers and Pharmers may carryout their attacks, it is first necessary to understand how these often neglected name resolution services work and appreciate the frailties being exploited.

2.2.      Understanding Conventional DNS

Although every person “surfing the net” will transparently make use of its services many hundreds of times per day, DNS is probably the least understood networking service of which the Internet depends upon.  Without DNS managing the translation from complex IP addresses to helpful location names and back again, many of today’s online businesses and offerings could not function.

While elegantly simple from a superficial perspective – up close DNS is a multifaceted beast packed full of legacy design compromises, layers upon layers of interconnected services, and complex flows of “trusted” information.

In order to understand the role DNS plays in Pharming attacks (and many other attack vectors), it is important to understand how it actually works.

2.2.1.     Connecting Computers

The protocols used by the Internet to allow two computers to communicate with each other typically rely upon numeric addresses of the format 123.456.789.012 in order to distinguish one from another.  While these numeric addresses are efficient for computers, most humans tend to prefer to use an alias when connecting to different computers. So, instead of referring to a computer as 192.168.20.12, it may be more convenient to call it “Fritz” - the file server in the local library.

In the early days of the Internet (and some time before it was really popular), each computer would have its own list of mappings between an alias and it numeric address (also referred to as its “IP Address”).  Typing the alias “Fritz” into the web browser would result in an invisible translation between the name and IP address, and the web browser would then connect to the file server in the local library.

This local file format worked well for small groups of machines, but scalability and manageability issues were a problem.  The Domain Naming System (DNS) was invented to solve these problems.  DNS servers are deployed throughout the Internet and allow multiple regulatory and commercial entities to manage the translation of unique aliases to computers at a global level.

2.2.2.     DNS Hierarchy

Core to DNS functionality is a hierarchical architecture of servers providing linking information to ever more informative and specific servers.  This can be visualised as a simple pyramidal structure with information flowing from the top “Root Servers”, through to the “Top Level Domain” servers and finally onto the “authoritative” domain servers.

Figure 1: Simplified DNS Hierarchy

This simple structure allows networked users to locate the hosts and services they are looking for anywhere in the world, while allowing organisations to manage their online host names using their own DNS servers.

Consider a customer who wishes to connect to the online web banking service of MyBank Limited which has been designated the name www.mybank.com. (frequently referred to as a “Fully Qualified Domain Name” or FQDN) by that organisation.  The IP address of the host is controlled by the company MyBank and is stored within a DNS server under that organisations control.  In order for the customer’s web browser software to connect to www.mybank.com, it must first discover the IP address of the web server by querying MyBank’s DNS server.  However, the customer’s computer most likely will not know the IP address of the DNS server, and must first uncover these details before it can actually query it.  To find out the DNS servers address, a number of queries must be made to other servers that contain details of how to reach it.

Firstly the user’s computer will require a DNS resolver to connect to a known root server (sometimes referred to as “.” (dot) servers) and obtain the details of a server that knows about .com. addresses.  The root server will thus provide details of an appropriate Top Level Domain (TLD) server, which is then queried by the DNS resolver for details about the authoritative .mybank.com. address.  Finally, the resolver queries the organisations authoritative DNS server for the IP address of the “www” host (full name www.mybank.com), and the user can then use this IP information to connect to the web banking host.

Figure 2: DNS resolution showing the DNS resolver in action

This entire process may only take a few fractions of a second to complete, and is sometimes visible to customers as a pause between typing in a specific web address into their web browsers and hitting go, and seeing the first parts of the web page to appear.  To speed things up, the customer’s computer may decide to cache the IP address associated with the host name for a period of time – thereby not requiring any repeated DNS lookups for a while.

Root Servers

There are a number of strategically placed Root Servers underpinning the entire Internet – referenced by 13 distinct names – each is assigned a letter ranging from A to M, with the full name containing ROOT-SERVERS.NET.  DNS resolvers use hard-coded IP lookup tables for these servers.

Their exclusive role is to point DNS resolvers to the appropriate TLD server for their query.

The following list contains the names and locations of all 13 critical Root Servers.  It is important to remember that these Root Servers are not single servers, but clusters of (globally) load balanced servers.

Servers

Location(s)

Historical Name

A.ROOT-SERVERS.NET

Dulles, VA, USA

ns.internic.net

B.ROOT-SERVERS.NET

Marina Del Rey, CA, USA

ns1.isi.edu

C.ROOT-SERVERS.NET

Herndon, VA, USA
Los Angeles, CA, USA

c.psi.net

D.ROOT-SERVERS.NET

College Park, MD, USA

terp.umd.edu

E.ROOT-SERVERS.NET

Mountain View, CA, USA

ns.nasa.gov

F.ROOT-SERVERS.NET

Auckland, New Zealand
Sao Paulo, Brazil
Hong Kong, China
Johannesburg, South Africa
Los Angeles, CA, USA
New York, NY, USA
Madrid, Spain
Palo Alto, CA, USA
Rome, Italy
Seoul, Korea
San Francisco, CA, USA
San Jose, CA, USA
Ottawa, ON, Canada

ns.isc.org

G.ROOT-SERVERS.NET

Vienna, VA, USA

ns.nic.ddn.mil

H.ROOT-SERVERS.NET

Aberdeen, MD, USA

aos.arl.army.mil

I.ROOT-SERVERS.NET

Stockholm, Sweden
Helsinki, Finland

nic.nordu.net

J.ROOT-SERVERS.NET

Dulles, VA, USA
Mountain View, CA, USA
Sterling, VA, USA
Seattle, WA, USA
Atlanta, GA, USA
Los Angeles, CA, USA
Amsterdam, The Netherlands

 

K.ROOT-SERVERS.NET

London, UK
Amsterdam, The Netherlands

 

L.ROOT-SERVERS.NET

Los Angeles, CA, USA

 

M.ROOT-SERVERS.NET

Tokyo, Japan

 

Given the current structure and constraints of the DNS service, only 13 root servers are typically referenced.  This is due to data limitations requiring all root server names to fit within a single UDP packet given the current naming scheme.  However, this is a compromise limitation and there is nothing to prevent the use of shorter names for root servers to allow for more to be listed within a single UDP packet, or the use of multiple UDP packets, in the future should it be so agreed.

Top Level Domain Servers

The Top Level Domain server’s role is to point DNS resolvers to an Authoritative Domain server.  The TLD layer in the pyramid is actually are divided into two distinct classes – Generic TLDs (gTLD) and Country-code TLDs (ccTLD) – with the ccTLD’s also having a range of subdomain servers.

Figure 3: Top Level Domain (TLD) breakdown

Until mid-2000 (prior to a number of high profile denial of service attacks) the root servers also handled all requests for the generic top level domains.  This responsibility was later removed from the root servers and led to the creation of dedicated TLD servers.  gTLD’s provide resolver information for the common .com, .net, .org, .gov, .mil and .gov domain groupings, while ccTLD’s provide resolver information for country specific domain groupings – such as .UK for the United Kingdom.  In many cases ccTLD’s also allow for subdomains – such as .ac.uk for academic institutes within the United Kingdom.

While the Root Servers are critical to the operation of the Internet, gTLDs and ccTLDs get many more requests.  Consequently gTLDs and ccTLDs are now more critical to the successful operation of DNS than the Root Servers.

Authoritative Domain Servers

Authoritative Domain Servers (or Name Servers) manage a Zone and either provide IP address lookup information themselves, or delegate the lookup of zone/sub-zone information to other DNS name servers.

The technical specifications for DNS define two classes of name servers: “Primary Masters” and “Secondary Masters”.  A Primary Master name server maintains a zone file which is stored locally on the host.  Secondary Master name servers ideally get their zone information from an authoritative name server for that zone – referred to as its master server – via a process called “zone transfer”.

For network resilience reasons, an authoritative domain server would typically have a list of at least one Secondary Master associated with a registered domain name – ideally more Secondary Master name servers are used.

DNS Servers

The DNS server (a generic term for Name Server) for a particular domain provides forward and reverse resolution services between a specific host name and its IP address.  For example, the DNS server for MyBank Limited may contain entries such as:

  • The IP address of “www” is 100.1.2.10 (www.mybank.com)
  • The IP address of “ftp” is 100.1.2.11 (ftp.mybank.com)
  • The IP address of “mail” is 100.1.2.14 (mail.mybank.com)
  • The IP address of “testserver” is 100.1.10.12 (testserver.mybank.com)

Resolvers

Resolvers are the software applications (typically transparent) used by a customers computer to automatically access names servers and resolve host name to IP address details.

Resolvers are designed to handle the following:

  • The querying of a name server,
  • The interpretation of responses from a name server (e.g. resource records or an error response),
  • The return of gathered information back to the customer programs that requested it.

2.2.3.     DNS Host Discovery

Having loosely covered the processes used to resolve a domain name to an IP address, it is important to understand how the global DNS environment works in the real world.  While the basic pyramid structure of the previous section was fine, to understand the intricacies of DNS resolution it is necessary to have a closer look at this hierarchical structure.

Figure 4: Detailed hierarchical view of the DNS resolution structure

If we now take a closer look at the resolution of the IP address associated with the domain name www.mybank.com – but from two different geographic locations (London and New York) – we will find that the DNS resolver can take two different paths in its discovery of this information:

Figure 5: Resolution of MyBank DNS server from two physical locations

From the example above, we see that the London customer queries K.ROOT-SERVERS.NET root server, then the K.GTLD-SERVERS.NET load balanced .com gTLD server, before being directed to the authoritative MyBank.com DNS server – which knows the IP address of www.mybank.com to be 100.1.2.10.  Meanwhile, the New York customer has queried the G root server and the F .com gTLD server before reaching the authoritative MyBank.com DNS server.  If these two customers were to repeat their lookups at a later date or time they would likely end up querying different servers.

2.2.4.     DNS Server Delegation

Things gradually become more complex when you take into account an international organisation that has registered and manages multiple domains.

Consider the example of MyBank Limited which has registered three domains (mybank.com, mybank.co.uk, and mybank.com.au) and manages three DNS servers strategically placed to handle customer host lookups in their three key geographic business regions (Europe, Americas, and the Pacific).  Along with these DNS servers, MyBank Limited has separate hosting facilities for key Internet-accessible mail and web services in London, Atlanta and Sydney.  The following diagram shows this arrangement.

Figure 6: Multiple corporate DNS servers with internationally distributed host servers

MyBank Limited has found that, given the size of their London and Atlanta offices, that they wish to use subdomains to help manage email services – hence the addition of Lon.mybank.com and Atl.mybank.com domains.  As part of this plan, MyBank Limited delegates the management of the Lon.mybank.com to the European DNS server (which also manages the mybank.co.uk domain) – even though the authoritative name server for mybank.com is located in the Americas.

In addition, MyBank Limited has rationalised its server hosting such that requests for www.mybank.com and www.mybank.co.uk resolve to the same IP address – which corresponds to a fully redundant cluster of web servers located in Atlanta.  Due to regulatory requirements in Australia, MyBank has been required to ensure that all Australian web requests go to a separate/dedicated server.

Finally, MyBank Limited has configured their DNS servers such that all external mail goes to the same mail host located in Atlanta – regardless of which regional gTLD or ccTLD it was destined for.  The only exception is for email sent specifically to the London office with the email address of whoever@lon.mybank.co.uk.

This arrangement of DNS servers and hosting means that customer requests for different host services will require different resolver paths to uncover the IP address they require.  The following table and graphic helps to illustrate this point.

www.mybank.com

mail.lon.mybank.com

mail.mybank.com.au

www.mybank.co.uk

Root Server
C.ROOT-SERVERS.COM

Generic TLD
F.GTLD-SERVERS.COM

MyBank Americas
NS0.MYBANK.COM

www.mybank.com
150.10.1.21

Root Server
M.ROOT-SERVERS.COM

Generic TLD
B.GTLD-SERVERS.COM

MyBank Americas
NS0.MYBANK.COM

MyBank Europe
NSE.MYBANK.COM

mail.lon.mybank.com
100.10.1.20

Root Server
K.ROOT-SERVERS.COM

.AU Country-code TLD
SEC1.APNIC.NET

.COM.AU ccTLD Sub.
NS2.AUSREGISTRY.NET

MyBank Pacific
NSP.MYBANK.COM

mail.mybank.com.au
150.10.1.20

Root Server
I.ROOT-SERVERS.COM

.UK Country-code TLD
NS7.NIC.UK

.CO.UK ccTLD Sub.
NS7.NIC.UK

MyBank Europe
NSE.MYBANK.COM

www.mybank.co.uk
150.10.1.21

Note that the Root Server, Generic TLD, Country-code TLD and ccTLD subdomain host addresses may change with each new DNS lookup request, as they all make use of multiple load-balanced servers to answer lookup requests.

Figure 7: International customers looking up internationally hosted servers

2.2.5.     Resolving an IP Address

While it is certainly possible for every Internet computer to carryout its own DNS lookup procedure each and every time, there are more efficient methods of obtaining the IP address information associated with a particular FQDN – methods that can help speed up resolution processes as well as reduce the volume of network traffic.

Within a corporate environment or dialup/broadband subscription ISP where there are many desktop computers accessing the Internet through a managed connection, instead of each customers computer making DNS queries directly (i.e. independently resolving through the Root Servers etc.), they are instead directed to use DNS servers provided by their organisation/ISP.  These shared DNS servers are configured to provide DNS resolving services on behalf of their customers and may also temporarily cache previously requested domain name information.

Depending upon the configuration of the corporate/ISP DNS server, instead of attempting to resolve the IP address of a requested FQDN directly, it may in turn ask a larger or better positioned DNS server to resolve it first – just in case it has already cached the information.  To illustrate this process, consider the following figure:

 

Figure 8: Resolving an IP address using non-authoritative DNS servers

In this scenario, the customer wishes to connect to www.mybank.com.  However, the customers computer has not connected to this host before (or doesn’t have the details cached in its own memory) and is thus forced to connect to an internal DNS server to find out this information.  If the internal DNS server doesn’t have this information cached, it may be configured to ask the local ISP’s DNS server for the information.  In some cases local ISP’s may be subsidiaries to larger national ISP organisations and will be configured to ask their nominated national ISP DNS server for connection details of the www.mybank.com FQDN.

If the details are not present in these DNS servers, one of them (most likely the last one asked or so configured) will then resolve the details by querying a root server, then a .com gTLD server, eventually reaching an authoritative DNS server for the mybank.com domain.  The mybank.com DNS server then informs the DNS server doing the resolving the location (IP address) of the www host.

Assuming that the national ISP DNS server did the asking, it would most likely cache the details (the length of time these details are cached would most likely be dictated by the TTL information provided by the authoritative mybank.com DNS server) and then pass the information back to the local ISP DNS server.  The local ISP DNS server would also cache the information, and then provide the location details up to the internal DNS server (which would most likely also cache the details), before finally passing the details to the original customer computer that made the request for www.mybank.com.  Armed with this IP address information, the customer’s computer can now attempt to connect to www.mybank.com.

2.2.6.     Caching Host and Domain Information

In the process of resolving a hosts IP address, a customer’s desktop computer should query their local DNS server for the necessary information.  If their local DNS server is not Authoritative for the domain of the host it is looking up, it should ask other servers to get an answer (as explained in the previous section - 2.2.5).

In the majority of cases, a customers computer will connect to the Internet via their corporate network or a local ISP and their default DNS server will also manage the domain (i.e. Authoritative) to which their computer belongs.  For example, a customer may use BT ADSL Internet services in the UK and are automatically assigned the name host81-155-234-22.range81-155.btcentralplus.com to their dynamically assigned IP address 81.155.234.22.

If this default DNS server is required to provide all resolution services to each computer on its network, it is likely that the server will be busy fulfilling numerous lookup requests which may slow down its performance - especially if it is also authoritative for its own domain.  To help reduce this lookup overhead, the DNS server may be configured to temporarily store any information it gets from other DNS servers inside its own database for a period of time stipulated by the answering (most likely authoritative) DNS server.  The storage time is defined by the knowledgeable DNS server in the form of a “time to live” or TTL for short.

The mechanism of temporarily storing lookup information is called Caching, and it is designed to allow a DNS server to respond faster to multiple queries for the same domain or host information.  DNS servers that operate in this manner are referred to as Caching DNS servers and are often configured to carryout recursive lookups.  Operating in this way, the caching DNS server will first check its current database of lookups for domain or host information.  If this information has not expired (checked by reviewing the TTL of the entry), the caching server will provide the requesting computer with this stored information.  If the TTL has expired, or the DNS server does not have any knowledge of the domain or host, it would then conduct a recursive lookup to find the correct information.  Once found, the caching DNS server would add the information to its database and pass the information back to the requesting computer. 

Figure 9: How a caching DNS server answers a lookup request

The majority of Internet Service Providers (ISPs) use some kind of caching DNS server to support their customers and reduce network loads.  By short-circuiting the normal domain or host resolution process, these servers can reduce the answer response time to the computers that use the service.  However, because previous answers are stored until their TTL expires, it can take hours or days before any legitimate changes to the original data may filter its way to all areas of the Internet.  A comparison of core functionality between a standard DNS server and a caching DNS server is as follows:

 

DNS Server

DNS Cache Server

Availability

Should be able to respond to lookup queries from any computer on the Internet

Should only respond to lookup queries that originate from a “local” network

Types of query that it should answer

Non-recursive queries

Recursive queries

Records that it should attempt to resolve

Should only respond with data it is authoritative about

Should attempt to resolve any legitimate request

2.2.7.     Local Lookup

As stated earlier, DNS evolved from locally stored reference files that contained mappings from a host name or alias, to a numeric IP address.  Almost every popular operating system in use today still provides this kind of service, and may be configured to use the information contained in these locally stored files in preference to that contained on a remote DNS server.

All modern desktop UNIX distributions, Linux distributions and Microsoft Windows operating systems utilise a ‘hosts’ file.  This host file contains the mapping information between a memorable alias and IP address, and is located in the /etc/hosts file on Linux systems and %Systemroot%\System32\Drivers\Etc\hosts on Microsoft Windows systems.  An example of a ‘hosts’ file is as follows:

# Copyright (c) 1993-1999 Microsoft Corp.

#

# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.

#

# This file contains the mappings of IP addresses to host names. Each

# entry should be kept on an individual line. The IP address should

# be placed in the first column followed by the corresponding host name.

# The IP address and the host name should be separated by at least one

# space.

#

# Additionally, comments (such as these) may be inserted on individual

# lines or following the machine name denoted by a '#' symbol.

#

# For example:

#

#      102.54.94.97     rhino.acme.com          # source server

#       38.25.63.10     x.acme.com              # x client host

127.0.0.1       localhost

192.168.10.5    printer

192.168.10.12   fileserver

192.168.10.12   fs.home

150.10.1.20     mail.lon.mybank.com

150.10.2.20     mail.mybank.co.uk

150.10.2.20     mail.atl.mybank.com

150.10.2.21     www.mybank.com

150.10.2.21     webserver

Depending upon the computers operating system, it may be configured to use ‘host’ files for host resolution in preference to remote DNS services.  There are a number of reasons for using a local ‘hosts’ file first:

  • Speed – reading the locally stored file for host naming information will generally be faster than requesting external network resources.
  • Updateability – for small networks, or networks that are subject to frequent change, updating a local file may be easier than setting up or modifying a dedicated DNS server.
  • Noise – some organisations choose to use hosts files on servers or other hosts to reduce the volume of network traffic which would normally be associated with repeated DNS queries.
  • Shortcuts – in many environments, personnel who frequently have to connect to the same hosts may prefer to supply their own shortened or more memorable alias to a host.  For example, instead of the name mail.lon.mybank.com, the user could add an entry to their ‘hosts’ file called “smtp” for that associated IP address.
  • Overriding – in some cases it may be necessary to locally override any public/authoritative DNS resolution of a particular host.  For instance, when testing a web application within a seperate hosting environment while the real one is still “live”, modifying the local hosts ‘hosts’ file to point www.mybank.com to the IP address of the test server should prevent the user from testing the wrong server.

Other Host Resolution Services

As you would expect, throughout computer history there have been a number of alternative methods of resolving a hosts alias to an IP address.  Many operating systems still provide backwards compatibility with these resolution services, and may try to resolve an unknown host name using them if their preferred method does not yield an authoritative result.  These services and the order in which they are queried, is important, and can have a security significance.

Unix and Linux systems use a file (called ‘hosts.conf’) to define the resolution services the host may use, and in which order.  For reference, these are typically (in order):

  • DNS
  • hosts – for lookups in /etc/hosts
  • NIS – a legacy UNIX directory service (Network Information Service)

Microsoft Windows operating systems would typically try to resolve a host alias to IP address using a greater number of methods.  For reference, these are typically (in order)

  • Checks to see if the alias is the computers own name
  • hosts – for lookups in %Systemroot%\System32\Drivers\Etc\hosts
  • DNS
  • WINS – a proprietary lookup protocol to Microsoft Operating Systems
  • Network Broadcasts
  • LMHOSTS – a file associated with the LAN Manager directory service

2.3.      The “New DNS”

While conventional DNS services are responsible for the efficient resolution of host name into an Internet routable IP address, there are a number of additional services used by customers to discover hosts that contain specific information resources they are looking for.  These services may be either online or built into the software a customer is using to access the Internet.

These “New DNS” services have been designed to make it easier for customers to find, and connect to, appropriate servers using minimal amounts of information.  For simplicity, they can be divided into two key categories:

  • “Autocompleters”
  • Search Engines

2.3.1.     “Autocompleters”

Most web browser implementations or Internet aware applications will try to “autocomplete” incomplete or unknown host names.  For instance, typing the word “beer” into a web browsers’ address bar will most likely result in one or more of the following actions:

  • The browser will try to resolve the host “beer” by see if the name is cached locally or listed in lookup files such as HOSTS or LMHOSTS.
  • It will append “http://” to the start of the name and try to connect to the host using the HTTP protocol.
  • It will append “www.” to the start of the name and “.com” to the end, and try to connect to the host “www.beer.com”
  • It will query the software vendors online database for advice about the best URL associated with this host name or “keyword”.  In many cases organisations will pay to have keywords associated with their product or website.
  • It will submit a query to a default search engine and automatically follow the resultant link.  Again, organisations may pay to ensure that their website is associated with the keyword.
  • It will submit a query to a nominated search engine and list all the options returned by the search engine.
  • It may just respond with “no such host”.

Whilst this process aids the discovery of a host name associated with the word “beer”, there is no guarantee that the customer will be directed to the same host name every time.

2.3.2.     Search Engines

Search engines are an increasingly popular mechanism for resolving destination hosts or URLs associated with a particular organisation.  In many cases, even though the customer knows the exact URL of the business service they wish to connect to, they find it easier to type in one or two keywords into their favourite online search engine (or browser toolbar) and follow the resultant link.

Figure 10: Google search for “westpac" to discover links to the New Zealand personal banking page

For example, instead of typing in the entire URL for the Westpac personal banking online service, a customer may find that it is faster to type “westpac” into Google (or a related toolbar search aid) and follow the second link on the page.

These search engines use a number of mechanisms to decide which responses are presented to the viewer, and in what order they are sorted.  This process is commonly referred to as “page ranking”.  The most common methods of deciding the page ranking of a response include:

  • Whether the searched words (or phrase) appear in the name of the host or as part of a URL.
  • How many times the searched word appears within a page or site, the order of the words, and how it is used within the structure of the page (e.g. a page title, a paragraph heading, within a sentence, e.g.).
  • How many other websites or pages contain links to the page containing the searched words, and what their own page rankings are.
  • The frequency of which other people have conducted the same or a similar search and followed a particular resultant link.
  • The age the page has existed.
  • “Tweaking” of keyword associations by the search engine company to reflect local language interpretations or regional locations of the request.
  • Paid for services by the search engine company to ensure that a particular result will always appear at the top of the results list.

Pharming Attack Vectors - Pharming (part 2)

 

     
    Copyright 2001-2007 © Gunter Ollmann