Secure Boot unter diversen Betriebssystemen

[kith]

Bitte einen aussagekräftigeren Threadtitel finden.

 

[-Nuke-]

"Angreifer hat es wie auch immer auf mein System geschafft, und will mir jetzt ein böses Kernelmodul unterjubeln"

Wenn ein Angreifer schon so weit ist, dass er dir theoretisch ein Kernel Modul unterjubeln könnte, dann bringt dir ein Schutz gegen modifizierte Module das auch nichts mehr. Er hat praktisch schon Vollzugriff auf das System.

 

[medV2]

Wenn ein Angreifer schon so weit ist, dass er dir theoretisch ein Kernel Modul unterjubeln könnte, dann bringt dir ein Schutz gegen modifizierte Module das auch nichts mehr. Er hat praktisch schon Vollzugriff auf das System.

Vollzugriff muss er nicht haben, es könnte sein das andere Mechanismen wie SELinux oder Apparmor noch aktiv sind. Zudem kann er sich so besser verstecken - ich bemerke die Kompromitierung des Systems nicht sofort, durch das manipulieren des Kernels/Module kann er sich besser vor zukünftiger Entdeckung verschleiern. Auserdem macht es die nach so einem Vorfall sehr wichtige Analyse und Forensik schwieriger.

Ich würde da also schon nen Vorteil sehen. Das mag alles sehr spezifisch sein - aber ich sehe halt vor allem auch keinen Nachteil in der Technologie.

 

[-Nuke-]

Zudem kann er sich so besser verstecken

Aber um genau das zu erreichen braucht der Angreifer Vollzugriff. Oder welche Nutzer können bei dir die Kernel/Modul Konfiguration ändern?

SecureBoot (+ wichtiger anderer Elemente wie Vollverschlüsselung und EFI/Boot Passwort Schutz) schützt halt nur vor einem ganz ganz kleinen Angriffsvektor. Dafür fährt es aber einen massiven Aufwand auf, sowohl in der Spezifikation als auch in der Umsetzung.

Und am Ende legt dir eine Ransomware trotzdem die Firma lahm, weil der ganze Boot und Kernel Schutz nichts gegen tatsächliche Angriffe in freier Wildbahn hilft.

 

[medV2]

Aber um genau das zu erreichen braucht der Angreifer Vollzugriff. Oder welche Nutzer können bei dir die Kernel/Modul Konfiguration ändern?

Der Kernel hat mehr rechte als root. Z.b. darf er ungehindert in den RAM, und jeder Kernelaufruf könnte auch manipuliert zurückkommen. Ein Standardvorgehen ist z.B. oft das Überprüfen von Binarys und Berechtigungen, denen kannst mit einem kompromitiertem Kernel aber nicht trauen. Ein Modul das sich in den Netzwerk/VPN Verkehr einklinkt wäre auch übelst schwer zu detecten, im vergleich zu einem normalen root-Binary. Oder Key/Keyfragmente die direkt aus dem RAM kopiert werden. Ich kann da schon viel herumspinnen, vermutlich (hoffentlich) wirds mir in meiner ganzen Karriere nie passieren.

SecureBoot (+ wichtiger anderer Elemente wie Vollverschlüsselung und EFI/Boot Passwort Schutz) schützt halt nur vor einem ganz ganz kleinen Angriffsvektor. Dafür fährt es aber einen massiven Aufwand auf, sowohl in der Spezifikation als auch in der Umsetzung.

Das stimmt schon, das ist alles sehr speziell. Für mich als Anwender von Secureboot ist der Aufwand aber dennoch sehr gering daher nehm ich es gerne mit. Ursprünglich hab ich ja der Aussage widersprochen, das es garnichts bringt, bzw. wollte dazu Meinungen hören.

Und am Ende legt dir eine Ransomware trotzdem die Firma lahm, weil der ganze Boot und Kernel Schutz nichts gegen tatsächliche Angriffe in freier Wildbahn hilft.

Glaub mir, dagegen steck ich auch deutlich mehr Energie und Arbeitsstunden rein, als gegen spinnerein mit maßgeschneiderten Angriffen auf Kernelmodule

 

[-Nuke-]

Der Kernel hat mehr rechte als root.

