Osor0s@vito Check out #AdventOfCloudSecurity day 10
https://infosec.exchange/@christophetd/109491506163807997
you are looking for "IAM Roles for Service Accounts"
Christophe :purple_potion: (@[email protected])
Attached: 4 images ποΈ December 10th #AdventOfCloudSecurity Pods running in an EKS cluster often need an identity in AWS, for instance to write to an S3 bucket or read from a DynamoDB table. The best (and easiest) way to achieve this securely is to use "IAM Roles for Service Accounts" (IRSA). Every EKS cluster comes with a backing OIDC provider. You can set a trust policy on an IAM role to delegate it to the EKS cluster. Then: 1. Create a K8s service account, and annotate it with `eks.amazonaws.com/role-arn: <your-role-arn> 2. Run your pod under this service account. An OIDC token is automatically mounted in the pod 3. You can use `sts:AssumeRoleWithWebIdentity` to exchange this token for temporary AWS credentials for the role! Bonus: this is totally transparent if you use the AWS CLI or an AWS SDK. References: * [IAM Roles for Service Accounts](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) * [AWS Blog: Diving into IAM Roles for Service Accounts](https://aws.amazon.com/blogs/containers/diving-into-iam-roles-for-service-accounts/)
Christophe 
ποΈ December 24th #AdventOfCloudSecurityβ
Together with @houston and @rami we wrote an analysis of over 50 publicly disclosed cloud breaches of 2022!
https://securitylabs.datadoghq.com/articles/public-cloud-breaches-2022-mccarthy-hopkins/
Merry Christmas to everyone who celebrates it!
ποΈ December 23rd #AdventOfCloudSecurityβ
"IAM vulnerable" by @sethsec is a great project to practice privilege escalation on AWS.
Comes with 31 different privilege escalation paths. Each one can be created and destroyed using Terraform, and comes with a write-up.
https://github.com/BishopFox/iam-vulnerable
https://bishopfox.com/blog/aws-iam-privilege-escalation-playground
GitHub - BishopFox/iam-vulnerable: Use Terraform to create your own vulnerable by design AWS IAM privilege escalation playground.
Use Terraform to create your own vulnerable by design AWS IAM privilege escalation playground. - GitHub - BishopFox/iam-vulnerable: Use Terraform to create your own vulnerable by design AWS IAM pri...
ποΈ December 22nd #AdventOfCloudSecurityβ
"Device code authentication" is a handy but also potentially dangerous feature of the OpenID Connect protocol.
For any identity provider that supports it, including AWS SSO and Azure AD, you can use it to bypass MFA / identity provider level controls such as IP allow-listing or device enrollment checks.
See a previous blog post with additional details, a proof of concept, and the detailed set of CloudTrail events generated.
ποΈ December 21st #AdventOfCloudSecurityβ
Most organizations getting breached on AWS are due to one of:
- Static, long-lived credentials that end up getting leaked
- Public S3 buckets
- Stolen instance credentials through an SSRF
Last year, I wrote down an analysis on most publicly reported cloud breaches: Cloud Security Breaches and Vulnerabilities: 2021 in Review - 2022 edition will be out soon!
See also my SANS New2Cyber presentation: "A Primer on Cloud Security and How Companies Get Hacked on AWS" and the associated mindmap.
ποΈ December 20th #AdventOfCloudSecurityβ
You don't need to open SSH ports to the Internet! Instead, you can use AWS SSM Session Manager to get a shell on any EC2 instance that runs the SSM agent (installed by default on several operating systems).
Advantages:
- No SSH port is open to the Internet
- Instances don't need a public IP / Internet access (you can have them use a VPC endpoint for SSM)
- You can control who can access instances through IAM policies! (in particular,
ssm:StartSession).
Bonus: Also works for port forwarding and with standard tooling like Ansible or Packer.
Drawback: An attacker compromising an identity that has ssm:StartSession or ssm:RunCommand can trivially automate running a command on all your instances at once (see an example).
References:
ποΈ December 19th #AdventOfCloudSecurityβ
Reading/writing objects from an S3 bucket does not generate any CloudTrail event by default.
That's because they tend to be highly noisy. However, it might make sense to selectively enable it on high-value buckets. For instance, enabling the logging of object write events on a bucket holding release artifacts. Incidentally, it also gives companies with leaky S3 buckets plausible deniability to say they "have no evidence data was accessed by a malicious actor".
Same goes for other services such as DynamoDB reads/writes and Lambda invocations.
The Terraform aws_cloudtrail documentation has great examples on how to selectively enable S3 data events.
References:
ποΈ December 18th #AdventOfCloudSecurityβ
If you have a security group that's open to something else than 0.0.0.0/0 and you restrict it further, it will not close established TCP connections.
This means in an IR case where you're blocking IPs, it's important to do it at the NACL level (which unfortunately may be impractical).
References:
Security group connection tracking - Amazon Elastic Compute Cloud
Your security groups use connection tracking to track information about traffic to and from the instance. Rules are applied based on the connection state of the traffic to determine if the traffic is allowed or denied. With this approach, security groups are stateful. This means that responses to inbound traffic are allowed to flow out of the instance regardless of outbound security group rules, and vice versa.
ποΈ December 17th #AdventOfCloudSecurity
You can retrieve the AWS account ID from any public S3 bucket. This technique leverages the s3:ResourceAccount condition key.
s3:ResourceAccount: 0*s3:ResourceAccount: 1*, s3:ResourceAccount: 2*...Tool: https://github.com/WeAreCloudar/s3-account-search
Reference: https://cloudar.be/awsblog/finding-the-accountid-of-any-public-s3-bucket/
The same technique also appears to work to guess Organization IDs (through the condition key aws:ResourceOrgID)
ποΈ December 16th #AdventOfCloudSecurity
It's easy to imagine that Lambda functions are "disposable containers" that get spun up and torn down on each invocation. Unfortunately (or fortunately) that's not the case - it would be too slow. Lambda invocations actually reuse the same runtime environment (firecracker VM or container). Not always, but they do.
An attacker compromising a Lambda function through a RCE can therefore persist, and steal events of other invocations of the function, such as HTTP requests from other clients forwarded from an API Gateway!
References:
- https://unit42.paloaltonetworks.com/gaining-persistency-vulnerable-lambdas/
- https://hackingthe.cloud/aws/post_exploitation/lambda_persistence/
- https://frichetten.com/blog/revisiting_lambda_persistence/
Original research: Yuval Avrahami (Unit42)
See also: Cold Starts in AWS Lambda
Gaining Persistency on Vulnerable Lambdas
This post is also available in: ζ₯ζ¬θͺ (Japanese)Serverless Security AWS Lambda was released in 2014 and introduced a new cloud execution model β serverless computing, which is now widely adopted. Since then, numerous companies began offering security solutions for AWS Lambda and serverless computing in general. These security platforms commonly provide: Vulnerability Scanning β Ensuring...