The Top 5 Cloud Security Risks of 2023 (So Far)

Originally published by Orca Security.

Written by Bar Kaduri and Jason Silberman.

As we approach the middle of 2023, we thought it an appropriate time to reflect on the cloud security risks and threats that we have seen so far this year.

After careful analysis of aggregated scan results from January-May this year, the Orca Research Pod has identified the top five most common, yet severe, cloud security risks that are ubiquitous in many cloud environments. In addition to revealing the risks and presenting the data we found, we also provide background information on each risk, as well as key recommendations on how to avoid these risks from occurring in the first place. We hope that this research will help organizations understand which areas can provide the greatest improvement in cloud security posture so they know where to focus their efforts.

Executive Summary

• The Orca Research Pod found that the five most common as well as severe cloud security risks of 2023 so far are, in order of severity: (1) unpatched exposed web services, (2) sensitive information in Git repositories, (3) unsecure sensitive AWS keys, (4) overprivileged IAM roles, and (5) overprivileged AWS Lambda functions. Each of these risks were found to be widespread in organizations of all sizes, even in those with a high maturity level in terms of cloud security.
• Even though these are not the newest and most talked about issues, they are part of cybersecurity 101 (such as the need to patch vulnerable web services and enforcing policies that adhere to the Principle of Least Privilege (PoLP)), and further highlight what is commonly said in the industry: that we should first focus on the security basics to make the largest improvement in cloud security postures.
• It is also important to acknowledge that many security teams are facing a huge backlog in open security alerts while being understaffed. This is hampering their ability to address risks in a timely manner, which is why prioritization of alerts, coupled with guided and automated remediation, are essential to overcome these challenges.
• The Orca Research Pod compiled this research by analyzing workload, configuration, and identity data captured from billions of real-world production cloud assets on Amazon Web Services (AWS), Microsoft Azure, Google Cloud, Kubernetes, and serverless functions, scanned from January 1st – May 1st, 2023.

Research Results

Below we list the five most common and critical cloud security risks of 2023 so far, in order of importance:

Finding #1: Patching is lagging on exposed web services

Orca found that 36% of organizations have an unpatched web service in their cloud environment that is exposed to the Internet and therefore easily accessible by attackers. Unpatched services, with known vulnerabilities and bugs, can be one of the main attack vectors into cloud environments. In fact, the majority of attack paths that the Orca Security research team detects and analyzes begin with an exploitation of a known vulnerability. The stakes are considerably higher if the service is web-facing, that is, accessible from outside the network.

Malicious actors can relatively easily exploit an unpatched vulnerability to cause service downtime, potential remote code execution, or more. In some cases, unauthorized remote access may also be a possibility.

All software has the potential to have vulnerabilities and bugs, including web services. Software vendors are responsible for discovering and fixing them before they are found and exploited by malicious actors. Software consumers are in turn responsible for immediately applying these fixes, released via updates or patches.

Finding #2: Sensitive information commonly stored in Git repository

Orca discovered that 50% of organizations have at least one Git repository containing sensitive data. Sensitive information such as database passwords, API keys, encryption keys, hash salts, and secrets, can mistakenly get pushed into a Git repository. In addition to this being contradictory to security best practices, if they are part of the source code of your application, attackers can potentially extract them and compromise your systems. Any pushed sensitive data must be detected and removed immediately, both from the repository and the history.

Finding #3: Sensitive AWS Keys often stored on file systems

49% of organizations have sensitive AWS keys stored on a file system inside a virtual machine. Think of AWS keys as literal keys to your system. Anyone with your key has access to all your resources and can perform any operations that you can, like launch EC2 instances, delete S3 objects, etc. This is why you must always store your keys in a safe location, and never share them with anyone, especially not external parties.

By default, sensitive AWS keys are stored on the file system. If these keys are obtained by a malicious actor, they can use them to access sensitive resources and perform unauthorized operations.

AWS keys provide indefinite access unless they are manually revoked. However, for many use cases, you don’t need long-term access without an expiration date. This is why AWS recommends using temporary credentials (generated using the Security Token Service) instead of AWS keys. In addition to the access key ID and secret access key, temporary credentials also have a security token that specifies the expiration date of the credentials.

Finding #4: Too many admin users per organization

Orca discovered that 33% of organizations grant full administrative privileges for more than 10% of IAM roles in their cloud environment, with 10% of the organizations even granting administrative permissions to more than 40% of their roles. This is way too many.

An IAM role in an AWS account is an identity with specific permissions that dictate what actions the identity can perform and which resources it can access. Unlike IAM users, IAM roles are not bound to a single person and can be assumed by anyone that is authorized to do so.

There are no long-term or indefinite security credentials associated with a role. Instead, short-term credentials are issued whenever a user assumes a role. Roles provide a great way to delegate access to users or applications that don’t usually need access to your resources.

IAM privileges are an example of how sometimes security is less convenient, but is still the correct choice. While it’s much faster, and easier, to grant many privileges to users—rather than restricting permissions and creating the need for more oversight—it’s a case of short-term gain and (potentially) larger damage in the long-term.

As a golden rule, it’s best to not, except in rare circumstances, define an IAM role with full administrative privileges, since anyone who assumes the role will have the ability to perform any action on any resource in the account. This violates the Principle of Least Privilege (PoLP), greatly increases the attack surface, and increases the risk of full account takeover.

Finding #5: Majority don’t use separated roles for Lambda functions

Orca discovered that 70% of organizations have at least two Lambda functions that share the same IAM role. In addition, almost 86% of all Lambda functions are sharing their IAM role.