© 3dfoto, 123RF

Der Einsatz von Cloudstorage-Lösungen wie Dropbox, Google Drive und Owncloud nimmt trotz Sicherheitsbedenken auch im Unternehmensumfeld immer mehr zu. Ist das Risiko vielleicht zu hoch?

Die Vorteile liegen auf der Hand: Zwischen verschiedenen Geräten Daten abgleichen oder Ordner mit Arbeitskollegen teilen oder automatisch Backups erstellen – das alles ist sehr bequem. Allein Dropbox zählt nach eigenen Angaben mehr als vier Millionen Geschäftskunden. Dennoch erfordert es großes Vertrauen in den Anbieter und dessen hoffentlich umfangreiche Sicherheitsvorkehrungen, wenn man eigene Daten in die Hände eines Cloudstorage-Providers weitergibt. Ohne Client-seitige Verschlüsselung kann der Provider grundsätzlich immer illegal mitlesen oder manipulieren.

Sicherheitsexperten wie Bruce Schneier argumentieren, dass die Nutzung von Cloudstorage-Diensten für durchschnittliche Nutzer überwiegend von Vorteil ist – das automatische Cloudbackup rettet im Falle eines Festplattenausfalls die Familienfotos, die Sicherheitsvorkehrungen des Anbieters übersteigen im Regelfall die des Nutzers bei Weitem [1].

Im Unternehmensumfeld sieht die Rechnung jedoch anders aus: Die unautorisierte Weitergabe oder der Verlust von Geschäftsdaten wird in vielen Fällen gravierendere Folgen haben. Allerdings sollte in Unternehmen eine Cloudstorage-Lösung niemals das lokale Backup wichtiger Daten ersetzen. Bestehen bleibt aber die Gefahr, dass ein Angreifer den Cloudstorage-Dienst als Werkzeug benutzt, um sich Zugriff auf sensible Daten zu verschaffen.

Die Testumgebung

Der Blick auf die Desktopclients von Dropbox, Google Drive und Owncloud soll zeigen, welches Sicherheitslevel der Nutzer von seinem Cloudstorage-Anbieter zu erwarten hat. Eine solche Analyse offenbart zumindest, wie es um die Sicherheit der verwendeten Clients bestellt ist. Die Serverinfrastruktur betrachtet dieser Beitrag nicht.

Bei der Analyse der Cloudstorage-Clients lässt sich an zwei Punkten ansetzen: Zum einen würde das Aushebeln der Transportverschlüsselung die Vertraulichkeit und Integrität der Daten sofort zunichtemachen, zum anderen ließen sich auch geschickte Manipulationen des verwendeten Synchronisationsprotokolls zur Kompromittierung nutzen.

In einer ersten Voranalyse lässt sich festhalten, dass alle drei Anbieter auf SSL/TLS zum Schutz der Kommunikation zurückgreifen – das ist leider nicht selbstverständlich: Andere Anbieter (Crashplan, Teamdrive, Wuala) sind hier weitaus risikobereiter und verlassen sich auf selbst entwickelte Protokolle. Angriffe wie Crime, Breach oder Heartbleed zeigen jedoch, dass auch TLS-Verschlüsselung nicht zwangsläufig sicher sein muss. Daher umfasst der Test eine Analyse der TLS-Implementierung.

Als zweiter Ansatzpunkt bleibt das Synchronisationsprotokoll: Um hier trotz Verschlüsselung eine Protokollanalyse möglich zu machen, kam für diesen Test ein Man-in-the-Middle-HTTPS-Proxy wie »mitmproxy« [2] zum Einsatz (Abbildung 1). Installiert man das Sicherheitszertifikat des Proxys im eigenen System, kann er auch TLS-Kommunikation abfangen, entschlüsseln und modifizieren. Auf diese Art und Weise lässt sich beispielsweise die Mitteilungsfreudigkeit des eigenen Smartphones genau unter die Lupe nehmen.

Abbildung 1: Ein Man-in-the-Middle-Proxy ermöglichet eine Protokollanalyse trotz Verschlüsselung.

Dropbox

Als einer der ersten großen Cloudstorage-Anbieter ist Dropbox ein beliebtes Ziel von Sicherheitsforschern. Tabelle 1 liefert einen Überblick über bisher erfolgte Angriffe. Gravierende Lücken gibt es dabei genügend. Es soll aber nicht unerwähnt bleiben, dass sich die Sicherheitslage mit der Zeit deutlich verbessert hat.

Die Analyse des Desktopclients verrät, dass es sich um eine plattformunabhängige Python-Applikation handelt. Die TLS-Kommunikation übernimmt Pythons Standardbibliothek, die im Hintergrund auf Open SSL baut und TLS 1.0 verwendet. Um sich vor kompromittierten Certificate Authorities (CAs) zu schützen, setzt Dropbox so genanntes Certificate Pinning ein: Statt dem Zertifikatsspeicher des Betriebssystems zu vertrauen, führt Dropbox eine explizite Whitelist, die fünf CAs für die Validierung enthält.

