summitroute / csp_security_mistakes Goto Github PK

https://orca.security/resources/blog/synlapse-critical-azure-synapse-analytics-service-vulnerability/

https://twitter.com/opsmorph/status/1493514089225666561

Azure App Service RCE / Sandbox Escape (CVE-2019-1372)

• Summary: A Vulnerability in App Service could allow an unprivileged function run by the user to execute code in the context of NT AUTHORITY\system thereby escaping the Sandbox. This Vulnerability allowed cross-account access when using Free/Shared tier.
• Platform: Azure
• Severity: Critical
• Date: Reported: June 27, 2019, Published: January 30, 2020
• Discoverer: Ronen Shustin (@ronenshh)
• Customer action: Azure Cloud - N/A, Azure Stack / Windows Azure Pack Web Sites V2 - Manual Update
• References: https://research.checkpoint.com/2020/remote-cloud-execution-critical-vulnerabilities-in-azure-cloud-infrastructure-part-ii/

https://awsteele.com/blog/2022/02/03/aws-vpc-data-exfiltration-using-codebuild.html

https://twitter.com/TzahPahima/status/1536705378049789952

https://www.gosecure.net/blog/2021/10/19/a-scientific-notation-bug-in-mysql-left-aws-waf-clients-vulnerable-to-sql-injection/

Recommending for inclusion as AWS chose to patch. Would not generally consider WAF bypasses notable

Christophe Parisel on LinkedIn created a Piercing Index to define how to calculate the severity: https://www.linkedin.com/feed/update/urn:li:activity:6896378758501154816/

https://ianduffy.ie/2016/11/26/azure-bug-bounty-pwning-red-hat-enterprise-linux/

• Reference the Cloud CVE Database Slack.
• Wiz post and their BH video
  • https://www.youtube.com/watch?v=JEA_Zgi8Tjg&list=PLH15HpR5qRsW62N-GLRb1q56Zr7sm10rF&index=8&ab_channel=BlackHat
  • https://blog.wiz.io/security-industry-call-to-action-we-need-a-cloud-vulnerability-database/

We need a better way to reference these than by the titles I gave them.

https://twitter.com/itspeterc/status/1534205155914264576

https://twitter.com/0xdabbad00/status/1473448889948598275

https://twitter.com/Frichette_n/status/1400517723910819844

https://orca.security/resources/blog/aws-glue-vulnerability/
https://orca.security/resources/blog/aws-cloudformation-vulnerability/

Should you have a Discover Date and a Fix Date field? Or maybe i should be asking - what happens to these issues once they are addressed? Do they go off this page? If not, i suggest a fix date be added.

https://twitter.com/0xdabbad00/status/1027701783693389826

https://www.whitesourcesoftware.com/resources/blog/aws-targeted-by-a-package-backfill-attack/

• Multiple Cloud Providers (Including Amazon AWS) Local Privilege Escalation
• Summary: A Vulnerability in 3rd party library used by several cloud providers could allow an unprivileged users to escalate privileges to kernel mode.
• Platform: Multiple
• Severity: High
• Date: Reported during Q1 2021, Published: December 07, 2021.
• Discoverer: Kasif Dekel (@kasifdekel)
• Customer action: Install patched software.
• References: https://www.sentinelone.com/labs/usb-over-ethernet-multiple-privilege-escalation-vulnerabilities-in-aws-and-other-major-cloud-services/

Add Brandon Sherman's AmazonSageMakerFullAccess issue: https://summitroute.com/blog/2019/06/18/aws_iam_managed_policy_review/

Add https://duo.com/blog/potential-gaps-in-suggested-amazon-web-services-security-policies-for-mfa

https://medium.com/ymedialabs-innovation/an-aws-managed-policy-that-allowed-granting-root-admin-access-to-any-role-51b409ea7ff0

There are a lot of these and I'm not sure if I should list every minor one.

https://bugs.xdavidhu.me/google/2021/12/31/fixing-the-unfixable-story-of-a-google-cloud-ssrf/

and this list: https://security.googleblog.com/2021/03/announcing-winners-of-2020-gcp-vrp-prize.html

https://www.secureworks.com/research/azure-active-directory-exposes-internal-information

https://www.wiz.io/blog/azure-app-service-source-code-leak

https://blog.lightspin.io/aws-rds-critical-security-vulnerability

https://unit42.paloaltonetworks.com/gke-autopilot-vulnerabilities/

https://security.googleblog.com/2022/06/announcing-winners-of-2021-gcp-vrp-prize.html

