hittin the hash | yet again

hashes and collisions have been on the back-burner for a bit now w/ recent hullabaloo...

so the thought that keeps coming back (reminder: /me != math guy) came from my experiences w/ gentoo... either the kernel or portage (but not both ;) used .sig files which contained multiple hashes for verification of the download integrity.

so say you've got a 1/x chance of collision in md5 and a 1/y chance of collision in sha1 (assuming that x & y are both reasonably large numbers), then isn't the likelihood of getting a collision of *both* hashes on the same file exponentially larger than getting a collision on x or y individually?

so if we're really worried about the apparently real weaknesses in some md5 and the up and coming realistic weaknesses in sha1 (via that chinese-professor-ninja-woman & her math students iirc), why not just start checking multiple hashes each time we verify integrity?

no new technology needed, just parse more than 1 value before you evaluate that if/then to true, right?

the birds n the bees

i've heard that nature repeats itself at different scales. seems reasonable to me. i know that nature has a lot to teach us (and if you don't, then sry but you're not paying attention)... so let's play around w/ analysing some attack and defence in nature and see where we end up..,

source article about bee's which may or may not be getting completely pwnt

beekeepers that didn't suffer from Colony Collapse Disorder, or had only a touch of the plague, made changes too, and they are still around and in fact are doing well and growing. Those changes have been huge in terms of what they have managed to do with the number of colonies they have, and even more so in terms of the paradigm shift in colony management techniques.

wait... orgs are supposed to adapt?

the major shift has been in how beekeepers monitor for, and control varroa mites in their colonies.

monitor the health and activity of network participants? what?!?

Better techniques are being used to find and count mite populations, and safer and kinder techniques are being used to control those mites.

are you one of those managers who told a motivated employee that dedicating time to review logs doesn't matter? for shame! for shame!!

This is good because mite populations don't build up to lethal numbers, lots of mites aren't able to pass along destructive viruses, and the control agents previously used are no longer building up inside the colony.

in my experience, manual intrusions seem to involve a period of time where the intruder evaluates and probes prior to executing whatever plan they have to help themselves at your expense. looking for signs of intrusion (logs!) is vital...

Beekeepers are feeding their bees more food when food is scarce, feeding them at a more appropriate time in the season, and feeding them better food. All have contributed to better wintering, better buildup, and healthier colonies.

what? support and nurture the business?!? crazy-talk!!! (lol)

flags aren't always true

srsly, we know this....

anyway, so the official story is that (an) al-qaeda cell(s) in Algeria are dying because they caught the black death... unfortunate side-effect which occurs when attempting to kill the american devil w/ biological hazards...

forgive me, but while the whole 'omfg terrorists w/ bio-agents' story is quite striking, i kinda expected red threat levels and all of that.

but you could consider an alternate view-point... the black death is highly curable. so if you infected hostile covert operatives with it they would spread it to their allies (your enemies!) who would be faced with either death or treatment at a hospital (oh, the black death you say? i'm sure the security services aren't interested in anyone with *that* old disease).

just a random thought...

noscript feature

ok, so peeps around me might've heard me blabbing on and on about my exciting noscript 'discovery'... i stumbled upon functionality i thought was weird while searching for sharpening stones for my katana (ironic but true).

anyway, i procrastinated research for a month or so, and when i realized i wasn't going to fuzz each html tag for js execution i emailed giorgio... that deflating sound is my ego:

many thanks for the PoC.

Is it just about links going back and forth in history working?
If so, fortunately that's a feature, not a bug: NoScript Options|Advanced|Untrusted|Attempt to fix JavaScript links.
In order to make user's life easier, NoScript tries to detect JavaScript links used for navigation purposes (e.g. containing an URL or resembling a back/forth history navigation) and "emulate" them on the fly *by design*.
If you want, you can disable this feature from the aforementioned configuration option.

Please let me know if I'm missing something more malicious.

Thank you again
--
Giorgio

i respond:

oh wow! rtfm & bad on me! ;) ok, well the things that seem malicious are all subtle imo.

the fact that .go() can be used for arbitrary navigation kinda seems dangerous. even though you'll be running noscript wherever you end up, it could be used to exploit a vuln that noscript doesn't protect against (possibly flash, pdf, etc).
...

and giorgio disagrees:

no "automatic navigation" can be triggered, because of the way this feature works: it reacts on *user click*, checks if the clicked item is a link (either an anchor or a map or a button) and tries to "guess" the destination by simple string parsing, then emulates the navigation.

Cheers

well, i'm not going to get into an infosec pissing match w/ a guy who's contributed more to protect end-users than i prolly ever will... sigh...

i was really surprised to find script execution when i had ns set to not allow scripts globally.

for the navigation feature, i've got no click generating foo atm. iirc there are things that can be done to overlay pages and catch clicks.

