Our day started with the DECT (part II) talk, a followup of the previous year DECT talk. The speakers focused on the DSC (DECT Standard Cipher) crypto algorithm currently used in DECT phones. The interesting thing is the reverse engineering work done to understand how this algorithm works, note that sniffing a couple of hours of traffic between a phone and the base station, gives you enough information to crack the algorithm and get the keystream used in that conversation, but the capture is pretty special, they said that a useful capture would be something like a continuous silence in the line, that isn’t usual, but possible like if you’re using your DECT phones as an intercom system for small child surveillance, in that case you’ll have an audio channel completely muted, and the other channel with the baby room noise. Anyway, they promised a complete release in january 2010, so more details and specific implementation of the DSC attack then. If you think that exposing weak designs to the public won’t change things, this talk is the perfect example this not always is true. The DECT industry has acknowledged the great work of the dedected.org group and from 25C3 a lot of things changed, the DECT manufacturers are working know to improve the standard and make it more robust. The next DECT standard will be open source, not closed as it’s now and they are working together with the security researchers, to be advised on how to do thinks correctly from a security point of view.
I wanted to attend Playing with the GSM RF Interface but finally I missed this one, the room was completely full and we couldn’t go into, so we tried the DDoS/Botnet talk but I’m sorry to say that we just lasted 10 minutes there, I was expecting a much more technical talk about DDoS countermeasures or maybe botnet shutdown techniques, but instead that, the talk was about online communities like BBS, IRC, blogs and message boards… and what good practices you’ve to follow to monitor them if you’re the admin. We thought that maybe would be a better idea to jump directly to saal1 and take a sit for the next talk, which was Using OpenBSC for fuzzing GSM handsets.
OK, a kind of followup from past year again, when Harald showed us OpenBTS with a BTS bought on eBay, it was amazing. A year after, Harald has talked again about GSM networks, its basic topology and protocolos used. The point here is that GSM networks are pretty closed, they are hard to play with, but the availability of BTS hardware and pieces of software like OpenBTS and OpenBSC make things much easier. The objective from here is to fuzz the network from our very own BTS and audit the implementation of the protocol stack. This is a very closed world, so a bug founded in a device is very likely to be present in others.
By the way, it seems that the GSM RF talk was about a DoS attack (resource exhaustion) launched from a terminal that affects the cell in wich the terminal is registered. I’m looking forward to finding the video recording to watch it, as soon as I do, I’ll write a little reference here, but for now I guess that either the terminal uses some kind of customized firmware (more likely the TSM30) or the attack was launched using a microBTS/nanoBTS connected to a laptop or something like that. I guess that these are the same slides used today.
Last talk of the day, Black Ops of PKI featured by Dan Kaminsky who reviewed all the security flaws that have raised up during the last couples of years. It was the same talk in the BlackHat/Defcon so nothing new under the sun. The first problem explained is about the hash algorithms used by the CAs to sign the certificates. You can find a lot of MD5 signed certificates, and if you remember the last year CCC talk about SSL certificates, it was completely broken using a selected prefix collision attack, doing this you could build your own intermediate certificate, so you can sign other certificates, to get this tou use the public key binary block sent in the CSR to the CA as the “selected prefix”, once you get your signed certificate you could fix it to convert it in a intermediate CA certificate and reuse the same signature from the CA, due to the “magic block” that generates the collision. This was showed last year, and reviewed again this year. Dan pointed out too the use of MD2 as a hash algorithm, but this would be right now a very strange case, despite the example that he has used is an old root certificate of Verisign. Everybody must use SHA-1 nowdays. The other kind of attacks were the “semantic” attacks. One example is to send a CSR to the CA where the CN has a NULL as part f the string. This is fixed, but could be allowed to get valid certificates for CN that you don’t own, or wildcard certificates. To finish, some examples using ASN.1 encoding, so you can take advante of integer overflows in the OID BER encoding.
Well, that was all for today, I skipped some talks in the afternoon, but we had some fun in the RealWorld ;)