Caleb Gross
We often hear about the risks of S3 buckets that are accidentally made publicly readable (leaked spreadsheets, source code), but what happens when you can also write to those buckets? Sure, you could deface the occasional static site, but let’s think bigger. Why not treat those buckets as free infrastructure and build your own backup service? Hold on, you say—that’s probably unreliable, right? Won’t admins simply delete our files upon discovering them? Perhaps we can mitigate that by using multiple buckets for redundancy! Hmm, this is starting to sound familiar…
Enter RABID: Redundant Array of Buckets of Independent Data. Think RAID, but instead of disks, we’re using exposed bucket storage. Slice a file into chunks, scatter them across dozens of targets, and replicate just enough times to shrug off cleanup scripts. One bucket vanishes? The other replicas still have your back.
This talk explores how parasitic storage holds up in a truly hostile cloud environment. We’ll outline the core challenges with decentralized storage: placing chunks without central coordination and embedding lightweight metadata pointers for rapid lookup. You’ll see how classic RAID concepts and erasure-coding theory translate (and sometimes break) when “drives” can be deleted at any moment. We’ll also touch on parasitic computing, opportunistic caching, and then bring the conversation back to defenders: bucket policies and automated scanners designed to root out rogue backups before they become a problem.
Whether you’re an admin hardening your cloud perimeter, a blue-teamer justifying investment in continuous audits, or a red-teamer looking to push the limits of misconfiguration exploits, you’ll leave with concrete tactics and a newfound respect for just how RABID cloud storage can get.