Der Ausfall von Amazons AWS-Cloud-Diensten am Montag dieser Woche bereitete nicht nur IT-Experten schlaflose Nächte, sondern etwa auch Besitzern von vernetzten Matratzen. Nun haben Amazons Techniker eine vollständige Analyse der Vorfälle veröffentlicht, die erklärt, wie es zu so weitreichenden Störungen kommen konnte.

Bereits der Titel der Amazon-Analyse weist auf einen Single-Point-of-Failure: „Zusammenfassung der Amazon DynamoDB-Dienst-Störung in der Region Nord Virginia (US-EAST-1)“. Der dort aufgetretene Fehler sorgte nicht nur für Ausfälle von Amazon-Diensten wie Streaming mit Prime oder Amazon Music, sondern legte etwa den Messenger Signal über Stunden lahm. Umso spannender ist, wie es dazu kommen konnte.

AWS-Ausfall: Detaillierter Fehlerverlauf

Während die Techniker bei Wiederherstellung des Normalbetriebs, den Amazon gegen kurz nach Mitternacht zum Dienstag, 21. Oktober, verkündete, bereits eine erste knappe Zusammenfassung des Vorfalls bereitgestellt haben, geht die jetzige Analyse deutlich in die Tiefe. Aus Amazons Sicht hat sich die Fehlerkaskade in drei Etappen abgespielt. Zwischen 8:48 Uhr mitteleuropäischer Sommerzeit am 20. Oktober 2025 und 11:40 Uhr lieferte Amazons DynamoDB erhöhte Fehlerraten bei API-Zugriffen in der Region Nord Virginia (US-EAST-1). Das war laut Amazon die erste Phase der Störung.

Die zweite Phase folgte zwischen 14:30 Uhr und 23:09 Uhr, während der der Network Load Balancer (NLB) erhöhte Verbindungsfehler bei einigen Load Balancern in Nord Virginia aufwies. Dies ging auf Health-Check-Fehler in der NLB-Flotte zurück, die zu diesen erhöhten Verbindungsfehlern führten. Zudem kam die dritte Phase von 11:25 Uhr bis 19:36 Uhr, in der das Starten neuer EC2-Instanzen nicht klappte. Bei einigen der EC2-Instanzen, die ab 19:37 Uhr anliefen, kam es jedoch zu Verbindungsproblemen, die ihrerseits bis 22:50 Uhr andauerten.

DynamoDB-Fehler

Die Probleme mit der DynamoDB erklärt Amazon mit „einem latenten Defekt“ im automatischen DNS-Management, wodurch die Namensauflösung der Endpunkte für die DynamoDB fehlschlug. „Viele der größten AWS-Dienste stützen sich in hohem Ausmaß auf DNS, um nahtlose Skalierbarkeit, Fehlerisolierung und -behebung, geringe Latenz und Lokalität zu gewährleisten. Dienste wie DynamoDB verwalten Hunderttausende von DNS-Einträgen, um eine sehr große heterogene Flotte von Load Balancern in jeder Region zu betreiben“, schreiben die Techniker. Automatisierung ist nötig, um zusätzliche Kapazitäten hinzuzufügen, sofern sie verfügbar sind, und um etwa korrekt mit Hardwarefehlern umzugehen. Zwar sei das System auf Resilienz ausgelegt, jedoch war die Ursache für die Probleme eine latente Race-Condition im DynamoDB-DNS-Management-System, die in einen leeren Eintrag für den regionalen Endpunkt „dynamodb.us-east-1.amazonaws.com“ mündete. Interessierte erhalten in der Analyse dazu einen tiefen Einblick in die DNS-Management-Struktur.

Sowohl der eigene als auch der Traffic von Kunden, die auf DynamoDB aufsetzen, war davon betroffen, da diese mangels korrekter Namensauflösung nicht mehr zu der DynamoDB verbinden konnten. Um 9:38 Uhr haben die ITler den Fehler im DNS-Management gefunden. Erste temporäre Gegenmaßnahmen griffen um 10:15 Uhr und ermöglichten die weitere Reparatur, sodass gegen 11:25 Uhr alle DNS-Informationen wiederhergestellt wurden.

Nicht startende EC2-Instanzen

