Hadmut Danisch

Ansichten eines Informatikers

Warum kein Schreibschutz?

Hadmut
17.10.2021 0:10

Mal was Technisches zur IT-Sicherheit und dem Behördenversagen zu ransomware.

Ein Leser fragt zur Sache mit den ransomware-Angriffen an:

Hallo Herr Danisch,

warum gibt es so etwas grundlegendes wie einen Schreibschutz nicht mehr?

Bei SD-Adaptern (auf Micro-SD) gibt es die noch. Aber das ist laut c’t anscheinend auch nur eine Art Kindersicherung, welche dem Betriebssystem sagt: „Bitte nicht schreiben!“

Das hat zuletzt noch im Copy-Shop funktioniert und es gab eine Fehlermeldung.
Warum wollen die aber überhaupt auf mein Medium schreiben, wenn sie es lediglich auslesen sollen?

Muss ich Betriebssysteme, wie zu Omas Zeiten, von CD-ROM installieren,
um auf Nummer sicher zu gehen?

Von hinten durchs Auge mit einem Raspberry Zero ließe sich das noch absichern.
Aber wieso brauche ich so viel Komplexität nur für einen verf…luchten Schreibschutz!?

Viele Grüße

Da geht es ein bisschen durcheinander wie Kraut und Rüben. Ich drösel das mal auf. Im Prinzip ehemals mein Spezialgebiet, über das ich mal … ach, vergessen wir’s.

Speichermedien unter Betriebssystemkontrolle

Also im wesentlichen RAM, eingebaute Festplatte, eingebaute SSD sind – im Allgemeinen – Medien zur zeitlichen Übertragung von Informationen, also ein Thema der Kommunikationssicherheit. Weil aber Absender und Empfänger in der Regel identisch sind, nämlich derselbe Rechner, kann ein Schreibschutz durch das Betriebssystem eben nicht vor dem Betriebssystem schützen, weil das in den Bereich der Systemsicherheit gehört. Und die Systemsicherheit schützt das System gegen Dritte, nicht vor sich selbst.

Deshalb gibt es normalerweise abgestufte Rechte, Benutzer, Administrator-/Rootrechte und so weiter. Das hilft, solange es dicht ist. Aber: Es ist nunmal nicht immer dicht, auch da gibt es Löcher, schlampige Konfigurationen und Leute, die als Admin arbeiten, während es zum Beispiel auf einem Behördenrechner nicht vorkommen sollte, dass der Anwender selbst Administratorrechte haben oder erlangen kann. Aber irgendwelche Fehler, die man ausnutzen kann, finden sich fast immer.

Das Problem dabei: Das, was der Benutzer arbeitet, muss er auch schreiben können. Wenn man beispielsweise einen Text in einem Textprogramm wie Word schreibt, ist zwar die Software gegen Überschreiben geschützt, nicht aber der Text, denn den muss man ja schreiben können.

Es hilft übrigens gegen Fehler des Betriebssystems auch nicht, ein Dateiverzeichnis read-only zu mounten, weil das Betriebssytem den ja wieder schreibbar mounten oder darunter durch schreiben könnte.

In der Forensik gilt das übrigens als Fehler, weil Betriebssysteme in der Regel auch auf read-only eingebundene Dateisysteme schreiben. Zum Beispiel, wann und so sie das letzte Mal eingebunden waren. Oder bei Dateisystemen mit Journal unerledigte Journaleinträge abarbeitet. Oder Fehler korrigiert. Deshalb ist sowas in der Forensik verboten und führt zur Unbrauchbarkeit von Beweisen. Da muss beim Anschluss von Festplatten zur Untersuchung mit einem Schreibschutzzwischenstecker gearbeitet werden, der jeglichen Schreibzugriff verhindert und sicherstellt, dass die Platte unverändert bleibt.

Externe Speichermedien

Anders sieht das aus, wenn man externe Speichersysteme anschließt, die über irgendein Protokoll angesprochen werden. Sicherheitstheoretisch (nach meinem Schema) ist das eine Übertragung im Raum, und das Laufwerk oder Medium stellt im Prinzip ein eigenes System der Systemsicherheit dar, das aber hier als nicht angegriffen gilt.

