Message-ID: <20030423145050.B16180@server.24hostingnow.com>
Date: Wed, 23 Apr 2003 14:50:50 -0400
From: Chris Leishman <chris@...shman.org>
To: bugtraq@...urityfocus.com
Subject: DNS vulnerabilities in shared host environments


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

== Overview

A potential vulnerability in the use of DNS exists in some shared
hosting environments.  Specifically, shared hosting services that
allow users to add domains to their account (so-called multi-domain
hosting or domain parking), usually via a web interface such as
cPanel (www.cpanel.net), and also use the same DNS server for
resolving addresses internally.

The vulnerability may allow users to masquerade as a domain and
receive email or other traffic destined for that domain from the
shared hosts servers.

Note that cPanel's default configuration does limit this
vulnerability, however many shared hosting providers alter the
configuration in a way that makes the systems vulnerable without
realizing the effect of their actions (see the 'Resolution' section
below for details).  This alteration is often done as the default
configuration makes it very difficult for a user to transfer a
domain to the new provider.

== Details

When a user adds a domain to their account, an authoritative entry
for that domain is created on the shared hosts DNS server.  This
usually includes an MX record for the domain which directs mail
traffic to the shared hosts mail server.

Theoretically the primary nameservers for the domain should be set
to the shared hosts DNS server, and the shared hosts DNS should only
be consulted regarding the domain if this is the case.

However if the shared hosts internal systems utilize the shared
hosts DNS server for name lookups, the server will respond as if it
was authoritative for the domain regardless of whether it is
actually configured as the primary NS.  This may lead to the
internal systems receiving results that are inconsistent with the
global DNS state.

== Example exploit

A user with a shared hosting account on the provider adds an
additional domain, 'hotmail.com',  to their account.  They do this
using the 'park domain' function of cPanel, which returns the new
nameserver IP's to use for the domain.  Of course the user cannot
reconfigure hotmail's primary NS to be those nameservers.

The user then configures a 'catch all' for any email sent to the
'hotmail.com' address.

If the shared hosting providers mail server uses the same DNS server
for resolving MX server addresses, it will now resolve 'hotmail.com'
as the shared hosts mail server rather than the real hotmail servers
and deliver the mail there.

The user now has access to all mail sent via the hosting providers
mail server to the hotmail.com domain.

== Resolution

One approach to avoiding this vulnerability is to ensure a user
cannot add a domain that is not already configured with the correct
primary NS.  In cPanel this is done by ensuring the following
configurable parameters are disabled:

  Allow Creation of Parked/Addon Domains that resolve to other
  servers.

  Allow Creation of Parked/Addon Domains that are not registered 

  Allow users to Park/Addon Domains on top of domains owned by other
  users.

These are disabled by default.

Unfortunately these defaults make it difficult to transfer a domain
to a new hosting provider, as it requires the domains primary NS be
altered (and the change proper gated) before cPanel allows records
for the domain to be added to that nameserver.  This means that
there will be a period of time in which the domain will be
configured with a primary NS that does not have any authoritative
information regarding the domain.  Also, some registrars will not
permit the primary NS to be changed unless that NS is already
configured as authoritative for the domain.  For these reasons,
hosting providers often enable the options above.

Ensuring these options are disabled prevents the attack described,
however there is still the possibility of various other potential
exploits (eg. what if the nameservers were correct when the domain
was added, but then the domain was transfered, the primary NS
changed, etc).

After the cPanel author(s) were informed of this issue, as
additional setting was added to the cPanel configuration:

  Prevent users from parking/adding on common Internet domains (ie
  hotmail.com, aol.com).

Whilst this will also help prevent exploit, it is certainly not a
complete solution to the issue.

The proper solution is for shared hosting providers to not trust the
user configurable systems, such as the shared hosts DNS server.  The
internal systems should use a separate DNS server that initially
queries an upstream source (or the root servers).  This way only
requests will only be sent to the shared hosts DNS for domains that
are correctly configured with that server as the primary NS.

== Additional issues

A similar attack exists for any other user configurable system that
depends on a global namespace.  For example, mail servers are
configured to know which domains they are supposed to treat as local
(and hence deliver mail to a user mailbox), and which are on remote
servers.  When a new domain is added on a shared hosting system, the
internal mail server is configured to consider the domain as local.
But if the global DNS does not contain an MX record for that domain
pointing to that mailserver, the the mailservers state is
inconsistent with the global mail delivery system.  If a provider
uses the same mail server for sending mail as for receiving it, then
it is possible to redirect mail to an internal mailbox rather than
to the real mailserver specified as the domains MX.  This exploit is
possible regardless of DNS configuration.

To avoid this issue the outgoing mail should be sent via a different
mail server (or mail queue) or forced to use the DNS to find the
correct MX server to send via.

== Notification

The administrators of some shared webhosting providers have been
contacted, as have the maintainers of cPanel (to obtain their input
on the issue).  Approximately 1 month was allowed for them to
reconfigure their systems before this announcement was publicly
released.

== Credit

This vulnerability has possibly been known in various forms within
some groups, but scope of the issue has not been fully realized
previously or publicly announced.

-----BEGIN PGP SIGNATURE-----

iD8DBQE+mUbhlBjBIrTiQhkRAnKMAJ92onnGs27UZ+G4UHUA4P4L7goHKwCfedes
7gRu7eIQwY5tDx0SM04ZjrY=
=k9Kh
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists