Pentagrid AG (Einträge über Information Disclosure)

Shreddy2 – Ein Raspberry Pi als Löschstation für USB-Sticks

Pentagrid AG — Mon, 20 Dec 2021 05:12:21 GMT

"Delete early, delete often" ist das leicht abgewandelte Motto, dass daran erinnert, Datenlecks durch verlorene oder gestohlene USB-Sticks mittels regelmäßigem Löschen zu minimieren. Sind Sie es leid, beim Formatieren eines USB-Sticks auf Ihrem lokalen Computer darauf zu achten, nicht versehentlich das falsche Gerät zu löschen? Um den Vorgang zu vereinfachen, haben wir eine USB-Löschstation als Software auf einem Raspberry Pi implementiert. Die Software wartet drauf, dass ein USB-Stick angeschlossen wird. Der wird dann bereinigt. Also: shreddy, ready, go!

Warnhinweis

Zunächst einmal sollten sensible Informationen nicht ungeschützt auf mobilen USB-Sticks gespeichert werden, vor allem dann nicht, wenn die Gefahr besteht, dass sie verloren gehen. Es ist daher immer eine gute Idee, Daten vor dem Speichern zu verschlüsseln oder einen USB-Stick mit Verschlüsselungsfunktion zu verwenden, der man vertrauen kann oder noch besser, die verifiziert wurde. Nichtsdestotrotz werden viele Daten auf USB-Sticks gespeichert. Wenn diese nicht regelmäßig gelöscht werden, sammelt sich ein Informationsberg, der, auch wenn einzelne Dateien weniger sensibel sind, in der Menge viel über interne Aktivitäten oder persönliche Angelegenheiten preisgeben kann. Daher verringert das regelmäßige Löschen von USB-Sticks die Auswirkungen im Falle eines Verlustes.

Löschen von Flash-Speichern

USB-Sticks nutzen Flash-Speicher. Werden Informationen darauf gelöscht, werden die Daten zunächst nicht wirklich gelöscht. Dateiinhalte können oft auf der Ebene des Dateisystems wiederhergestellt werden, insbesondere bei FAT-Dateisystemen, die auf USB-Sticks weit verbreitet sind. Ein Wiederherstellen ist solange möglich, wie Verwaltungsinformationen und Dateiinhalte nicht überschrieben werden. Aber selbst bei teilüberschriebenen Dateien können noch genügend extrahierbare Informationen erhalten bleiben. Früher wurden Dateien auf Magnetplatten mit speziellen Löschprogrammen mehrfach überschrieben, um eine Wiederherstellung zu verhindern oder zu erschweren. Während dies bei magnetischen Festplatten gut funktioniert, funktioniert dieser Ansatz bei Flash-Speichern nicht. Der Flash-Speicher-Controller versucht, Schreibvorgänge über den Flash-Speicher zu verteilen, sodass eine gleichmäßige Schreibbelastung der Speicherzellen erzielt wird. Diese Methode wird als Wear-Levelling bezeichnet und verlängert die Lebensdauer eines Speichermediums. Dieses Wear-Leveling verhindert jedoch, eine einzelne Datei einfach zu überschreiben. Beim Versuch eine Datei mehrfach zu überschreiben würden zwar mehrere Regionen innerhalb des Flash-Speichers überschrieben werden, nicht notwendigerweise aber die Speicherzellen, an denen der ursprüngliche Dateiinhalt gespeichert war. Außerdem hält der Flash-Speicher-Controller zusätzlichen Speicherplatz als Ersatz für ausfallende Speicherzellen vor. Wurde der Dateiinhalt an eine solche nun nicht mehr nutzbare Stelle geschrieben, kann er ohne Low-Level-Zugriff auf den Flash-Speicher nicht mehr überschrieben werden.

Was ist also der richtige Weg, um einen USB-Speicherstick zu löschen? NIST SP 800-88 Rev. 1 "Guidelines for Media Sanitization" empfiehlt das folgende Verfahren zum Löschen von USB-Wechselmedien (einschließlich sogenannter Pen Drives, Thumb Drives, Flash Memory Drives, Memory Sticks usw.):

Datenträger werden mit organisatorisch genehmigten und getesteten Überschreibtechnologien/-methoden/-tools überschreiben. Das Überschreiben sollte mindestens zwei Durchgänge umfassen, und dabei ein Muster im ersten Durchgang und sein Komplementärmuster im zweiten Durchgang verwenden. Es können zusätzliche Durchgänge verwendet werden.

Das NIST fügt jedoch auch als Hinweis hinzu: "In den meisten Fällen, in denen eine Bereinigung gewünscht ist, sollten USB-Wechselmedien vernichtet werden." Das ist die Empfehlung, um auf Nummer sicher zu gehen.

Für weniger kritische Daten und Datensammlungen kann jedoch ein einfacher Überschreibansatz mit mehreren Durchgängen ausreichend sein. Da das Überschreiben einer einzelnen Datei aufgrund der Art und Weise, wie der Flash-Speicher verwaltet wird, prinyipbedingt kein Überschreiben darstellt, bleibt als Ansatz ein mehrfaches vollständiges Überschreiben, um das Risiko von Datenrückständen erheblich zu verringern. Wei et al. beobachteten in ihren praktischen Wiederherstellbarkeitstests:

In den meisten Fällen reichte das zweimalige Überschreiben des gesamten Datenträgers aus, um den Datenträger zu säubern, unabhängig vom vorherigen Zustand des Laufwerks. Es gab drei Ausnahmen: Etwa 1 % (1 GB) der Daten blieb auf Laufwerk A nach zwanzig Durchläufen übrig. Wir testeten auch eine kommerzielle Implementierung des 5220.22-M-Standards mit vier Durchläufen auf Laufwerk C. Für den Fall der sequentiellen Initialisierung entfernte sie alle Daten, aber bei der zufälligen Initialisierung blieb ein einzelner Fingerabdruck (Anmerkung: zuvor wurden auf dem Datenträger Testdaten verteilt) übrig.

Mit anderen Worten: Es gibt keinen wirklich korrekten Weg der sicheren Datenlöschung, außer die Daten nicht außerhalb eines Verschlüsselungscontainers zu verarbeiten oder den Datenträger physisch zu zerstören. Sagen Sie uns nicht, Sie seien nicht gewarnt worden. Trotzdem haben wir ein Tool erstellt, wenn Sie versuchen möchten, Daten zu löschen.

Software

Wir haben eine Software in Python implementiert. Diese nutzt die Bibliothek py-udev für das Monitoring von entsprechenden USB-Events. Die Speichermedien werden dann in drei Durchgängen überschrieben: Der erste und zweite Durchgang verwenden den Befehl badblocks, um die komplementären Muster 0x00 und 0xff zu schreiben. Der badblocks-Befehl ist eigentlich nicht für das Überschreiben von Daten gedacht. Dies ist jedoch ist ein Nebeneffekt beim Prüfen des Speichers auf beschädigte Bereiche. Wir verwenden das Programm hier, weil es die Angabe eines expliziten Schreibmusters erlaubt. Das Überschreiben des Blockgeräts in einem dritten Durchgang wird durch den Aufruf des shred-Befehls im Zufallsmodus umgesetzt. Das Überschreiben des Speichers mit Zufallsdaten soll den Aufwand für die Suche nach extrahierbaren Datenresten erhöhen. Anschließend legt die Software ein neues FAT-32-Dateisystem an. Dazu nutzt das Programm parted und mkfs.

Die Software kann auf einem Raspberry Pi installiert werden, der in einem Büro in einer vertrauenswürdigen Umgebung platziert wird. Nutzerinnen und Nutzer können ihre benutzten USB-Sticks anstecken und später wiederkommen, um sie abzuholen. Dies kann ein eigenes Sicherheitsproblem darstellen. Nochmals, Sie wurden gewarnt.

