CCC 25C3

We have long considered mobile phone systems a fairly closed issue, but this may be changing. Dieter Spaar and Harald Welte demonstrated a GSM base station they had bought on eBay. The pair had been able to reverse engineer the base station well enough to run it as a mini-GSM network. During the talk (and the previous night) it popped up as ‘001 01’ network and the researchers were able to make voice and SMS connections. Reverse engineering the base station and creating a system for connecting to it was certainly a tidy piece of work, but it is not clear to me whether or how quickly this could evolve into the threat of rogue phone networks. Ordinarily, a GSM phone will not connect to an arbitrary network if its home network is available, but in the US network coverage is patchy. A coverage gap could be filled by a rogue network to execute a man-in-the-middle attack or just to collect IMSI and IMEI data.

This isn’t as far-fetched as it may seem – in the distant past receivers were used on analogue phone networks to sniff phone credentials. Until now, obtaining the required hardware and then understanding it well enough to be able to create a GSM network node has been a hurdle, but Spaar and Welte have now demonstrated that the hurdle can be cleared.

They also mentioned in passing a similar project that is attempting to implement GSM protocol on the GNU radio/USRP (Universal Software Radio Peripheral). If this succeeds, it will be much easier to obtain the necessary hardware, as a GNU radio (which is basically a radio receiver implemented heavily in software and capable of receiving all bands) is far more easily obtained than a GSM base station (although still costly at around EUR 1,000). The authors had bought the entire stock of base stations available on eBay at that time and were offering them at cost to interested parties. The GNU radio and base station projects should complement each other well as one deals with the physical layer while the other with the network link layer.

The authors’ base station did not support UMTS, so they have not yet done any work in that field. With the rise of smart phones, UMTS is the protocol that is the most interesting from the Internet security perspective. UMTS does support a much more sound encryption protocol than GSM, and the encryption goes to the telco rather than stopping at the base station, so it will be much harder to find useful hacks. However, as this proof of concept has shown, it is likely only to be a matter of time.

Collin Mulliner of the Fraunhofer-Gesellschaft Institute presented his findings on Symbian OS 9 security. He chose to focus on this version as previous versions of the OS didn’t have notable security mechanisms in place and the API had become more or less POSIX-compliant with this version. The Symbian OS runs on approximately 50% of the world’s smart phones as the PDA-side operating system. Mulliner was interested in the susceptibility of the OS and its applications to buffer overflow attacks and the usefulness of the capability-based security system.

The OS itself has no buffer overflow protection mechanisms in place, such as stack canaries, but will use the code execution protection mechanisms of the CPU if they exist. For that reason Mulliner found that CPUs with ARM architecture version 5 and below were vulnerable to attack, but version 6 and above were not. He intends to test other types of code injection attack against these newer architectures in the future. He showed the results of some of his experimentation with buffer overflows, such as making a call from shellcode and an IMEI reader. To make shellcode generation easier for this platform he created a shellcode encoder so as to avoid zero bytes and to avoid problems with the instruction cache. Finding exploitable code was done by attaching the (now free) remote debugger and fuzzing. An alternative he mentioned was using IDA Pro’s debugger for Symbian.

Mulliner also discovered what he believes is a weakness in the capabilities system of Symbian OS. By granting network access to virtually all applications, the shellcoder can use networking to take the available IMEI to the open code-signing site that Symbian provides for developers and have code signed specifically for that phone. The captcha system on that site is weak and can be broken by numerous anti-captcha services. Thus an attacker can target a mobile phone via a buffer overflow attack and then create malware for that phone and upload it. Since users are already preconditioned to press the ‘Yes’ button as many times as the phone asks them, he believes the success rate of such malware will be high.

This talk was basically a deconstruction of the iPhone’s hardware based on the work the authors did while jail-breaking it (removing the phone’s protection mechanisms). The phone is divided – like most, though not all, smart phones – into two halves: the phone and the PDA part.

