© Achim Prill, 123RF

Angesichts hoher Festplattenpreise sind gebrauchte Disks ein Renner bei Ebay. Aber der Wert der unbedacht darauf hinterlassenen Daten ist oft viel höher als der Kaufpreis. Wer seine Platte nur formatiert, bevor er sie entsorgt, wähnt sich in trügerischer Sicherheit.

Wer eine alte Festplatte sicher entsorgen und vorher die Daten darauf endgültig löschen will, sollte gängige Anweisungen von Behörden oder Militär konsultieren. Doch beim Studium der Dokumente aus US-Institutionen erwacht auch im geduldigsten Admin schnell das Verlangen, zum Baumarkt zu fahren und dort nach einem Schweißbrenner oder einem extra starken Magneten zu fragen und seine Datenträger anschließend mit derlei destruktiver Hardware zu verwöhnen. Hohe Temperaturen und starke Magnetfelder sind Experten zufolge das einzige Mittel, um innerhalb kurzer Zeit Daten auf Festplatten zuverlässig zu löschen.

Oder 7- bis 35-mal überschreiben

Die Anweisungen legen dem sicherheitsbewussten Anwender nämlich nahe, seine Festplatten mehrfach zu überschreiben, die Empfehlungen von Gutman [1] oder des US-Militärs (Department of Defense, DoD 5220.22-M) sprechen von sage und schreibe sieben- bis 35-fachem Überschreiben mit unterschiedlichen Mustern als einzig sicherer Lösung.

Wer schon einmal eine 2-TByte-Festplatte gewipet hat, weiß, dass so ein Vorgehen dauert. Doch der Aufwand lohnt, behaupten Studien, die wahllos entsorgte Festplatten unter die Lupe nahmen und dabei Erschreckendes zu Tage gefördert haben (Tabelle 1). Dieser Artikel zeigt, wie viele Daten sich von vermeintlich gelöschten Datenträgern problemlos wiederherstellen lassen, und gibt Admins Tipps und Werkzeuge an die Hand, die ihre Festplatten gezielt und sicher löschen.

Aus zweiter Hand

Legendär ist in diesem Zusammenhang die Studie [2], die der heutige kalifornische Navy-Professor Simson Garfinkel [3] über die Entsorgungspraktiken von PC-Besitzern erstellte. In einem von ihm durchgeführten Experiment hat sich der Experte 158 Festplatten aus verschiedenen Secondhand-Quellen besorgt. Einige Disks, teilweise über Reseller bezogen, hatten die Vorbesitzer offensichtlich vorwiegend im Small-Business-Bereich eingesetzt. Der weitaus größte Teil stammte aber aus Ebay-Versteigerungen direkt von privaten Anwendern.

Von den Platten fertigte Garfinkel forensische Abbilder, die er mit simplen Linux-Bordmitteln wie den Kommandos »strings« oder »grep« auswertete. Mit erschreckendem Erfolg: Lediglich 9 Prozent der Festplatten befanden sich in einem Zustand, der keine Datenrekonstruktion mit Softwaretools ermöglichte. Auf 64 Prozent der Platten war entweder noch ein intaktes Dateisystem vorhanden, das sich direkt mounten ließ, oder die Vorbesitzer hatten die Platten nur formatiert, was es erlaubte, sie mit wenigen forensischen Kniffen wieder komplett zu rekonstruieren.

MBR löschen reicht nicht

Die Anleitung im Kasten “Übung mit USB-Stick” zeigt, dass auch der verbreitete Mythos, es reiche, die Partitionstabelle oder den ganzen MBR zu zerstören, schlichtweg falsch ist. Die richtigen Tools stellen alle Daten problemlos wieder her. Wer das selbst ausprobieren will, findet auf der DELUG-DVD das zum Testen geeignete Image eines USB-Sticks.

Garfinkel stellte außerdem fest, dass der Großteil der lesbaren Daten aus den üblichen Office-Anwendungen stammte (Tabelle 1). Auf 42 der Festplatten fand der Forensiker sogar Kreditkartennummern (CCNs).

Diese Daten eignen sich besonders gut für die Rohdatensuche mit geeigneten regulären Ausdrücken. Das Forensikprogramm Bulk Extractor [5] erledigt die Arbeit sehr komfortabel – weil automatisch – und sucht dabei auch gleich noch alle IP-, E-Mail- Adressen und Telefonnummern (Abbildung 1).