Die Software implementiert zwei Methoden, um über den Status zu informieren. In einem Netzwerkmodus hat die Löschstation Netzwerkschnittstelle, über die mittels netcat oder telnet Statusinformationen abgefragt werden können (siehe Screenshot). Da der Netzwerkmodus einem möglicherweise kompromittierten Raspberry Pi erlaubt, den Inhalt des USB-Sticks auszulesen und Daten an einen Angreifer auszuleiten, könnte der Raspberry Pi alternativ in einem Funkschnittstellen blockierenden Metallgehäuse und ohne Ethernet betrieben werden. Die zweite Methode der Statussignalisierung ist ein am Raspberry Pi angebrachtes USB-Busylight. Solange ein Löschvorgang läuft, leuchtet das Busylight rot, ein rotes Blinken meldet einen Fehler, und ein grünes Licht bedeutet, dass alle eingesteckten USB-Sticks verarbeitet wurden. Im Leerlauf, wenn kein USB-Speicherstick eingesteckt ist, spart das Busylight Energie und ist aus. Die Software unterstützt derzeit Busylights von Kuando über die Python-Bibliothek pyBusylight.

Der Quellcode ist auf Github verfügbar. Dort ist auch die Installationsanleitung zu finden.

Block browser requests to Google during security analysis in Burp

Pentagrid AG — Wed, 04 Nov 2020 09:00:00 GMT

How to stop Portswigger's Burp Proxy's built-in Chromium browser to leak information to Google's Safe Browsing during a web application penetration test?

When doing web application security research and penetration tests for customers, we sometimes get insights into tools we use that seem weird and undesired. A while ago we were testing a financial website with confidential data with the Mozilla Firefox browser and Firefox was sending the following requests whenever we downloaded a PDF from the website:

POST /safebrowsing/clientreport/download?key=%GOOGLE_SAFEBROWSING_API_KEY% HTTP/1.1
Host: sb-ssl.google.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:70.0) Gecko/20100101 Firefox/70.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/octet-stream
Content-Length: 189
Connection: close

blob:https://www.example.org/6f75423b-3828-5e4b-8241-3e633c684041___________
Dblob:https://www.example.org/6f75423b-3828-5e4b-8241-3e633c684041___
txt_download_name_file_overview.pdf
[...]

As you can see, Firefox leaks the PDF file name we were downloading, the hostname of the website we were testing and some more binary data that could include a file hash. On one side we were happy that we found this privacy issue and could report it to our customer, because this browser behaviour affects normal users. On the other side we do not want our testing tools to behave like this. Safebrowsing can be disabled via the pentest browser's settings menu or by setting these values in about:config and it must be done for every web application test browser in use:

browser.safebrowsing.malware.enabled = false
browser.safebrowsing.phishing.enabled = false

In the meantime the Portswigger Burp proxy we use regularly and write extensions for was updated to include a new feature: A builtin Chromium browser. We really appreciate the added usability and were happy to use this feature in a security analysis in a corporate Windows AD environment, where changing proxy settings was not allowed for the preinstalled browser. Fortunately because we asked our customer to install Burp with administrative privileges, the built-in Chromium browser of Burp could be used. However, we noticed that the preconfigured Chromium browser was again very verbose and contacted Google servers, especially during startup. As we would like to keep all information about our security analysis to our customers and ourselves, we avoid any third-party services wherever feasible. That's why we operate and use our own Burp Collaborator server, for example.

It is possible to disable the Safe Browsing feature in the browser used to perform web application pentests. However, if it is necessary to switch the browser, these settings must be changed there as well and the approach does not really work for the the built-in Chromium browser, because its settings are reset on every start. The easiest solution is to control traffic in the Burp Proxy: We can abuse the Upstream-Proxy setting found in "User options - Connections" in Burp for this purpose. While the following approach will block the requests from reaching the Google servers, they will still show up in the history tab of Burp.

Download google-blocking.json.
In Burp, go to "User options - Connection".
On the left of the "Upstream Proxy Servers" headline, click the settings and chose "Load options".
Chose the file you just downloaded and press "OK". Then, the upstream proxy settings look like in the screenshot below.

This configuration will redirect requests to most Google domains to TCP port 1337 on localhost, which is (hopefully) a dead end. It is possible to use the file as a Burp startup configuration, or even better, merge it with your existing startup configuration by editing the Burp settings JSON file manually. Then, your are able to use these Burp settings in new projects as well.

A drawback of the approach is that your test browser cannot be used for Google searches afterwards and it may break functionality if the tested sites requires resources from Google of course. However, it is recommended to use separate browsers for regular work and for web application testing anyway, because they are configured for different purposes.