Die EC2-Instanzen starteten ab 8:48 Uhr nicht mehr, da dieser von sogenannten DropletWorkflow Manager (DWFM) auf verschiedene Server verteilt werden. Die DWFM überwachen den Status der EC2-Instanzen und prüfen, ob etwa Shutdown- oer Reboot-Operationen korrekt verliefen in sogenannten Leases. Diese Prüfungen erfolgen alle paar Minuten. Dieser Prozess hängt jedoch von der DynamoDB ab und konnte aufgrund deren Störung nicht erfolgreich abschließen. Statusänderungen benötigen einen neuen Lease. Die DWFM versuchten, neue Leases zu erstellen, die jedoch zwischen 8:48 Uhr und 11:24 Uhr zunehmend in Time-Outs liefen. Nachdem die DynamoDB wieder erreichbar war, konnten die EC2-Instanzen jedoch mit dem Fehler „insufficient capacity errors“ nicht starten. Das Backlog der ausstehenden Leases erzeugte einen Flaschenhals, sodass neue Anfragen dennoch in Time-Out-Situationen kamen. Gegen 14:28 Uhr konnten die DWFM alle Leases zu allen Droplets genannten Instanzen wieder herstellen, nachdem Neustarts der DWFMs die Warteschlangen geleert hatte. Aufgrund einer temporären Anfragendrosselung, die die IT-Mitarbeiter zur Reduktion der Gesamtlast eingerichtet hatten, kam es jedoch etwa zu Fehlermeldungen der Art „equest limit exceeded“.

Die Droplets/EC2-Instanzen erhalten von einem Network Manager Konfigurationsinformationen, die ihnen die Kommunikation mit anderen Instanzen in der gleichen Virtual Private Cloud (VPC), mit VPC-Appliances und dem Internet erlaubt. Die Verteilung hatte durch die Probleme mit den DWFM ein großes Backlog erzeugt. Ab 15:21 Uhr kam es dadurch zu größeren Latenzen. Zwar starteten neue EC2-Instanzen, sie konnten mangels gültiger Netzwerkkonfigurationen jedoch nicht im Netzwerk kommunizieren. Das haben die ITler gegen 19:36 Uhr in den Griff bekommen, sodass EC2-Starts wieder „normal“ verliefen.

Verbindungsfehler durch Network Load Balancer

Die Network Load Balancer (NLB) von AWS nutzen ein Überwachungssystem (Health-Check-System). Sie umfassen Lastverteilung-Endpoints und verteilen Traffic auf die Backend-Systeme, bei denen es sich typischerweise um EC2-Instanzen handelt. Das Health-Check-System überprüft regelmäßig alle NLB-Knoten und entfernt alle Systeme, die dabei als „ungesund“ auffallen. Die Prüfungen schlugen bei der Störung jedoch zunehmend fehl, da die vom Health-Check-System neu gestarteten EC2-Instanzen keinen Netzwerk-Status melden konnten. Die Prüfungen schlugen in einigen Fällen fehl, obwohl NLB-Knoten und die Backen-Systeme korrekt funktionierten. Die Ergebnisse der Prüfung lieferten abwechselnd korrekten Status und Fehler zurück, wodurch NLB-Knoten und Backend-Systeme aus dem DNS entfernt wurden, um beim nächsten erfolgreichen Durchlauf wieder hinzugefügt zu werden. Das fiel in der Netzwerküberwachung gegen 15:52 Uhr auf.

Die Last im Health-Check-System stieg durch die alternierenden Prüfergebnisse an, wodurch es langsamer wurde und Verzögerungen bei Health-Checks auftraten. Dadurch wurden schließlich Lord-Balance-Kapazitäten reduziert, da diese außer Dienst gestellt wurden. Dadurch kam es zu vermehrten Verbindungsfehlern von Anwendungen, wenn die übriggebliebene noch laufende Kapazität nicht zum Verarbeiten der Anwendungslast ausreichte. Um 18:36 Uhr hat das IT-Team die automatischen Prüfungen für die NLB deaktiviert, wodurch alle verfügbaren, noch in Funktion befindlichen NLB-Knoten und Backend-Systeme wieder in Dienst gestellt werden konnten. Nachdem auch die EC2-Systeme sich erholt hatten, konnten die Health-Checks gegen 23:09 Uhr wieder aktiviert werden.

