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

ie 0day and the heap spray....

so this little writeup on the ie7 0day by hdmoore got me thinking about heap sprays and such.

that reminded me of this awesome writeup by justin schuh about turning a firefox bug into a sploit, because i think the technique he was using here was also a heap spray. (note: turns out it's not a heap spray, but similar on some levels)

i'm really curious about leveraging heap sprays in javascript enabled applications beyond the browser (such as PDFs and Flash), but i doubt i'll get motivated enough to play. i am way behind on things already!

i keep putting off my pending semi-substantial blog post too... /me sighs...

vuln report digestion

(note: this is NOT an article about responsible disclosure ;)

so i found some vulns in a commercial app a while back, and i've been working w/ the vendor to get them reported and fixed and all of that.

when i first tried to contact this reasonably large company my google search foo was weak, and i couldn't find the proper email address to report the vuln. so i started digging through the "contact us" phone numbers and making calls. after 2 hours of phone trees and transfers and being on hold, i went back to google and found the proper email address.

this is a company which makes IT products for businesses, and their security reporting contact info is buried deep enough in a page that what i found on google was someone asking my same question and someone else answering it.

so what happens if you try to do responsible disclosure on something outside the norm? how about the modem CSRF vuln disclosed by nathan the other day? here we have a consumer grade product produced by a big ass corp, and an attack which exploits default settings via one of the less well known web application attack vectors.

if you hit the contact us page at motorola.com to try to report this issue, you're relegated to the "general info" team. are they going to take this issue seriously? are they going to route it to the right people to get a firmware update made (to fix the retarded defaults) and a notice pushed out to consumers?

this may be an application level attack, and it may be against a non-traditional target, but the disclosure was pretty similar to dropping an 0day. anyone who read his blurb and has some tech skills could be out there owning gateways right now. and if you did it right you could potentially own a lot, which could lead to a lot of other attacks.

i'll go out on a limb and speculate that privately reporting this vuln to motorola would probably be more of a pain than i went through doing my recent disclosure.

it'd be nice to see companies that produce tech products or services putting security contact info on their main "contact us" pages to help researchers who want to privately report vulns but don't want it to be an arduous journey...