Abbildung 1: Fast immer findet Bulk Extractor allerlei Daten auf einer vermeintlich gelöschten Festplatte.

xmount --in ewf --out dd --cache /tmp/stick.ovl stick.E01 /ewf

losetup /dev/loop0 /ewf/stick.dd
dd if=/dev/zero of=/dev/loop0 count=1fdisk -lu /dev/loop0
Platte /dev/loop0: 977 MByte, 977534976UByte

sigfind -o 510 55AA /dev/loop0
Block size: 512  Offset: 510  Signature:U 55AA
Block: 61 (-)
Block: 62 (+1)
Block: 63 (+1)
Block: 67 (+4)
Block: 68 (+1)
Block: 69 (+1)

losetup -o $((61*512)) /dev/loop1 /dev/loop0mount /dev/loop1 /mnt

Bulk Extractor, Foremost und Sleuthkit

Als Testmedium für die Fähigkeiten von Bulk Extractor kann ebenfalls das Image des USB-Sticks von der DELUG-DVD dienen, der mit dem für USB-Sticks typischen FAT 32 formatiert ist. Bulk Extractor soll nun so viele sensible Informationen wie möglich wiederherstellen. Dafür arbeitet er zwar wie andere File Carver, sucht aber anhand eingebauter regulärer Ausdrücke nach den erwähnten Kriterien und listet diese zusammen mit dem ermittelten Offset auf, eine Gruppierung nach Häufigkeit in Histogrammdateien gibt es gratis dazu:

bulk_extractor /dev/loop0 -o bulk

Zur Rekonstruktion von Dateien setzt der interessierte Anwender oder Forensiker üblicherweise Tools wie Foremost [6] oder Scalpel [7] ein. Nach dem Bulk-Extactor-Lauf finden sich in »ccn.txt« Hinweise zu fünf Kreditkartennummern (Listing 1).

01 # Feature File Version: 1.1
02 2152094 378282246310005 class=CellBody>378282246310005</td></tr>\012<tr><
03 2152294 371449635398431  class=CellBody>371449635398431</td></tr>\012<tr><
04 2152504 378734493671000  class=CellBody>378734493671000</td></tr>\012<tr><
05 2152707 5610591081018250         class=CellBody>5610591081018250</td></tr>\012<tr><
06 2153481 6011000990139424         class=CellBody>6011000990139424</td></tr>\012<tr><

Da die Offsets sehr nahe beieinander liegen, ist zu vermuten, es handele sich um eine einzige Datei. Jetzt liefert »dd« Auskunft über den Inhalt der ersten 1000 Bytes nach dem ersten Offset (Listing 2). Diese CCN stammen aus einer öffentlichen Webseite mit Testnummern gängiger Anbieter. Doch die Histogrammdateien »url-histogram.txt« enthalten oft auch interessante Informationen über besuchte Webseiten (Listing 3).

Solange die Dateien unfragmentiert vorliegen, liefert Bulk Extractor brauchbare Ergebnisse, die Darstellung von benachbartem Text wird mit Hilfe von Dd und passendem Offset zum Kinderspiel, wenn auch zu einem langen: Bei den derzeit gängigen Festplattengrößen ist eine Wartezeit von einem kompletten Wochenende durchaus möglich.

Übersichtlichere Ergebnisse liefert in vielen Fällen das Forensiktool Foremost, weil es gleich komplette Dateien rekonstruiert. Doch Bulk Extractor kümmert sich dafür auch um den Slack-Bereich ([8], [9]). Noch genauer analysieren ihn Fsstat aus dem Sleuthkit [10] und Bmap [11] (Listing 4). Weil die Webseite des zweiten Tools [12] bis zum Redaktionsschluss nicht erreichbar war, haben die Autoren des Linux-Magazins Bmap statisch kompiliert und stellen es auf der DELUG-DVD zur Verfügung.

01 378282246310005</td></tr>
02 <tr><td rowspan="1" colspan="1" width="248px" class="whs4">
03 <p class=CellBody>American Express</td>
04 <td rowspan="1" colspan="1" width="363px" class="whs5">
05 <p class=CellBody>371449635398431</td></tr>
06 <tr><td rowspan="1" colspan="1" width="248px" class="whs4">
07 <p class=CellBody>American Express Corporate</td>
08 <td rowspan="1" colspan="1" width="363px" class="whs5">
09 <p class=CellBody>378734493671000</td></tr>
10 <tr><td rowspan="1" colspan="1" width="248px" class="whs4">
11 <p class=CellBody>Australian BankCard</td>
12 <td rowspan="1" colspan="1" width="363px" class="whs5">
13 <p class=CellBody>5610591081018250</td></tr>
14 <tr><td rowspan="1" colspan="1" width="248px" class="whs4">
15 <p class=CellBody>Diners Club</td>
16 <td rowspan="1" colspan="1" width="363px" class="whs5">
17 <p class=CellBody>30569309025904</td></tr>
18 <tr><td rowspan="1" colspan="1" width="248px" class="whs4">
19 <p class=CellBody>Diners Club</td>
20 <td rowspan="1" colspan="1" width="363px" class="whs5">
21 <p class=CellBo1000+0 Datensätze ein
22 1000+0 Datensätze aus
23 1000 Bytes (1,0 kB) kopiert, 0,003 s, 293 kB/s

01 # Histogram File Version: 1.1
02 n=6     http://feeds.feedburner.com/Regexlibcom-RecentPatterns
03 n=4     http://purl.org/dc/elements/1.1/
04 n=3     http://openoffice.org/2004/office
05 n=3     http://www.w3.org/1999/xlink
06 n=3     http://www.w3.org/2003/g/data-view#
07 n=2     http://aspadvice.com/lists/SignUp/list.aspx?l=68&c=16
08 n=2     http://aspalliance.com/
09 n=2     http://de.wikipedia.org/wiki/Liste_der_Postleitbereiche_Deutschland
10 n=2     http://de.wikipedia.org/wiki/Postleitzahl_%28Deutschland%29

01 FILE SYSTEM INFORMATION
02 --------------------------------------------
03 File System Type: FAT32
04
05 OEM Name: MSDOS5.0
06 Volume ID: 0x948335be
07 Volume Label (Boot Sector): NO NAME
08 Volume Label (Root Directory): HPMSTICK
09 File System Type Label: FAT32
10 Next Free Sector (FS Info): 5256
11 Free Sector Count (FS Info): 1903928
12
13 Sectors before file system: 61
14
15 CONTENT INFORMATION
16 --------------------------------------------
17 Sector Size: 512
18 Cluster Size: 4096
19 Total Cluster Range: 2 - 238179

Der Ausschuss: Slack

Der so genannte Slack resultiert aus der Aufteilung eines Dateisystems in Cluster: Beim Schreiben in eine Datei wird das Medium aus Listing 4 immer Vielfache von 4096 Bytes belegen. Ist eine Datei 19353 Byte groß, belegt sie fünf Cluster. Während die ersten vier komplett gefüllt sind, bleiben beim letzten noch 1127 Bytes frei. Ist das Dokument unter Libre Office mit Linux als Betriebssystem angelegt, finden sich lediglich 0x00 Pattern als Füllinformationen in diesem Restbereich (Slack).

Ein Windows-XP-Betriebssystem legt allerdings unter Umständen verräterische Informationen auch in diesem Bereich ab. Befinden sich im benachbarten Bereich des noch im Arbeitspeicher liegenden OO-Dokuments beispielsweise Bytes eines gerade geöffneten Mailclients, so greift das Betriebssystem ohne Rücksicht auf Verluste in den Arbeitsspeicher und holt sich ab Beginn des Dokuments 20480 Bytes, das heißt 1127 Bytes aus der benachbarten E-Mail, genug Platz für eine Mailadresse.

Für den Benutzer ist diese Information zwar komplett unsichtbar, sie verbleibt aber so lange im Slack-Bereich auf der Platte, bis die Originaldatei komplett überschreiben ist. Listing 5 zeigt, wie sich Datei-Slack mit Bmap auslesen, testweise beschreiben und verifizieren lässt.

01 # bmap --mode slack ccn.odt
02 getting from block 661
03 file size was: 19353
04 slack size: 103
05 block size: 512
06
07 # echo "Hier könnte etwas vertrauliches gespeichert sein" | bmap --mode putslack ccn.odt
08 stuffing block 661
09 file size was: 19353
10 slack size: 103
11 block size: 512
12
13 # bmap --mode slack ccn.odt
14 getting from block 661
15 file size was: 19353
16 slack size: 103
17 block size: 512
18 Hier könnte etwas vertrauliches gespeichert sein
19
20 # bmap --mode wipeslack ccn.odt
21 stuffing block 661
22 file size was: 19353
23 slack size: 103
24 block size: 512

Sicheres Löschen mit Convert and Copy und Dc3dd

Einfachste Abhilfe schafft der klassische »dd« -Befehl. Die landläufige Meinung, der Name des Programms laute “Disc Dump” oder “Disc Duplicate”, ist übrigens falsch. Die Manpage weiß es besser: “dd – convert and copy a file” steht da. Kein d, aber zwei c in der Auflösung? Eigentlich wäre die passende Abkürzung “cc”, aber die war schon für einen bekannten Compiler vergeben.

Noch besser als Dd eignet sich ein Fork mit dem Namen Dc3dd fürs sichere Löschen von Daten, weil er für den Anwender abschätzbar macht, wie lange der Durchlauf dauern wird – was Dd nicht leistet. Trotzdem fehlt immer noch eine komfortable Fortschrittsanzeige.

Zwar kennt Dc3dd die von Dd bekannten Argumente wie »if« und »of« , aber darüber hinaus auch Nützliches wie die Option »verb=on« . Die zeigt dem Anwender fortlaufend, was das Programm kopiert oder löscht, sowie die erreichte Übertragungsrate. Damit lässt sich über Hochrechnungen erschließen, wie lange das Löschen dauern wird. Allerdings legt das Tool gleich mal mit einer einigermaßen sportlichen Anfangsrate los und lässt dann stark nach, in der Regel auf ungefähr den halben Wert. Hochrechnungen sind erst sinnvoll, wenn sich die Rate stabilisiert hat.

Dc3dd befindet sich seit einiger Zeit in den Repositories für Debian und Ubuntu. Viele zusätzliche Funktionen erweitern die Möglichkeiten für den Anwender, zum Beispiel kann er mit »wipe=Gerät« eine Platte mit einem dedizierten Pattern »pat=Hexadezimal-Pattern« überschreiben. Eine Festplatte »/dev/sdb« füllt dementsprechend der Befehl

dc3dd wipe=/dev/sdb verb=on

mit lauter Nullen. Komplementäres Wipen mit den Bitfolgen »0x55« und »0xAA« erfolgt in zwei Durchgängen:

dc3dd wipe=/dev/sdb pat=0x55 verb=on
dc3dd wipe=/dev/sdb pat=0xAA verb=on

Doch – wie schon eingangs erwähnt – braucht dieser Vorgang einige Zeit. Für das Überschreiben einer 1-TByte-SATA-Festplatte, die die Tester einem handelsüblichen PC entnahmen, waren im Labor etwa vier bis sechs Stunden nötig.

Auch zur Erfolgskontrolle bietet sich ein Dd-Befehl an: »dd if=test.dd | xxd« sollte dem Anwender keine anderen Muster mehr ausgeben, als jenes, das er im vorherigen Befehl eingegeben hatte. Um die Datenflut auf dem Bildschirm und das damit verbundene Scrollen zu minimieren, lässt sich die Suche nach nicht gelöschten Bytes auch mit Awk und Grep filtern:

dd if=test.dd | xxd | awk '{print $2,$3,$4,$5,$6,$7,$8,$9}' | grep -v 0000

Softwaremäßig bleibt so schon nach einmaligem Wipen nichts mehr übrig. Ein teures Expertenlabor könnte eventuell noch Daten wiederherstellen, derartige Auswertungen stellen aber die absolute Ausnahme dar, die sich nur finanzkräftige Angreifer leisten.

Wipe, Shred und Journals

Doch Dd und Dc3dd sind nicht die einzigen Bordmittel zum Wipen von Speichermedien. Die Programme »wipe« und »shred« sind ebenfalls auf gängigen Distributionen vorinstalliert. Auch sie ermöglichen das sichere, unwiederbringliche Löschen von Verzeichnissen und sogar einzelnen Dateien.

Doch auch hier ist höchste Vorsicht angesagt: Die meisten modernen Dateisysteme nutzen Journale. Ausnahmen sind da FAT und FAT 32 oder Ext 2. Der Wipe-Vorgang kümmert sich aber nur um die Datei selbst, nicht aber um den Inhalt des Journals. Auch wenn danach erfolgende Schreibvorgänge alles wieder überschreiben, können Spuren bleiben, die beispielsweise Bulk Extractor ganz leicht findet. Ein simpler »string« Befehl mit dem Device als Parameter macht solche Rückstände jedoch schnell sichtbar.

Alles anders bei SSDs

Hohe Festplattenpreise und die in vielen Fällen bessere Performance der Solid State Discs (SSD) machen die elektronischen Speichermedien schon heute immer beliebter. Ein Performancetest aus der Juli-Ausgabe des Linux-Magazins [13] zeigt, dass bei der richtigen Wahl des Dateisystems die Festplatten nicht mehr mithalten können.

Doch ein großes Problem bleibt: Michael Wei und seine Kollegen widmen sich in einer Studie [14] dem Thema “Sicheres Löschen von SSDs” und kommen zu dem Schluss, dass die traditionellen Löschmechanismen von Festplatten bei Solid State Disks nicht mehr greifen. Die eingebaute Elektronik schreibt nämlich zugunsten einer längeren Lebensdauer des Speichers alle Schreibkommandos um und leitet diese beispielsweise auf bisher weniger benutzte Sektoren um.

Nur Hdparm nutzt Low-Level-Befehle wie ATA Secure Erase [15], um mit Kommandos wie »hdparm –user-master u –security-erase Passwort /dev/sdb« sicheres und gezieltes Löschen zu erreichen. Doch damit das klappt, muss auch das Bios mitspielen und es erlauben, ein Security Password auf der SSD zu setzen – was aber meist nicht der Fall ist. Dennoch könnte diese Methode dazu beitragen, auch auf SSDs kritische Spuren zu beseitigen. Aber leider unterstützen auch nicht alle Hersteller von SSDs diese Befehle. Das Ata-Wiki [15] ist auch dafür erste Anlaufstelle.

Schnell und kompromisslos

Wer nach einer komfortablen und schnellen Lösung sucht, um Platten zu wipen, wird Darik’s Boot And Nuke [16] schätzen. Hinter dem Kürzel DBAN steckt eine Linux-Live-CD (als ISO-Image auf der DELUG-DVD, Abbildung 2).

Doch Vorsicht ist geboten: Wer seinen PC von dieser CD bootet und im Bootprompt »quick« eingibt, löscht Festplatten ohne Rückfrage. Erschwerend kommt hinzu, dass DBAN alle erkannten Drives automatisch einbindet. Anstelle von »quick« kann der Anwender hier die Gutman- [1] oder die vom amerikanischen Militär (DoD) empfohlene eingangs erwähnte Methode auswählen.

Abbildung 2: Kurz, schmerzlos und bewährt: Darik’s Boot And Nuke alias DBAN löscht die ausgewählten Festplatten unwiederbringlich.

Bleachbit

Paranoide Anwender hören aber nicht beim Löschen der Festplatten auf, sondern benutzen auch noch Tools, die die vermeintlich flüchtigen Daten des Arbeitsspeichers entfernen, die mitunter ebenfalls sensible Daten enthalten. Um diesen Angriffsvektor auszunutzen, muss ein Angreifer aber erst einmal Zugriff auf ein laufendes System bekommen. Nichtsdestotrotz löscht der sicherheitsbewusste Admin mit dem Programm Bleachbit (Abbildung 3, [17]) auch die Daten in seinem RAM zuverlässig (Kasten “Auf der Flucht mit Bleachbit”).

Installieren lässt sich Bleachbit aus den gängigen Repositories, in den Menüs der Desktops landet es meist unter dem Eintrag »Systemwerkzeuge« . Aus einer Vielzahl von Möglichkeiten kann der Anwender dann auswählen, welche seiner vielen Spuren er entfernen will, die Funktionen reichen von Cookies über Festplatten-Wipes bis zur Browser-History.

Abbildung 3: Einfache Bedienung und viele Funktionen bringt das Universal-Löschtool Bleachbit, und zwar sowohl für Linux als auch auf Windows.

Fazit

Schon das Bordpersonal eines normalen Linux-Systems bietet genügend Möglichkeiten, Datenspeicher sicher zu löschen, bevor sie der Admin in die Tonne tritt oder meistbietend versteigert. Auch die Erfolgskontrolle lässt sich mit Standardtools der Bash automatisieren. Die stundenlange Wartezeit verliert damit einigen Schrecken. Wer sich nicht an die Kommandos wagt oder einfach lieber ein GUI bedient, greift zu DBAN.