LUKS/dm-crypt vulnerable?
Hi,
did just read this article on a vulnerability of the Windows programm "Truecrypt":
http://www.h-online.com/security/Bootkit-bypasses-hard-disk-encryption--/news/113884
It doesn't affect me, since I'm not using Windows at all, but would such also be possible on a LUKS/dmcrypt encrypted Linux machine? E.g. GRUB in the MBR, /boot unencrypted, the rest encrypted and decrypting via a specially crafted initrd which ask for the passphrase at bootup time?
Could also somebody steal my encrypted Laptop, install such a programm into the MBR, boot the machine and read my data (when the Laptop is not powered on)?
Hi,
of course, this also affects dm-crypt - or any other encryption scheme for that matter.
You need an unbroken chain of trust to achieve security. You must be able to trust your hardware/firmware, your BIOS, the code in your MBR, your boot loader, your kernel, your drivers, your system libraries, your shell, your cryptsetup executable and so on.
If an attacker manages to replace or manipulate at least one piece of that chain, he has broken your security.
Here is an example of a keylogger implemented in keyboard firmware: http://www.blackhat.com/presentations/bh-usa-09/CHEN/BHUSA09-Chen-RevAppleFirm-SLIDES.pdf (Yes, even keyboards might come with programmable flash nowadays ;-)
However, this is nothing new. If you assume that an attacker is determined and able to get physical access to your computer - especially without your knowledge - securing your system gets much, much harder.
In this case you need a method to verify the integrity of every compnent of your system. The best bet would probably be something like TPM. This should cover at least the BIOS and the rest of the software but manipulated firmware might still slip through.
Marc
Quoted 4 lines · Marc Ballarin
In this case you need a method to verify the integrity of every compnent of your system. The best bet would probably be something like TPM. This should cover at least the BIOS and the rest of the software but manipulated firmware might still slip through.
The real solution would be TXT from new intel chips.
This can provide runtime secure boot so the chain of trust is _really_ short.
In fact only the cpu, northbridge and the signed module provided by intel.
I've tested it with an intel executive DQ45 motherboard and a q9550 cpu. It works though requires a good deal of work (patching included).
http://sourceforge.net/projects/tboot/
michael
Signature · 1 line
It's already too late!
Quoted 1 line · Michael Gebetsroither
The real solution would be TXT from new intel chips.
I'm not going to buy such hardware ever. It could be misused to a bunch of "evil things", too, e.g. forcing the use of special software on me. There was a discussion on the topic at the lkml going on about 2 months ago.
Quoted 7 lines · Heinz Diehl
Quoted 1 line · Michael Gebetsroither
The real solution would be TXT from new intel chips.
I'm not going to buy such hardware ever. It could be misused to a bunch of "evil things", too, e.g. forcing the use of special software on me. There was a discussion on the topic at the lkml going on about 2 months ago.
No one can force you to use this software on _your_ hardware.
michael
Signature · 1 line
It's already too late!
Quoted 1 line · Michael Gebetsroither
No one can force you to use this software on _your_ hardware.
That's right, no one can force me to run TXT/LaGrande on my hardware. But it can be misused in the future to enforce all kind of restrictions on me. Sure, I don't have to activate TXT, but then I'm maybe no longer able to get access to my online bank account if I'm not running special software from the bank inside the TXT enabled environment. And not to forget DRM, TXT will be the perfect solution to enforce it on you.
To get TXT working it is both hard- and software which have to play together. Boykotting the hardware is one possible action against it.
Quoted 8 lines · Marc Ballarin
You need an unbroken chain of trust to achieve security. You must be able to trust your hardware/firmware, your BIOS, the code in your MBR, your boot loader, your kernel, your drivers, your system libraries, your shell, your cryptsetup executable and so on.
If an attacker manages to replace or manipulate at least one piece of that chain, he has broken your security.
Here is an example of a keylogger...
Yes, all that I'm totally aware of, but that was not what I meant (or I'm misunderstanding the whole):
The article on "stoned" is not detailed enough to explain if the system must be running to have it installed, or if it is also possible to break into a _powered off_ system by installing "stoned" (or whatever) in the MBR.
The scenario:
My Laptop, fully encrypted with LUKS/dmcrypt gets stolen while totally _powered off_. By "fully encrypted" I mean:
- GRUB in the MBR
- /boot unencrypted
- Rest encrypted
- Booting by providing the correct password, handled by a specially crafted initrd
Would it be possible to break into my data by installing "stoned for Linux" or whatever into my MBR?
I't quite clear to me that people who can get physical access to this Laptop (or whatever computer) can install a keylogger or manipulate it in a way that they can get hands on my passphrase or the key. They can do what they want to infect my machine with all kind of malware to spy on me.
But what happens when the machine is powered off and stolen? The thief wants to have my data. Can he/she use something like "stoned" to get into the system and decrypt the harddisk contents?
Quoted 7 lines · Heinz Diehl
Yes, all that I'm totally aware of, but that was not what I meant (or I'm misunderstanding the whole):
The article on "stoned" is not detailed enough to explain if the system must be running to have it installed, or if it is also possible to break into a
_poweredoff_system by installing "stoned" (or whatever) in the MBR.
Sure, just dismantle the hdd, install the rootkit, then put it back into the target comp.
Quoted 2 lines
Would it be possible to break into my data by installing "stoned for Linux" or whatever into my MBR?
Yes, theoretically. Direct physical access is always the key. You could (and should) check integrity of the boot chain to detect such tampering. That is not always possible, and depends largely on the setup in use.
Quoted 5 lines
I't quite clear to me that people who can get physical access to this Laptop (or whatever computer) can install a keylogger or manipulate it in a way that they can get hands on my passphrase or the key. They can do what they want to infect my machine with all kind of malware to spy on me.
Ah, ...
Quoted 3 lines
But what happens when the machine is powered off and stolen? The thief wants to have my data. Can he/she use something like "stoned" to get into the system and decrypt the harddisk contents?
... now I think I understand the Q.
Something like an install of "stoned" does not yield any access to your data in the case you describe. All that "stoned" manages is to lay out a trap. If your system gets stolen while being fully encrypted the attacker gains nothing via "stoned" at all.
It would be different if the attacker modified things you dont know about, and you continue to normally use your machine. Hence the importance of denying direct physical access to your machine, and/or take precautions to detect such tampering.
Signature · 1 line
left blank, right bald
Quoted 3 lines · Heinz Diehl
But what happens when the machine is powered off and stolen? The thief wants to have my data. Can he/she use something like "stoned" to get into the system and decrypt the harddisk contents?
To achieve this, they will have to hand it back, wait for you to type your password to boot, then steal it again :P
Stoned is just a trojan that installs into the boot sector, a very well done trojan, but that is.
The whole argument about stoned and truecrypt is that stoned developer insisted truecrypt was not secure, because it did not enforce checking of boot sector integrity.
Truecrypt developers said that was a moot point, because, if someone is able to replace the boot sector it could well replace the code that checks its integrity.
add a bit of hype, mix .....
L.
Signature · 6 lines
Luca Berra -- [email protected] Communication Media & Services S.r.l. /"\ \ / ASCII RIBBON CAMPAIGN X AGAINST HTML MAIL / \
Quoted 2 lines · Luca Berra
To achieve this, they will have to hand it back, wait for you to type your password to boot, then steal it again :P
I was nearly clear over that, but had to ask anyway, because it was so many disinformation. I did read that "stoned" could hook into the BIOS and capture some traffic from there which should be enough to get access to the key. I just couldn't believe that this is possible when the machine is powered off.
Besides, I'm not using Truecrypt at all (since I do not use Windows), but my thoughts went almost immediately to LUKS/dmcrypt. I always power my Laptop completely down when no longer in use, after my former one got stolen I'm somewhat sensible now. (There's my online bank account, a lot of business email, letters, documents and so on...).
Quoted 3 lines
Truecrypt developers said that was a moot point, because, if someone is able to replace the boot sector it could well replace the code that checks its integrity.
..which is not true, of course. I can e.g. have a copy of the boot sector/MBR on a memory stick, together with a checksum file of /boot. Copying the first 512 bytes and checking it against the checksum of the known good bootsector on the memory stick will detect any manipulation immediately. A simple "dd if=mbr_copy of=/dev/sda bs=512 count=1" will cure the problem.
Quoted 7 lines · Heinz Diehl
Quoted 3 lines · Luca Berra
Truecrypt developers said that was a moot point, because, if someone is able to replace the boot sector it could well replace the code that checks its integrity.
Quoted 9 lines
..which is not true, of course. I can e.g. have a copy of the boot sector/MBR on a memory stick, together with a checksum file of /boot. Copying the first 512 bytes and checking it against the checksum of the known good bootsector on the memory stick will detect any manipulation immediately.
A simple "dd if=mbr_copy of=/dev/sda bs=512 count=1" will cure the problem.
Yes and no. This will only work, if you ensure you are booting from that usb device alltogether. Still though, the boot firmware could be manipulated, which means it does not matter, that you have a backup of the 'correct' mbr somewhre. And I am not even talking about HW manipulation and HW Keyloggers, which are often more easily to install and get back at any particular time later you want.
Quoted 5 lines · Heinz Diehl
..which is not true, of course. I can e.g. have a copy of the boot sector/MBR on a memory stick, together with a checksum file of /boot. Copying the first 512 bytes and checking it against the checksum of the known good bootsector on the memory stick will detect any manipulation immediately. A simple "dd if=mbr_copy of=/dev/sda bs=512 count=1" will cure the problem.
If the integrity of the system is compromised this won't help.
What if the trojan itself did "an dd if=/dev/sda of=hidden_mbr_copy..." and redirected all future read-access to the original MBR to this backup file?
The same would be true for manipulated kernels. They could keep the original kernel image in a hidden file and redirect all system calls aimed on the manipulated image to this good image. Alternatively they could simply manipulate md5sum, sh1sum or whatever and add logic like:
if filename==name of corrupted kernel
print md5 of good kernel
else
print true md5
Only booting from a trustworthy medium would help and the same is true in the case of truecrypt.
Marc
Quoted 2 lines · Marc Ballarin
Only booting from a trustworthy medium would help and the same is true in the case of truecrypt.
No, even this does not help.
As it's too easy to get code persistent in some location on the computer which is run on every boot.
michael
Signature · 1 line
It's already too late!
Quoted 8 lines · Michael Gebetsroither
Quoted 2 lines · Marc Ballarin
Only booting from a trustworthy medium would help and the same is true in the case of truecrypt.
No, even this does not help.
As it's too easy to get code persistent in some location on the computer which is run on every boot.
Well, it is not absolute, but it can help driving the attacker effort way up. There is limited capacity to have malcode hiding in the BIOS FLASH (for example), and it cannot easily be made to work with every OS. The trusted system will still have to work and the malcode will somehow have to extract keys and/or passphrase. With a Linux system, this basically requires virtualization. If the trusted medium uses alternate password entry methods, simple sniffing of keystrokes will not be enough and the effort to still get the password may be prohibitively high.
From my observations the really good potential attackers work for government agencies or in research and will not attack low value targets, such as hosts storing personal data of individuals and booting from a trusted medium should usually be pretty safe for individuals.
Arno
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier
Quoted 1 line · Marc Ballarin
If the integrity of the system is compromised this won't help.
[...]
That's quite clear that in this case you'll have to boot from CD/DVD to check the systems /boot and MBR against the known good versions on your memory stick. Of course, if the system is compromised otherwise, e.g. by a keylogger or some BIOS manipulation or whatsoever, this won't help.
In my case, all should be ok. It's only a Laptop which isn't used by someone else but me, and if I'm going to loose it ever, it's powered off and no one will get the opportunity to get access to my money
through my private bank account via the credentials which are stored on this machine.
I have now a copy of the boot secor/MBR and /boot on a memory stick, which is signed with my gpg key in addition, and I'll check up from time to time.
Quoted 7 lines · Heinz Diehl
Hi,
did just read this article on a vulnerability of the Windows programm "Truecrypt":
http://www.h-online.com/security/Bootkit-bypasses-hard-disk-encryption--/news/113884
Quoted 7 lines
It doesn't affect me, since I'm not using Windows at all, but would such also be possible on a LUKS/dmcrypt encrypted Linux machine? E.g. GRUB in the MBR, /boot unencrypted, the rest encrypted and decrypting via a specially crafted initrd which ask for the passphrase at bootup time?
Could also somebody steal my encrypted Laptop, install such a programm into the MBR, boot the machine and read my data (when the Laptop is not powered on)?
No, and they cannot do that on windows either. What they do is to install this and then have you open the crypto container. Then they can read. It is more sophisticated than a keyboard sniffer reading your password, but not that different. But on windows, it hides well.
On Linux, the attack would possibly involve changing the kernel. You would still have to open the crypto-container once after the modification.
Arno
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier
Quoted 3 lines · Arno Wagner
No, and they cannot do that on windows either. What they do is to install this and then have you open the crypto container. Then they can read.
Thank you, that was what I wanted to know.