Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Web-App-Sec
[Top] [All Lists]

Re: .com. filter bypass

Subject: Re: .com. filter bypass
Date: Thu, 19 Aug 2004 10:04:14 -0400 (EDT)
      I know this is pretty trivial, but I haven't seen anyone write anything
about this.  I'm not sure how useful it really is as an attack vector, but:

"http://www.google.com./"; is a valid url in browsers (with the dot at
the end).

        It seems like it might be used to circumvent some pattern matching
filters in use with CGIs.  Something like:

#!/usr/bin/perl
print "Content-Type: text/html\n\n";
$domain_query = $ENV{QUERY_STRING} # $domain_query is "www.google.com."
if ($domain_query !~ m/^www\.google\.com$/){
  #execute something you normally wouldn't allow for www.google.com
} else {
  print "Sorry!\n";
}

On 13 October 2003, Richard M. Smith posted a like report to the bugtraq
list referring to an issue within IE and cookies.  I would provide a link
but the securityfocus.com site is really, really slow right now. If you
can get to it, I think it's a pretty good read, although maybe not
necessarily relevant from a CGI/web application perspective.

        Where the URL in this case actually is google.com when rendered.
I tested this with IE on XP Pro and lynx on XP Pro cygwin and on FBSD.
As a side note, nslookup and traceroute both ignored the trailing
period, which actually is okay behavior, but also makes them candidates
if this sort of check is performed before they are run with a system
call....  Yup, as I said, pretty trivial.

The behavior for nslookup and other DNS resolvers is to be expected if and
only if the default domains you search do not have an entry that matches
the host.  If your resolver's domain list defines 'securityfocus.com' as a
default domain, google.com and google.com. will be handled identical as
long as there is no DNS entry for google.com.securityfocus.com.

The importance of the period at the end of the host is that it ensures
that the host is handled as if its last domain part, i.e. 'com' is handled
from the DNS root rather than from a more local area.  This behavior is
seen in BIND configuration files where missing the final '.' results in
adding the domain name to the end of the host.  (I would guess it's one of
the most common DNS configuration problems.)

Most people, including programmers and anyone who is either not familiar
with BIND (I do not know if djbdns or other DNS servers suffer as readily
from this issue) or the RFCs pertaining to DNS, are blissfully unaware of
the trailing dot and its relevance or purpose in DNS.  (You don't see
people advertising the URL for their site as "http://www.mysite.com.";, do
you?)  As a result, you see issues in code like the filter you present
above.  I don't think this sort of issue is mentioned in any texts on
domain/host matching (although I admittedly have not read many on the
subject).

Sincerely,


Chris Ess
System Administrator / CDTT (Certified Duct Tape Technician)

<Prev in Thread] Current Thread [Next in Thread>