Das meine ich ja gar nicht. Meine Frage ist am Ende: Wie kommt bei dir, ohne SecureBoot, der modifizierte Kernel bzw. Modul ins System?

Also nicht "wenn es passiert", sondern mal ganz konkret. Wie könnte es passieren? Weil dann kann man nämlich schön überlegen was dann noch alles so geht und wo SecureBoot wirklich helfen würde, oder eben auch nicht.

 

[medV2]

Ganz klassisch Sicherheitslücke in Anwendung (Client oder Server) + Privilege Escalation im Kernel / SUID Binary.

 

[-Nuke-]

Ganz klassisch Sicherheitslücke in Anwendung (Client oder Server) + Privilege Escalation im Kernel / SUID Binary.

Ja und genau das meine ich. Dann hab ich sowieso Vollzugriff und kann das ganze System modifizieren. Dass ich dann im SecureBoot Fall halt deinen Kernel/Module ggf. nicht modifizieren kann (fragwürdig, bei eigener Signierung und Root-Zugang), ist halt keine große Einschränkung.

 

[medV2]

Ich signier das ja nicht selbst, und wenn ja dann nicht auf dem gleichen System.. Guck dir doch mal an wie das derzeit z.b. bei SLES oder RHEL gelöst ist. Und die Einschränkungen hab ich vorhin ausgeführt. Für mich dreht sich das gerade etwas im Kreis von daher..

 

[-Nuke-]

Naja, du wolltest doch Meinungen dazu haben. Und die ist, dass SecureBoot keinen nennenswerten Beitrag zur Systemsicherheit liefert ("Schlangenöl"), weil jeder Use Case entweder stark konstruiert ist oder, wie in dem von dir genannten Fall einen Befall des Systems auch nicht verhindert.

Und bisher hab ich kein Szenario lesen können, was mich dabei umstimmen würde. Weil "du kannst weder den Kernel noch die Kernel-Module modifizieren" ist für sich alleine stehend einfach kein Argument. Weil das kann ohne weiteres auch ohne SecureBoot hier kein normaler Benutzer.

 

[pit234a]

Ich signier das ja nicht selbst,

ich bin hier überfordert, aber interessiert, mehr dazu zu lernen.

Bisher dachte ich, dass ich sehr wohl als Nutzer dem BIOS des PC einen gültigen Schlüssel nenne und der dann eben alles weitere verifiziert.
Ist das nicht so?
Das BIOS kann ja wohl doch nicht alle möglichen Schlüssel auf Vorrat bereit halten? Wenn so, dann bräuchte ich ja eh nur einen der bekannten Schlüssel, um mein System damit zu markieren? Desgleichen, wenn es einen bestimmten Algorithmus gibt und keine Schlüssel-Datenbank.

Sodann, was, wenn ich mal ein System update?
Wenn ich neue Module baue oder einen neuen Kernel: muss ich dann nicht auch in der Lage sein, dies wieder zu verifizieren? Nicht nur in der Lage sein, sondern bin ich sogar gezwungen dazu?
Wenn so, dann muss es auch einen Mechanismus dazu geben, der dann auch wieder von bösen Geistern missbraucht werden kann.

Ich wiederhole, dass ich keine ausreichenden Kenntnisse habe, was ich an den vorhergehenden Beiträgen fest mache, die mich alleine durch die verwendeten Fach-Begriffe schon überfordern.
Aber Secure-Boot ist doch etwas, das auf BIOS-Ebene statt findet und sich auf ein zu ladendes System bezieht und wenn dies nicht für alle Zeiten auf gewisse Systeme beschränkt bleiben will, muss sich daran auch etwas ändern lassen. Oder nicht?

 

[medV2]

ich bin hier überfordert, aber interessiert, mehr dazu zu lernen.

Bisher dachte ich, dass ich sehr wohl als Nutzer dem BIOS des PC einen gültigen Schlüssel nenne und der dann eben alles weitere verifiziert.
Ist das nicht so?

Dem BIOS oder eben SHIM. Aber das ist ja der Public Key, um ein Modul/Kernel zu signieren wird der Privatekey gebraucht.

 

[Andy_m4]

