0zapftis revisited – 0ktoberfest for Security Researchers

René Pfeiffer/ October 11, 2011/ High Entropy, Odd

The CCC analysis of the malicious software bought and used by the German government has put our blog schedule and RSS reading habits out of balance. Frankly our necks hurts because we constantly shake our heads since the PDF of the analysis was published. We have talked to journalists who showed interested in the design of the malware. It’s very hard not to go into rant or BOFH mode when talking about the design and the use of the trojan horse. You have to use quite some Zen skills to stay focused and to see what we have here. In fact the whole discovery and the avalanche of questions raining down on German officials marks a turning point for the significance of computer security. Furthermore it is a perfect example of all the problems security researchers have been preaching about in the past years, maybe even over the past decade. For the legal implications of the code we recommend the German Law Blog and Internet Law (we found no articles covering the legal situation in English yet).

Let’s start with the design and put it into perspective. Read the study from the CCC about the code. Then read the chapters „The Context of Cryptography“, „Block Cipher Modes“, „The Secure Channel“ and „Implementation Issues“ of Cryptography Engineering. Reading the chapter summaries will do nicely. Make sure you understand the statements „cryptography is not the solution“, „cryptography is very difficult“ and „cryptography is the easy part“. If you feel like putting everything into historical context you should read Simon Singh’s The Code Book, too. After that realise that the German Enigma encrypted communication had sessions keys while the developers of Troj/BckR2D2-A have not. Someone must have been in deep sleep for over 70 years. Avoiding any further rants, what does this and the string of other design deficiencies tell you? This is a sign that the code may consist of different parts that have been combined and that there are poor development processes at work. Security aspects were apparently not part of the development cycle. Furthermore the team who built the malware was not experienced with secure programming. Go to any hacker event, go to any security conference; if you were a developer of the Troj/BckR2D2-A team, then you would get a metric ton of useful input within minutes of talking (and listening, of course). Looking at the malware itself completes the impression that the developer of the code completely lack „security culture“.

Given the state of the code there has definitely never been a threat model design phase. If you intend to deploy malicious software for spying purposes, then you have to reflect on how not to arouse suspicion, how to stay hidden and how to covertly and safely transmit data or receive commands.

What else is there? The CCC only has the DLL and the kernel driver. There is no installer, which is a key part of the deployment. Wait before assuming that the installer is highly guarded, because it is a key component. It is not. Today F-Secure wrote in their blog that they have the installer. Why? Because someone submitted the installer with its real name scuinst.exe (Skype Capture Unit Installer) to Virustotal.com! Multiple times! What does this tell you? It tells us that we have left the detachment of the developer’s/operator’s technical mindset and see a mental detachment in terms of professional paranoia which leads to leaks such as F-Secure has described. To paraphrase: One does not simply upload the secret weapon to third-party web sites (no offence to Virustotal which is a great service). If you have at least a minimal essence of security awareness somewhere in your mind, then you do not scatter the code (or parts) of your secret „über-cyber-weapon“ over web sites out of your control (and we’re not even speaking about honey pots).

So where is the 0ktoberfest? Is there some beer? Yes, there is, at DeepSec 2011’s Speaker’s Dinner. Seriously, if you take a look at the code, how it was developed, how it was deployed and how its capabilities were advertised you have a perfect example why modern security problems can’t be solved without getting in touch with various (=more than a single person) experts, not only security experts. Businesses, individuals, government agencies, hackers and academics need to talk. You have to cultivate your professional paranoia, and you have to keep an open mind. Doing both is difficult, so don’t do it without help. You can always serve as a bad example later.

Update: Digitask has claimed that the CCC analysed an old version of its trojan from 2008. Digitask’s lawyer Winfried Seibert told journalists: „Berücksichtigt werden muss, dass die Software im September 2008 geliefert wurde. Es ist ausgesprochen unrealistisch, sie an den Maßstäben des Jahres 2011 zu messen“. This translates to: „It must be considered that the software was delivered in September 2008. It is downright unrealistic to measure it with the standards of 2011.“ Furthermore he claims that Digitask delivered a product that conformed to the state-of-the-art technology in 2008. If this was true, then using no authentication and no access control, omitting encryption from the command channel, using a single hard-coded symmetric encryption key and using Electronic Code Book encryption (for which attacks have been know in 2007 and before) would have been state-of-the-art technology in 2008. This is plain wrong. There is ample supply of literature and lectures on secure coding that was published prior to 2008.

Another of Mr Seibert’s statements illustrate the lack of „security culture“. He said: „Technische Details erörtern wir mit den Kunden, und sonst mit niemandem.“ This translates to: „We only discuss technical details with the customer and no one else.“ There’s nothing wrong with keeping trade secrets, but key designs should have the chance of being evaluated by peers. This is especially true if you foolishly try to use „homebrew cryptography“, among other dangerous technology. In turn customers should be very wary of any „state-of-the-art black-box technology“. If the security of the product in question crumbles by the simple use of packet sniffers, then there is no „state-of-the-art“ any more.