Software Sandboxing

In den letzten Themen ging es darum, Schwachstellen im Code möglichst zu verhindern: Eingaben prüfen, Ausgaben sicher kodieren, Fehler sauber behandeln und speicherbezogene Angriffe vermeiden. Das ist die erste Verteidigungslinie. Trotzdem bleibt eine realistische Frage: Was passiert, wenn trotz aller Schutzmaßnahmen doch eine Schwachstelle ausgenutzt wird? Genau hier kommt Sandboxing ins Spiel.

Bei NovaHealth läuft im Patientenportal viel fremder oder schwer kontrollierbarer Code: JavaScript im Browser, externe Bibliotheken, vielleicht sogar Dienste und Dateien, die von Patienten oder Partnern hochgeladen werden. Eine Sandbox sorgt dafür, dass ein kompromittierter Prozess nicht sofort das gesamte System mitnimmt.

„Heißt Sandboxing einfach, dass man einem Programm nicht mehr komplett vertraut, selbst wenn es eigentlich laufen darf?“

„Genau. Das Programm bekommt nur den Bereich und die Rechte, die es wirklich braucht. Wenn darin etwas schiefgeht, bleibt der Schaden begrenzt“

Sandboxing bedeutet, dass ein Prozess, eine Anwendung oder ein Stück Code in einer abgegrenzten Umgebung ausgeführt wird. Diese Umgebung legt fest, worauf der Code zugreifen darf: Dateien, Netzwerk, Speicher, Geräte, andere Prozesse oder Systemfunktionen. Alles, was nicht ausdrücklich erlaubt ist, bleibt außerhalb der Reichweite. Der Code darf arbeiten, aber nicht überall hin.

Sandboxing im Alltag

Ein typisches Beispiel ist der Browser. Moderne Browser führen Webseiten in getrennten Prozessen aus. Ein einzelner Tab soll nicht ohne Weiteres auf lokale Dateien, Passwörter, andere Tabs oder das Betriebssystem zugreifen können. Das ist wichtig, weil dein Browser ständig fremden Code ausführt. Jede Webseite bringt HTML, CSS und JavaScript mit. Ohne Isolation wäre jeder Webseitenbesuch deutlich riskanter.

Auch mobile Betriebssysteme nutzen Sandboxing. Auf iOS und Android läuft jede App grundsätzlich in ihrem eigenen Bereich. Eine App darf nicht einfach die Daten einer anderen App lesen. Zugriff auf Kamera, Kontakte oder Standort muss separat erlaubt werden. Das schützt nicht vor jeder bösartigen App, begrenzt aber den Schaden deutlich.

Im Kontext der sicheren Anwendungsentwicklung ist Sandboxing vor allem eine Architekturentscheidung.

Schon während der Planung sollte klar sein, welche Anwendungsteile getrennt laufen, welche Rechte sie brauchen und welche Verbindungen erlaubt sind. Das betrifft Code, der fremde Inhalte verarbeitet, Datei-Uploads prüft, externe Bibliotheken nutzt oder eigene Dienste wie API, Worker und Frontend trennt. Sandboxing ergänzt sichere Programmierung: Wenn trotz Validierung, Authentifizierung und sauberer Fehlerbehandlung etwas kompromittiert wird, begrenzt die Sandbox den Schaden.

Container als Sandbox

Ein wichtiger Einsatzbereich sind Container. Ein Container bündelt eine Anwendung mit den benötigten Bibliotheken, Konfigurationsdateien und Laufzeitabhängigkeiten. Er bringt aber kein eigenes vollständiges Betriebssystem mit. Er läuft als isolierter Prozess auf dem Host.

Diese Isolation ist für NovaHealth praktisch. Das Patientenportal, die Laborergebnis-API und ein Dienst für Benachrichtigungen können getrennt voneinander betrieben werden. Wird der Benachrichtigungsdienst kompromittiert, darf der Angreifer dadurch nicht automatisch auf die Labor-API, Datenbankdateien oder andere Prozesse des Hosts zugreifen.

Container trennen dafür mehrere Bereiche voneinander:

• Prozesse: Der Container sieht nur die Prozesse, die zu ihm gehören.
• Dateisystem: Die Anwendung bekommt ein eigenes Dateisystem mit genau den Dateien, die sie benötigt.
• Netzwerk: Dienste können eigene Netzwerkbereiche und gezielte Verbindungen erhalten.
• Ressourcen: CPU, Arbeitsspeicher und Dateizugriffe können begrenzt werden.
• Berechtigungen: Linux-Capabilities können reduziert werden, damit ein Prozess nicht mehr darf als nötig.

Wichtig ist die Grenze dieser Isolation. Container sind keine vollständigen virtuellen Maschinen. Sie teilen sich den Kernel des Host-Systems. Wenn der Container zu viele Rechte bekommt und als root läuft oder sensible Dateien lesen/schreiben darf, kann potenziell aus dem Container ausgebrochen werden.

