Last Updated: 2008-02-29 21:48:56 UTC
by Jim Clausing (Version: 2)
Just a quick note to alert our readers that an new version of the popular network protocol analyzer/sniffer Wireshark (v0.99.8) has been released. This release includes some security fixes in the SCTP, SNMP, and TFTP dissectors. Malformed packets can crash the application. We'll update the story with CVE entries when they become available.
Last Updated: 2008-02-29 20:50:47 UTC
by Swa Frantzen (Version: 1)
When I started a few days ago with the follow-up diary entry on the original coldboot entry, I was hoping to provide an overview that e.g. security officers could use to make sure their users knew how to use the encryption products installed on their machines in order to ensure that the intended protection is actually achieved. But we're faced with a situation where we need to rely on contradictory claims we have no way to validate. Hence, to avoid spreading false information, I'm pulling the overview in the guidance diary, and will change it into a list of vendor reactions.
Only a deep technical audit (reverse engineering or source code) of all these products could be able to provide the needed answers, but we just don't have the resources to do that now.
Instead I've decided to pass on the hard to answer questions for your vendors, if I cant pressure them, collectively we still might cast our vote for honesty and openness.
For the typical pre-boot whole disk encryption, without added hardware:
- How is/are the key(s) protected in a machine that's fully off ?
Know that the key is a cryptographic key (e.g. an AES key), it's a sequence of bits, not a password you type. It needs to be stored somewhere, somehow. Know how it is protected. I strongly dislike any answer including words like "proprietary", "confidential", "obfuscated" etc.
- How is/are the key(s) protected in a machine that's running and actively used ?
Once the machine cleared the pre-boot, typically "the key is in the lock", or the cryptographic key is stored in RAM, for use by the drivers. At this point, we expect the coldboot attack can be performed. Any vendor claiming not being vulnerable at this stage should explain how they never have a key in RAM that they use to encrypt and decrypt disk blocks.
GUIDANCE: machines where control is lost in this state, are most probably vulnerable.
- How is/are the key(s) protected in a machine that has its screen locked ?
Once a user leaves his machine for a bit of time a screen saver might kick in and lock the machine. By default this does not always mean the keys are removed from RAM (mostly they will not be). It is not trivial to remove the cryptographic keys at this point as they need to be retrieved and e.g. programs can continue to run (which might require access to the disk ...)
GUIDANCE: machines with a locked screen are typically not protected by the disk encryption due to the coldboot attack, unless your vendor specifies exactly how they remove the key(s) while allowing the processes to continue to run.
- How is/are the key(s) protected in a machine that's asleep ?
Once a user closes his laptop one of the actions possible is to sleep the machine. Basically the contents of the RAM is kept in place. Since this is a mode users would typically use to transport machines, attention needs to be given to this mode. While the processes are not running anymore, there might be some way to remove the keys from RAM before sleeping the machine, and upon waking the machine first prompting the user and restoring the keys from their protected storage.
GUIDANCE: for most products of the pre-boot type, the guidance you need to give your users is not to use sleep mode at all (if you can block it, or replace it with hibernation, that might be a good option to consider).
- How is/are the key(s) protected in a machine that's hibernating (RAM+hibernate file)?
This might seem easier: the machine first writes its status (including a memory image) to disk and then powers off. The encryption software might erase the keys from RAM before powering off, making the machine more safe in the first minutes. If it doesn't erase the keys from RAM, they will eventually fade anyway, allowing for a short window of vulnerability to the coldboot attack (up to a dozen minutes or so).
An interesting part is how the memory image is managed: it potentially contains the key from RAM too! Similarly swap files (or partitions) can contain keys just as well.
GUIDANCE: much depends on the answers you get from your vendor, there seems more difference between products in this respect, so do ask them how their product works. Determine trust and risks afterwards.
For solutions that add hardware (e.g. TPM, USB tokens, dedicated hardware, ...) details are needed and the questions need to be adapted to those details.
For solutions that only encrypt a directory or a file, the issues are slightly different , still focusing on the different states and knowing how the key(s) are protected, how the processes using the data continue to run etc. is the answer you seek in order to build the guidance for your users.
All other products that you use that handle cryptographic keys could/should be examined in the same fashion, it's not just disk encryption that's at stake!
Contacts at vendors claiming full invulnerability or extremely unlikely scenarios are not good sources of information to gather data from to use in evaluation your risks, seek more technical answers before you believe their evaluation blindly.
Finally, with frustration, I need to express my sincere regrets to the people of those vendors who were cooperative in providing information to questions such as those above; to the readers contributing information and to all those hoping we could get the overview stable and correct.
Swa Frantzen -- Gorilla Security
Last Updated: 2008-02-28 18:36:17 UTC
by Bojan Zdrnja (Version: 2)
Yesterday I received samples of an IRC bot. This in itself would be nothing interesting except the fact that the archive contained binaries for FreeBSD and Mac (Darwin, ppc).
After initial analysis I found out that it's nothing special – just a port of a well known IRC bot called EnergyMech. The most interesting thing was that the attacker compiled it for FreeBSD and Mac. This probably didn't require any extra effort though since it compiles out of the box on FreeBSD and Linux anyway.
The bot did all the standard stuff: had couple of "owners" defined; comments in Portuguese and connected to Undernet, the IRC network that a lot of attackers like.
I decided, for the fun of it, to run the sample through VirusTotal, just to see what results AV programs will have. It was .. erm.. interesting, as you will see below.
There were in total 3 files:
$ md5sum linux freebsd darwin
The FreeBSD version of the bot was detected by 23 out of 32 AV programs (decent) and the Linux one by 24 out of 32 AV programs (even better). This was clearly signature detection since almost all AV programs detected the FreeBSD version as something for Linux (Linux/RST.B) – my guess is that they trigger on some text in the binary.
Finally, the Darwin version was a bit of a shock – 0 detections in total (!). Since it was a Mach-O executable for PPC, my guess is that AV programs didn't know how to parse the file format and just thought of it as data.
Just couple of things we received from our readers. The EnergyMech package is not malicious - it's just an IRC bot, similar to eggdrop so the fact that the bad guys use it doesn't make the package itself malicious.
Regarding the AV detection, it appears that those binaries could be infected with the RST virus (that would explain all detection and why the darwin file was clean since the RST virus infects only ELF files). I briefly analyzed the Linux version and it didn't appear to be infected (at least didn't show any infection activities). It's indeed possible and it wouldn't be the first time when attacker's own machine was actually infected (oh the irony).
Last Updated: 2008-02-28 00:21:54 UTC
by Bojan Zdrnja (Version: 1)
As a frequent reader of ISC, I have no doubt that you are aware of malware that was distributed on digital frames and other devices (if you haven't read those diaries, see http://isc.sans.org/diary.html?storyid=3817).
After we received some samples from our readers (thank you!) I decided to analyze one of them just for fun. According to VirusTotal, all AV programs (except for one) detected this sample, so at least all users running an up to date AV program are safe.
Most of the activities by the trojan were more or less standard until I saw that it creates a high number of new registry keys. I dig a bit further and found that it uses one relatively old technique that I haven't seen abused for quite some time: the trojan used the Image File Execution Options section of the registry.
Disassembly of the trojan showed that it cycles through a loop and creates a Debugger value for a lot of keys:
The question now was: what is this doing? I had to dig through MSDN to find what exactly this section of the registry does (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options). Basically, the Debugger value allows a programmer to specify a debugger for any executable on the system. This will make Windows start that program (the debugger) instead of the executable you wanted to start in order to allow you to debug that program (it actually makes it pretty difficult to start the real executable and not the specified debugger).
One really cool usage for this feature is to replace the default Task Manager with Sysinternal's Process Explorer – one has to create this key for the taskmgr.exe application and point to Process Explorer and voila, it'll get started instead of Task Manager.
The trojan abused this feature – it had a list of almost dozens of well know anti-virus and other security tools executables. Then it created these registry keys for every single application so the trojan would get executed instead – pretty sneaky. You can see part of the registry of an infected machine below:
You can see the trojan trying to disable the NOD32 AV program on the screenshot above. Since Windows don't really check if it's a real debugger that is being started, I hope that all AV vendors are aware of this (old) technique and that they check for their own entries in this section of the registry. By the way, this feature can be used for some nasty pranks so don't abuse it please.