Für mich als Anwender von Secureboot ist der Aufwand aber dennoch sehr gering daher nehm ich es gerne mit.

Naja. Was heißt gering? Das funktioniert ja nur, wenn die Kette vollständig ist. Sprich alles muss durchsigniert sein bishin zu den Kernelmodulen. Idealerweise baust Du Dir dann einen eigenen Kernel mit allen benötigten Treibern drin und schaltest Module-Load komplett ab.
Und wenn Du es wirklich sicher haben willst, dann nimmst Du auch keinen fertigen Schlüssel (wo Du immer damit rechnen musst, das den auch der Angreifer hat), sondern eigene Schlüssel. Dann musst Du zusätzlich bedenken, das Du bei jedem Update das alles wieder nachsignieren musst. Und das kannst Du auch nicht auf der Maschine selbst machen, wie Du richtigerweise sagst, sondern auf einer eigenen Maschine.
Also mit eben mal was im "BIOS" anknipsen und dann hast Du es, ist es eben nicht getan.

Einen Tod musst Du sterben. Entweder machst Du es easy. Dann ist der Sicherheitsgewinn marginal. Oder Du machst es ordentlich, dann ist da eben auch Aufwand dabei.
Und selbst wenn Du den Aufwand betreibst, bleibt ja immer noch die Frage, wie hoch der Sicherheitsgewinn in der Praxis ist. Sich bis zum Kernel durchexploiten ist nicht unbedingt etwas, was häufig vor kommt. Also zumindest nicht in der aktuellsten Version. Solche Zero-Days sind wertvoll. Die wird daher niemand leichtfertig einsetzen, weil jeder Einsatz eine Entdeckung riskiert und damit das sie durch Updates unbrauchbar wird. Das wird man also eher auf Ziele ansetzen, wo es wirklich lohnt und eher nicht so, um beim kleinen Mittelständler einzubrechen. :-)

Vollkommen nutzlos ist Secure-Boot freilich nicht. Aber wie bei allen Sicherheitsmaßnahmen stellt sich schlicht die Frage nach dem Kosten-Nutzen-Verhältnis und wäre die Energie, die ich da rein stecke nicht anders eventuell sinnvoller angelegt.

Bisher dachte ich, dass ich sehr wohl als Nutzer dem BIOS des PC einen gültigen Schlüssel nenne und der dann eben alles weitere verifiziert.

Sozusagen. Im BIOS bzw. UEFI muss ein Schlüssel hinterlegt sein, anhand dessen das UEFI den signierten Bootloader prüfen kann, ob der 1.korrekt signiert und 2.unverändert ist und nur dann lädt er ihn und führt ihn aus. Der Bootloader kann seinerseits wieder prüfen, ob der Kernel korrekt signiert ist. Der Kernel, ob Treiber korrekt signiert sind usw.
So hat man quasi eine Vertrauenskette.

Das BIOS kann ja wohl doch nicht alle möglichen Schlüssel auf Vorrat bereit halten? Wenn so, dann bräuchte ich ja eh nur einen der bekannten Schlüssel, um mein System damit zu markieren?

Na alle möglichen Schlüssel sowieso nicht. Üblicherweise ist der Microsoft-Key im UEFI hinterlegt. Loader die Microsoft signiert hat, lassen sich auf solchen Systemen booten. Prominentestes Beispiel ist natürlich der Windows-Loader. Aber mit shim gibts auch ein einfachen Loader für das Linux-Lager, den Microsoft netterweise signiert hat. Allerdings dient der primär dazu die etwaige Userporbleme mit aktiven Secure-Boot zu umgehen (der User muss nicht "umständlich" Secure-Boot abschalten und kann trotzdem Linux booten). Was nach dem shim kommt ist i.d.R. nicht signiert und damit hast Du auch keine Vertrauenskette und somit keine Sicherheit.

Man hat aber in der Regel die Möglichkeit eigene Keys im UEFI zu hinterlegen. Damit bist Du nicht auf Microsoft angewiesen, musst Dich aber auch um die (sichere) Signierung selbst kümmern.

 

[Yamagi]

Ich hab mal umbenannt und wieder aufgemacht.

 

[Rosendoktor]

