next »

[vsloathe]

My latest project is the next logical step in the expansion of my cross-domain tomfoolery.

Let me begin by briefing the outside world, and those less well-versed in the javascript security model. Per the "Same Origin Policy" and other such cross-domain restrictions, javascript is forbidden from talking to (that is, sending requests to, receiving data from, or reading/writing the DOM of) any domain other than the domain on which is resides. Let us clarify the "domain on which it resides" to mean the domain that is calling that javascript. The distinction, of course, is that I cannot remotely include a script from site A on site B and then magically have access to site A's security context from within that script.

Now that we all possess a rote mastery of the javascript security model and domain security context, let me explain what we're after.

In the past, many people have developed methods by which to circumvent the security model I've described above, but every method ever developed involves cooperation from the remote server. This is inconvenient for many reasons, I'm sure you can think of a few off the top of your head. This is where Cross Site Scripting (XSS) injection comes in. There is a lot of mysticism, especially in the non-technical webmaster community, surrounding XSS injection. Let me first start off by clearing up any confusion on the legality or legitimacy of XSS. There is nothing illegal about XSS. As long as you do not modify any server side script or use it to "gain unauthorized access to any computing resource not belonging to the accessing party", you're not doing anything illegal. XSS vulnerabilities stem from a webmaster being less-than-competent enough to secure the forms and input methods on his or her website. That's a long explanation, and you'd think that competent webmasters outnumber the less-than-competent ones, but from my research and many others', you can rest assured that there is maybe a single digit percentage of sites on the web that are not vulnerable to some form of XSS injection.

So let that be a lesson to you: properly sanitize your form inputs!

Ok, so we've found a page where we can inject script into a form field and it will be executed by the user's browser. Super. We own the user's session at this point. Let me pause for a moment and say that I *really* hate relying on poorly-secured...anything for my hacks, but let me also say that, as I mentioned before, XSS vulnerabilities are pretty easy to rely on. There are a number of fora out there where 30 or 40 new XSS injection vectors are found every day on popular sites.

The most important question: What to inject?

Here's the part where I am. I'm working on a piece of code that opens an iframe to inject the target page. Once we are in that domain's security context, a 2-way communication channel can be opened (via the injected code), and we have access to the target site's DOM. The piece of code I'm working on involves a simple protocol for writing to and reading from the target site's DOM. By manipulating the target site's DOM from the master node, we are able to make all manner of requests to the site. Say I wanted to add a script to the site's DOM with the src attribute set to a script that is hosted on my page...Perk's XMLHTTPRequest class for example. Now I have a nice, compact way to GET and POST data from the security context of the target domain, and read the response. The holy grail!

Anyway, once I'm finished the first piece of vulnerability auditing code, it will be posted here.

[perkiset]

WOW nice work VS, looking forward to seeing your final installment on this one.

NutBalls volunteers for you to make all of his sites zombies as a demonstration piece.

[nutballs]

lol fucker

[DangerMouse]

:s I feel thick! Can you draw me a picture please lol? Are we talking about achieving this?

MasterSite ---> Opens iFrame to TargetSite ---> TargetSite capable of performing GET / POST requests at will based on exploiting XSS hole to get initial code run

The bit I'm not sure I follow is how the initial injection will be performed? i.e. How will MasterSite inject the iFrame that contains TargetSite to set up the initial communications channel? Presumably theres no access to the DOM of an iFrame, so I guess its prassing in an intial XSS vector via a GET request?

DM

[vsloathe]

It can pass it via GET or POST, see my "asynchronous remote post class" in the PHP repository here on the boards.

[ed: Find it here: http://www.perkiset.org/forum/php/vsloathes_asynchronous_remote_post_class_20-t1082.0.html  /perk]

The way the 2 frames (parent and zombie child) will communicate is through the use of URL fragment identifiers. The Google should reveal more on this method, it's pretty basic. The way the protocol I'm developing works (based on URL fragment identifiers) is as follows:

Child iframe gets injected, loading the initial payload with a specially formatted URL from RPX class
Child iframe sends "connected" message back to parent
loop{
Parent sends command, waits for response
Child sends response, waits for command
}ad infinitum

[DangerMouse]

Ah thanks, interesting reading on the fragment identifiers.

I think where I'm getting a little muddled is where the intitial iFrame is injected, and it's target.

I think I wrongly assumed that a page under your total control, would create an iFrame with a target of the site you wanted to exploit, and use that relationship to execute further javascript within the context of the framed site; but now I'm guessing that the relationship works the other way around? Site out of your control gets an iFrame injected via XSS vulnerability, which then caters for a full comms relationship between the two, the iFrame being the controlling site and the site containing the iFrame being a victim? Or am I off base again?

DM

[vsloathe]

Ah thanks, interesting reading on the fragment identifiers.

I think where I'm getting a little muddled is where the intitial iFrame is injected, and it's target.

I think I wrongly assumed that a page under your total control, would create an iFrame with a target of the site you wanted to exploit, and use that relationship to execute further javascript within the context of the framed site; but now I'm guessing that the relationship works the other way around? Site out of your control gets an iFrame injected via XSS vulnerability, which then caters for a full comms relationship between the two, the iFrame being the controlling site and the site containing the iFrame being a victim? Or am I off base again?

DM

That sounds about right. Each site can read and write the src attribute of the other, so once the "payload" is injected in the iframed site (which has to contain a vulnerable form for any of this to work, remember!), you have complete and utter control over the child (iframed) site.

None of this is really new or earth-shattering, and the fact that it relies on an easily-averted exploit ensures that it won't ruin the "internet as we know it" any time soon, which is why I believe in full disclosure of what I'm doing. None of the techniques are new, it's the combination of them that I'm doing here that I think makes it kind of neat.