Thursday, May 27, 2010

novel(?) anti-xss technique caught my eye

saw this a few weeks ago, and it stuck out b/c i'd never seen or heard of anything like it... i ran it past a few peeps i respect and they'd never seen it, so i figured i'd share :D

it's very common to find XSS in search functions on web apps where the text a user enters into the form is reflected onto the page after the form is submitted. so you hit an app and search for "foo" and on the search results page you get back the search form is populated with "foo" which you just searched for. well if someone constructs a malicious link like:

http://someapp.somedomain.edu/search.htm?q=foo"><script>evil code here...

you end up w/ an xss attack assuming the app is poorly written...

typically during web app assessments you've gotta go smack the developer and tell them to validate their inputs and encode their outputs, but this time it took me a minute to figure out what was going on... sooooo here's the resulting html src of a little PoC i put together and tested w/ google app engine and ff3.x:


<html>
<head>
<title>xsstest</title></head>
<body>
<center>
<form name='testform' action='javascript:alert(testText.value);' id='testform'>
<input name="testText" id="testText" tabindex="1" onkeyup="javascript:alert(this.value)" />
<input type="submit" name="btnTest" id="btnTest" value="testfoo" onclick="" />
</form>
</center>
</body>
</html>


so wtf is that? ok, this was based on a search form on an ajax-ish web app. there was more to the real app, but this includes all the relevant bits. when i searched on the app, i saw my inputs were reflecting in my browser so i went to check if they were html encoding them server side... but the value i was inputting in the search field never showed up in the page src... ermm, wot?

well, here's what i think is happening:


<input name="testText" id="testText" tabindex="1" onkeyup="javascript:alert(this.value)" />


note that the "value=" tag is missing above. that makes the value attribute null when the server first serves it. when you use the form the app acted on your inputs using stuff like onkeyup/onkeydown, but when the user data needs to be read, it's done using the object oriented "this." convention which allows an object to refer to itself.

when you submitted the form the app would process your inputs, but the actual value you enter is never written to the page by the server. it exists only in memory on your client machine and is never written into html src. when the page refreshes your client browser renders the input element and snags the 'value=' value from memory and thus seems to avoid those pesky output encoding issues...?

anywho, it looks legit to me, but it's not a game changer or anything. kinda limited in it's application, and doesn't do anything for sql injection, csrf, etc.

but still kinda nifty mb ;)

Friday, May 7, 2010

rwnin@firefox-extension: ./sslvis -h -vvv

[sslvis: firefox extension]
https://addons.mozilla.org/en-US/firefox/addon/158232/


[background]
iirc, the basis for a lot of security assumptions on the modern intert00bz come down to everyone trusting that the CAs will keep their promise to not issue bullcerts (technical term: bullshit certificates).

but it looks like they are issuing them to governments and intelligence agencies:

http://www.wired.com/threatlevel/2010/03/packet-forensics/
http://arstechnica.com/security/news/2010/03/govts-certificate-authorities-conspire-to-spy-on-ssl-users.ars


[not to be a bitch]
i mean, in theory all important comms should go over crypto that you manage and trust... and this can be used for 'good'. but that doesn't change the fact that most people use these communication channels for a variety of reasons with an expectation of near absolute privacy.


[so the theory goes]
they are hunting someone using 'secure' public inet services and wanna do a targeted interception or run some pattern matching on a network near afghanistan to find someone. so they do a network level tap on a choke point in the networks serving the region.


[and?]
the CAs gave em a valid cert, so they plug in their device and they're doin cleartext intercepts on everything going through that region. the cert is valid, it's made out to google or sekritbadguylayer.com or whoever.


[massive qualifier]
so do you think that cert the CA gave some snooping party is an exact match of the legit cert of the one running in production?

i'm gonna guess no for the following reasons:

1) the CA would be completely destroying the trust model (bad for business) if they couldn't revoke the certs
2) maybe they simply can't reproduce a cert they issued because data wasn't kept or conditions can't be reproduced (?)


[not my idea]
hashes are just dang hard for people to pay attention to, cause they're huge random strings. but a few years back at bh/dc someone (kaminsky? ranum? sober? no...) was talking about how you can visually represent that same hash value as a series of colors, and all of the sudden it's really easy for humans to notice when a hash changes.


[soooo]
boiling a hash into a word is what sslvis does, and it's a very similar concept. if you hit gmail one day and your word is 'paradox' when it always used to be 'apple' you can easily notice that those words have changed. normally you wouldn't be alerted to the change because there are no warnings or indicators for changes to another valid cert.


