Nach einem AWS-Ausfall wurde ein Konto kompromittiert

Nach dem AWS-Dienstausfall berichtete kürzlich ein Nutzer, dass sein AWS-Konto von einem externen Angreifer übernommen wurde

Angriffspfad und Problemstellung

• Es wurde erwähnt, dass während der Ausfallzeit einige Sicherheitsrichtlinien möglicherweise nicht korrekt funktioniert haben
• Der Angreifer hinterließ nach dem Ausfall auffällige Zugriffsspuren in den Kontoprotokollen, und es kam zu unerwarteter Erstellung/Löschung einiger Ressourcen
• Der Nutzer äußerte Bedenken hinsichtlich möglicher Berechtigungsänderungen oder der Offenlegung von Anmeldeinformationen im Zusammenhang mit dem Ausfall

Schäden und Reaktion

• Kostenanstieg, Datenexfiltration und weitere direkte Schäden traten auf
• Der Nutzer kontaktierte den AWS-Support, um die Vorfalldetails und Gegenmaßnahmen zu erfragen
• In der Community wurde die Bedeutung von Prävention betont, z. B. Aktivierung der Zwei-Faktor-Authentifizierung und Minimierung rollenbasierter Zugriffsbefugnisse

[GN⁺]

Hacker News Kommentare

• Normalerweise würde man so etwas als Zufall sehen, aber ich hatte selbst einen Fall, in dem ein Kundenkonto kompromittiert wurde. Der Kunde war eine kleine Organisation, und in zwei alten IAM-Konten, die seit über fünf Jahren nicht genutzt wurden, tauchten plötzlich Konsolenanmeldungen und Passwortänderungen auf. In der Aufarbeitung zeigte sich, dass bisher nur die Aktivierung des AWS SES Produktionszugriffs und ein Support-Ticket zur Anhebung des täglichen E-Mail-Limits auf 50.000 vorlagen. Dass ein Konto, das mehr als fünf Jahre inaktiv war, genau zu diesem Zeitpunkt aktiv wurde, ist völlig verdächtig.
  • Das riecht stark nach Phishing. Beispielsweise bekommt man eine E-Mail, die wie eine AWS-Ausfallmeldung aussieht, wird zur Konsole zum Login verleitet und authentifiziert sich über einen bösartigen Wrapper, wodurch die Kontosicherheit kompromittiert werden kann.
  • Fast identisch ist mir schon vor einem Jahr passiert. Login mit einem uralten Konto, danach SES-Zugriff und Antrag auf Erhöhung des E-Mail-Limits. Wir konnten schnell reagieren, weil das Erhöhungs-Ticket zwingend erforderlich war. Wenn noch nicht geprüft, sollten auch neu erstellte Rollen überprüft werden. Wir haben den kompromittierten Account sofort bereinigt und dabei alle Rollen mit einem Alter unter einem Monat oder mit Admin-Rechten entfernt. Gleichzeitig konnten wir bestätigen, dass der Angriff tatsächlich von meinem Key ausging. Der Nutzer war fast einen Monat vor der eigentlichen SES-Anfrage erstellt worden; es ist möglich, dass der Angreifer uns schon kompromittiert hatte und den AWS-Ausfall als Chance nutzte. So wurde es in einer anderen AWS-Angelegenheit kaum sichtbar.
• Wenn ein Angreifer bereits Zugriff erhalten hat, kann er möglicherweise warten, bis es in der AWS-Infrastruktur zu einem Durcheinander wie einem Ausfall kommt, dann zuschlagen und sich darin zu verstecken versuchen. Auch wenn ein Token vor Wochen oder Monaten geleakt wurde, kann man so lange zuwarten, bis ein größeres Ereignis eintritt. Wenn ich Angreifer wäre, würde ich diese Taktik ebenfalls probieren.
  • Das ist absolut möglich. Als Due-Diligence-Prüfer habe ich solche Fälle tatsächlich gehört. Angreifer bereiten alles vor und warten, bis ein wichtiges Ereignis wie ein Unternehmensverkauf ansteht, bevor sie aktiv werden. Je ausgefeilter ein Angreifer ist, desto eher nutzt er solche Gelegenheiten gezielt vorausschauend.
  • Zur Klarstellung aus demselben Team: Ich habe tatsächlich vor zwei Jahren eine Warn-E-Mail zu den heute ausgenutzten Schlüsseln von einem zufälligen Absender erhalten. Bis gestern gab es jedoch keine Nutzung.
  • Auch das wäre vielleicht ein schlechter Zeitpunkt für einen Angriff. Alle schauen gerade auf AWS und melden sich viel an, sodass Auffälligkeiten eher bemerkt werden. Würde unser Unternehmen AWS nutzen, würde man in dieser Lage besonders genau alles beobachten.
• Würde ich Angreifer sein, würde ich den Zeitpunkt wählen, wann ich angreife. Ein großer Ausfall, bei dem selbst die Log-Aggregation nicht korrekt funktioniert, kann eine gute Gelegenheit sein. Vielleicht wurde genau zu diesem Zeitpunkt ausgenutzt, dass die Umgebung bereits kompromittiert war, oder der Angreifer hat den AWS-Ausfall benutzt, um mit meinen Ressourcen weitere Angriffe durchzuführen.
• In einer Cloud-Umgebung kann man in CloudTrail prüfen, durch welches Event eine ungewöhnliche Ressource (z. B. EC2) erstellt wurde. Oft reicht ein Blick auf das RunInstances-Event.
  • Ich nutze AWS aktuell nicht mehr und kann die Konsole nicht direkt prüfen, aber bei ähnlichen Fällen würde ich grob die folgenden Schritte empfehlen:
    1. Ermitteln, welches Konto/der Principal die EC2 erstellt hat (eventSource:ec2.amazonaws.com, eventName:RunInstances)
    2. Nachfolgende Aktionen anhand von userIdentity nachverfolgen
    3. Anmeldehistorie der Konsole prüfen (eventSource:signin.amazonaws.com, userIdentity.type:[Root/IAMUser/AssumedRole/FederatedUser/AWSLambda], eventName:ConsoleLogin)
    4. STS-Authentifizierungsanfragen prüfen (eventSource:sts.amazonaws.com, eventName:GetSessionToken)
    5. Prüfen, ob AssumeRole mit STS-Sessions verwendet wurde (eventSource:sts.amazonaws.com, eventName:AssumeRole)
    6. Versuche zur Persistenz prüfen, etwa Erstellung neuer IAM Roles/Accounts (eventSource:iam.amazonaws.com, eventName:CreateUser/ DeleteUser)
    7. Prüfen, ob eine bestehende Rolle/ein bestehendes Account auf höhere Berechtigungen angepasst wurde (eventSource:iam.amazonaws.com, eventName:CreateRole/DeleteRole/AttachRolePolicy/DetachRolePolicy)
    8. Erstellungs-/Löschhistorie von Access Keys prüfen (eventSource:iam.amazonaws.com, eventName:CreateAccessKey/DeleteAccessKey)
    9. Backdoor-Risiko über Änderungen am IAMInstanceProfile von Produktions-EC2 prüfen (als Detailreferenz siehe AWS Docs-Beispiel) Wenn ein tiefergehender Kompromiss vermutet wird, empfiehlt sich eine fachkundige Überprüfung der Umgebung und ein Audit.
  • Das sind gute Hinweise, ich werde die Logs noch durchsehen. Zusätzlich habe ich folgende Beobachtungen gemacht:
    1. Unter dem Root-Konto wurden etwa 20 Organisationen erstellt, alle mit E-Mail-Adressen derselben Domain (co.jp)
    2. Der Angreifer hatte mehrere Fargate-Templates vorbereitet
    3. Ressourcen wurden in 16 bis 17 AWS-Regionen erzeugt
    4. Es gab unnötige Anfragen wie SES, WS Fargate-Quotenerhöhungen und SageMaker-Notebook-Wartungsanfragen (davon kamen mehrere Warn-E-Mails)
    5. Bei einigen E-Mails wurden neue Namen im Stil [e-mail] gefunden
  • Das RunInstances-Event war genau dieses Event.
• Einige Reddit-Nutzer berichteten, während des AWS-Ausfalls beim Aktualisieren kurz als völlig anderer Benutzer angemeldet gewesen zu sein.
  • Ähnliches passierte auch bei einer Firma, in der ich früher gearbeitet habe. Kunden landeten in Kundendaten anderer Kunden; die Ursache war ein falscher Mitarbeiter, der im Live-Debugging in einer Live-Produktionsumgebung zu testen versuchte (ich hatte im Vorstellungsgespräch gegen diese Einstellungstätigkeit argumentiert). Solche Probleme sind wirklich schwer nachzuverfolgen und zu beheben.
  • Ich frage mich, ob es nicht während der Ausfallzeit zu einem temporären Inkonsistenzzustand von DynamoDB gekommen ist, sodass sogar die IAM-Anmeldedaten durcheinandergeraten sind. Wenn das stimmt, wäre das ein wirklich ernstes Problem. Gibt es da einen Link zu einem ähnlichen Fall?
  • Wenn Beweise vorliegen, bitte teilt sie. Das ist wirklich schockierend.
  • Mir kam der Gedanke, ob nicht auch ChatGPT kürzlich ein ähnliches Problem hatte. Es fühlt sich irgendwie ähnlich an.
  • Solche Sicherheitsvorfälle sind weitaus schwerwiegender als ein bloß vorübergehender Service-Ausfall.
• Normalerweise wäre sowas wohl ein Zufall, aber meistens steckt ein geleakter Access Key dahinter. Es gibt auch Fälle, in denen das Passwort eines Konsolenkontos ohne aktivierte MFA geleakt wurde, das ist aber seltener.
• In Panikmomenten sind Menschen besonders anfällig für Phishing. Man sollte die Passwörter komplett zurücksetzen und AWS über den Vorfall informieren. In der Regel lässt sich das über Vertrauen gut abwickeln.
• Die Region us-east-1 ist größer als man denkt. Nach zuletzt veröffentlichten Informationen gibt es dort angeblich 159 Rechenzentren, und es könnten Millionen von Accounts dort konzentriert sein. Dieses Phänomen könnte mit dem AWS-Ausfall zusammenhängen, aber ich denke persönlich, dass es eher Zufall ist.
  • 159 Rechenzentren, das ist erstaunlich. Wenn ihr eine Quelle habt, teilt sie bitte.
• Es klingt merkwürdig, aber ich dachte, wenn man einen API Key schickt, könnte man prüfen, ob er auf einer Leak-Liste steht.
  • Ich weiß, das klingt wie ein Witz, dennoch will ich eine wichtige Information vorsichtig teilen. Auch wenn es ein Scherz ist, sollte man die Erwähnung des Teilens von API Keys oder Credentials vermeiden. Jemand könnte es ernst nehmen, deshalb ist Vorsicht wichtig.