SSRF: Stealing Cloud Credentials & How to Stop It (Free Labs)

[00:00:00]Think about everything you do to lock down a server in the cloud.

[00:00:03]Private S3 bucket, public access blocked, no passwords sitting in the code, a load balancer out front, firewalls tight. You did it all by the book.

[00:00:14]And in about 5 minutes, we're going to rob it blind. No malware, no password cracking, no breaking in, >> [music] >> just one line of curl typed from a machine that has no account, no key, and no business being there. And the server hands over the keys to its private storage.

[00:00:29]Then we'll shut the whole attack down by changing a single setting.

[00:00:33]So, let's build it, break it, [music] and fix it. Start with the thing every attack in the cloud is really after, credentials.

[00:00:40]Our web server [music] needs to read files from private storage. The old bad way is to paste a permanent access key and [music] secret straight into the code, long-lived. And if that ever leaks, the account is wide open.

[00:00:50]The better way, the recommended way, is an IAM role.

[00:00:54]We create a role, [music] give it read-only access to storage and nothing else, least privilege, and attach it to the server.

[00:01:00]Now, AWS hands the server short-lived, automatically rotating credentials on demand.

[00:01:05]>> [music] >> No secrets in the code. This is good practice. Hold that thought. Next, the thing worth stealing.

[00:01:11]We create an S3 bucket and leave block all public access [music] switched on, fully locked down.

[00:01:17]Nobody reaches this bucket from the open internet. The only way in is with valid AWS credentials, the exact temporary credentials that role hands our server.

[00:01:25]>> [music] >> Inside, we drop one secret file. That's the prize. Those servers need somewhere to live. So, we build a network, a VPC, our own private slice of the cloud with an internet gateway as its door to the outside.

[00:01:37]We carve out two subnets in two different availability zones. Why two?

[00:01:42]Because the load balancer we're about to add refuses to run in fewer than two zones. [music] Now, the front door.

[00:01:47]We put an internet-facing application load balancer out front, [music] listening on port 80, open to the world.

[00:01:53]Behind it, the web server's own firewall is deliberately tighter.

[00:01:57]>> [music] >> It accepts web traffic only from the load balancer, not from the open internet.

[00:02:01]So, every request has to come through the front door first.

[00:02:03]>> [music] >> Textbook. Here's the target itself. A small EC2 instance in the first subnet running a tiny Python web app. The app has one feature, a link preview.

[00:02:13]You give it a URL, it fetches that URL for you, and shows you what [music] came back. Useful. It's also the entire vulnerability, because the server will fetch any URL you hand it, no questions asked.

[00:02:26]That's [music] server-side request forgery, SSRF.

[00:02:31]We attach our read-only role to this server, and we leave one legacy setting in place, the instance [music] metadata service set to version one, token optional.

[00:02:43]Every EC2 [music] instance can ask a special internal address, 169.254. [music] 169.254.

[00:02:53]About itself, >> [music] >> including the live credentials of its attached role.

[00:02:58]Version one of that service, [music] IMDS version one, hands them to anyone who simply asks.

[00:03:06]Last piece, the attacker's machine.

[00:03:09]A second small instance, [music] SSH open, and on purpose, no IAM role at all.

[00:03:17]It carries [music] zero AWS privileges of its own.

[00:03:21]A clean outsider, exactly like a real attacker's laptop.

[00:03:26]Now, watch the heist. [music] We connect to the attacker box and fire one request at the load balancer's address.

[00:03:33]But, we set that URL parameter to the internal metadata address.

[00:03:37]The web server does its job.

[00:03:39]>> [music] >> It reaches inside itself, queries 169.254.169.254.

[00:03:45][music] Grabs its own role's credentials, >> [music] >> and passes them right back out through the load balancer to us.

[00:03:54]First, the role name, then the temporary access key, the secret, >> [music] >> and the session token.

[00:04:01]We plug those stolen keys into the attacker [music] box. And now, as far as AWS is concerned, we are that web server.

[00:04:10]We read the secret file clean out of that locked bucket.

[00:04:14]The bucket [music] that blocks all public access robbed because the thief walked in holding valid credentials.

[00:04:21]So, how do we stop it? We don't [music] touch the code.

[00:04:25]We change one setting.

[00:04:27]Flip the metadata [music] service to version two, required.

[00:04:31]Now, every metadata request has to start with a cryptographic put request carrying a special [music] header to get a short-lived session token.

[00:04:40]And only then can it read anything.

[00:04:42][music] Our SSRF trick can only make simple get requests through that URL parameter.

[00:04:49]It can't send that put. It can't get a token.

[00:04:53]We run the exact same attack again, and this time [music] it comes back empty.

[00:04:58]Content length zero.

[00:05:00]The credentials never leave the building.

[00:05:03]That's the whole story on one diagram.

[00:05:06]A read-only IAM role for clean [music] temporary credentials, a private bucket locked to authenticated access only, a VPC across two zones, an internet-facing load balancer, and a web [music] server firewalled to sit behind it.

[00:05:22]Every one of those choices was correct.

[00:05:25]The attack didn't [music] beat good architecture. It beat one legacy default. A single metadata setting was the entire difference between a heist [music] and a dead end.

[00:05:35]A diagram shows you the shape of it.

[00:05:37]What it can't show you is how fast this [music] happens. You don't really feel it until you type that one line yourself and watch someone else's credentials scroll up your screen.

[00:05:47]So, we built two things for you to do exactly that, both free and hands-on.

[00:05:51][music] First, five mini labs, one per piece, IAM, S3, VPC, [music] ALB, and EC2, so you can drill each service on its own until it's second nature.

[00:06:02]Then, [music] the capstone, the SSRF metadata heist, where you wire it all together and play both sides.

[00:06:09]You start as the architect, create the read-only role and attach it to your server. Stand up the private bucket, keep public access blocked, and drop in the secret file that's the prize.

[00:06:18][music] Build the network, a VPC, two subnets across two zones, an internet gateway.

[00:06:25]Put the load balancer out front on port 80, and lock the web server's firewall so it only takes traffic from the balancer.

[00:06:32]Launch the target running that link preview [music] app, and here's the part that matters. Leave the metadata service on the old version, token [music] optional.

[00:06:40]That one setting is the door you're about to walk through.

[00:06:43]Then, add a second machine [music] as the attacker with no role at all.

[00:06:48]Now, flip sides. Connect to that attacker box and aim a curl at the load balancer, pointed at the internal metadata address.

[00:06:55]The server hands back its role name, then it's live access key, secret, and session [music] token.

[00:07:01]Paste those stolen keys in and you are the server, reading the secret file clean out of a bucket that blocks the whole public internet.

[00:07:08]Then, flip the metadata service to version two, >> [music] >> required, one setting, no code change.

[00:07:14]Run the same attack again and it comes back empty, content length zero. A real credential theft shut down in about 30 seconds.

[00:07:23]One line to rob it, one setting to shut it [music] down.

[00:07:26]If that's your kind of thing, subscribe.

[00:07:28]We take apart a real cloud attack like this every time, [music] the break and the fix, start to finish.

[00:07:34]Got an exploit you want us to crack open next? Drop it in the comments. Then, go build it, break it, and fix it yourself.

[00:07:42]See you in the next one.