Web Browsers And Other Mistakes

Web Browsers And Other Mistakes Alex “kuza55” K. [email_address] http://kuza55.blogspot.com/

Outline
Understanding Web Technologies
Finding Vulnerabilities
Triggering Vulnerabilities
Exploiting Vulnerabilities

Understanding Web Technologies
Cookies
IE: FindMimeFromData
Flash: crossdomain.xml & LoadPolicyFile
Browser Encoding Behaviour

Cookies
What is a cookie?
It’s a name value pair stored on the client
It is sent only o the domain it was set for
And that’s all most developers know
Here is what a cookie looks like when it is set:
Set-Cookie: NAME = VALUE[ ; expires= DATE][ ; path= PATH][ ; domain= DOMAIN_NAME][ ; secure][; httpOnly]
Here is what a cookie looks like when it is sent:
Cookie: NAME=VALUE[; NAME=VALUE]

Cookies
But where does a cookie actually get sent?
The browser does a ‘domain-match’ which means:
Domain A Matches Domain B if:
The domains are identical, or
A is a FQDN string and has the form NB, B has the form .B', and B' is a FQDN string.
(So, x.y.com domain-matches .y.com but not y.com)
A browser sends a cookie if the domain the user is going to (A) domain-matches the domain in the cookie (B)

Cookies
So cookies set for .microsoft.com are sent to subdomain.microsoft.com
Who can set cookies?
A host (A) can set cookies for any domain (B) that it domain-matches
So subdomain.microsoft.com can set cookies for .microsoft.com
But not for .com (two-dot rule)

Cookies
But the two-dot rule doesn’t work for registries like .co.uk since they do have two dots
Browsers have reacted differently
IE doesn’t allow cookies for (com|net|org).yy or xx.yy (unless they are in a whitelist)
Firefox 2 has no protections
Firefox 3 has a massive (but incomplete list)
Opera does DNS resolution on the cookie domain (B)

Cookies
So on Firefox2 you can set cookies for any domain not on the com, net, org TLDs
In all browsers sub1.domain.com can set cookies for .domain.com which also get sent to sub2.domain.com
By abusing the path attribute we can effectively over-write cookies very specifically, or for the whole domain by setting lots of them

Cookies
The secure attributes only lets cookies be transmitted over SSL
The httpOnly attribute doesn’t let JavaScript access cookies
You can however access the cookie via XHR as it is being sent, so it is ineffective on sites which regenerate cookies
On Firefox and Opera we can delete all the user’s cookies by exhausting the global limit on how many cookies can be stored
More detailed info at http://kuza55.blogspot.com/2008/02/understanding-cookie-security.html

FindMimeFromData
FindMimeFromData decides upon a content-type for a page, rather than strictly following a server provided content-type header
Allows uploaded images to be rendered as javascript executing html pages
Well, it used to
Previously all GIF & JPG images with correct signatures would not be rendered as html
Now PNGs aren’t either
We still have all the other formats though, e.g. .txt .pdf
People still make mistakes with server-side signature verification

FindMimeFromData
Checks are hardcoded
Not vulnerable to encoding issues
Only first 256 bytes are checked for these strings:
<html
<head
<body
<script
<pre
<table
<a href
<img
<plaintext
<title

FindMimeFromData
I’ve also been told that it has some heuristic algorithms which trigger on smaller tags if there are enough of them
Haven’t been able to reproduce with blackbox testing

crossdomain.xml
crossdomain.xml files let you allow cross-domain communication via Flash
They look like this:
<cross-domain-policy>
<allow-access-from domain=“www.domain.com" />
</cross-domain-policy>
But do these apply to the site the flash file was loaded from, or the site it was embedded in?
The site it was loaded from!
They also get the default ability to communicate with their hosted site, regardless of crossdomain.xml
File extensions and Headers attached to the HTTP response are ignored…
If you can upload unfiltered .xyz files, you can load the .xyz file as a flash file, and abuse it’s privileges
Think OWA and other webmail

Flash Internals
Flash AS2 VM is tag based
Processed one tag after the other until it gets to the end
No validity checks unless the tag is processed
We can append junk to our swf files, and they’re still valid
So we don’t need to control the whole file
So injections of odd Content-Types where you control the very start are exploitable
Think JavaScript callbacks
Can even get around typical filtering

JavaScript Callbacks
arbitrary data here([{"errors":["NO_RESULT"]}]);

