Nachahmungsschwachstelle in Akamai EAA – ein tiefer Einblick

In diesem Beitrag werden die technischen Details der Schwachstelle CVE-2021-28091beschrieben, die sich auf die EAA-Plattform (Enterprise Application Access) von Akamai auswirkt. Wir behandeln unseren Ermittlungs-, Behebungs- und Offenlegungsprozess für die Schwachstelle. Einen Überblick über die Schwachstelle, die Auswirkungen auf Akamai, die Auswirkungen auf EAA-Kunden und die erforderlichen Maßnahmen finden Sie in unserem Begleitbericht.

Übersicht

In diesem Abschnitt führen wir Sie durch die Geschichte und Anatomie dieser Schwachstelle. Einige Leser werden diesen Abschnitt zunächst überspringen und direkt zum Abschnitt „Erforderliche Maßnahmen“ wechseln. Verwenden Sie diese Übersicht als Referenz für alle Bewertungen, die sie durchführen müssen, oder für zukünftige Bewertungen.

Vor der Übernahme von Soha Systems und damit auch der EAA-Technologie durch Akamai im Jahr 2016 wurde eine Schlüsselfunktion in die Plattform eingeführt, mit der Plattformkunden Zugriffskontroll- und Authentifizierungsentscheidungen basierend auf Identitätsdaten von Drittanbietern treffen können. Die EAA-Plattform bietet mehrere Methoden für die Integration von Identitäten von Drittanbietern. Die wichtige Methode für diesen Bericht ist die Unterstützung des Authentifizierungsprotokolls SAML 2.0 (Security Assertion Markup Language).

SAML ist ein weitverbreiteter offener Standard. SAML ermöglicht es einem Identity Provider (IdP), einem Service Provider (SP) durch kryptografische Signierung und Rücksendung eine Assertion bereitzustellen, indem der IdP dem SP über den Client innerhalb einer bestimmten Zeitspanne ein Assertionsobjekt vorlegt. (Weitere Informationen finden Sie unten im Abschnitt „Hintergrund“.)

Als Drittanbieter-IdP-Unterstützung zu EAA hinzugefügt wurde, wählten die Entwickler die Open-Source-Bibliothek Lasso aus, um SAML-Unterstützung innerhalb der Plattform zu implementieren. Basierend auf der Bewertung des Codes, in dem Lasso die SAML-Antworten als SP überprüft, glauben wir, dass die Entwickler, die die Drittanbieter-IdP-Funktion implementierten, dies zum Zeitpunkt der ersten Integration auf der Grundlage der mit der Bibliothek bereitgestellten Testfälle angemessen getan haben. Weitere Untersuchungen haben ergeben, dass die Testsuite, die für die Implementierung von Akamai verwendet wurde, nicht gründlich genug war, um diese Identitätsdiebstahl- oder ähnliche Schwachstellen im Authentifizierungsprozess zu identifizieren. Dieser Mangel wurde im Rahmen unserer Reaktion behoben. Hierzu wurde die Testsuite, die auf neue Produkteinführungen angewendet wird, erweitert, um alle Kombinationen gültig und ungültig signierter Antworten und/oder Assertionen sowie aller nicht signierten Antworten und Assertionen einzubeziehen. Diese neuen Tests sind in Zukunft Teil des standardmäßigen QS-Prozesses.

In den folgenden Abschnitten des Berichts werden die verschiedenen Schwächen und Einflussfaktoren aufgegliedert, die die Gesamtanfälligkeit ausmachten. Unser Ziel bei der Bereitstellung dieser Transparenz ist es, anderen dabei zu helfen, die Schritte von Akamai zu verstehen und ähnliche Umstände in ihren eigenen Umgebungen zu vermeiden.

Systemtests und -bewertungen

Unit-Tests, Integrationstests und Regressionstests sind kritische Aspekte jedes Softwareentwicklungslebenszyklus (Software Development Lifecycle, SDLC). Obwohl die implementierte Unterkomponente alle diese Testmethoden aufwies, haben wir eindeutig gelernt, dass die Tests nicht streng genug waren. Darüber hinaus hat dieser Vorfall einen Fehler aufgedeckt, über den einige Bibliotheken Dritter – unter der falschen Annahme, dass der SDLC der Abhängigkeit selbst streng ist und durch domainspezifische Entdeckungen wie Schwachstellen in ähnlichen Bibliotheken informiert wird – in Projekte aufgenommen werden.