SHIM hat eine eigene Liste an Zertifikaten und die kann - soweit ich weiß - nur aus dem laufenden authentifzierten System geändert werden. Ebenso gibts für diese MOK (Machine Owner Key) Liste ein Passwort - Linuxdistros setzten das gerne auf das root-Passwort, wird aber auch öfters leer gelassen. Die Bestätigung musst du immer aus der UEFI Konsole machen, du brauchst also nochmal physischen Zugriff.

Ach ja, die MOKs... hatte ich ganz vergessen, kommt bei mir nicht zum Einsatz da ich die UEFI Keys gegen meine eigenen austausche. Danke.

 

[ari]

Aus der technischen Diskussion rund um Secure Boot halte ich mich raus, das ist so weit von meinem Fachgebiet entfernt wie's nur geht. Aber "ihr" überschätzt die Expertise von Angreifer:innen / die für einen erfolgreichen Angriff notwendige Expertise deutlich. Ich war in den letzten Jahren bei den Aufräumarbeiten einiger Sicherheitsvorfälle jedweder Couleur dabei - die in diesem Thread diskutierten Angriffsszenarien gegen Systeme waren dabei kein einziges Mal Thema. Bei Weitem nicht.

 

[pit234a]

Aus der technischen Diskussion rund um Secure Boot halte ich mich raus, das ist so weit von meinem Fachgebiet entfernt wie's nur geht. Aber "ihr" überschätzt die Expertise von Angreifer:innen / die für einen erfolgreichen Angriff notwendige Expertise deutlich. Ich war in den letzten Jahren bei den Aufräumarbeiten einiger Sicherheitsvorfälle jedweder Couleur dabei - die in diesem Thread diskutierten Angriffsszenarien gegen Systeme waren dabei kein einziges Mal Thema. Bei Weitem nicht.

nochmal nachgefragt: hätte secure boot bei deinen Fällen geholfen?
Ich selbst bin da vollkommen unbedarfter Endanwender und habe regelrecht gar keine IT-relevante Ausbildung und die wenigen Teile sind auch schon über 30 Jahre veraltet. Wir haben in dem Unternehmen, bei dem ich angestellt bin, die IT nun an irgendwelche Dienstleister verteilt, die das wahrscheinlich alles besser können
Als wir früher noch eine eigene IT-Abteilung im Unternehmen hatten, war auch der Kontakt zu diesen Kollegen noch stärker und die lächelten immer leicht süffisant zu den Sicherungsmaßnahmen, die damals so hoch gepriesen wurden. Sie ließen sich zwischen den Zeilen immer so vernehmen, dass der größte Angriffsvektor der dumme Nutzer sei und weil IT nicht unser Geschäft ist, können alle Nutzer als dumm genug gelten, Fehler zu machen. Ganz besonders, wenn man solchen dummen Nutzern dann auch noch Admin-Rechte einräumt, was bei uns weithin der Fall gewesen ist.
Ich nenne dazu ein Beispiel, das ich nicht mit exakten Zahlen belegen kann. Es ist uns nämlich verboten, gewisse Apps auf den Smart-Phones zu installieren. Genau genommen dürfen wir eh nur SW aus einem Pool benutzen, doch bei den Handy-Apps scheint das eher ein Wildwuchs zu sein. Da hat fast jeder die eine oder andere oder auch mehrere der ausdrücklich untersagten Apps installiert und fragt dann ganz verwundert, wieso ich das nicht auch benutze.
"Ist doch gar kein Problem, so einfach geht das... und schon gehörst du dazu."
Für mich ist so etwas natürlich nogo und ich will auch ausdrücklich nicht dazu gehören. Tatsächlich wird man dabei aber oft schräg angesehen, vor allem auch von Kunden, die nicht verstehen können, wieso man sich einer so geilen Sache nicht hingibt, wie sie irgendeine App doch bietet, und noch dazu vollkommen kostenlos.
Ich meine, was nützt secure boot auf dem PC, wenn ich das Handy voller Angriffs-SW lade, mit dem Firmen-Netz verbinde, mit dem Firmen-PC, dem Privat-PC und so weiter?
Ich kann mir sehr gut vorstellen, dass die meisten Angriffe ja auf Daten erfolgen und nicht auf Betriebssysteme. Anstatt einen PC mit einem nicht verifizierten OS zu booten, nehme ich ihn einfach mit, wenn ich schon mal physikalisch davor sitze oder baue schnell mal die Festplatte aus, was ja kaum länger dauert, als ein System zu booten. Naja, manchmal zumindest.
Aber ist es nicht sehr viel effizienter, einen Angriff auf ein laufendes System zu starten? Dazu muss ich nicht mal meinen Stützpunkt verlassen. Gut geschützt in der berühmten Hütte im finsteren Wald mit super schnellen Internet-Leitungen und ausreichend Rechner-Power, wie man sich das seit James Bond ja für Bösewichter so vorstellt, kann ganz bequem ein Angriff ausgedacht und durchgeführt werden?

