Einige Leser werden sich sicherlich noch an unsere Analyse der .git-Verzeichnisse in den Alexa Top 1 Millionen erinnern. Mit Hilfe unserer Tools kann man auch verborgen geglaubte Verzeichnisse (ohne Directory-Listing) auslesen und analysieren. Einen ähnlichen Ansatz haben wir nun für die .DS_Store-Datei entwickelt und wollen das Vorgehen und die Gefahren in diesem Blogpost vorstellen und aufzeigen, wie wir mit dieser Methode an sensitive Dateien hätten gelangen können. Darüber hinaus erläutern wir mögliche Schutzmaßnahmen.

Was ist die “.DS_Store-Datei”?

Beschäftigen wir uns also zunächst einmal mit der Datei “.DS_Store”. Einigen Personen wird diese sicherlich bekannt sein, wenn man einem Apple-Nutzer den USB-Stick ausgeliehen hat, denn betrachtet man den Inhalt des Sticks anschließend auf einem Windows-System oder einem Linux System, dann findet man dort, unter anderem meist eine Datei mit dem Namen “.DS_Store”. Der Dateiname steht für “Desktop Services Store” und in dieser Datei werden Informationen über die in einem Ordner enthaltenen Dateien und deren Anzeigeoptionen gespeichert, etwa die Position der Datei oder Kommentare zur Datei. Unter Mac-OS basierenden Betriebssystemen erstellt der “Finder” diese Datei automatisch, sie enthält zur Verwaltung der Dateien ihre Namen. Um die Datei vor dem Nutzer zu verstecken, wird wie bei vielen *NIX-ähnlichen Betriebssystemen ein Punkt dem Dateinamen vorangestellt. Das Format dieser Datei ist propäritär und wurde von Apple selbst entwickelt. Folglich werden die Dateien auch standardmäßig nur von Apple Geräten interpretiert. In dem Blogpost “The origins of .DS_Store” aus dem Jahre 2006 von einem der Erfinder der “.DS_Store”-Datei beschreibt dieser, dass er nachträglich einen anderen Namen wählen würde und zudem die Verbreitung der Datei massiver ist, als ursprünglich geplant. So kommt es laut seiner Aussage dazu, dass die Datei erstellt wird, sobald man einen Ordner betrachtet - geplant sei allerdings gewesen, dass die Datei nur erstellt werden soll, sofern die Ordneransicht geändert wird. Bis heute findet sich die Datei auf zahlreichen Festplatten. Nun könnte man glauben, dass diese Datei harmlos sei und bloß ein Abfallprodukt von der Nutzung durch einen Apple Rechner. Betrachtet man eine “.DS_Store”-Datei in einem Editor, so scheint zunächst auch nichts spannendes mit ihr möglich zu sein:

Wie einigen bekannt oder aufgefallen sein wird, handelt es sich um eine Binärdatei. Weil eine detaillierte Beschreibung des Dateiformats für diesen Blogpost zu umfangreich wäre, hat Sebastian auf seinem Blog einen einzelnen Blogpost dazu geschrieben.

Wieso kann die Datei zu einem Problem werden?

Diese Datei kann zu einem Sicherheitsproblem werden, wenn diese vom lokalen Dateisystem eines Nutzers in andere Hände fallen. Beispielsweise durch einen Upload einer Webseite vom Entwicklersystemauf einen Webserver. Gelangt ein Angreifer an diese Datei, weil der Webserver den Download nicht verhindert und zuvor ein Upload stattgefunden hat, so kann er gegebenenfalls Rückschlüsse auf weitere auf dem Server vorhandene Dateien ziehen. Wir wollten wissen, ob sich diese Methode tatsächlich so leicht umsetzen lässt wie gedacht, haben deshalb einige Nachforschungen betrieben und möchten unsere Beobachtungen im Folgenden schildern.

Als Grundlage für unsere Untersuchung, nahmen wir einen Export der Alexa Top 1 Millionen Webseiten. Sollten wir die .DS_Store Datei auf diesen Webseiten finden können, so wären einige der weltweit meistbesuchten Webseiten potentiell gefährdet. Basierend auf Sebastians Bibliothek zum Parsen der Datei in der Sprache “Go”, entwickelte er ein Tool, um die Existenz der Datei auf dem Server zu prüfen. Während dem letzten Hackercongress (34C3) in Leipzig nutzen wir dort die schnelle Internetanbindung, um innerhalb der vier Tage des Kongresses alle Webseiten auf diese Schwachstelle hin zu untersuchen.

Das Vorgehen

Dabei ging das Tool wie folgt vor:

• HTTP GET-Anfrage von http://domain.tld/.DS_Store
• Parsen der Datei und Extrahieren von Dateinamen
• Im rekursiven Modus: Prüfung, ob der Dateiname ein Ordner ist und ob in diesem Ordner wieder eine .DS_Store Datei abrufbar ist.
• Für alle gefundenen Dateipfade: HTTP HEAD-Anfrage zur URL, um die Abrufbarkeit festzustellen

Den Scandurchlauf haben wir im rekursiven Modus durchgeführt, weil viele interessante Dateien häufig nicht auf der ersten Dateiebene liegen. Allerdings liegt in jedem Unterordner oft wieder eine .DS_Store-Datei, was einen tieferen Einblick in die Verzeichnisse ermöglicht. Das Parsen der Dateien und die daraus resultierende Liste mit Dateinamen ermöglichte uns noch nicht die Aussage, ob diese Dateien auch wirklich auf dem Webserver existieren und potentiell heruntergeladen werden können. Wir erinnern uns - die Informationen aus der .DS_Store Datei beziehen sich auf die lokale Umgebung des Mac-Betriebsystems. Um der Frage, ob die Dateien auch online wiederzufinden sind, auf den Grund zu gehen, wurde zu jeder gefundenen Datei eine HEAD-Anfrage geschickt. Mit diesem HTTP-Anfragentyp schickt der Webserver nur die Header der Antwort zurück, jedoch nicht den Inhalt der Datei. Zwar ist diese Methode nicht perfekt, weil manche Webserver statt HTTP-Antwort “Nicht gefunden” (404) auch “OK” (200) zurückgeben, oder die HEAD-Anfragemethode deaktiviert ist, aber so kann man uns später nicht vorhalten, dass wir auf sensitive Inhalte zugegriffen hätten. Bei einem Antwortstatuscode von 200 nahmen wir die Existenz der Datei an und darauf basieren die folgenden Ergebnisse, wenn nicht anders angegeben.

Die Ergebnisse

Die Ergebnisse haben wir in Log-Dateien festgehalten. Von 1 Millionen abgescannten URLs haben circa 10000 Domains eine “.DS_Store”-Datei zum Download angeboten. Zunächst waren wir etwas enttäuscht, da wir von einer etwas größeren Verbreitung ausgegangen sind, allerdings stellte sich heraus, dass wir auch mit dem vorliegenden Datensatz einige interessante Rückschlüsse ziehen konnten. Einige Funde sind uns möglicherweise entgangen, weil der Parser nicht alle Dateien erfolgreich auslesen konnte. Insgesamt enthielt unsere Logdatei 1185671 gefundene URLs (auf Grund der angewandten Rekursion), die sich durch die Analyse der .DS_Store Dateien ergab.

Die HTTP-Antwortstatuscodes der HEAD-Anfragen verteilen sich wie folg:

Ein Großteil der gefundenen Dateien war potentiell abrufbar. Bei etwas mehr als 21000 URLs konnte der Status nicht ermittelt werden. Die verbleibenden Statuscodes deuten eher daraufhin, dass die Dateien nicht abrufbar (403 - Forbidden) oder nicht mehr vorhanden (404 - not found) waren. Die Häufigkeit einer gefundenen Datei war nicht gleichverteilt, sondern einige größere Webseiten schienen in vielen Verzeichnissen die .DS_Store Datei zu haben. Wenn ein Administrator oder ein Entwicklerteam die .DS_Store also “vergessen” hatte, so ist dies gleich mehrfach geschehen, was teilweise eine weitreichende Einsicht in die Inhalte von Webserververzeichnisse ermöglicht. In der folgenden Auflistung sieht man die Top 10 der Funde pro Domain (diese wurden hier aus Gründen der Sicherheit anonymisiert):

1
2
3
4
5
6
7
8
9
10

  80957 domain1.tld
  67754 domain2.tld
  55143 domain3.tld
  19688 domain4.tld
  19520 domain5.tld
  18989 domain6.tld
  12525 domain7.tld
  12058 domain8.tld
  11521 domain9.tld
  11463 domain10.tld

Eine interessante Betrachtung ist die Verteilung der Top-Level-Domains, welche .DS_Store-Dateien preisgeben. Wie man aus den Top 25 erkennt, sind .com Seiten stark vertreten. Sie stellen fast 50% der betroffenen Domains, das könnte auf die hohe Verbreitung von Mac OS in den USA zurück zu führen sein, dazu liegen allerdings nicht genügend Informationen über die Personen oder Unternehmen, die die Domains registriert haben vor.

Nachdem wir nun ungefähr erfahren haben, welche Domains und in welchem Umfang von diesem Problem betroffen sind, können wir weitere Betrachtungen im Detail vornehmen - beispielsweise können wir unseren Blick auf die Dateien, die durch diese Methode entdeckt werden können, werfen. Wie oben beschrieben, sind diese Aussagen auf den 200-Status Antworten der HEAD-Abfragen basierend. Möglicherweise gibt es also weitaus mehr (interessante) Dateien, die von einem Angreifer heruntergeladen werden könnten. Die Top 10 der meistgefundenen Dateiendungen sieht wie folgt aus:

1
2
3
4
5
6
7
8
9
10

 256715 .jpg
  75177 .png
  64835 .php
  42422 .html
  39691 .gif
  23683 .htm
  16397 .pdf
   9736 .js
   9346 .txt
   6886 .css

Schaut man sich die Liste der über 1500 Dateiendungen weiter an, so findet man u.a. auch folgende Einträge, die für einen Missbrauch nützliche Informationen beinhalten könnten:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

661 .bak
569 .gz
549 .doc
464 .db
343 .csv
266 .eml
248 .log
240 .old
202 .docx
186 .inc
162 .config
129 .cfg
123 .sql
123 .sh
105 .htaccess
 55 .git
 35 .LOG
 23 .orig
 22 .tgz
 21 .pem
 18 .out
 16 .conf
 16 .cfs
 10 .php_old
 10 .php_
 10 .key
  8 .back
  6 .backup
  5 .bkp
  4 .php_bak
  3 .htpasswd
  2 .core
  2 .bash_history

Unter den “.bak” Dateien finden sich beispielsweise folgende Dateinamen:

1
2
3
4

  9 index.php.bak
  2 wp-config.php.bak
  2 php.ini.bak
  2 db.bak

Einige dieser Dateien lassen sich ohne weiteres herunterladen, da keine Authentifizierung erforderlich ist und sie offensichtlich nicht nur in der lokalen Umgebung des Entwicklers vorhanden waren, sondern auch auf den Webserver geladen wurden. Wir sind durch diese Technik auf Backupdateien, Zertifikate oder sonstige sensible Informationen aufmerksam geworden und haben die verantwortlichen Stellen (sofern möglich) informiert. Die meisten informierten Webseitenbetreiber haben direkt reagiert, entsprechende Dateien offline genommen, geschützt und .DS_Store Dateien entfernt, andere haben bislang leider noch keine Handlungen vorgenommen - wir hoffen allerdings, das die Veröffentlichung dieses Artikels erneut zur Sensibilisierung beiträgt.

Kurioses zum Fund

Interessant an der Angelegenheit ist, dass dieses Problem bereits mehrfach beleuchtet wurde, die “Fixes” aber meist deletantisch sind oder zumindest immernoch eine Angriffsoberfläche gegeben ist.

Erste Diskussionen zu dem Thema gab es bereits 2001 - heute, 17 Jahre später führt die Datei immernoch zu Sicherheitsproblemen. Apple musste auf Grund zahlreicher Kundenbeschwerden das Veröffentlichen von .DS_Store-Dateien auf Netzlaufwerken unterbinden und erklärte in einem Hilfeartikel wie sich die Funktion abschalten ließ. Adobe weißt in einem FAQ der Web-Software Dreamweaver darauf hin, dass man am besten einen Cronjob aktivieren soll, der die .DS_Store-Dateien regelmäßig löscht. Diese Art des Schutz ist allerdings ausschließlich temporär und daher wohl nicht als vollkommen ausreichend zu betrachten (bessere Lösungsvorschläge finden sich unten). Auch im Rahmen von Bug Bounty Programmen wurde diese Technik bereits eingesetzt, so wurde ein Security Researcher beispielsweise vor 2 Jahren bei Twitter fündig. Dort fand ein Security-Researcher mit dem Namen “lewerkun” unter anderem Lizenzschlüssel, ein WLAN-Zertifikat, ein CA Root Zertifikat und erhielten dafür (gerade einmal) eine Belohnung in Höhe von 560$.

