expertenaustausch > linux.debian.user.german

Christian Knoke (15.11.2016, 13:10)
Moin,

aus persönlichem Interesse, und weils Debian im besonderen betrifft, eine Bugtraq
Meldung über cryptsetup:



-->-->--
If you use Debian or Ubuntu/ (probably many derived distributions are also
vulnerable, but we have not tested), and you have encrypted the system
partition, then your systems is vulnerable.
--<--<--

Ich hatte mich schon früher an den cryptsetup Scripten geärgert, weil die
nicht so funktionieren wie sie sollen. Die Scripte sind Debian-spezifisch,
nehme ich an.

Unten noch der Beginn der Originalmeldung.

Gruß
Christian

-->-->--

Authors: Hector Marco & Ismael Ripoll -- Cybersecurity Group
CVE: CVE-2016-4484
Comment: CWE-636: Not failing securely.
Dates: November 11th, 2016 - Disclosed at DeepSec 2016, Viena.
November 14th, 2016 - Published in the web.

Description

A vulnerability in Cryptsetup, concretely in the scripts that unlock the
system partition when the partition is ciphered using LUKS (Linux Unified
Key Setup). The disclosure of this vulnerability was presented as part of
our talk "Abusing LUKS to Hack the System" in the DeepSec 2016 security
conference, Vienna.

This vulnerability allows to obtain a root initramfs shell on affected
systems. The vulnerability is very reliable because it doesn't depend on
specific systems or configurations. Attackers can copy, modify or destroy
the hard disc as well as set up the network to exflitrate data. This
vulnerability is specially serious in environments like libraries, ATMs,
airport machines, labs, etc, where the whole boot process is protect
(password in BIOS and GRUB) and we only have a keyboard or/and a mouse.

Note that in cloud environments it is also possible to remotely exploit this
vulnerability without having "physical access."

Am I vulnerable ?

If you use Debian or Ubuntu/ (probably many derived distributions are also
vulnerable, but we have not tested), and you have encrypted the system
partition, then your systems is vulnerable.

[...]
Adrian Bunk (15.11.2016, 20:30)
On Tue, Nov 15, 2016 at 12:08:58PM +0100, Christian Knoke wrote:
> Moin,
> aus persönlichem Interesse, und weils Debian im besonderen betrifft, eine Bugtraq
> Meldung über cryptsetup:
>
> -->-->--
> If you use Debian or Ubuntu/ (probably many derived distributions are also
> vulnerable, but we have not tested), and you have encrypted the system
> partition, then your systems is vulnerable.
> --<--<--
>...





"What you gain is a root access to the initramfs, which you usually can
access in other ways if you already have physical access to enter a
passphrase to unlock the encrypted partition."

> Gruß
> Christian


cu
Adrian
Christian Knoke (15.11.2016, 22:20)
Adrian schrieb am 15. Nov um 20:21 Uhr:


>
>
> "What you gain is a root access to the initramfs, which you usually can
> access in other ways if you already have physical access to enter a
> passphrase to unlock the encrypted partition."


Es ist ein Angriffsvektor. Wenn du ein sicheres BIOS/UEFI hast, und wenn
grub passwortgeschützt ist, dann ist der Rootzugriff in der initrd eine
Sicherheitslücke. Das System wird modifiziert, beim nächsten boot die
Passphrase abgegriffen, ét voilà, luks_open().

Gruß
Christian
Peter Funk (16.11.2016, 13:10)
Hallo Christian,

Christian Knoke schrieb am Dienstag, den 15.11.2016 um 21:16:
> Adrian schrieb am 15. Nov um 20:21 Uhr:
> Es ist ein Angriffsvektor. Wenn du ein sicheres BIOS/UEFI hast, und wenn
> grub passwortgeschützt ist, dann ist der Rootzugriff in der initrd eine
> Sicherheitslücke. Das System wird modifiziert, beim nächsten boot die
> Passphrase abgegriffen, ét voilà, luks_open().


