Hallo, Der Kernel wird laut "system verschlüsseln" ja nicht verschlüsselt gespeichert. Es ist also möglich mir einen gepatchten Kernel unter zu schieben der die eigentlich verschlüsselten Daten versendet. Richtig?

Drum hat man den Kernel ja auf nem flashdrive das nicht im PC ist…

senden9 schrieb:

Es ist also möglich mir einen gepatchten Kernel unter zu schieben der die eigentlich verschlüsselten Daten versendet. Richtig?

Richtig. Du könntest allerdings beim Systemstart ein script aufrufen, das Dir (Vergleich von Dateigröße, Datum, Hash, ...) meldet, wenn sich am Kernel was geändert hat. (Vergleich mit den alten Informationen, die - wie das script selber - manipulationssicher in einer Datei im verschlüsselten Datenbereich abgelegt sind.) Dann hast Du zwar das System einmal mit dem manipulierten kernel gestartet, weißt dann aber wenigstens gleich, daß Du nicht weiter damit arbeiten willst. (Bei kernelupdates solltest Du natürlich auch die Vergleichsdatei aktualisieren ... )

Funktioniert natürlich nur, wenn der Angreifer nicht so clever ist, alle von Dir verwendeten Vergleichsgrößen trotz Veränderung auf den alten Stand zu setzen - sofern das möglich ist.

Stichwort Rootkit – wenn der Angreifer den Kernel hackt, kann er dies im laufenden System auch so verstecken, dass jedes Prüfscript ins Leere läuft.

Eine 100%ige Sicherheit gibt es nicht, nur erhöhte Hürden für den Angreifer.

V for Vortex schrieb:

Stichwort Rootkit – wenn der Angreifer den Kernel hackt, kann er dies im laufenden System auch so verstecken, dass jedes Prüfscript ins Leere läuft.

*hmm* Wie würde er das machen, wenn er nicht wissen kann, was das Prüfscript prüft und wie die Ausgabe aussieht ? Ich hätte eigentlich gedacht, das sei ziemlich narrensicher ...

Eine 100%ige Sicherheit gibt es nicht, nur erhöhte Hürden für den Angreifer.

Wohl wahr ...

Die größte Schwachstelle ist normalerweise ja das Passwort, ein Hardware-Keylogger kostet ein paar Cent und die wenigsten Leute kontrollieren jedes Mal die USB-Anschlüsse an der Rückseite des PCs.

Ich habe mein /boot auf einem USB-Stick (und den Stick am Schlüsselbund), ist sehr praktisch da ich da dann auch gleich zig Live-CDs mit drauf habe. Das Passwort macht dann nur ein Keyfile auf dem gleichen Stick auf und die Festplatte wird dann mit dem Keyfile entschlüsselt.

Ein Angreifer muss es also schaffen den USB-Stick zu modifizieren bzw. das USB abzuhören und das Passwort mitzuloggen. Das ist dann schon mal etwas sicherer im Vergleich zu einem unverschlüsselten /boot auf der Festplatte wo man nur das Initramfs modifizieren muss. Und das ist kinderleicht denn das Initramfs ist einfach nur ein Shell-Script, da braucht man nicht mal grosse Programmierkenntnisse dafür zu haben. Der Kernel selbst kann unmodifiziert bleiben.

frostschutz schrieb:

Ein Angreifer muss es also schaffen den USB-Stick zu modifizieren bzw. das USB abzuhören und das Passwort mitzuloggen.

Oder er mogelt Dir eine andere Bootpartition unter und erweckt nur den Eindruck, dass das System von USB starten würde. Die Frage ist natürlich, woher den Platz für eine neue Partition nehmen. Je nach System gibt es da aber durchaus Lösungen. Im schlimmsten Fall der Einbau einer größeren Platte oder einer zusätzlichen Platte

DrScott schrieb:

Oder er mogelt Dir eine andere Bootpartition unter und erweckt nur den Eindruck, dass das System von USB starten würde.

Das wird schwierig. Ich hab ein gepatchtes Grub... nicht aus Sicherheitsgründen sondern um auf der rechten Seite Platz für einen schönen großen Tux-Pinguin zu haben. Das Grub-Menü selbst ist bei mir auch sehr umfangreich und ebenso von Hand entstanden. Wenn da dann stattdessen ein Standard-Ubuntu-Grub kommt merke ich das also sofort...

