<<< Date Index >>>     <<< Thread Index >>>

common dns misconfiguration can lead to "same site" scripting



Hello, I'd like to document what appears to be a common named
misconfiguration that can result in a minor security issue with web
applications.

It's a common and sensible practice to install records of the form
"localhost. IN A 127.0.0.1" into nameserver configurations, bizarrely
however, administrators often mistakenly drop the trailing dot,
introducing an interesting variation of Cross-Site Scripting (XSS) I
call Same-Site Scripting. The missing dot indicates that the record is
not fully qualified, and thus queries of the form
"localhost.example.com" are resolved. While superficially this may
appear to be harmless, it does in fact allow an attacker to cheat the
RFC2109 (HTTP State Management Mechanism) same origin restrictions, and
therefore hijack state management data.

The result of this minor misconfiguration is that it is impossible to
access sites in affected domains securely from multi-user systems. The
attack is trivial, for example, from a shared UNIX system, an attacker
listens on an unprivileged port[0] and then uses a typical XSS attack
vector (e.g. <img src=...> in an html email) to lure a victim into
requesting http://localhost.example.com:1024/example.gif, logging the
request. The request will include the RFC2109 Cookie header, which could
then be used to steal credentials or interact with the affected service
as if they were the victim.

Another attack vector exists where a victim connects to a site from (or
via) a machine that hosts another website, any XSS-like flaw or
reflective web service on the hosted website can therefore be exploited
in the context of the misconfigured domain. This would also affect users
who connect via a shared caching http proxy machine, that also hosts an
http daemon.

An excellent example of exploiting this misconfiguration was discovered
by my colleague, Will Drewry, in CUPS.

http://localhost.example.com:631/jobs/?job_id=&job_printer_name=Click%20Me&job_printer_uri=javascript:alert(document.cookie)
 

This misconfiguration allows any of the domains affected to be
vulnerable to this issue via CUPS (installed on most UNIX, Linux, Mac
systems). The bug requires a click to be exploited, but illustrates the
problem nicely.

Initial analysis shows that some of the worlds most popular websites are
affected. The administrators of the example domains listed below were
sent a draft of this email 7 days before release, so some (or all) may
have been corrected, these examples are simply intended to demonstrate
how widespread this problem is. 

localhost.microsoft.com has address 127.0.0.1
localhost.ebay.com has address 127.0.0.1
localhost.yahoo.com has address 127.0.0.1
localhost.fbi.gov has address 127.0.0.1
localhost.citibank.com has address 127.0.0.1
localhost.cisco.com has address 127.0.0.1

etc.

Recommendations

It is advised that non-FQ localhost entries be removed from nameserver
configurations for domains that host websites that rely on HTTP state
management. Of course, any other records that return RFC1918 or RFC3330
reserved addresses should also be carefully examined for similar issues.

Additionally, those practising blackhole routing via dns to mitigate
denial of service attacks against specific hostnames should avoid the
temptation to resolve targets to 127.0.0.1 or similar addresses for
sensitive domains.

[0] It appears to be a common mistake to confuse the JavaScript SOP and
the HTTP originating host definition for Cookies with regard to port
number. The JavaScript SOP
(http://www.mozilla.org/projects/security/components/same-origin.html)
does include the port number, where as RFC2109
(http://www.ietf.org/rfc/rfc2109.txt) explicitly does not. This
behaviour is arguably incorrect, making it impossible to securely host a
website from a multi-user machine, but nevertheless is the case, and is
implemented by most major browsers.

Thanks to Will Drewry, Robert Swiecki, and Filipe Almeida for their
valuable assistance researching this topic.

-- 
-------------------------------------
taviso@xxxxxxxxxxxxxxxx | finger me for my gpg key.
-------------------------------------------------------