Diese Fragestellungen im Zusammenhang mit secure boot gehen natürlich an der technischen Realisation für bestimmte Betriebssysteme vorbei.
Ich finde sie gleichwohl wichtig und interessant und wenn wir schon einen Beitrag haben, wo sich jemand mit realer Erfahrung zu Angriffen meldet, möchte ich da nachfragen: wie viel hätte secure boot im richtigen Leben zur Sicherheit beigetragen?

 

[Andy_m4]

Aber ist es nicht sehr viel effizienter, einen Angriff auf ein laufendes System zu starten?

Kommt darauf an, was Du erreichen willst und ob Du überhaupt Zugang kriegst.
Ich sag mal: um ein paar Daten zu entwenden reicht das sicher aus.
Willst Du aber z.B. ein Passwort heimlich mitlesen und Phishing ist keine Alternative, dann ist wiederum ein Keylogger interessant. Dafür ist es praktisch ein Programm zu haben, was sich möglichst unbemerkt ins System einnisten kann.
Bei solchen Szenarien wird der Schutz des Betriebssystems selbst - und zwar vor Manipulation - schon wieder interessant.

Gern zitiert wird in dem Zusammenhang das Evil-Maid-Szenario. Wo dann eine Person die Gelegenheit benutzt, um sich kurz in einem passenden/unbeaufsichtigten Moment Zugang zum Gerät zu verschaffen um mal schnell von einem USB-Stick zu booten, welcher dann die Malware platziert.
Vor so was schützt ein korrekt konfiguriertes Secure-Boot, weil man eben nicht mal schnell von USB-Stick gebootet werden kann.
Vor so was würde im Prinzip auch eine vollverschlüsselte Festplatte schützen, da diese nicht mehr unbemerkt manipuliert werden kann. Aber der Schwachpunkt ist hier die Bootpartition die ja unverschlüsselt sein muss, um den initialen Bootvorgang zu starten. Statt direkt im System würde sich dann die Malware hier irgendwo eingraben.

Der Schutz von Secure-Boot ist aber bei Weitem nicht perfekt. Wenn jemand physisch Zugang zum Gerät hat, hat er natürlich jede Menge Möglichkeiten für Angriffe bishin zur Modifikation der Hardware.

Ergänzen lässt sich noch dazu sagen, das UEFI etc. natürlich auch ziemlich komplex ist und damit eine hohe Wahrscheinlichkeit gegeben ist, das sich da irgendwie ein Angriff drauf fahren lässt. Und dann auch noch die Tatsache, das solche Firmware nicht mehr in irgendeinem unveränderlichen ROM sitzt, sondern updatebar ist. Du hast quasi ein manipulierbares Betriebssystem über dem normalen Betriebssystem. Wenn das UEFI infiziert ist, hat jedes Betriebssystem sehr schlechte Karten sich dagegen zu wehren und schon allein die Infektion zu erkennen.

Früher, als wir noch ein althergebrachtes BIOS im ROM hatten, da konnte man wenigstens sicher sein das nach der Infektion ein stromlos machen des Gerätes und formatieren der Festplatte alles wirklich weggefegt hat.

wie man sich das seit James Bond ja für Bösewichter so vorstellt, kann ganz bequem ein Angriff ausgedacht und durchgeführt werden?

