CloudWatch-Log-Events lesen
Kann die gespeicherten Log-Ereignisse einer CloudWatch-Log-Gruppe lesen.
Ermöglicht Eskalation für sich allein.
logs:GetLogEventsFür sich allein kann logs:GetLogEvents die gespeicherten Log-Events einer CloudWatch-Log-Gruppe lesen. Bei einem weiten Ressourcenbereich erreicht dies allein die Daten selbst.
Warum es gefährlich ist
Ein Principal kann logs:GetLogEvents aufrufen, um die gespeicherten Log-Ereignisse der CloudWatch-Log-Gruppe zu lesen. Anwendungs- und Plattform-Logs enthalten routinemäßig Access Keys, Bearer-Tokens, Datenbank-Verbindungszeichenfolgen und PII, die von nachlässigem Code ausgegeben wurden, ihr Lesen ist also eine direkte Datenexfiltration und, wenn eine langfristige Anmeldeinformation vorhanden ist, ein Übergang zu der Identität, zu der sie gehört. CloudWatch Logs ist eine API mit öffentlichem Endpoint und IAM-Kontrolle, dies ist also ein Lesezugriff auf der Control-Plane ohne Netzwerkvoraussetzung; die Schwere richtet sich nach der Sensibilität der Log-Gruppe.
In MITRE ATT&CK entspricht dies T1552, Unsecured Credentials, unter der Taktik Credential Access. AWS protokolliert dies in CloudTrail als GetLogEvents, FilterLogEvents, GetQueryResults. Der Aufruf ist gegenüber normaler Aktivität unauffällig, daher ist er ohne passende Regel leicht zu übersehen.
Erkennung
GetLogEventsFilterLogEventsGetQueryResultsVoraussetzungen
logs:GetLogEvents (oder FilterLogEvents/GetQueryResults) für die Log-Gruppe; logs:Unmask zusätzlich, um eine Datenschutz-Maskierungsrichtlinie zu umgehen. CloudWatch Logs hat keine Ressourcenrichtlinie, daher genügt der Zugriff allein über die Identitätsrichtlinie.
MITRE ATT&CK
T1552 · Unsecured CredentialsTaktik
Credential Access
Eine Maßnahme, die ihn beseitigen würde: logs:GetLogEvents/FilterLogEvents/GetQueryResults auf die Principals beschränken, die sie benötigen; Anmeldeinformationen/PII aus Logs bereinigen und eine CloudWatch-Logs-Datenschutzrichtlinie aktivieren.
Ob sie angewendet werden sollte, hängt davon ab, wie die Berechtigung in Ihrer Umgebung verwendet wird, daher ist es eine geschäftliche Entscheidung und keine automatische Behebung. Dieselbe Berechtigung kann in einem Konto tragend und in einem anderen reines Risiko sein.
Pathbreak bestätigt, ob dieser Pfad in Ihrem Konto auflösbar ist, stuft ihn gegenüber den anderen danach ein, wie viel er eröffnet, und nutzt Ihr Bedrohungsmodell und Ihren Geschäftskontext, um zu zeigen, welche Pfade es wert sind, unterbrochen zu werden.
Fragen
Was erlaubt logs:GetLogEvents?
Kann die gespeicherten Log-Ereignisse einer CloudWatch-Log-Gruppe lesen.
Kann logs:GetLogEvents allein Privilegien eskalieren?
Ja. Auf einer ausreichend breiten Ressource gehalten, erreicht sie ohne weitere Berechtigung die Daten selbst.
Wie wird das Lesen von CloudWatch-Log-Events erkannt?
Achten Sie in CloudTrail auf GetLogEvents, FilterLogEvents, GetQueryResults. Der Aufruf ist im Vergleich zur normalen Aktivität leise, daher lässt er sich ohne eine entsprechende Regel leicht übersehen.
Wie unterbricht man diesen Pfad?
Eine Maßnahme, die ihn beseitigen würde, ist: Beschränken Sie logs:GetLogEvents/FilterLogEvents/GetQueryResults auf die Principals, die sie benötigen; entfernen Sie Anmeldeinformationen/PII aus Logs und aktivieren Sie eine CloudWatch-Logs-Datenschutzrichtlinie. Ob sie angewendet werden sollte, hängt davon ab, wie die Berechtigung in Ihrem Konto verwendet wird, es ist also eine geschäftliche Entscheidung und keine automatische Behebung.
Welche MITRE ATT&CK Technik ist das?
T1552, Unsecured Credentials, unter der Taktik Credential Access.
Verwandte Pfade
Referenzen
Finden Sie dies in Ihrem eigenen Konto
Wir führen einen schreibgeschützten Scan eines AWS-Kontos durch und zeigen Ihnen, welche dieser Pfade existieren, nach Blast-Radius priorisiert, mit der Änderung, die jeden einzelnen unterbricht. Erste validierte Pfade innerhalb der Stunde.