Wenn ich also ein CD-Laufwerk anschließe und eine gepresste CD-ROM/DVD oder eine beschreibbare aber abgeschlossene Scheibe reinstecke, bin ich sicher, weil kein Schreibzugriff möglich ist, sondern man nur Lesen kann. Anders bei wiederbeschreibbaren, da kann man natürlich den Inhalt ändern und zum Beispiel ausführbare Dateien infizieren oder Datendateien verschlüsseln.

Bei den angesprochenen SD-Karten (nicht nur die Adapter, sondern auch die Speicherkarten in Normalgröße haben so einen Schreibschutzschieber) ist es in der Tat so, dass der Schreibschutzschieber rein gar nichts bewirkt, weil er kein Schalter ist, sondern nur ein bewegliches Stück Plastik, wie der Schreibschutz damals bei den Disketten oder den Videokassetten, wer die noch kennt. Das ist im Prinzip nur ein einzelnes Speicherbit, das man mit dem Fingernagel schreiben kann. Der Kartenleser kann das über einen Schalter oder eine Lichtschranke abfragen. Manchmal wird das überhaupt nicht ausgewertet und hat gar keine Funktion, schützt überhaupt nicht. Manchmal wird es im Kartenleser ausgewertet, dann schützt es sehr gut, weil der Kartenleser das Schreiben verweigert. Und manchmal wird es im Betriebssystem ausgewertet, dann hilft es nur, solange das Betriebssystem sicher und nicht kompromittiert oder fehlerhaft ist. Kann zum Beispiel trotzdem zu den bekannten Schreibeffekten führen.

Es gibt in der IT-Sicherheit so eine Erzählung, dass sich mal irgendein Graphikbüro in die Pleite gefahren hat. Die hatten wohl alle Macs und wichtige Kundendaten, und sich dann irgendwas eingefangen, was die Daten geschrottet hat. Und zwar alle.

Dann dachten die sich, das ist ja kein Problem, wir haben ja einen Backup auf einer externen Platte. Dann hat man die an einen der Rechner angeschlossen, der aber auch verseucht war, und der die Festplatte dann auch gleich geshreddert (oder verschlüsselt) hat, und dann waren sie pleite.

Overlay-Mount

Hütet Euch davor, Euch darauf zu verlassen, dass ein Dateisystem read-only wäre. Selbst wenn es eine CD oder eine schreibgeschützte Festplatte ist, kann der Rechner dann, wenn er kompromittiert ist oder einen Fehler hat, oder sich der Admin was anderes gedacht hat, trotzdem schreiben können. Wenn er beispielsweise eine Kopie anfertigt. Einen Cache anlegt. Oder ein Overlay drüberlegt. Overlay heißt, dass man zwei oder mehr Dateisysteme übereinander einbindet, an derselben Stelle. Und dann schaut das Betriebssystem, wo es zuerst etwas findet. Man kann also beispielsweise über eine schreibgeschützte DVD noch ein RAM-Filesystem drübermounten, und dann sieht das plötzlich wie schreibbar aus und verhält sich auch so, weil das RAM-Filesystem nur noch die Änderungen aufnimmt. Ist bei vielen Linux-Systemen so, die als Live-System von der CD gemountet werden, die machen das fast alle so. Schreibgeschützt und trotzdem schreibbar.

Server-Systeme

Besser sind dann Server-Systeme, die die Daten verwalten und nur das machen, also viel schwerer anzugreifen sind, und auf denen man die Daten sichert und die ihrerseits wieder Backups produzieren (z. B. auf Band).

Aber auch da gilt: Wichtig ist das, was man durch seine Arbeit produziert, und wenn man das schreiben kann (muss man ja, um arbeiten und es speichern zu können), dann kann man auch Mist schreiben oder die verschlüsselten Daten.

Die falsche Frage und die richtige Antwort

Das, was ich bisher dazu gesagt habe, dürfte bei den meisten Lesern nun den Gedanken „Schön, hilft uns aber nicht weiter. Der schwätzt schlau daher, aber sagt nur, was alles nicht geht.“ (Machen Security-Heinis oft.)

Der Grund dafür ist einfach. Der Leser hat die falsche Frage gestellt.