Zwar ist ein strenger SDLC für jede Komponente und jede ihrer Abhängigkeiten erforderlich, aber oft reichen die Tests, die in den Komponentenentwicklungs- und QS-Plan (Qualitätssicherung) integriert sind, nicht aus. Als Ergänzung zu diesen Tests können sogenannte Adversarial Assessments wie Penetrationstests oder Codeüberprüfungen von Drittanbietern angewendet werden. Im Fall von EAA wurden mehrere externe Sicherheits- und Schwachstellenbewertungen der EAA-Plattform über die Lebensdauer des Produkts durchgeführt, häufig von Kunden. Dennoch wurde diese Schwachstelle Akamai zum ersten Mal in dem Bericht gemeldet, der diese Reaktion startete. Akamai hat gezielte Bewertungen für andere Teile der EAA-Plattform und ihre Clientanwendung durchgeführt, aber diese spezielle Komponente wurde nicht mit der gleichen Genauigkeit überprüft.

Vermeidung einer vorzeitigen Offenlegung

Schon früh in diesem Vorfallsreaktionsprozess verfasste Akamai eine Kundenbenachrichtigung, um Kunden dabei zu unterstützen, die Untersuchungen durchzuführen, die im Abschnitt „Erforderliche Maßnahmen“ im Begleitpostvorgeschlagen werden. In einer Prüfung dieses Dokuments vor seiner Veröffentlichung erhielten die Mitarbeiter von Akamai, die noch nicht über die Schwachstelle informiert waren, eine Kopie der Kundenbenachrichtigung. Innerhalb einer Stunde nach der Übermittlung der Benachrichtigung konnten unsere Prüfer das betroffene Protokoll (SAML) sowie das Paket (Lasso) identifizieren und anhand kürzlicher Aktivitäten des Lasso-Projektverwalters Vermutungen darüber anstellen, worin die Schwachstelle bestand. Nach dieser Erkenntnis haben wir die eingeschränkte Benachrichtigung sofort aufgegeben, um die Grundsätze einer verantwortungsvollen Offenlegung zu befolgen. 

Nach weiteren Gesprächen mit unseren Prüfern konnte das Vorfallsteam den Prozess erlernen, mit dem die Prüfer diese Entdeckungen gemacht hatten. Ein wichtiger Fund der Prüfer war die Fehlermeldung, die vom IdP zurückgegeben wurde, wenn eine Fehlerbedingung auftrat. Bis die Korrektur der Schwachstelle veröffentlicht wurde, gaben SAML-Fehler eine Fehlerseite zurück, auf der Endnutzern der Lasso-Fehler angezeigt wurde (siehe Abbildung unten). Die Weiterleitung eines Fehlers – insbesondere für kritische Sicherheitsprozesse wie die Authentifizierung – widerspricht den Best Practices, weshalb der Fehler für Endnutzer ab dieser Version nicht mehr sichtbar ist. 

Das obige XML-Dokument wurde für die Zwecke dieses Berichts vereinfacht, aber die Struktur ist unverändert. Das äußere, „übergeordnete“ Dokument ist die SAML-Antwort, mit Metadaten zur Anfrage und einem Assertionsdokument. Die Assertion, auch SAML-Assertion genannt, umfasst die Daten, die vom IdP an den SP zur Verwendung im Authentifizierungsprozess bereitgestellt werden. In einer einzelnen SAML-Antwort können mehrere Assertionen vorhanden sein. Im obigen Beispiel ist der Inhalt der ds:Signature-Klammern eine kryptografische Signatur über dem Inhalt im übergeordneten Objekt, was in diesem Fall die Assertion ist. Dasselbe Signaturobjekt kann auch auf das gesamte Antwortobjekt angewendet werden. Mit der Signatur kann der SP validieren, dass die in der Assertion oder Antwort enthaltenen Daten legitim sind und vom IdP bereitgestellt wurden. Im Fall der Assertion gilt die Signatur nur für alle in der Assertion enthaltenen Daten wie Nutzername, E-Mail-Adresse oder Hinweise auf Gruppenmitgliedschaft. Die auf Antwortebene angewendeten Signaturen gelten für den vollständigen Inhalt der Antwort und alle darin enthaltenen Assertionen.