Das ist im Prinzip richtig: Aber die meisten Leser hier
werden LUKS wohl so wie ich hier auf ihrem Laptop einsetzen.
Wenn ein Laptop physisch irgendwie aus der Hand gegeben
wird, dann können Leute, die in der Lage wären, die oben
genannte Sicherheitslücke auszunutzen, auch noch ganz andere
Angriffsvektoren nutzen:

Das Problem sind dabei die vielen Flash-Speicherchips,
die sich heute in einem modernen Notebook-PC befinden.
Solange es Sachen wie z.B. die Intel-Management-Engine
gibt, sind BIOS-Passwort, UEFI usw. meiner Meinung nach nur
genauso ein Sicherheits-Theater, wie die Klarsicht-Beutel für
Flüssigkeiten im Handgepäck am Flughafen.

Diese Meinung habe ich, seitdem ich auf Youtube eine
Präsentation von Joanna Rutkowska auf einem der CCC Kongresse
gesehen habe.

Wer also nicht gerade politischer Aktivist oder
Enthüllungsjournalist ist oder meint, aus irgendeinem anderen
Grund von besonderem Interesse für einen der Geheimdienste zu
sein, sollte sich wegen CVE-2016-4484 nicht noch mehr Sorgen
machen, als wir uns sowieso schon alle machen! ?

Viele Grüße, Peter Funk
Christian Knoke (16.11.2016, 14:10)
Peter Funk schrieb am 16. Nov um 11:30 Uhr:
> Christian Knoke schrieb am Dienstag, den 15.11.2016 um 21:16:
> Das ist im Prinzip richtig: Aber die meisten Leser hier
> werden LUKS wohl so wie ich hier auf ihrem Laptop einsetzen.


zu Hause wird nicht verschlüsselt?

> Wenn ein Laptop physisch irgendwie aus der Hand gegeben
> wird, dann können Leute, die in der Lage wären, die oben
> genannte Sicherheitslücke auszunutzen, auch noch ganz andere
> Angriffsvektoren nutzen:


Klar.

Nur hier reicht es, ein paar Tasten zu drücken und evtl. kurz einen
USB-Stick anzuschließen. Unverschlüsselte Daten können direkt abgesaugt
werden. Die LUKS-Partitionen kann man kopieren und später mit der Passphrase
entschlüsseln. Dazu muss man den Laptop nicht in die Hand nehmen.

Weitere Möglichkeiten gibt es, wenn der user dropbear installiert hat.

> Wer also nicht gerade politischer Aktivist oder
> Enthüllungsjournalist ist oder meint, aus irgendeinem anderen
> Grund von besonderem Interesse für einen der Geheimdienste zu
> sein, sollte sich wegen CVE-2016-4484 nicht noch mehr Sorgen
> machen, als wir uns sowieso schon alle machen! ?


Ein verbreiteter (?) Irrtum. Alle diese Angriffe können auch von Kriminellen
ausgeführt werden.

Gruß
Christian
Sascha Reißner (17.11.2016, 15:20)
Am Dienstag, den 15.11.2016, 12:08 +0100 schrieb Christian Knoke:
> Moin,
> aus persönlichem Interesse, und weils Debian im besonderen betrifft,eine Bugtraq
> Meldung über cryptsetup:
>
> -->-->--
> If you use Debian or Ubuntu/ (probably many derived distributions are also
> vulnerable, but we have not tested), and you have encrypted the system
> partition, then your systems is vulnerable.
> --<--<--


Das wusste ich schon vor einem Jahr als ich meinen Computer
verschlüsselt habe und mir über Angriffsvektoren Gedanken machte.
Wenn man einzelne Patitionen verschlüsselt kann ein Angreifer die
Patitionstabelle lesen und erhält so Hinweise (Größe, Lage ,Format)
über die Aufteilung. Er kann sich dann auf den Teil konzentrieren der
Ihm interessiert.

