Episode description

Links:

• CodeBuild to exfiltrate data from an AWS VPC: https://awsteele.com/blog/2022/02/03/aws-vpc-data-exfiltration-using-codebuild.html
• Thousands of Open Databases: https://InfoSecwriteups.com/how-i-discovered-thousands-of-open-databases-on-aws-764729aa7f32
• “Why do Amazon S3 Data Breaches Keep Happening?”: https://markn.ca/2022/why-do-amazon-s3-data-breaches-keep-happening/
• You’re going to be placed on a public list of shame: https://Twitter.com/0xdabbad00/status/1489305680490106880?s=12
• How to report security issues in other people’s software: https://Twitter.com/notdurson/status/1489350457730469888
• S3 Bucket Negligence Award: https://www.zdnet.com/article/unsecured-aws-server-exposed-airport-employee-records-3tb-in-data/
• “Security Practices in AWS Multi-Tenant SaaS Environments”: https://aws.amazon.com/blogs/security/security-practices-in-aws-multi-tenant-saas-environments/
• Stratus Red Team: https://github.com/Datadog/stratus-red-team

Transcript

Corey: This is the AWS Morning Brief: Security Edition. AWS is fond of saying security is job zero. That means it’s nobody in particular’s job, which means it falls to the rest of us. Just the news you need to know, none of the fluff.

Corey: This episode is sponsored in part by our friends at Sysdig. Sysdig is the solution for securing DevOps. They have a blog post that went up recently about how an insecure AWS Lambda function could be used as a pivot point to get access into your environment. They’ve also gone deep in-depth with a bunch of other approaches to how DevOps and security are inextricably linked. To learn more, visit sysdig.com and tell them I sent you. That’s S-Y-S-D-I-G dot com. My thanks to them for their continued support of this ridiculous nonsense.

Corey: Hello there. Another week, another erosion of the perception of AWS’s hard security boundaries. I don’t like what 2022 is doing to my opinion of AWS’s security track record. Let’s get into it.

We start this week with a rather disturbing post from Aidan Steele, who talks about using CodeBuild to exfiltrate data from an AWS VPC. We’re increasingly seeing increased VPC complexity, which in turn means that most of us don’t have a full understanding of where the security boundaries and guarantees lie.

Someone decided to scan a bunch of public AWS IP ranges and lo and behold, an awful lot of us suck at security. Specifically, they found Thousands of Open Databases. This is clearly not an exclusively AWS problem seeing as how it falls fairly on the customer side of the Shared Responsibility Model, but it does have the potential to be interpreted otherwise by folks with a less nuanced understanding.

Mark Nunnikhoven has a blog post up that asks the question “Why do Amazon S3 Data Breaches Keep Happening?” I’ve often wondered the same thing. The vector has been known for years, the console screams at you if you attempt to configure things this way, and at this point, there’s really little excuse for a customer making these mistakes. And yet they keep happening.

Scott Piper has had enough. He’s issued a simple warning: If you’re a vendor who offers a solution that deploys EC2 instances to customer environments, and you don’t support IMDSv2, you’re going to be placed on a public list of shame. He’s right: His first shame example is AWS themselves with a new feature release. For those who aren’t aware of what IMDSv2 is, it’s the instance metadata service. Ideally, you have to authenticate against that thing before just grabbing data off of it. This is partially how Capital One wound up getting smacked a couple years back.

Corey: You know the drill: You’re just barely falling asleep and you’re jolted awake by an emergency page. That’s right, it’s your night on call, and this is the bad kind of Call of Duty. The good news is, is that you’ve got New Relic, so you can quickly run down the incident checklist and find the problem. You have an errors inbox that tells you that Lambdas are good, RUM is good, but something’s up in APM. So, you click the error and find the deployment marker where it all began. Dig deeper, there’s another set of errors. What is it? Of course, it’s Kubernetes, starting after an update. You ask that team to roll back and bam, problem solved. That’s the value of combining 16 different monitoring products into a single platform: You can pinpoint issues down to the line of code quickly. That’s why the Dev and Ops teams at DoorDash, GitHub, Epic Games, and more than 14,000 other companies use New Relic. The next late-night call is just waiting to happen, so get New Relic before it starts. And you can get access to the whole New Relic platform at 100 gigabytes of data free, forever, with no credit card. Visit newrelic.com/morningbrief that’s newrelic.com/morningbrief.

Corey: AWS’s Dan Urson has a thread on how to report security issues in other people’s software. Something about it’s been nagging at me, and I think I’ve figured out what it is. Ignore the stuff about, “Have a coherent report,” and, “Demonstrate a reproduction case;” it gets into following the vendor’s procedures and whatnot around disclosure. I think it has to do with where I’m coming from. I generally don’t find security problems, or other bugs, by actively exploiting vendor systems; instead, I trip over them as a customer trying to get something done. The idea that I owe that vendor much of anything when I’m in that position rankles a bit. I get that this is a nuanced topic.

And of course, 3TB of airport employee records were exposed in this week’s S3 Bucket Negligence Award. I hate to sound like I’m overly naive here, but what exactly is in the employee records that makes them take up that much space? I’m a big believer in not storing information you don’t need, and that just seems like an enormous pile of data to have lying around awaiting compromise.

AWS themselves had an interesting post go out: “Security Practices in AWS Multi-Te...