Die Verifizierung der verschiedenen Signaturen in der SAML-Antwort wird dem SP anvertraut und oft zu dem Zeitpunkt konfiguriert, zu dem der IdP für die Kommunikation mit der Anwendung konfiguriert wird. Nach unserer Reaktion auf das Problem glauben wir, dass die Standard-Verifizierungsbedingungen für SAML-Antworten wie folgt lauten sollten:

• Wenn die gesamte SAML-Antwort gültig signiert ist, müssen alle Assertionen in der Antwort korrekt signiert sein oder keine Signatur aufweisen. Wenn ungültige Signaturen gefunden werden, muss die Verifizierung fehlschlagen. Diese Methode basiert darauf, dass der IdP für den gesamten signierten Nachrichtentext autoritativ ist.
• Wenn die SAML-Antwort nicht signiert ist, müssen alle Assertionen in der Antwort korrekt signiert sein. Andernfalls darf die Verifizierung nicht erfolgreich sein.
• Wenn die SAML-Antwort eine ungültige Signatur aufweist, darf die Verifizierung nicht erfolgreich sein.

Die oben genannten Verarbeitungsbedingungen entsprechen dem von Akamai vorgeschlagenen Patch für Lasso.

Der Bericht, der Akamai zu Beginn dieses Problems zur Verfügung gestellt wurde, zeigte, dass der Forscher zwei SAML-Assertionen in einer einzigen SAML-Antwort eingereicht hatte, wobei die erste gültig signiert war, die zweite jedoch unsigniert. Die Standardkonfiguration für Lasso hatte die folgenden Standard-Verifizierungsbedingungen.

• Wenn die erste SAML-Assertion in der Antwort gültig signiert wurde, war die Verifizierung erfolgreich – egal, ob die vollständige SAML-Antwortsignatur gültig war oder nicht.
• Wenn die erste SAML-Assertion ungültig signiert wurde, war die Verifizierung nicht erfolgreich.
• Wenn die SAML-Antwort gültig signiert und keine der Assertionen signiert wurde, war die Verifizierung erfolgreich.
• Andernfalls schlug die Überprüfung fehl.

 Noch komplizierter wurde das Ganze durch die Tatsache, dass die Funktion zum Abrufen der Assertion aus der SAML-Antwort die letzte Assertion im Antwortobjekt zurückgab, wenn die Antwort von der Bibliothek als gültig erachtet wurde – unabhängig davon, ob die Assertion eine gültige Signatur aufwies. Beispiel: Ein Angreifer erhält wie oben beschrieben eine gültige SAML-Antwort mit einer einzelnen Assertion von einem IdP und fügt Folgendes als zweite Assertion hinzu:

Wenn der angegebene Nutzer für die Organisation gültig ist, aber mehr Berechtigungen hat, erhält der Angreifer die kombinierte SAML-Antwort zur Weiterleitung an den SP:

Wenn Lasso versuchte, diese SAML-Antwort zu validieren, kam dabei heraus, dass die Antwort gültig war. Wenn die aufrufende Anwendung die Assertion aus der obigen Antwort abrief, wurde die Assertion mit der Nutzer-ID (UID) des Superusers zurückgegeben und wahrscheinlich als gültige Assertion betrachtet. Wenn die SAML-Antwort selbst über eine gültige Signatur verfügte, waren neben dem oben gezeigten Beispiel auch Methoden zum Identitätswechsel möglich. Dies war bei der Verarbeitung von SAML-Antworten durch EAA der Fall. 

Ausnutzungsbedingungen

Damit die SAML-Antwort vor der Übermittlung an den SP geändert werden kann, muss eine der folgenden Bedingungen erfüllt sein:

• Der legitime Client, der von einem gültigen autorisierten Nutzer kontrolliert und über den eine SAML-Antwort weitergeleitet wird, muss die SAML-Antwort ändern, indem das zusätzliche Assertionsdokument als Teil der SAML-Antwort injiziert wird. Dies kann beispielsweise über eine schädliche Browsererweiterung oder andere Malware auf dem Clientsystem erfolgen, die manchmal auch als „Man-in-the-Browser“-Angriff bezeichnet werden.
• Der Angreifer braucht eine Kopie einer SAML-Antwort, die noch gültig ist – entweder weil noch Zeit bleibt, bevor die Assertion abläuft, oder weil die Assertion in einigen Anwendungen noch nicht vorgelegt wurde. Eine Zwischenpartei kann beispielsweise eine SAML-Antwort über einen Proxy abfangen und ändern. Dies wird oft als „Man-in-the-Middle“-Angriff bezeichnet.
• Ein nicht autorisierter Client kennt die Anmeldeinformationen eines autorisierten Nutzers oder kann sie erraten. Anmeldeinformationen können über viele Verfahren erfasst werden, darunter Phishing, Passwortdiebstahl, Raten oder Brute-Force-Angriffe.

Jede der oben genannten Bedingungen könnte dazu führen, dass die Sitzung eines Nutzers kompromittiert wird, und wenn die SAML-Implementierung wie oben beschrieben fehlerhaft ist, ist der SP anfällig für einen Identitätsdiebstahl.

Geschichte der Schwachstelle

Diese Sicherheitslücke, auch bekannt als XML-Signatur-Wrapping, wurde immer und immer wieder gemeldet. 

Die Überprüfung der Lasso-Repositorys deutet darauf hin, dass die Schwachstelle in der Bibliothek bereits im November 2005 in die Codebase integriert wurde – weit vor unserer Aufnahme der Bibliothek und auch vor der Veröffentlichung der vorherigen Schwachstellen, die für andere Plattformen bekannt gegeben wurden.

Während der Untersuchung stellten wir außerdem fest, dass Verwalter der Lasso-Bibliothek einen Commit im Projekt durchgeführt hatten, kurz nachdem die Benachrichtigung über das Problem an Akamai gesendet worden war. Gespräche mit dem Berichterstatter ergaben, dass dieser Commit überhaupt nicht mit seinem Bericht in Zusammenhang stand, sondern lediglich Zufall war.

Die am 24. Februar 2021 vorgeschlagene Lösung hat die Auswirkungen des Exploits teilweise behoben, aber nach weiterer Überprüfung haben wir festgestellt, dass es sich nicht um eine vollständige Lösung handelte. Daher wurde unser Patch letztendlich den Verwaltern vorgeschlagen.

Ein Blick auf die Vorfallsreaktion von Akamai

Akamai verfolgt einen formellen Prozess zur Reaktion auf Vorfälle. Vorfälle werden regelmäßig durch die Kooperation von Mitarbeitern in den Bereichen Technik/Systementwicklung, Netzwerkbetrieb und Kundensupport bearbeitet. Im Allgemeinen gilt: Je schwerwiegender der Vorfall, desto mehr Mitarbeiter sind daran beteiligt und desto stärker wird er gegenüber geplanten Betriebsabläufen und Arbeiten priorisiert. Bei allen Vorfällen verfolgt Akamai folgende Ziele: 

• Auswirkungen des Problems begrenzen 
• kontinuierlichen, sicheren Betrieb unserer Systeme gewährleisten
• kontinuierliche, sichere Arbeit unserer Vorfallsteams gewährleisten
• Kunden zufriedenstellen und ihre Daten schützen
• Gesetze und Vorschriften einhalten
• sicherstellen, dass wir in der Lage sind, aus den Gefahren zu lernen, die den Vorfall ermöglicht haben, und uns dadurch zu verbessern

Wie oben beschrieben, haben wir nach der Benachrichtigung über diese Schwachstelle unseren Vorfallsreaktionsprozess aktiviert. Dieser Prozess ermöglichte es Akamai, technische Ressourcen aufeinander abzustimmen, mit internen und externen Stakeholdern sowie dem Management zu kommunizieren und alle Aktivitäten im Zusammenhang mit dem Vorfall zeitnah und effektiv zu koordinieren.

Patching- und Bereitstellungsprozess