The phone part deals only with making calls and transferring data over the GSM/UMTS network. It is based on the Nucleus OS and uses encryption extensively. It has a code trust chain that starts when the initial SIMloader is run, but the bootloader which comes next has exploitable bugs – which the authors found via hardware fuzzing and allowed them to break the trust chain. While no applications can be installed on the phone side of the iPhone, unlocking it is the only way to run the iPhone on networks other than the one for which it was configured.

The PDA part is based on Mac OS X with an XNU kernel. There is a nearly complete chain of code trust, with the bootloader being the exception, so this part is what needs to be broken. The phone is pretty well secured if it isn’t jail-broken, but inevitably someone will find a vulnerability and there is currently no official way of writing software for the kernel of the iPhone (or the phone part), so there is no way of easily protecting the phone with third-party software.

I was a bit disappointed that the authors didn’t go into more detail about the operating system. However, the fact that the OS is based very strongly on Mac OS X is probably enough to understand how it is built. (Later, I was told that the main differences from Mac OS X are in the GUI model, which is far cleaner and tailored to small devices.)

A group of researchers from Germany and Luxembourg presented their findings on DECT phones. Although used in very few wireless phones in the US, DECT is one of the most popular standards for wireless home phones and other short-range digital wireless devices in Europe and other parts of the world.

Communications are scrambled and presumably time-sliced in an unpredictable manner. Initially, the researchers planned to use a GNU radio/USRP to build a sniffer for DECT wireless traffic, but then stumbled upon a cheaper solution in the form of a PCMCIA card. After reverse engineering that card they were able to create a DECT sniffer for about EUR 23, which was also able to transmit (in contrast to the USRP solution where real-time transmission is hampered by the delay in processing the incoming signals).

Like GSM, the cipher used by DECT is kept secret, but security through obscurity will eventually fail unless the security is very sound. Some parts of the cipher are documented in a patent, but others are not because the encryption is implemented in a dedicated chip, and the authors had to resort to chip reverse engineering.

The end result is that with a fairly small investment in hardware, the researchers were able to eavesdrop on DECT calls, but also sniff traffic from other devices that use this system, such as electronic payment terminals and traffic lights. Eventually they will be able to associate with any given DECT network and place calls.

In July 2008, multiple vendors issued patches to their DNS servers and clients to fix a problem that had been discovered many years ago, but which was only recently recognized as severe. Like much of the Internet, DNS was designed with a threat model more focused on availability than security and is brilliant at distributing data in a federated manner. For that reason, we have come to rely on DNS to federate all sorts of data that probably shouldn’t have been entrusted to a relatively insecure protocol. The bug in question allowed a type of DNS cache poisoning due to the fact that the source ports of the DNS server were predictable.

Dan Kaminsky took us on a tour of all that he had been doing last year getting DNS patched in a coordinated way so that no vendors would prove to be in a liable position. The good news is that it is estimated that over 75% of the DNS servers were patched after one month, but there are still plenty that are not. Achieving this was no easy feat as it required the vendors to be persuaded of the severity of the problem and of the need to fix it pre-emptively. It was a good tale of setting aside egos for the greater good.

Kaminsky put forward a very strong case for getting DNSSEC into a usable state, as he grudgingly believes that it is the only way of making DNS trustworthy in the long run. Dan’s thesis is that authentication on the Internet is basically broken and fixing DNS would go a long way towards re-establishing trust. DNS itself may not, ultimately, be fixable so Dan believes that fixing and then deploying DNSSEC is the only way forward.

Luciano Bello and Maximiliano Bertacchini reported on a bug that was introduced into the Debian version of the random number generator (RNG) due to a complaint. Apparently, some of the code in the RNG was generating warnings and a user considered this enough of an annoyance to report it as a bug. The code in question read unallocated memory for seeding purposes, so the debugger reported it as an uninitiated variable. Unfortunately, it was not clear to the Debian package maintainers what that code was supposed to do, so they created a Debian-specific patch that removed the two lines in question. The result is that Debian Linux and all Debian-derived distributions had the bug for a while, meaning that a large number of systems are affected.

