Attacking Storage Services Hitb

This presentation, delivered at HITB CyberWeek 2020 Red Team Village, examines how cloud storage services serve as the lynchpin of cloud infrastructure and why they represent a critical attack surface. Anant Shrivastava walks through real-world case studies, a structured attack methodology covering enumeration through post-exploitation, and defenses that both cloud vendors and tenants should implement to protect their storage assets across AWS, Azure, and GCP.

Key Topics Covered

Cloud Storage as Critical Infrastructure:

• Cloud storage services (AWS S3, Azure Storage, GCP Storage, Digital Ocean Spaces, SharePoint, OneDrive, Dropbox, Google Drive, code repositories) underpin virtually all cloud operations
• Storage is used for files, documents, source code, transient objects, keys, and secrets
• PaaS and FaaS rely on storage for application and function source code, making storage compromise a gateway to deeper attacks
• Cloud storage acts as a decoupled data backend that other cloud services depend on, making it a single point of failure when compromised

Real-World Case Studies:

• Authenticated user access misconfiguration allowing unintended data exposure (HackerOne #128088) — demonstrating that access controls can be deceptive
• Rocket.chat installer referencing an unclaimed S3 bucket, enabling supply chain attacks (HackerOne #399166) — showing dangers of hardcoded bucket references
• fwupd CVE-2020-10759: unclaimed S3 bucket in Linux Vendor Firmware Service combined with a PGP signature bypass, receiving 2.5 million update requests from 500,000 unique IPs in 26 days — illustrating dangling resource risks at massive scale
• SSRF to EC2 takeover via metadata credentials leading to S3 bucket enumeration, PEM file extraction for all EC2 instances, privilege escalation to higher-power roles, and full AWS account backdooring via new IAM user with iam:* capabilities
• Elastic Beanstalk SSRF exploitation: metadata harvesting, predictable bucket naming using account ID and region, source code access via S3 CLI, and CI/CD pipeline abuse for deploying a backdoor on the official website
• AWS Cognito misconfiguration research: crowdsourced 2,504 identity pool identifiers via CommonCrawl and APK decompilation, revealing more than 1 in 5 configurations insecure, 906 S3 buckets with sensitive data, and 1,572 exposed Lambda functions with at least 78 sensitive environment variables

Attack Methodology — Enumeration:

• Storage names are globally unique per provider and often predictable for an organization
• Brute-force and enumerate bucket names using tools like cloud_enum (multi-cloud), Cloud Scraper (extracts cloud URLs from HTML source), and dedicated cloud bucket search engines
• AWS S3 URL formats: https://s3.amazonaws.com/bucket_name and https://<bucket>.s3.amazonaws.com; region identification via redirect responses to any-region URLs
• Google dorking to discover exposed storage resources
• Curated tool lists maintained at RedHuntLabs Awesome-Asset-Discovery

Attack Methodology — Identification and Exploitation:

• Permission-focused exploitation: anonymous access, misconfigured write access, “authenticated user” ACLs (any AWS user, not just your org), and lax IAM policies
• Azure SAS URLs: shared access signatures with specific permissions that developers commonly leak; overly privileged SAS URLs grant storage account control
• Leaked Azure storage account keys searchable on GitHub via DefaultEndpointsProtocol keyword
• Azure Storage Explorer as a post-compromise tool for browsing and manipulating storage contents
• Azure blob access patterns: https://<storagename>.blob.core.windows.net/<container> with ?restype=container&comp=list for directory listing

Post-Exploitation and Pivoting:

• Credential harvesting from office documents using exiftool to extract Author and Last Modified By metadata
• Specialized metadata extraction tools like FOCA for automated username harvesting
• Source code access in PaaS/FaaS environments leading to remote code execution
• Secret extraction (passwords, API keys, PEM files) enabling lateral movement and privilege escalation across the cloud environment

Defenses and Remediation:

• Cloud vendor responsibilities: clear warnings on problematic configurations, automation for common problem detection and auto-remediation (e.g., AWS Config rules)
• Tenant responsibilities: strict IAM policies following least privilege, no unauthenticated or public access unless explicitly required, understanding that “authenticated user” often means any authenticated user on the platform
• Periodic security scanning using tools like Scout Suite for multi-cloud configuration auditing
• Disaster preparedness: simulate attacks, observe responses, fine-tune incident response procedures, and revalidate regularly

Actionable Takeaways

1. Treat cloud storage as a high-value target in every engagement — it connects to nearly every other cloud service and often contains secrets, source code, and sensitive data.
2. Enumerate storage resources aggressively using tools like cloud_enum, Google dorking, Cloud Scraper, and cloud bucket search engines during reconnaissance.
3. Check for misconfigured permissions including anonymous access, writable public buckets, and overly permissive “authenticated user” settings across AWS S3, Azure Blob, and GCP Storage.
4. Hunt for leaked Azure SAS URLs and storage account keys on GitHub (search DefaultEndpointsProtocol) as common entry points for storage compromise.
5. Chain SSRF vulnerabilities with cloud metadata services to obtain temporary credentials, then pivot to storage enumeration and exploitation using predictable naming patterns.
6. Leverage post-exploitation paths from storage access: extract credentials from document metadata with exiftool/FOCA, access PaaS/FaaS source code for RCE, and pivot using discovered secrets and PEM files.
7. Implement periodic cloud security scanning with tools like Scout Suite, enforce least-privilege IAM policies, use vendor-native controls such as AWS Config for auto-remediation, and conduct regular attack simulations to validate your incident response.