Der Prozess zur Entwicklung einer Lösung für diese Schwachstelle und zur Bereitstellung des Patches im EAA-Netzwerk war dem normalen Prozess für geplante Upgrades sehr ähnlich. Er umfasste jedoch eine deutlich kleinere Änderung und konnte daher erheblich schneller erfolgen.

Innerhalb der ersten Stunden nach der Vorfallsreaktion haben wir einen Zeitplan für die Problembehebung vorbereitet, in dem einige wichtige Entscheidungen berücksichtigt wurden. Dieser Zeitrahmen nach Abschluss der Fehlerbehebung lautete: Der QS-Prozess würde voraussichtlich 3 Tage nach dem QS-Standardprozess dauern, und die Bereitstellungsphase würde 48 Stunden betragen. Nach der Bereitstellungsphase haben wir die Kommunikation des Problems in Form eines Blogbeitrags sowie in Form von Kundenbenachrichtigungen geplant. Diese Zeitpläne hätten verkürzt werden können, aber da es keine Hinweise auf eine aktive Ausnutzung gab, haben wir die Stabilität unseres Netzwerks priorisiert und sichergestellt, dass die Systeme unserer Kunden während des gesamten Prozesses stabil blieben.

Nach der ersten Sichtung des Problems hat das Technikteam über zwei Wege an einer Lösung gearbeitet: mit unterschiedlichen Engineering- und QS-Ressourcen. 

Ein Team untersuchte und entwickelte eine Teillösung für das Problem und schloss das gemeldete Problem. Es beschränkte die Anforderungen der Verarbeitung von SAML-Antworten auf eine unserer Meinung nach normale Darstellung einer SAML-Antwort mit einer Assertion. Diese Methode hat möglicherweise dazu geführt, dass einige Antworten von einigen IdPs abgelehnt wurden, selbst wenn sie gültig und sicher waren. Dieser Ansatz bot auch die Option, die strengere Prüfung auf Kundenbasis zu deaktivieren, um den Rest des Kundenstamms im Falle einer unerwarteten Interaktion mit einer kleinen Anzahl von IdPs zu schützen.

Das andere Team verfolgte einen ähnlichen Ansatz wie das erste Team, arbeitete aber nicht an einer konfigurierbaren Teillösung, sondern an einer Lösung, die unserer Ansicht nach vollständig ist. Ihr Ansatz wurde überprüft, um sicherzustellen, dass alle korrekt formatierten und signierten SAML-Antworten akzeptiert werden, wodurch die Komplexität reduziert wird, die erforderlich ist, um Kunden ein Downgrade zu ermöglichen.

Wir haben diesen dualen Ansatz gewählt, da wir so – selbst wenn der eine Pfad erfolglos ist oder QS-Herausforderungen verursacht – über den zweiten Pfad weiterhin eine Lösung bereitstellen können. Die Teillösung sollte am 24. Februar gegen Ende des Tages (nach US-amerikanischer Zeit [EST]) für die QS bereitstehen – drei Tage nach Beginn des Vorfalls. Die Entwicklung der vollständigen Lösung würde voraussichtlich eine Woche länger dauern. Die Arbeit dauerte bis in die Nacht des 25. Februars hinein. Zu diesem Zeitpunkt zeigte der Fortschrittsbericht des Technikteams, dass die vollständige Lösungsoption gut vorankam und letztendlich eine schnellere Entwicklung und weniger komplexe Tests zu erwarten waren.

Die vollständige Lösungsoption wurde etwa einen Tag vor der Teillösung an das QS-Team übergeben. Nach der Übergabe der ersten Option an das QS-Team wurde eine Patch-Benachrichtigung an alle EAA-Kunden gesendet, in der der erwartete Zeitrahmen für die Bereitstellung vermerkt wurde.

Dieser Status blieb während des QS-Prozesses gleich. Kurz vor dem Wartungsfenster erhielt die vollständige Lösung die Genehmigung des QS-Teams, was den Weg für die Bereitstellung freigab.