Das lässt sich unter Linux recht einfach prüfen.

Der Container und der Host teilen sich denselben Kernel:

└─$ uname -r
6.11.2-amd64

└─$ sudo docker run --rm alpine uname -r
6.11.2-amd64

Es ist im Container und auf dem Host derselbe Prozess:

Wenn der Container entsprechend gestartet wird, darf er Dateien auf dem Host lesen und schreiben:

Deshalb sollte ein Container bewusst gehärtet werden:

• Container mit einem nicht privilegierten Benutzer starten, nicht als root (wie hier im Beispiel…).
• Das Dateisystem möglichst read-only betreiben und nur notwendige Schreibpfade freigeben.
• Netzwerkzugriffe konkret begrenzen, zum Beispiel Labor-API nur zur Datenbank.
• Images klein halten, regelmäßig aktualisieren und auf bekannte Schwachstellen prüfen.
• Secrets nicht im Container Image speichern, sondern über eine Secret-Verwaltung bereitstellen.
• Ressourcenlimits setzen, damit ein fehlerhafter Dienst nicht den gesamten Host blockiert.

Sandboxing in der Sicherheitsanalyse

Sandboxing spielt auch in der Analyse von verdächtigen Programmen eine wichtige Rolle. Dateien die unter Schadsoftwareverdacht stehen, dürfen natürlich nicht direkt auf einem produktiven System geöffnet werden, sondern in einer isolierten Analyseumgebung. Das betrifft zum Beispiel auch E-Mail-Anhänge, heruntergeladene Programme oder Dateien aus einem Incident.

In einer solchen Analyseumgebung wird beobachtet, was die Datei macht:

• Welche Prozesse werden gestartet?
• Welche Dateien werden erstellt oder verändert?
• Welche Registry-Einträge werden gesetzt?
• Welche Netzwerkverbindungen werden aufgebaut?
• Werden weitere Dateien nachgeladen?

Werkzeuge wie Cuckoo Sandbox, Any.run oder Hybrid Analysis helfen dabei, dieses Verhalten sichtbar zu machen. Auch Secure Email Gateways nutzen solche Verfahren. Ein verdächtiger Anhang wird vor der Zustellung in einer Sandbox ausgeführt. Zeigt er Schadverhalten, wird die E-Mail blockiert.

Wer viel mit Microsoft Outlook in Office356 arbeitet, wird vermutlich schon einmal gesehen haben, dass Mail-Anhänge nicht sofort durchgestellt werden. Je nach Größe und Datei, hängen sie einige Zeit in einer Prüfung fest. Hier wird beschrieben, wie genau diese Prüfung stattfindet. Dazu gehört auch, dass in „Phase 3: Inhaltsfilterung“ der Inhalt der Mail in einer Sandbox ausgeführt wird. Das gilt ebenfalls für verdächtige Links in der Mail, die in einer Browser-Sandbox geöffnet und geprüft werden.

Das folgende Bild zeigt beispielhaft, welche in der Sandbox vom Programm durchgeführten Aktionen als verdächtig eingestuft werden. Wenn es sich um echte Malware handelt, ersetzen diese Tools allerdings keine vollwertige Analyse. Es geht hier nur um eine isolierte Ausführung und erste Indikatoren, was das verdächtige Programm tut. Die ganze im Beispiel gezeigte Ausgabe von Hybrid Analysis ist hier zu finden.

Grenzen von Sandboxing

Wichtig ist dabei: Sandboxing ist eine Begrenzung, kein perfekt sicheres Allheilmittel. Es gibt Sandbox Escapes, also Schwachstellen, mit denen Code aus der Sandbox ausbrechen kann. Außerdem gibt es technisch fortgeschrittene Malware die prüfen kann, ob sie in einer Analyseumgebung läuft. Typische Hinweise sind fehlende Mausbewegungen, sehr kurze Laufzeiten, bekannte VM-Treiber, wenige installierte Programme oder auffällige Hostnamen.

Erkennt Malware eine Sandbox, bleibt sie manchmal absichtlich unauffällig. Sie startet dann erst später, wartet auf Benutzeraktivität oder aktiviert ihre eigentliche Funktion nur auf echten Systemen. Der einfachste Fall ist ein „sleep“ einzubauen, das so lange wartet bis die Sandbox meldet, dass nichts verdächtiges passiert ist. Deshalb muss Sandboxing immer mit weiteren Maßnahmen kombiniert werden, die wir bereits an einigen Stellen ausführlich besprochen haben: Härtung, Rechtebegrenzung, Monitoring, Patch-Management und sichere Standardkonfigurationen.

Vereinfacht gesagt: Sandboxing reduziert den Schaden, wenn Code sich falsch oder bösartig verhält. Sie verhindert nicht jede Schwachstelle, aber sie kann dafür sorgen, dass aus einem einzelnen kompromittierten Prozess nicht sofort ein kompromittiertes System wird.