Gegenmaßnahmen

Um die unfreiwillige Preisgabe von Informationen zu verhindern, empfehlen wir folgende Maßnahmen.

Grundsätzlich sollten logischerweise niemals Dateien auf Webserver hochgeladen werden, welche nicht abrufbar sein sollten (auch nicht temporär). Das klingt zunächst einleuchtend, die Praxis zeigt allerdings, dass dies nicht so sehr die Regel ist. Unser Kollege Hanno Böck konnte in seiner Seine Präsentation vom 34c3 vorführen, wie in zahlreichen Fällen mittels “wget” komplette Datenbestände heruntergeladen werden konnten - was eindrucksvoll zeigt, dass es einiges an Handlungsbedarf gibt.

Möchte man auf seinem Webserver überprüfen, ob die diskutierten Dateien dort zu finden sind, so kann man auf Linux-Servern folgenden Kommando verwenden:

1
2

cd /var/www # Ins DocumentRoot des Webservers wechseln
find . -type f -iname "*.DS_Store*"

Das Kommando sucht in dem Ordner /var/www nach Dateien, die “.DS_Store” im Dateinamen haben. Sollte eine Ausgabe erscheinen und die entdeckten Dateien nicht explizit herunterladbar sein, so könnte eine Informationspreisgabe möglich sein. Falls Sie alle gefundenen Dateien entfernen möchten, reicht das Anhängen des Parameters -delete an das Suchkommando.

Eine bessere Methode ist hingegen den Webserver anzuweisen, diese Dateien nicht auszuliefern und den Zugriff zu blockieren. Für die zwei bekanntesten Webserver schlagen wir folgende Konfigurationseinträge vor:

Apache

In der httpd.conf kann der Zugriff mit Hilfe der folgenden Direktive verhindert werden:

1
2
3
4

<Files ~ "\.DS_Store$">
    Order allow,deny
    Deny from all
</Files>

Nginx

Im server-Block blockiert die folgende Anweisung den Zugriff:

1
2
3

location ~ \.DS_Store$ {
      deny all;
}

Zusätzlich sollte überprüft werden, dass:

• diese Dateien nicht in Code-Verwaltungsprogramme (git/svn/etc) eingecheckt und auf dem Server heruntergeladen werden
• diese Dateien bei rsync/(s)ftp oder anderen Dateiübertragen vorher exkludiert oder entfernt werden

Proof of Concept

Um eindrücklich zu zeigen welche Folgen das Veröffentichen der .DS_Store-Datei hat, haben wir eine Demowebseite erstellt auf der man unseren Parser nutzen kann, um Dateinamen aus DS_Store-Dateien auszulesen:

• Link zum “Online .DS_Store Parser”

Disclamer: Bitte ausschließlich für Selbsttest oder Lehre/Forschung nutzen. Die Benutzung für illegale Zwecke ist untersagt!

Weitere Fragen zum Tool beantworten wir im entsprechenden FAQ oder gern per Email.

Möglicher weiterer Research

.DS_Store-Dateien können auch innerhalb von ZIP-Dateien enthalten sein, sofern diese unter Apple gepackt wurden. Unser Parser ist auf das Auslesen von Dateinamen aus .DS_Store-Dateien spezialisiert - es ist allerdings auch durchaus denkbar andere Informationen (etwa Kommentare zu Dateien) aus .DS_Store-Dateien auszulesen, was den Angriffsvektor noch mächtiger machen würde. Neben .DS_Store gibt es unter anderen Betriebssystemen möglicherweise weitere Dateien, welche interessant sein können - auch Verzeichnisse wie “.Trash” könnten sich für zukünftige Nachforschungen in dem Bereich lohnen.

Das Team der Internetwache.org