Datenabfluss aus Owncloud & Nextcloud: Der Betrieb hat versagt, nicht die Software

Die aktuellen Berichte über massiven Datenabfluss aus selbst gehosteten Owncloud-, Nextcloud- und ShareFile-Instanzen sind technisch betrachtet unspektakulär – und genau das macht sie so problematisch. Es gab keinen Zero-Day, keine kompromittierte Verschlüsselung, keinen Architekturfehler in der Software. Der Zugriff erfolgte mit gültigen Benutzerkonten. Teilweise mit Zugangsdaten, die Jahre alt waren.

Wer daraus ein „Open-Source-Problem" ableitet, verkennt die Lage grundlegend.

Was ist passiert?

Angreifer haben Zugangsdaten genutzt, die zuvor über sogenannte Infostealer-Malware von Endgeräten abgegriffen wurden. Redline, Lumma, Vidar und ähnliche Varianten extrahieren gespeicherte Passwörter, Browserdaten und Session-Informationen. Diese Daten landen nicht sofort in Angriffen, sondern häufig monatelang oder jahrelang in Log-Sammlungen, die auf Untergrundmarktplätzen gehandelt werden.

In den nun bekannt gewordenen Fällen wurden genau solche alten Logs ausgewertet. Die Angreifer haben gezielt nach Zugängen zu Cloud- und Filesharing-Systemen gesucht – und sind fündig geworden. Die Anmeldung funktionierte, weil keine zusätzliche Authentifizierung verlangt wurde. Kein MFA, kein zusätzlicher Faktor, keine Hürde.

Warum die Software nicht das Problem war

Owncloud und Nextcloud unterstützen seit Langem:

• Multi-Faktor-Authentifizierung (TOTP, Hardware-Token, App-basiert)
• Zentrale Passwort-Policies
• Sitzungsmanagement inklusive Session-Invalidierung
• Detaillierte Audit- und Zugriffslogs
• Rollen- und Rechtemodelle

All diese Mechanismen waren verfügbar. Sie wurden nur nicht konsequent eingesetzt. MFA war optional statt verpflichtend. Bestehende Sessions blieben gültig, selbst nachdem Credentials längst kompromittiert waren. Passwörter wurden nicht regelmäßig rotiert. Logs wurden nicht aktiv ausgewertet, sondern bestenfalls archiviert.

Das ist kein Softwarefehler. Das ist ein Betriebsfehler.

Der eigentliche Angriffsvektor: fehlende Sicherheitsdisziplin

Technisch betrachtet war der Angriff trivial:

1. Infostealer infiziert ein Endgerät.
2. Zugangsdaten werden extrahiert und in Logs abgelegt.
3. Logs werden später von einem Initial-Access-Broker ausgewertet.
4. Login mit Benutzername und Passwort.
5. Voller Zugriff auf produktive Cloud-Daten.

Dieser Ablauf funktioniert nur unter einer Voraussetzung: Der zweite Faktor fehlt. Sobald MFA erzwungen wird, sind diese Zugangsdaten wertlos. Genau deshalb ist MFA kein „Nice-to-have", sondern eine Grundanforderung für jedes internetexponierte System.

Dass teilweise jahrealte Passwörter noch gültig waren, zeigt ein weiteres strukturelles Problem: kompromittierte Credentials werden nicht als Sicherheitsvorfall behandelt, sondern als Randnotiz. Dabei ist längst bekannt, dass Infostealer-Logs eine der wichtigsten Quellen für heutige Angriffe sind.

Open Source als falscher Sündenbock

In der öffentlichen Debatte taucht reflexartig der Vorwurf auf, selbst gehostete oder Open-Source-basierte Lösungen seien unsicherer als proprietäre Cloud-Angebote. Die aktuellen Vorfälle belegen das Gegenteil.

Die Sicherheit der eingesetzten Software war ausreichend. Die Konfiguration war es nicht. Wer Open Source hier verantwortlich macht, verlagert Verantwortung – weg vom eigenen Betrieb, hin zur Lizenzform. Das ist bequem, aber falsch.

Ein proprietäres System ohne erzwungenes MFA wäre auf exakt dieselbe Weise kompromittiert worden.

Was jetzt zwingend erforderlich ist

Die Handlungsempfehlungen sind technisch klar und nicht neu:

• MFA verpflichtend für alle Nutzer, ohne Ausnahmen
• Sofortige Invalidierung aller aktiven Sessions nach Aktivierung von MFA
• Regelmäßige Rotation von Passwörtern, insbesondere für privilegierte Konten
• Aktive Auswertung von Zugriffslogs auf Anomalien
• Annahme, dass Credentials kompromittiert sind – nicht die Hoffnung, dass sie es nicht sind

Selbsthosting bedeutet nicht nur Kontrolle, sondern auch Verantwortung. Wer digitale Souveränität will, muss sie operativ umsetzen. Nicht auf dem Papier, nicht in Strategien, sondern in der täglichen Administration.

Fazit

Diese Vorfälle sind kein Beweis gegen Open Source. Sie sind ein Beweis dafür, dass Sicherheitsfunktionen wertlos sind, wenn sie nicht genutzt werden. Die Software hat geliefert. Der Betrieb nicht.

Open Source war hier nicht die Schwachstelle. Fehlende Konsequenz war es.