Am 24. Januar 2023 waren wegen eines Fehlers bei der Freigabe des Codes für die Verwaltung von Service-Token mehrere Cloudflare-Dienste für 121 Minuten nicht verfügbar. Durch den Zwischenfall wurde eine Vielzahl von Cloudflare-Produkten in ihrer Funktionsweise beeinträchtigt. Betroffen waren unter anderem Aspekte unserer Workers-Plattform, unsere Zero-Trust-Lösung und Funktionen der Steuerungsebene in unserem Content Delivery Network (CDN).
Cloudflare bietet eine Service-Token-Funktion an, mit der sich automatisierte Dienste gegenüber anderen Services authentifizieren können. Kunden können mit Service-Token beispielsweise die Interaktion zwischen einer Anwendung, die in einem Rechenzentrum läuft, und einer Ressource bei einem Public Cloud-Anbieter absichern. Im Rahmen des Release wollten wir eine Funktion einzuführen, mit der sich Administratoren den Zeitpunkt der letzten Verwendung eines Tokens anzeigen lassen können. Dies erlaubt es Usern, ungenutzte Token auf sichere Weise zu bereinigen. Doch bei der Änderung wurden versehentlich andere Metadaten der Service-Token überschrieben, wodurch die Token der betroffenen Konten für die Dauer des Vorfalls ungültig wurden.
Dass dieses Release auch Auswirkungen auf andere Dienste hatte, erklärt sich dadurch, dass Cloudflare auf Cloudflare läuft. Service-Token beeinflussen die Authentifizierungsfähigkeit von Konten und mehrere Cloudflare-Dienste laufen über zwei der betroffenen Konten. Als die Service-Token dieser Konten überschrieben wurden, kam es bei den über diese Konten laufenden Diensten zu fehlgeschlagenen Anfragen und anderen unerwarteten Fehlern.
Ein begrenztes Kunden- und Endnutzersegment war direkt von diesem Vorfall betroffen und andere Kunden verzeichneten eventuell eine gewisse Beeinträchtigung der Dienste, doch insgesamt waren die Auswirkungen auf das Netzwerk und die Services von Cloudflare überschaubar. Uns ist aber bewusst, dass die Folgen für die betroffenen Kunden schmerzhaft waren. Wir möchten nun dokumentieren, was schiefgelaufen ist, damit Sie den Vorfall nachvollziehen können. Außerdem beschreiben wir die von uns ergriffenen Maßnahmen, mit denen sichergestellt werden soll, dass sich ein solches Vorkommnis nicht wiederholt.
Was ist ein Service-Token?
Wenn sich User bei einer Anwendung oder einem Identitätsanbieter einloggen, geben sie normalerweise einen Benutzernamen und ein Kennwort ein. Mit dem Kennwort kann der User nachweisen, dass er die Kontrolle über den Benutzernamen hat und dass der Dienst ihm das Fortfahren erlauben soll. Es können zusätzliche Authentifizierungsebenen hinzugefügt werden, z. B. Hardkeys oder Gerätestatus. Doch grundsätzlich geht es darum, dass ein Mensch einem Dienst beweist, dass er der ist, für den er sich ausgibt.
Menschen sind jedoch nicht die einzigen Nutzer, die sich bei einem Service authentifizieren müssen. So müssen Applikationen häufig untereinander kommunizieren. Nehmen wir zum Beispiel an, Sie entwickeln eine Anwendung, die einem Nutzer Informationen zu einer geplanten Reise anzeigt.
Die Airline speichert etwa die Einzelheiten zu dem Flug und seine Dauer in ihrem eigenen System. Sie möchte die Details jeder einzelnen Reise nicht im Internet veröffentlichen und Ihrer Anwendung keinen Zutritt zu ihrem privaten Netzwerk erlauben. Ebenso möchte das Hotel sicherstellen, dass es die Einzelheiten zu einer Zimmerbuchung nur an einen gültigen, zugelassenen Drittanbieterdienst übermittelt.
Ihre Anwendung benötigt also eine vertrauenswürdige Methode, um sich bei diesen externen Systemen zu authentifizieren. Service-Token lösen dieses Problem, indem sie als eine Art Benutzername und Passwort für Ihren Dienst fungieren. Wie Benutzernamen und Passwörter bestehen Service-Token aus zwei Teilen: einer Client-ID und einem geheimen Client-Schlüssel (Client Secret). Sowohl die ID als auch der geheime Schlüssel müssen mit einer Authentifizierungsanfrage gesendet werden. Auch Token haben eine bestimmte Verfallszeit, nach der sie ungültig werden und erneuert werden müssen. Sie können Ihrer Anwendung ein Service-Token zuweisen. Wird dieses von denen von Ihnen benötigten vorgelagerten Systemen validiert, kann Ihr Dienst Informationen über Fluggesellschaften und Hotels abrufen und diese dem Endnutzer in einem einzigen Bericht präsentieren.
Wenn Administratoren Cloudflare-Service-Token erstellen, generieren wir Client-ID und Client Secret als Paar. Kunden können dann ihre anfragenden Dienste so konfigurieren, dass sie beide Werte als HTTP-Header senden, wenn sie auf eine geschützte Ressource zugreifen müssen. Der anfragende Dienst kann in einer beliebigen Umgebung ausgeführt werden, einschließlich innerhalb des Cloudflare-Netzwerks in Form eines Workers oder an einem separaten Ort wie einem Public Cloud-Anbieter. Die Kunden müssen die entsprechende geschützte Ressource hinter dem Reverse-Proxy von Cloudflare bereitstellen. Unser Netzwerk überprüft die HTTP-Header jeder Anfrage, die an einen konfigurierten Dienst gerichtet ist. Falls vorhanden, validiert Cloudflare deren Authentizität. Auf dieser Grundlage wird die Anfrage von Cloudflare dann entweder blockiert oder zugelassen. Wir protokollieren auch das Authentifizierungsereignis.
Zeitlicher Ablauf des Vorfalls
Für de Angaben wurde die Weltzeit (UTC) zugrunde gelegt.
Am 24.01.2023 um 16:55 Uhr startete das Access Engineering-Team das Release, das versehentlich begann, die Metadaten von Service-Token zu überschreiben, wodurch der Vorfall verursacht wurde.
Am 24.01.2023 um 17:05 Uhr bemerkte ein Mitglied des Access Engineering-Teams ein nicht damit zusammenhängendes Problem und setzte das Release zurück, wodurch die weitere Überschreibung von Service-Token-Metadaten verhindert wurde.
Die Werte der Service-Token werden im gesamten Netzwerk von Cloudflare erst dann aktualisiert, wenn der Service-Token selbst aktualisiert wird (weitere Einzelheiten dazu finden Sie weiter unten). Die Folge war, dass sich die Überschreibung der Service-Token-Metadaten erst nach und nach bemerkbar machte.
24.01.2023, 17:50 Uhr: Das erste ungültige Service-Token für Cloudflare WARP wurde mit unserem globalen Netzwerk synchronisiert. Für WARP- und Zero Trust-Nutzer begannen die Folgen, sichtbar zu werden.
Am 24.01.2023 um 18:12 Uhr wurde aufgrund des starken Rückgangs der erfolgreichen WARP-Gerätestatus-Uploads ein Vorfall gemeldet.
24.01.2023, 18:19 Uhr: Das erste ungültige Service-Token für die Cloudflare-API wurde mit unserem globalen Netzwerk synchronisiert. Die Auswirkungen begannen, für Cache Purge, Cache Reserve, Images und R2 spürbar zu werden. Für diese Produkte wurden Warnungen ausgelöst, die erkennen ließen, dass der Vorfall ein größeres Ausmaß erreicht.
Am 24.01.2023 um 18:21 Uhr wurden die überschriebenen Service-Token im Rahmen erster Nachforschungen entdeckt.
Am 24.01.2023 um 18:28 Uhr wurde der Vorfall heraufgestuft, sodass alle betroffenen Produkte abgedeckt wurden.
Am 24.01.2023 um 18:51 Uhr wurde eine erste Lösung gefunden und implementiert, um das Service-Token für das Cloudflare WARP-Konto auf seinen ursprünglichen Wert zurückzusetzen, was Auswirkungen auf WARP und Zero Trust hatte. Die Beeinträchtigung von WARP und Zero Trust verschwand.
Am 24.01.2023 um 18:56 Uhr wurde dieselbe Lösung für das Cloudflare-API-Konto implementiert, was sich auf Cache Purge, Cache Reserve, Images und R2 auswirkte. Die Beeinträchtigung von Cache Purge, Cache Reserve, Images und R2 verschwand.
Am 24.01.2023 um 19:00 Uhr wurde eine Aktualisierung des Cloudflare-API-Kontos vorgenommen, bei der das Cloudflare API-Konto falsch überschrieben wurde. Dadurch wurden Cache Purge, Cache Reserve, Images und R2 erneut beeinträchtigt. Alle internen Cloudflare-Konten-Änderungen wurden daraufhin bis zum Ende des Vorfalls gesperrt.
Am 24.01.2023 um 19:07 Uhr wurde die Cloudflare-API aktualisiert, um den korrekten Service-Token-Wert festzulegen. Die Beeinträchtigung von Cache Purge, Cache Reserve, Images und R2 verschwand.
Am 24.01.2023 um 19:51 Uhr wurden die Service-Token aller betroffenen Konten aus einem Datenbank-Backup wiederhergestellt. Der Vorfall war beendet.
Was beinhaltete das Release und wie kam es zu dem Ausfall?
Das Access-Team wollte dem Service-Token das Feld „last seen at“ hinzufügen. Dies war ein häufig geäußerter Wunsch, weil sich damit feststellen lässt, welche Service-Token aktiv verwendet werden.
Was ist schiefgelaufen?
Der Wert „last seen at“ wurde durch Scannen aller neuen Login-Ereignisse in der Kafka Queue für Login-Ereignisse eines Kontos ermittelt. Wurde ein Login-Ereignis mit einem Service-Token entdeckt, wurde eine Aktualisierung des zuletzt registrierten Werts für den entsprechenden Service-Token eingeleitet.
Um den Wert „last seen at“ des Service-Token zu aktualisieren, wird eine Lese-Schreib-Transaktion durchgeführt, mit der die Informationen über das entsprechende Service-Token gesammelt werden. Bei Leseanforderungen für Service-Token wird der Wert „client secret“ aus Sicherheitsgründen standardmäßig unkenntlich gemacht. Die Aktualisierung des Service-Token mit dem Wert „last seen at“ verwendete dann die Informationen aus dem Lesevorgang, die den geheimen Client-Schlüssel nicht enthielten, und aktualisierte das Service-Token beim Schreibvorgang mit einem leeren „client secret“.
Es folgt ein Beispiel für die richtigen und falschen Service-Token-Werte:
Beispiel für die Werte des Zugriffsdienst-Token
{
"1a4ddc9e-a1234-4acc-a623-7e775e579c87": {
"client_id": "6b12308372690a99277e970a3039343c.access",
"client_secret": "<hashed-value>", <-- what you would expect
"expires_at": 1698331351
},
"23ade6c6-a123-4747-818a-cd7c20c83d15": {
"client_id": "1ab44976dbbbdadc6d3e16453c096b00.access",
"client_secret": "", <--- this is the problem
"expires_at": 1670621577
}
}
Die Datenbank für „Client Secrets“ von Service-Token führte zwar eine „not null“-Prüfung durch, aber in diesem Fall wurde ein leerer Textstring nicht als Nullwert gemeldet.
Infolge dieses Fehlers wurde während der zehn Minuten, in denen das „last seen at“-Release aktiv war, bei jedem Cloudflare-Konto, das ein Service-Token zur Authentifizierung verwendete, der „client secret“-Wert auf einen leeren String gesetzt. Das Service-Token musste dann geändert werden, damit das leere „Client Secret“ für die Authentifizierung verwendet werden konnte. Insgesamt befanden sich vier Konten in diesem Zustand und in allen Fällen handelte es sich um interne Cloudflare-Konten.
Wie haben wir das Problem behoben?
Als vorübergehende Lösung konnten wir die korrekten Service-Token-Werte für die Konten mit überschriebenen Service-Token manuell wiederherstellen. Dadurch wurden die unmittelbaren Auswirkungen auf die betroffenen Cloudflare-Dienste unterbunden.
Das Datenbank-Team konnte dann eine Lösung implementieren, um die Service-Token aller betroffenen Konten aus einer älteren Datenbankkopie wiederherzustellen. Damit wurden alle Auswirkungen dieses Vorfalls beendet.
Warum waren andere Cloudflare-Dienste betroffen?
Service-Token haben Einfluss auf die Authentifizierungsfähigkeit von Konten. Mehrere Cloudflare-Dienste laufen über zwei der betroffenen Konten. Als die Service-Token dieser Konten überschrieben wurden, traten bei den über diese Konten laufenden Diensten fehlgeschlagene Anfragen und andere unerwartete Fehler auf.
Cloudflare WARP-Registrierung
Cloudflare bietet einen Forward-Proxy für Mobilgeräte und Desktops, Cloudflare WARP (unsere „1.1.1.1“-Applikation). Dieser kann von jedem Nutzer auf einem Gerät installiert werden, um den Datenschutz seines Internet-Traffics zu verbessern. Ein Cloudflare-Konto ist dafür nicht erforderlich. Wir speichern auch keine Protokolle, in denen Aktivitäten einem Nutzer zugeordnet werden.
Wenn ein Nutzer eine Verbindung über WARP herstellt, validiert Cloudflare die Registrierung eines Geräts mittels eines Diensts, der die Schlüssel auf dem Gerät empfängt und validiert. Dieser Service kommuniziert wiederum mit einem anderen System, das unser Netzwerk anweist, dem neu registrierten Gerät Zugang zu unserem Netzwerk zu gewähren.
Während des Vorfalls konnte der Registrierungsdienst nicht mehr mit den Systemen in unserem Netzwerk kommunizieren, die ein Gerät normalerweise validieren. Infolgedessen konnten Nutzer keine neuen Geräte mehr registrieren und/oder die App auf einem neuen Gerät installieren. Außerdem gab es eventuell Probleme beim Upgrade auf eine neue Version der App (was ebenfalls eine erneute Registrierung auslöst).
Richtlinien von Cloudflare Zero Trust für Gerätestatus und Neuregistrierung
Cloudflare bietet eine umfassende Zero Trust-Lösung, die Kunden mit oder ohne Agenten auf dem Gerät einsetzen können. Einige Anwendungsfälle sind nur bei Verwendung des Cloudflare-Agenten auf dem Gerät möglich. Bei dem Agenten handelt es sich um eine Unternehmensversion der gleichen WARP-Lösung von Cloudflare, die jedes Mal, wenn der Agent den Gerätestatus senden oder empfangen musste, ähnliche Beeinträchtigungen aufwies. Dies hatte Auswirkungen auf drei Anwendungsfälle von Cloudflare Zero Trust.
Erstens konnten, ähnlich wie beim Verbraucherprodukt, neue Geräte nicht registriert und vorhandene Geräte nicht widerrufen werden. Die Administratoren konnten auch die Einstellungen der registrierten Geräte nicht ändern. In allen Fällen wurden den Nutzern dann Fehler angezeigt.
Zweitens können viele Kunden, die ihr bestehendes privates Netzwerk durch die Zero Trust-Lösung von Cloudflare ersetzen, Regeln hinzufügen, mit denen die Identität eines Nutzers durch die Verwendung von Richtlinien zur Sitzungsdauer kontinuierlich überprüft wird. Diese Regeln haben den Zweck, die Nutzer zu einer erneuten Authentifizierung zu zwingen. So soll verhindert werden, dass veraltete Sitzungen weiterhin Zugriff auf interne Systeme haben. Der Agent auf dem Gerät fordert den Nutzer auf Grundlage von Meldungen der Steuerungsebene von Cloudflare auf, sich neu zu authentifizieren. Während des Vorfalls wurden diese Meldungen nicht gesendet und die Nutzer konnten sich nicht erfolgreich neu authentifizieren.
Last but not least waren auch Kunden betroffen, die auf Gerätestatus-Regeln zurückgreifen. Diese erlauben es Kunden, die Zugriffs- oder Gateway-Richtlinien verwenden, mithilfe des WARP-Agenten kontinuierlich durchzusetzen, dass ein Gerät die Compliance-Regeln des Unternehmens erfüllt.
Der Agent übermittelt diese Meldungen an einen Cloudflare-Dienst, der für die Aufrechterhaltung des Gerätestatus verantwortlich ist. Das Zero Trust-Zugangskontrollprodukt von Cloudflare verwendet ein Service-Token, um diese Meldung zu empfangen und sie zusammen mit anderen Regeln auszuwerten. So wird ermittelt, ob ein Nutzer auf eine bestimmte Ressource zugreifen darf. Während des Vorfalls wurden diese Regeln standardmäßig blockiert, weshalb der durch diese Richtlinien angepasste Traffic dem Nutzer als gestört erschien. In einigen Fällen wurde dadurch der gesamte für das Internet bestimmte Datenverkehr von einem Gerät vollständig gesperrt, sodass die Nutzer auf nichts mehr zugreifen konnten.
Cloudflare Gateway speichert den Gerätestatus für Nutzer alle fünf Minuten im Cache, um Gateway-Richtlinien anzuwenden. Der Gerätestatus wird zwischengespeichert, damit Gateway Richtlinien anwenden kann, ohne den Gerätestatus bei jeder Anfrage überprüfen zu müssen. Je nachdem, welcher Gateway-Richtlinientyp gefunden wurde, ergeben sich für den Nutzer zwei unterschiedliche Ergebnisse. Bei einer übereinstimmenden Netzwerkrichtlinie wird die Verbindung des Nutzers unterbrochen, bei einer HTTP-Richtlinie wird ihm eine 5XX-Fehlerseite angezeigt. Bis der Vorfall behoben war, erreichten wir einen Spitzenwert von mehr als 50.000 5XX-Fehlern/Minute über der Referenzlinie und wir verzeichneten mehr als 10,5 Millionen Posture-Read-Fehler.
Gateway-5XX-Fehler pro Minute
Gesamtzahl der Gateway-Gerätestatus-Fehler
Cloudflare R2 Storage und Cache Reserve
Cloudflare R2 Storage ermöglicht es Entwicklern, ohne die die mit typischen Cloud-Speicherdiensten verbunden hohen Egress-Bandbreitengebühren große Mengen unstrukturierter Daten zu speichern.
Während des Vorfalls war der R2-Dienst nicht in der Lage, ausgehende API-Anfragen an andere Teile der Cloudflare-Infrastruktur zu stellen. Dies hatte zur Folge, dass R2-Nutzer bei Anfragen an R2 eine erhöhte Fehlerquote verzeichneten.
Viele Produkte von Cloudflare sind für die Datenspeicherung auch von R2 abhängig und waren ebenfalls betroffen. Cache Reserve-Nutzer erlebten beispielsweise in diesem Zeitfenster Beeinträchtigungen, denn sie verzeichneten eine erhöhte Belastung des Ursprungsservers für alle Elemente, die sich nicht im primären Cache befanden. Die meisten Lese- und Schreibvorgänge für den Cache Reserve-Dienst waren während dieses Vorfalls beeinträchtigt, sodass Einträge in und aus Cache Reserve fehlschlugen. Doch wenn Cache Reserve einen R2-Fehler feststellt, greift der Service auf den Ursprungsserver des Kunden zurück. Daher konnte der Nutzer-Traffic in diesem Zeitraum weiterhin übermittelt werden.
Cloudflare Cache Purge
Das Content Delivery Network (CDN) von Cloudflare speichert die Inhalte von Websites und Internetanwendungen in den Rechenzentren unseres Netzwerks auf der ganzen Welt, um die Entfernung zu verringern, die die Anfrage eines Nutzers für eine Antwort zurücklegen muss. In manchen Fällen möchten Kunden die von uns zwischengespeicherten Daten löschen und durch andere Daten ersetzen.
Die Cloudflare-Steuerungsebene –also der Ort, an dem ein Administrator mit unserem Netzwerk interagiert – verwendet ein Service-Token, um sich zu authentifizieren und den Cache Purge-Service zu erreichen. Während des Vorfalls schlugen viele Bereinigungsanfragen fehl, weil das Service-Token ungültig war. Im Durchschnitt schlugen 20 Bereinigungsanfragen pro Sekunde fehl, maximal waren es 70 Anfragen pro Sekunde.
Was tun wir, um zu verhindern, dass so etwas noch einmal passiert?
Vorfälle wie diesen nehmen wir sehr ernst und wir sind uns der Auswirkungen bewusst, die er hatte. Wir haben mehrere Maßnahmen identifiziert, die ergriffen werden können, um das Risiko eines ähnlichen Problems in der Zukunft zu verringern. Als Folge dieses Vorfalls führen wir den folgenden Plan zur Behebung des Problems ein:
Testen: Das Access Engineering-Team wird Unit-Tests hinzufügen, die automatisch ähnliche Probleme mit dem Überschreiben von Service-Token aufspüren, bevor neue Funktionen eingeführt werden.
Warnen: Das Access-Team wird im Falle eines drastischen Anstiegs der fehlgeschlagenen Service-Token-Authentifizierungsanfragen eine automatische Warnung implementieren, um Probleme abzufangen, bevor sie vollständig eingeführt werden.
Reagieren: Das Access-Team hat Prozessverbesserungen identifiziert, die ein schnelleres Rollback für bestimmte Datenbanktabellen ermöglichen.
Umsetzen: Alle relevanten Datenbankfelder werden so aktualisiert, dass sie zusätzlich zu den bestehenden „not null checks“ auch Prüfungen auf leere Strings enthalten.
Für die Unterbrechungen, die dies für unsere Kunden bei einer Reihe von Cloudflare-Diensten verursacht hat, bitten wir um Entschuldigung. Wir arbeiten aktiv an diesen Optimierungen, um die Stabilität zu erhöhen und sicherzustellen, dass dieses Problem nicht noch einmal auftritt.