Defeating the Same Origin Policy part 1

Defeating the Same Origin Policy part 1

Summary: The Same Origin Policy is one of the guiding principles that seek to protect our browsing experience. The Same Origin Policy was originally released with Netscape Navigator 2.

SHARE:
30

Billy RiosThe Same Origin Policy is one of the guiding principles that seek to protect our browsing experience. The Same Origin Policy was originally released with Netscape Navigator 2.0 and has been incorporated in one form or another in every major browser since. The concept has additionally been extended to protect such technologies as the Java Virtual Machine, Flash (they're still working on it), and Silverlight (yet to be put to the real test). John Heasman

Same Origin Policy's goal is to prevent a document, script, applet, etc. loaded from one site of origin from manipulating properties of or communicating with another site of origin. Unfortunately, the Same Origin Policy has been the victim of some brutal attacks as anti-DNS Pinning and DNS Rebinding attacks have come into full scope.

Why is this important? Well, there's a number of reasons as there are a number of technologies that Same Origin Policy protects, but let's focus on one example that really exemplifies the danger of bypassing the Same Origin Policy, Java Applets.

Java Applets have been traditionally protected by the Java Virtual Machine's DNS pinning mechanisms. These protections simply state if an applet is loaded from abc.com (whether through an HTML page or the codebase parameter of the applet tag), it is allowed only to communicate with abc.com and not with def.com (unless it is a signed-applet). Billy Rios (shown in the top image above) and I presented at Hack in the Box Malaysia in 2007 on how this pinning could be broken. There's a nice excerpt on Billy's XS-Sniper blog, which I used to post on, that covers the subject in depth. The basics of it were as follows:

  • Attacker forces victim to load an cache a Java Applet (this might be done through XSS)

    • This applet would be pinned to the attacker's site where it was loaded from, say xs-sniper.com.

  • The attacker controls the domain the applet was loaded from, as he owns the domain; therefore, he can change the IP Address that xs-sniper.com is associated to.
  • The victim is forced to load the applet again, this time in a new JVM instance

    • In our example at Hack in the Box Malaysia, this was done by forcing the victim's IE browser to load Firefox through the firefoxurl:// protocol handler, which we could point to our site and applet like firefoxurl://xs-sniper.com/appletpage.html.
    • This can be done in a couple other ways which we mentioned in the powerpoint presentation we gave.

  • Since the applet has already been loaded and cached, there's no need for the victim to download the applet again, which is good since xs-sniper.com is no longer pointing to our IP Address, it's pointing to an IP Address internal to the victim's network.
  • As the applet has been loaded in a separate JVM (IE and Firefox will each have their own instance of the JVM), the applet will become pinned to the IP Address now associated with xs-sniper.com.
  • We can now use the full power of Java applets against the Internal IP Address. In our example, we used a Java applet to connect to an oracle database server, dictionary attack the username/password to gain access to the server, and then allow us to run arbitrary SQL queries.

The ramifications here are clear, and quite devastating. Fortunately, Sun patched this issue quite quickly, protecting the unsuspecting. That is until John Heasman (shown in the second image above) of NGSSoftware came around. When Billy and I published the attack that we used against Java Applets, John emailed us about something he was working on, which was even easier and accomplished the same results. Here's a summary of that flaw:

By specifying a codebase URI prefixed by “verbatim:” it is possible to load an applet from a remote location but have the browser plugin believe it has been loaded from the local host. This allows an untrusted applet to connect to and attempt to exploit network services running on the local host. It should be noted that unlike binary sockets in Flash 9, an applet can connect to any port, not just those greater than 1024.

At the time of reporting this issue, NGS provided Sun with a demonstration applet that exploited MS06-040 (”Vulnerability in Server Service could allow remote code execution”) on a vulnerable XP SP1 system.

Scared much yet? With applets, you have this greater capability and flexibility then was possible with these types of attacks against Flash or browsers (until Dan Kaminsky came along and implemented full-blown sockets in Javascript). It's feasible that one could re-engineer Metasploit into Java (eek) and use an applet to perform grand attacks against Internal systems, thus bypassing the firewall through the victim's browser!

Well, again, Sun came and patched John's verbatim attack, which is great news. Then just recently we had this Sun advisory come out, which we blogged about here on ZDNet. As soon as I read some of the shady attack vectors that were involved, I knew it had to be Heasman. I contacted John about this, and he mentioned he would be making a few postings as demos of the bugs he was involved with on his blog, which you can now see here.

The first attack John covers is against Java Web Start. I'll cut out pieces of John's blog posting here to paraphrase the attack:

Applets are instantiated via the <APPLET> or <OBJECT> HTML tag. Both the code and codebase attributes/parameters must be set e.g. <APPLET code="foo" codebase="http://bar"/> will cause foo.class to be loaded from http://bar. The code that loads the class creates a URL object via the following constructor:

This constructor has an interesting property, namely:

public URL(URL context, String spec) throws MalformedURLException

If the authority component is present in the spec then the spec is treated as absolute and the spec authority and path will replace the context authority and path. If the authority component is absent in the spec then the authority of the new URL will be inherited from the context.

This effectively means that executing:

URL url1 = new URL("http://baz"); URL url2 = new URL(url1, "http://bar");

returns us url2 representing http://bar. So what happens if we instantiate an applet as follows:

<APPLET code="http://baz/foo" codebase="http://bar" />

What happens next may be obvious, but to recap, basically it will load the foo applet from the baz website, but report it as loaded from bar, so we've effectively broken Java's same origin policy. Of course, things are never that simple, so there's some complications that John had to get around, as John mentions below:

Of course, the devil is in the detail... there are some complications to get this attack working. Firstly, if we specify a code parameter containing a '.', e.g.:

<APPLET code="http://baz.com/foo" codebase="http://bar" />

then an internal canonicalisation routine is triggered, converting '/' characters into '.' so we end up with a URL looking like "http:..baz.com.foo" and the attack fails. The easiest way round this limitation is to use the decimal representation of an IP address, as is apparently common with spammers. If you're too lazy to do the maths, there's an online converter here. So our code parameter will look like:

<APPLET code="http://2130706433/foo" codebase="http://bar" />

The final complication is that the Java plugin loads foo.class expecting to find a class called "http://2130706433/foo". This is easy to solve - we compile our class with a class name of "aaaaaaaaaaaaaaaaaaaaa" and use a hex editor to replace this string with "http://2130706433/foo" (the compiler doesn't like it but the JVM will load it).

AHA, now we've broken Same Origin Policy! Of course, it doesn't end there, John has an attack that will actually break us out of the Java sandbox! I'll cover that here as well, and I'll also be covering a few more attack vectors against Same Origin Policy over the next week or so, so stay tuned!

-Nate

Topics: Security, Open Source

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

30 comments
Log in or register to join the discussion
  • ouh... That made my head hurt.

    Excellent post. I wasn't sure wither to laugh or scream. Worrisome, I will say that.And while this subject is, in fact, no laughing matter, the way you made it look so easy made me laugh anyway. Good Post, excellently written. I thoroughly enjoyed it. (the article, not the subject matter.) Let this be a wake-up call to us all.

    Hat's off to Sun, for being so responsive, and responsible. There's hope yet in the World. -d (waiting for part II now)
    dawgit
    • Re: ouh...

      Yeah, it really is funny how easy it looks... wait till you see the discussion of how Rob Carter, Billy Rios, and I used anti-DNS Pinning against Picasa. It's not quite as simple as it all sounds when you have the head down churning through the research.

      Personally, I've been consistently impressed by John Heasman's work, which is why I was so glad that I got a chance to cover one of his flaws. The Litchfield brothers get a ton of press with regards to NGSSoftwares dealings (and rightfully so), but let us not forget the bad assery (spell check that, if it isn't a word, it should be) of Heasman.

      -Nate
      nmcfeters
      • LOL

        [i]but let us not forget the bad assery (spell check that, if it isn't a word, it should be) [/i]

        <Laughs> Aw man, you made me spew soda all over my monitor.

        I'll forgive you this time though, because your article was a very good read.
        Hallowed are the Ori
    • Yeah, it is a head-acher.

      The realities even more so than the technical aspects of article.

      It is nice to know that the good guys are finding flaws to be patched, and that they are, in fact, being patched.
      seanferd
  • fallacy of division

    A simpler attack on the same origin policy is related to the use of composite web pages and JavaScript widgets in enterprise systems.

    Some platform vendors provide partner applications written in JavaScript access to secure services or session IDs. Any JavaScript widget on the current page can subclass the XMLHttpRequest prototype and watch all service traffic coming and going. All it takes is one malicious script linked to anything on the current page for this attack.

    Just because the browser is a trusted container for potentially untrusted applications does not mean that a web page is also a trusted container. This basic fallacy of division is a big misconception among platform vendors that enterprise customers should be aware of...
    billappleton@...
    • RE: Fallacy

      Yep, I'll be talking about this too.
      nmcfeters
  • RE: Defeating the Same Origin Policy part 1

    Thanks, I wish I wouldve thought to put that in the article!
    nmcfeters
  • Screen door on a submarine

    The "functionality" of browsers to download and execute code without security being engineered in FIRST will be a nightmare of problems over the next few years. As more and more people and companies fall victim to attacks and theft, the designers will finally start backing away from "whiz-bang" features that leave systems open to attack. Many of these techniques may make the developers lives' easier, but at the cost of exposing users to attack.

    It's easy to take a "short cut" like leaving your front door open so your kids can get in without a key, until you get tired of being robbed every week ...
    terry flores
    • Dive dive dive

      What would be the fun in that? "Innovators" get to spill more ink on endless "solutions".
      SteveTheWirePuller
  • I don't quite get this

    "Since the applet has already been loaded and cached, there???s no need for the victim to download the applet again, which is good since xs-sniper.com is no longer pointing to our IP Address, it???s pointing to an IP Address internal to the victim???s network."

    Correct me if I'm wrong, but if the victim's computer is pointing to an internal IP address and loads the same applet from an outside address, isn't that already violating the Same Origin Policy?

    "The final complication is that the Java plugin loads foo.class expecting to find a class called 'http://2130706433/foo'."

    In other words, they've essentially applied a bandage to the problem rather than rewriting the involved class loading code to be secure from the ground up. Yuck.

    That's the problem with applying bandages vs rewriting the code from the ground up to be secure. The bandage solution almost never works. Yes, rewriting lots of code is a pain - but in the end, it's well worth the rewrite.
    CobraA1
    • RE: I don't quite get this...

      So, I'm not sure which part you aren't quite getting. What
      you said sounds mostly correct. Basically, initially when
      the victim was forced to download the applet, the applet
      could only communicate with the server it was loaded
      from, xs-sniper.com, which for arguments sake let's say
      points at 1.2.3.4. We as an attacker FORCE the applet to
      be cached.

      Now, we change the ip address associated with xs-
      sniper.com to 127.0.0.1 and then forced the victim to load
      a new JVM with the firefoxurl: and again load our applet.
      The applet code is cached, so it doesn't need to download
      it again, and our servers ip address has changed from
      1.2.3.4 to their localhost, so now the applet can
      communicate with the victim's machine without being
      signed. That is the violation of SOP. It's not reloading the
      applet from a remote source, as it sounds like you are
      saying, it's simply reloading the cached applet, which is
      STILL pinned in the cache to xs-sniper.com, from a
      different JVM, so a new DNS request is made to xs-
      sniper.com and the applet is effectively pinned to the
      localhost.

      Nate
      nmcfeters
  • Wealthy people forgoe the sublime use of a server w/ ultimate protection.

    Vista is not for the love of homebase users that download everything they can while exploring personnal interests and creating a profile. This article has brass and does explain reasons and somemore with JVM just why you should respect your Vista operating system and just use it and getoff. There is a whole new expression with these Ultimate choices for personnal prestige; is there a need to say more?
    rtirman37@...
    • Uhh...

      [i]is there a need to say more?[/i]

      Uh, no, there isn't. Please don't.
      Hallowed are the Ori
      • RE: Uhh...

        Umm... yeah, so something must've got lost in translation
        there.

        -Nate
        nmcfeters
  • Cache seems a major contributor

    Everything is Cached these days and often causes problems.
    Not reloading something that has changed!
    I hate these new OS's that cache files in directory. You copy
    a new file into a directory across a network and have to
    refresh the directory before it shows up. On a Macintosh you
    don't even have a refresh option and just have to wait.
    We super computers now, why do we have to cache, and if
    we have to, can't we make it work.
    LittleGuy
    • RE:

      Caching isn't really done as much for client-side speed but
      to off-lay server side requests. Imagine a site like the eBay
      market place and how many requests are going back and
      forth and all over SSL... you'd need more than a
      supercomputer to handle all that.

      -Nate
      nmcfeters
      • All the more reason for thin clients on the browser

        Imagine how much faster, simpler, efficient, powerful, etc,
        etc...

        It is nice to have a web interface that can be used
        anywhere, anytime, but none of them are useful with a 56k
        connection. Client side code can support slow connections
        because it only need to communicate data. We could
        eliminate security issues since the clients would be
        certified by the company that provides them. The world is
        mis-lead into thinking client code is bad, we can only trust
        the operating systems and a browser. Let the developers
        develop powerful code without browser limitations and let
        the operating systems allow these tools to be installed
        easily. Keep web interfaces for your blackberry's and when
        no other options exist.

        The Operating systems should have a trace mode which
        shows the user exactly what their programs AND OS's are
        doing. What's sent out, what brought in. What is my
        computer doing now? If we don't like something, we
        should be able to uninstall it on the spot. No more hide
        and seek. Some of these tools exist, but they are far from
        built in.

        Why do we use our computers as dumb terminals?
        Why don't people see this?
        Give me back my PERSONAL COMPUTER!
        LittleGuy
        • RE: Thin Clients

          >We could eliminate security issues since the clients would be certified by the company that provides them.

          Wow, I completely disagree with you here. In fact, I firmly believe the move towards more client side code is going to make things more insecure. Besides that, thin clients would have the same issues with Same Origin Policy, so in the context of this talk, it doesn't make a whole lot of sense... I mean, we're talking about Java Web Start, Applets, Flash, Silverlight, these are all things that push down onto the client side a good piece of code, albeit that some work with the browser.

          >The Operating systems should have a trace mode which shows the user exactly what their programs AND OS's are doing.

          Who needs it? Regmon, Filemon, Wireshark, DTrace on Mac and *Nix, etc.

          -Nate
          nmcfeters
          • Browsers have become thins clients with lots of holes

            Browser+JVM have become a Frankenstein of a thin client that executes mutable code and has effectively unlimited access to OS and user data. If everything was executing server-side then we wouldn't have so many problems.

            If you meant trusted, tested, and signed thin clients, well ... Who do you trust? I've seen signed applets with malware embedded in them. I've seen MANY reputable sites that just refuse to use signed code (too lazy, can't be bothered, you name the excuse). One reason the security system is so broken is that so many websites just ignore it and force you to drop your pants just to access their sites. Users have been trained to violate their own security by everyone from CNN to Microsoft downloading code, so they hit the "OK" button out of resignation as opposed to any intelligent decision.

            And of course, what does signed/certified mean? There isn't a SINGLE service provider out there who takes responsibility for their code or their actions. Not one. Everybody has a multi-page TOS or EULA that describes in detail how they are not responsible for any reason, including negligence or fraud. Why would you trust anyone like that to execute code on your computer??
            terry flores
          • RE:

            Neither approach by itself is desireable. I would say the greatest push towards thin client type applications has little to do with security and far more to do with performance.

            -Nate
            nmcfeters