for the sandbox fun, nursing my bruised ego kept me away from coming up w/ a way to smuggle the information back to the attacker. but my understanding of infosec suggests that giving someone a way to discover information about a system (file exists, exists but you don't have perms, exists and is executable, and doesn't exist) is not optimal. also, prompting a user w/ a download dialogue seems dangerous, even for local files.

anyway, i've put up a quick PoC for the stuff i was playing with...

winter cleaning time

was out in cali visiting my folks, and got into an infosec discussion w/ dad (who sat patiently while i ranted for a *while*).

on the topic of best practices i was talking about password rotation and pushed an idea i've been kickin around (but which has roots w/ @shawnmoyer)... i've been thinking of doing a livecd experiment (really, someday soon), and for a less extreme suggestion i brought up treating your OS install as a replaceable session. do quarterly rotations, or whatever.

doing this limits the lifetime of a lot of compromises, ensures that recent (restorable) backups exist, and pushes you towards a core set of applications which are being kept up to date.

he asked if i was doing this myself, and i owed up and said no. so now i am. bleh, me and my big mouth... ;)

anywho, i'll be linking up interesting docs and stuff here when i find em...

hashes and collisions

ok, so there's been a few blurbs about hashes and collisions lately...

this is something that caught my eye back in the day in CS class...

i am not a math guy at all (stats breaks my brain), so i am not at all qualified to speak on this topic. a hash function like md5 or sha1 or whatever takes an arbitrary sized input and reduces it to a pseudo-unique string of a certain size. so take the following md5 values:

echo "r" | md5sum
72cfd272ace172fa35026445fbef9b03
echo "rw" | md5sum
bc3f381953be1f16b956a9d394cf969f
echo "rwnin" | md5sum
023c306a26488624aaa2b3028779cfb0

so each input gets a "unique" output, but the issue is that a one, two, five, or five thousand character input always gets a 32 character output. so if you input a single character, or the entire text of hamlet, or any (or every) subset of hamlet possible you will always get a 32 character output with md5.

as i said before, i'm not so good with math, but there is a fundamental problem here. a 32 character hex value can represent approx 3.4x10^38 values. that's a ton!!! BUT. that huge number of values is used to represent *all arbitrary (infinite) values*...

and that's the problem. so even sha512 gives you a fixed length output. ultimately you know that collisions in such a system are possible. they may be mathematically unlikely, but they are inevitable.

so it's kinda frustrating to read the vuln advisories which say "oh, most people stopped using md5 so this isn't an issue", because a few years ago there were advisories which said "we stopped using 3DES so this isn't an issue".

if we decide to place our trust in hash based certificates (which is our trust in the tubes, at the end of the day), we need to accept that someone might get lucky and fake a CA cert. the haters may say "oh well that's super unlikely". well, i guess they are the same people who say "it's stupid to buy a lottery ticket! do you know the odds!?!"

well guess what, every week or three, some lucky bastard wins the lottery. and some unlucky bastard gets struck by lightning. so don't be surprised if someone finds a collision for your hash algorithm.

ironic: /me props av company

so i've dogged on the AV industry pretty hard in the past, but i want to give some props to the peeps at McAfee Avert Labs.

i've been following them on my feeds for a while and they turn out consistently interesting and nifty blurbs about attackers. sometimes tech, and sometimes just info.

i found this portion of a recent entry particularly interesting:

Many websites employ security images to convince the user that they can feel safe logging in so long as they see a teddy bear, a train, or some other image they choose from a library when creating their profile. As phishing scams become more complex, scammers’ websites can easily start acting as proxies to the legitimate website. This isn’t in widespread use yet, but a few isolated incidents have been seen, and the technique is easy to craft: when you enter your username into the phishing site, the site turns around and queries the legitimate website for your security image. It can then display the security image to the customer to gain their trust.

that's just an awesome bit of info. attackers using their phising sites as proxies to get your security image?!? a simple and prolly quite effective hack against pseudo-2-factor auth. it doesn't break the tubes, and there are mitigations, but it's something i'd never thought of before.

btw, the theme of that blog post is about online fraud and also users who are new to the internet, which is a topic some friends and i kicked around a while ago. we just got to the point where grandma isn't going to fall for lovebug type emails, and now we've got this emerging class of users out of china, some african nations, and other emerging economies. do we have to re-educate all of these people from scratch???

i was happy to hear from a coworker who recently got back from a trip to china that the security team he worked w/ over there is developing short (30 second) snippets about security best-practices and distributing them to their users as an ongoing practice. hopefully we'll see more stuff like that all over as time goes on...

sooooo, if avert labs isn't on your feeds, i'm poking you cause it's pretty good stuff...

anywho... lookit that, a post which props some AV peeps and ends on a hopeful note... ;)