[verification?]
there may be a completely legit reason the cert changed. certs expire, disks fail, load balancers exist, devices change, etc etc etc. that's why sslvis sends the host, domain, tld, and hashword value to an external app server:



the default server is hosted on google app engine and feeds the info into a tagcloud:



it includes a (crappy) search feature which let's you visualize the proportions of the certs other people are seeing in real-time. it is slated to include clouds which show the results over time (vapor tagclouds atm ;).

so if your google word is paradox, and that's what everyone else is seeing for the last hour, you're prolly ok to feel kinda sorta mb privatish... kinda...

but if your google word is paradox and there are no other results or just a couple others there is a stark visual cue in the juxtaposed sizing in the tag cloud... this let's you know you're experiencing an anomaly in your connection, and mb you shouldn't proceed...?



in the img above, it looks like maybe a non-malicious anomaly, since canvas is the normal word for www.google.com from what i've seen... (should prolly implement a word search function)


[communist socialist conspiracy?!?!]
well it kinda democratizes and visualizes the whole CA trust issue. a sort of sunshine for crypto maybe? again, not a new idea...


[sidenote]
what about wildcard ssl certs? in theory this detects them too...?


[erm, privacy?]
yea, there is a definite loss of privacy here. but before anyone rants about it, you kinda need to understand that there are rooms in major network facilities where state actors are tapping massive networks on a massive scale. the fact that you go to ilovefarmanimals.com or someshadysite.com is already potentially known to a potentially interested party, even if the details of what you are doing are hidden in the SSL channel.

oh, well that and you can use regexp exclusions or just disable reporting. by default rfc1918 networks are excluded. a trailing asterisk let's you know that a value wasn't reported.

also, you can choose your remote reporting server in the extension options and the source is available so you can just light up one for your own network (and/or just write your own interface to capture the data, it's just a couple HTTP GET parameters).


[what else can it do?]
well, if you capture ip information you track and geo-locate anomalies in near-real time... that could be kinda cool i think...

it would be pretty easy for the app to report back to your browser that your result is way off from the current norm and actively alert you somehow...?


[kludges?]
well... erm... a lot... but right now the data is exported via xmlhttp requests that fire each time you change focus on the tab, and not for each actual request you make... firing on each request also kinda sucks for sites with frequent requests. keeping tabs on what requests are made and how often is probably the way to go.

(btw, i use a secondary xmlhttprequest because you can't read the public hash for an active connection from javascript easily afaik)

there are more kludges... check it out for yourself, i'm def open to suggestions ;)


[downsides]
you're losing (a ton of) entropy, so there's an increased chance an attacker could find a collision and be really tricky. right? a bigger wordlist and highly efficient hashing algo helps there mb...? it might make sense to just report the actual hash back to the server, or pass it as a sanity-check parameter. not sure what (if any) privacy ramifications that might have.

also the app currently has no anti-fraud capabilities. rate-limiting prolly makes sense server-side, and client-side the user could be subjected to some captcha-esk process that issues a cert to check for humans vs cylons.

the app is currently cleartext comms, so a mitm could mitm you when you use it ;)

oh, and this is all only works if the snoopers aren't getting exact copies of certs, either from the CAs or from a compromised certificate store.


[other?]
there are some bugs and unimplemented features... and the app is still in the sandbox since i'm not done testing and adding features.


[coda]
that's all... for now... :)

Monday, April 19, 2010

why it sucks to be an infosec defense guy & an example of real-world cyberwar

i got a chance to listen to Richard Clarke talk w/ Terry Gross on Fresh Air today, and while it was full of a lot of the things that suck about listening to mass-media talk about infosec, there were definately some gems...

i'd say it's worth a listen... anywho, onto the content:


[why it sucks to be an infosec defense guy]

@ 02:20

"somehow from a thumb-drive, a virus a worm got into the classified network, which is supposed to be a closed loop network, of CENTCOM and attacked compromised thousands of computers of our warfighters in Iraq and Afghanistan and probably exfiltrated large amounts of information to someplace in the internet [in December 2008]"

ok, so this blurb says two things to me.

1) "it attacked an infected thousands of computers on a closed-loop network" - here's a lot of assumption, but when i hear about worms spreading in closed networks, it makes me say 'oh you didn't apply security patches to those machines because you thought they were safe'. unless this thumb-drive was full of 0day, this incident is classic failure to follow best-practices because you assumed some other layer of defense would keep you safe.

