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... :)