Deshalb ist bei mir nicht die root-Partition, sondern die ganze
Festplatte verschlüsselt. Auf der Platte gibt es keinen MBR, keine
EFI-Partition und keine Partitionstabelle die jemand lesen könnte.
Zum Boot benötigt man einen USB-Stick auf dem eine Kopie der
boot-Partition und das Key-File für den LUKS-Container liegt.
Nach dem aufsperren des LUKS-Container wird ein PV (LVM) sichtbar indem
die LV's liegen (die normalerweise als Partitionen im MBR stehen).
Sobald der LUKS-Container aufgesperrt ist, kann man den Stick bereits
abziehen, da alle nötigen Sachen in der initramfs liegen die ja schon im
RAM ist.
Da ein LUKS-Container einen Header hat, ist dies die einzige Information
die ein Angreifer bekommt und wieviele aktive Key-Slots vorhanden sind.

Ohne dem USB-Stick meldet der Rechner 'no operating system found'.
Christian Knoke (17.11.2016, 22:00)
Sascha Reißner schrieb am 17. Nov um 14:14 Uhr:
[..]
> boot-Partition und das Key-File für den LUKS-Container liegt.
> Nach dem aufsperren des LUKS-Container wird ein PV (LVM) sichtbar indem
> die LV's liegen (die normalerweise als Partitionen im MBR stehen).


Das ist sehr interessant. So (so ähnlich) wollte ich dass auch einrichten,
habe es aber nicht hinbekommen.

Ich nehme an, das key file auf dem usb Stick ersetzt bei dir die passphrase?

> Sobald der LUKS-Container aufgesperrt ist, kann man den Stick bereits
> abziehen, da alle nötigen Sachen in der initramfs liegen die ja schon im
> RAM ist.
> Da ein LUKS-Container einen Header hat, ist dies die einzige Information
> die ein Angreifer bekommt und wieviele aktive Key-Slots vorhanden sind.


Dieser Header ist auch ein Schwachpunkt, weil man allein auf den header,
ohne den Rest der Platte, einen brut force angriff machen kann.

Der angreifer klaut erst den header, und bei seinem zweiten Besuch kann er
das System modifizieren. Er muss nicht mehr die ganze Platte kopieren,
sondern kann gezielt nach Informationen suchen.

Gruß
Christian
Sascha Reißner (18.11.2016, 06:10)
Am Donnerstag, den 17.11.2016, 20:56 +0100 schrieb Christian Knoke:
> Sascha Reißner schrieb am 17. Nov um 14:14 Uhr:
> Dieser Header ist auch ein Schwachpunkt, weil man allein auf den header,
> ohne den Rest der Platte, einen brut force angriff machen kann.
> Der angreifer klaut erst den header, und bei seinem zweiten Besuch kann er
> das System modifizieren. Er muss nicht mehr die ganze Platte kopieren,
> sondern kann gezielt nach Informationen suchen.


Das ist mir klar. Ich spielte auch mit dem Gedanken die Platte mit
crypt-setup ohne LUKS zu verschlüsseln. Dadurch gibt es garkeinen Header
und die Platte ist auch voll verschlüsselt. Nachteil ist aber, daß man
das Key-File später nicht tauschen kann (außer man macht ein volles
Backup der Daten und formatiert die Platte komplett neu).

Mit LUKS hab ich die Möglichkeit später das Key-File zu tauschen.
Zusätzlich habe ich 8 Key-Slots. Ein Slot enthält eine Passphrasevom
einrichten. Diese habe ich belassen für den Fall, daß der Stick mal
kaputt oder verloren geht. Dann boote ich mit einer GRML, schließe LUKS
mit der Passphrase auf, erstelle ein neues Key-File, lösche das alte
Key-File aus dem Key-Slot, füge das neue hinzu und erstelle mir einen
neuen Stick.

