AWS Security is Twitching

Links:

• Disclosed a nasty auto-delete bug: https://arstechnica.com/information-technology/2021/10/researcher-refuses-telegrams-bounty-award-discloses-auto-delete-bug/
• Enroll basically all of it’s users: https://blog.google/technology/safety-security/making-sign-safer-and-more-convenient/
• Worth taking a look: https://labs.bishopfox.com/tech-blog/IAM-vulnerable-assessing-the-aws-assessment-tools
• Enumerate those yourself: https://www.hezmatt.org/~mpalmer/blog/2021/10/07/enumerating-aws-iam-accounts.html
• AWS Access Keys: https://www.nojones.net/posts/aws-access-keys-a-reference/
• Routes billions of text messages: https://www.vice.com/en/article/z3xpm8/company-that-routes-billions-of-text-messages-quietly-says-it-was-hacked
• “Enabling Data Classification for Amazon RDS database with Amazon Macie”: https://aws.amazon.com/blogs/security/enabling-data-classification-for-amazon-rds-database-with-amazon-macie/
• “How to set up a two-way integration between AWS Security Hub and Jira Service Management”: https://aws.amazon.com/blogs/security/how-to-set-up-a-two-way-integration-between-aws-security-hub-and-jira-service-management/
• “Update the alternate security contact across your AWS accounts for timely security notifications”: https://aws.amazon.com/blogs/security/update-the-alternate-security-contact-across-your-aws-accounts-for-timely-security-notifications/
• CloudSploit: https://github.com/aquasecurity/cloudsploit

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 things 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. You can take a look at this, but what it does is it provides an enterprise approach to drive these things throughout your entire environment and manage them centrally. You can 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: To begin with, the big news is that week is the week of the year in which the Last Week in AWS charity shirt is available for sale. All proceeds to benefit 826 National. To get your snarky, sarcastic shirt, “The AWS Status Page,” this year, visit lastweekinaws.com/charityshirt and thank you in advance for your support.

Now, last week’s big security news was about Amazon’s subsidiary, Twitch—or Twetch, depending upon pronunciation. It had a bunch of its code repos and streamer payouts leaked. Given that they are in fact an Amazon company largely hosted on AWS, you know, except for the streaming parts; are you a lunatic? That would cost ALL the money—this makes it tricky for AWS to message this as not their problem as per their vaunted Shared Responsibility Model. What’s the takeaway? Too soon to say but, ouch.

From the community. Telegram offered a researcher a €1,000 bounty, which is just insultingly small. The researcher said, “Not so much,” and disclosed a nasty auto-delete bug. If you’re going to run a bug bounty program, ensure that you’re paying researchers enough money to incentivize them to come forward and deal with your no-doubt obnoxious disclosure process.

You can expect a whole bunch of people who don’t care about security to suddenly be asking fun questions as Google prepares to enroll basically all of its users into two-factor-auth. Good move, but heads up, support folks.

I found a detailed analysis of AWS account assessment tools. These use things like CloudSploit, which I’ll talk about in a bit, IAM Vulnerable, et cetera. Fundamentally, they all look at slightly different things; they’re also all largely the same, but it might be worth taking a look.

AWS has made statements indicating that they don’t believe that enumerating which IAM accounts exist in a given AWS account is a security risk, so someone has put out a great technique you can use to enumerate those yourself. Why not, since Amazon doesn’t find this to be a problem.

A reference to the various kinds of AWS Access Keys is also something I found relatively handy because I hadn’t seen this ever explained before. It taught me a lot about the different kinds of key nonsense that I encounter in the wild from time to time. Take a look, it’s worth the read.