Hash-collissions in real world scenarios

Tuesday, April 29. 2008, 21:44
I just read an article about the recent wordpress vulnerability (if you're running wordpress, please update to 2.5.1 NOW), one point raised my attention: The attack uses MD5-collisions.

I wrote some articles about hash collisions a while back. Short introduction: A cryptographic hash-function is a function where you can put in any data and you'll get a unique, fixed-size value. »unique« in this case scenario means that it's very hard to calculate two different strings matching to the same hash value. If you can do that, the function should be considered broken.

The MD5 function got broken some years back (2004) and it's more or less a question of time when the same will happen to SHA1. There have been scientific results claiming that an attacker with enough money could easily create a supercomputer able to create collisions on SHA1. The evil thing is: Due to the design of both functions, if you have one collision, you can create many more easily.

Although those facts are well known, SHA1 is still widely used (just have a look at your SSL connections or at the way the PGP web of trust works) and MD5 isn't dead either. The fact that a well-known piece of software got issues depending on hash collisions should raise attention. Pretty much all security considerations on cryptographic protocols rely on the collision resistance of hash functions.

The NIST plans to define new hash functions until 2012, until then it's probably a safe choice to stick with SHA256 or SHA512.

gajim with otr encryption

Monday, April 21. 2008, 02:21
gajim with otrIn the instant messaging world, encryption is a bit of a problem. There is no single standard that all clients share, mostly two methods of encryption are out there: pgp over jabber (as defined in the xmpp standard) and otr.

Most clients only support either otr (pidgin, adium) or pgp (gajim, psi), for a long time I was looking for a solution where both methods work. psi has otr-patches, but they didn't work when I tried them. kopete also has an otr-plugin, but I've not tested that yet.

Today I found that there is an otr-branch of gajim, which is my everyday client, so this would be great. As you can see on the picture, it seems to work on a connection with an ICQ user using pidgin.

I've created some ebuilds in my overlay (the code is stored in bazaar, I've copied the bzr eclass from the desktop effects overlay):
svn co https://svn.hboeck.de/overlay

Kassenzettel

Friday, April 18. 2008, 21:05
Normalerweise versuche ich aus Datenschutzgründen, nach Möglichkeit mit Bargeld und nicht mit EC-Karte zu bezahlen. Gestern jedoch merkte ich erst im Laden, dass ich viel zu wenig Bargeld bei mir hatte. Also doch mit Karte.

Beim rausgehen warf ich ein Stück überflüssige Verpackung gleich in den Müll und wollte schon mit dem Kassenzettel ebenso verfahren, hielt jedoch kurz inne. Steht da was möglicherweise sensibles drauf? Geschaut, tatsächlich, BLZ, Kontonummer (kein Name, sonst wär's noch problematischer). Ich weiss nicht ob das üblich ist, werde aber in Zukunft darauf achten.

Welche möglicherweise spannenden Datensätze man generieren könnte, durch schlichtes Wühlen in den Papierkörben vor großen Geschäften, das überlasse ich der Phantasie meiner Leser.

Wordpress mass hacks for pagerank

Thursday, April 10. 2008, 02:44
Today heise security brought a news that a growing number of old wordpress installations get's misused by spammers to improve their pagerank. I've more or less waited for something like that, because it's quite obvious: If you have an automated mechanism to use security holes in a popular web application, you can search for them with a search engine (google, the mighty hacktool) and usually it's quite trivial to detect both application and version.

This isn't a wordpress-thing only, this can happen to pretty much every widespread web application. Wordpress had a lot of security issues recently and is very widespread, so it's an obvious choice. But other incidents like this will follow and future ones probably will affect more different web applications.

The conclusion is quite simple: If you're installing a web application yourself, you are responsible for it! You need to look for security updates and you need to install them, else you might be responsible for spammers actions. And there's no »nobody is interested in my little blog«-excuse, as these are not attacks against an individual page, but mass attacks.

For administrators, I wrote a little tool a while back, where I had such incidents in mind: freewvs, it checks locally on the filesystem for web applications and knows about vulnerabilities, so it'll tell you which web applications need updates. It already detects a whole bunch of apps, while more is always better and if you'd like to help, I'd gladly accept patches for more applications (the format is quite simple).

With it, server administrators can check the webroots of thier users and nag them if they have outdated cruft laying around.
(Page 1 of 1, totaling 4 entries)