Im Weiteren erörtert Amazon noch, wie von den gestörten Hauptsystemen abhängige Amazon-Services der zeitliche Störungsverlauf aussah. Das IT-Team will einige Änderungen als Folge der größeren Cloud-Störungen umsetzen. Etwa der DynamoDB „DNS Planner“ und „DNS Enactor“-Automatismus wurde weltweit deaktiviert. Das soll so bleiben, bis unter anderem die aufgetretene Race-Condition gelöst wurde. Die Network Load Balancer sollen eine Geschwindigkeitskontrolle erhalten, die begrenzt, wie viele Kapazitäten ein einzelner NLB nach fehlschlagenden Health-Checks entfernen kann. Für die EC2-Systeme entwickelt Amazon zusätzliche Test-Suites, um etwa den DWFM-Workflow zu analysieren und künftige Regressionen zu vermeiden.

(dmk)

Admins von Atlassian-Software sollten zeitnah Confluence Data Center und Jira Data Center auf den aktuellen Stand bringen. Geschieht das nicht, können Angreifer an zwei Sicherheitslücken ansetzen, um Systeme zu attackieren.

Jetzt Systeme schützen

Eine Schwachstelle (CVE-2025-22167 „hoch„) betrifft Jira Software Data Center und Jira Software Server. An dieser Stelle können Angreifer im Zuge einer Path-Traversal-Attacke unrechtmäßig auf Daten zugreifen. In einer Warnmeldung versichern die Entwickler, dass sie die Lücke in den Versionen 9.12.28, 10.3.12 und 11.1.0 geschlossen haben.

Die Schwachstelle (CVE-2025-22166 „hoch„) in Confluence Data Center dient einem Beitrag zufolge als Ansatzpunkt für DoS-Attacken. An dieser Stelle schaffen die Ausgaben 8.5.25, 9.2.7 und 10.0.2 Abhilfe.

Auch wenn es noch keine Berichte zu laufenden Angriffen gibt, sollten Admins mit der Installation der Sicherheitsupdates nicht zu lange warten.

(des)

Für eine kritische Sicherheitslücke in Adobes Shop-Systemen Commerce und Magento stehen seit September Updates zum Schließen bereit. Die sollten Admins zügig installieren – Attacken auf die Schwachstellen laufen inzwischen.

Adobe hat die Sicherheitsmitteilung zur Schwachstelle inzwischen angepasst und ergänzt, dass das Unternehmen von Angriffen im Internet auf die Lücke weiß. Richtig konkret wird das Unternehmen bei der Schwachstellenbeschreibung nicht, sondern zieht sich abstrakt auf „Common Weakness Enumeration“-Einordnung der Probleme zurück. Demnach handelt es sich um eine unzureichende Eingabeprüfung (Improper Input Validation, CWE-20), die zur Umgehung von Sicherheitsfunktionen führt (CVE-2025-54236, CVSS 9.1, Risiko „kritisch„). Im zugehörigen CVE-Eintrag findet sich der konkretere Hinweis, dass „erfolgreiche Angreifer das missbrauchen können, um Sessions zu übernehmen“. Nutzerinteraktion ist zum Missbrauch nicht nötig.

Eine technisch tiefergehende Analyse findet sich bei NullSecurityX. Es handelt sich um eine Deserialisierungs-Schwachstelle, die die IT-Forscher „SessionReaper“ genannt haben. „Diese Schwachstelle ermöglicht es nicht authentifizierten Angreifern, REST-, GraphQL- oder SOAP-API-Endpunkte auszunutzen, was zu einer Übernahme der Sitzung oder unter bestimmten Bedingungen (etwa dateibasierter Session-Speicher) zur Ausführung von Code aus dem Netz (RCE) führen kann“, erörtern sie dort.

Cyberangriffe haben begonnen

Die IT-Analysten von Sansec haben nun seit Mittwoch aktive Angriffe auf die Sicherheitslücke „SessionReaper“ beobachtet. Den Autoren des Sicherheitsberichts zufolge haben derzeit lediglich 38 Prozent der Adobe-Commerce und -Magento-Stores die Sicherheitsupdates installiert – mehr als 60 Prozent der Shops sind damit noch verwundbar. IT-Sicherheitsforscher von Assetnote haben eine Analyse des Patches vorgelegt und die Deserialisierungslücke darin vorgeführt.

Erste Angriffe haben die IT-Forscher bereits beobachtet, Proof-of-Concept-Exploits sind öffentlich verfügbar. Daher rechnen die Analysten damit, dass nun massive Angriffe bevorstehen. Cyberkriminelle nehmen den Exploit-Code in ihre Werkzeugkästen auf und scannen das Netz automatisiert nach verwundbaren Instanzen. IT-Verantwortliche sollten die von ihnen betreuten Magento- und Commerce-Shops umgehend mit den bereitstehenden Aktualisierungen versorgen.

(dmk)