https://orca.security/resources/blog/oracle-server-side-request-forgery-ssrf-attack-metadata/

Security September (which includes two issues already in the repo) had five entries, one of which was unexploitable.

1. https://onecloudplease.com/blog/security-september-racing-against-cloudwatch-synthetics-canaries
2. https://onecloudplease.com/blog/security-september-fun-with-fncidr
3. Ian has also disclosed: https://onecloudplease.com/blog/s3-bucket-namesquatting
4. GKE and EKS were vulnerable to the CAP_NET_RAW issues as well
5. A 2012 security analysis of AMIs found

   we were also able to undeleted 8,996 files from an official image that was published by Amazon AWS itself.

6. csv injection in cloudtrail disclosed by Rhino
7. 2008 - AWS Sig V1 vulnerability

https://mbrancato.github.io/2021/12/28/rce-dataflow.html

Wanted to check if this makes sense to open a PR for. The issue was AWS originally allowed the 169.254.169.254 to be routed to other EC2 instances, allowing them to effectively act as the IMDS server for the VPC.

This allowed lateral movement across instances due to the fact during boot cloud-init will run user data as root from this IP without verifying whether the server is trusted or not.

Reference: https://github.com/RyanJarv/EC2FakeImds

From my understanding this is not possible anymore for any account that hasn’t used this feature in the past. I don’t believe AWS made any public comment on this however.

https://github.com/SummitRoute/csp_security_mistakes#azure-notlegit-app-service-vulnerability-exposed-source-code-repositories

The reference here should be https://www.wiz.io/blog/azure-app-service-source-code-leak/

https://twitter.com/_fel1x/status/1391712232380194818

Note the same issue impacted Azure.

Would be nice to known if the issue was resolved or not

Azure: Container Breakout in Azure Cloud Shell and Azure Container Instances

• Summary: Azure failed to restrict customers' containers on ACS and ACI from accessing services on the underlying node, allowing for container breakout via the Kubelet API which allowed anonymous access. The researcher could see other customers' containers running on neighboring Kubernetes nodes, but decided to stop and report to MSRC. Though cross-account access wasn't demonstrated, the high bounty (30,000$) indicates MSRC considered the issue to be severe. It should be noted that compromising another customer's Cloud Shell instance is an absolutely devastating attack resulting in a full takeover of the victim's Azure account.
• Platform: Azure
• Severity: High or Critical, up to you
• Date: January 20, 2020
• Discoverer: Chen Cohen
• Customer action: N/A
• References:
  • https://hencohen10.medium.com/i-own-your-cloud-shell-taking-over-azure-cloud-shell-kubernetes-cluster-through-unsecured-558621519cf9

Hello,

https://twitter.com/nJoyneer/status/1526593840928411650?t=uLgCnUvoD2dwVyajbR3U0Q&s=19

I'm surprised by the late disclosure after AWS fix.

https://github.com/SummitRoute/csp_security_mistakes#aws-aws-employee-posts-customer-access-keys-and-information

The Register reports:

A spokesperson for Amazon has told us the code repository was used by the engineer in a personal capacity, and claimed no customer data or company systems were exposed.

https://www.theregister.com/2020/01/23/aws_engineer_credentials_github/

This repo is a good start at collecting this data, but ultimately it needs to be presented via a webapp that can provide filtering and sorting. Some people are primarily interested in specific CSPs (ex. #23), most recent issues (#6), most severe issues, and more. I think backing this data in github is beneficial for transparency, submitting PRs and issues, etc. but the presentation of this data needs to be improved.

Would it make sense to split the main file into per-provider files? It's long enough now that if nothing else a hyperlinked table of contents would be a massive help...

https://orca.security/resources/blog/autowarp-microsoft-azure-automation-service-vulnerability/

https://cloudsecurityforum.slack.com/archives/C6DN616HG/p1653611790045629

I found a security vulnerability in MWAA (Amazon Managed Workflows for Apache Airflow) that has been fixed so now I can talk about it. Specifically there are two API calls that the service uses to convert IAM credentials into tokens that can be used to login to airflow. The CreateCliToken and CreateWebLoginToken were logging the tokens to CloudTrail. The event used included the hostname for the airflow server, so everything required to login to the server was in the event.

Reported May 11th, fixed May 22.

tokens are only valid for 60 seconds and CloudTrail log delivery is not fast enough that they are valid by the time an AWS customer can see them.

It seems like it might be more useful to have the items in reverse chronological order, with newest first.