This affects many cryptographic protocols, in particular key generation and the Diffie-Hellmann key exchange protocol. The problem is that even though Debian has now been fixed and many systems have probably been updated, we may have to live with the bad keys for a long time. Luckily, users of Firefox are not susceptible (even if the web servers it connects to are) as it uses its own crypto library. This vulnerability also highlights how insecure code may be socially engineered into open or closed source software.

The most eagerly anticipated event of the conference was the demonstration of an attack against a Certificate Authority (CA). The organizers didn’t announce the title or content of this talk until a few hours before the event, for fear of a court injunction or similar action preventing it from going ahead.

We have known for many years now that the MD5 cryptographic hash function is broken and other hash functions are under attack (see VB, October 2004, p.13). There have been demonstrations of engineered MD5 hash collisions in the past. However, many people still continue to use MD5 in security applications – and, specifically, they are still being used in the generation of cryptographic certificates for websites and code.

Using the known prefix attack against MD5 and deriving the way that Equifax’s RapidSSL service generates website certs, the researchers were able to create an MD5 collision for a CA certificate using the site cert generated for them by RapidSSL. This was a clever piece of engineering as the first fields of a cert are generated by the CA, so they needed a way of predicting these, while the rest of the certificate was under their direct control. The prefix attack allowed them to create a CA cert document for which the signature of the real CA still held true.

With this rogue CA certificate, the researchers could create any sort of site or code certificate they wanted and it would look like the rogue certificate authority was certified by Equifax. They hobbled the generated CA cert by backdating its expiry date to 2004 (the year of the first publication of hash collisions) so that any certificates it generated would not be accepted in practice. While experimenting with this, they found that most browsers do not honour the certificate revocation system, the notable exception being IE in Windows Vista.

The attack is only possible because of the weakness of MD5, and the moral of the story is that we need to stop using MD5 in security applications as soon as possible. The researchers recommended SHA-1, although it too is beleaguered, and so it might be prudent to move beyond SHA-1 and implement a certificate management system.

We had a lively debate about the significance of this presentation. I think it is a significant proof of concept, and even though the researchers picked on RapidSSL, there is a good chance that someone will find a way to abuse a different CA as well. It is always important to have a proof of concept to kick people into action. However, we’ve known for some time that MD5 is broken. We also know that people don’t pay enough attention or don’t understand the certificate system when browsing. Given the DNS and RNG problems, authentication in the Internet is pretty broken at this point anyway. So, it may not make much of a difference. What worried me was that when I met the speakers briefly, my impression was that there is more in the pipeline – they did not reveal everything they knew. It will pay to be vigilant.

Felix Lindner (FX) talked about attacks against the Cisco IOS. Basically, if motivated enough, instead of concentrating on servers, an attacker can take control of the infrastructure instead. Since Cisco is, by a large margin, the market’s biggest supplier of networking equipment, it makes sense to concentrate on Cisco’s IOS operating system. Having said that, the attacker would need to be pretty motivated and it would have to be a part of a targeted attack. The IOS comes in many versions compiled in different ways by different engineers. In fact, OS diversity is probably Cisco’s best defence, as the OS itself is just as susceptible as any piece of software. It would also be a very effective attack and would give the attacker control over the infrastructure. To make matters worse, FX explained how difficult it is to perform post-mortem forensic analysis on IOS: if an error occurs, the equipment reboots itself, removing the evidence of the attack.

To counteract this, FX has been working on tools to log and diagnose the state of the IOS. He also suggests one simple solution: restrict connections to the infrastructure machines, as there is no reason why a user PC needs to access the router directly.

While the Storm worm seems to be subsiding a little, it is still a fascinating beast. There was a talk about how to take over parts of the Storm net. This relies heavily on understanding how Overnet works and how it uses hashes. Basically, a Storm bot uses the Overnet to locate the C&C and then communicates directly with it. It turns out that one can poison the hash system and point the bots to one’s own system. One needs to know how to pretend to be the C&C to do this, and the authors gathered their knowledge by reverse engineering the bots and looking at the traffic. They could have ‘cleaned’ all the bots in the network, but refrained from doing so. It probably would be illegal in most countries – and dangerous in any case.