-----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-----
This archive was generated by hypermail 2b30 : Thu Apr 24 2003 - 11:17:15 PDT