Der Bereitstellungsprozess begann mit einem sehr leicht beladenen Point of Presence (POP), auf dem wir eine erweiterte Regressionssuite ausführten, bei der der Traffic sorgfältig auf mögliche Unterbrechungen für Kunden überwacht wurde. Ein weiterer leicht beladener POP wurde mit einem reduzierten Testprozess und einem festgelegten Überwachungszeitraum aktualisiert. Frühmorgens am 2. März wurden die POPs aktualisiert, die die interne EAA-Bereitstellung von Akamai durchführten, um mehr Lasttests mit unseren fast 8.000 Endnutzern zu ermöglichen. Nachdem wir bei keiner der Bereitstellungen Probleme verzeichnet hatten, wurden die restlichen POPs über die verbleibenden 36 Stunden des Wartungsfensters aktualisiert. So wurde der Bereitstellungsprozess letztendlich vor dem Schließen des Wartungsfensters abgeschlossen. 

Während des Upgradeprozesses traten bei den meisten Nutzern, die mit ihren EAA-Anwendungen interagierten, wahrscheinlich eine oder mehrere erneute Authentifizierungsinteraktionen auf.  Diese bestehen in der Regel aus einer vorübergehenden Sitzungsunterbrechung und einer Umleitung zu ihrem IdP, wo sie ihre Zugangsdaten eingeben müssen, bevor sie zu ihrer normalen Arbeit zurückgeleitet werden. Nutzer des EAA-Clients haben dieses Verhalten möglicherweise ebenfalls beobachtet. Während der Bereitstellung traten vermehrt Neuauthentifizierungsversuche von EAA-Kunden auf. Nach dem Codeupgrade auf jedem POP wurde der Sitzungscache, den EAA verwaltet, gelöscht, was über einen Zeitraum von fünf Minuten eine erneute Authentifizierung für alle Anfragen auslöste. Nach der erneuten Authentifizierung konnten wir keine weiteren Auswirkungen auf Endnutzer feststellen.

Management des Vorfallsteams

Ein wichtiger Aspekt bei der Entwicklung, Überprüfung und sicheren Implementierung der Lösung in unserem Netzwerk bei erheblichen Problemen wie diesem ist die sorgfältige Betreuung des Teams, das an dem jeweiligen Problem arbeitet. Der Vorfallsmanagementprozess von Akamai und die begleitende Schulung enthalten Anleitungen zur Verhinderung von Burn-outs der Technik- und Managementteams, die auf Vorfälle reagieren. Diese Anleitung beinhaltet die Überprüfung, ob das Vorfallsteam …

• regelmäßig isst
• schläft (im Idealfall eine ganze Nacht lang)
• sich um persönliche Verpflichtungen kümmert
• gesund bleibt (COVID-19-Impfstoffe, Sport)

Die Behebung des Vorfalls ist zwar von entscheidender Bedeutung, wir haben jedoch festgestellt, dass die richtige Teambetreuung während des gesamten Prozesses dazu beiträgt, eine sicherere Lösung für das betroffene Produkt und/oder System zu schaffen und gleichzeitig die Anzahl vermeidbarer Fehler sowie potenziell kundenrelevanter Ereignisse zu reduzieren, die häufig mit der stressigen Vorfallsreaktion verbunden sind.

Ein weiterer wichtiger Aspekt des Vorfallsmanagementprozesses von Akamai ist das Prinzip, dass wir alle gemeinsam daran arbeiten und dass wir jetzt oder in Zukunft niemanden beschuldigen werden. Das Vorfallsteam arbeitet zusammen, um das Problem zu lösen – egal, worin dieses Problem besteht. Es konzentriert sich zunächst darauf, die Auswirkungen zu reduzieren, und findet dann heraus, wie man es künftig verhindern kann. Akamai konzentriert sich darauf, Annahmen zur Ursache des Vorfalls zu finden, aus diesen unvollständigen Annahmen zu lernen und die entsprechenden Änderungen vorzunehmen, um die Wahrscheinlichkeit zu verringern, dass diese oder ähnliche Ereignisse erneut auftreten.

Aktionen erforderlich

Systembesitzer, die Lasso für ihre SAML-Authentifizierung verwenden, sollten so schnell wie möglich einen Patch installieren. Es können zusätzliche Maßnahmen erforderlich sein, um die Auswirkungen auf die authentifizierten Systeme zu untersuchen. Weitere Informationen darüber, welche Maßnahmen erforderlich sein können, finden Sie im Abschnitt „Erforderliche Maßnahmen“ im Begleitpost zu diesem Schreiben.

Zeitachse