Lion Cipher Lab
Find and block public EBS snapshots and AMIs (offline, every Region, with a cross-account check)
- Cloud Security
- Intermediate
- ~60 min
- Free · no account required
Why it matters
When people think 'cloud data leak' they think of an open S3 bucket. The quieter version is the disk snapshot. An EBS snapshot is a complete copy of a server's hard drive -- database files, config files with passwords in them, SSH keys, logs. One setting, createVolumePermission Group:"all", lets any of the millions of AWS accounts in the world restore that snapshot into their own account and read every file, and security researchers have repeatedly found thousands of such snapshots sitting public. Machine images (AMIs) have the same switch one layer up. And an attacker who steals a set of…
What you'll learn
- reading what makes an EBS snapshot public (createVolumePermission Group:"all") and what makes an AMI public (launchPermission Group:"all"), straight from the JSON the AWS CLI returns
- separating PUBLIC from CROSS-ACCOUNT: a share to a specific AWS account ID is not public, but if that account is not on your organisation's allowlist it is still data leaving your control
- knowing why encryption matters here: AWS will not let you make an encrypted snapshot public, and an AMI backed by an encrypted snapshot cannot be shared publicly
- catching the exposure a snapshot-only check misses: a snapshot that is itself private but backs a PUBLIC AMI is readable by anyone who launches that AMI
- writing a standard-library Python auditor (json, os, glob -- no pip, no network) over saved describe-snapshots / describe-images / attribute / block-public-access JSON, Region by Region
- measuring the controls honestly: block-new-sharing left 4 public at 4, block-all-sharing in one Region took it to 3, and only removing Group:all plus block public access in every Region reached 0
- naming what EBS and AMI block public access do NOT fix: shares to specific accounts (2 unencrypted external shares survived the full fix), other Regions, and already-public AMIs
- mapping each offline step to the real, read-only-first AWS CLI calls (describe-*, get-*-block-public-access-state) and the remediation calls (modify-*-attribute, enable-snapshot-block-public-access, enable-image-block-public-access)
Steps in this lab
- Snapshots, AMIs and who can use them -- every term, defined once
- Why an attacker cares -- and how this differs from the S3 lab
- The live-account mapping (optional, your own account only, read-only first)
- Seed a two-Region account as saved CLI output
- Write the auditor -- public, external, via-AMI, latent
- Measure the BEFORE state -- and what the naive grep misses
- Write the remediation stand-in
- Stage 1 and 2: the gentle switch, then one Region -- 4, 4, then 3
- Stage 3: the full fix in every Region -- 0 public (and the real commands)
- The honest negative: 0 public, and still 2 snapshots walking out the door
- When to use this, when not to, and how a pro does it better
- What you built