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

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

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

cloud security redux

short and sweet post.... tons of talk about the cloud over the last 6-12 months...

so the cloud is a bunch of boxes offering a service out there on inet. all the security discussion i've seen has focused basically on confidentiality of your data once it enters the cloud, but mb there's another way to look at it.

clouds are potentially massive environments of resources which are allocated and partitioned to paying customers. instead of focusing on the risk posed to cloud customers, why not look a little at the risk to the cloud operators?

clouds are big business networks, and big networks are often under-monitored. attacking cloud allocation schemes could result in resources being allocated to an attacker off-the-record. "ghost" resources in the cloud controlled by an attacker who isn't paying for service and isn't abiding by the ToS. these ghost resources could be used for all kinds of illegitimate purposes with significant value for the attacker who controls them.

if you are subtle, you could probably operate under the radar within the cloud for quite some time...

effective selective near real time mass communication?

today i saw the highway being shutdown along a route that some important person would presumably soon be traveling. i was able to observe some interesting operational details, and started pseudo-red-teaming the situation in my head looking for vulns.

i tweeted about the route, and that got me thinking about how much operational real-world security benefits from obscurity.

if someone was paying attention and could act upon the information i tweeted, it could present a significant security exposure. ZOMG!!!1! twitter is a terrorist tool!!! nono, that's not what I'm saying...

the amazonfail hashtagging phenomenon shows us something about it. If a grassroots group of people want to track a topic in near-real time, they can do it. soooo, loopin back to phy sec and operational security issues, hashtagging could be used to track a number of things which traditionally have been effective in-part due to obscurity, such as:

#roadblock
#sobrietycheck
#speedtrap

these are all candidates for multi-tagging with a #city hash to make them more useful.

i guess you could track celebrity locations in near-real time too:

#bradpitt #paparazzi
#clairedanes #stalker

orrrrr how about #flashmob #city.... or #hotclub #city.... or #riot #city... waitwaitwait...

anyway, the point (if there is one) is that no single person can make twitter give them this type of information, but if certain hashtags becomes popular grassroots phenomenons, they can significantly alter the effectiveness of traditional obscurity based physical security measures. even if #roadblock is never picked up, someone looking might be able to infer things using #traffic ;)


*update* - looks like i tweeted the route taken by the presidential motorcade...

ie 8 add-ons

so ie8 supports add-ons... judging by the number of ratings, not too many people are playing around yet...

the security options are disappointing, and i'd really like more visibility into how these apps are vetted. are they ms built, or community-built? i'm too lazy to register atm ;)

here's an app from wayyyyyyyyyy back in the day... prolly my first app layer foo, for doing zebulun... lulz...

google chrome security thoughts

some peeps say nay and others say mb...

looks like pdp is running w/ it as a model changing the way we use computers...?? he doesn't say so, but it sure sounds similar...

there have been a number of vulns (carpet bombing, etc) reported so far, but i'm not too worried about those. this is beta software, so we have to expect there will be some oversights which can be exploited. so, based on what we know today, how do we see the design changes which will be present in the final release impacting security?


[process isolation]



process isolation may defeat some client side attacks... are cookies isolated to their tabs? if so, browsing separate domains via tabs may offer some protection from cookie stealing and CSRF.

this is kinda out there, but since processes are isolated, watchdogs on memory and proc usage (mb io?) may be able to identify 0day-ish attacks which are consuming resources...? that's a long shot tho...


[incognito]



incognito mode seems nice on many levels. i've heard jokes about how it's just a pr0n-mode, but there are many times i browse around online where i don't want to allow any web site to write anything to disk (ie: reading headlines on digg). i don't expect anything hostile to happen, but there are attacks (ie: malicious ads/apps via 3rd party content) which could be bumped into. why not use incognito for daily-browsing? might it be a reasonable alternative to running no-script, ad-block, cookie-safe, and flash-block?

i do question whether or not this is read-only, or just a more restricted jail. it seems like temporary file writes will still be required, but i'm not quite sure...


[attack vectors]

so what attacks look possible under this design?



so if users drag pop-ups out, and they get promoted to their own windows, how does that impact sec? does all retained information (cookies, history, etc) propogate to the new process for the pop'd out tab?



sandboxing seems very very good... lots of badness (malicious jscript stealing creds, keylogging, etc) is mitigated in this model. but can it be attacked? if each process is isolated, can an escalation attack upward against the master chrome process succeed in breaking the security model? that brings the question of how much chrome security depends on the isolation model being maintained (ie: how bad are things if isolation is gone; are we just back to where we were w/ browsers pre-chrome? or is it worse b/c we assumed we'd be isolated and so didn't take other sec steps)



the idea of tracking what a user has actually requested is pretty nifty. reminds me of packet-filters (old browsers) vs stateful firewalls (chrome). the comic here points out that plugins don't conform to this model, so those may be a weak-point. another issue will be whether or not a process can create a false user request. can a malicious pwnt tab process mimic some type of user request, either in the local tab or in another tab process.



sandboxing plugins reduces risk, but they can now attack upward as well? will a flaw in a plug-in feature (ie: quick-time, flash) potentially open the chrome process to attack?

another interesting tidbit in the diagram is that the chrome process links pages to plugins. can this be abused somehow? can plugins associate themselves w/ alternate pages? what makes a process eligible to be linked to a plugin process? etc etc etc...

that's all i've got for now. chrome seems to offer some nifty and refreshing looks at browser design.