LoadPolicyFile
LoadPolicyFile lets you have those files by other names and in non-root directories
Must be served with a Content-Type header of:
text/*
application/xml
application/xhtml+xml
Or in some cases text/x-cross-domain-policy
But there is also additional strictness, depending on the root crossdomain.xml

Flash 9,0,124,0
Adobe released a patch ~3 weeks ago
A lot of stuff changed
(It seems ) Flash files now only inherit permissions if they are hosted and loaded from a given sit
Flash files can no longer force users to send (somewhat) arbitrary headers to arbitrary domains
Or at least that’s the idea ;)

Browser Encoding Behaviour
Horribly Understood
Little-to-No useful documentation
We’ve still discovered enough to exploit some apps

UTF-7 XSS
Classic case:
No charset in HTTP headers and no charset in meta tags
IE auto-detects UTF-7 if you throw it enough UTF-7 encoded data in the first 4Kb of a document
Improved Classic Case: (Stefan Esser)
As above, but don’t rely on auto-detect
Load utf-7 xss-ed page into an iframe with the outside frame having a charset of utf-7
All browsers originally
Firefox Patched

UTF-7
No charset in header; charset in meta tag, UTF-7 injection before meta tag
E.g. injection in a title tag
Close the title tag
Inject a UTF-7 encoded meta tag
Inject your UTF-7 encoded XSS
Credit to Yo suke Hasegawa
http://openmya.hacker.jp/hasegawa/PoC/utf-7/inject-meta.html

NULL Bytes
Completely ignored in HTML by IE
<scr%00ipt> is the same as <script>
Makes a lot of filters exploitable
Including previous versions of RequestValidation

Variable Width Encoding
<a href=“ <input> ”> <input> </a>
<a href=“ <input>[MBChar] > style=“a:expression(alert(1));>text </a>
[MBChar] is a Multibyte character, where “ or ‘ (if ‘ is used as the quote symbol) is the last byte and the first byte is the last byte of our first input
Only some character sets:
http:// ha.ckers.org/charsets.html

HTML Entity Decoding
When the browser uses html tag attributes it HTML-decodes them, e.g.
<a href=http://site/page.php?x=y&a=b>
Is effectively the same as
<a href=http://site/page.php?x=y&a=b>
So
<a onclick=‘func(“test”);’>
Is the same as
<a onclick=‘func("test&quot);’>

HTML Entity Decoding
So
<a onclick=‘func(“test&quot); eval(window.name);//”);’>
Is the same as
<a onclick=‘func(“test”); eval(window.name);//”);’>
So if you’re ever inserting data into attributes and the data inside could potentially be dangerous
E.g. event handlers, URLs, styles, etc
Decode before escaping/encoding/filtering, then re-encode
If not escaping/encoding/filtering; double encode to preserve value

Point?
Most developers and security people still don’t fully understand all the technologies they work with
Including me 
Please provide good documentation
Don’t force us to black-box test IE8 to figure out how things work
I can’t reverse my way out of a wet paper bag

Finding Vulnerabilities
IE: FindMimeFromData
Flash: crossdomain.xml & LoadPolicyFile
Browser Encoding Issues
IE: Inter-Protocol XSS

FindMimeFromData
Usually no checks done
Many sites use the `recommended` Microsoft solution, setting a header like this:
Content-Disposition: attachment
Still dangerous if users open files
Some sites try to do filtering themselves
These can usually be bypassed by throwing more knowledge of the algorithm at them

FindMimeFromData
Some sites verify you have an image for which IE has a signature
Try setting an extension for which IE has a signature, e.g. .png
But include a valid image of another format
e.g. a GIF with .jpg extension
Sometimes works since developers only verify that the image is valid using a generic function, e.g. getimagsize() for PHP
Or they simply look for the presence of a signature

crossdomain.xml
Config:
Check the /crossdomain.xml file
search for ” <cross-domain-policy>” site:site.com
Content-based attacks:
Crawl the site for instances where you control the first bytes
Inspect File uploads
Try to inject a flash file under a different extension

LoadPolicyFile
Examine /crossdomain.xml
Depending on what you find there may be restrictions
If no file exists; LoadPolicyFile will fail
There were some tricks to bypass this before, but they don’t seem to work any more
May specify restrictions on other policy files
http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security_print.html

Browser Encoding Issues
Check for charset in HTTP Headers
Is it multi-byte?
Can you make valid multibyte characters with a quote as the last character?
Vulnerable
Check for charset in meta tags
Do you have a filtered injection before it?
Vulnerable
Otherwise vulnerable

Inter-Protocol XSS
Browsers speak HTTP to ports regardless if those ports understand
IE doesn’t perform any checks on the response
Firefox searches for http (case-insensitive) in the first 8 bytes
Never going to happen unless it’s valid
IE searches for http/ (case-insensitive) in the first 1024 bytes and then assumes the next line is a http header
So we can sometimes do HTTP Response Splitting and Header Injection

Point?
Finding everything is hard
Especially when clients are constantly changing
We need something for developers to more easily write secure code
Frameworks
Better documentation is needed
Most of this was found by trial and error and eureka moments by various researchers

Triggering Vulnerabilities
Logged out XSS
CSRF-Protected XSS
JavaScript Hijacking
Session Fixation
CSRF Token Fixation
CSRF Vulnerabilities

Logged Out XSS
What does it mean to be ‘logged in’?
No, its not like the meaning of life.
To be logged in is to send a cookie tied to a valid session
So when are you logged out?
When your cookie is invalid or you don’t send a cookie
How do we log the user out for a single request?

Logged Out XSS
Stop a valid cookie being sent
Flash to mangle the cookie
Not in IE
Not Latest Flash
Some session handlers like PHP throw a warning, but still create a new session.
RequestRodeo
Firefox Extension which strips all auth data from off-site requests
Nice extension, but introduces new issues
Path Specific Cookies
Cross-Site Cooking
Subdomain XSS
Hope you can somehow delete part of an authentication cookie which can be guessed, e.g. a username

CSRF-Protected XSS
Log the user in as someone else
Log the user out first (not always necessary)
Delete all cookies or CSRF or Wait (not long usually)
Or Stop the cookies being sent
RequestRodeo
Log the user in as yourself
Flash (Not IE) (Not latest)
Session Fixation
URL Tokens
PHP, Java, others?
Cross-Site Cooking
Subdomain XSS
Abusing SSO systems

JavaScript Hijacking
Also called JSON hijacking
Prevalent in Web 2.0 sites which use JSON to transport sensitive data
Remote <script> tags allow us to extract it if
The JSON data is wrapped in a callback function
The user is running Firefox 2.X
We can over-write the default constructors and read the data without it being returned to us
But sometimes it is actual JavaScript hijacking, e.g. sometimes other sensitive data is included in files which are interpreted as valid JavaScript
So don’t put anything sensitive in JavaScript files or JSON

Session Fixation
Instead of stealing the cookie, set the cookie and then let the user eventually authenticate using it
Useful when we are only able to set a cookie
Standard defence is to regenerate the session id when the privilege level changes
Usually considered difficult, unless:
We can supply the token via the URL (sometimes)
With PHP’s default session handler we must first delete the existing cookies
We can use Cross-Site Cooking attacks
We have an XSS/Cookie Injection bug in a subdomain

CSRF Token Fixation
But is regenerating tokens enough?
Not always
Session Tokens are not the only things we want
We want CSRF tokens
Which we can also fixate
Use a similar procedure to Session Fixation
Still need to force the user to use our cookie
Just as difficult to exploit

Usually very simple to Trigger
Not on ASP.NET
We can only do user-to-user CSRF
Not unauthed-to-user csrf
So admin areas are unexploitable by default
However, protections are not configurable; only programmable
ViewStateUserKey
Prone to replay attacks between sessions if the key is non-session specific

CAPTCHAs as CSRF solutions
Two types
captcha.php
captcha.php?id=123456
Both can be CSRF-ed
captcha.php can be csrf-ed onto the page and filled in by the user
captcha.php?id=123456 can sometimes be retrieved, solved by an attacker, and then used in an attack

File Upload CSRF
Publicly considered unexploitable until February ’08
Due to the unusual format of the http requests
Two methods released, by pdp and me
An ActionScript 3 object called URLRequest gives us enough flexibility to easily forge the headers
http:// www.gnucitizen.org /blog/cross-site-file-upload-attacks/
There is a browser bug which also give us enough control
http://kuza55.blogspot.com/2008/02/csrf-ing-file-upload-fields.html

Point?
Assume all client-side vulnerabilities can be triggered
New techniques constantly being developed
Browser technology is a moving target
Don’t let researchers tell you there are bugs, but then not patch them because you think no-one can exploit them

Exploiting Vulnerabilities
Beyond Simple Cookie Stealers
Hiding in Client-Side Channels
Beyond the Same-Origin Policy

Cookie stealing payloads are still the most common
Also most easily defeated
httpOnly
IP locks
However more complex payloads are slowly gaining traction

User-as-a-proxy payloads are becoming more common, especially as tools are released
XSS Proxy
XSS Tunnel
http://www.portcullis-security.com/tools/free/xssshell-xsstunnell.zip
Single action user-as-a-proxy payloads are sometimes preferable

Other XSS Tricks
Password manager abuse
Browser cache snooping
Altering client-side data stores

Password Manager Abuse
Browser automatically fills in passwords
Can opt-out on Firefox
signon.prefillForms
Still possible if you know the username
Fill in the username
Focus on the username field
Focus on the password field
Extract the password (use setTimeout)
Firefox only does a domain check
IE does a URL check and doesn’t prefill

However, it’s not so simple
You need to tab to the password field for it to be filled in
Focus tricks don’t work
IE has a weirder event model than Firefox
Tabs from script do not invoke the password manager
Makes the popup blocker bypassable (well, it used to)
Makes this harder to exploit
So we need some social engineering
Entice the user into pressing the tab key

IE’s page check checks the top frame’s URL
So we can’t have the page inside an iframe
Doesn’t check whether the form is off-site
Not particularly useful unless you can only inject an iframe into a login page
Or you can do cross-site frame injection, maybe
Open the login window in a popup
Inject JS into it
Entice users to press the tab key
Probably too much effort, and too many tricks required

Browser Cache Snooping
Why?
Sensitive details
Think credit cards, etc
How?
XmlHttpRequest()
Results?
IE only
Requires no tricks.

Altering client-side data stores
Some Javascript becomes exploitable, e.g.
window.location = getCookie(‘redirURL’);
We still face the issue of what our payload should do
But we gain the benefit of persistence

Hiding in Client-Side Channels
One of the problems with XSS is that it can be found in server logs
This is silly since we only need the client to see our payload
So we can use client-side channels to transfer our payload
document.domain
location.hash
window.name
sessionStorage/globalStorage
etc

Beyond the Same-Origin Policy
Exploiting Trust Relationships
IP
DNS

Exploiting Trust Relationships: IP
Many technologies do not discriminate by port
Many are not virtual host-aware

IP ports
Cookies are shared across ports
Flash crossdomain.xml policies rarely make use of port restrictions
Why does this matter?
Non-virtual host aware ports
E.g. Inter-Protocol XSS

Virtual Hosts
The domain is based on the Host: request header the browser added to the request
Some ports may not be vhost aware but xssable
Inter-Protocol XSS, Reverse Proxies, etc
Some may be vhost aware, but may not know our specific vhost, e.g. chosts registered for only one port
SSL Ports, Load Balancers, etc
Sometimes we can manipulate the Host: header
In an earlier version of Flash we could send a malformed Host: header
addRequestHeader(“Host:blah", " ");
Gets the default host

Exploiting Trust Relationships: DNS
Many security models rely on DNS
And the security of all sites in the DNS tree
Implicit trust between parents and child domains
In certain protocols anyway
DNS is also not static or homogenous

Heterogeneous DNS Records
DNS servers do not necessarily have the same records, e.g.
A Company may have a wildcard DNS record for *.company.com resolving to 12.34.56.78
If they now create a website at internal.company.com but only place that record on the internal DNS server
If *.company.com is vulnerable to XSS, then so is internal.company.com when resolved externally
Think laptops
Think `persistent` payloads

Ambiguous IP Addresses in DNS
Many domains inadvertently have a localhost.domain.com address pointing to 127.0.0.1 (Travis Ormandy)
localhost.microsoft.com used to
Many internal hosts resolve externally
Domains now resolve to IPs which are not controlled by domain owner

Ambiguous IP Addresses in DNS
Exploitable in few scenarios
Multi-User system
XSS-able service on 127.0.0.1 (Travis Ormandy)
Local Machine
HTTP proxy
Attacker on the same local net

Bringing Down the Walls: document.domain
document.domain is a read/write property which is set to the domain of the current page
This property can be set to any parent domain
To check whether sites communicate two checks must be passed (usually):
The document.domain’s are both the same
Either both have been altered, or neither have
Many sites alter the domain to allow this explicitly
MySpace
Live.com
Yahoo!

Bringing Down the Walls: document.domain
However these is a bug in IE
Known & Unpatched for >1 year
If a website reads the location.href property, IE will think the document.domain peoperty has been altered
Many scripts read this property
Google Analytics
So any parent domains which read location.href anywhere at all effectively trust all child domains

Exploiting Trust Relationships: DNS
Sites can set cookies for child domains and read cookies from parent domains
sessionStorage/globalStorage can read/write to parent domains
crossdomain.xml allows wildcards
Commonly used
amazon.com allows *.amazon.com (among others)
yahoo.com allows *.yahoo.com
SiteLock template for ActiveX controls allows wildcards

Subdomain Squatting
Network Solutions hijacked their customers’ subdomains to serve ads (Techcrunch)
Earthlink and Comcast hijacked the subdomains of all sites on the internet and served ads to their customers (Kaminsky)
Both cases were XSS-able, the NetSol equivalent trivially

Point?
Stop building technologies which put trust into DNS
We can’t continue to blindly trust DNS
Nothing other than same-origin-style matches should be good enough
Sometimes that’s not good enough either
Don’t do weird DNS things, and don’t use shared hosting

Questions?

Thanks!

Web Browsers And Other Mistakes

by kuza55 on Aug 29, 2008

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 4

Statistics

Web Browsers And Other Mistakes — Presentation Transcript