Did your research: Prior Art for "15 ideas for cloud security research"

Feb 14, 24
Did your research: Prior Art for

The inimitable Daniel Grzelak (dagrz) over at Plerion shared “15 ideas for cloud security research”

I figured I’d take it a step further and offer you a set of references to bootstrap your work on any of these ideas! Take inspiration, steal liberally, and share back

How to make and find malicious cloud formation

From 2019, Rhino Security’s AWS CloudFormation and Resource-Injection Walkthrough launched a Pacu module cfn__resource_injection.

Scott Piper also has written up Stack Set phishing over at tldrsec.

How I hacked [pick an AWS service]

Check out TrustOnCloud’s Threat Models, such as “The last S3 security document that we’ll ever need, and how to use it”, as a maximalist take on this idea. I have my own minimalist version for Lambda over on my “Lambda risks” Wiki

Cloud Conformity is a solid knowledge hub, as is the Datadog Cloud Security Atlas

Inference: What I deduced about your AWS environment

This is all about recon, so see:

  1. Daniel’s recent Conditional Love for AWS Metadata Enumeration, which built on Ben Bridts’ Finding the Account ID of any public S3 bucket
  2. Check out the “Enumeration” section for each CSP from hackingthe.cloud

I read every warning in AWS documentation

Check out AWS Reference Notes!

I scan the AWS IP space every day

Here’s someone 10 years ago setting up massscan

Here’s 2020 research hunting specific targets based on TLS certificates

Here’s a time someone did this and focused on open ElasticSearch and Kibana in 2022.

Honey account

Check out Chris Farris’ “Public Access Keys - 2023” project, and the follow up The Consistently Inconsistence response to Access Key Leaks. Also, Orca’s 2023 Honeypotting in the Cloud Report.

Burning $

Ian McKay is a master of this art form, with his List of expensive / long-term effect AWS IAM actions. Corey Quinn also frequently explores this topic in Last Week in AWS, such as in The Cloud Genie

Error message mapping

Fewer pointers here, but the implies Nick Fritchette’s work. Research like Enumerate AWS API Permissions Without Logging to CloudTrail is often based on error messages and codes. I’d especially recommend you brush up on A Look at AWS API Protocols

Endpoint mapping

Ah, Nick again for this one! He’s found a few bugs in undocumented AWS APIs: Amplify example, Bypassing CloudTrail in AWS Service Catalog, and Other Logging Research. Same thing for Gafnit Amiga’s AWS ECR Public Vulnerability

You could use aws-api-models, a repository of documented and undocumented AWS API models extracted from the AWS console, originally compiled by Nick, as a starting point. Keep an eye out for more work from him in this area!

Tagging for security

Auto-tagging? I always think of bridgecrew’s open source yor

Who should fix it? Take some inspiration from Matt Fuller’s OG fwd:cloudsec talk It’s Time to Rethink the Shared Security Responsibility Model

Zero $ CSPM

Not to talk my own book, but I cover a very high level of this in my Beyond the AWS Security Maturity Roadmap - Asset Inventory & CSPM Section slides

On the technical side, I’d probably start with steampipe (or a competitor), dump the data into Snowflake (or similar), then add a couple IAM tools like Cloudsplaining and PMapper to get better coverage on Identity. I’d focus on the three “perimeters” to start: Identity, Network, and Data - these are where issues are most likely to cause a breach

Extend someone else’s research - Dive into some of the awesome work others are doing like Gafnit Amiga, Aidan Steele, Scott Piper, Ian Mckay, Ben Bridts and try and take the next step

I’ve mentioned Gafnit, Ian, and Ben already!

Aidan is hard to compete with, but one of his magic tricks is beating AWS to delivering clients and open source implementations of new features. He did this with openrolesanywhere, for example. So the recipe would be: 1) Pick a new feature, that lacks an open source client, architecture, implementation, etc. 2) Implement it 3) Share both the implementation, and what it taught you about the service, internals, etc.

Scott is maybe my most direct inspiration in cloud security research. I’d think about:

  1. flaws.cloud/flaws2.cloud something you enjoyed? Extend the wonderful Seth Art’s CloudFoxable
  2. Enjoy his blogs? Me too! Go through some of the older ones and revisit them: what’s the current state for ransomware prevention? anything new in the world of client side monitoring? (check out iamlive from Ian here!) Are Managed Policies any better these days?
  3. Like his open source lists? Maybe take https://github.com/fwdcloudsec/known_aws_accounts and create a POC of integrating it to your CSPM or SIEM or CNAPP or CANAPE (that’s made up, don’t panic!)

Improve a compliance framework

  • You could do a mapping exercise like Chris Farris’ Mapping CIS Controls to Cloud
  • You could review the CIS Foundational Benchmark for AWS and rate how useful each is/stack rank (please, please convince them to drop MFA Delete for S3!)
  • Look at a revision like PCI DSS 4.0, and share what changes are relevant for cloud security

AWS advice on the internet sux

This one feels risky! It would be easy to punch down here at folks who are genuinely trying to help. This is also complicated by the fact that AWS controls have improved over the years – any recommendation from a couple years ago may only be wrong due to improvements.

A few tips though:

  1. A fun spin would be to focus on “bad infrastructure-as-code”. You could analyze popular Terraform modules or CloudFormation stacks and highlight the insecure defaults, then upstream fixes!
  2. Maybe focus on educating on improvements to secure defaults (ex. S3 bucket encryption!) and tie that back to guidance that is now invalidated
  3. If you’re going with the initial proposal, the Kaggle StackOverflow dataset might help get you started!

IaC backdoors

I’m not aware of much on the backdoor side, but for Terraform would point to some great existing work on attacks: