Filehosting: Dropbox-Client entschlüsselt

Sicherheitsforscher haben den in Python geschriebenen Dropbox-Client entschlüsselt und ihre Ergebnisse veröffentlicht. Damit offenbaren sie potentielle Sicherheitslücken - auch für andere Software.

Artikel veröffentlicht am 29. August 2013, 13:44 Uhr, Jörg Thoma

Hacker haben den Code des Dropbox-Clients entschlüsselt. (Bild: Dropbox)

Den Sicherheitsexperten Dhiru Kholia und Przemyslaw Wegrzyn ist es gelungen, den verschlüsselten Python-Code des Dropbox-Clients zu entschlüsseln und zu analysieren. Dabei entdeckten sie auch, wie die zweifache Authentifizierung des Filehosters zu umgehen ist und wie fremde Dropbox-Konten übernommen werden können, sofern ein Angreifer die entsprechenden Zugangsdaten von einem Rechner erbeuten kann. Das ist allerdings ziemlich aufwendig.

Die beiden Forscher erwähnen aber auch, dass mit jeder neuen Version des Dropbox-Clients die Sicherheit erhöht wird. Bisherige Schwachstellen seien schnell beseitigt worden, nachdem die beiden Forscher das Unternehmen darauf aufmerksam gemacht hätten. Dropbox hatte in der Vergangenheit mehrfach mit Schwachstellen zu kämpfen.

Datenbank entschlüsselt

Die beiden Forscher untersuchten die Authentifizierung, die über die sogenannte host_id und die host_int erfolgt. Bis Version 1.2.48 wurde host_id unverschlüsselt in der als Datei abgelegten SQLite-Datenbank Config.db gespeichert. Dieser Wert wird einmalig bei der Installation generiert und wird auch später dann nicht geändert, etwa wenn das Passwort neu gesetzt wird.

Seit Version 1.2.48 wird die Datenbankdatei verschlüsselt. Die für die Verschlüsselung verwendeten "Secrets" lägen aber den Installationsdateien bei. Ohne diese würde der Dropbox-Client nicht funktionieren. Die Datei Keystore_linux.py in der Linux-Version des Dropbox-Clients enthält die entsprechenden Befehle für die Verschlüsselung. Dort lässt sich die Datei Config.dbx, die die host_id enthält, mit der Anwendung Dbx-keygen-linux auslesen.

Sicherer unter Windows

Unter Windows wird die SQLite-Datenbank mit der Windows-eigenen Verschlüsselungsschnittstelle Data Protection API (DPAPI) verschlüsselt. Daher mussten die Forscher einen anderen Weg suchen, um dessen Wert zu ermitteln. Im Debug-Modus schreibt der Dropbox-Client Logfiles im Klartext. Dort wird auch die host_id eingetragen. Der Debug-Modus war in älteren Dropbox-Versionen nur durch eine partielle Md5-Summe geschützt. Seit Version 2.0 wird der vollständige SHA-256-Hash benötigt.

Um an die host_id unter Windows zu kommen, haben die Hacker versucht, eine Man-in-the-Middle-Attacke auf den verschlüsselten Datenverkehr zwischen Client und Server zu fahren. Dabei fanden sie heraus, dass herkömmliche Hackerwerkzeuge nicht in der Lage sind, die SSL-Verbindung abzuhören. Die SSL-Zertifikate sind hart kodiert und die verwendete SSL-Bibliothek ist mit der ausführbaren Binärdatei statisch verlinkt. Daher ist das Patchen der Datei zwar möglich, aber äußerst zeitaufwendig.

Code-Injection per Monkey Patching

Die beiden Forscher haben stattdessen per Monkey Patching die entsprechenden SSL-Objekte verändert. Dabei nutzen sie Reflective DLL Injection unter Windows und LD-PRELOAD unter Linux, um Zugriff auf die relevanten Objekte im Speicher zu erhalten. Danach konnten sie die versendeten Daten einsehen, bevor sie verschlüsselt wurden. Diese Technik lässt sich allerdings nicht nur mit dem Python-Code des Dropbox-Clients anwenden, sondern auch mit weiteren dynamischen Skriptsprachen wie Ruby, Perl oder Javascript.

Die zusätzlich benötigte host_int wird beim Start des Dropbox-Clients vom Server übermittelt und ändert sich dann nicht mehr. Sie lässt sich beispielsweise durch eine Anfrage mit der host_id beim Dropbox-Server ermitteln, etwa auch über ein unverschlüsseltes WLAN. Hat ein Angreifer beide Werte, kann er jederzeit auf die Dropbox-Daten eines Opfers zugreifen, etwa indem er einen Weblink generiert.

Diese zweifache Authentifizierung werde nur für den Zugriff auf die Dropbox-Webseite benötigt, schreiben die Forscher. Der Dropbox-Client selbst verwendet sie nicht. Damit werde impliziert, dass weiterhin nur der Wert der host_id benötigt wird, um an die Daten eine Opfers zu gelangen.