Sicherheitslücke bei SAML-Implementierung, die sich auf einige Akamai-Services auswirkt
Dieser Blogbeitrag bietet einen Überblick über eine Schwachstelle, die im gepatchten EAA-Produkt (Enterprise Application Access) von Akamai entdeckt wurde. Diese Sicherheitslücke könnte es einem Kriminellen ermöglicht haben, sich bei der Interaktion mit einer Anwendung, die Security Assertion Markup Language Version 2 (SAML v2, in diesem Dokument als SAML bezeichnet) zur Authentifizierung von Nutzern verwendete, als autorisierter Nutzer auszugeben.
Nach der ersten Benachrichtigung eines Drittanbieters erkannten die Techniker von Akamai, dass die Schwachstelle in Lassovorhanden war, einer Open-Source-Bibliothek eines Drittanbieters, in die das SAML-2.0-Authentifizierungsprotokoll implementiert war. Lasso ist die Bibliothek, die Akamai EAA verwendet, um SAML-Assertionen für Anwendungen zu überprüfen, wenn ein Kunde die SAML-Authentifizierung mit Drittanbieter-IdPs (Identity Providers) konfiguriert. Eine weitere Untersuchung der Lasso-Bibliothek ergab, dass die Schwachstelle größere Auswirkungen auf andere Software hatte, die Lasso als Abhängigkeit aufwies.
Ab 4. März 2021 wurde eine umfassende Lösung im EAA-Netzwerk implementiert. Für die EAA-Connector-Appliances oder den EAA-Client waren keine Updates erforderlich. Akamai hat festgestellt, dass die SOGo- und PacketFence-Pakete – die von Inverse verwaltet werden, einem Unternehmen, das kürzlich von Akamai übernommen wurde – für Bereitstellungen mit SAML-Authentifizierung ebenfalls von Lasso abhängig sind. Das SOGo-Paket war außerdem von einer anderen unabhängigen, aber damit verbundenen Schwachstelle betroffen: CVE-2021-33054. Informationen zu den Auswirkungen auf SOGo und PacketFence finden Sie hier. Wir haben überprüft, dass alle anderen externen Anwendungen von Akamai, einschließlich Akamai Control Center, nicht anfällig für diesen Angriffsvektor sind.
Der Lasso-Sicherheitslücke wurde die folgende CVE-ID zugewiesen: CVE-2021-28091. Aufgrund der Schwere dieser Sicherheitslücke fordert Akamai alle EAA-Kunden, die die SAML-Authentifizierungsfunktion von EAA für ihre Anwendungen nutzen, dazu auf, ihre Systeme auf einen möglichen früheren Identitätsdiebstahl durch einen internen Akteur zu überprüfen. Akamai empfiehlt außerdem dringend, dass alle Nutzer der Lasso-Bibliothek oder von Software, die von Lasso abhängig ist, ihre Ankündigung zu überarbeiten und den Patch so bald wie möglich zu installieren und ihre Anwendungen auf Zugriff mit gestohlenen Identitäten zu überprüfen. Der Fix ist in Lasso 2.7.0 verfügbar. Vorschläge zur Durchführung einer Untersuchung potenziell betroffener Systeme sind im Abschnitt „Erforderliche Maßnahmen“ weiter unten aufgeführt.
Detaillierte Informationen über die Schwachstelle sind in einem technischen Begleitblog dokumentiert. Er deckt die technischen Details sowie die Erkennungs-, Selektierungs-, Patching- und Benachrichtigungsprozesse für diese Schwachstelle ab.
Als Teil der Problembehebung fügte Akamai Protokollierung für falsch signierte SAML-Antworten hinzu. Zum Zeitpunkt der Veröffentlichung stellten Fälle falsch signierter SAML-Antworten, die auf der EAA-Plattform protokolliert wurden, keine Anzeichen für eine Gefährdung dar, sondern bezogen sich auf die Einrichtung von Konfigurationen, in denen Fehler erwartet wurden, sowie auf Tests, um zu überprüfen, ob die Schwachstelle behoben wurde.
Eine kurze Erläuterung der Schwachstelle
Diese Sicherheitslücke wurde ausgelöst, wenn eine SAML-Antwort an einen SAML-Serviceprovider (SP) übergeben wurde, an die eine zusätzliche, nicht signierte Assertion am Ende des SAML-Antwortinhalts angehängt war. Dieses Verhalten war möglich, wenn ein Angreifer eine nicht signierte, aber anderweitig richtig formatierte Assertion für einen anderen Nutzer am Ende des SAML-Antwortdokuments injiziert hatte.
Diese Schwachstelle ermöglichte es Akteuren mit Zugriff auf eine richtig formatierte SAML-Antwort für eine Organisation – in der Regel authentifizierte Nutzer, aber potenziell auch kompromittierte Endpoints oder schädliche Proxys –, ihre Identität zu ändern und sich als anderer Nutzer innerhalb derselben Organisation auszugeben. Die SAML-Antwort oder ihre einzelnen Assertionen konnten signiert sein, aber der vom Angreifer eingefügte Teil der SAML-Antwort musste nicht signiert sein, damit der Angriff erfolgreich war. Um dieses Problem auszunutzen, musste der Angreifer gültige Zugangsdaten für einen Identity Provider (IdP) oder die Zugangsdaten zur Authentifizierung als gültiger Nutzer besitzen. Wir kategorisieren die potenziellen Auswirkungen auf vier Arten: Netzwerkzugriff über eine andere Identität (nicht authentifiziert und authentifiziert), Anwendungszugriff über eine andere Identität sowie eine alternative Lasso-Abhängigkeit für Anwendungen, die auf der Lasso-Bibliothek basieren, wie unten beschrieben.
Auswirkungen der Schwachstelle
Die folgenden drei Auswirkungskategorien gelten für Akamai EAA:
Bei EAA-Konfigurationen, in denen SAML zur Authentifizierung bei Akamai verwendet wurde, um Entscheidungen über den Anwendungszugriff zu treffen, hätten nicht autorisierte Nutzer über das Netzwerk auf die Anwendungen zugreifen und dabei Anwendungs-ACLs (Access Control Lists) oder andere Zugriffskontrollen umgehen können. Dies entspricht funktionell dem Vorgang, bei dem ein Angreifer mit gestohlener Identität das Zielsystem im Local Area Network erreichen kann. Dieser Angriff wird in diesem Bericht als imitierter Netzwerkzugriff bezeichnet. Die mit dem imitierten Netzwerkzugriff verbundenen Risiken hängen von der Art der Anwendungen ab, auf die zugegriffen wird:
(1) Nicht authentifizierte Anwendungen: Die damit verbundenen Risiken sind dieselben wie bei allen Anwendungen, bei denen Endnutzer vollen Zugriff haben, sobald sie sich im lokalen Netzwerk befinden.
(2) Authentifizierte Anwendungen: Die Risiken für diese Art von Anwendung sind naturgemäß geringer, da die Anwendung ihre eigene Authentifizierung implementiert.
Bei EAA-Konfigurationen, die die Anmeldeinformationen für die Anwendung selbst erweitern – durch Verwendung anwendungsorientierter Authentifizierungsmechanismen wie eingeschränkter Kerberos-Delegierung, Header-Authentifizierung oder OpenID Connect –, kann der Nutzer der Anwendungssitzung die Identität eines anderen Nutzers annehmen. Dieser Vorgang wird in diesem Bericht als (3) imitierter Anwendungszugriff bezeichnet.
Bei Anwendungen, die in die oben genannten Kategorien fallen, waren nur diejenigen angreifbar, die SAML für die Kommunikation mit einem Drittanbieter-IdP verwendeten, der Akamai Assertionen bereitstellte. EAA-Anwendungen, die andere Authentifizierungsmechanismen wie OpenID Connect (OIDC) oder OAuth verwenden, um mit Drittanbieter-IdPs zu kommunizieren, verwenden nicht den anfälligen Bereich von Lasso. Darüber hinaus waren Anwendungskonfigurationen, die die IdP-Funktion von Akamai verwendeten, nicht anfällig für diese Schwachstelle. Weitere Einzelheiten zur Schwachstelle in der Bibliothek finden Sie in unserem Begleitblog.
Eine Überprüfung unserer Software ergab, dass diese Sicherheitslücke seit Version 1.0, die in Q1 2014 veröffentlicht wurde, im EAA-Service bestand. Prüfer sollten davon ausgehen, dass die Schwachstelle ab dem Zeitpunkt vorhanden war, an dem die Drittanbieter-SAML-Unterstützung in der Konfiguration des Kunden hinzugefügt wurde, und bis zum 5. März 2021 bestand, als das Patching des EAA-Netzwerks abgeschlossen wurde.
Die endgültige Kategorie der Schwachstelle gilt für Elemente, die die Lasso-Bibliothek verwenden. Die meisten Anwendungen, die die Lasso-Bibliothek für die SAML-Authentifizierung verwenden, unterliegen möglicherweise dieser Sicherheitslücke durch Nutzernachahmung. Dies wird in diesem Bericht als (4) alternative Lasso-Abhängigkeit bezeichnet.
Zeitrahmen für Identifizierung, Patching und Offenlegung
Am Dienstagabend, dem 23. Februar 2021, erhielt Akamai eine Benachrichtigung über dieses Problem von einem Techniker im Enterprise Information Protection Team von Best Buy. Kurz nach Erhalt der Benachrichtigung überprüfte das Information Security Team von Akamai den Bericht und startete den Vorfallsmanagementprozess. Zwischen dem Beginn des Vorfalls und der Benachrichtigung über den Kundenpatch früh morgens am 27. Februar 2021 (UTC) reproduzierten die Techniker von Akamai das im Bericht beschriebene Problem, implementierten die Lösung und starteten die Untersuchung der Kundenauswirkungen. Akamai hat seine Kundenbenachrichtigung zum Patch kurz nach 1:00 Uhr (UTC) veröffentlicht, etwa eine Stunde nach der Übergabe des Problems an unser QS-Team. Unser QS-Team startete dann die Überprüfung der Problembehebung und gewährleistete die Stabilität der neuen Version vor der geplanten Einführung. Der Roll-out begann am 2. März und wurde am 4. März abgeschlossen.
Während der Untersuchungs- und Korrekturphasen der Reaktion haben wir festgestellt, dass die Schwachstelle auf unserer Plattform mit der Lasso-Bibliothek in Verbindung stand. Eine weitere Untersuchung der Lasso-Bibliothek ergab, dass die Schwachstelle möglicherweise größere Auswirkungen auf andere Software hatte, die Lasso als Abhängigkeit aufwies. Während wir an der Lösung der Sicherheitslücke in unserem Netzwerk gearbeitet haben, starteten die Ingenieure von Akamai und das Team für Informationssicherheit den Prozess, um das Problem verantwortungsbewusst gegenüber Verwaltern der Bibliothek und anderen verifizierten Nutzern von Lasso offenzulegen.
Um die Auswirkungen auf andere Nutzer der Bibliothek zu begrenzen, beschränkte Akamai die Kommunikation bezüglich der Schwachstelle auf diejenigen, die sich mit dem Patching und der koordinierten Offenlegung von Schwachstellen befassten. Die von uns angewandten Beschränkungen entsprechen den branchenüblichen Verfahren zur verantwortungsvollen Offenlegung und sollen die Wahrscheinlichkeit einer weiteren Ausnutzung der Schwachstelle verringern.
Während der Zeit zwischen der vollständigen Implementierung unseres Patches und der Veröffentlichung dieses Berichts arbeitete Akamai mit den Lasso-Verwaltern, den nachgelagerten Lasso-Nutzern sowie CERT/CC zusammen, um die zeitnahe Übermittlung dieses Problems an so viele betroffene Parteien wie angemessen zu koordinieren.
Aktionen erforderlich
Aufgrund der oben genannten Auswirkungen empfehlen wir, die folgenden Maßnahmen basierend auf den oben aufgeführten Auswirkungskategorien zu ergreifen.
Aktuelle oder ehemalige Kunden, einschließlich Kunden mit aktuellen oder früheren Testbereitstellungen, die zu einem beliebigen Zeitpunkt Drittanbieter-SAML-IdPs zur Authentifizierung bei EAA verwendet haben, sollten basierend auf den Auswirkungskategorien die folgenden Maßnahmen ergreifen:
Imitierter Netzwerkzugriff für nicht authentifizierte Anwendungen: Möglicherweise waren Nutzer, die einen anderen Nutzer für Systeme imitieren, für die keine Authentifizierung erforderlich ist, das Ziel von Exploits, bei denen Daten, Systemprozesse oder Anwendungsfunktionen extrahiert oder geändert werden sollten. Antworten auf diese Anwendungen sollten so behandelt werden, als ob ein Angreifer mit Zugriff auf gültige Nutzeranmeldeinformationen direkten LAN-Zugriff (Local Area Network) auf die entsprechende Anwendung hätte. Wenn für die Anwendung im EAA-Portal Gruppenbeschränkungen oder andere Nutzerkontrollen eingerichtet wurden, sollten die Einschränkungen überprüft werden, wobei berücksichtigt werden sollte, welche Aktionen Nutzer, die gegen diese Kontrolle verstoßen haben, durchführen konnten oder welche Sicherheitsziele mit dieser Kontrolle implementiert wurden.
Imitierter Netzwerkzugriff für authentifizierte Anwendungen: Ähnlich wie bei der vorherigen Kategorie ermöglichte diese Methode einem Nutzer, sich auf der Netzwerkverbindungsebene als anderer Nutzer auszugeben. Aufgrund der Natur der Anwendung, in die eine eigene Zugriffskontrolle und Autorisierung außerhalb des EAA-Systems implementiert ist, müssen diese Anwendungen möglicherweise weniger genau überprüft werden. Abgesehen von zusätzlichen Schwachstellen im eigenen Authentifizierungs- und Autorisierungssystem der Anwendungen bedeutet der direkte Netzwerkzugriff nicht sofort, dass ein Nutzer sich als anderer Nutzer ausgeben kann. Diese Anwendungen sollten hinsichtlich ihrer potenziellen Kategorisierung als alternative Lasso-Abhängigkeit (siehe unten) berücksichtigt werden.
Imitierter Anwendungszugriff : Anwendungen in dieser Kategorie sollten aufgrund der Art der in diesem Bericht beschriebenen Schwachstelle genauer untersucht werden. Diese Kategorie kann in zwei Formen vorliegen:
Die anwendungsbasierten Authentifizierungsmechanismen leiten die falsch verifizierte, imitierte Nutzeridentität an die Ursprungsanwendung weiter, sodass der Akteur alle Aktionen innerhalb der Zielanwendung ausführen kann – genauso wie der imitierte Nutzer. Dies gilt für Webanwendungen, die kein eigenes Authentifizierungssystem umfassen, sondern auf die Identitätsassertion der EAA-Plattform angewiesen sind.
Die Funktion zur automatischen RDP-Anmeldung (Remote Desktop Protocol) für RDP-Anwendungen, die vom Administrator bereitgestellte Anmeldeinformationen für den Zugriff auf den RDP-Ursprungsserver benötigt. Wenn der Nutzerzugriff auf eine RDP-Anwendung durch die Gruppenmitgliedschaft eingeschränkt wird, kann ein Nutzer die Identität eines anderen Nutzers in der zulässigen Gruppe annehmen, wobei er die angegebenen Zugangsdaten verwendet und so auf den RDP-Dienst zugreift, als ob es sich um den imitierten Nutzer handelt.
Administratoren des Ursprungssystems sollten diese Systeme genau untersuchen, um unerwartete Software oder Konfigurationen auszuschließen, die von einem Angreifer installiert worden sein könnten, einschließlich Malware, Rootkits oder Kernel-Erweiterungen. Administratoren sollten außerdem prüfen, ob diese Anwendungen es jemandem ermöglichen könnten, über ihre reguläre Autorisierung hinaus zusätzlichen Zugriff zu erhalten. Bei persistenten, langlebigen Sitzungen sollten Administratoren erwägen, alle diese langlebigen Verbindungen zu beenden, die vor 5. März 2021 gestartet wurden. Darüber hinaus sollten Administratoren bei Anwendungen, die Nutzerkonten, Access Control Lists, Autorisierungstoken, Sicherheitsinfrastruktur oder andere sensible/kritische Systeme verwalten, besonders darauf achten, dass keine unerwarteten Änderungen vorgenommen wurden.
Für Entwickler, Verwalter oder Administratoren von Software, die die Lasso-Bibliothek verwendet, empfiehlt Akamai, dass Sie aufgrund der oben aufgeführten Kategorie „Alternative Lasso-Abhängigkeit“ so schnell wie möglich ein Upgrade auf Lasso-Version 2.7.0 durchführen. Wie in den oben genannten Kategorien sollten Systemadministratoren die Aktionen von Endnutzern auf ungewöhnliche Nutzungsmuster überprüfen, da Versuche eines Identitätswechsels wahrscheinlich nicht protokolliert werden. Überwachen Sie Softwarepakete, die Lasso erfordern, auf Patching-Benachrichtigungen, wenn das Paket über einen festgelegten Verteilungskanal verfügt. Die aktualisierten Debian-, Ubuntu- und RedHat-Pakete werden voraussichtlich innerhalb von Stunden nach diesem Beitrag veröffentlicht, wenn nicht sogar vor Veröffentlichung dieses Berichts.
Beispiele dafür, wie die Schwachstelle ausgenutzt werden kann
Imitierter Netzwerkzugriff auf nicht authentifizierte Anwendungen
Die Verwendung von EAA für den Zugriff auf nicht authentifizierte Anwendungen bedeutet, dass EAA als Authenticator und Autorisierer fungiert, um Zugriff auf diese Anwendungen zu gewähren, ohne Authentifizierungsinformationen an sie zu übermitteln. Wenn eine Umgebung EAA verwendet, um den Zugriff auf nicht authentifizierte Anwendungen zuzulassen oder zu verweigern, können diese internen Anwendungen nicht erkennen, dass der vorliegende Nutzer nur imitiert wird.
In diesem Szenario müssen Administratoren überprüfen, welche Auswirkungen es hat, wenn Nutzer, die nicht berechtigt sind, auf die Anwendung zuzugreifen, eine Verbindung zur Anwendung herstellen können. Wenn die Anwendung beispielsweise nur öffentliche Informationen verarbeitet, wären die Auswirkungen gering. Wenn sie aber sensible oder regulierte Daten verarbeitet, können die Auswirkungen sehr umfangreich sein.
Außerdem müssen Administratoren der Anwendung ihre Protokolle auf Anwendungsebene auf Aktivitäten analysieren, die darauf hinweisen könnten, dass die Identität eines Kontos nachgeahmt wurde. Die Protokollanalyse kann Beispiele für Nutzeraktivitäten zeigen, die nicht den allgemeinen, regelmäßigen Nutzungsmustern entsprachen, wie z. B. Zugriff auf die Anwendung zu ungewöhnlichen Zeiten oder Zugriff auf Daten oder Prozesse in der Anwendung, auf die der Nutzer normalerweise nicht zugreifen würde.
Imitierter Netzwerkzugriff auf authentifizierte Anwendungen
Wenn EAA für den Zugriff auf Anwendungen verwendet wird, die ihre eigene Authentifizierung bereitstellen, ist das Risiko, das diese Sicherheitslücke bei der jeweiligen Anwendung verursacht, geringer als bei nicht authentifizierten Anwendungen. Eine erfolgreiche Imitation der EAA-Sitzung würde sich nicht auf die Authentifizierung auswirken, die von der Anwendung durchgeführt wird.
Die Protokollanalyse kann Beispiele zeigen, bei denen sich jemand über EAA als ein Nutzer und innerhalb der Anwendung als ein anderer Nutzer authentifiziert. Diese Analyse würde Administratoren Hinweise geben, ob jemand versucht hat, die Schwachstelle auszunutzen, um unbefugten Zugriff zu erhalten.
Administratoren von Anwendungen in dieser Kategorie sollten überprüfen, ob die von der Anwendung selbst vorgenommenen Authentifizierungen Lasso genutzt haben und somit möglicherweise auch in die Kategorie „Alternative Lasso-Abhängigkeit“ fallen.
Imitierter Anwendungszugriff
Wenn EAA die für die EAA-Sitzung verwendete Identität an eine Anwendung weitergibt, geht die Anwendung davon aus, dass die Identität validiert wurde. Wenn eine Anwendungssitzung mit einem imitierten Nutzer erstellt wird, geht die Anwendung davon aus, dass der imitierte Nutzer der echte Nutzer ist. In diesem Fall könnte eine erfolgreiche Nachahmung auftreten, wenn beim Weiterleiten von Identitätsinformationen an Ihre Anwendung die eingeschränkte Kerberos-Delegierung, die Header-Authentifizierung oder OpenID Connect (OIDC) verwendet wurden.
Im Fall der automatischen Anmeldefunktion für RDP-Anwendungen kann der Akteur, der eine andere Person imitiert, auf den RDP-Service zugreifen, als wäre er der imitierte Nutzer, wobei er die vom Administrator bereitgestellten Zugangsdaten verwendet, um sich mit dem Ursprungsservice zu verbinden. Zwar kann er die vom Administrator bereitgestellten Zugangsdaten nicht einsehen, doch der Zugriff auf das System wird so gewährt, als würde der imitierte Nutzer die Aktion ausführen.
Wie bei anderen Fällen könnte die Protokollanalyse Administratoren dabei unterstützen, Sitzungen zu finden, die aufgrund des Zeitpunkts und der Art der Aktivität ungewöhnlich sind.
Alternative Lasso-Abhängigkeit
Abgesehen von der Lasso-Abhängigkeit von EAA ist wahrscheinlich jede Anwendung, die Lasso nutzt, von dieser Schwachstelle betroffen. Entwickler sollten ihre Codebasis überprüfen, um herauszufinden, ob ihre Anwendungen die Lasso-Bibliothek nutzen. Wenn ja, sollten sie die Bibliothek aktualisieren oder die Auswirkungen so schnell wie möglich mindern. Wenn Sie sich auf eine Anwendung verlassen, die von Lasso abhängig ist, wird empfohlen, diese Anwendung auf Updates zu überwachen, sodass Administratoren Patches so bald wie möglich ausführen können. Diese Sicherheitslücke wurde in Lasso-Version 2.7.0 behoben.
Protokollierung und Forensik
Wie bereits im Abschnitt „Auswirkungen“ oben erwähnt, ist der Umfang der erforderlichen Maßnahmen ziemlich groß, was auf mehrere Faktoren zurückzuführen ist:
Das potenzielle Gefährdungszeitfenster für diese Schwachstelle erstreckt sich mindestens bis 2016, wenn nicht weiter.
Die EAA-Plattform archiviert Konfigurationen nur für einen Zeitraum von 90 Tagen, nachdem die Konfigurationen gelöscht oder ersetzt wurden. Daher kann Akamai bei EAA-Konfigurationen, die vor mehr als 90 Tagen deaktiviert wurden, nicht feststellen, ob sie die Bedingungen der Sicherheitslücke erfüllt haben.
Die Authentifizierungskomponente in EAA verfügte nicht über ausreichende Protokollierung, um festzustellen, ob diese Sicherheitslücke ausgenutzt wurde. Während unserer Tests dieser Schwachstelle unternahm Akamai mehrere Versuche, die verfügbaren Protokollierungsinformationen zu untersuchen, um festzustellen, ob die Ausnutzung zu erkennen war. Die protokollierten Informationen konnten jedoch die potenzielle Ausnutzung dieser Schwachstelle nicht bestätigen oder ausschließen. Um die potenzielle Gefährdung von Endnutzer-Authentifizierungstoken zu begrenzen und die Geheimhaltung und den Datenschutz von Kundenauthentifizierungstoken zu wahren, protokolliert Akamai außerdem nicht die SAML-Assertionen, die wir validieren.
Als Reaktion auf diese Behebung wurde der EAA-Plattform eine neue Protokollierung hinzugefügt, um fehlerhafte Authentifizierungsversuche zu erkennen – denn so würde sich dieser Angriff nach dem Patch für EAA bemerkbar machen. Zum Zeitpunkt der Veröffentlichung wurden alle betrügerischen Authentifizierungsversuche den Regressionstests nach der Bereitstellung, der Verifizierung der Problembehebung durch die meldende Partei, den Drittanbieter-IdPs mit abgelaufenen Zertifikaten sowie den falsch konfigurierten IdPs zugeordnet.
Vereinbarungen
Wir möchten uns bedanken bei:
Best Buy, seinem Enterprise Information Protection Team und Sam Tinklenberg, die uns die Schwachstelle der Nutzernachahmung in EAA gemeldet haben.
Entr’ouvert, die Verwalter der Lasso-Bibliothek, danken wir für ihre Unterstützung beim Patchen und Offenlegen dieser Schwachstelle sowie für ihre fortwährende Wartung der Bibliothek.
Wir danken CERT/CC dafür, dass sie uns dabei unterstützt haben, diese beiden Schwachstellen offenzulegen, und den verschiedenen Personen, die kontaktiert wurden, um schnell auf dieses Problem zu reagieren.
Zusätzliche Informationen
Wir empfehlen allen, die weitere Fragen haben, unseren Begleitpostzu lesen. Und EAA-Kunden, die weitere Fragen haben, können sich gern an den technischen Support von Akamai wenden.
