S3-Lesezugriff per Bucket-Richtlinie selbst gewähren
Kann die Richtlinie eines Buckets umschreiben, um sich selbst Lesezugriff zu gewähren, und dann lesen.
Ermöglicht Eskalation für sich allein.
s3:PutBucketPolicyFür sich allein kann s3:PutBucketPolicy die Richtlinie eines Buckets umschreiben, um sich selbst Lesezugriff zu gewähren, und ihn dann lesen. Bei einem weiten Ressourcenbereich erreicht dies allein Zugriff für einen externen oder öffentlichen Principal.
Warum es gefährlich ist
Ein Principal kann s3:PutBucketPolicy auf dem Bucket aufrufen, um eine Ressourcenrichtlinie anzuhängen, die sich selbst (oder der Öffentlichkeit) s3:GetObject gewährt, und dann die Objekte des Buckets lesen. Dies umgeht das Fehlen eines Lese-Grants in der Identitätsrichtlinie: Der Angreifer schreibt das Schloss um, statt einen Schlüssel zu besitzen. Die Schwere wird von der Sensibilität des Buckets bestimmt, die Kontrolle über die Richtlinie wird zu einer direkten Exfiltration dessen, was der Bucket enthält.
In MITRE ATT&CK entspricht dies T1098, Account Manipulation, unter der Taktik Privilege Escalation. AWS protokolliert dies in CloudTrail als PutBucketPolicy, PutBucketAcl, PutAccountPublicAccessBlock. Der Aufruf erscheint in CloudTrail, geht aber in der normalen Administration unter, daher braucht es eine Regel, damit er auffällt.
Erkennung
PutBucketPolicyPutBucketAclPutAccountPublicAccessBlockVoraussetzungen
s3:PutBucketPolicy für den Bucket. Der Missbrauch setzt zusätzlich voraus, dass kein SCP-/Boundary-/PrincipalOrgID-Schutzmechanismus die Übergewährung blockiert und (bei einem öffentlichen Grant), dass S3 Block Public Access auf Kontoebene nicht erzwungen wird.
MITRE ATT&CK
T1098 · Account ManipulationTaktik
Privilege Escalation
Eine Maßnahme, die ihn beseitigen würde: s3:PutBucketPolicy auf CI/CD/Admins beschränken; S3 Block Public Access auf Kontoebene aktivieren; Schreibzugriffe auf die Bucket-Richtlinie per SCP verweigern.
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 s3:PutBucketPolicy?
Kann die Richtlinie eines Buckets umschreiben, um sich selbst Lesezugriff zu gewähren, und dann lesen.
Kann s3:PutBucketPolicy allein Privilegien eskalieren?
Ja. Auf einer ausreichend breiten Ressource gehalten, erreicht sie ohne weitere Berechtigung Zugriff für einen externen oder öffentlichen Principal.
Wie wird das Selbst-Gewähren von S3-Lesezugriff über eine Bucket-Richtlinie erkannt?
Achten Sie in CloudTrail auf PutBucketPolicy, PutBucketAcl, PutAccountPublicAccessBlock. Der Aufruf erscheint in CloudTrail, geht aber in der normalen Administration unter, daher braucht es eine Regel, damit er auffällt.
Wie unterbricht man diesen Pfad?
Eine Maßnahme, die ihn beseitigen würde, ist: Beschränken Sie s3:PutBucketPolicy auf CI/CD/Administratoren; aktivieren Sie S3 Block Public Access auf Kontoebene; verweigern Sie Schreibzugriffe auf die Bucket-Richtlinie via SCP. 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?
T1098, Account Manipulation, unter der Taktik Privilege Escalation.
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.