Mistrusted Advisor: When AWS Tooling Leaves Public S3 Buckets Undetected

Mistrusted Advisor: When AWS Tooling Leaves Public S3 Buckets Undetected

Speakers: Jason Kao, Founder, Fog Security

Conference: fwd:cloudsec Europe 2025

YouTube: https://www.youtube.com/watch?v=JUM77vJzM54

Overview

Jason Kao, founder of Fog Security and veteran cloud security researcher, disclosed a set of vulnerabilities in AWS Trusted Advisor's S3 security checks that allowed publicly accessible S3 buckets to be reported as secure. By crafting bucket policies that denied Trusted Advisor's service role access to specific S3 API actions, Kao demonstrated that buckets with world-readable (and even world-writable) ACLs and policies would be silently categorized as "ignored" by Trusted Advisor — displaying a green checkmark and zero warnings. The finding was responsibly disclosed through AWS's HackerOne VDP program in May 2025, required two rounds of fixes, and was fully remediated by July 2025.

Background

▶ Watch: Finding overview: Trusted Advisor reports public S3 buckets as secure when de... (1:30)

AWS Trusted Advisor is a management and governance service that provides automated recommendations across multiple categories, including security. Its S3 bucket permissions check is one of the free security checks available to every AWS account regardless of support tier, making it one of the most widely deployed S3 security monitoring tools in existence. The check evaluates buckets for public access configurations and displays results using a traffic-light system: red for action recommended, yellow for investigation recommended, green for secure, and gray for excluded items.

S3 access control is notoriously complex, governed by multiple overlapping mechanisms: Block Public Access settings at both account and bucket levels, Resource Control Policies at the org level, object ownership settings (which determine whether ACLs are enabled), bucket policies, ACLs, and encryption configurations. This layered complexity creates fertile ground for gaps between what security tools check and what's actually possible.

Kao's research began from a simple observation: there is an intersection between the IAM permissions that Trusted Advisor's service role uses to scan S3 buckets and the permissions that can be explicitly denied in a bucket policy. If you deny Trusted Advisor the ability to read the very configuration it needs to evaluate, what happens?

Key Findings

▶ Watch: Trusted Advisor's free S3 check exists on every AWS account regardless of sup... (4:00)

Kao discovered three distinct bypass scenarios, each targeting a different S3 API action that Trusted Advisor relies on:

1. Denying s3:GetBucketAcl — prevents Trusted Advisor from reading the bucket's ACL configuration.
2. Denying s3:GetBucketPolicyStatus — prevents Trusted Advisor from determining whether the bucket policy grants public access.
3. Denying s3:GetBucketPublicAccessBlock — prevents Trusted Advisor from checking the bucket-level Block Public Access settings.

In each case, when Trusted Advisor was denied access to scan a bucket's configuration, it did not flag the bucket as inaccessible or suspicious. Instead, it categorized the bucket as "ignored" — a previously undocumented third category alongside "included" and "excluded" items. Ignored buckets were not counted in the summary statistics, not surfaced in the action/investigation recommendations, and displayed incorrect ACL status information.

The critical failure mode: a bucket could simultaneously have a public read/write ACL, a bucket policy granting s3:GetObject to Principal: *, and Block Public Access disabled — yet Trusted Advisor would display "0 out of 1 buckets have permission properties that grant global access" with a green checkmark.

Technical Deep Dive

▶ Watch: Bucket policy walkthrough showing a fully public+writable bucket that Trusted... (8:00)

The Venn Diagram Attack Surface

Kao's methodology was elegant. He mapped the set of IAM permissions that Trusted Advisor's service role uses to scan S3 against the set of S3 actions that can be explicitly denied in a bucket policy. The intersection — s3:GetBucketAcl, s3:GetBucketPolicyStatus, and s3:GetBucketPublicAccessBlock — represented actions where a bucket policy could selectively blind the security tool while leaving the bucket fully accessible to anyone else.

Payload Examples

A typical bypass bucket policy includes two statements: one granting public read access (Allow Principal: * on s3:GetObject) and one denying Trusted Advisor's service role access to a specific configuration API. For example:

• A statement allowing s3:GetObject for all principals on the bucket's objects.
• A statement denying s3:GetBucketAcl for all principals (which catches Trusted Advisor's service role).

The deny on s3:GetBucketAcl doesn't affect the public read access — GetObject still works for anonymous users. But Trusted Advisor can no longer read the ACL and therefore cannot evaluate the bucket's public access status.

The "Ignored Bucket" Category

The most concerning aspect of the finding was Trusted Advisor's failure mode. Rather than reporting an error or flagging the bucket for investigation (which the documented alert criteria said it should do — "if trusted advisor does not have permission to check the policy or the ACL, it should report yellow/investigation recommended"), the bucket was silently placed into an "ignored" category. This category was only visible by drilling deep into the check results and examining a rarely-viewed subcategory. The summary dashboard showed all-green.

Remediation Timeline

• May 2025: Initial disclosure via HackerOne.
• Late May 2025: AWS deployed first code fix.
• Early June 2025: Kao retested and found the fix incomplete.
• June 30, 2025: AWS deployed a second fix.
• August 15, 2025: AWS updated their customer communication based on Kao's feedback.
• August 20, 2025: Coordinated public disclosure.

Kao noted that AWS's initial customer email was insufficient: it didn't mention that Trusted Advisor had inaccurately reported public buckets as secure, didn't detail the incorrect ACL results, and contained a technical inaccuracy (referencing s3:GetPublicAccessBlock instead of the correct s3:GetBucketPublicAccessBlock — the former targets account-level settings and would fail in a bucket policy).

Post-Remediation State

After the fix, buckets where Trusted Advisor is denied access are now properly flagged as "action recommended" (red), ACL and policy status show correct information, and additional details like Block Public Access status are displayed. The "ignored bucket" behavior has been eliminated.

Broader Implications for Security Tool Research

During the Q&A, Kao confirmed that the research pattern — exploring what happens when you deny a security tool the permissions it needs — extends beyond Trusted Advisor. He disclosed that additional findings on other AWS resources and tooling have been reported to AWS via HackerOne and are currently in flight. When asked whether he plans to extend this research to third-party CSPMs, Kao noted there are no current plans but encouraged the community to apply the same methodology. The fundamental question — "Does this security tool handle access-denied errors correctly, or does it silently assume everything is fine?" — is applicable to every security scanning tool in every cloud environment. An audience member also asked about checking other services where a deny statement in a resource policy could block AWS Config or similar native tools from detecting misconfigurations, and Kao confirmed this as an active research direction.

Demo / Proof of Concept

▶ Watch: The 'ignored bucket' category: silently excluded from all summary statistics ... (10:00)

Kao walked through screenshots of the Trusted Advisor console before and after remediation. The before screenshots showed the green checkmark and "0 out of 1 buckets" summary alongside an ignored bucket that was, in fact, publicly readable and writable. He also demonstrated the bucket policies used for each of the three bypass techniques. The open-source S3 Scanner tool developed by his team was referenced as an alternative for checking S3 access issues.

Defensive Implications

▶ Watch: Confirmed: additional findings on other AWS services are currently in flight ... (14:00)

• Do not rely solely on AWS Trusted Advisor for S3 security monitoring. Even post-fix, the finding demonstrates that AWS's own tooling can have blind spots. Layer multiple detection mechanisms.
• Enable Block Public Access at the account level. This is the single most effective control against public S3 exposure, as it overrides bucket-level configurations.
• Retire ACL usage. ACLs are a legacy access control mechanism that adds unnecessary complexity. Disable them via object ownership settings.
• Deploy Resource Control Policies to enforce S3 security at the organization level.
• Verify that your security tools report errors when they lack access. A tool that silently skips resources it can't scan is worse than no tool at all — it creates false confidence.
• Review bucket policies for deny statements targeting security service roles. A malicious insider could use this technique to hide public buckets from detection.
• Consider the S3 Scanner open-source tool for independent validation of S3 access configurations.

Key Takeaways

• AWS Trusted Advisor silently ignored S3 buckets that denied its scanning permissions, reporting them as secure when they were publicly accessible — including with public write access.
• Three specific IAM actions (s3:GetBucketAcl, s3:GetBucketPolicyStatus, s3:GetBucketPublicAccessBlock) could be denied to bypass detection.
• The finding affected every AWS account, since the S3 bucket permissions check is a free Trusted Advisor check available on all support tiers.
• AWS required two rounds of fixes and improved their customer communication only after researcher feedback.
• Security tool efficacy should be actively tested. If a tool claims to detect public buckets, verify that it handles access-denied scenarios correctly.
• This research pattern — exploring what happens when you deny a security tool's permissions — likely applies to other AWS services and third-party CSPMs. Kao confirmed additional findings are in flight with AWS.

About the Speaker(s)

Jason Kao is the founder of Fog Security and has deep expertise in cloud security from his time at Praetorian and leading research at CloudQuery. He holds multiple security patents and has spoken at AWS re:Invent, re:Inforce, and SANS CloudSecNext. His research focuses on the intersection of cloud service configurations and security tool efficacy.