Da muss dann also wenn schon eine perfekte Virtualisierungsschicht zwischengeschalten werden, so daß dann tatsächlich mein Stick und mein Bootzeug kommt aber eben trotzdem eine Software dazwischensitzt die alles mitprotokolliert.

Die Frage ist natürlich, woher den Platz für eine neue Partition nehmen.

Meistens sind mehr als genug Anschlüsse für sowas vorhanden.

Happy Penguin schrieb:

Du könntest allerdings beim Systemstart ein script aufrufen, das Dir (Vergleich von Dateigröße, Datum, Hash, ...) meldet, wenn sich am Kernel was geändert hat. (Vergleich mit den alten Informationen, die - wie das script selber - manipulationssicher in einer Datei im verschlüsselten Datenbereich abgelegt sind.)

Damit das Skript dann aber aktiv wird muss die Platte entschlüsselt sein -- somit hätte der Angreifer das Harddisk Passwort schon --> FAIL

Happy Penguin schrieb:

V for Vortex schrieb:

Stichwort Rootkit – wenn der Angreifer den Kernel hackt, kann er dies im laufenden System auch so verstecken, dass jedes Prüfscript ins Leere läuft.

*hmm* Wie würde er das machen, wenn er nicht wissen kann, was das Prüfscript prüft und wie die Ausgabe aussieht ? Ich hätte eigentlich gedacht, das sei ziemlich narrensicher ...

Ein solcher Hack oder ein Rootkit verbergen möglichst sämtliche Änderungen am System vor diesem selbst, gaukeln also die jeweiligen normalen Werte (hier z.B. einen Original-Kernel) vor. Daher ist es insofern egal, womit das System dann geprüft wird. Daher ist generell ein Scan eines laufenden Systems aus diesem selbst heraus nur sehr beschränkt sinnvoll.

Ok, die vorgeschlagene Lösung, den Inhalt von /boot zu checken macht erst NACH einer erfolgreichen Attacke auf diese Aufmerksam. (d.h. der Angreifer könnte jetzt das System entsperren) Aber ist das nicht trotzdem der pragmatischte Umgang damit? Im Anschluss müsste wird dann mittels luksaddkey ein neuer Schlüssel erstellt werden und der alte dann gelöscht. http://wiki.ubuntuusers.de/LUKS/Schl%C3%BCsseldatei (Und je nachdem welche Konsequenzen sich abzeichnen wenn jemand eine "Evil-Maid"-Attacke auf dein System für adequat erachtet, sollte man sich schonmal überlegen, ob man wichtige Daten als verschlüsselte Container an RapidShare übergibt, den Header plus Schlüssel als verschlüsselten Container irgendwo platziert und dann vom Rechner löscht - wer dann kommt, kommt zu spät)

Als Gegenmaßnahme gegen Hardwarekeylogger bzw. Geräte die USB-Kommunikation abhören hilft das zwar auch nicht - aber für einen solchen Angriff kommen m.E. fast nur staatliche Institutionen in Frage.

Konkrete Frage: Wie richte ich mir denn mein System ein, dass ich /boot auf nen Stick bzw. SD packen kann?

T Schroeder schrieb:

Ok, die vorgeschlagene Lösung, den Inhalt von /boot zu checken macht erst NACH einer erfolgreichen Attacke auf diese Aufmerksam. (d.h. der Angreifer könnte jetzt das System entsperren)

Er könnte nicht sondern er kann und wird (man muss dann davon ausgehen, daß der Angreifer sich auch gleich eine Kopie der ganzen Platte gezogen hat.).

Aber ist das nicht trotzdem der pragmatischte Umgang damit?

Macht insofern Sinn, daß man den Angriff überhaupt bemerkt, ja.

Im Anschluss müsste wird dann mittels luksaddkey ein neuer Schlüssel erstellt werden und der alte dann gelöscht.

Das reicht nicht. Der Angreifer könnte ja zumindest den LUKS-Header kopiert haben und dort ist dann die alte Passphrase noch gültig. LUKS kann zwar die Passphrase ändern und mehrere Passphrases verwalten aber der eigentliche Schlüssel für die Daten bleibt immer gleich. Mit einem alten Header kommt man daher mit alter Passphrase dann noch an die Daten heran. Einzige Lösung hier ist neu verschlüsseln (Daten sichern, luksFormat, Daten rückspielen).