Man muss zuerst den Angriff verstehen, bevor man nach dem Schutz fragt.

Klassischerweise hatte man früher mal so eine Dreiteilung von Sicherheitsanforderungen, nämlich Confidentiality, Integrity, Authenticity (abgekürzt CIA). wir hatten damals am Institut eine schöne deutsche Übersetzung, die sich zu KGB abkürzt (immer Lacher), kriege ich aber nicht mehr zusammen. Kommunikationssicherheit, Garantierte Übertragung, Beweisbare Identität oder so ähnlich.

Das reicht aber nicht, Computersteinzeit. Es kamen noch solche Dinge wie Non-Repudiation (Nichtbestreitbarkeit), Zero Knowledge (Nicht-Transitivität von Beweisen) oder Availability (Verfügbarkeit) hinzu.

Und das ist genau der Punkt, wir haben hier ein Problem der Verfügbarkeit.

Das Problem ist nicht, die Datenträger vor Schreiben zu schützen, denn Schreiben müssen wir können, sonst können wir nicht arbeiten. Sondern die Daten vor Löschen und Überschreiben zu schützen.

Und damit läuft man in ein Problem, weil normale Dateisysteme sowas nicht als Zugriffsrecht kennen. Es gibt da nur die Frage, ob man nur lesen oder auch schreiben darf, aber nicht, ob man das, was man geschrieben hat, wieder löschen oder überschreiben darf, wenn man gleichzeitig auch neue Daten schreiben können darf.

Und weil es so ein Dateisystem (meines derzeitigen Wissens) für den Allgemeingebrauch und allgemeinverfügbarer Software nicht gibt, ist zwangsläufig der Ansatz falsch, das Problem auf Dateisystemebene lösen zu wollen.

Wobei es schon Dateisysteme gibt, die sowas indirekt können, nämlich solche mit snapshots. ZFS, BTRFS, bei Windows und Mac weiß ich es jetzt nicht, welches was kann. Da könnte man beispielsweise täglich oder wöchentlich einen Snapshot anlegen. Eine Zwischensicherung. Ändert man dann was an einer Datei, beispielsweise eben die Verschlüsselung durch Ransomware, kann man trotzdem noch auf die Version im Snapshot zugreifen. Setzt natürlich voraus, dass man genug Plattenplatz hat, die regelnäßig macht und vor allem der Angreifer die snapshots nicht angreifen oder kompromittieren kann.

Oder man macht ganz ordinäre Bauern- und Diesel-Snapshots, auch unter dem schönen Namen Backups bekannt. Das elfte Gebot: Thou shalt make backups. Damit löst man die Probleme eigentlich generell, das sollte man eigentlich immer machen. Neulich hat sich mal irgendeine Uni damit geschrottet, weil die der Ransomware anheim fielen, alle Daten futsch, und dann wollten sie ihre Backup-Bänder wieder einspielen, hatten aber nicht bedacht, dass sie inzwischen ein neues Bandlaufwerk hatten, das dann die alten Bänder zu Salat verarbeitet hat. Alles weg. Man muss eine Menge können und machen, um ordentliche Backups zu produzieren. Vor 20 Jahren sagte mir mal einer von der Kriminalpolizei, dass sie bei Durchsuchungen in Firmen immer auch die neuesten Backups aus dem Schrank mitnehmen, weil die Leute gerne Daten löschen, wenn draußen die Polizei auffährt. In erstaunlich vielen Fällen erfahren dann die Firmen erst von der Polizei im Rahmen der Hausdurchsuchung, dass ihre Backups nicht funtionieren und die Daten nicht drauf sind, weil sie nie das Wiedereinspielen testen.

Auch die typischen Netzdateisysteme wie NFS, APS, SMB können das (nach meinem letzten, auch nicht mehr frischen Wissensstand) nicht, das Schreiben und das Überschreiben oder Löschen zu unterscheiden und unterschiedliche Rechte zu vergeben.

Wir haben ein Problem, wir kennen den Angriff und wir wissen, dass die verfügbaren Dateisysteme keine (einfache) Lösung dafür haben. (Es gibt Systeme, die Berechtigungsmonitore unterstützen, die könnten sowas, und ich bin jetzt nicht fit genug in Selinux, aber da könnte das auch gehen.)