Dafür hat Dropbox einige Modifikationen an Open SSL vorgenommen. Die Folge ist allerdings, dass Dropbox mit Open SSL 0.9.8l (November 2009) eine ältere Version im Client einsetzt. Die enthält zwar für den Anwendungsfall keine bisher bekannten Sicherheitslücken, von besonderer Vorsicht kann aber auch nicht gesprochen werden.

Das von Dropbox zur Synchronisation entwickelte Protokoll stellt sich als solide heraus. Dennoch kann es zu Problemen kommen: Löscht der Nutzer einen freigegebenen Ordner, bleibt die URL als Link auf den Pfad weiter gültig. Legt der Nutzer später einen Ordner mit dem gleichen Namen an, kann er auf ihn über den alten Link zugreifen.

Tendenziell kritisch sind auch die Abfragen, ob geänderte Dateien vorliegen. Aus Performancegründen passiert das nämlich ohne TLS, wodurch User-IDs sowie zugehörige Gruppen-IDs im Klartext transferiert werden. Ein gut platzierter passiver Netzwerkangreifer kann aus diesen Informationen die Gruppen-Zugehörigkeiten und -Aktivitäten eines ganzen Unternehmens ableiten.

Eine interessante Randnotiz ist die aktive Client-seitige Datendeduplikation wert, die Dropbox bis 2011 benutzte. Hatte ein anderer Nutzer eine Datei bereits einmal hochgeladen, war dadurch ein erneuter Upload nicht erforderlich. Das ist jedoch bei genauerer Betrachtung nicht unproblematisch: Speichert eine Firma ihre Standardschreiben in der Cloud, lassen sich durch gezieltes Ausprobieren beispielsweise die Beträge in der Gehaltsabrechnung jedes Mitarbeiters erraten. Ist kein Upload erforderlich, hat man die korrekte Version getroffen.

Dieser Angriff war Dropbox zwar bekannt, auf die durch die Deduplikation erreichbaren Geschwindigkeitsvorteile wollte der Anbieter aber dennoch nicht verzichten. Dass das Problem mittlerweile behoben ist, hat einen anderen Grund: Ein findiger Entwickler veröffentlichte ein Tool namens Dropship, mit dem es möglich war, Dateien durch Eingabe des zugehörigen SHA256-Hash herunterzuladen. Aus Angst, als Filesharing-Plattform missbraucht zu werden, findet die Deduplikation nun nur noch Server-seitig nach dem Upload statt.

Google Drive

Im Vergleich zu Dropbox sind öffentliche Angriffsdemonstrationen gegen Google Drive eher spärlich gesät – aufgrund des deutlich späteren Markteintritts (2012) hinkt der Vergleich jedoch. Wer genau hinschaut, findet auch für Google Drive Lücken wie das Cross-Zone Scripting in den Smartphone Apps vom Oktober 2012 oder die Kontoübernahme durch Stored XSS (April 2014). Diese Lücken wurden jedoch meist erst nach Behebung veröffentlicht, um das von Google ausgeschriebene Bug Bounty zu erhalten, das Bugmelder belohnt, die sich zuerst an das Unternehmen wenden.

Mit Blick auf die Clientsoftware verfolgt Google eine ähnliche Strategie wie Dropbox: Auch hier bekommt der Kunde eine plattformunabhängige Python-Applikation, die aber im Gegensatz zu Dropbox die neueste Open-SSL-1.0.1-Patch-Release verwendet. Wie für Python-2-Anwendungen typisch, wird TLS 1.0 zur Kommunikation verwendet. Auch Googles Client benutzt Certificate Pinning und akzeptiert nur von Googles CA signierte Zertifikate.

Bei der Analyse des Kommunikationsprotokolls erlebte der Tester einige Überraschungen: Löscht er eine zuvor geteilte Datei über die Weboberfläche, wird dies mit »Die Datei wurde in den Papierkorb verschoben und ist nicht länger geteilt« quittiert. Ruft ein anderer Nutzer jedoch die Sharing-URL auf, bietet Google ihm die Möglichkeit, noch bequem eine Kopie zu erstellen, bevor die Datei nach 30 Tagen endgültig aus dem Papierkorb fliegt (Abbildung 2).

Abbildung 2: Google Drive gewährt auch auf gesperrte Dateien unter Umständen noch wochenlang Zugriff.

Die Antwort des Google-Security-Teams fällt ernüchternd aus: “[…] the wording is slightly misleading, but the feature itself is working as intended.” Auch wenn die Formulierung nach erneuter Rückfrage mittlerweile angepasst wurde, sollte ein sicherheitsbewusster Anbieter derart irreführende Benutzeroberflächen nicht als “slightly misleading” abtun.