RapidShare

Brrr grusel.

Als Gegenmaßnahme gegen Hardwarekeylogger bzw. Geräte die USB-Kommunikation abhören hilft das zwar auch nicht - aber für einen solchen Angriff kommen m.E. fast nur staatliche Institutionen in Frage.

Oder die eigene Familie... wenn ein Mitglied selbiger technikversiert und an deinem Zeug interessiert ist...

Konkrete Frage: Wie richte ich mir denn mein System ein, dass ich /boot auf nen Stick bzw. SD packen kann?

/boot auf einem USB-Stick ist weiters nichts besonderes, einfach auswählen als Device für Grub / Boot. Das ist erstmal nicht anders als wenns eine Boot Partition auf der internen Festplatte wäre.

Ah, ich sehe das Problem.

wenn zum Zeitpunkt 1 (Beginn der Attacke) bereits ein vollständiges Festplattenimage gezogen wird, dann fehlt nur noch der Schlüssel... Dann muss verhindert werden, dass Eve zu einem späteren Zeitpunkt2 in Besitz vom Schlüssel kommt.

in Anschluss an Bruce Schneier folge ich trotzdem einen pragmatischen Ansatz. Nach dem Booten wird der Kernel gecheckt und das sollte dann während des Bootvorgangs zu Konsequenzen führen (deaktivierung der Netzwerkkarte und aller USB-Ports z.B.) - Hier wäre dann der kritische Punkt die Übergabe von /boot an /root... Immer noch nicht perfekt aber ein gangbarer Ansatz (Alles andere muss zu Trusted Platform o.ä. Gedanken führen) Dahinter steht die Hoffnung, den Schlüssel im System zu halten, also zu verhindern, dass der Klartextschlüssel weitergeleitet wird.

T Schroeder schrieb:

Nach dem Booten wird der Kernel gecheckt...

Was soll dieser Check liefern, wenn der "Angriffscode" vorher schon all seine Spuren wieder verwischt hat? Übrigens ist zum Abgreifen des Passworts gar keine Kernelmodifikation notwendig. Es reicht eine Anpassung der Skripte in der initrd. Diese Anpassung schnappt sich das Passwort, verwischt dann die Spuren und fährt erst dann auf dem normalen Wege mit der Weitergabe des eingegebenen Passworts an das System fort.

DrScott schrieb:

Was soll dieser Check liefern, wenn der "Angriffscode" vorher schon all seine Spuren wieder verwischt hat? Übrigens ist zum Abgreifen des Passworts gar keine Kernelmodifikation notwendig. Es reicht eine Anpassung der Skripte in der initrd.

Und das veränderte initrd weist die gleichen Charakteristika (timestamp, filesize, Hashwert, ... ich denke, es fällt uns noch mehr ein ) auf, wie das unveränderte Original-initrd, bzw. läßt sich so hinbiegen ?

Da der Angreifer nicht wissen kann, welche Größen das Testscript vergleicht, stelle ich mir das schwierig vor. Auch das Zwischenschalten einer Zwischenschicht, die die nachfolgenden Scriptausgaben abfängt und mit dem Originalwert überschreibt, setzt ja voraus, daß die Zwischenschicht vorab weiß, in welcher Form ich die Ausgabe gestalte. (Vielleicht bin ich ja böse und füge bewußt eine Dummyzeile mit zwei unterschiedlichen Werten ein - wenn die dann plötzlich auch als gleich ausgegeben werden, weiß ich, da pfuscht was dazwischen. )

Und die Kopie der verschlüsselten Platte nützt nur dann was, wenn der Schlüssel auch übergeben / verschickt werden kann - solange keine Verbindung ins Netz hergestellt wird, müsste das doch unterbunden sein, oder ?

P.S./OT:
(Um Mitternacht sei mir ein leicht infantiler Scherz erlaubt ... )
Übrigens, eben bekam ich erstmal eine Fehlermeldung der Forenserver:

Some of our servers are currently running amok.
We are trying hard to get it up as soon as possible again. So stay tuned!
Sorry for the inconvenience.

Insbesondere der zweite Satz klingt für mich amüsant und ruft den Wunsch wach, dem Server was in einer Internetapotheke zu bestellen ... wenn ich den Mails glauben kann, die ständig in meinem Spamordner landen, sollte das sofort und dauerhaft helfen.

In diesem Sinne: Gute Nacht !