Docker Hubs Datenpanne von 2019 legte Repo-Tokens von 190.000 Konten offen – die Behebung brach Autobuilds

Am 25. April 2019 entdeckte Docker unbefugten Zugriff auf eine einzelne Docker-Hub-Datenbank. Daten von etwa 190.000 Konten – etwas weniger als 5 % der Hub-Nutzer – könnten offengelegt worden sein: Benutzernamen, bcrypt-Passwort-Hashes und die GitHub- und Bitbucket-Zugriffstokens, die Dockers Autobuild-Funktion antrieben. Docker gab dies zwei Tage später über E-Mail-Benachrichtigungen und eine Support-Ankündigung von Kent Lamb, seinem Director of Support, bekannt.

Die Token-Offenlegung war weitaus wichtiger als die Passwörter. ZDNet merkte an, dass die meisten Docker-Hub-Nutzer Angestellte in großen Unternehmen sind, die Container-Images automatisch bauen, die in die Produktion ausgerollt werden. Wer diese Tokens besaß, konnte auf private Quellcode-Repositories zugreifen oder, schlimmer, die Dockerfiles, mit denen Produktionssoftware gebaut wird, still und leise verändern. Docker selbst konnte nicht sagen, ob der Eindringling etwas heruntergeladen hatte – nur, dass ein Zugriff „möglicherweise erfolgt“ sei bzw. dass Daten „möglicherweise offengelegt“ worden seien.

Dockers Reaktion war die einzig sichere und war bewusst disruptiv: offengelegte Passwörter zurücksetzen, jedes betroffene GitHub- und Bitbucket-Token widerrufen und die Repositories entkoppeln. Die Nutzer mussten ihre Repos neu verbinden und ihre GitHub- und Bitbucket-Sicherheitsprotokolle auf Anzeichen von Missbrauch prüfen. In Dockers eigenen Foren berichteten Nutzer, dass unerwartete „Docker Cloud Build“-Deploy-Keys in ihren GitHub-Repositories auftauchten, während die widerrufenen Integrationen nachwirkten, und fragten vergeblich, wie sie feststellen könnten, ob ihr Konto wirklich unter den 190.000 gewesen war.

Docker identifizierte den Eindringling nie öffentlich und bestätigte keine Exfiltration. Es hieß, offizielle Images seien nicht betroffen, und führte zusätzliche Sicherheitsmaßnahmen ein, um deren Integrität zu gewährleisten. Der dauerhafte Schaden betraf das Vertrauen: Die Registry, die das Container-Ökosystem als Infrastruktur betrachtet, hatte gezeigt, dass eine Datenpanne dort einem Angreifer die Schlüssel zum Quellcode der Kunden in die Hand gibt, nicht nur zu deren Logins.

Alle betroffenen Passwörter zurückgesetzt; die GitHub-/Bitbucket-Tokens jedes Autobuilds widerrufen und Repos entkoppelt – die Builds blieben kaputt, bis jeder Eigentümer sie neu verband

Langlebige OAuth-Tokens für GitHub und Bitbucket lagen in einer operativen Hub-Datenbank, sodass ein einziges Eindringen die Code-Pipelines der Kunden offenlegte und nicht nur deren Logins.

Docker Hub war zur De-facto-Public-Registry für das gesamte Container-Ökosystem geworden, sodass sein Wirkungsradius der der Branche war und nicht der eines einzelnen Anbieters.

Docker konnte nicht feststellen, ob Daten heruntergeladen worden waren, sodass rund 190.000 Sicherheitsteams das Schlimmste annehmen und ihre Repositories manuell prüfen mussten.

Die offengelegten Konten waren keine Durchschnittsnutzer, sondern Betreiber von Firmen-Autobuilds, was die Offenlegung von Zugangsdaten zu einem akuten Lieferkettenrisiko machte und nicht zu einem routinemäßigen Passwort-Reset.

Eine Registry, die alle als Infrastruktur behandeln, ist auch ein Speicher für vorgelagerte Zugangsdaten. Langlebige Tokens für die Quellcodeverwaltung in einer operativen Datenbank machten aus einem kurzen Eindringen eine branchenweite Prüfung.

Docker setzte betroffene Passwörter zurück, widerrief die Autobuild-Tokens und entkoppelte Repositories und wies Kunden an, ihre GitHub- und Bitbucket-Protokolle auf unerwartete Zugriffe zu prüfen. Offizielle Images wurden als unberührt erklärt, mit zusätzlichen Integritätsmaßnahmen. Eine Exfiltration wurde nie bestätigt und kein Angreifer öffentlich genannt. Der Vorfall wurde zu einer stehenden Referenz in Sicherheitsempfehlungen für die Lieferkette, CI-zu-Quellcodeverwaltung-Zugangsdaten kurzlebig und eng begrenzt zu halten.