Was man braucht ist etwas, was man Monitor nennt, ein System, das für jeden Dateizugriff prüft und entscheidet, ob der geht oder nicht. Und damit sind wir wieder im Bereich der Systemsicherheit, brauchen also ein separates System, einen Server.

Und dieser Server muss dafür sorgen, dass man ihn einbinden kann, und beliebig Dateien schreiben, damit man seine Arbeitsergebnisse dort ablegen kann, aber niemals bereits abgelegte Ergebnisse wieder löschen oder überschreiben.

Oder beispielsweise nur dann löschen oder überschreiben kann, wenn man sie innerhalb eines Zeitraumes x angelegt hat, beispielsweise nur innerhalb desselben Tages, damit höchstens ein Arbeitstag Arbeit verloren gehen kann.

Da fallen mir jetzt spontan zwei Herangehenweisen ein:

  • Man kann sich sowas selbst basteln, indem man ein Datensystem über einen gewöhnen Webserver wie Apache oder NGINX (bei NGINX dürfte es über dessen Rechteabfragesystem etwas leichter gehen, bei Apache kann man es über die API und Programmiersprachen im Server laufen lassen), per WEBDAV exportiert und auf den Anwendungsrechnern einbindet. Das ist zwar schnarchlangsam, aber ziemlich einfach zu implementieren. Wirft aber natürlich das Problem auf, wie man das macht, wenn man an einem Text über Tage oder immer wieder mal arbeitet.
  • Oder man verwendet ein Versionierungssystem, das genau das leistet. Jede geschriebene Datei erzeugt eine neue Version.

    Der Klassiker dafür sind die Versionierungsprogamme aus der Unix/Linux-Welt, das inzwischen führende ist GIT. Damit kann man das machen, dass man Dateien ändern und auch löschen kann, dabei aber immer neue Versionen erzeugt und immer auch auf die alten noch zugreifen kann, es also im Prinzip niemals überschreiben und löschen kann, sondern immer nur neue Versionen (also neue Dateien) anlegt.

    Vor 10 Jahren wollte ich aus exakt diesem Grund mal einer Rechtsabteilung, einem Rudel von Juristen, bei denen ich damals gearbeitet habe, nahebringen, ihre Verträge und so weiter nicht mehr per Mail hin und herzuschieben und jeden sein persönliches Durcheinander aus drölfzig Dateileichen verwalten zu lassen, weil dann keine Sau mehr weiß, was und wo die jeweils neueste Version ist, sondern sie als Windows-Nutzer dazu bewegen, Microsoft Sharepoint zu verwenden, das man damals im Betrieb hatte. Das war zwar schon ganz entsetzlich und eine gruslige Krücke, aber genau das konnte es. Man konnte das aus Word, Excel und so weiter direkt ansprechen, also ganz normal arbeiten, und so einstellen, dass jeder Schreibvorgang eine neue Version anlegt, man also niemals mehr eine bestehende Datei löschen oder verschlüsseln könnte. Man könnte es zwar, aber es würde nur zu neuen Versionen führen, die alten blieben zugreifbar. Man kann also immer auf die Version vor dem ransomware-Angriff zugreifen.

    Das hat ihnen nicht gefallen, das wäre nichts für Juristen. Sie arbeiten lieber wie mit Aktenhaufen auf ihrem Tisch. Irgendwann kam ich mal morgens rein, und ein Baum von einem sonst hochaggressiven Killeranwaltstypen saß am Tisch, Nerven am Ende, heulend, die anderen voller Mitleid um ihn herum. Einer derer, die von meinen Vorschlägen gar nichts gehalten hatte. Notebookplatte kaputt. Wieviel Arbeit kaputt? 2 Jahre. Kein Backup. Ja, ich hab’s Euch doch gesagt.

    Ein anderer kam an, und fragte, wie man Datenrettung betreibt. Seine Frau ist Lehrerin, hatte ihr gesammeltes erarbeitetes Lehrmaterial der letzten 20 Jahre auf einer Festplatte (in Worten: Eine) und sich die Daten versehentlich alle gelöscht. Ließen sich aber von einer Datenrettungsfirma alle wiederherstellen, weil ich sie davon abgehalten hatte, die Platte gleich mal wiederzuverwenden, um schnell neue Daten draufzuschreiben (und damit die ausgehängten alten Daten zu überschreiben). Ich habe ihn mal gefragt, wieviel sie zusammen im Jahr verdienen (ziemlich Anwalt plus Lehrerin), was eine externe USB-Platte kostete, und warum sie sich nicht wenigstens einmal im Jahr, besser einmal im Quartal, eine neue zur Sicherung kaufen und die irgendwo zuhause und an einem zweiten Ort lagern. Guckte mich an wie ein Auto.

    Die Sache hat einen Haken.

    Solche Versionierungen funktioneren nur wirlich gut, wenn sie inkrementell arbeiten, also nicht jedesmal eine neue Version komplett speichern, sondern nur die Änderungen zur vorangegangenen. Sowas funktionert ganz wunderbar, wenn man Quelltexte für Software verwaltet oder die Quelltexte für Dokumente, Bücher und so weiter, die man in LaTeX schreibt.

    Es funktioniert hundsmiserabel mit Programmen wie Word oder Excel oder anderen Sachen, die ihre Inhalte nicht als einfache Textdatei speichern. Weil dann jede Dateiversion den vollen Platz belegt. Schreibt man zwanzig Änderungen, braucht man zwanzigmal so viel Platz.

    Aber: Es geht. Und soweit ich mich erinnere, kann man unter Sharepoint auch einstellen, wieviele Versionen man speichern will.

    Da muss man etwas aufpassen. Wenn man beispielsweise immer nur die letzten 10 Versionen speichert, kann die Ransomware natürlich einfach 10 neue Versionen schreiben und dann ist auch alles weg.

    Aber man kann zum Beispiel nur die Major-Versionen dauerhaft speichern, und die Minor-Versionen nur für bestimmte Zeit. Und dann ab und zu mal oder besser regelmäßig ein Backup auf Bänder.

