[dm-crypt] LUKS/dm-crypt vulnerable?

[dm-crypt] LUKS/dm-crypt vulnerable?

[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

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)?

Re: [dm-crypt] LUKS/dm-crypt vulnerable?

[Marc Ballarin]

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

Re: [dm-crypt] LUKS/dm-crypt vulnerable?

[Michael Gebetsroither]

* Marc Ballarin <Ballarin.Marc@gmx.de> wrote:

> 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
-- 
It's already too late!

Re: [dm-crypt] LUKS/dm-crypt vulnerable?

[Arno Wagner]

On Sat, Aug 08, 2009 at 03:26:14PM +0200, Heinz Diehl wrote:
> 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)?

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
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
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 

Re: [dm-crypt] LUKS/dm-crypt vulnerable?

[Heinz Diehl]

On 08.08.2009, Marc Ballarin wrote: 

> 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?

Re: [dm-crypt] LUKS/dm-crypt vulnerable?

[Heinz Diehl]

On 08.08.2009, Michael Gebetsroither wrote: 

> 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.

http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html

Re: [dm-crypt] LUKS/dm-crypt vulnerable?

[Michael Gebetsroither]

* Heinz Diehl <htd@fancy-poultry.org> wrote:
> On 08.08.2009, Michael Gebetsroither wrote: 

>> 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
-- 
It's already too late!

Re: [dm-crypt] LUKS/dm-crypt vulnerable?

[Heinz Diehl]

On 08.08.2009, Michael Gebetsroither wrote: 

> 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.

http://lkml.org/lkml/2009/5/15/170

Re: [dm-crypt] LUKS/dm-crypt vulnerable?

[Heinz Diehl]

On 08.08.2009, Arno Wagner wrote: 

> 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. 

Re: [dm-crypt] LUKS/dm-crypt vulnerable?

[markus reichelt]

[-- Attachment #1: Type: text/plain, Size: 1926 bytes --]

* Heinz Diehl <htd@fancy-poultry.org> wrote:

> 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.

Sure, just dismantle the hdd, install the rootkit, then put it back
into the target comp. 


> 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.


> 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, ...

> 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.

-- 
left blank, right bald

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [dm-crypt] LUKS/dm-crypt vulnerable?

[Luca Berra]

On Sat, Aug 08, 2009 at 05:36:35PM +0200, Heinz Diehl wrote:
>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.

-- 
Luca Berra -- bluca@comedia.it
         Communication Media & Services S.r.l.
  /"\
  \ /     ASCII RIBBON CAMPAIGN
   X        AGAINST HTML MAIL
  / \

Re: [dm-crypt] LUKS/dm-crypt vulnerable?

[Heinz Diehl]

On 10.08.2009, Luca Berra wrote: 

> 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...).

> 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.

Re: [dm-crypt] LUKS/dm-crypt vulnerable?

[Sven Eschenberg]

On Mon, August 10, 2009 09:10, Heinz Diehl wrote:
> On 10.08.2009, Luca Berra wrote:
>
>
>> 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.
>
>

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.

Re: [dm-crypt] LUKS/dm-crypt vulnerable?

[Marc Ballarin]

Heinz Diehl schrieb:

> ..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

Re: [dm-crypt] LUKS/dm-crypt vulnerable?

[Michael Gebetsroither]

* Marc Ballarin <Ballarin.Marc@gmx.de> wrote:

> 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
-- 
It's already too late!

Re: [dm-crypt] LUKS/dm-crypt vulnerable?

[Heinz Diehl]

On 10.08.2009, Marc Ballarin wrote: 

> 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.

Re: [dm-crypt] LUKS/dm-crypt vulnerable?

[Arno Wagner]

On Mon, Aug 10, 2009 at 12:34:37PM +0200, Michael Gebetsroither wrote:
> * Marc Ballarin <Ballarin.Marc@gmx.de> wrote:
> 
> > 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 

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
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