Ja. Diese James-Bond-artige Sicht auf die Dinge, bringt die Leute ja häufig dazu zu sagen: "Wer soll mich schon angreifen wollen".
Die meisten Angriffe sind aber gar nicht irgendwelche raffinierten gezielten Attacken, sondern eher grobschlächtig.
Nach dem Motto: Wir schießen mal ein bisschen wild mit einer abgesägten Schrotflinte aufs Feld und wenn da zufällig ein Hase im Weg stand, dann haben wir den.
Oder anders gesagt: Solange es reicht massenhaft eMails mit ein bissl Chat-GPT-generated Text und nem Anhang rechnung.pdf.exe zu verschicken, solange müssen wir uns gar nicht die Mühe machen einen Angriff auf Secure-Boot zu starten.

 

[ari]

nochmal nachgefragt: hätte secure boot bei deinen Fällen geholfen?

Nein. In den Fällen, in denen ich begleitend involviert war, waren die Ursachen für kompromittierte Systeme immer etwas aus dem "Standardrepertoire". Beispielsweise Dinge wie ungesicherte Wartungszugänge, triviale und / oder wiederverwendete Passwörter, aus dem Internet erreichbare Systeme mit simpel auszunutzenden Schwachstellen. Ich kann mich genau an einen einzigen Fall erinnern, der technisch komplex war. Da war eine zu dem Zeitpunkt noch nicht öffentlich bekannte Sicherheitslücke in Kombination mit einer gewissen Portion Insiderwissen der Ursprung eines Einbruches. Aber auch da hätte Secure Boot nicht geholfen.

Versteht mich bitte nicht falsch, ich möchte hier nicht für oder wider der Sinnhaftigkeit von Secure Boot argumentieren. Aber ich halte es für sinnvoll, das Ausmass des Schutzes, den es gegen gängige Angriffe bietet beziehungsweise die Wahrscheinlichkeit eines Angriffes, bei dem Secure Boot relevant werden würde, nicht aus den Augen zu verlieren.

 

[kaputtnik]

Stimmt schon, dass Angriffe auf IT-Infrastrukturen in der Regel trivial sind. Das liegt aber daran, dass es die Schutzmaßnahmen bei den meisten Unternehmen auch sind und daher der Aufwand für einen komplexen Angriff überhaupt nicht notwendig ist.

Leider verleitet das mMn viele zum Trugschluss, dass es keine komplexen Angriffe gibt oder diese nicht bei einem selbst zum Einsatz kommen können.

Was Secureboot angeht, hab ich das auch schon seit einer Weile auf meinem Notebook mit Linux neben der Vollverschlüsselung eingerichtet.

Der Aufwand, das zu betreiben, nachdem es eingerichtet wurde, ist trivial.

Staatstrojaner und Co. haben ja leider gezeigt, dass es Menschen gibt, die unbemerkt Schadsoftware auf deinem System installieren wollen, wenn sie kurz Zugriff auf dein Endgerät haben.
Auch wenn die Eintrittswahrscheinlichkeit gering ist, habe ich für mich entschieden, die Funktion aus den oben genannten Gründen mitzunehmen.

 

[medV2]

Eins vorweg, natürlich ist mir, und ich denke jedem hier klar, dass wir von einem unwahrscheinlichen Angriffsszenario sprechen. Dennoch gibt es die auch, um so mehr man mit Kunden und größeren Kunden arbeitet, so wahrscheinlicher ist es auch, dass man gezielte Angriffe sieht.

Sicherheit ist immer ein Zwiebel-konzept, auch wenn ich die ersten Lagen besonders im Auge behalten sollte und die Zweifelsohne die wichtigsten sind, so sollte man auch den Kern nicht vernachlässigen.
Auch habe ich z.B. als IT Dienstleister bei Kunden nicht immer über alles die Kontrolle.

Ja, es gibt “secureboot” und “secureboot”. Ich kann alles nur selbst signieren und nur mir trauen. Das ist ein großer Aufwand, den ich auch nicht betreibe. Was nicht heißt, dass es nicht Systeme gibt, wo so etwas sinnvoll sein kann.
Ich nehme das, was mir RHEL an die Hand gibt. RHEL traue ich ohnehin, sonst dürfte ich ihr OS nicht einsetzen. Da habe ich sehr wenig Aufwand, wirklich nur wenn ich ein nicht von RHEL bereitgestelltes Kernelmodul brauche - kommt es bei zig Servern alle 1-2 Jahre mal vor.