Das also ist die eine Antwort auf die falsch gestellt Frage. Das, was man selbst erarbeitet, gehört in ein sogenanntes Repository, in das man seine Arbeitsergebnisse einwerfen, sie dann aber nicht mehr löschen oder überschreiben, sondern nur versionieren kann.

Und das ist im IT-Bereich eigentlich auch Standard. Man erwartet das von Entwicklern, dass die abends oder zeitnah ihr Zeugs „einchecken“. Damit dann, wenn ihr Notebook abbrennt, geklaut wird, der ransomware anheimfällt, die Arbeitsergebnisse in Sicherheit sind.

Der andere Punkt ist die Software selbst, einschließlich der Systemkonfiguration.

Das gehört so gebaut, dass es jederzeit reproduzierbar ist. Dass also der Rechner jederzeit, schnell, zuverlässig, unter kontrollierten Bedingungen und in bekannter Zeit, neu installiert werden kann.

Im Prinzip muss das also alles so laufen, dass man im Fall eines Defektes, Diebstahls, ransomware, den Rechner einfach löscht, automatisch neu installiert, wieder auf sein versioniertes Repository zugreift und sich die Arbeitsdaten holt, und dann da weitermacht, wo man vor dem Angriff aufgehört hat.

Sowas geht.

Sowas wird auch gemacht.

Das ist kein Hexenwerk.

Aber in vielen Bereichen wird es eben nicht gemacht, weil es da einfach üblich ist, so auf Windows-Ebene vor sich hinzuknödeln wie besagter Rechtsanwalt, und dann zu heulen, wenn es kracht.

Man muss sich aber auch klarmachen, dass die Windows-Welt – obwohl ich oben als Beispiel Sharepoint genannt habe – dafür nicht so wirklich gut geeignet ist. Weil man halt auch einfach kauft und frisst, was Microsoft auf den Markt wirft, und weder befähigt noch in der Verhandlungsposition ist, Anforderungen ins Lastenheft zu schreiben, dass das System gewisse Resistenz gegen solche Angriffe aufbringen und die Sache wiederherstellbar machen soll.

Aber: Wenn mal wollte und befähigtes Personal hätte, dann ginge es.