Auch sonst zeigt das verwendete Protokoll Schwächen: Durch geschicktes Verzögern von Paketen lässt sich durchaus ein Blind Write (schreiben ohne vorher zu lesen) in geteilten Ordnern hervorrufen, ohne dass wie bei Dropbox eine in Konflikt stehende Kopie der Datei erzeugt wird. Schränkt man die Sichtbarkeit einer Datei von »Öffentlich« auf »Jeder, der über den Link verfügt« ein, ändert sich unpraktischerweise eben dieser Link nicht und die Datei bleibt weiterhin – über Suchmaschinen bereits indiziert – praktisch öffentlich einsehbar.

Owncloud

Während es sich bei Dropbox und Google Drive um reine Software-as-a-Service -Dienste handelt, lässt sich Owncloud als Open-Source-Produkt im eigenen Netzwerk installieren. Wer sich also vor einem Zugriff durch amerikanische Bundesbehörden fürchtet, ist hier deutlich besser aufgehoben. Dennoch ist der Betrieb eines Owncloud-Servers sicherheitstechnisch nicht zu unterschätzen: Allein 2013 veröffentlichte Owncloud 28 Security Advisories, die unter anderem fünfmal Remote Code Execution, viermal Arbitrary File Disclosure und dreimal SQL-Injection dokumentierten. Dass sie dabei sicherheitsrelevante Commits als »logging changes« maskierten, trägt auch nicht gerade zur Vertrauensbildung bei.

Für die TLS-Transportverschlüsselung verlässt sich Owncloud ebenfalls auf Open SSL, wobei die neueste 1.0.1-Patch-Release mit – sofern vom Server unterstützt – vorbildlichem TLS 1.2 zum Einsatz kommt. Da Owncloud nicht an einen bestimmten Server gebunden ist, benutzt es zur Zertifikatsvalidierung den Zertifikatsspeicher des Betriebssystems. Die Zertifikate können dabei in der grafischen Oberfläche überprüft werden. Owncloud generiert jedoch selbst dann keine Meldung, wenn sich beispielsweise das Wurzelzertifikat ändert.

Bei der Kommunikation mit dem Server setzt Owncloud auf den etablierten Webdav-Standard, was böse Überraschungen mit Blick auf das Protokoll verhindert. Auch die Dateifreigabe verläuft vorbildlich: Teilt ein Benutzer eine Datei per Link, kann er sowohl Passwortschutz als auch ein Ablaufdatum optional angeben. Damit bietet Owncloud von allen hier getesteten Diensten den solidesten Client – den zugehörigen Server muss jedoch der Nutzer in jedem Fall selber sichern.

Fazit

Auch wenn der erste Eindruck täuschen mag – hochkritische Sicherheitslücken wurden in diesem Test in keinem der überprüften Clients gefunden. Optimistisch stimmt, dass die Dienstanbieter grundsätzlich auf etablierte Schutzmechanismen (TLS) setzen und zudem versuchen, diese selbst noch weiter zu härten (Certificate Pinning).

Dass einige Best Practices wegen externer Hürden – Python 2 unterstützte zum Testzeitpunkt noch kein TLS 1.1+ – nicht zu erfüllen sind, erscheint verständlich. Dennoch lässt sich beispielhaft an der Deduplikation bei Dropbox erkennen, dass die Anbieter für Performancegewinne auch wissentlich deutliche Abstriche bei der Sicherheit hinnehmen.

Knackpunkt bei allen getesteten Systemen bleibt, dass in keinem Fall eine Client-seitige Verschlüsselung stattfindet. Zwar vereinfacht sich damit die Entwicklung der jeweiligen Weboberflächen stark, mit Blick auf die Zahl der in den letzten Jahren entdeckten Lücken muss jeder Firmenkunde sich aber fragen, ob er diesen Sicherheitskompromiss eingehen möchte.

Was bleibt zum Schluss als eine Handlungsempfehlung? Für die meisten Nutzer bleibt SaaS-Cloudstorage weiterhin empfehlenswert. Die Vorteile wie automatische Backups überwiegen. Soll die NSA außen vor bleiben, kann der Nutzer alternativ auch auf europäische Anbieter zurückgreifen, die dann etwa Owncloud als SaaS-Lösung anbieten [3].

Wer sich hingegen volle Kontrolle über die eigenen Daten wünscht, sollte sich eine eigene Owncloud-Instanz im VPN-Netzwerk einrichten, was zumindest vor Angriffen aus dem Internet schützt. Auf eine Online-Dateifreigabe muss der Anwender dann aber verzichten. Als weitere Alternative kommen Anbieter wie Spider Oak [4] in Betracht, die von Haus aus eine Client-seitige Verschlüsselung mitbringen.

Der Autor

Maximilian Hils studiert Information Systems an der Universität Münster und forscht dort am Lehrstuhl für IT-Security (Prof. Dr. Rainer Böhme). Für seine Bachelor-Arbeit hat er Dropbox, Google Drive und Owncloud einer Sicherheitsanalyse unterzogen, deren Ergebnisse er im Rahmen der 22. DFN-Sicherheitskonferenz am 24./25. Februar 2015 in Hamburg präsentiert.