Dangers of Service as a Principal in AWS

The talk examines a weakness in AWS resource-based policies, which are access rules attached directly to a resource such as a storage bucket or a notification topic rather than to a user or role. The presenters explain how these policies differ from identity policies and note that many services, including S3, SNS and API Gateway, rely on them. They describe a recurring pattern seen in client environments: resource policies that trust an entire AWS service principal without restricting which account is making the call.

The middle of the talk is a demonstration. An S3 upload event was configured to publish to an SNS topic in one account, and that topic's policy trusted the S3 service in general. The presenters showed that a separate, attacker-controlled account could create the same event configuration and trigger notifications into the original topic. They then walked through a similar case with API Gateway invoking a Lambda function, where a caller from another account could reach a secret the function retrieves and pass arbitrary inputs to it.

To close, the speakers recommend adding source account conditions to service-principal trust statements, avoiding wildcards, and reviewing policies during design rather than after deployment. They point out that automated tooling for this issue is limited, that console and CLI warnings are inconsistent, and that AWS is aware of the problem and working on a fix.