Auch wichtig: Analyse/Forensik NACH dem Zwischenfall. Ein Kunde möchte wissen, ob womöglich Kundendaten oder Business Informationen abgeflossen sind. Eine vertrauenswürdige Bootkette hilft, da man kann gewisse Annahmen treffen und die in einer Form begründen kann, die zumindest für die Verantwortlichen meist reicht.

Im Endeffekt ist es ne Kosten/Nutzen Frage, und da sich mit meiner Methode wenige Kosten ergeben und ich zumindest Vorteile sehe ist es für mich ne klare Sache. Und um den Vorteil nochmal klar heraus zu streichen: Sehr unwahrscheinliche Angriffe die aber einen hohen Impakt haben und erleichterung bei der Forensik nach einem Zwischenfall.

 

[ari]

Leider verleitet das mMn viele zum Trugschluss, dass es keine komplexen Angriffe gibt oder diese nicht bei einem selbst zum Einsatz kommen können.

Es ist eine Frage des Threat Modelling. Wenn du in deinen Überlegungen Bedrohungsakteure inkludieren musst, die in der Lage sind solche technisch komplexen Angriffe durchzuführen, dann müssen deine Gegenmassnahmen deutlich weiter gehen als das, was wir hier im Thread diskutieren. Und sich vor allem auch auf eine Vielzahl "analoger" Aspekte ausweiten.

Meine Erfahrung ist eher, dass Menschen, die sich über komplexe technische Angriffe Gedanken machen dazu neigen, ihre eigene Attraktivität für Angreifer:innen zu überschätzen und gleichzeitig gerne und häufig anderweitige Fehler machen, die es genau solchen Angreifer:innen leicht machen, einen erfolgreichen Angriff zu fahren. Damit meine ich dediziert niemanden aus diesem Thread. Nicht, dass das falsch rüberkommt.

Der Aufwand, das zu betreiben, nachdem es eingerichtet wurde, ist trivial.

Das kommt ganz auf das eigene Setup an. Eines meiner Systeme ist auf proprietare Treiber von Nvidia "angewiesen". Dafür brauche ich DKMS, damit gebaute Kernelmodule laufen nicht so ohne weiteres. Ich könnte mir einen Machine Owner Key generieren, den entsprechend in die Datenbank eintragen & das Problem so lösen. Wenn ich den nicht mit einem Passwort schütze kann jede:r Angreifer:in damit fleissig eigene Kernelmodule signieren, und den ganzen Schutz aushebeln. Mit einem gesetzten Passwort ist das Automatisieren von Upgrades aber wieder (etwas) komplizierter. Mein Punkt ist: Es ist definitiv machbar, und kein gigantischer Aufwand. Aber doch ein Mehraufwand, der im Alltag nervig werden kann.

Auch wichtig: Analyse/Forensik NACH dem Zwischenfall. Ein Kunde möchte wissen, ob womöglich Kundendaten oder Business Informationen abgeflossen sind. Eine vertrauenswürdige Bootkette hilft, da man kann gewisse Annahmen treffen und die in einer Form begründen kann, die zumindest für die Verantwortlichen meist reicht.

Da steige ich gerade nicht ganz durch. Wo hilft mir die Bootkette dabei zu sagen, ob von einem kompromittierten System Daten abgeflossen sind?

 

[Andy_m4]

Staatstrojaner und Co. haben ja leider gezeigt, dass es Menschen gibt, die unbemerkt Schadsoftware auf deinem System installieren wollen, wenn sie kurz Zugriff auf dein Endgerät haben.

Also ich würde mit dem Argument mitgehen, das man deshalb Secure-Boot einrichten sollte, weil Secure-Boot zu haben ist immer noch besser als gar nichts zu haben. Und der Punkt gilt ja auch noch dann, wenn man die ganzen vorgefertigten Sachen benutzt, wo die Einrichtung ja tatsächlich kaum mehr als ein Knopfdruck ist.