Ohne LUKS müsste ich das Key-File irgendwo ganz sicher aufbewahren,
damit ich im Falle eines kaputten oder verloren gegangenen Sticks an
meine Daten komme. Im Falle eines Diebstahls müsste ich die Platte mit
dem gesicherten Key-File aufsperren, ein volles Backup ziehen und die
Platte mit einem neuen Key-File wieder verschlüsseln. Erheblicher
Aufwand wenn man bedenkt, daß ich hier jetzt immer nur von der Platte
geschrieben habe. In dem Container muß man ja auch die LV's mit den
Filesystemen wieder erstellen und die fstab mit den neuen UUID's
anpassen.

Ein dritter Gedanke kommt mir da:
Man kann ein Backup vom LUKS-Header ziehen.
Ob LUKS den Header direkt vor dem Container braucht, hab ich noch nicht
geprüft. Wenn das nicht erforderlich ist könnte man den Header ebenfalls
auf den Stick schreiben und den auf der Platte löschen.
Dazu muß man aber die Start-Scripte, die den LUKS-Container öffnen,
anpassen, damit diese den LUKS-Header in der Datei auf dem Stick
verwenden um den Container auf der Platte zu öffnen.
Oder man fügt 2 Scripte hinzu. Das erste schreibt beim Start des
Rechners das Backup wieder am Anfang der Platte. Das andere läuft als
letztes beim Shutdown und überschreibt den Header auf der Platte wieder
mit Datenmüll.
Bei beiden Varianten wird das Header-Backup-File zur wichtigsten Datei
die man irgendwo absolut sicher verwahren muß für den Fall eines
kaputten Sticks.

So, das ist mal wieder genug Gedankenspielerei.
Vielleicht ist jetzt dem Einen oder Anderen von Euch noch etwas
eingefallen.
Christian Knoke (18.11.2016, 11:00)
Sascha Reißner schrieb am 18. Nov um 05:00 Uhr:
> Am Donnerstag, den 17.11.2016, 20:56 +0100 schrieb Christian Knoke:
> Das ist mir klar. Ich spielte auch mit dem Gedanken die Platte mit
> crypt-setup ohne LUKS zu verschlüsseln.


das hatte ich versucht, aber die Scripte wollten kein key file vom Stick
einlesen.

> Dadurch gibt es garkeinen Header
> und die Platte ist auch voll verschlüsselt. Nachteil ist aber, daß man
> das Key-File später nicht tauschen kann (außer man macht ein volles
> Backup der Daten und formatiert die Platte komplett neu).


grundsätzlich sollte es möglich sein, nach backup und umount das blockdevice
umzuschlüsseln. In einem Prozess lesen (ein wenig 500 mb voraus) und im
anderen schreiben.

> Mit LUKS hab ich die Möglichkeit später das Key-File zu tauschen.


> Ohne LUKS müsste ich das Key-File irgendwo ganz sicher aufbewahren,
> damit ich im Falle eines kaputten oder verloren gegangenen Sticks an
> meine Daten komme.


Ohne LUKS würde man das key file, das dann ja den Plattenschlüssel enthält,
seinerseits mit einer pass phrase schützen. Der Vorteil ist, dass auf den
geschützten Schlüssel kein brute force Angriff möglich ist, wenn die pass
phrase lang genug ist (sie müsste aber auch nicht extrem lang sein) und wenn
dem Angreifer nicht gleichzeitig der Platteninhalt zu Verfügung steht.

[..]
> Rechners das Backup wieder am Anfang der Platte. Das andere läuft als
> letztes beim Shutdown und überschreibt den Header auf der Platte wieder
> mit Datenmüll.


ich denke zumindest die 2. variante ist zwar holprig, aber möglich.

> Bei beiden Varianten wird das Header-Backup-File zur wichtigsten Datei
> die man irgendwo absolut sicher verwahren muß für den Fall eines
> kaputten Sticks.


ist aber nicht so dass Problem, weil man ohne die Plattendaten nicht viel
damit anfangen kann.

> Vielleicht ist jetzt dem Einen oder Anderen von Euch noch etwas
> eingefallen.
> --
> mfG Sascha


Gruß
Christian
Ähnliche Themen