2) and wait, was this "closed-loop" network airgapped? well, clearly it wasn't if you were able to exfiltrate any data out of it to the internet. and even if it wasn't an airgapped network, why the #@%(*@#%* are you letting this classified military network which supports men & women with guns TALK TO THE INTERNET?!?! srsly guys, you know firewall policies can be set to block traffic leaving your network too, right?

this kind of stuff just sucks. here you have a network which should be one of the most secured in the world, and has tons of resources dedicated to protecting it, and it falls flat on it's face w/ two well known best practices. when .mils aren't doin this stuff, you know that corp networks are probably worse. how can you tell me to help protect you if you're unwilling to patch and control your network? and you're surprised when bad things happen to you? srsly?

we know how to do so much good defensive stuff, but it's a lot of mundane process and procedure. it takes cycles and people, and it takes some documentation and training, some audit and enforcement, and it takes some effort and work. and it seems like no one is doing it... booo :(

oh well... c'est la vie


[an example of real-world cyberwar]

as a bonus...

remember when Israel bombed some secret facility in Syria? well, according to Clarke, that attack was performed by Israeli F-15s and F-16s which are very not-stealthy fighters. so a reasonable question is why weren't these planes shot at/down by Syrian air-defense networks?

according to Clarke, the Syrians saw nothing on their radar at the time and after the fact because "the Israelis had used cyberwar as part of a traditional attack. They had taken control of the Syrian air-defense system, and made all of the radars look like there was nothing in the sky, even though the sky was filled with Israeli fighter-bombers."

anyway, just wanted to include this because so many people in the infosec game seem to think that cyberwar can only be a digital-pearl-harbor type catastrophic attack. as if the entire attack will be encompassed by bytes on a wire. in my opinion cyberwar capabilities can be used effectively as a small part of larger tactical engagements. dismissing cyberwar as a fantasy ignores real-world realities and capabilities which are apparently being put to use today by state actors, and possibly others...

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...?

Friday, February 5, 2010

datapyning (tool release)

okok, i'm always writing stuff and never getting it released, so this time i've kludged up a tool and dropped it on google code:

http://code.google.com/p/datapyning

just a little python script that will query search info (to google atm, others in next rev) and pull down all the returned results. the idea is to allow you
to collect files/data en-mass and store it away for further analysis later...

[purpose]

so is there any security relevance here? well i built the tool to archive data for a security research project i've been kicking around. i see it being useful for a variety of research and information discovery tasks, but i donno if anyone else will.

ultimately, the idea came from me trying to find some info i'd seen before and coming to the conclusion that the data had poofed into the aether. if you aren't archiving information you care about, is anyone else???

this tool might help you archive some of that data for your purposes...


[examples]

~ grab up to 20 PDFs posted in the last week w/ the search phrase 'free', verbosely

[user@box datapyning]$ ./datapyning.py -S ./null.list -n 20 -f pdf -t w -s free -v

~ grab up to 100 .xls files in the last year w/ .com, .org, and .net domains w/ search phrase 'profit' quietly into a dir called foo

[user@box datapyning]$ ./datapyning.py -f xls -t y -S ./small.list -s profit -q -d foo

~ grab up to 100 results from the last 24 hrs for each tld w/ the search phrase 'default.password'

[user@box datapyning]$ ./datapyning.py -s "default.password"


[limitations]

* searching for -s 'foo bar' makes google barf, but -s 'foo.bar' works... wtf, mah bad, def on the list to get fixed :(
* other 'advanced' search features (intext:, etc) aren't accesible via cli and mostly not through the search phrase
* currently the tool kinda expects search frequencies >= 1 per day (result dir contains dirs named by search date)
* search domains/sites aren't handled on the cli (files w/ crlf delimeters only)
* max of 100 records per search
* no status bar for larger downloads (it will timeout, make note, and move on if d/l fails)
* no rate limiting, sooo it will use the bandwidth it can
* not sure if the way download file names are genericized and logged makes sense
* tied to google (but potential for either modularized search providers or mb search agnostic)

Tuesday, February 2, 2010

snail-mail-fail

hey lookit, important tax-return document in the mail... wazzat w/ the top of the envelope?



erm... umm... wot?



sighhhhh.... yea, those current number fields aren't blank... fuggin wonderful...



so there's an IRL infosec attack in motion... i'll speculate local postal carriers couldn't harvest enough numbers to make it worthwhile... maybe a USPS mail distribution worker, or someone in the mail or finance dept of Chase or whoever produces their mailers...?