Links:

• Enumeration vulnerability in AWS: https://twitter.com/donkersgood/status/1433148548565151748
• Lacework Cloud Threat Report: cloud-threat-report.html">https://info.Lacework.com/2021-cloud-threat-report.html
• High Availability WireGuard On AWS: https://www.procustodibus.com/blog/2021/02/ha-wireguard-on-aws/
• How to improve visibility into AWS WAF with anomaly detection: https://aws.amazon.com/blogs/security/how-to-improve-visibility-into-aws-waf-with-anomaly-detection/
• How US federal agencies can authenticate to AWS with multi-factor authentication: https://aws.amazon.com/blogs/security/how-us-federal-agencies-can-authenticate-to-aws-with-multi-factor-authentication/
• Ransomware mitigation: Top 5 protections and recovery preparation actions: https://aws.amazon.com/blogs/security/ransomware-mitigation-top-5-protections-and-recovery-preparation-actions/
• Top 10 security best practices for securing data in Amazon S3: https://aws.amazon.com/blogs/security/top-10-security-best-practices-for-securing-data-in-amazon-s3/

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 Thinkst Canary. This might take a little bit to explain, so bear with me. I linked against an early version of their tool, canarytokens.org, in the very early days of my newsletter, and what it does is relatively simple and straightforward. It winds up embedding credentials, files, or anything else like that that you can generate in various parts of your environment, wherever you want them to live; it gives you fake AWS API credentials, for example. And the only thing that these are empowered to do is alert you whenever someone attempts to use them. It’s an awesome approach to detecting breaches. I’ve used something similar for years myself before I found them. Check them out. But wait, there’s more because they also have an enterprise option that you should be very much aware of: canary.tools. Take a look at this: what it does is it provides an enterprise approach to drive these things throughout your entire environment and manage them centrally. You can even get a physical device that hangs out on your network and impersonates whatever you want to. When it gets Nmap scanned, or someone attempts to log into it, or access files that it presents on a fake file store, you get instant alerts. It’s awesome. If you don’t do something like this, instead you’re likely to find out that you’ve gotten breached the very hard way. So, check it out. It’s one of those few things that I look at and say, “Wow, that is an amazing idea. I am so glad I found them. I love it.” Again, those URLs are canarytokens.org and canary.tools. And the first one is free because of course it is. The second one is enterprise-y. You’ll know which one of those you fall into. Take a look. I’m a big fan. More to come from Thinkst Canary in the weeks ahead.

Corey: This is the inaugural episode of what is going to become a weekly feature, the AWS Morning Brief: Security Edition, where I do what I normally do: round up the news from Amazon’s cloud ecosystem, pick the things that I find interesting and make fun of them, only in the security world. This is going to be things that the rest of us need to care about, not the things that AWS feels a content need to put out there, but no one in the trenches tends to read. If you don’t work in security—by which I mean have the word security not in your job title—you’re in the right place. Neither do I, but I still have to care. So, what happened last week? Well, let’s dive in and we’ll see how this show shapes up.

We begin with the fact that there’s a contingent of anti-cloud folks out there who make the argument that [the cloud is somehow insecure, unsafe for your data, and not something you should be doing 00:08:26]. I generally have little patience for those folks, but when Azure’s Cosmos DB had a bug that allowed third parties unfettered and unlogged access to customer data, I’m hard-pressed to disagree with them. Events like this aren’t good for anyone. Companies don’t say things like, “Wow, as your security seems dicey, I’m going to use AWS or Google Cloud instead.” They say things instead, like, “Can’t trust the cloud. Hey, Dewey, fire up your Motel Six loyalty card because you’re about to spend the next nine months on the road building more company data centers for us.” Events like this weaken us all.

The second volume of the cloud-threat-report.html">Lacework Cloud Threat Report has been released, and one of the things I really appreciate about it is that it talks about what’s actually going on in the wild, not invented theoretical threats that are designed to get you to shovel money into their product. I do not and will not condone the fear, uncertainty, and doubt—or FUD—marketing approach. There’s a reason that The Duckbill Group’s web pages are about how we help, not stuffed full of dire warnings about what might go wrong and blow the budget. If I can do it, so can the entire security industry. Nice job, Lacework, on that one.

There was a [great screed on Twitter 00:08:26] last week on the perils of using AWS read-only managed policies. The gist of the argument is that AWS is always updating these things, and permissions that aren’t included today may well be included tomorrow. Further, AWS does indeed have over-scoped permissions in managed policies. I gave a talk about one of them at re:Invent 2019. It’s a good thing to be aware of. While managed policies are definitely convenient, even AWS claims its security policies all squarely on the customer side of the shared responsibility model. Well, when they screw theirs up, they claim that anyway.

Luc van Donkersgoed recently found an enumeration vulnerability in AWS that allows users to determine valid account IDs and any IAM principles in it. AWS insists that this information is not sensitive and thus this doesn’t constitute a vulnerability. I can see that viewpoint, but if it’s true, why do AWS blog post screenshots always blur the account ID? Why isn’t there an API to explicitly get the account ID for a given resource?

The AWS documentation on account identifiers states that you shouldn’t provide credentials to third parties; it doesn’t say anything about account IDs. The messaging is, at a minimum, confusing. Until then, treat your AWS account ID as sensitive, I guess. There’s not a lot of reason for third parties to need it. I just wish AWS wo...