shift or die

security. photography. foobar.

MD5 hackers

I was lucky to be sitting in the speaker’s corner at 25C3 when the MD5 hackers met before the talk and was asked to take a picture of them.

I quickly set up my newly purchased Strobist gear and caught the following shot:

The uncropped version can be seen over at the CCC events blog, and for those who need it, here is the original version in its complete 12 MP glory. Everything is released under CC-BY, so I am happy if you use it, but please credit me accordingly (»Photo: Alexander Klink.«).

I was not quite happy with this version, but I learned the typical photographer’s problem: the subjects only have a limited amount of time. Once we (risktaker, POCsascha and myself) had set up a better version with two flashes and a softbox, they were already on their way to their talk … :-( — which was awesome, of course.

DemoTag works

Cynops recently bought a RFID DemoTag, a device that is made by the IAIK people at TU Graz. Its main use is to be able to copy a Mifare card’s »unique« ID. Not having had a reader for Mifare cards, I wasn’t able to play with it all week — not until the mrmcd, that is.

Luckily, local and not-so-local RFID hackers where present and willing to play with it — thanks to Collin and starbug. Here are some pictures of us spoofing a Mifare card with ID »DEADBEEF« :-)

Here is the device with two different readers:

This is how it looks on the client — you connect to the device via the serial port and tell it to be the tag with ID x, and you can see the communication between the reader and the tag:

And this is how it looks on the reader side — DEADBEEF received correctly :-)

mrmcd111b Vorträge

Auf den meta rhein main chaos days 111b habe ich zwei Vorträge gehalten.

Der erste war eine Wiederauflage meines EuSecWest Vortrags auf Deutsch — hierzu gibt es auch ein Video.

Der zweite handelte mal wieder von OpenXPKI und war für eine Veranstaltung dieser Größe mit ungefähr 15-20 Leuten ziemlich gut besucht. Besonders gefreut hat es mich, dass fast der komplette #openxpki-Channel anwesend war :-). Hier gibt’s die Slides:

The(?) DNS Bug

So, it’s out. Apparently, Halvar got pretty close and Matasano accidentally posted the whole thing on their blog — d’oh.

So, as hiding it now is definitely too late, I guess the »no speculation rule« is off the table as well. Here are some random thoughts of mine:

This is huge. It is pretty easy to exploit, so I wonder how stable DNS will be within the next few days (at work, I use a T-Mobile hotspot which apparently messes transparently with my DNS traffic, so dnscache refuses to work, thus I am vulnerable even though I could help it by running a local dnscache — bummer).

Lutz Donnerhacke keeps saying on the Heise forums that this is not Dan’s original exploit (which he claims to know, and I believe him), so I wonder whether this is something completely new or whether it’s just a variant on Dan’s exploit. On the »this is it« side is the testing of $random.toorrr.com, which closely matches the exploit scenario. Also, Dan has been looking at random subdomains of domains in the web context, which apparently with some providers don’t return NXDOMAIN but a provider specific page (this has the “nice” implication that if it can be exploited, the cookies for $domain are in danger even though the website that is compromised is not made by the real owner of $domain).

I would guess that there are some more tricks to it, as Dan returns ::1 on AAAA queries with his (obviously custom) nameserver, so I doubt this is by accident but serves some kind of purpose. Also, all of the advisories mention the birthday paradox which has not come into play with this exploit (yet) - this is just iterative guessing, but there is no such thing as having multiple outstanding queries for the same RR or so. Furthermore, Thomas Ptacek set pretty high expectations on when he would be impressed, and apparently he was …

This exploit would be particularly easy/fast if you could generate the spoofed responses at the requesting client as well, anyone knows if this is remotely possible using Flash, Java, or some other browser-based client stuff?

Well, interesting times to be a security researcher …

Traversing Dan’s directory

So I guess you have all read Dan’s post (and seen Sarah’s video, of course :-).

… And I guess many of you have used the DNS checker on doxpara.com to see if your DNS is vulnerable (although, personally, I like the “dig +short porttest.dns-oarc.net TXT” method better). Well, so did I (and neither my home provider, my mobile provider nor $CUSTOMER have fixed their DNS yet) and of course using wasn’t enough, I had to look more closely at how it works …

Turns out it is doing a simple lookup on $randomstring.toorrr.com, which resolves to the webserver via a CNAME chain that encodes the interesting data from the queries that are sent out by the resolver. So what does Dan do with it then? He writes a file with the query details (requested hostname, date, source ports and query IDs) to /fprint/$randomstring on his webserver (which is automatically deleted after about two minutes or so), which the script then fetches using some AJAX-magic. Luckily for me, he forgot to turn of the directory listing on /fprint/, so not only the original requestor could download the result files, but me too.

Thus, for the last few days, I have been doing something along the lines of while true; do rm 209.200.168.66/fprint/index.html; wget -U “Hi Dan, just compiling some stats, hope you don’t mind … Alex” -r -nc -l inf http://209.200.168.66/fprint/; sleep 30; done and put the output into a database. 471690 queries later, Dan apparently noticed and put a »*laughs*« into /fprint/index.html.

Well, still enough data to produce some interesting graphs. The first one shows the number of new IPs appearing every hour and how many of those had fixed source ports and weak source ports (max(srcport) - min(srcport) < 100).

From here, one can already see that the red line (fixed source ports, thus apparently vulnerable to what Dan’s been cooking up) is still more than 50% of the blue one - here are the percentages of red vs. blue:

But of course, it is not only interesting how many new vulnerable servers are discovered, but what happens to the old ones. The next two graphs show the number of vulnerable servers at the time (some of those may have been fixed, but not retested afterwards, so take the figures with a grain of salt) and how many have been fixed.

Let’s hope that the numbers change a bit before August 6th or I guess all hell will break loose …