Aber wie gesagt, Der Schutz von Secure-Boot ist nicht wirklich gut. Das hält den "Kleinkriminellen" ab. Wenn Du jetzt aber sagst "Staatstrojaner" und den zu platzieren ist für die behördliche Stelle offenbar so wichtig, das sie den Aufwand auf sich nehmen, mein Gerät in die Finger zu kriegen, dann würde ich mich nicht darauf verlassen, das Secure-Boot mich schützt.

Wenn mich also am Flughafen die Sicherheitsbehörden rauszerren und mein Laptop mal kurz mit ins Hinterzimmer nehmen, während sie mich befragen und mich dann irgendwie wieder gehen lassen und mir den Laptop in die Hand drücken, würde ich das Gerät eher schreddern, aber ganz sicher nicht weiter benutzen, weil ich hab ja Secure-Boot; was soll passieren.

Secure-Boot bringt mir nur in einem Fall was: Ich hab nicht mitgekriegt das sie den Laptop in den Händen hatten und sie waren obendrein zu doof den Schutz auszuhebeln.

Ein Kunde möchte wissen, ob womöglich Kundendaten oder Business Informationen abgeflossen sind. Eine vertrauenswürdige Bootkette hilft, da man kann gewisse Annahmen treffen und die in einer Form begründen kann, die zumindest für die Verantwortlichen meist reicht.

Naja. Wenns nur darum geht jemanden irgendwas zu erzählen, dann von mir aus.
Die Leute lassen sich ja teilweise alles mögliche aufschwatzen. Wenn man so argumentiert, kann man jeglichen Unsinn rechtfertigen. Dann kann ich auch sagen: Wegen esoterisch Kunden tu ich in meine Geräte immer ein Schutzkristall und wenn ich den das dann sage, sind die alle beruhigt. :-)
Das kann man so machen, hat aber natürlich nix mit einer realen Risikobewertung zu tun.

erleichterung bei der Forensik nach einem Zwischenfall.

Diese Forensik hat aber prinzipbedingt Grenzen. Du kannst eigentlich nur nachweisen, was auch da ist. Du kannst aber darüber keine gesicherten Aussagen treffen treffen. Wenn Du also zu einer Sache keine Anhaltspunkte findest, heißt das noch lange nicht, das sie nicht passiert sind. Und selbst bei den Sachen, die Du findest ist es immer eine Frage der Wertung. Das sehen wir auch immer schön bei Behauptungen a-la "Russische Hacker haben ..." und als "Beweis" werden dann irgendwelche russischen Wörter in der Malware präsentiert, was natürlich letztlich gar nichts beweist.

Forensik funktioniert also sowieso nur in einen engen Bereich. Und wenn man dann noch sagt, das mir Secure-Boot dabei hilft ...
Also es mag Fälle geben, wo das so ist. Aber generell wirkt das erst mal etwas seltsam und ich würde eher denken: Wenn sich sowas jemand woher zieht (ziehen muss), um Secure-Boot positiv zu begründen, dann kanns nicht so dolle sein. :-)

Wie gesagt: Ich gehe mit dem Punkt mit, das es zu haben ist besser als nix zu haben. Aber man sollte es nicht versuchen es größer aufblasen, als es ist.

 

[-Nuke-]

Wobei man mit dem Argument "es zu haben ist besser als nichts zu haben" sich auch eine Anti-Virus-Software mit Echtzeitschutz installieren müsste.

 

[Andy_m4]

Wobei man mit dem Argument "es zu haben ist besser als nichts zu haben" sich auch eine Anti-Virus-Software mit Echtzeitschutz installieren müsste.

Grundsätzlich hast Du Recht.
Bei Antivirus handelst Du Dir ja auch handfeste Nachteile ein, in dem Du zusätzliche Angriffspunkte schaffst. Oder gar nachteilige Auswirkungen bei dem kein Angreifer involviert ist. Zum Beispiel ein False-Postive, wo Du dann Aufwand in Gegenmaßnahmen (Neuaufsetzen) reinsteckst, obwohl gar nichts war.
Die meisten Sicherheitsmaßnahmen haben auch so einen negativen Impact und man muss halt gucken, inwieweit die Vorteile gegenüber den Nachteilen überwiegen.
Und ich würde mal behaupten, das es da für Secure-Boot besser aussieht als für AV-Software.