Beruflich Dokumente
Kultur Dokumente
Dan Kaminsky
Director of Penetration Testing
IOActive, Inc.
© LucasFilm
Mobile Too!
© LucasFilm
Where The Wild Things Are
• Rampant and persistent XSS/XSRF announcements
• Superbowl .WMF 0-day
– Two days before Superbowl, malicious image placed on
web page
– 1+M desktops compromised overnight
• DNS Rebinding Test By Dan Boneh’s Team at Stanford
– Test flash applet placed on an Ad network, distributed
across many web sites
– Applet acquired partial network connectivity to client LAN
– +100K networks exposed
These Are A Few Of My Favorite
Things
• DNS…? Tunneling…? Behind Firewalls…?
– “I try to get out, but they pull me back in!”
• DNS Rebinding is an old bug
– Dates back to 1996
– So old, people forgot about it, and started building
systems that didn’t defend against it
• Dan Boneh of Stanford University’s been driving the
most thorough research
– Attack dates back to 1996 (“Princeton Attack”)
– Martin Johns revived the attack in August 2006
– RSnake’s been pushing a lot of attention its way
• Effect: DNS Rebinding partially breaks the security
policy of the web.
How Does The Web Work?
• Web pages are pulled together in the browser,
from pieces that can come from all over the place
– You can even embed one web page inside
another one!
• This is an “IFrame”
– But what if someone embedded Hotmail, and
you were logged in? Would they be able to
read your mail?
The Same Origin Policy
• “Look but don’t touch”
– A web page can embed Hotmail, but it can’t “look inside”
to see what’s happening
– Access to “look inside” controlled by Same Origin Policy
– If foo.com has an iframe to foo.com, it can look inside.
– If foo.com has an iframe to bar.com, it can display
bar.com to the user, but it can’t peek inside and see what
the user sees.
• “If two things come from the same place, they must be
trusted the same”
– Same place = Same name, right?
The Bug
• Names don’t host anything.
• Everything comes from IP addresses
• We use DNS to translate between a name we trust and an IP
address we communicate with
– Foo.com -> 1.2.3.4
– Bar.com -> 3.4.5.6
• Assumption: The translations don’t change
– Reality: Both foo.com and bar.com can return any IP
address, at any time, whether they control that IP or not
• Bar.com can return an IP address of Foo.Com’s
Now What?
• One moment, bar.com could point to a server in Europe
• The next moment, bar.com could point to the printer down
the hall
• Suppose your browser loaded a page from each address
– The content from the European server would be from
bar.com
– The content from the printer down the hall would also be
from bar.com
– According to the Same Origin Policy, the server in
Europe can do whatever it wants to your printer!
• The server can’t get past your corporate firewall…
• …but it doesn’t need to. It’ll tell your browser what to
do, and your browser will report back with whatever
your printer is up to.
Why The Attack Works
• Browser doesn’t know bar.com from the external
IP is any different from bar.com from the internal
IP
– This is by design
– Major web sites have IP addresses spread
across the world, and resources acquired from
them need to be able to script against one
another
• Detecting that there’s a cross-IP scripting action
happening is only the beginning – what to do after
that is what people are trying to figure out.
What is the canonical attack here?
• Firewall Bypass
– Most corporate networks draw a significant
distinction between the external network and
the internal network
• Things inside can route out
• Things outside cannot route in
• By bouncing off a lured browser, an attacker
on the outside can access resources on the
inside
Levels of Exploitation
• Level 1: Browser-Only
– One IFrame is from Europe, the other is down the hall.
Same name, so they can script against eachother.
– The Win: Arbitrary HTTP Sites
• Level 2: Web Plugins
– MSXML* / XmlHTTPRequest / Silverlight
– The Win: HTTP + Web Services + Semi-Arbitrary
Headers
• Level 3: Socket Plugins
– Flash / Java, though different resources available
through each
– The Win: Everything from L1+L2, plus various degrees
of TCP or UDP access
Java
• Original Target of 1996 Princeton Attack
– From Applet interface, can only get high-port
UDP and TCP to the actual calling app
• More widely deployed than I thought
• LiveConnect
– Ability for Javascript to call Sockets directly,
without going through Applet interface
– Totally rebindable – effect is high-port UDP and
TCP to anyone
– FireFox and Safari only though
Flash
• Has worked hardest to make arbitrary socket
connections work when they’re supposed to
– Most mature security model in the industry
– They don’t handle rebinding well though
• Breaks what is otherwise a lot of really good
work
• Effect: Arbitrary TCP, though you have to pull
some tricks to get TCP ports below 1024
Mechanisms for rebinding an
address
• Lots of ways to use a rebind, but how do you
achieve it in the first place?
– How do you cause the DNS infrastructure to
accept your change of address?
– The entire architecture is designed to cache
across hours to days, not to be swappable in
seconds
• Three mechanisms
– Temporal
– Spatial
– Ridiculous
Traditional Rebinding: Temporal
Modulation
• DNS records have a TTL field – lets you declare how long a
record should live in the infrastructure before a second query
causes a new request to the original server
– Declare a 0 TTL and records will supposedly not cache
– Now every time the browser has a slightly different DNS
request, you get an opportunity to provide a different
location
• Problem: Some networks won’t respect your low TTL.
Some networks brag about that ;)
– You could wait until the network-enforced minimum TTL
expires, but that takes time
Another Rebinding Mechanism:
Spatial Modulation
• DNS responses can contain multiple addresses
• When bar.com is asked for its IP address, it
returns both its address and the address of the
printer
– This can have a infinite TTL
• Problem: Which record will the browser choose?
– Totally random.
• Solution: Try again
– Seriously.
Spatial Error Resolution
• Case 1: Browser wants external, gets internal
– Fix 1: External resource is hosted on an unusual port, so
the internal connection will fail and thus retry to external.
This has problems with outbound firewalls, though.
– Fix 2: Immediately after connecting, look for evidence in
the connected session that we’ve actually reached the
correct server. If not, destroy the object that did the
incorrect retrieve and keep trying until success.
• The trick: Retrieve the content with XMLHttpRequest
so that you can actually destroy the object that
guessed incorrectly.
• Case 2: Flash/Java wants internal, gets external
– Fix: Look for magic token on incoming session. If magic
token is returned, destroy the object and try again. If no
token, retry the applet a couple times just in case there’s
a extrusion firewall in the way.
Ridiculous?
• People are trying to use DNS TTLs as a security
technology
• DNS TTL’s are not a security technology
– Finally, something less a security technology
than Virtual Machines
• Overriding a TTL, if you control the record, turns
out to be very easy, and this is by design
– When something wasn’t designed to be a
security technology, don’t be surprised when it
isn’t one
CNiping
• CNAME Records: DNS Aliases
– Instead of returning an address, return what the
“Canonical”, or Official Name was, and then the
address of that Canonical Name
– If you are allowed to be the resolver for that
canonical name, your additional record
overrides whatever’s already in the cache, even
if the TTL hasn’t expired yet
• It’s not a bug.
• Works against most, but not actually all
name servers
CNiping Demo[0]
• dig 1.foo.notmallory.com
;; ANSWER SECTION:
1.foo.notmallory.com. 120 IN
CNAME bar.foo.notmallory.com
bar.foo.notmallory.com. 120 IN
A 10.0.0.0
• dig bar.foo.notmallory.com
bar.foo.notmallory.com. 111 IN
A 10.0.0.0
CNiping Demo[1]
• dig 2.foo.notmallory.com
2.foo.notmallory.com. 120
IN CNAME
bar.foo.notmallory.com.
bar.foo.notmallory.com. 120
IN A 10.0.0.1
• dig bar.foo.notmallory.com
bar.foo.notmallory.com. 118
IN A 10.0.0.1
Review
• By swapping addresses out from
underneath a web browser, we can get
arbitrary TCP (and sometimes UDP)
access to hosts reachable by the client.
What can we do with this?
– Can we VPN into corporate networks
with nothing but a lured web browser?
• Sure! It’s easy!*