Supported Services and Risks
Panoptica continually scans your cloud resources for potential risks, security issues and vulnerabilities across dozens of key services. This catalog provides a complete list of the services Panoptica scans across multiple cloud providers and platforms, and the hundreds of risks Panoptica can detect in those services. The results of these scans show up in different aspects of the Panoptica platform:
- To view the services Panoptica has identified in your environment, see Asset Inventory.
- To view the risks Panoptica has identified, see Security Posture.
- To view those risks prioritized and contextualized, see Attack Paths.
The catalog is sorted by provider, service name, and category. In Chrome or Edge, use the Table of Contents to the right to navigate to the information you're looking for. Firefox and Safari, however, are unable to expand a section to display an anchor link within, like Chrome and Edge can. If you're using Firefox or Safari, click the cloud provider header in the Table of Contents (AWS, Azure, GCP, etc.), then select the service you want to expand in the main section.
Amazon Web Services (AWS) - click to collapse
Amazon Web Services (AWS)
Click on a service name below to view a table of the risks Panoptica detects in AWS, along with brief descriptions and attack scenarios.
AWS Certificate Manager
AWS Certificate Manager
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Insecure Configurations | ACM Certificate Without Minimum Of 2048-bit Key For RSA Certificate | An ACM certificate that does not use a minimum of 2048-bit key for RSA certificate. | "A key length of 1024 bit is not considered secure, as it can be cracked using brute-force methods. Upgrade your certificates to 2048-bit or 4096-bit RSA certificates which are using stronger encryption algorithms." |
Neglected Resource | ACM Certificate Expires In 30 Days | An ACM certificate is going to expire in 30 days. | It is not a best practice to have an expired certificate. An expired certificate can be accidentally deployed to another resource, leading to application errors and credibility damage. Renew the certificate as soon as possible. |
Neglected Resource | ACM Certificate Pending Validation | An ACM certificate with 'PENDING_VALIDATION' status. | When an ACM certificate is not validated within 72 hours, it becomes invalid and you have to create a new certificate request. |
Neglected Resource | Expired ACM Certificate | An expired ACM certificate. | It is not a best practice to have an expired certificate. An expired certificate can cause an accidental deployment to another resource, leading to application errors and credibility damage. |
Neglected Resource | Invalid ACM Certificate | An ACM certificate with 'FAILED' or 'VALIDATION_TIMED_OUT' status. | It is not a best practice to have invalid certificates. Invalid certificates should be deleted. |
Neglected Resource | Unused ACM Certificate | Unused ACM Certificate | It is not a best practice to have unused certificates. Unused certificates should be used or removed. |
Amazon CloudFront
Amazon CloudFront
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Insecure Configurations | CloudFront Distribution Lacking WAF Protection | This risk highlights a CloudFront distribution that is not protected by a Web Application Firewall (WAF). Without WAF protection, your distribution may be vulnerable to common web exploits that could affect availability or compromise security. To enhance your distribution's security, it's recommended to attach a properly configured WAF to your CloudFront distribution. | "A WAF helps protect web applications by filtering and monitoring traffic. It usually protects web applications from attacks such as cross-site forgery, cross-site-scripting (XSS), file inclusion, and SQL injection. An attacker can use this opportunity to attack your application." |
Insecure Configurations | CloudFront Distribution Permitting Insecure HTTP Connections | This risk underscores a CloudFront distribution that allows insecure HTTP connections. Such connections could expose your data to potential risks during transmission. It's advised to enforce secure HTTPS connections for your CloudFront distribution to ensure the security and integrity of your data. | An attacker can gain access to traffic between your CloudFront distribution and the application viewers. |
Insecure Configurations | CloudFront Distribution with Logging Disabled | This risk signifies a CloudFront distribution that has logging disabled. Without logging, it can be challenging to monitor and troubleshoot your distribution's activity. It's highly recommended to enable and properly configure logging for your CloudFront distribution to ensure effective operations and prompt issue resolution. | CloudFront distribution logging is used to track all the requests. It is necessary for investigating activities and for auditing purposes. |
Insecure Configurations | CloudFront Operating with Unencrypted Origin Server Connection | This risk identifies a CloudFront distribution configured to operate with an unencrypted connection to the origin server. Such a configuration can expose your data to unnecessary risks during transmission. It's highly advised to secure the connection to your origin server with encryption, such as HTTPS, to uphold the integrity and confidentiality of your data. | An attacker can gain access to traffic between your CloudFront distribution and an origin server. |
Insecure Configurations | CloudFront With Insecure TLS Ciphers | A CloudFront distribution that does not use secure TLS (Transport Layer Security) protocol versions. | It is recommended to use the latest version of TLS if possible. Older versions (prior to TLS 1.2) may be deprecated or may contain known vulnerabilities that an attacker can use. |
Amazon DocumentDB
Amazon DocumentDB
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Insecure Configurations | DocumentDB Audit Logs Export Disabled | DocumentDB cluster without export audit logs to Cloudwatch. | Without comprehensive auditing, there's a higher risk of undetected security breaches or unauthorized access to your system. |
Insecure Configurations | DocumentDB Cluster has Short Retention Period | DocumentDB cluster has less than 7 days backup retention period. | A backup retention period ensures that you have a reliable copy of your data in case of accidental deletion, corruption, or other data loss events. |
Insecure Configurations | DocumentDB without Deletion Protection | Deletion protection is disabled. | Disabling deletion protection in a DocumentDB can introduce several security risks. Deletion protection is a feature that prevents accidental or unauthorized data deletions, and disabling it can make your database more vulnerable to various threats. |
Insecure Configurations | DocumentDB Without Storage Encryption | An attacker with access to the DocumentDB can access sensitive data stored in the DB. | This risk indicates an Amazon DocumentDB that lacks encryption, a critical security measure to safeguard sensitive data from unauthorized access. Unencrypted database instances raise the risk of data exposure or misuse, mainly if accessed by unauthorized entities. Implementing encryption to secure your data and comply with best practices and regulations is strongly recommended. |
Amazon DynamoDB
Amazon DynamoDB
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Neglected Resource | DynamoDB Table Without Continuous Backup | A DynamoDB table without continuous backups for the point-in-time recovery feature. | It is a best practice to enable continuous backups for your DynamoDB tables. DynamoDB continuous backups, powered by Point-in-time Recovery (PITR) feature, will help you protect your DynamoDB data against accidental writes, deletes, or any loss of data. |
Insufficient Monitoring | DynamoDB Streams is disabled | DynamoDB Streams is disabled. DynamoDB Streams is a feature of AWS DynamoDB that captures a time-ordered sequence of item-level modifications in any DynamoDB table and stores this information in a log for up to 24 hours. Whenever an application performs create, update, or delete operations on items in the table, DynamoDB Streams writes a record of the changes to a stream. When DynamoDB Streams is disabled for a table, no stream records will be captured or available for that table. This implies that any applications or services that depend on this stream for triggers or data will not receive any updates. Also, any existing stream data for the table will be inaccessible, and the history of changes will not be stored. | The absence of DynamoDB streams means there is no real-time monitoring or auditing trail of item-level changes, which could delay the detection of unauthorized modifications to the database. As a result it could potentially give an attacker more time to operate unnoticed within the system. |
Insufficient Encryption | DynamoDB Encrypted at Rest with Amazon DynamoDB Key | AWS DynamoDB table encrypted with Amazon DynamoDB key. | KMS service allows you to easily create, rotate, disable and audit Customer Master Keys created for your Amazon DynamoDB. Using a default Amazon DynamoDB key to encrypt DynamoDB table in AWS is not recommended due to limited control over key management, potential security risks from shared keys across accounts, and inadequate support for key rotation. |
Insecure Configurations | DynamoDB Table without Deletion Protection | Deletion protection is disabled. | Disabling deletion protection in DynamoDB can introduce several security risks. Deletion protection is a feature that prevents accidental or unauthorized data deletions, and disabling it can make your database more vulnerable to various threats. |
Insufficient Encryption | DynamoDB Encrypted at Rest with AWS Managed Key (Single) |
Amazon EC2
Amazon EC2
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Insecure Configurations | Default Security Group Assignment | The EC2 instance uses the default Security Group. | An attacker might exploit misconfuguration or wide allowed outbound IP range to obtain network access to the EC2 instance. |
Insecure Configurations | EC2 Classic Instance Not Operating Within a VPC | This risk underscores an EC2 Classic instance that is not operating within a Virtual Private Cloud (VPC). Operating outside of a VPC may expose your EC2 instance to unnecessary security risks and limit control over network configuration. It's strongly advised to migrate your EC2 Classic instances to a VPC, providing an additional layer of security and increased control over networking aspects, to bolster your system security. | Current workloads might be interrupted. |
Insecure Configurations | EC2 Instance Operating with Unsecured Metadata Service | This risk points to an EC2 instance that has metadata services enabled without the necessary security tokens. Without these tokens, the metadata services, which can hold sensitive information about the EC2 instance, are exposed to potential unauthorized access. This vulnerability can lead to security breaches and data leaks. It is strongly recommended to secure the metadata services by implementing required security tokens, ensuring proper authorization, and thereby safeguarding the integrity of the instance's metadata. | When the instance is public and has a connection to the internet, the attacker can take advantage of these default configurations and get full access to the instance and its permissions. This is a default configuration that most of the developers are not aware of. The default configuration can leave your environment at increased risk in the event of a credential exposure/compromise. The metadata information is available by making a request to the IP address of 169.254.169.254. The current AWS Metadata service does not require any HTTP headers to be present and allows any process to make HTTP requests, and it allows an attacker to trick the instance with SSRF (server-side request forgery) vulnerability and making an HTTP/HTTPS requests on his behalf. |
Insecure Configurations | Load Balancer Operating with Outdated SSLv3 Protocol | This risk category identifies a Load Balancer that is configured to use the outdated SSLv3 protocol. The SSLv3 protocol has known vulnerabilities and its use poses a significant security risk, including susceptibility to the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack. It is strongly advised to update the Load Balancer's configuration to use a more secure, modern protocol such as TLS 1.2 or TLS 1.3. By doing so, you can reduce the risk of data breaches and ensure secure, encrypted communication. | This version has a flaw that could allow an attacker to decrypt information, such as authentication cookies. This vulnerability is known as POODLE attack - man-in-the-middle exploits which take advantage of Internet and security software clients' fallback to SSL 3.0. |
Insecure Configurations | RDS Database Instance Without Encryption | An attacker with access to the RDS DB can access sensitive data stored in the DB. | This risk indicates an Amazon RDS database instance that lacks encryption, a critical security measure to safeguard sensitive data from unauthorized access. Unencrypted database instances raise the risk of data exposure or misuse, mainly if accessed by unauthorized entities. Implementing encryption to secure your data and comply with best practices and regulations is strongly recommended. |
Public Exposure | Public AWS EBS Snapshot | Publicly shared Elastic Block Store (EBS) volume snapshot with all other AWS accounts. | An attacker can use the public shared EBS snapshot in its own account and potentially expose sensitive data. |
Neglected Resource | Unassociated Elastic IP Address | The Elastic IP is unused, not associated with any resource in the cloud environment. | An attacker might leverage the neglected Elastic IP to bypass security mechanisms or direct traffic to a malicious server. |
Public Exposure | Public AWS AMI | Publicly shared AWS AMI with all other AWS accounts. | An attacker can attach the public shared AMI to a machine in the attacker's AWS account and inspect the image. |
Amazon Elastic Container Registry
Amazon Elastic Container Registry
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Permissive Access | Private ECR Repository Allows Anonymous Users To Pull Images | Private ECR repository allowing anyone to pull images. | An attacker can pull images from a private repository. |
Permissive Access | Private ECR Repository Allows Anonymous Users To Push Images | Private ECR repository with permissions to push images. | An attacker can push a malicious image to the repository. |
Insecure Configurations | Private ECR Repository Without KMS Key | Private ECR repository without KMS encryption. | KMS provides more control over the repository encryption. |
Insecure Configurations | Public ECR Repository Allows Anonymous Users Access | Public ECR repository enables any user to perform ECR actions. | |
Insecure Configurations | Public ECR Repository Allows Anonymous Users To Push Images | Public ECR repository with permissions to push images. | An attacker can push a malicious image to the repository. |
Amazon ECS
Amazon ECS
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Insecure Configurations | EC2 Instance Operating with Unsecured Metadata Service | This risk points to an EC2 instance that has metadata services enabled without the necessary security tokens. Without these tokens, the metadata services, which can hold sensitive information about the EC2 instance, are exposed to potential unauthorized access. This vulnerability can lead to security breaches and data leaks. It is strongly recommended to secure the metadata services by implementing required security tokens, ensuring proper authorization, and thereby safeguarding the integrity of the instance's metadata. | "When the instance is public and has a connection to the internet, the attacker can take advantage of these default configurations and get full access to the instance and its permissions. This is a default configuration that most of the developers are not aware of. The default configuration can leave your environment at increased risk in the event of a credential exposure/compromise. \nThe metadata information is available by making a request to the IP address of 169.254.169.254. \nThe current AWS Metadata service does not require any HTTP headers to be present and allows any process to make HTTP requests, and it allows an attacker to trick the instance with SSRF (server-side request forgery) vulnerability and making an HTTP/HTTPS requests on his behalf." |
Insecure Configurations | ECS Container Operating in Elevated Privilege Mode | This risk signifies an ECS container that's operating in a privileged mode. When a container is run in privileged mode, it holds potential access to all devices on the host system, thereby posing a significant security risk. This unrestricted access could lead to unauthorized activities or data breaches if the container were to be compromised. It's highly recommended to review the necessity of privileged mode for this container. If not required, a prompt action to modify the container's access privileges is advised to uphold system security and integrity. | An attacker with access to the container can gain unauthorized access to other resources in the enviornment. |
Insecure Configurations | ECS Container with Elevated System Administrator Capabilities | This risk underscores an ECS container configured with CAP_SYS_ADMIN capabilities. This configuration grants the container nearly unrestricted system-level permissions equivalent to the root user on the host, which can significantly amplify the potential impact of a security breach if the container is compromised. It's essential to reassess the necessity of such elevated privileges. If these superuser capabilities are not necessary for the container's operations, it is strongly advised to reduce its permissions promptly, thereby bolstering system security and reducing potential attack vectors. | CAP_SYS_ADMIN is equivalent to root. An attacker with access to the container can gain root privileges." |
Insecure Configurations | Load Balancer Operating with Outdated SSLv3 Protocol | This risk category identifies a Load Balancer that is configured to use the outdated SSLv3 protocol. The SSLv3 protocol has known vulnerabilities and its use poses a significant security risk, including susceptibility to the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack. It is strongly advised to update the Load Balancer's configuration to use a more secure, modern protocol such as TLS 1.2 or TLS 1.3. By doing so, you can reduce the risk of data breaches and ensure secure, encrypted communication. | This version has a flaw that could allow an attacker to decrypt information, such as authentication cookies. This vulnerability is known as POODLE attack - man-in-the-middle exploits which take advantage of Internet and security software clients' fallback to SSL 3.0. |
Insecure Configurations | RDS Database Instance Without Encryption | An attacker with access to the RDS DB can access sensitive data stored in the DB. | This risk indicates an Amazon RDS database instance that lacks encryption, a critical security measure to safeguard sensitive data from unauthorized access. Unencrypted database instances raise the risk of data exposure or misuse, mainly if accessed by unauthorized entities. Implementing encryption to secure your data and comply with best practices and regulations is strongly recommended. |
Amazon EKS
Amazon EKS
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Credentials Exposure | EKS Cluster Operating Without Secrets Encryption | This risk identifies an EKS cluster that is operating without secrets encryption. The absence of encryption could expose your sensitive information and make it vulnerable to unauthorized access or breaches. It's strongly advised to enable secrets encryption for your EKS cluster to enhance the protection of sensitive data. OWASP K08:2022 Secrets Management Failures | By default, Kubernetes secrets are stored in Base64 encoding in the etcd. An attacker with access to the cluster etcd, will be able to use the stored secrets and compromise your cluster. |
Insecure Configurations | EKS Cluster Running With Logging Configurations Disabled | This risk signifies an EKS cluster that is operating with disabled logging configurations. Proper logging provides crucial insights into your system's operations and potential issues. A disabled logging configuration could hinder problem detection and system monitoring. It's highly recommended to enable and configure appropriate logging for your EKS cluster to ensure efficient operations and issue resolution. OWASP K05:2022 Inadequate Logging and Monitoring | Logging provides audit and diagnostic logs directly from EKS to CloudWatch Logs in your account. These logs make it easy for you to secure and run your clusters. |
Public Exposure | Publicly Accessible EKS API Server Endpoint | This risk underscores an EKS API Server Endpoint that is publicly accessible. Public access to your API Server Endpoint could potentially expose your system to unauthorized access and possible security threats. It's advised to review and restrict access to your EKS API Server Endpoint, limiting it to necessary IP ranges or secure VPN connections, to bolster system security. OWASP K09:2022 Misconfigured Cluster Components | An attacker can access the Kubernetes API server from external IP address and use it as an optional entry point into the environment. |
Inadequate Authorization & Authentication | Weak Password on Linux Non-Privileged User | Weak passwords for non-privileged Linux users expose systems to unauthorized access risks. | Compromised accounts could lead to data leaks or be a pivot point for deeper network infiltration. |
Inadequate Authorization & Authentication | Weak Password on Linux Privileged User | Weak passwords on privileged Linux accounts pose a critical threat to system security. | Attackers gaining privileged access can execute commands, alter system configurations, or access sensitive data. |
Inadequate Authorization & Authentication | Weak Password on Windows Standard User | Standard Windows accounts with weak passwords increase the vulnerability to system breaches. | Unauthorized access might result in information theft, malware installation, or user impersonation. |
Inadequate Authorization & Authentication | Weak Password on Windows Administrator | Weak passwords in Windows administrator accounts significantly elevate the risk of system compromise. | Critical system operations can be hijacked, leading to full system control, data exfiltration, or widespread system damage. |
Amazon EFS
Amazon EFS
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Insecure Configurations | Default Security Group | ||
Insecure Configurations | Security Group with Inappropriately Configured CIDR IP | This risk highlights a Security Group with a misconfigured CIDR IP, which may expose your resources to unintended networks, leading to potential unauthorized access. A swift review and correction of CIDR IP configurations in your security groups is strongly recommended to uphold network security. | The Instances that are connected to this security group, can be accidentally exposed to the Internet and compromised. |
Public Exposure | Security Group Allows Access From Any IP (0.0.0.0/0) | A security group with an inbound network rule that allows incoming connection from any IP address (0.0.0.0/0) to any port. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group Permits Connections From Any IP (0.0.0.0/0) | This risk points to an AWS Security Group configured to allow incoming connections from any IP address, denoted by the range 0.0.0.0/0. This unrestricted access can lead to potential unauthorized access and data breaches. It's recommended to validate the need for such open access, and if it is not required, promptly implement stricter access control based on specific IP addresses or ranges. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Exposed RDP Port | This risk identifies a Security Group that has the RDP port (3389) open to the public, posing a significant security risk. Unauthorized access to the RDP port can potentially allow cyber attackers to control your AWS resources. It's crucial to review and restrict access to the RDP port, limiting it to specific, necessary IP ranges or secure VPN connections, to strengthen your system security. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Exposed Telnet Port | This risk underscores a Security Group that has the Telnet port (23) open to the public. An open Telnet port can be a significant security vulnerability as it can allow unauthorized access to your AWS resources. This exposure could potentially lead to unauthorized data access, data breaches, or unwanted modifications. It's highly advised to review and tighten access to the Telnet port, limiting it to necessary IP ranges or more secure protocols. Swift action to restrict this access will greatly enhance your AWS security posture and reduce potential cyber attack vectors. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Open Cassandra Port | This risk signifies a Security Group that has the Cassandra port (9142) open to the public. This can allow unauthorized access to your Cassandra databases, potentially leading to data breaches or malicious alterations. It's highly recommended to review and limit the port access to necessary IP ranges or secure connections, enhancing your database security. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group With Open Kubernetes Kubelet Port (10250) | A security group with an inbound network rule that allows incoming connection from any IP address (0.0.0.0/0) to Kubernetes Kubelet port (10250). | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Open MySQL/MariaDB Port | This risk points to a Security Group that has the MySQL/MariaDB port (3306) open to the public. This can allow unauthorized access to your MySQL/MariaDB databases, potentially leading to data breaches or malicious alterations. It's highly recommended to review and limit the port access to necessary IP ranges or secure connections, greatly enhancing your database security. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Open Redis Port | This risk signifies a Security Group with an open Redis port (6379), providing public access. This could potentially expose your Redis databases to unauthorized access and possible security breaches. A swift action to review and restrict access to the Redis port, limiting it to necessary IP ranges or secure VPN connections, is advised to fortify your database security. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Publicly Accessible Kafka Port | This risk identifies a Security Group with an open Kafka port (9092), providing public access. This configuration could potentially expose your Kafka servers to unauthorized access and potential security threats. It's advised to promptly review and restrict access to the Kafka port, limiting it to necessary IP ranges or secure VPN connections, to improve your overall system security. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Publicly Accessible Kibana Port | This risk signifies a Security Group with an open Kibana port (5601), providing public access. This could potentially expose your Kibana instances to unauthorized access and potential security threats. It's advised to promptly review and restrict access to the Kibana port, limiting it to necessary IP ranges or secure VPN connections, to improve your overall system security. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Publicly Accessible Memcached Port | This risk highlights a Security Group configured with an open Memcached port (11211), allowing public access. This configuration can potentially expose your Memcached servers to unauthorized access and data breaches. It's recommended to promptly review and restrict access to the Memcached port, limiting it to necessary IP ranges or secure connections, thereby fortifying your server security. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Publicly Accessible Redshift Port | This risk points to a security group configuration that leaves the Amazon Redshift port (5439) open to the public. An exposed Redshift port can increase the risk of unauthorized access and potential data breaches. It's recommended to verify the need for such a configuration and, if unnecessary, promptly restrict access to this port to enhance the security of your Redshift clusters. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Publicly Accessible RPC Port | This risk highlights a Security Group configured with an open RPC port (135), making it publicly accessible. This configuration can potentially allow unauthorized access to your AWS resources. Open RPC ports are known to be vectors for certain types of cyber attacks, potentially leading to data breaches or unauthorized modifications. It's strongly recommended to review and limit access to the RPC port, confining it to necessary IP ranges or secure connections. Immediate action to secure this access will substantially enhance your AWS security and reduce potential cyber threats. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Publicly Exposed MSSQL Port | This risk signifies a Security Group configured with an open MSSQL port (1433), granting public access. This unrestricted access can potentially expose your SQL Server databases to unauthorized access and malicious activities. It's advised to immediately review and restrict the MSSQL port access to specific, necessary IP ranges or secure connections, enhancing your database security. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Publicly Exposed Splunkd Port | This risk identifies a Security Group that has the Splunkd port (8089) open to the public. This configuration potentially leaves your Splunkd services vulnerable to unauthorized access and cyber threats. It's strongly recommended to review and limit access to the Splunkd port, confining it to specific, trusted IP ranges or secure VPN connections, to enhance your system security. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Unrestricted FTP Ports | This risk highlights a Security Group that has FTP ports (20/21) open to the public. An open FTP port can allow unauthorized access to your AWS resources, potentially leading to data breaches, misuse, or unwarranted changes. It's strongly recommended to review and tighten access to these FTP ports, limiting them to specific, necessary IP ranges or secure connections. Prompt action to restrict this access will significantly enhance your AWS security and reduce exposure to potential cyber threats. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Unrestricted PostgreSQL Port | This risk highlights a Security Group with an open PostgreSQL port (5432). This configuration can expose your PostgreSQL databases to unauthorized access and potential malicious activities. Promptly reviewing and restricting access to the PostgreSQL port, confining it to necessary IP ranges or secure connections, is strongly recommended to enhance your database security. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Unrestricted SMB Port Access | This risk category identifies a Security Group that has the SMB port (445) openly accessible to the public. An open SMB port can provide an entry point for unauthorized access to your AWS resources, potentially leading to data breaches or malicious modifications. This port is often targeted for exploits like the WannaCry ransomware attack. It's strongly recommended to review and restrict access to the SMB port, confining it to specific, necessary IP ranges or secure VPN connections. Taking immediate action to limit this access will significantly enhance your AWS security posture and reduce potential attack surfaces. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Unrestricted SSH Port Access | This risk identifies a Security Group that has the SSH port (22) open to the public, potentially permitting unauthorized access to your AWS resources. It's crucial to review and restrict access to the SSH port, confining it to specific, necessary IP ranges or secure VPN connections, to bolster your system security. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Unsecured DocDB Port | This risk indicates a Security Group that has the DocDB port (27017) open to the public. This configuration potentially leaves your DocumentDB databases exposed to unauthorized access and potential malicious actions. A swift review and restriction of access to the DocDB port, confining it to specific, trusted IP ranges or secure connections, is strongly recommended to uphold your database security. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Unsecured Elasticsearch Ports | This risk highlights a Security Group with Elasticsearch ports (9200/9300) open to the public. These open ports can potentially expose your Elasticsearch clusters to unauthorized access and possible cyber threats. Immediate review and restriction of access to these ports, limiting them to necessary IP ranges or secure connections, is strongly advised to bolster your cluster security. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Unsecured OracleDB Port | This risk highlights a Security Group that has the OracleDB port (1521) open to the public. This configuration potentially leaves your Oracle databases exposed to unauthorized access and cyber attacks. A swift review and restriction of access to the OracleDB port, confining it to specific, trusted IP ranges or secure connections, is strongly recommended to uphold your database security. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Amazon ElastiCache
Amazon ElastiCache
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Permissive Access | Elasticache User (Not Default) Access String Allows Access to All Keys and Commands | Allowing access to all keys and commands through the Elasticache User Access String provides overly broad and unrestricted access, which can lead to unauthorized data manipulation or misuse. | An attacker gains access to the Elasticache User Access String with permissions for all keys and commands. They could potentially launch a series of malicious operations, such as deleting critical data, injecting harmful commands, or exfiltrating sensitive information, posing a significant security threat to the system's integrity and confidentiality. |
Permissive Access | Elasticache User without Authentication | When a user in Elasticache lacks authentication, a significant security vulnerability arises as there are no authentication mechanisms in place to verify the legitimacy of user requests, potentially exposing the system to unauthorized access and misuse. | An attacker could impersonate a user to gain unrestricted access to the cluster. This could lead to unauthorized data retrieval, manipulation, or even the injection of malicious data into the cache, compromising data integrity. |
Permissive Access | Elasticache Default User is in UserGroups | In Elasticache, a default user is automatically configured with the user ID and name "default," and it is added to all user groups, while remaining immutable and unable to be deleted or modified. This user is granted an access string that allows it to execute all commands and access all keys, creating a potential security vulnerability by providing overly broad and unmodifiable access privileges. | An attacker gains access to the cluster using the default user, taking advantage of the absence of authentication requirements and the user's full access privileges, which allows them to perform unauthorized operations. |
Permissive Access | Non Default Elasticache User Not Associated With Any Group | A user not associated with any group. | |
Permissive Access | Non Default Elasticache User Not Associated With Any Group that Has High Permissions | A user in Elasticache who possesses a full access string or is authenticated independently (without relying on IAM) lacks the security benefits of centralized access control and proper management, thereby increasing the risk of unauthorized access, misconfigurations, and making it challenging to efficiently audit and administer user permissions. | An attacker discovers an unsupervised Elasticache user, initially created without specific permissions. If this user is later added to a group with elevated privileges without proper review, the attacker seizes the moment, gaining unauthorized access to critical resources. |
Insufficient Encryption | Elasticache Encryption by Rest is disabled | Disabling encryption by rest in AWS ElastiCache can potentially lead to security vulnerabilities, as sensitive data may become exposed to potential unauthorized access, data breaches, or compromises due to the absence of encryption safeguards for stored data. | An attacker gains unauthorized access to the Elasticache cluster. Since Encryption at Rest is disabled, they can easily access and exfiltrate sensitive data, such as cached passwords or confidential information, potentially leading to data breaches or unauthorized data exposure. |
Insufficient Encryption | Elasticache Encryption by Transit is disabled | Disabling Encryption in Transit in Elasticache creates a security problem by allowing data transmitted between clients and the cluster to be susceptible to interception, potentially compromising data confidentiality and integrity. | An attacker with access to the network infrastructure or a compromised intermediary device can exploit Elasticache Encryption in Transit being disabled to intercept and eavesdrop on unencrypted data packets transmitted between clients and the cache, potentially compromising data confidentiality and integrity. |
Insufficient Encryption | Elasticache Serverless Uses AWS Managed KMS | AWS Elasticache Serverless encrypted with AWS managed key. | KMS service allows you to easily create, rotate, disable and audit Customer Master Keys created for your Amazon Elasticache. Using a default AWS Key Management Service (KMS) key to encrypt Elasticache Serverless in AWS is not recommended due to limited control over key management, potential security risks from shared keys across accounts, and inadequate support for key rotation. |
Insecure Configurations | Elasticache User with Password Authentication Only | When a user in Elasticache relies solely on authentication by password, the security concern arises if the chosen password is weak or easily guessable, as it can create a vulnerability where malicious actors may successfully guess or crack the password, leading to unauthorized system access and potential compromises to data integrity and confidentiality. | An attacker can employ brute-force or dictionary attacks to repeatedly guess the password. |
Insufficient Encryption | Elasticache Serverless Uses AWS Managed KMS | AWS Elasticache Serverless encrypted with AWS managed key. | KMS service allows you to easily create, rotate, disable and audit Customer Master Keys created for your Amazon Elasticache. Using a default AWS Key Management Service (KMS) key to encrypt Elasticache Serverless in AWS is not recommended due to limited control over key management, potential security risks from shared keys across accounts, and inadequate support for key rotation. |
Amazon ELB
Amazon ELB
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Insecure Configurations | EC2 Instance Operating with Unsecured Metadata Service | This risk points to an EC2 instance that has metadata services enabled without the necessary security tokens. Without these tokens, the metadata services, which can hold sensitive information about the EC2 instance, are exposed to potential unauthorized access. This vulnerability can lead to security breaches and data leaks. It is strongly recommended to secure the metadata services by implementing required security tokens, ensuring proper authorization, and thereby safeguarding the integrity of the instance's metadata. | When the instance is public and has a connection to the internet, the attacker can take advantage of these default configurations and get full access to the instance and its permissions. This is a default configuration that most of the developers are not aware of. The default configuration can leave your environment at increased risk in the event of a credential exposure/compromise. The metadata information is available by making a request to the IP address of 169.254.169.254. The current AWS Metadata service does not require any HTTP headers to be present and allows any process to make HTTP requests, and it allows an attacker to trick the instance with SSRF (server-side request forgery) vulnerability and making an HTTP/HTTPS requests on his behalf. |
Insecure Configurations | Load Balancer Operating with Outdated SSLv3 Protocol | This risk category identifies a Load Balancer that is configured to use the outdated SSLv3 protocol. The SSLv3 protocol has known vulnerabilities and its use poses a significant security risk, including susceptibility to the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack. It is strongly advised to update the Load Balancer's configuration to use a more secure, modern protocol such as TLS 1.2 or TLS 1.3. By doing so, you can reduce the risk of data breaches and ensure secure, encrypted communication. | This version has a flaw that could allow an attacker to decrypt information, such as authentication cookies. This vulnerability is known as POODLE attack - man-in-the-middle exploits which take advantage of Internet and security software clients' fallback to SSL 3.0. |
Insecure Configurations | RDS Database Instance Without Encryption | An attacker with access to the RDS DB can access sensitive data stored in the DB. | This risk indicates an Amazon RDS database instance that lacks encryption, a critical security measure to safeguard sensitive data from unauthorized access. Unencrypted database instances raise the risk of data exposure or misuse, mainly if accessed by unauthorized entities. Implementing encryption to secure your data and comply with best practices and regulations is strongly recommended. |
AWS IAM
AWS IAM
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Identity & Access Management | IAM User Access Key Unrotated for Over 90 Days | This risk identifies an Amazon IAM (Identity and Access Management) user whose access key hasn't been rotated for over 90 days. Keeping access keys unrotated for prolonged periods can increase the risk of unauthorized access if the keys are compromised. It's recommended to adopt a practice of regular key rotation, ideally, every 90 days, to ensure secure access management. | An attacker with access to the access key can achieve the user's privileges and perform unauthorized actions in the account. |
Identity & Access Management | IAM User Holding Unused, Outdated Access Keys | This risk signifies an IAM user that has access keys not used for over 90 days. Outdated, unused keys can pose a significant security risk if they are compromised. It's strongly advised to review and rotate old access keys, promptly deactivating any that are unused to enhance account security. | An attacker with access to the access key can achieve the user's privileges and perform unauthorized actions in the account. |
Identity & Access Management | Inactive IAM User Access Key | This risk indicates an inactive access key associated with an Amazon IAM (Identity and Access Management) user. Despite being inactive, these keys can pose a potential security risk if they were to be reactivated without appropriate controls. It's recommended to routinely review and manage inactive keys, eliminating or rotating those that aren't needed, to maintain a robust access management system. | |
Identity & Access Management | IAM User With Old Password For Over 90 Days | User unchanged his password in the last 90 days. | Attacker can use this user for getting access to compromised environment. |
Identity & Access Management | IAM User Without MFA | This risk identifies an Amazon IAM (Identity and Access Management) user who doesn't have Multi-Factor Authentication (MFA) enabled. MFA provides an extra layer of security by requiring more than just a password for user authentication. Without MFA, the user's account is at a higher risk of unauthorized access. Enabling MFA for all IAM users is strongly recommended to bolster account security. | An attacker can bypass authentication with a password only. |
Identity & Access Management | Inactive IAM User In IAM Credential Report | Inactive user is user with unused access key or user that didn't connect to aws console in the last 90 days. | Attacker can use inactive user credentials that leading to environment compromised |
Identity & Access Management | IAM Role Configured with Predictable External ID | This risk points to an IAM role that has a predictable external ID. Such easily guessed IDs can potentially allow unauthorized entities to assume the role, posing a risk of unauthorized access and potential security breaches. A review and update of all IAM role external IDs, ensuring they are complex and unpredictable, is strongly recommended to maintain secure role access. | "An attacker can trick a third party that can assume a role in your account, and gain unauthorized access to your resources. External ID is a unique identifier that third parties use to assume a role in your account, and its purpose is to prevent the confused deputy problem. When the external id can be easily guessed, the confused deputy remains a problem. We look for external id values that have less than three different types of characters, contain sequences such as 123, abc, qwe, and more, or that are included in the role ARN (account id, role name)." |
Identity & Access Management | IAM Role Configured with Unrestricted Assume Role Permissions | This risk identifies an IAM Role that has been configured to allow 'Assume Role' permissions to any AWS user. This broad configuration increases the potential of unauthorized access to the resources associated with this IAM role. It can lead to misuse of permissions, data breaches, or even alteration of your AWS services. It's highly recommended to review and restrict the 'Assume Role' permissions to specific users or roles, thereby enhancing your AWS security posture by reducing unnecessary exposure. | An attacker with access to any AWS account can assume the role and use its permissions. |
Inadequate Authentication & Authorization | Root user with active access key | Root user with active access key. | Providing access keys to the AWS root user is highly risky, as it allows full, unrestricted access to the entire account, potentially leading to unauthorized actions and severe security breaches. |
Permissive Access | IAM group with administrator policy attached | IAM user group with a managed administrator access policy attached. | A privileged IAM group allows its users administrator access to AWS cloud services and resources. |
Insecure Configurations | IAM Group with full access policy attached | IAM user group with a managed full access policy attached. | A privileged IAM group allows its users full access to AWS cloud services and resources. |
AWS Key Management Service
AWS Key Management Service
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Identity & Access Management | KMS Key Allows Anonymous Access | A key policy that allows certain actions to all users. | If there are no other access mechanisms with deny statements that override this permissive key policy, an attacker will be able to perform the specified actions on your key. |
Neglected Resource | KMS Customer Managed Key Without Rotation | A customer-managed key with disabled key rotation. | Key rotation reduces the risk of a compromised key being used by an attacker to access your encrypted resources. |
Neglected Resource | Unusable Customer Managed Key | A customer-managed KMS key that can't be used. The key is either disabled or pending deletion. | It is not a best practice to have usable keys as it can harm key management processes and increase your monthly AWS bill. |
AWS Lambda
AWS Lambda
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Insecure Configurations | EC2 Instance Operating with Unsecured Metadata Service | This risk points to an EC2 instance that has metadata services enabled without the necessary security tokens. Without these tokens, the metadata services, which can hold sensitive information about the EC2 instance, are exposed to potential unauthorized access. This vulnerability can lead to security breaches and data leaks. It is strongly recommended to secure the metadata services by implementing required security tokens, ensuring proper authorization, and thereby safeguarding the integrity of the instance's metadata. | "When the instance is public and has a connection to the internet, the attacker can take advantage of these default configurations and get full access to the instance and its permissions. This is a default configuration that most of the developers are not aware of. The default configuration can leave your environment at increased risk in the event of a credential exposure/compromise. The metadata information is available by making a request to the IP address of 169.254.169.254. The current AWS Metadata service does not require any HTTP headers to be present and allows any process to make HTTP requests, and it allows an attacker to trick the instance with SSRF (server-side request forgery) vulnerability and making an HTTP/HTTPS requests on his behalf." |
Insecure Configurations | Lambda Function Security Group | ||
Insecure Configurations | Load Balancer Operating with Outdated SSLv3 Protocol | This risk category identifies a Load Balancer that is configured to use the outdated SSLv3 protocol. The SSLv3 protocol has known vulnerabilities and its use poses a significant security risk, including susceptibility to the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack. It is strongly advised to update the Load Balancer's configuration to use a more secure, modern protocol such as TLS 1.2 or TLS 1.3. By doing so, you can reduce the risk of data breaches and ensure secure, encrypted communication. | "This version has a flaw that could allow an attacker to decrypt information, such as authentication cookies. This vulnerability is known as POODLE attack - man-in-the-middle exploits which take advantage of Internet and security software clients' fallback to SSL 3.0." |
Insecure Configurations | RDS Database Instance Without Encryption | An attacker with access to the RDS DB can access sensitive data stored in the DB. | This risk indicates an Amazon RDS database instance that lacks encryption, a critical security measure to safeguard sensitive data from unauthorized access. Unencrypted database instances raise the risk of data exposure or misuse, mainly if accessed by unauthorized entities. Implementing encryption to secure your data and comply with best practices and regulations is strongly recommended. |
Public Exposure | Public Lambda Function Without Authentication | "Lambda Function that is configured with a function URL and without authentication. OWASP A6:2017 <a href=""https://owasp.org/www-pdf-archive/OWASP-Top-10-Serverless-Interpretation-en.pdf""Security> Misconfiguration." | A function URL is a dedicated HTTPS endpoint that allows access and invocation of the function from the public Internet. The configuration of the detected function also supports unauthenticated access, which allows anyone from the Internet to trigger it. |
Unsupported Software | Lambda Function Operating on Deprecated Runtime | "This risk identifies a Lambda function operating on a runtime that is deprecated or has reached end of support. Operating on such a runtime can expose the function to unpatched vulnerabilities and reduce overall performance. An immediate update to a supported runtime is recommended to ensure the security and efficiency of your Lambda function. OWASP A6:2017 <a href=""https://owasp.org/www-pdf-archive/OWASP-Top-10-Serverless-Interpretation-en.pdf""Security> Misconfiguration." | An attacker can exploit known unpatched vulnerabilities in the Lambda function runtime |
Amazon Neptune
Amazon Neptune
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Insecure Configurations | Neptune Cluster has Short Retention Period | Neptune database has less than 7 days backup retention period. | A backup retention period ensures that you have a reliable copy of your data in case of accidental deletion, corruption, or other data loss events. |
Insecure Configurations | Neptune DB Storage Encrypted Enabled | ||
Insecure Configurations | Neptune IAM Database Authentication Disabled | IAM Database Authentication in Amazon Neptune provides an additional layer of security for accessing your Neptune database. Instead of using a traditional username and password for database authentication, IAM Database Authentication allows you to use AWS Identity and Access Management (IAM) credentials to authenticate to your Neptune database. | Attackers might attempt to break traditional authentication methods by brute force or password guessing attacks. |
Insecure Configurations | Neptune without Deletion Protection | Deletion protection is disabled. | Disabling deletion protection in Neptune DB can introduce several security risks. Deletion protection is a feature that prevents accidental or unauthorized data deletions, and disabling it can make your database more vulnerable to various threats. |
Insecure Configurations | Neptune Without Storage Encryption | An attacker with access to the Neptune database can access sensitive data that stored in it. | This risk indicates an Amazon Neptune database that lacks encryption, a critical security measure to safeguard sensitive data from unauthorized access. Unencrypted database instances raise the risk of data exposure or misuse, mainly if accessed by unauthorized entities. Implementing encryption to secure your data and comply with best practices and regulations is strongly recommended. |
AWS OpenSearch
AWS OpenSearch
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Insecure Configurations | Node-to-Node Encryption is Disabled for Amazon OpenSearch Domain | Node-to-node encryption disabled in Amazon OpenSearch Domain. | An attacker who has gained access to the data stored in the domain node can easily read it. |
Insecure Configurations | Amazon OpenSearch Domain Allows Unencrypted HTTP Traffic | Amazon OpenSearch domain is configured to allow unencrypted HTTP traffic. | An attacker can easily intercept and manipulate unencrypted HTTP traffic, potentially stealing sensitive information. |
Public Exposure | Amazon OpenSearch Domain is Publicly Accessible | Amazon OpenSearch Domain is set to public, potentially exposing it to unauthorized access and attacks. | An attacker may target a publicly accessible domain endpoint and use attacks such as Denial of Service or Brute-force, among others. |
Insecure Configurations | Encryption at Rest is Disabled for Amazon OpenSearch Domain | Encryption at rest is disabled for Amazon OpenSearch Domain, increasing the risk of unauthorized access to your data. If enabled, the feature encrypts the following aspects of a domain: All indexes (including those in UltraWarm storage); OpenSearch logs; Swap files; All other data in the application directory; Automated snapshots | An attacker who has gained access to the data stored in the domain can easily read it. |
Insecure Configurations | Automatic Software Updates Feature are Disabled for Amazon OpenSearch Domain | Amazon OpenSearch Domain's automatic software updates are turned off. | An attacker can abuse outdated software to exploit known vulnerailities. |
Amazon RDS
Amazon RDS
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Insecure Configurations | EC2 Instance Operating with Unsecured Metadata Service | This risk points to an EC2 instance that has metadata services enabled without the necessary security tokens. Without these tokens, the metadata services, which can hold sensitive information about the EC2 instance, are exposed to potential unauthorized access. This vulnerability can lead to security breaches and data leaks. It is strongly recommended to secure the metadata services by implementing required security tokens, ensuring proper authorization, and thereby safeguarding the integrity of the instance's metadata. | "When the instance is public and has a connection to the internet, the attacker can take advantage of these default configurations and get full access to the instance and its permissions. This is a default configuration that most of the developers are not aware of. The default configuration can leave your environment at increased risk in the event of a credential exposure/compromise. The metadata information is available by making a request to the IP address of 169.254.169.254. The current AWS Metadata service does not require any HTTP headers to be present and allows any process to make HTTP requests, and it allows an attacker to trick the instance with SSRF (server-side request forgery) vulnerability and making an HTTP/HTTPS requests on his behalf." |
Insecure Configurations | Load Balancer Operating with Outdated SSLv3 Protocol | This risk category identifies a Load Balancer that is configured to use the outdated SSLv3 protocol. The SSLv3 protocol has known vulnerabilities and its use poses a significant security risk, including susceptibility to the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack. It is strongly advised to update the Load Balancer's configuration to use a more secure, modern protocol such as TLS 1.2 or TLS 1.3. By doing so, you can reduce the risk of data breaches and ensure secure, encrypted communication. | "This version has a flaw that could allow an attacker to decrypt information, such as authentication cookies. This vulnerability is known as POODLE attack - man-in-the-middle exploits which take advantage of Internet and security software clients' fallback to SSL 3.0." |
Insecure Configurations | RDS Database Instance Without Encryption | An attacker with access to the RDS DB can access sensitive data stored in the DB. | This risk indicates an Amazon RDS database instance that lacks encryption, a critical security measure to safeguard sensitive data from unauthorized access. Unencrypted database instances raise the risk of data exposure or misuse, mainly if accessed by unauthorized entities. Implementing encryption to secure your data and comply with best practices and regulations is strongly recommended. |
Data Security | RDS Cluster Without Configured Backup Retention | This risk signifies an Amazon RDS cluster not configured for backup retention. A lack of backup retention can lead to data loss in case of system failures or errors. It's highly recommended to configure a suitable backup retention policy to protect data and ensure the possibility of recovery in the event of unexpected issues. | The backup retention period determines the period for which you can perform a point-in-time recovery. |
Data Security | RDS Database Instance Publicly Accessible | This risk identifies an Amazon RDS database instance configured to allow public access, making it potentially reachable by any AWS user or internet user. Publicly accessible database instances pose a heightened risk of unauthorized data access and potential data breaches. It's recommended to validate whether such public access is necessary and, if not, promptly restrict the access to enhance the security of your data. | An attacker can access the DB leading to data exposure. |
Insecure Configurations | EC2 Instance Operating with Unsecured Metadata Service | This risk points to an EC2 instance that has metadata services enabled without the necessary security tokens. Without these tokens, the metadata services, which can hold sensitive information about the EC2 instance, are exposed to potential unauthorized access. This vulnerability can lead to security breaches and data leaks. It is strongly recommended to secure the metadata services by implementing required security tokens, ensuring proper authorization, and thereby safeguarding the integrity of the instance's metadata. | "When the instance is public and has a connection to the internet, the attacker can take advantage of these default configurations and get full access to the instance and its permissions. This is a default configuration that most of the developers are not aware of. The default configuration can leave your environment at increased risk in the event of a credential exposure/compromise. The metadata information is available by making a request to the IP address of 169.254.169.254. The current AWS Metadata service does not require any HTTP headers to be present and allows any process to make HTTP requests, and it allows an attacker to trick the instance with SSRF (server-side request forgery) vulnerability and making an HTTP/HTTPS requests on his behalf." |
Insecure Configurations | Load Balancer Operating with Outdated SSLv3 Protocol | This risk category identifies a Load Balancer that is configured to use the outdated SSLv3 protocol. The SSLv3 protocol has known vulnerabilities and its use poses a significant security risk, including susceptibility to the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack. It is strongly advised to update the Load Balancer's configuration to use a more secure, modern protocol such as TLS 1.2 or TLS 1.3. By doing so, you can reduce the risk of data breaches and ensure secure, encrypted communication. | "This version has a flaw that could allow an attacker to decrypt information, such as authentication cookies. This vulnerability is known as POODLE attack - man-in-the-middle exploits which take advantage of Internet and security software clients' fallback to SSL 3.0." |
Insecure Configurations | RDS Database Instance Without Encryption | An attacker with access to the RDS DB can access sensitive data stored in the DB. | This risk indicates an Amazon RDS database instance that lacks encryption, a critical security measure to safeguard sensitive data from unauthorized access. Unencrypted database instances raise the risk of data exposure or misuse, mainly if accessed by unauthorized entities. Implementing encryption to secure your data and comply with best practices and regulations is strongly recommended. |
Data Security | RDS Cluster Database Snapshot Publicly Shared | This risk signifies a publicly shared Amazon RDS cluster database snapshot, making it accessible to any AWS user. Publicly sharing snapshots elevates the risk of unauthorized access, data misuse, or breaches. The necessity of this public sharing should be verified; if not required, immediate action to restrict the sharing is advised to minimize potential security risks. | DB cluster snapshot is public and available for any Amazon Web Services account to copy or restore. |
Data Security | RDS Cluster Database Snapshot Without Encryption | This risk highlights an Amazon RDS cluster database snapshot that is without encryption. Encryption serves as a vital security layer, safeguarding sensitive data from unauthorized access and potential breaches. An unencrypted snapshot increases the likelihood of data misuse if it's unintentionally accessed or shared. Prompt action to apply encryption is recommended to ensure the security of the snapshot's data. | An attacker can access the data stored in the RDS cluster database snapshot without decrypting it. |
Data Security | RDS Database Cluster Snapshot Externally Shared | This risk signifies an Amazon RDS database cluster snapshot shared with an external AWS account, potentially risking exposure of sensitive data. Uncontrolled or untrusted accounts might misuse or further expose this data, leading to potential breaches and compliance issues. Immediate investigation and appropriate action, such as revoking sharing if it violates security policies, are recommended to mitigate potential risks. | An attacker with access to the external account can copy the database cluster snapshot and create a RDS database cluster. |
Data Security | RDS Database Snapshot Externally Shared | This risk signifies an Amazon RDS database snapshot shared with an external AWS account, potentially risking exposure of sensitive data. Uncontrolled or untrusted accounts might misuse or further expose this data, leading to potential breaches and compliance issues. Immediate investigation and appropriate action, such as revoking sharing if it violates security policies, are recommended to mitigate potential risks. | An attacker with access to the external account can copy the database snapshot and create a RDS database. |
Data Security | RDS Database Snapshot Publicly Shared | This risk signifies a publicly shared Amazon RDS database snapshot, making it accessible to any AWS user. Publicly sharing snapshots elevates the risk of unauthorized access, data misuse, or breaches. The necessity of this public sharing should be verified; if not required, immediate action to restrict the sharing is advised to minimize potential security risks. | DB snapshot is public and available for any Amazon Web Services account to copy or restore it. |
Data Security | RDS Database Snapshot Without Encryption | This risk highlights an Amazon RDS database snapshot that is without encryption. Encryption serves as a vital security layer, safeguarding sensitive data from unauthorized access and potential breaches. An unencrypted snapshot increases the likelihood of data misuse if it's unintentionally accessed or shared. Prompt action to apply encryption is recommended to ensure the security of the snapshot's data. | An attacker can access the data stored in an RDS snapshot without decrypting it. |
Inadequate Logging & Backup | RDS instance without configured backup retention | This risk signifies an Amazon RDS instance not configured for backup retention. A lack of backup retention can lead to data loss in case of system failures or errors. It's highly recommended to configure a suitable backup retention policy to protect data and ensure the possibility of recovery in the event of unexpected issues. | The backup retention period determines the period for which you can perform a point-in-time recovery. |
Amazon Redshift
Amazon Redshift
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Data Security | Redshift Cluster Publicly Accessible | This risk points to an Amazon Redshift cluster configured to be publicly accessible, potentially making it reachable by any internet user. Publicly accessible Redshift clusters can significantly raise the risk of unauthorized data access and potential data breaches. It's recommended to validate the need for such public access and, if unnecessary, promptly restrict access to strengthen your data security. | An attacker can access Redshift cluster through the cluster endpoint. |
Data Security | Redshift Cluster Without Encryption | This risk identifies an Amazon Redshift cluster that has not been configured for encryption, a crucial security measure to protect sensitive data from unauthorized access. Unencrypted Redshift clusters present an increased risk of data exposure or misuse. Implementing encryption to secure your data and adhere to best practices and compliance regulations is strongly recommended. | An attacker can access the data stored in your Redshift cluster. |
Insecure Configurations | Redshift is Using Default Port | Using the default port (5439) in AWS Redshift indicates a potential security vulnerability due to the default configuration, which could expose the database clusters to increased risk of unauthorized access and attacks targeting known default ports. | An attacker scans for open ports and identifies an AWS Redshift cluster using the default port 5439, exploits this known configuration by attempting brute-force or dictionary attacks to gain unauthorized access to the database, potentially leading to data theft or manipulation. |
Public Exposure | AWS RedShift Enhanced VPC Routing is Disabled | AWS Redshift enhanced VPC routing is disabled. | When using AWS Redshift enhanced VPC routing, Amazon Redshift forces all COPY and UNLOAD traffic between your cluster and your data repositories through your virtual private cloud (VPC) based on the Amazon VPC service. If enhanced VPC routing is not turned on, Amazon Redshift routes traffic through the internet, including traffic to other services within the AWS network. |
Inadequate Logging & Backup | Redshift User Activity Logging is Disabled | AWS Redshift logs information about connections and user activities in your database are disabled. | An attacker exploits the lack of AWS Redshift user activity logging, enabling them to perform unauthorized actions within the database without leaving a trace, potentially leading to data breaches or unauthorized modifications. |
Inadequate Logging & Backup | Redshift has Short Retention Period | AWS Redshift Cluster has less than 7 days backup retention period. | A backup retention period ensures that you have a reliable copy of your data in case of accidental deletion, corruption, or other data loss events. |
Insufficient Encryption | Redshift SSL is Disabled | Redshift cluster is not configured to require SSL. | If SSL is disabled, an attacker could intercept the unencrypted database traffic, potentially capturing sensitive data such as passwords and queries. |
Insecure Configurations | RedShift uses default Master Username | Redshift uses default master username. | An attacker can exploit widely known default credentials to gain unauthorized entry into the system. |
Insufficient Encryption | Redshift Cluster Uses Default KMS |
Amazon Route 53
Amazon Route 53
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Insecure Configurations | Public Route53 Hosted Zone Holding Private DNS Record | This risk points to a Route53 hosted zone that is public yet contains private DNS records. This configuration can lead to unintended exposure of internal resource information, heightening the risk of unauthorized access and potential breaches. A prompt review of the hosted zone's configuration to ensure appropriate privacy for DNS records is strongly recommended. | All DNS in a public hosted zone can be queried from any external internet IP address. An attacker can resolve these records and gain information about your environment. |
Insecure Configurations | Route53 Without Auto Renew Domain | A Route 53 domain with the auto renew feature not enabled. | With the auto renew feature enabled, your domains won't get expired. Expired domains leave your application exposed to multiple attacks, so it is best practice to enable the feature. |
Insecure Configurations | Route53 Without Domain Transfer Lock | A Route 53 domain with Transfer Lock set to false. | An attacker may be able to transfer your domain to another domain name registrar, and hijack your domain. |
Neglected Resource | Route53 Domain Expires In 30 Days | A Route 53 domain is going to be expired in 30 days. | Expired domains leave your application exposed to multiple attacks. Extend the expiration date as soon as possible. |
Neglected Resource | Route53 Domain Expires In 7 Days | A Route 53 domain is going to expire in 7 days. | Expired domains leave your application exposed to multiple attacks. Extend the expiration date as soon as possible. |
Neglected Resource | Route53 With Expired Domain | An expired domain name is registered in Route 53. | An attacker can hijack the expired domain and use it for malicious purposes. In addition, an expired domain can cause failures or downtime in your application. |
Amazon S3
Amazon S3
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Permissive Access | Cross-Account S3 Bucket Access | This risk indicates that an Amazon S3 bucket is configured to permit access from users in different AWS accounts. If not strictly controlled, cross-account access can elevate the risk of unauthorized data access or leakage. It's advisable to scrutinize the necessity of this access configuration and promptly modify the bucket's access policies to enhance your data security if not required. | An attacker from any AWS account can define this S3 bucket as their target bucket for the service logs or configuration. |
Data Security | S3 Bucket Contains Potentially Public Objects | This risk identifies an Amazon S3 bucket that contains objects that may be publicly accessible, thereby potentially enabling any internet user to access them. Potentially shared objects in an S3 bucket can heighten the risk of unauthorized data access and potential data breaches. It's recommended to review these objects and their access controls, and if public access is not necessary, promptly update their permissions to secure your data. | An attacker can maybe access some objects in the bucket leading to data exposure. |
Data Security | S3 Bucket Encrypted with AWS S3 Managed Key | S3 bucket encrypted with AWS S3 managed key. | Using AWS S3 managed key to encrypt an S3 bucket in AWS is not recommended due to limited control over key management. Managing your own KMS keys allows for better security practices, ensures isolation of resources, and facilitates compliance with industry standards. Creating and using customer-managed keys provides a more robust and customizable approach to data encryption in AWS S3. |
Data Security | S3 Bucket Publicly Accessible | This risk points to an Amazon S3 bucket configured as publicly accessible, potentially making it reachable by any internet user. Publicly accessible S3 buckets significantly reduce the risk of unauthorized data access and potential breaches. It's recommended to validate the need for such public access, and if it's not necessary, promptly restrict access to improve your data security. | An attacker can access the bucket and objects leading to data exposure. |
Insecure Configurations | EC2 Instance Operating with Unsecured Metadata Service | This risk points to an EC2 instance that has metadata services enabled without the necessary security tokens. Without these tokens, the metadata services, which can hold sensitive information about the EC2 instance, are exposed to potential unauthorized access. This vulnerability can lead to security breaches and data leaks. It is strongly recommended to secure the metadata services by implementing required security tokens, ensuring proper authorization, and thereby safeguarding the integrity of the instance's metadata. | When the instance is public and has a connection to the internet, the attacker can take advantage of these default configurations and get full access to the instance and its permissions. This is a default configuration that most of the developers are not aware of. The default configuration can leave your environment at increased risk in the event of a credential exposure/compromise. The metadata information is available by making a request to the IP address of 169.254.169.254. The current AWS Metadata service does not require any HTTP headers to be present and allows any process to make HTTP requests, and it allows an attacker to trick the instance with SSRF (server-side request forgery) vulnerability and making an HTTP/HTTPS requests on his behalf. |
Insecure Configurations | Load Balancer Operating with Outdated SSLv3 Protocol | This risk category identifies a Load Balancer that is configured to use the outdated SSLv3 protocol. The SSLv3 protocol has known vulnerabilities and its use poses a significant security risk, including susceptibility to the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack. It is strongly advised to update the Load Balancer's configuration to use a more secure, modern protocol such as TLS 1.2 or TLS 1.3. By doing so, you can reduce the risk of data breaches and ensure secure, encrypted communication. | This version has a flaw that could allow an attacker to decrypt information, such as authentication cookies. This vulnerability is known as POODLE attack - man-in-the-middle exploits which take advantage of Internet and security software clients' fallback to SSL 3.0. |
Insecure Configurations | RDS Database Instance Without Encryption | An attacker with access to the RDS DB can access sensitive data stored in the DB. | This risk indicates an Amazon RDS database instance that lacks encryption, a critical security measure to safeguard sensitive data from unauthorized access. Unencrypted database instances raise the risk of data exposure or misuse, mainly if accessed by unauthorized entities. Implementing encryption to secure your data and comply with best practices and regulations is strongly recommended. |
AWS Sagemaker
AWS Sagemaker
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Insufficient Encryption | Sagemaker Endpoint Configuration without Encryption Key | Sagemaker Endpoint Configuration without Encryption Key. Encrypting your AWS SageMaker endpoint configuration with a KMS key is a crucial step in securing your machine learning application. It protects sensitive data at rest, ensuring that unauthorized users cannot access your model's configurations or the data it processes. | An attacker can access your model's configurations or the data it processes. |
Public Exposure | Publicly Accessible AWS Sagemaker Domain | AWS Sagemaker domain with public access enabled. | An attacker can access the resource. Allowing unrestricted, public access to cloud services could open an application up to external attack. |
Insufficient Encryption | AWS Sagemaker Domain without Customer KMS Key | AWS Sagemaker domain is not encrypted using a KMS key. | An attacker can access your EFS volume attached to the domain. |
Public Exposure | Sagemaker Notebook Instance with Direct Internet Access | Sagemaker notebook instance with direct internet access, when your notebook allows direct internet access, SageMaker provides a network interface that allows the notebook to communicate with the internet through a VPC managed by SageMaker. | An attacker can access your notebook instance. |
Permissive Access | Sagemaker Notebook Instance with Root Access | Sagemaker notebook instance with root access. | An attacker who gains access to the notebook instance can find a way to get root access to that instance, and then it will have full control over that instance. Using that full control, he might be able to steal important data or even continue his attack using lateral movement techniques. |
Insufficient Encryption | SageMaker Notebook Instance not encrypted using a KMS Key | SageMaker notebook instance without KMS key. Encrypting your AWS SageMaker notebook with a KMS key is a vital security practice that safeguards your sensitive data, code, and intellectual property. It enforces robust access controls, ensuring that only authorized personnel can decrypt and interact with your content. | An attacker can access your sensitive data. |
AWS Secrets Manager
AWS Secrets Manager
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Insecure Configurations | Secret Manager Secret Not Rotated Over 30 Days | Secret not rotated for over 30 days. | An attacker with access to the secret can get its content and elevate his privileges. |
Amazon VPC
Amazon VPC
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Insecure Configurations | Default Security Group | ||
Insecure Configurations | Security Group with Inappropriately Configured CIDR IP | This risk highlights a Security Group with a misconfigured CIDR IP, which may expose your resources to unintended networks, leading to potential unauthorized access. A swift review and correction of CIDR IP configurations in your security groups is strongly recommended to uphold network security. | The Instances that are connected to this security group, can be accidentally exposed to the Internet and compromised. |
Public Exposure | Security Group Allows Access From Any IP (0.0.0.0/0) | A security group with an inbound network rule that allows incoming connection from any IP address (0.0.0.0/0) to any port. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group Permits Connections From Any IP (0.0.0.0/0) | This risk points to an AWS Security Group configured to allow incoming connections from any IP address, denoted by the range 0.0.0.0/0. This unrestricted access can lead to potential unauthorized access and data breaches. It's recommended to validate the need for such open access, and if it is not required, promptly implement stricter access control based on specific IP addresses or ranges. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Exposed RDP Port | This risk identifies a Security Group that has the RDP port (3389) open to the public, posing a significant security risk. Unauthorized access to the RDP port can potentially allow cyber attackers to control your AWS resources. It's crucial to review and restrict access to the RDP port, limiting it to specific, necessary IP ranges or secure VPN connections, to strengthen your system security. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Exposed Telnet Port | This risk underscores a Security Group that has the Telnet port (23) open to the public. An open Telnet port can be a significant security vulnerability as it can allow unauthorized access to your AWS resources. This exposure could potentially lead to unauthorized data access, data breaches, or unwanted modifications. It's highly advised to review and tighten access to the Telnet port, limiting it to necessary IP ranges or more secure protocols. Swift action to restrict this access will greatly enhance your AWS security posture and reduce potential cyber attack vectors. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Open Cassandra Port | This risk signifies a Security Group that has the Cassandra port (9142) open to the public. This can allow unauthorized access to your Cassandra databases, potentially leading to data breaches or malicious alterations. It's highly recommended to review and limit the port access to necessary IP ranges or secure connections, enhancing your database security. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group With Open Kubernetes Kubelet Port (10250) | A security group with an inbound network rule that allows incoming connection from any IP address (0.0.0.0/0) to Kubernetes Kubelet port (10250). | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Open MySQL/MariaDB Port | This risk points to a Security Group that has the MySQL/MariaDB port (3306) open to the public. This can allow unauthorized access to your MySQL/MariaDB databases, potentially leading to data breaches or malicious alterations. It's highly recommended to review and limit the port access to necessary IP ranges or secure connections, greatly enhancing your database security. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Open Redis Port | This risk signifies a Security Group with an open Redis port (6379), providing public access. This could potentially expose your Redis databases to unauthorized access and possible security breaches. A swift action to review and restrict access to the Redis port, limiting it to necessary IP ranges or secure VPN connections, is advised to fortify your database security. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Publicly Accessible Kafka Port | This risk identifies a Security Group with an open Kafka port (9092), providing public access. This configuration could potentially expose your Kafka servers to unauthorized access and potential security threats. It's advised to promptly review and restrict access to the Kafka port, limiting it to necessary IP ranges or secure VPN connections, to improve your overall system security. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Publicly Accessible Kibana Port | This risk signifies a Security Group with an open Kibana port (5601), providing public access. This could potentially expose your Kibana instances to unauthorized access and potential security threats. It's advised to promptly review and restrict access to the Kibana port, limiting it to necessary IP ranges or secure VPN connections, to improve your overall system security. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Publicly Accessible Memcached Port | This risk highlights a Security Group configured with an open Memcached port (11211), allowing public access. This configuration can potentially expose your Memcached servers to unauthorized access and data breaches. It's recommended to promptly review and restrict access to the Memcached port, limiting it to necessary IP ranges or secure connections, thereby fortifying your server security. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Publicly Accessible Redshift Port | This risk points to a security group configuration that leaves the Amazon Redshift port (5439) open to the public. An exposed Redshift port can increase the risk of unauthorized access and potential data breaches. It's recommended to verify the need for such a configuration and, if unnecessary, promptly restrict access to this port to enhance the security of your Redshift clusters. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Publicly Accessible RPC Port | This risk highlights a Security Group configured with an open RPC port (135), making it publicly accessible. This configuration can potentially allow unauthorized access to your AWS resources. Open RPC ports are known to be vectors for certain types of cyber attacks, potentially leading to data breaches or unauthorized modifications. It's strongly recommended to review and limit access to the RPC port, confining it to necessary IP ranges or secure connections. Immediate action to secure this access will substantially enhance your AWS security and reduce potential cyber threats. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Publicly Exposed MSSQL Port | This risk signifies a Security Group configured with an open MSSQL port (1433), granting public access. This unrestricted access can potentially expose your SQL Server databases to unauthorized access and malicious activities. It's advised to immediately review and restrict the MSSQL port access to specific, necessary IP ranges or secure connections, enhancing your database security. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Publicly Exposed Splunkd Port | This risk identifies a Security Group that has the Splunkd port (8089) open to the public. This configuration potentially leaves your Splunkd services vulnerable to unauthorized access and cyber threats. It's strongly recommended to review and limit access to the Splunkd port, confining it to specific, trusted IP ranges or secure VPN connections, to enhance your system security. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Unrestricted FTP Ports | This risk highlights a Security Group that has FTP ports (20/21) open to the public. An open FTP port can allow unauthorized access to your AWS resources, potentially leading to data breaches, misuse, or unwarranted changes. It's strongly recommended to review and tighten access to these FTP ports, limiting them to specific, necessary IP ranges or secure connections. Prompt action to restrict this access will significantly enhance your AWS security and reduce exposure to potential cyber threats. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Unrestricted PostgreSQL Port | This risk highlights a Security Group with an open PostgreSQL port (5432). This configuration can expose your PostgreSQL databases to unauthorized access and potential malicious activities. Promptly reviewing and restricting access to the PostgreSQL port, confining it to necessary IP ranges or secure connections, is strongly recommended to enhance your database security. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Unrestricted SMB Port Access | This risk category identifies a Security Group that has the SMB port (445) openly accessible to the public. An open SMB port can provide an entry point for unauthorized access to your AWS resources, potentially leading to data breaches or malicious modifications. This port is often targeted for exploits like the WannaCry ransomware attack. It's strongly recommended to review and restrict access to the SMB port, confining it to specific, necessary IP ranges or secure VPN connections. Taking immediate action to limit this access will significantly enhance your AWS security posture and reduce potential attack surfaces. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Unrestricted SSH Port Access | This risk identifies a Security Group that has the SSH port (22) open to the public, potentially permitting unauthorized access to your AWS resources. It's crucial to review and restrict access to the SSH port, confining it to specific, necessary IP ranges or secure VPN connections, to bolster your system security. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Unsecured DocDB Port | This risk indicates a Security Group that has the DocDB port (27017) open to the public. This configuration potentially leaves your DocumentDB databases exposed to unauthorized access and potential malicious actions. A swift review and restriction of access to the DocDB port, confining it to specific, trusted IP ranges or secure connections, is strongly recommended to uphold your database security. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Unsecured Elasticsearch Ports | This risk highlights a Security Group with Elasticsearch ports (9200/9300) open to the public. These open ports can potentially expose your Elasticsearch clusters to unauthorized access and possible cyber threats. Immediate review and restriction of access to these ports, limiting them to necessary IP ranges or secure connections, is strongly advised to bolster your cluster security. | An attacker might use this misconfiguration to access assets within the AWS environment. |
Public Exposure | Security Group with Unsecured OracleDB Port | This risk highlights a Security Group that has the OracleDB port (1521) open to the public. This configuration potentially leaves your Oracle databases exposed to unauthorized access and cyber attacks. A swift review and restriction of access to the OracleDB port, confining it to specific, trusted IP ranges or secure connections, is strongly recommended to uphold your database security. | An attacker might use this misconfiguration to access assets within the AWS environment. |
SNS (Simple Notification Service)
SNS (Simple Notification Service)
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Data Security | SNS Topic Encryption is Not Enabled | The absence of encryption for SNS topics exposes transmitted messages to risks of unauthorized access, interception, and tampering, compromising the confidentiality, integrity, and privacy of sensitive information within the messages. | In an environment where an SNS topic lacks encryption, an attacker can gain unauthorized access. Through this access, an attacker can intercept messages transmitted through the unencrypted SNS topic, enabling them to extract sensitive information. |
Data Security | SNS Topic is Encrypted With a Default Key | Using the default key for encrypting SNS topics presents limitations in effective key management. Default key does not allow the ability to create, rotate, disable or enable the encryption key used to protect the data. | The default key used for encryption in AWS lacks the necessary mechanisms to provide secure end-to-end encryption and prevent a Man-in-the-Middle attack on SNS topics. This makes it vulnerable to interception and manipulation by an attacker. |
Insecure Configurations | SNS Topic Data-in-Transit is Not Enforced | An SNS topic without HTTPS enforcment. | Without HTTPS, a network-based attacker can eavesdrop on network traffic or manipulate it using an attack such as man-in-the-middle. |
Permissive Access | SNS Topic Policy Allows 'SNS:Publish' for All Principals Without Conditions | The security finding of an SNS topic policy allowing unrestricted 'SNS:Publish' access increses the risk of unauthorized message dissemination, abuse, compromised data integrity, and non-compliance with security regulations. | An attacker identifies the SNS topic with the open publishing access and leverages this vulnerability to send unauthorized messages to the topic. With the ability to publish messages without restrictions, the attacker can disseminate malicious content, such as phishing links, malware payloads, or false information to the subscribers of the topic. |
Permissive Access | SNS Topics Administrative Actions Are Publicly Executable | Preventing public execution of administrative actions on SNS topics is essential to maintain messaging system security, safeguard sensitive data, prevent service disruptions, and ensure compliance by restricting unauthorized users from performing administrative operations. | An attacker identifies a publicly accessible SNS topic and discovers that administrative actions can be executed without authentication. With this control, the attacker can modify topic settings, change access permissions, or delete the topic altogether. |
Insecure Configurations | SNS Topics Are Publicly Accessible | Ensuring that SNS is not publicly accessible is important to protect against unauthorized access, data breaches, and other security threats. | An attack targeting the Simple Notification Service (SNS) public access could involve unauthorized actors exploiting the open access configuration of an SNS topic. By identifying a publicly accessible SNS topic, the attackers can abuse it to send messages or notifications to a large number of recipients, potentially causing disruptions, spamming users, or spreading malicious content. |
SQS (Simple Queue Service)
SQS (Simple Queue Service)
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Data Security | SQS Queue is Not Encrypted With a Customer-Managed Key | SQS (Simple Queue Service) not being encrypted with a customer-managed key increases the risk of unauthorized access and potential exposure of sensitive data. | When SQS is not encrypted with a customer-managed key, the messages stored in SQS are still encrypted using AWS-managed keys. Without customer-managed key encryption. KMS key allows a more granular control over the SQS data encryption/decryption process. |
Data Security | SQS Server-Side Encryption is Not Enabled | Disabling AWS SQS Server-Side Encryption (SSE) exposes data to vulnerabilities, non-compliance with data protection regulations, compromises data integrity, and undermines trust in the service. | When Server-Side Encryption (SSE) is not enforced in SQS, an attacker with unauthorized access can intercept and read unencrypted messages stored in the queue, leading to data exposure. |
Insecure Configurations | SQS Data-in-Transit Encryption is Not Enforced | Not enforcing data-in-transit encryption in SQS (Simple Queue Service) increases the risk of data interception and unauthorized access during the transmission of messages. | The transmitted messages are vulnerable to interception by malicious actors. Attackers can eavesdrop on network traffic or manipulate it, using an attack such as man-in-the-middle. |
Permissive Access | SQS Policy Allows All Actions From All Principals Without a Condition | Allowing all actions from all principals without conditions in AWS SQS eliminates access control, increases the risk of unauthorized operations, data breaches, compliance violations, and operational disruptions. | In a scenario where there is a lack of access control in AWS SQS, allowing all actions from all principals without conditions, any AWS identity or entity has unrestricted access to perform any action on the SQS queues. This absence of granular access controls and restrictions allows an attacker to exploit this lack of control by gaining unauthorized access to sensitive data within the queues. |
Insecure Configurations | SQS Policy Allows Public Access | SQS (Simple Queue Service) policy that allows public access increases the risk of unauthorized users gaining access to the queue and potentially manipulating or retrieving sensitive messages. | When an SQS (Simple Queue Service) policy is misconfigured to allow public access, unauthorized individuals can exploit this vulnerability. Attackers can manipulate and retrieve sensitive messages from the queue without any authentication or authorization checks. |
Microsoft Azure - click to collapse
Microsoft Azure
Click on a service name below to view a table of the risks Panoptica detects in Azure, along with brief descriptions and attack scenarios.
Azure AI Search Service
Azure AI Search Service
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Public Exposure | Azure AI Search with Public Network Access | Azure AI Search is publicly accessible. | An attacker might focus on azure ai search app that is publicly accessible, aiming to exploit vulnerabilities such as Denial of Service, Brute-force attacks, and others. |
Azure App Service
Azure App Service
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Insecure Configurations | Azure Function Cross-origin Resource Sharing (CORS) Feature not Implemented | Cross-Origin Resource Sharing (CORS) is a security feature that allows or restricts web applications running at one origin (domain) to make requests for resources from a different origin, subject to certain constraints, to prevent unauthorized access to data. This finding signifies an Azure Function without Cross-Origin Resource Sharing enforcement. | An attacker could exploit permissive CORS policies set on a web application to make unauthorized cross-origin requests, potentially gaining access to sensitive data or performing actions on behalf of a legitimate user without their consent. For example, an attacker might trick a victim into visiting a malicious website that sends requests to a trusted web service using the victim's credentials, allowing the attacker to steal data or perform actions on the victim's behalf. |
Insecure Configurations | Azure Function Enables Unencrypted Traffic | An Azure Function without HTTPS enforcment. | Without HTTPS, a network-based attacker can eavesdrop on network traffic or manipulate it using an attack such as man-in-the-middle. |
Insecure Configurations | Azure Function Support Insecure Transportation Security Protocol | An Azure Function that uses insecure TLS (Transport Layer Security) protocols. | It is recommended to use the latest version of TLS if possible. Older versions (prior to TLS 1.2) may be deprecated or may contain known vulnerabilities that an attacker can use. |
Insecure Configurations | FTP Service Enabled for Azure Function | An Azure Function S/FTP endpoint enabled. | The Azure FTP deployment endpoints are publicly accessible. An attacker might attempt to brute-force the service to gain access to the app/service code base. |
Insecure Configurations | Remote Debugging is Enabled for Azure Function | An Azure Function that enables remote debugging. | If remote debugging in Azure Functions is enabled without proper security controls, an attacker could potentially gain unauthorized access to the running code, extract sensitive information, inject malicious code, or disrupt the application, posing a significant security risk. |
Unsupported Software | Azure Function Deprecated Runtime | Azure function with a deprecated runtime. | An attacker can exploit known unpatched vulnerabilities in the azure function runtime. |
Azure Application Gateway
Azure Application Gateway
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Insecure Configurations | Application Gateway Should have Http to Https redirection | Application Gateway has an HTTP listener without a redirection to HTTPS defined. It is important to make sure all communication is encrypted by enabling HTTP-to-HTTPS redirection for all HTTP listeners. | |
Insecure Configurations | Application Gateway Allows Old TLS versions | Application Gateway is allowing the usage of old TLS versions, such as Version 1.0 and Version 1.1 | An attacker can communicate with the application gateway using old and vulnerable versions of TLS such as TLS 1 and TLS1.1 which are vulnerable to downgrade attacks becuase they rely on SHA-1 hash for the integrity of exchanged messages. |
Azure Cache for Redis
Azure Cache for Redis
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Public Exposure | Azure Cache for Redis is Publicly Accessible | Azure Cache for Redis is publicly accessible to all IP's. | An attacker can expose the database to anyone on the Internet, significantly increasing the risk of malicious access, data breaches, or potential service disruptions. |
Azure Container App
Azure Container App
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Insecure Configurations | Azure Container App Allow Inbound Traffic From Any IP | Azure Container App allows inbound traffic from any IP address. | An attack could easily access a container app without any restrictions. |
Public Exposure | Azure Container App with Public Network Access | Azure Container App is publicly accessible. | An attacker might focus on a container app that is publicly accessible, aiming to exploit vulnerabilities like Denial of Service, Brute-force attacks, and others. |
Insecure Configurations | Azure Container App Permissive Cross-origin Resource Sharing (CORS) Policy | Azure Container App is set to allow any (wildcard) origins. | An attacker could exploit permissive CORS policies set on a web application to make unauthorized cross-origin requests, potentially gaining access to sensitive data or performing actions on behalf of a legitimate user without their consent. For example, an attacker might trick a victim into visiting a malicious website that sends requests to a trusted web service using the victim's credentials, allowing the attacker to steal data or perform actions on the victim's behalf. |
Insecure Configurations | Azure Container App Allows Unencrypted HTTP Traffic | Azure Container App without HTTPS enforcement. | Without HTTPS, a network-based attacker can eavesdrop on network traffic or manipulate it using an attack such as man-in-the-middle. |
Azure Container Instance (ACI)
Azure Container Instance (ACI)
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Public Exposure | Public Storage Account Container | Container with public access allowed. | In some cases, an attacker will be able to access data stored in the container. |
Insecure Configurations | Azure Container Instance Allows 'Any' DNS Scope Reuse | Azure Container Instance enables the reuse of 'Any' DNS scope, which can potentially lead to malicious subdomain takeover. | An attacker can abuse this configuration to steal the subdomain. |
Public Exposure | Azure Container Instance with Public Network Access | Azure Container Instance is publicly available | An attacker might focus on a container instance that is publicly accessible, aiming to exploit vulnerabilities like Denial of Service, Brute-force attacks, and others. |
Insufficient Encryption | Azure Container Instance Encrypted with Microsoft Managed Key | Azure Container Instance disk encrypted with Microsoft Managed Key. | An attacker who discovers a vulnerability in Azure's key management processes could potentially gain unauthorized access to encryption keys, enabling them to decrypt and access your Azure Container Instance data. |
Azure Cosmos DB
Azure Cosmos DB
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Data Security | Cosmos DB Connection From Public Azure Data Centers Enabled | This option configures the firewall to allow all requests from Azure, including requests from the subscriptions of other customers deployed in Azure. | In a scenario where a Cosmos DB account allows connections from IP address "0.0.0.0" (representing all public data centers), an attacker with an unauthorized account could exploit this configuration by gaining access from any location. This attacker could potentially infiltrate the Cosmos DB account, extract sensitive data, launch malicious queries, or even manipulate the database's content, all while leveraging the unrestricted public IP allowance. |
Insecure Configurations | Cosmos DB Account "Disabled Key Based Metadata Write Access" is Disabled | A CosmosDB Database with "Disabled Key Based Metadata Write Access" option disabled. | In a scenario where "disabled key based metadata write access" is disabled, an attacker could potentially exploit this vulnerability by gaining unauthorized access to modify or tamper with metadata using compromised keys. This could lead to unauthorized privilege escalation, data manipulation, or confusion in data organization, impacting the integrity and security of the Cosmos DB resources. |
Insecure Configurations | Cosmos DB Account is Not Using Virtual Network | Enabling Virtual Network integration for a Cosmos DB account is important as it adds an additional layer of security by restricting data access to specific networks, reducing exposure to potential threats. | In an attack scenario, if Virtual Network integration is not enabled for a Cosmos DB account, a malicious actor could exploit the lack of network restrictions by infiltrating the account through public endpoints, potentially compromising sensitive data or executing unauthorized operations on the database. |
Inadequate Authentication & Authorization | Cosmos DB Account Local Auth is Enabled | Cosmos DB account local auth is enabled. | An attacker with access to these static keys, could potentially perform malicious actions such as data extraction, modification, or deletion. Since the keys are long-lived and not subject to regular rotation, the compromise could persist for an extended period, leading to significant data breaches and security breaches. |
Insecure Configurations | Cosmos DB Account with Service Managed Encryption Key | Customer-Managed Keys (CMK) provide crucial advantage of retaining full control and ownership over their encryption keys, allowing them to enforce stricter access policies and meet regulatory compliance requirements. | An attacker who discovers a vulnerability in Azure's key management processes could potentially gain unauthorized access to encryption keys, enabling them to decrypt and access sensitive data stored in Cosmos DB. |
Public Exposure | Cosmos DB Account Access is Allowed From All Networks | Azure Cosmos DB with public access enabled. | An attacker could exploit this misconfiguration by remotely connecting to the publicly open database and exfiltrating sensitive data. |
Public Exposure | Cosmos DB Account is Not Using Private Endpoints | A CosmosDB database without private endpoints. | Not enabling Virtual Network integration for a Cosmos DB account can result in reduced security, potentially exposing data to unauthorized access. |
Azure Database for MariaDB
Azure Database for MariaDB
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Insecure Configurations | MariaDB Server is Not Using Virtual Networks | Not using virtual networks in a MariaDB account poses a security risk as it exposes the database to potential unauthorized access and data exposure, lacking the additional layer of network isolation and security controls provided by virtual networks. | In a scenario where a virtual network is not configured, the communication occurs over the public internet unless there are other network-level controls in place. If the communication is not encrypted, it becomes susceptible to interception by attackers. These attackers can then execute a Man-in-the-Middle attack to intercept the traffic between the two entities. |
Insecure Configurations | MariaDB Server TLS /SSL Disabled | MariaDB with disabled TLS/SSL option. | If TLS/SSL is disabled for a MariaDB account, an attacker on the same network could intercept the unencrypted database traffic, potentially capturing sensitive data such as passwords and queries. |
Public Exposure | MariaDB Server Connection From Public Azure Services | Having a firewall rule allowing access from Azure Public Services in MariaDB could pose a security as it might permit access from a broader range of Azure services than necessary, potentially exposing the database to unintended and unnecessary connections within the Azure network. | An attacker exploits a misconfigured MariaDB firewall rule allowing access from any Azure Public Service, potentially gaining unauthorized entry through unintended services. Once inside, the attacker could perform malicious operations on the database, jeopardizing data integrity and confidentiality. |
Public Exposure | MariaDB Server Has Full Public Network Access | Having Full public network access for all in a MariaDB account poses a security risk by potentially exposing the database to unauthorized access from any address. | An attacker, aware of the public network access on a MariaDB account for all, could exploit this vulnerability by launching attacks, attempting unauthorized logins, and potentially gaining control over the database, leading to unauthorized data access. |
Public Exposure | MariaDB Server is Not Using Private Endpoints | MariaDB without a private endpoint configured. | An attacker could exploit network vulnerabilities to intercept unencrypted database communication, potentially capturing sensitive data or injecting malicious commands. |
Azure Databricks Workspace
Azure Databricks Workspace
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Insufficient Encryption | Azure Databricks Managed Service Encrypt with Microsoft Managed Key | Azure databricks managed services encrypted at rest using server-side encryption with Microsoft-managed key. | An attacker who discovers a vulnerability in Azure's key management processes could potentially gain unauthorized access to encryption keys, enabling them to decrypt and access your Azure Databricks data. |
Insufficient Encryption | Azure Databricks Double Encryption for DBFS Root Should be Enabled | Azure Databricks double encryption for DBFS root disabled. Enabling double encryptionprovides an additional layer of security for your data at rest. | When double encryption is not enabled for DBFS root in Azure Databricks, an attacker can get your data because its protected by the default single layer of encryption, which does carry certain risks. Single-layer encryption can leave data potentially vulnerable if the encryption algorithm is compromised or if the encryption key is exposed through a security breach. |
Public Exposure | Azure Databricks with Public Network Access | Azure Databricks workspace with 'public network access' enable. | An attacker can access to the exposed resource. |
Public Exposure | Azure Databricks Should has a Secure Cluster Connectivity Enabled (No Public IP) | Azure Databricks secure cluster connectivity (No Public IP) disabled. When you enable 'No public IP' your clusters are not directly accessible from the internet, it is reducing the attack surface for potential threats. | When you are not enable 'Secure Cluster Connectivity'public IP addresses are assigned to Azure Databricks clusters, an attacker can exploit it todata theft, extracting sensitive or proprietary information from the datasets processed by the cluster. |
Insecure Configurations | Azure Databricks is not in a Virtual Network | Using a Virtual Network (VNet) in Azure Databricks is essential for security and network control. It provides an isolated environment where data processing and analytics can occur away from the public internet, significantly reducing exposure to external threats. VNets allow for the implementation of precise access controls and network traffic filtering using network security groups (NSGs), ensuring that only authorized users and services can interact with the Databricks workspace. | In a scenario where a virtual network is not configured, the communication occurs over the public internet unless there are other network-level controls in place. If the communication is not encrypted, it becomes susceptible to interception by attackers. These attackers can then execute a Man-in-the-Middle attack to intercept the traffic between the two entities. |
Insufficient Encryption | Azure Databricks Managed Disk Encrypt with Microsoft Managed Key | Azure databricks managed disk encrypted at rest using server-side encryption with Microsoft-managed key. | An attacker who discovers a vulnerability in Azure's key management processes could potentially gain unauthorized access to encryption keys, enabling them to decrypt and access your Azure Databricks data. |
Public Exposure | Azure Databricks without Private Endpoint | 'Private endpoint connection' is empty, this feature enables you to connect your Databricks workspace securely to Azure services or your on-premises network through a private IP address within your own virtual network (VNet). This private connection is facilitated by Azure Private Link, which ensures that data traffic between your Databricks workspace and other services traverses only through the Microsoft Azure network, avoiding exposure to the public internet. | An attackers can exploit exposed public endpoints to gain unauthorized access, potentially leading to denial of service attacks and compromising the workspace. |
Azure Entra ID
Azure Entra ID
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Permissive Access | Principal with Role Access Review Operator Service Permission on Management Group | A Principal with permissions to discover and revoke access as needed on management group scope. | An attacker could delete role assignments for all principals at management group scope. |
Permissive Access | Principal with high permissions in service ManagedIdentity on Management Group | A Principal with actions:* under Microsoft.ManagedIdentity. | A Principal with permissions to do all actions (*) under Microsoft.ManagedIdentity on management group scope |
Permissive Access | Principal with high permissions in service Network on Subscription | A Principal with actions:* under Microsoft.Network. | A Principal with permissions to do all actions (*) under Microsoft.Network on subscription scope. |
Permissive Access | Principal with high permissions in service ServiceFabric on Subscription | A Principal with actions:* under Microsoft.ServiceFabric. | A Principal with permissions to do all actions (*) under Microsoft.ServiceFabric on subscription scope. |
Permissive Access | Principal with high permissions in service DataShare on Subscription | A Principal with actions:* under Microsoft.DataShare. | A Principal with permissions to do all actions (*) under Microsoft.DataShare on subscription scope. |
Permissive Access | Principal with high permissions in service DocumentDB on Management Group | A Principal with actions:* under Microsoft.DocumentDB. | A Principal with permissions to do all actions (*) under Microsoft.DocumentDB on management group scope. |
Permissive Access | Principal with Permission to Write Role Definition on Management Group | A Principal with permissions to create or edit custom roles on management group scope (Microsoft.Authorization/ roleDefinitions/write). | An attacker can edit a custom role assigned to themselves to gain a high-privilege role like owner, thus elevating permissions on the control and data plane at the management group scope. |
Permissive Access | Principal with User Access Administrator Permission on Management Group | A principal with permissions to manage user access to Azure resources on management group scope. | An attacker can create a custom role, assign it to themselves, and elevate permissions on the control and data plane at management group scope. |
Permissive Access | Principal with high permissions in service Batch on Management Group | A Principal with actions: and/or data actions: under Microsoft.Batch. | A Principal with permissions to do all actions and/or data actions (*) under Microsoft.Batch on management group scope. |
Permissive Access | Principal with Role Based Access Control Administrator Permission on Management Group | A Principal with permissions to manage access to Azure resources by assigning roles using Azure RBAC on management group scope. | An attacker can create a custom role, assign it to themselves, and elevate permissions on the control and data plane at management group scope. |
Permissive Access | Principal with high permissions in service Kubernetes on Management Group | A Principal with actions: and/or data actions: under Microsoft.Kubernetes. | A Principal with permissions to do all actions and/or data actions (*) under Microsoft.Kubernetes on management group scope. |
Permissive Access | Principal with high permissions in service KeyVault on Subscription | A Principal with actions: and/or data actions: under Microsoft.KeyVault. | A Principal with permissions to do all actions and/or data actions (*) under Microsoft.KeyVault on subscription scope. |
Permissive Access | Principal with Owner Permissions on Subscription | A Principal with permissions to perform all actions on subscription scope (such as write, read, delete). | An attacker can perform any action on any resource on subscription scope |
Permissive Access | Principal with high permissions in service DataLakeAnalytics on Subscription | A Principal with actions:* under Microsoft.DataLakeAnalytics. | A Principal with permissions to do all actions (*) under Microsoft.DataLakeAnalytics on subscription scope. |
Permissive Access | Principal with high permissions in service Authorization on Subscription | A Principal with actions:* under Microsoft.Authorization. | A Principal with permissions to do all actions (*) under Microsoft.Authorization on subscription scope. |
Permissive Access | Principal with high permissions in service Storage on Management Group | A Principal with actions: and/or data actions: under Microsoft.Storage. | A Principal with permissions to do all actions and/or data actions (*) under Microsoft.Storage on management group scope. |
Permissive Access | Principal with high permissions in service Automation on Management Group | A Principal with actions:* under Microsoft.Automation. | A Principal with permissions to do all actions (*) under Microsoft.Automation on management group scope. |
Permissive Access | Principal with Write Permission on Management Group | A Principal with permissions to perform all write actions on management group scope (*/write - all actions that end with write). | An attacker can perform any write action on any resource on management group scope |
Permissive Access | Principal with high permissions in service Synapse on Subscription | A Principal with actions:* under Microsoft.Synapse. | A Principal with permissions to do all actions (*) under Microsoft.Synapse on subscription scope. |
Permissive Access | Principal with high permissions in service DataLakeStore on Subscription | A Principal with actions:* under Microsoft.DataLakeStore. | A Principal with permissions to do all actions (*) under Microsoft.DataLakeStore on subscription scope. |
Permissive Access | Principal with Read Permission on Management Group | A Principal with permissions to perform all read actions on management group scope (*/read - all actions that end with read). | An attacker can perform any read action on any resource on management group scope. |
Permissive Access | Principal with high permissions in service DBforMYSQL on Management Group | A Principal with actions:* under Microsoft.DBforMYSQL. | A Principal with permissions to do all actions (*) under Microsoft.DBforMYSQL on management group scope. |
Permissive Access | Principal with Delete Permission on Management Group | A Principal with permissions to perform all delete actions on management group scope (*/delete - all actions that end with delete). | An attacker can perform any delete action on any resource on management group scope |
Permissive Access | Principal with Permission to Write Role Assignments on Subscription | A Principal with permissions to create or edit role assignments on subscription scope (Microsoft.Authorization/ roleAssignments/write). | An attacker can assign themselves a high-privilege role like owner, thereby elevating permissions on the control and data plane at the subscription scope. |
Permissive Access | Principal with high permissions in service Kubernetes on Subscription | A Principal with actions: and/or data actions: under Microsoft.Kubernetes. | A Principal with permissions to do all actions and/or data actions (*) under Microsoft.Kubernetes on subscription scope. |
Permissive Access | Principal with high permissions in service Kusto on Subscription | A Principal with actions:* under Microsoft.Kusto. | A Principal with permissions to do all actions (*) under Microsoft.Kusto on subscription scope. |
Permissive Access | Principal with high permissions in service DBforMYSQL on Subscription | A Principal with actions:* under Microsoft.DBforMYSQL. | A Principal with permissions to do all actions (*) under Microsoft.DBforMYSQL on subscription scope. |
Permissive Access | Principal with high permissions in service DBforPostgreSQLe on Management Group | A Principal with actions:* under Microsoft.DBforPostgreSQL. | A Principal with permissions to do all actions (*) under Microsoft.DBforPostgreSQL on management group scope. |
Permissive Access | Principal with high permissions in service ContainerService on Subscription | A Principal with actions: and/or data actions: under Microsoft.ContainerService. | A Principal with permissions to do all actions and/or data actions (*) under Microsoft.ContainerService on subscription scope. |
Permissive Access | Principal with high permissions in service DataLakeAnalytics on Management Group | A Principal with actions:* under Microsoft.DataLakeAnalytics. | A Principal with permissions to do all actions (*) under Microsoft.DataLakeAnalytics on management group scope. |
Permissive Access | Principal with Read Permission on Subscription | A Principal with permissions to perform all read actions on subscription scope (*/read - all actions that end with read). | An attacker can perform any read action on any resource on subscription scope |
Permissive Access | Principal with high permissions in service Communication on Subscription | A Principal with actions:* under Microsoft.Communication. | A Principal with permissions to do all actions (*) under Microsoft.Communication on subscription scope. |
Permissive Access | Principal with high permissions in service Cache on Subscription | A Principal with actions:* under Microsoft.Cache. | A Principal with permissions to do all actions (*) under Microsoft.Cache on subscription scope. |
Permissive Access | Principal with Permission to Write Role Definition on Subscription | A Principal with permissions to create or edit custom roles on subscription scope (Microsoft.Authorization/ roleDefinitions/write). | An attacker can edit a custom role assigned to themselves to gain a high-privilege role like owner, thus elevating permissions on the control and data plane at the subscription scope. |
Permissive Access | Principal with high permissions in service app on Management Group | A Principal with actions: and/or data actions: under Microsoft.app. | A Principal with permissions to do all actions and/or data actions (*) under Microsoft.app on management group scope. |
Permissive Access | Principal with high permissions in service SignalRService on Management Group | A Principal with actions: and/or data actions: under Microsoft.SignalRService. | A Principal with permissions to do all actions and/or data actions (*) under Microsoft.SignalRService on management group scope. |
Permissive Access | Principal with high permissions in service Communication on Management Group | A Principal with actions:* under Microsoft.Communication. | A Principal with permissions to do all actions (*) under Microsoft.Communication on management group scope. |
Permissive Access | Principal with high permissions in service web on Management Group | A Principal with actions:* under Microsoft.web. | A Principal with permissions to do all actions (*) under Microsoft.web on management group scope. |
Permissive Access | Principal with high permissions in service ApiManagement on Management Group | A Principal with actions:* under Microsoft.ApiManagement. | A Principal with permissions to do all actions (*) under Microsoft.ApiManagement on management group scope. |
Permissive Access | Principal with high permissions in service DataLakeStore on Management Group | A Principal with actions:* under Microsoft.DataLakeStore. | A Principal with permissions to do all actions (*) under Microsoft.DataLakeStore on management group scope. |
Permissive Access | Principal with high permissions in service VisualStudio on Subscription | A Principal with actions:* under Microsoft.VisualStudio. | A Principal with permissions to do all actions (*) under Microsoft.VisualStudio on subscription scope. |
Permissive Access | Principal with Administrator Data Plane Permissions on Management Group | A Principal with permissions to perform all data actions on management group scope (such as- write, read, delete). | An attacker can perform any data action on any resource on management group scope. |
Permissive Access | Principal with high permissions in service ManagedIdentity on Subscription | A Principal with actions:* under Microsoft.ManagedIdentity. | A Principal with permissions to do all actions (*) under Microsoft.ManagedIdentity on subscription scope. |
Permissive Access | Principal with Full Administrator Permissions on Subscription | A Principal with permissions to perform all actions and all data actions on subscription scope(all actions and all data actions- such as write, read, delete). | An attacker can perform any action and data action on any resource on subscription scope |
Permissive Access | Principal with high permissions in service Network on Management Group | A Principal with actions:* under Microsoft.Network. | A Principal with permissions to do all actions (*) under Microsoft.Network on management group scope. |
Permissive Access | Principal with high permissions in service Synapse on Management Group | A Principal with actions:* under Microsoft.Synapse. | A Principal with permissions to do all actions (*) under Microsoft.Synapse on management group scope. |
Permissive Access | Principal with Administrator Data Plane Permissions on Subscription | A Principal with permissions to perform all data actions on subscription scope (such as- write, read, delete). | An attacker can perform any data action on any resource on subscription scope. |
Permissive Access | Principal with high permissions in service Automation on Subscription | A Principal with actions:* under Microsoft.Automation. | A Principal with permissions to do all actions (*) under Microsoft.Automation on subscription scope. |
Permissive Access | Principal with high permissions in service Sql on Subscription | A Principal with actions:* under Microsoft.Sql. | A Principal with permissions to do all actions (*) under Microsoft.Sql on subscription scope. |
Permissive Access | Principal with high permissions in service web on Subscription | A Principal with actions:* under Microsoft.web. | A Principal with permissions to do all actions (*) under Microsoft.web on subscription scope. |
Permissive Access | Principal with high permissions in service DataShare on Management Group | A Principal with actions:* under Microsoft.DataShare. | A Principal with permissions to do all actions (*) under Microsoft.DataShare on management group scope. |
Permissive Access | Principal with high permissions in service CognitiveServices on Management Group | A Principal with actions: and/or data actions: under Microsoft.CognitiveServices. | A Principal with permissions to do all actions and/or data actions (*) under Microsoft.CognitiveServices on management group scope. |
Permissive Access | Principal with high permissions in service CognitiveServices on Subscription | A Principal with actions: and/or data actions: under Microsoft.CognitiveServices. | A Principal with permissions to do all actions and/or data actions (*) under Microsoft.CognitiveServices on subscription scope. |
Permissive Access | Principal with high permissions in service Search on Subscription | A Principal with actions:* under Microsoft.Search. | A Principal with permissions to do all actions (*) under Microsoft.Search on subscription scope. |
Permissive Access | Principal with Owner Permissions on Management Group | A Principal with permissions to perform all actions on management group scope (such as write, read, delete). | An attacker can perform any action on any resource on management group scope |
Permissive Access | Principal with Role Based Access Control Administrator Permission on Subscription | A Principal with permissions to manage access to Azure resources by assigning roles using Azure RBAC on subscription scope. | An attacker can create a custom role, assign it to themselves, and elevate permissions on the control and data plane at subscription scope. |
Permissive Access | Principal with high permissions in service Batch on Subscription | A Principal with actions: and/or data actions: under Microsoft.Batch. | A Principal with permissions to do all actions and/or data actions (*) under Microsoft.Batch on subscription scope. |
Permissive Access | Principal with high permissions in service Kusto on Management Group | A Principal with actions:* under Microsoft.Kusto. | A Principal with permissions to do all actions (*) under Microsoft.Kusto on management group scope. |
Permissive Access | Principal with high permissions in service Compute on Management Group | A Principal with actions: and/or data actions: under Microsoft.Compute. | A Principal with permissions to do all actions (*) under Microsoft.Compute on management group scope. |
Permissive Access | Principal with high permissions in service Search on Management Group | A Principal with actions:* under Microsoft.Search. | A Principal with permissions to do all actions (*) under Microsoft.Search on management group scope. |
Permissive Access | Principal with high permissions in service DomainRegistration on Management Group | A Principal with actions:* under Microsoft.DomainRegistration. | A Principal with permissions to do all actions (*) under Microsoft.DomainRegistration on management group scope. |
Permissive Access | Principal with Full Administrator Permissions on Management Group | A Principal with permissions to perform all actions and all data actions on a management group scope(all actions and all data actions- such as write, read, delete). | An attacker can perform any action and data action on any resource on management group scope |
Permissive Access | Principal with high permissions in service Cache on Management Group | A Principal with actions:* under Microsoft.Cache. | A Principal with permissions to do all actions (*) under Microsoft.Cache on management group scope. |
Permissive Access | Principal with high permissions in service DataBricks on Subscription | A Principal with actions:* under Microsoft.Databricks. | A Principal with permissions to do all actions (*) under Microsoft.Databricks on subscription scope. |
Permissive Access | Principal with high permissions in service Sql on Management Group | A Principal with actions:* under Microsoft.Sql. | A Principal with permissions to do all actions (*) under Microsoft.Sql on management group scope. |
Permissive Access | Principal with high permissions in service ApiManagement on Subscription | A Principal with actions:* under Microsoft.ApiManagement. | A Principal with permissions to do all actions (*) under Microsoft.ApiManagement on subscription scope. |
Permissive Access | Principal with high permissions in service SignalRService on Subscription | A Principal with actions: and/or data actions: under Microsoft.SignalRService. | A Principal with permissions to do all actions and/or data actions (*) under Microsoft.SignalRService on subscription scope. |
Permissive Access | Principal with high permissions in service NetApp on Subscription | A Principal with actions:* under Microsoft.NetApp. | A Principal with permissions to do all actions (*) under Microsoft.NetApp on subscription scope. |
Permissive Access | Principal with Contributor Permission on Subscription | A Principal with permissions to manage all resources, but does not allow you to assign roles in Azure RBAC, manage assignments in Azure Blueprints, or share image galleries on subscription scope. | An attacker with the contributor role could potentially upload malicious data to resources or download sensitive information, such as secrets, directly from existing resources within the Azure environment. |
Permissive Access | Principal with high permissions in service ContainerService on Management Group | A Principal with actions: and/or data actions: under Microsoft.ContainerService. | A Principal with permissions to do all actions and/or data actions (*) under Microsoft.ContainerService on management group scope. |
Permissive Access | Principal with Permission to Write Role Assignments on Management Group | A Principal with permissions to create or edit role assignments on management group scope (Microsoft.Authorization/ roleAssignments/write). | An attacker can assign themselves a high-privilege role like owner, thereby elevating permissions on the control and data plane at the management group scope. |
Permissive Access | Principal with Role Access Review Operator Service Administrator Permission on Subscription | A Principal with permissions to discover and revoke access as needed on subscription scope. | An attacker could delete role assignments for all principals at subscription scope. |
Permissive Access | Principal with User Access Administrator Permission on Subscription | A Principal with permissions to manage user access to Azure resources on subscription scope. | An attacker can create a custom role, assign it to themselves, and elevate permissions on the control and data plane at subscription scope. |
Permissive Access | Principal with high permissions in service app on Subscription | A Principal with actions: and/or data actions: under Microsoft.app. | A Principal with permissions to do all actions and/or data actions (*) under Microsoft.app on subscription scope. |
Permissive Access | Principal with high permissions in service VisualStudio on Management Group | A Principal with actions:* under Microsoft.VisualStudio. | A Principal with permissions to do all actions (*) under Microsoft.VisualStudio on management group scope |
Permissive Access | Principal with high permissions in service DataBricks on Management Group | A Principal with actions:* under Microsoft.Databricks. | A Principal with permissions to do all actions under Microsoft.Databricks on management group scope. |
Permissive Access | Principal with high permissions in service DomainRegistration on Subscription | A Principal with actions:* under Microsoft.DomainRegistration. | A Principal with permissions to do all actions (*) under Microsoft.DomainRegistration on subscription scope. |
Permissive Access | Principal with high permissions in service KeyVault on Management Group | A Principal with actions: and/or data actions: under Microsoft.KeyVault. | A Principal with permissions to do all actions and/or data actions (*) under Microsoft.KeyVault on management group scope. |
Permissive Access | Principal with high permissions in service Authorization on Management Group | A Principal with actions:* under Microsoft.Authorization. | A Principal with permissions to do all actions (*) under Microsoft.Authorization on management group scope. |
Permissive Access | Principal with Delete Permission on Subscription | A Principal with permissions to perform all delete actions on subscription scope (*/delete - all actions that end with delete). | An attacker can perform any delete action on any resource on subscription scope |
Permissive Access | Principal with high permissions in service Compute on Subscription | A Principal with actions: and/or data actions: under Microsoft.Compute. | A Principal with permissions to do all actions and/or data actions (*) under Microsoft.Compute on subscription scope. |
Permissive Access | Principal with high permissions in service Storage on Subscription | A Principal with actions: and/or data actions: under Microsoft.Storage. | A Principal with permissions to do all actions and/or data actions (*) under Microsoft.Storage on subscription scope. |
Permissive Access | Principal with high permissions in service NetApp on Management Group | A Principal with actions:* under Microsoft.NetApp. | A Principal with permissions to do all actions (*) under Microsoft.NetApp on management group scope. |
Permissive Access | Principal with high permissions in service DBforPostgreSQL on Subscription | A Principal with actions:* under Microsoft.DBforPostgreSQL. | A Principal with permissions to do all actions (*) under Microsoft.DBforPostgreSQL on subscription scope. |
Permissive Access | Principal with Write Permission on Subscription | A Principal with permissions to perform all write actions on subscription scope (*/write - all actions that end with write). | An attacker can perform any write action on any resource on subscription scope. |
Permissive Access | Principal with high permissions in service DocumentDB on Subscription | A Principal with actions:* under Microsoft.DocumentDB. | A Principal with permissions to do all actions (*) under Microsoft.DocumentDB on subscription scope. |
Permissive Access | Principal with Contributor Permission on Management Group | A Principal with permissions to manage all resources, but does not allow you to assign roles in Azure RBAC, manage assignments in Azure Blueprints, or share image galleries on management group scope. | An attacker with the contributor role could potentially upload malicious data to resources or download sensitive information, such as secrets, directly from existing resources within the Azure environment. |
Permissive Access | Principal with high permissions in service ServiceFabric on Management Group | A Principal with actions:* under Microsoft.ServiceFabric. | A Principal with permissions to do all actions (*) under Microsoft.ServiceFabric on management group scope. |
Azure Function
Azure Function
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Public Exposure | Public Unauthenticated Function | A function with HTTP trigger and anonymous auth level. The HTTP trigger lets you invoke a function with an HTTP request, and the anonymous auth level lets you present a request without an API key. OWASP A2:2017 Broken Authentication. | An attacker can invoke the function, and in some cases can escape the function, gain the function app permissions and compromise your environment. |
Azure MySQL Flex
Azure MySQL Flex
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Public Exposure | Azure DB For MySQL is Publicly Accessible | Azure Database for MySQL haspublic network access setting enabled and a firewall rule that allow access from all IPs. | Anyone on the web can access the DB. Access is usually done using a key, but if the key gets compromised, it could lead to a lot of issues as anyone can reach that DB. It is best to use a virtual network to limit access to only those who need it. |
Public Exposure | Azure DB For MySQL is Publicly Accessible from Any Azure Service | Azure Database for MySQL haspublic network access setting enabled and a firewall rule that allow access from any azure service, even services of different azure subscription. | An attacker can create an azure account and azure subscription and any service he will deploy will have access to that DB. |
Azure OpenAI
Azure OpenAI
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Insecure Configurations | Azure OpenAI with Microsoft Managed Keys | Customer-Managed Keys (CMK) provide crucial advantage of retaining full control and ownership over your encryption keys, allowing you to enforce stricter access policies and meet regulatory compliance requirements. | An attacker who discovers a vulnerability in Azure's key management processes could potentially gain unauthorized access to encryption keys, enabling them to decrypt and access your Azure OpenAI data at rest such as the training data and fine-tuned models. |
Public Exposure | Azure OpenAI Allow Access from All Networks | Azure OpenAI with public access enabled. | "Allowing unrestricted, public access to cloud services could open an application up to external attack. An Attacker can access the resource and access the models using api calls, by exploiting a different vulnerability of the service/models he can gain access to the service/models configurations and maybe even gain access to sensitive information." |
Azure Resource Management (ARM)
Azure Resource Management (ARM)
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Identity & Access Management | Role Definition With List Storage Account Keys Permissions | A role definition with permissions to list storage account keys. | An attacker with access to the role can accsses storage accounts with "allowSharedKeyAccess" set to true. |
Identity & Access Management | Principal With Owner Role | Principal is assigned with the 'Owner' rolw that gives full permissions in the subscription. | An attacker with access to the principal can compromise the subscription. |
Identity & Access Management | Principal With User Access Administrator Role | Principal assigned with the 'User Access Administrator' role that enables to manage user access to Azure resources. | An attacker with access to the principal can compromise the subscription. |
Insufficient Encryption | Storage Account Table CMK Encryption Disabled | Unable to encryptStorage Account Tableswith Customer-managed key. | By default, Azure Storage accounts is encrypted using service-managed keys, using of CMK in Azure Storage gives customers the flexibility to manage and rotate their encryption keys according to their security and compliance requirements, and prevent from attacker to gain access to a sensitive data. |
Insufficient Encryption | Azure Storage Account with Microsoft Managed Key | Customer-Managed Keys (CMK) provide crucial advantage of retaining full control and ownership over your encryption keys, allowing you to enforce stricter access policies and meet regulatory compliance requirements. | An attacker who discovers a vulnerability in Azure's key management processes could potentially gain unauthorized access to encryption keys, enabling them to decrypt and access your data. |
Insufficient Encryption | Storage Account Queue CMK Encryption Disabled | Unable to encryptStorage Account queues with Customer-managed key. | By default, Azure Storage accounts is encrypted using service-managed keys, using of CMK in Azure Storage gives customers the flexibility to manage and rotate their encryption keys according to their security and compliance requirements, and prevent from attacker to gain access to a sensitive data. |
Azure Storage Account
Azure Storage Account
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Insecure Configurations | Storage Account With 'non-secure' Connection | Storage account that allows requests from a non-secure connection. | An attacker can have access to your data through unencrypted communications with the storage account. |
Insecure Configurations | Storage Account With Shared Key Access | Storage account with shared key access allowed. It is not a best practice to use shared key authorization for a storage account. | An attacker with access to a storage account key can access your storage account and compromise your data. |
Public Exposure | Storage Account With Blob Public Access Allowed | A storage account with blob public access allowed. This setting allows public access to be configured for containers in the account but does not enable public access to your data. | In some cases, an attacker will be able to access your blobs and compromise your data. |
Public Exposure | Storage Account With Unrestricted Network Access | Network access to the storage account is not restricted. | In some cases, an attacker would be able to access your storage account and the data stored in it. |
Azure Virtual Machine
Azure Virtual Machine
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Insecure Configurations | VM is not using managed disks | VM is not using managed disk, unmanaged disk is deprecated and can't be created any more but can still exist until the end of 2025. Managed disk are more secure by default and more resilient | |
Insecure Configurations | VM Secure Boot is Disabled | VM secure boot is disabled, it is best to enable secure boot as part of the trusted launch feature for best protection against boot level malwares | An attacker might be able to load undetectable rootkit or malicious code to the bootloader to run as part of the boot process of the machine. |
Insecure Configurations | VM is not part of zone or availability-set | Azure VM is not part of any availability zone or set, availability zones and sets protects the VM from failures and creates better resiliency, connectivity and availability | An attacker can have easier time causing DoS if availability zones and availability sets are not in used. |
Inadequate Logging & Backup | VM Boot Diagnostics is Disabled | VM boot diagnostics is disabled, This can help with understanding and following the events that happened incase of a secure incidents or when VM is compromised | N/A |
Insecure Configurations | Linux VMs Should not Use Passwords | Linux VM is allowing authentication using passwords. Keys alone should be used as passwords are more vulnerable, brute force for example | A weak password can be compromised by an attacker which can then can use that password to SSH to the machine. |
Insecure Configurations | VM vTPM is Disabled | VM vTPM is disabled, vTPM validates your VM pre-boot and boot integrity. It generates and securely stores encryption keys. | If vTPM is disabled, an attacker might be able to compromise the boot process of the VM. |
Azure Virtual Network
Azure Virtual Network
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Public Exposure | Network Security Group With Open RDP Port (3389) | A network security group with RDP port (3389) open to any IP. | An attacker can try to exploit RDP vulnerabilities leaving your environment at risk. |
Azure VM Scale Set
Azure VM Scale Set
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Insecure Configurations | VMSS is not using managed disks | Virtual machine scale-set (VMSS) is not using managed disk, unmanaged disk is deprecated and can't be created any more but can still exist until the end of 2025. Managed disk are more secure by default and more resilient. VMSS should be utilizing managed disks provided by azure. |
Microsoft Entra ID Autorization Policy
Microsoft Entra ID Autorization Policy
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Inadequate Authentication & Authorization | Entra ID Conditional Access Mfa for All Users is not Configured Properly | The conditional access policy that enforces multifactor authentication for all users is not configured propely. | An attacker can exploit the lack of enforecement of this condtional access policy and perform an identity related attack such as password spray, replay, and phishing. |
Inadequate Authentication & Authorization | Entra ID Tenant doesn't Enable Conditional Policy for MFA for All users | The conditional access policy that enforces multifactor authentication for all users is not enabled. | An attacker can exploit the lack of enforecement of this condtional access polic and perform an identity related attack such as password spray, replay, and phishing. |
Inadequate Authentication & Authorization | Entra ID Tenant without security defaults | An Entra Id tenant that doesn't enable security defaults. Security Defaults is a free option available with Entra ID which includes several security settings such as requriring all users to register for mfa. | An attacker can exploit the lack of security defaults and perform an identity related attack such as password spray, replay, and phishing. |
Google Cloud Platform (GCP) - click to collapse
Google Cloud Platform (GCP)
Click on a service name below to view a table of the risks Panoptica detects in GCP, along with brief descriptions and attack scenarios.
App Engine
App Engine
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Permissive Access | App Engine Service With Default Service Account | By default App Engine service run with App Engine default service account, this service account has 'Editor' role in the project. | Attacker with access to App Engine service with default service account can deploy changes to the Cloud project can also run code with read/write access to all resources within that project. |
Insecure Configurations | App Engine Service with Insecure Ingress Settings | This risk identifies a Google Cloud App Engine service configured with insecure ingress settings, potentially allowing unauthorized access. Insecure ingress settings can significantly heighten the risk of unauthorized access and potential data breaches. It's recommended to review these settings, and if the open access isn't necessary, promptly refine the ingress rules to enhance the security of your App Engine service. | An attacker can send direct requets to the app from the internet. |
Public Exposure | App Engine App With Public Ingress Rule | App Engine app with public ingress rule. | An attacker might use this misconfiguration to access the application running in App Engine. |
Unsupported Software | App Engine Service With Legacy Runtime | App Engine service running on legacy runtime. | Legacy runtimes support language versions that are no longer> maintained by open source communities. As communities stop maintaining versions, the app may be exposed to vulnerabilities for which no publicly available fix exists. |
BigQuery
BigQuery
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Permissive Access | BigQuery Dataset With Cross Project Access | A BigQuery dataset with a policy binding of a service account from a different project. | An attacker with access to the project that has access to the dataset can compromise your data. |
Permissive Access | BigQuery Table/View With Cross Project Access | A BigQuery table or view with a policy binding of a service account from a different project. | An attacker with access to the outside service account can access this table or view and compromise your data. |
Insecure Configurations | BigQuery Dataset Without Customer Managed Encryption Key (CMEK) | A BigQuery dataset without a customer-managed encryption key (CMEK). | CMEK provides more administrative control. Administrators can rotate, manage access to, and disable or destroy the key used to protect data at rest. |
Insecure Configurations | BigQuery Table/View Without Customer Managed Encryption Key (CMEK) | A BigQuery Table or View without a customer-managed encryption key (CMEK). | CMEK provides more administrative control. Administrators can rotate, manage access to, and disable or destroy the key used to protect data at rest. |
Public Exposure | Public BigQuery Dataset | A publicly accessible BigQuery dataset. | An attacker can access this dataset and compromise your data. |
Public Exposure | Public BigQuery Table/View | A publicly accessible BigQuery table or view. | An attacker can access this table or view and compromise your data. |
Bigtable
Bigtable
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Identity & Access Management | Bigtable Instance Allows Access Of Service Account From Another Project | Bigtable instance with a policy binding of a service account from a different project. | An attacker with access from different project can compromise the environment. |
Identity & Access Management | Bigtable Table Allows Access Of Service Account From Another Project | Bigtable table with a policy binding of a service account from a different project. | An attacker with access from different project can compromise the environment. |
Insecure Configurations | Bigtable Cluster Without Customer Managed Encryption Key (CMEK) | Bigtable cluster configured without CMEK. | CMEK provides more administrative control. Administrators can rotate, manage access to, and disable or destroy the key used to protect data at rest. |
Cloud Run
Cloud Run
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Identity & Access Management | Cloud Run Job Running with Permissive Permissions | A user / users with the roles/run.admin role can invoke or interact with the Cloud Run Job. While this approach can simplify deployment and usage, it also raises security concerns, as it may expose sensitive data or functions to potential misuse or unauthorized access. | Permissive permissions present significant security risks in cloud environments, as they can lead to unauthorized access, data breaches, and potential misuse of resources. |
Identity & Access Management | Cloud Run Service Running with Permissive Permissions | A user / users with the roles/run.admin role can invoke or interact with the Cloud Run Service. While this approach can simplify deployment and usage, it also raises security concerns, as it may expose sensitive data or functions to potential misuse or unauthorized access. | Permissive permissions present significant security risks in cloud environments, as they can lead to unauthorized access, data breaches, and potential misuse of resources. |
Identity & Access Management | IAM with cloud run service admin permission | A GCP identity with admin permissions to cloud run job. | An attacker with this permission has administrative access to a cloud run job. |
Identity & Access Management | IAM with cloud run service admin permission | A GCP identity with admin permissions to cloud run service. | An attacker with this permission has administrative access to a cloud run service. |
Identity & Access Management | Unauthenticated Invocations Allowed for Cloud Run Service | Unauthenticated invocations are enabled for this Cloud Run service. It is assigned the "allUsers" principal type with the "Cloud Run Invoker" IAM role. This effectively makes the service accessible to anyone on the internet without requiring authentication, granting anonymous access to it. | This service can be accessed by an attacker without the need for authentication. This could potentially be leveraged to exploit any vulnerabilities, resulting in a Denial of Service (DoS) attack, unauthorized extraction of sensitive data, or remote execution of commands on the underlying host. |
Insecure Configurations | Binary Authorization Disabled for Cloud Run Job | Binary Authorization offers deployment control based on policies, ensuring that only trusted and verified container images are allowed for deployment. | An attacker who gains access to the Continuous Integration environment can inject malicious code or tamper with legitimate code during the build and deployment (CI-CD) process. This can introduce vulnerabilities, backdoors, or other security weaknesses into the software, which may go undetected until the compromised code is deployed. |
Insecure Configurations | Binary Authorization Disabled for Cloud Run Service | Binary Authorization offers deployment control based on policies, ensuring that only trusted and verified container images are allowed for deployment. | An attacker who gains access to the Continuous Integration environment can inject malicious code or tamper with legitimate code during the build and deployment (CI-CD) process. This can introduce vulnerabilities, backdoors, or other security weaknesses into the software, which may go undetected until the compromised code is deployed. |
Permissive Access | Cloud Run Job is Using the Compute Engine Default Service Account | Cloud Run job uses the compute engine default service account. This account is automatically created when a new project is set up By default, this service account has broad IAM permissions and it is automatically associated with every Cloud Run job. | An attacker with access to the default service account token could access each and every Cloud Run job and its associated management API operating within the same GCP project. |
Permissive Access | Cloud Run Service is Using the Compute Engine Default Service Account | Cloud Run service uses the compute engine default service account. This account is automatically created when a new project is set up. By default, this service account has broad IAM permissions and is automatically associated with every Cloud Run service. | An attacker with access to the default service account token could access each and every Cloud Run service and its associated management API operating within the same GCP project. |
Public Exposure | Cloud Run Service Publicly Accessible | This risk signifies a publicly accessible Cloud Run Service, making it accessible to any Internet user. Publicly accessible services raise the risk of unauthorized access, misuse, and breaches. The necessity of this public service should be verified; if not required, immediate action to restrict this service is advised to minimize potential security risks. | Depending on the application deployed, an attacker can exploit vulnerabilities to gain unauthorized access, manipulate and steal sensitive data, and even execute malicious actions that compromise the entire system. |
Compute Engine
Compute Engine
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Credentials Exposure | Compute Engine Instance With Cleartext Chargify Key | Chargify Key Discovered In Cleartext | An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls. |
Credentials Exposure | Compute Engine Instance With Cleartext Jenkins Password | Jenkins Password Discovered In Cleartext | An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls. |
Credentials Exposure | Compute Engine Instance With Cleartext MySQL Password | MySQL Password Discovered In Cleartext | An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls. |
Credentials Exposure | Compute Engine Instance With Cleartext NewRelic Key | NewRelic Key Discovered In Cleartext | An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls. |
Credentials Exposure | Compute Engine Instance With Cleartext OAuth Key | OAuth Key Discovered in Cleartext | An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls. |
Credentials Exposure | Compute Engine Instance With Cleartext Postgres Password | Postgres Password Discovered In Cleartext | An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls. |
Credentials Exposure | Compute Engine Instance With Cleartext RabbitMQ Password | RabbitMQ Password Discovered In Cleartext | An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls. |
Credentials Exposure | Compute Engine Instance With Cleartext Salesforce Credentials | Salesforce Credentials Discovered In Cleartext | An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls. |
Credentials Exposure | Compute Engine Instance With Cleartext Segment Token | Segment Token Discovered In Cleartext | An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls. |
Credentials Exposure | Compute Engine Instance With Cleartext SMTP Password | SMTP Password Discovered In Cleartext | An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls. |
Credentials Exposure | Compute Engine Instance With Cleartext Vero Secret | Vero Secret Discovered In Cleartext | An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls. |
Credentials Exposure | Compute Engine Instance With Sensitive Generic Secret | Sensitive Generic Secret Found in Cleartext | An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls. |
Credentials Exposure | Compute Engine Instance With Sensitive Generic Secret In Metadata | Sensitive Generic Secret Found in Metadata | An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls. |
Identity & Access Management | IAM principal with set IAM policy permission on compute instances | A GCP Identity with permissions to set an IAM policy for compute instances. | An attacker with the setIamPolicy on a compute instance will be able to modify the IAM policy of the instance, granting himself additional privileges at the resource level. If this permission is given at the project level, the attacker will be able to change all the project instances' policies. This method could range from full access to a specific instance to full administrator access to the project. |
Insecure Configurations | Compute Engine Instance With Interactive Serial Console Enabled | VM interactive serial console is enabled and does not support IP-based access restrictions. | Attacker can attempt to connect to the instance's serial console from any IP address. |
Insecure Configurations | Compute Engine Instance With IP Forwarding Enabled | VM instance with a configuration that enables IP forwarding. | Attacker can attempt to send and receive packets with differenct source and destination. |
Insecure Configurations | Compute Engine Instance With Project Wide SSH Keys | VM instance with a configuration that allows project-wide SSH keys. | Attacker can attempt to connect to an instance using the SSH keys configured for the project. |
Insecure Configurations | Unused Compute Engine Disk | Unused disk by any instance is found. | An attacker can access the unused disk, leading to data exposure. |
Unsupported Software | Deprecated Compute Engine Image | ||
Unsupported Software | Compute Engine Instance With Deprecated Image | A deprecated image. | An attacker can exploit the deprecated image and create an instance using it. |
Dataproc
Dataproc
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Insecure Configurations | API access to all Google Cloud services in same project is allowed | Dataproc cluster configured to allow API access to all Google Cloud services in the same project. | An attacker with access to compute engine can access google cloud services without scope limitation, leading to potentially exploit various services. |
Insecure Configurations | Dataproc Cluster Without Customer Managed Encryption Key (CMEK) | A Dataproc cluser configured without CMEK. | CMEK provides more administrative control. Administrators can rotate, manage access to, and disable or destroy the key used to protect data at rest. |
Public Exposure | Public Dataproc Cluster | A public Dataproc cluster. | An attacker can access Dataproc instances from the internet. |
Unsupported Software | Dataproc Cluster With Unsupported Image Version | A Dataproc cluster with an unsupported image version. | An attacker can exploit known unpatched vulnerabilities in unsupported images. |
Function
Function
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Permissive Access | Compute Engine Instance Default Service Account With Owner Role | Compute Engine default service account with owner permissions on the project. | An attacker with access to a compute engine that is attached to the default service account will have full access to the project. |
Permissive Access | Compute Instance Default Service Account With Editor Role | Compute Engine default service account with editor permissions on the project. | An attacker with access to a compute engine that is attached to the default service account will be able to perform unauthorized actions in your project. |
Permissive Access | Service Account With Editor Role | Service Account with editor permissions on the project. | An attacker with access to the service account will be able to perform most of the actions in the project. |
Service Account With Owner Role | Service Account with owner permissions on the project. | An attacker with access to the service account will be able to perform any action in the project. | |
Permissive Access | User With Editor Role | User with editor permissions on the project. | An attacker with access to the user will be able to perform most of the actions in the project. |
Permissive Access | User With Owner Role | User with owner permissions on the project. | An attacker with access to the user will be able to perform any action in the project. |
Insecure Configurations | Cloud Function With HTTP Only (not HTTPS) | GCP function with HTTP trigger set to require HTTP only (and not HTTPS). OWASP A6:2017 Security Misconfiguration. | An attacker can invoke the function via HTTP, gain the function app permissions and compromise your environment. |
Public Exposure | Cloud Function Allows Anonymous Access | The function allows access for anonymous users. OWASP A2:2017 Broken Authentication. | An anonymous attacker can run actions against the function and might damage internal services or expose sensetive data. |
Permissive Access | Cloud Function Can Be Invoked By Anonymous Users | The function can be invoked by anonymous users. OWASP A6:2017 Security Misconfiguration. | An anonymous attacker can invoke the function and might damage internal services or expose sensetive data. |
Unsupported Software | GCP Function With Deprecated Runtime | GCP function with a deprecated runtime. OWASP A6:2017 Security Misconfiguration. | An attacker can exploit known unpatched vulnerabilities in the gcp function runtime. |
GKE (Google Kubernetes Engine)
GKE (Google Kubernetes Engine)
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Insecure Configurations | GKE Cluster is Alpha | GKE alpha cluster. OWASP K09:2022 Misconfigured Cluster Components | Alpha clusters are short-lived clusters that run stable Kubernetes releases with all Kubernetes APIs and features enabled. Alpha clusters are limited and do not receive security updates. |
Insecure Configurations | GKE Cluster With Application Layer Secrets Encryption Disabled | GKE cluster with application-layer secrets encryption disabled. OWASP K08:2022 Secrets Management Failures | An attacker can gain access to an offline copy of etcd, where secrets are stored. |
Insecure Configurations | GKE Cluster With Client Certificate | GKE cluster with client certificate. OWASP K06:2022 Broken Authentication Mechanisms | An attacker can use the base64 certifcate public certificate to authenticate to the cluster endpoint. Certificates do not rotate automatically. and are difficult to revoke. |
Insecure Configurations | GKE Cluster With 'Cloud Logging' Option Disabled | GKE cluster with "Cloud Logging" option disabled. OWASP K05:2022 Inadequate Logging and Monitoring | Logging provides audit and diagnostic logs in your account. Collecting logs are critical for clusters as it significantly accelerates the troubleshooting process. |
Insecure Configurations | GKE Cluster With 'Control plane authorized networks' Option Disabled | GKE cluster with "Control plane authorized networks" option disabled. OWASP K07:2022 Missing Network Segmentation Controls | An attacker can access the cluster's control plane endpoint through HTTPS. |
Insecure Configurations | GKE Cluster With Default Service Account Attached To Node Pool | GKE cluster with a default service account attacked to the node pool. OWASP K09:2022 Misconfigured Cluster Components | By default, nodes are given the compute engine default service account. This account has more permissions than are required to run your Kubernetes Engine cluster, allowing attackers to use these permissions to compromise your environment. |
Insecure Configurations | GKE Cluster With 'Legacy authorization' Option Enabled | GKE cluster with "Legacy authorization" option enabled. OWASP K06:2022 Broken Authentication Mechanisms | By default, ABAC is disabled for clusters created using GKE version 1.8 and later as RBAC has significant security advantages over ABAC. |
Insecure Configurations | GKE Cluster With Network Policy Disabled | GKE cluster with network policy disabled. OWASP K07:2022 Missing Network Segmentation Controls | An attacker can access any pod in the cluster without network restrictions. Network policy is used to create Pod-level firewall rules. These firewall rules determine which Pods and Services can access one another inside your cluster. |
Insecure Configurations | GKE Cluster With Shielded Nodes Disabled | GKE cluster with shielded nodes disabled. OWASP K09:2022 Misconfigured Cluster Components | An attacker can exploit a vulnerability in a Pod to exfiltrate bootstrap credentials and impersonate nodes in a cluster giving the attacker access to cluster secrets. |
Insecure Configurations | GKE Cluster Without Automatic Node Upgrade | GKE cluster with no automatic node upgrade enabled. OWASP K09:2022 Misconfigured Cluster Components | Node auto-upgrades help you keep the nodes in your cluster up-to-date with the cluster control plane version when your control plane is updated on your behalf. |
Insecure Configurations | GKE Cluster With 'secure boot' Option Disabled | GKE cluster with 'secure boot' option disabled. OWASP K09:2022 Misconfigured Cluster Components | Secure boot helps protect nodes against boot-level and kernel-level malware and rootkits. |
KMS (Cloud Key Management)
KMS (Cloud Key Management)
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Neglected Resource | KMS Key With Rotation Period Bigger Than 90 Days | A KMS key that has a rotation period bigger than 90 days. | Key rotation reduces the risk of a compromised key being used by an attacker to access your encrypted resources. |
Public Exposure | Publicly Accessible KMS Key | A publicly accessible Cloud KMS key. | An attacker can access your KMS key. Depending on the level of access, he might be able to use the key to decrypt data and compromise it. |
Memorystore
Memorystore
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Insecure Configurations | Memorystore AUTH is Disabled | Disabling authentication (AUTH) in Memorystore allows unrestricted access to the data store, leaving it exposed to unauthorized users and increasing the risk of data breaches and tampering. | An attacker, aware that authentication (AUTH) is disabled in Memorystore, can gain unauthorized access to the data store, potentially exfiltrating sensitive data, injecting malicious content, or disrupting the service without any authentication barriers. |
Insecure Configurations | Memorystore Connection by Direct Peering | Using Direct Peering establishes a direct VPC peering connection between the customer's network and Google's managed project, potentially exposing the customer's network to security risks, as this peering isn't shared with other Google Cloud services and lacks the enhanced access controls and isolation offered by Private Service Access (PSA). | An attacker monitors network traffic in the customer's VPC that uses Direct Peering to connect to Memorystore for Redis. Since Direct Peering lacks the isolation and security features of Private Service Access (PSA), the attacker can potentially eavesdrop on sensitive data transmissions, such as Redis authentication credentials or sensitive cache data, leading to data exfiltration or unauthorized access. |
Insecure Configurations | Memorystore Encryption by Transit is Disabled | Disabling encryption in Memorystore's transit data transmission exposes data to potential interception, tampering, and security breaches, posing significant risks to data confidentiality and integrity. | An attacker monitoring the network traffic between a client application and a Memorystore instance with encryption in transit disabled could intercept sensitive user session data, such as login credentials, and potentially launch a man-in-the-middle attack, impersonating the client or the server, leading to data theft or manipulation. |
Insecure Configurations | Memorystore Encryption without CMEK | Not having Customer Managed Encryption Keys (CMEK) in Memorystore's encryption setup leaves data encryption solely reliant on default Google-managed keys, potentially exposing sensitive data to unauthorized access and lacking the enhanced control and key management provided by CMEK. | An attacker with sufficient knowledge of Memorystore's encryption configuration without CMEK could potentially compromise the default Google-managed keys, gaining unauthorized access to the encrypted data and bypassing the additional security controls offered by customer-managed encryption keys, leading to data exposure and potential breaches. |
Network Firewall
Network Firewall
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Public Exposure | Firewall Rule Permits Connections From Any IP (0.0.0.0/0) | This risk signifies a Google Cloud Platform Firewall Rule configured to allow incoming connections from any IP address, indicated by the range 0.0.0.0/0. This unrestricted access can heighten the risk of unauthorized access and potential data breaches. It's recommended to verify whether such broad access is necessary and, if not, promptly refine the access control to allow connections from specific, trusted IP addresses or ranges. | An attacker might use this misconfiguration to access assets within the GCP environment. |
Project
Project
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Identity & Access Management | Compute Engine Instance Default Service Account With Owner Role | Compute Engine default service account with owner permissions on the project. | An attacker with access to a compute engine that is attached to the default service account will have full access to the project. |
Identity & Access Management | Compute Instance Default Service Account With Editor Role | Compute Engine default service account with editor permissions on the project. | An attacker with access to a compute engine that is attached to the default service account will be able to perform unauthorized actions in your project. |
Identity & Access Management | GKE cronJobs permissions | GKE any cronJobs permission. | An attacker can create, delete, get, list and update any cronJob. |
Identity & Access Management | GKE daemonSets permissions | GKE any daemonSets permission. | An attacker can create, delete, get, list and update any daemonSets. |
Identity & Access Management | GKE deployments permissions | GKE any deployments permission. | An attacker can create, delete, get, list and update any deployments. |
Identity & Access Management | GKE job permissions | GKE any jobs permission. | An attacker can create, delete, get, list and update any job. |
Permissive Access | GKE permissions to create any resource | GKE permissions to create any resource. | An attacker can create any resource in the cluster, leading to cluster compromise. |
Permissive Access | GKE permissions to create cluster role binding | GKE permissions to create cluster role bindings. | An attacker can create cluster roles binded to a risky role, leading to cluster compromise. |
Permissive Access | GKE permissions to create cronjobs | GKE permissions to create cronjobs. | An attacker can create cronjobs containing containers that execute malicious code within a cluster, leading to cluster compromise. |
Permissive Access | GKE permissions to create daemonsets | GKE permissions to create daemonsets. | An attacker can create daemonsets containing containers that execute malicious code within a cluster, leading to cluster compromise. |
Permissive Access | GKE permissions to create deployments | GKE permissions to create deployments. | An attacker can create a deployment with malicious components leading to cluster compromise. |
Permissive Access | GKE permissions to create ingresses | GKE permissions to create ingresses. | An attacker can create risky ingresses, exposing internal services and leading to cluster compromise. |
Permissive Access | GKE permissions to create jobs | GKE permissions to create jobs. | An attacker can create jobs containing malicious code executed within a cluster, leading to cluster compromise. |
Permissive Access | GKE permissions to create pods | GKE permissions to create pods. | An attacker can create pods containing containers that execute malicious code within a cluster, leading to cluster compromise. |
Permissive Access | GKE permissions to create replicasets | GKE permissions to create replicasets. | An attacker can create replicasets containing containers that execute malicious code within a cluster, leading to cluster compromise. |
Permissive Access | GKE permissions to create replication controllers | GKE permissions to create replication controllers. | An attacker can create replication controllers containing containers that execute malicious code within a cluster, leading to cluster compromise. |
Permissive Access | GKE permissions to create role binding | GKE permissions to create role bindings. | An attacker can create roles binded to a risky role, leading to cluster compromise. |
Permissive Access | GKE permissions to create statefulsets | GKE permissions to create statefulsets. | An attacker can create statefulsets containing containers that execute malicious code within a cluster, leading to cluster compromise. |
Permissive Access | GKE permissions to delete any resource | GKE permissions to delete any resource. | An attacker can delete any resource in the cluster, leading to cluster compromise. |
Permissive Access | GKE permissions to get any resource | GKE permissions to get any resource. | An attacker can delete any resource in the cluster, leading to cluster compromise. |
Permissive Access | GKE permissions to list any resource | GKE permissions to list any resource. | An attacker can list any resource in the cluster, leading to cluster compromise. |
Permissive Access | GKE permissions to update cronjobs | GKE permissions to update cronjobs. | An attacker can update cronjobs to contain containers that execute malicious code within a cluster, leading to cluster compromise. |
Permissive Access | GKE permissions to update daemonsets | GKE permissions to update daemonsets. | An attacker can update daemonsets to contain containers that execute malicious code within a cluster, leading to cluster compromise. |
Permissive Access | GKE permissions to update deployments | GKE permissions to update deployments. | An attacker can update a deployment to contain malicious components leading to cluster compromise. |
Permissive Access | GKE permissions to update ingresses | GKE permissions to update ingresses. | An attacker can update ingresses to expose internal services, which can lead to cluster compromise. |
Permissive Access | GKE permissions to update jobs | GKE permissions to update jobs. | An attacker can update cronjobs to contain containers that execute malicious code within a cluster, leading to cluster compromise. |
Permissive Access | GKE permissions to update replicasets | GKE permissions to update replicasets. | An attacker can update replicasets to contain containers that execute malicious code within a cluster, leading to cluster compromise. |
Permissive Access | GKE permissions to update replication controllers | GKE permissions to update replication controllers. | An attacker can update replication controllers containing containers that execute malicious code within a cluster, leading to cluster compromise. |
Permissive Access | GKE permissions to update statefulsets | GKE permissions to update statefulsets. | An attacker can update a statefulset to contain malicious components leading to cluster compromise. |
Identity & Access Management | GKE pods permissions | GKE any pods permission. | An attacker can create, delete, get, list and update any pod. |
Identity & Access Management | GKE replicaSets permissions | GKE any replicasets permission. | An attacker can create, delete, get, list and update any replicasets. |
Identity & Access Management | GKE replicationControllers permissions | GKE any replicationControllers permission. | An attacker can create, delete, get, list and update any replicationController. |
Identity & Access Management | GKE secrets permissions | GKE any secrets permission. | An attacker can create, delete, get, list and update any secret. |
Identity & Access Management | GKE statefulSets permissions | GKE statefulSets permissions. | An attacker can create, delete, get, list and update any statefulSet. |
Permissive Access | IAM principal with set IAM policy permission on compute instances | A GCP Identity with permissions to set an IAM policy for compute instances. | An attacker with the setIamPolicy on a compute instance will be able to modify the IAM policy of the instance, granting himself additional privileges at the resource level. If this permission is given at the project level, the attacker will be able to change all the project instances' policies. This method could range from full access to a specific instance to full administrator access to the project. |
Permissive Access | IAM principal with set IAM policy permission on service accounts | A GCP Identity with permissions to set an IAM policy for service accounts. | An attacker with the setIamPolicy on a service account will be able to modify the IAM policy of the resource, granting himself additional privileges at the resource level. If this permission is given at the project level, the attacker will be able to change all the project service accounts' policies and give himself access to the strongest ones. This method could range from full access to a specific resource to full administrator access to the project depending on the permissions of the service account. |
Permissive Access | IAM principal with set IAM policy permission on storage buckets | A GCP Identity with permissions to set an IAM policy for storage buckets. | An attacker with the setIamPolicy on a storage bucket will be able to modify the IAM policy of the bucket, granting himself additional privileges at the resource level. If this permission is given at the project level, the attacker will be able to change all the project buckets' policies. This method could range from full access to a specific bucket to full storage access to the project. |
Permissive Access | IAM with Create cloud function with service account permission | A GCP identity with permissions to create and call a cloud function with an assigned service account. | An attacker with the iam.serviceAccounts.actAs, cloudfunctions.functions.create, cloudfunctions.functions.sourceCodeSet and cloudfunctions.functions.call will be able to create a new cloud function with a specified service account. The function, when invoked, can access the metadata API and return the associated service account's access token. This method could range from no privilege escalation to full access to the project, depending on the service account's permissions. |
Permissive Access | IAM with Create cloud scheduler with service account permission | A GCP identity with permissions to create a cloud scheduler job. | An attacker with the iam.serviceAccounts.actAs and >cloudscheduler.jobs.create permissions will be able to create jobs that send requests to *.googleapis.com endpoints. These requests can be authenticated as a specific service account. To escalate privileges with this method, the attacker needs to create an HTTP request of the action he wants to perform. |
Permissive Access | IAM with Create compute instance with service account permission | A GCP identity with permissions to create a new compute instance with a specified service account. | An attacker with the iam.serviceAccounts.actAs and with permissions to create a new instance will be able to create an instance with a specified service account and get its access token. This method could range from no privilege escalation to full access to the project, depending on the service account's permissions. |
Permissive Access | IAM with Create Deployments permission | A GCP Identity with permissions to create a deployment in the deployment manager service. | An attacker with the deploymentmanager.deployments.create permission can gain the Editor role permissions on the project. This permission lets you launch new deployments of resources into GCP as the PROJECT-NUMBER@ cloudservices.gserviceaccount.com service account, which, by default, is granted the Editor role on the project. |
Permissive Access | IAM with Create service account key permission | A GCP Identity with permissions to create a service account key. | An attacker with the iam.serviceAccountKeys.create permission can create a user-managed key for a Service Account that will allow him to access GCP as that Service Account. This method could range from no privilege escalation to full access to the project, depending on the service account's permissions. |
Permissive Access | IAM with Create service usage API key permission | A GCP identity with permissions to create API keys. | An attacker with the serviceusage.apiKeys.create permission will be able to create an API key, that is unrestricted by default, and use it to authenticate with GCP's APIs. By that, he can gain access to the entire GCP project. |
Permissive Access | IAM with Create storage HMAC keys permission | A GCP identity with permission to create HMAC keys. | An attacker with the storage.hmacKeys.create permission will be able to create an hmac key for a specified service account, and use it for authentication. Depending on the service account's permissions, this method could range from no privilege escalation to full storage access. |
Permissive Access | IAM with Get service account access token permission | A GCP Identity with permissions to get a service account's access token | An attack with the iam.serviceAccounts.getAccessToken permission will be able to get an access token that belongs to a specified service account and gain its permissions. Depending on the service account's permissions, this method could range from no privilege escalation to full administrator access to the account. |
Permissive Access | IAM with List service usage API keys permission | A GCP identity with permissions to get an existing API key. | An attacker with the serviceusage.apiKeys.list and apikeys.keys.getKeyString permissions will be able to get all the API keys in the project. If there is an unrestricted key, the attacker will gain full access to the project. |
Permissive Access | IAM with Set IAM policy permission on the project | A GCP Identity with permissions to set an IAM policy for the project. | An attacker with the setIamPolicy on a project will be able to modify the IAM policy of the resource, granting himself additional privileges. This method could lead to full administrator access to the project. |
Permissive Access | IAM with Sign service account blob permission | A GCP Identity with permission to sign a blob. | An attack with the iam.serviceAccounts.signBlob permission will be able to create a signed blob that requests an access token from a specified service account. Depending on the service account's permissions, this method could range from no privilege escalation to full administrator access to the account. |
Permissive Access | IAM with Sign service account JWT permission | A GCP Identity with permission to sign a JWT (JSON web token). | An attack with the iam.serviceAccounts.signJwt permission will be able to sign and request an access token of a specified service account. Depending on the service account's permissions, this method could range from no privilege escalation to full administrator access to the account. |
Permissive Access | IAM with Update cloud function with service account permission | A GCP identity with permissions to update an existing cloud function and its assigned service account. | An attacker with the iam.serviceAccounts.actAs, cloudfunctions.functions.update and cloudfunctions.functions.sourceCodeSet permissions will be able to update an existing cloud function and even switch its service account to a function that accesses the metadata API and retrieves the associated service account's access token. This method could range from no privilege escalation to full access to the project, depending on the service account's permissions. |
Permissive Access | IAM with Update IAM Role permission | A GCP Identity with permissions to update an IAM role. | An attacker with the iam.role.updatepermission and a custom role assigned will be able to add permissions to the role, and by that gain more privileges or even full privileges on the project. |
Permissive Access | Service Account With Editor Role | Service Account with editor permissions on the project. | An attacker with access to the service account will be able to perform most of the actions in the project. |
Permissive Access | Service Account With Owner Role | Service Account with owner permissions on the project. | An attacker with access to the service account will be able to perform any action in the project. |
Permissive Access | User With Editor Role | User with editor permissions on the project. | An attacker with access to the user will be able to perform most of the actions in the project. |
Permissive Access | User With Owner Role | User with owner permissions on the project. | An attacker with access to the user will be able to perform any action in the project. |
Insecure Configurations | Project With Interactive Serial Console Enabled | Project VM interactive serial console is enabled and does not support IP-based access restrictions. | Attacker can attempt to connect to the instance's serial console from any IP address. |
Pub/Sub
Pub/Sub
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Identity & Access Management | Compute Engine Instance Default Service Account With Owner Role | Compute Engine default service account with owner permissions on the project. | An attacker with access to a compute engine that is attached to the default service account will have full access to the project. |
Identity & Access Management | Compute Instance Default Service Account With Editor Role | Compute Engine default service account with editor permissions on the project. | An attacker with access to a compute engine that is attached to the default service account will be able to perform unauthorized actions in your project. |
Identity & Access Management | Service Account With Editor Role | Service Account with editor permissions on the project. | An attacker with access to the service account will be able to perform most of the actions in the project. |
Identity & Access Management | Service Account With Owner Role | Service Account with owner permissions on the project. | An attacker with access to the service account will be able to perform any action in the project. |
Identity & Access Management | User With Editor Role | User with editor permissions on the project. | An attacker with access to the user will be able to perform most of the actions in the project. |
Identity & Access Management | User With Owner Role | User with owner permissions on the project. | An attacker with access to the user will be able to perform any action in the project. |
Insecure Configurations | Pub/Sub Topic Without Customer Managed Encryption Key (CMEK) | Pub/Sub topic without customer-managed encryption key (CMEK). | With no customer-managed encryption key (CMEK), an attacker can manage message encryption and decryption process. |
IAM (Identity and Access Management)
IAM (Identity and Access Management)
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Identity & Access Management | IAM principal with set IAM policy permission on service accounts | A GCP Identity with permissions to set an IAM policy for service accounts. | An attacker with the setIamPolicy on a service account will be able to modify the IAM policy of the resource, granting himself additional privileges at the resource level. If this permission is given at the project level, the attacker will be able to change all the project service accounts' policies and give himself access to the strongest ones. This method could range from full access to a specific resource to full administrator access to the project depending on the permissions of the service account. |
Identity & Access Management | IAM with Create service account key permission | A GCP Identity with permissions to create a service account key. | An attacker with the iam.serviceAccountKeys.create permission can create a user-managed key for a Service Account that will allow him to access GCP as that Service Account. This method could range from no privilege escalation to full access to the project, depending on the service account's permissions. |
Identity & Access Management | IAM with Get service account access token permission | A GCP Identity with permissions to get a service account's access token | An attack with the iam.serviceAccounts.getAccessToken permission will be able to get an access token that belongs to a specified service account and gain its permissions. Depending on the service account's permissions, this method could range from no privilege escalation to full administrator access to the account. |
Identity & Access Management | IAM with Sign service account blob permission | A GCP Identity with permission to sign a blob. | An attack with the iam.serviceAccounts.signBlob permission will be able to create a signed blob that requests an access token from a specified service account. Depending on the service account's permissions, this method could range from no privilege escalation to full administrator access to the account. |
Identity & Access Management | IAM with Sign service account JWT permission | A GCP Identity with permission to sign a JWT (JSON web token). | An attack with the iam.serviceAccounts.signJwt permission will be able to sign and request an access token of a specified service account. Depending on the service account's permissions, this method could range from no privilege escalation to full administrator access to the account. |
Cloud SQL
Cloud SQL
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Insecure Configurations | Cloud PostgreSQL Instance Without 'point-in-time' Recovery | PostgreSQL instance without point-in-time recovery. | Point-in-time recovery helps you recover an instance to a specific point in time. For example, if an error causes a loss of data, you can recover a database to its state before the error occurred. |
Insecure Configurations | Cloud SQL Instance Connection Logs Disabled | SQL instance without connection logs enabled. | The "log_connections" flag causes each attempted connection to the server to be logged, as well as successful completion of both client authentication (if necessary) and authorization. By default this option is set to "off", allowing attackers to login to the instance without leaving a trace. |
Insecure Configurations | Cloud SQL Instance Without Automatic Backup | SQL instance without automatic backup configuration. | Backups protect your data from loss or damage. |
Insecure Configurations | Cloud SQL Instance Without SSL Encryption | SQL instance without SSL encryption configured. | |
Insecure Configurations | GCP PostgreSQL Instance Flag 'cloudsql.allowpasswordless local_connections' is On | Setting the "cloudsql.allowpasswordless local_connections" to 'on' enables local connections without a password. | An attacker gains access to the local network and connect to a user since there is no need for a password. |
Insecure Configurations | GCP PostgreSQL Instance Flag 'cloudsql.iam_authentication' is Off | Turning off 'cloudsql.iam_authentication' in GCP PostgreSQL relies solely on traditional authentication, potentially weakening IAM security integration. | An attacker who gains access to database credentials could potentially impersonate a user without the added security of IAM authentication checks. This could lead to unauthorized data access, manipulation, or even malicious actions within the database, compromising data security. |
Insecure Configurations | Gcp Sql Instance Flag 'check_proxy_users' is Off | 'check_proxy_users' flag off in GCP SQL risks unauthorized access by proxy users, compromising security. | An attacker who gains access to a proxy user's credentials could potentially impersonate the proxy user without proper authentication checks. This could allow the attacker to perform unauthorized actions, access sensitive data, and potentially exploit the lack of authentication verification to compromise the integrity and security of the database. |
Insecure Configurations | GCP SQL Instance Flag 'default_password_lifetime' is set to 0 | Setting 'default_password_lifetime' to 0 in GCP SQL risks prolonged use of unchanged passwords, heightening the potential for unauthorized access and security breaches. | An attacker could gain access to a user's password and maintain unauthorized access indefinitely without password expiration. This increases the likelihood of undetected and prolonged data breaches. |
Insecure Configurations | Gcp SQL Instance Flag 'disconnect_on_expired_password' is Off | Turning 'disconnect_on_expired_password' off in GCP SQL allows users with expired passwords continued access, risking unauthorized and insecure access. | An attacker who obtains the login credentials of a user with an expired password could continue to access the database. This could lead to unauthorized data manipulation, data theft, or even malicious actions within the database, compromising data security and integrity. |
Insecure Configurations | GCP SQL Instance Flag 'local_infile' is On | 'local_infile' flag in GCP SQL increases risk of data exposure and unauthorized access via local file loading. | An attacker with access to the database could potentially exploit the feature to load malicious files from their local system into the database. |
Insecure Configurations | GCP SQL Instance Flag 'mysqlnative_password proxy_users' is Off | This variable controls whether the mysql_native_password built-in authentication plugin supports proxy users. It has no effect unless the check_proxy_users system variable is enabled. | An attacker who gains access to a proxy user account is not authorized and connects to the account. |
Insecure Configurations | GCP SQL Instance Flag 'password_require_current' is Off | A GCP SQL instance "password_require_current" flag is set to "off". | An attacker, taking advantage of the flag being off, changes a password without the need to know the old password, thereby gaining access to the account. |
Insecure Configurations | GCP SQL Instance Flag 'skip_show_database' is Off | Turning 'skip_show_database' off in GCP SQL risks exposing database and schema details, facilitating unauthorized enumeration and targeted attacks. | An attacker could potentially use the SHOW DATABASES command to enumerate available databases and gain insights into the database schema. This knowledge could aid them in crafting more effective and targeted attacks. |
Insecure Configurations | GCP SQL is Not Using CMK | GCP SQL instance without CMK. | In a scenario where a GCP SQL instance is not using Customer-Managed Keys (CMK), an attacker who gains unauthorized access to Google's managed encryption keys or exploits vulnerabilities in Google's key management infrastructure could potentially decrypt and access sensitive data stored in the SQL database, leading to data breaches and confidentiality breaches. |
Insecure Configurations | GCP SQL Without Password Policy | No password policy in GCP SQL increases the risk of weak passwords and unauthorized access, compromising data security. | An attacker could potentially perform brute-force attacks or use common passwords to guess weak passwords associated with the database, granting them unauthorized access to the data and compromising the security and integrity of the system. |
Public Exposure | Cloud SQL Instance Allows Network Connection From Any IP (0.0.0.0/0) | SQL instance with an authorized network of 0.0.0.0/0 | This prefix will allow any IPv4 client to pass the network firewall and make login attempts to your instance, including clients you did not intend to allow. |
Public Exposure | GCP SQL is Not Using Private Ip | GCP SQL instance is Not Using Private Ip. | Without a private IP in GCP SQL, an attacker could potentially intercept sensitive database traffic over the public network, leading to data exposure. |
Storage Bucket
Storage Bucket
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Data Security | Cloud Storage Bucket Contains Potentially Public Objects | This risk identifies a Google Cloud Storage bucket that contains objects that may be publicly accessible, thereby potentially enabling any internet user to access them. Potentially shared objects in a storage bucket can heighten the risk of unauthorized data access and potential data breaches. It's recommended to review these objects and their access controls, and if public access is not required, promptly update their permissions to secure your data. | An attacker can maybe access some objects in the bucket leading to data exposure. |
Data Security | Storage Bucket Publicly Accessible | This risk points to a Google Cloud Storage bucket configured as publicly accessible, potentially making it reachable by any internet user. Publicly accessible storage buckets can significantly increase the risk of unauthorized data access and potential data breaches. It's recommended to verify whether such public access is necessary and, if not, promptly restrict access to strengthen your data security. | An attacker can access this bucket and compromise your data. |
Data Security | Storage Bucket Without Encryption | This risk signifies a Google Cloud Storage bucket that lacks encryption, a critical security measure to protect sensitive data from unauthorized access. Unencrypted Storage buckets can raise the risk of data exposure or misuse. It's strongly advised to enable encryption to safeguard your data and comply with security best practices and regulations. | An attacker can access this bucket and compromise your data |
Identity & Access Management | IAM principal with set IAM policy permission on storage buckets | A GCP Identity with permissions to set an IAM policy for storage buckets. | An attacker with the setIamPolicy on a storage bucket will be able to modify the IAM policy of the bucket, granting himself additional privileges at the resource level. If this permission is given at the project level, the attacker will be able to change all the project buckets' policies. This method could range from full access to a specific bucket to full storage access to the project. |
Identity & Access Management | Service Account With Editor Role | Service Account with editor permissions on the project. | An attacker with access to the service account will be able to perform most of the actions in the project. |
Identity & Access Management | Service Account With Owner Role | Service Account with owner permissions on the project. | An attacker with access to the service account will be able to perform any action in the project. |
Identity & Access Management | User With Editor Role | User with editor permissions on the project. | An attacker with access to the user will be able to perform most of the actions in the project. |
Identity & Access Management | User With Owner Role | User with owner permissions on the project. | An attacker with access to the user will be able to perform any action in the project. |
Oracle Cloud Infrastructure (OCI) - click to collapse
Oracle Cloud Infrastructure (OCI)
Click on a service name below to view a table of the risks Panoptica detects in OCI, along with brief descriptions and attack scenarios.
DB System
DB System
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Data Security | Oracle Autonomous Databases Publicly Accessible | Autonomous database with a cidr address of 0.0.0.0/0. | An attacker might be able to access the database from any IP address. |
Data Security | Oracle Database Auto Backup Disabled | Database without automatic backup configuration. | It is a best practice to enable continuous backups for your databases. |
Data Security | Oracle Database Without Encryption | Unencrypted database. | An attacker can access the data stored in your database. |
Insecure Configurations | Autonomous Oracle Database Without mTLS | mTLS is not required for the database. | mTLS helps ensure that traffic is secure and trusted in both directions between a client and server. |
Policy
Policy
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Identity & Access Management | Administator permissions over tenancy | Administator access over tenancy. | An attacker with administrator permissions can perform any action on any resource in the environment. |
Identity & Access Management | Manage cluster-family permission in compartment | Permission to manage cluster-family in compartment. | An attacker with manage cluster-family access has full access to container engine for kubernetes resources in the compartment. |
Identity & Access Management | Manage cluster-family permission in tenancy | Permission to manage cluster-family in tenancy. | An attacker with manage cluster-family access has full access to container engine for kubernetes resources in tenancy. |
Identity & Access Management | Manage database-family permission in compartment | Permission to manage database-family in compartment. | An attacker with manage database-family access has full access to database resources in the compartment. |
Identity & Access Management | Manage database-family permission in tenancy | Permission to manage database-family in tenancy. | An attacker with manage database-family access has full access to database resources in tenancy. |
Identity & Access Management | Manage DNS permission in compartment | Permission to manage DNS in compartment. | An attacker with manage DNS access has full access to DNS resources in the compartment. |
Identity & Access Management | Manage DNS permission in tenancy | Permission to manage DNS in tenancy. | An attacker with manage DNS access has full access to DNS resources in tenancy. |
Identity & Access Management | Manage instance-family permission in compartment | Permission to manage instance-family in compartment. | An attacker with manage instance-family access has full access to instance resources in the compartment. |
Identity & Access Management | Manage instance-family permission in tenancy | Permission to manage instance-family in tenancy. | An attacker with manage instance-family access has full access to instance resources in tenancy. |
Identity & Access Management | Manage object-family permission in compartment | Permission to manage object-family in compartment. | An attacker with manage object-family access has full access to bucket and object resources in the compartment. |
Identity & Access Management | Manage object-family permission in tenancy | Permission to manage object-family in tenancy. | An attacker with manage object-family access has full access to buckets and objects resources in tenancy. |
Identity & Access Management | Manage policies permission in tenancy | Permission to manage policies in tenancy. | An attacker with 'manage' permission over policies in the tenancy can exploit this permission and perform privilege escalation by creating a policy with higher permissions and assign its group to be part of it. |
Identity & Access Management | Manage users permission in tenancy | Permission to manage users in tenancy. | An attacker with 'manage' users permission can perform any action on users in the environment such as resetting passwords, leading to privilege escalation. |
Identity & Access Management | Use all resources permission in tenancy | Permission to use all resources in tenancy. | An attacker with 'use' permission over all resources in the tenancy can exploit this permission and perform privilege escalation. |
Storage Bucket
Storage Bucket
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Data Security | Object Storage Bucket Publicly Accessible | This risk identifies an Oracle Cloud Storage bucket configured to be publicly accessible, potentially making it reachable by any internet user. Publicly accessible buckets significantly raise the risk of unauthorized data access and potential data breaches. It's recommended to ascertain the necessity of such public access, and if it's not required, promptly restrict access to bolster your data security. | An attacker can access the bucket and objects leading to data exposure. |
Data Security | Object Storage Bucket Without Encryption | This risk indicates an Oracle Cloud Storage bucket not configured for encryption, a vital security measure to safeguard sensitive data from unauthorized access. Unencrypted buckets can increase the risk of data exposure or misuse. It's strongly recommended to enable encryption to secure your data and adhere to security best practices and compliance regulations. | An attacker can access this bucket and compromise stored data. |
User
User
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Identity & Access Management | User Without MFA | This risk highlights an Oracle Cloud user who doesn't have Multi-Factor Authentication (MFA) enabled. MFA offers an added layer of security by requiring more than just a password for user authentication. An absence of MFA exposes the user's account to a heightened risk of unauthorized access. It's strongly advised to enable MFA for all users to strengthen account security within Oracle Cloud. | An attacker can bypass authentication with a password only. |
Kubernetes - click to collapse
Kubernetes
Click on a service name below to view a table of the risks Panoptica detects in Kubernetes clusters, along with brief descriptions and attack scenarios.
API Endpoint
API Endpoint
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Public Exposure | Publicly Exposed Asset | Public API endpoint with authentication issues that has a PII in the response. | An attacker can leverage the authentication issue to access the endpoint and obtain the PII returned in the response. |
Cluster Role
Cluster Role
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Identity & Access Management | Cluster Role With Attach Pods Permissions | OWASP K03:2022 Overly Permissive RBAC Configurations | |
Identity & Access Management | Cluster Role With Create CronJobs Permissions | A cluster role that allows to create cronjobs in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | |
Identity & Access Management | Cluster Role With Create DaemonSets Permissions | A cluster role that allows to create daemonsets in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | |
Identity & Access Management | Cluster Role With Create Deployments Permissions | A cluster role that allows to create deployments in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | |
Identity & Access Management | Cluster Role With Create Jobs Permissions | A cluster role that allows to create jobs in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | |
Identity & Access Management | Cluster Role With Create Mutating Webhook Configuration Permissions | A cluster role that allows create mutating webhook configurations resource in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized. |
Identity & Access Management | Cluster Role with Create or Wildcard Permissions to the LocalSubjectAccessReview Resource | A Cluster role with Create or Wildcard Permissions to the LocalSubjectAccessReview Resource. | An attacker with access to this cluster role can map users and their associated permissions within a namespace in the cluster. |
Identity & Access Management | Cluster Role with Create or Wildcard Permissions to the SubjectAccessReview Resource | A Cluster role with Create or Wildcard Permissions to the SubjectAccessReview Resource. | An attacker with access to this cluster role can map users and their associated permissions within the cluster. |
Identity & Access Management | Cluster Role with Create or Wildcard Permissions to the TokenRequest Resource | A Cluster role with Create or Wildcard Permissions to the TokenRequest Resource. | An attacker with access to this cluster role can request tokens for any service account in the cluster. Service account tokens are used to authenticate requests to the Kubernetes API server, and if an attacker has access to those tokens, they can use them to impersonate service accounts and gain access to privileged resources and actions. This could give the attacker the ability to modify or delete any resource in the cluster, potentially leading to a full compromise of the cluster. |
Identity & Access Management | Cluster Role With Create ReplicaSets Permissions | A cluster role that allows to create replicasets in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | |
Identity & Access Management | Cluster Role With Create Replication Controllers Permissions | A cluster role that allows to create replicationcontrollers in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | |
Identity & Access Management | Cluster Role With Create RoleBinding Permissions | A cluster role that allows to create a role binding to any role in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | An attacker can leverage this permission to create a binding between its identity and a strong role in the cluster. |
Identity & Access Management | Cluster Role With Create RoleBinding/ClusterRoleBinding Permissions | A cluster role in Kubernetes with permission to create a cluster role binding. OWASP K03:2022 Overly Permissive RBAC Configurations | An attacker with access to that cluster role can escalate his privileges by binding the service account or user to the cluster-admin cluster role or a different cluster role with higher permissions. |
Identity & Access Management | Cluster Role With Create StatefulSets Permissions | A cluster role that allows to create statefulsets in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | |
Identity & Access Management | Cluster Role With Create Validating Webhook Configuration Permissions | A cluster role that allows create validating webhook configurations resource in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized. |
Identity & Access Management | Cluster Role With Delete Deployments Permissions | A cluster role that allows to delete deployments in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | |
Identity & Access Management | Cluster Role With Delete Mutating Webhook Configuration Permissions | A cluster role that allows delete mutating webhook configurations resource in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized. |
Identity & Access Management | Cluster Role With Delete Namespaces Permissions | Cluster role with delete namespaces in cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | Attacker with delete namespace permission can delete any namespace in the cluster include the running pods in the namespace. |
Identity & Access Management | Cluster Role With Delete Validating Webhook Configuration Permissions | A cluster role that allows delete validating webhook configurations resource in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized. |
Identity & Access Management | Cluster Role With Delete/DeleteCollection Secrets Permissions | A cluster role that allows to delete or deletecollection secrets in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | |
Identity & Access Management | Cluster Role With Exec Pods Permissions | OWASP K03:2022 Overly Permissive RBAC Configurations | |
Identity & Access Management | Cluster Role with Full Permissions to any Resources on Non-K8s Core or Wildcard API Groups | A cluster role has full permissions for any resource on API groups other than wildcard or the K8s core API. | An attacker with access to this cluster role can perform any action against the API groups defined in this cluster role. Possibly escalate his privileges and move laterally within the cluster. |
Identity & Access Management | Cluster Role with Get and Create Permissions to the Nodes/Proxy Resource | A cluster role with Get and Create permissions to the nodes/proxy resource. | An attacker that has access to a principal with the Get, Create permissions on the nodes/proxy resource can communicate with the Node’s Kubelet API directly and possibly escalate it's privileges to a cluster admin. |
Identity & Access Management | Cluster Role With Patch Mutating Webhook Configuration Permissions | Cluster role with patch mutating webhook configuration in cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized. |
Identity & Access Management | Cluster Role With Patch Validating Webhook Configuration Permissions | Cluster role with patch validating webhook configuration in cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized. |
Identity & Access Management | Cluster Role with Permissions to Change Configmaps | A cluster role that allows to update or patch configmaps in the cluster. | An attacker with access to this cluster role can alter configmaps in the cluster. |
Identity & Access Management | Cluster Role with Permissions to Change Service Accounts | A cluster role with permissions to change service accounts. | An attacker with access to this cluster role can alter service accounts in the cluster. |
Identity & Access Management | Cluster Role with Permissions to Create Configmaps | A cluster role that allows to create configmaps in the cluster. | An attacker with access to this cluster role can create configmaps in the cluster. |
Identity & Access Management | Cluster Role with Permissions to Create Nodes | A cluster role with permissions to create nodes. | An attacker with access to this cluster role can create nodes in the cluster. |
Identity & Access Management | Cluster Role with Permissions to Create Service Accounts | A cluster role with permissions to create service accounts. | An attacker with access to this cluster role can create service acconts in the cluster. |
Identity & Access Management | Cluster Role with Permissions to Delete Configmaps | A cluster role that allows to delete configmaps in the cluster. | An attacker with access to this cluster role can delete configmaps in the cluster. |
Identity & Access Management | Cluster Role with Permissions to Delete Nodes | A cluster role with permissions to delete nodes. | An attacker with access to this cluster role can delete nodes in the cluster. |
Identity & Access Management | Cluster Role with Permissions to Delete Service Accounts | A cluster role with permissions to delete service accounts. | An attacker with access to this cluster role can delete service accounts in the cluster. |
Identity & Access Management | Cluster Role with Permissions to Read Configmaps | A cluster role with permissions to read or list Configmaps. | An attack with access to this cluster role can read or list configmaps in the cluster. |
Identity & Access Management | Cluster Role with Permissions to Read Service Accounts | A cluster role with permissions to read service accounts. | An attacker with access to this cluster role can read service accounts in the cluster. |
Identity & Access Management | Cluster Role with Permissions to Update Nodes | A cluster role with permissions to update nodes. | An attacker with access to this cluster role can update nodes in the cluster. |
Identity & Access Management | Cluster Role With Update CronJobs Permissions | A cluster role that allows to update cronjobs in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | |
Identity & Access Management | Cluster Role With Update DaemonSets Permissions | A cluster role that allows to update daemonsets in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | |
Identity & Access Management | Cluster Role With Update Deployments Permissions | A cluster role that allows to update deployments in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | |
Identity & Access Management | Cluster Role With Update Jobs Permissions | A cluster role that allows to update jobs in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | |
Identity & Access Management | Cluster Role With Update ReplicaSets Permissions | A cluster role that allows to update replicasets in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | |
Identity & Access Management | Cluster Role With Update Replication Controllers Permissions | A cluster role that allows to update replicationcontrollers in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | |
Identity & Access Management | Cluster Role With Update StatefulSets Permissions | A cluster role that allows to update statefulsets in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | |
Identity & Access Management | Cluster Role With Update\Patch Secrets Permissions | A cluster role that allows to update or patch secrets in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | |
Identity & Access Management | Cluster Role With View Secrets Permissions | A cluster role that allows to list and view all secrets in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | Once there is a single account in the cluster with the cluster-admin role binding, an attacker with access to that cluster role can steal the admin’s token and escalate his privileges to the highest cluster privileges. |
Identity & Access Management | Cluster Role With View Secrets Permissions | A cluster role that allows to get any secret in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | An attacker can leverage this permission to obtain a secret value and move lateraly inside the cluster. |
Identity & Access Management | Cluster Role With Wildcard Create Permissions | A cluster role that allows to create any resource in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | |
Identity & Access Management | Cluster Role With Wildcard CronJobs Permission | A cluster role that allows to perform any action on cronjobs in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | |
Identity & Access Management | Cluster Role With Wildcard DaemonSets Permissions | A cluster role that allows to perform any action on daemonsets in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | |
Identity & Access Management | Cluster Role With Wildcard Delete Collection Permissions | A cluster role that allows to deletecollection of any resource in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | |
Identity & Access Management | Cluster Role With Wildcard Delete Permissions | A cluster role that allows to delete any resource in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | |
Identity & Access Management | Cluster Role With Wildcard Deployments Permissions | A cluster role that allows to perform any action on deployments in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | |
Identity & Access Management | Cluster Role With Wildcard Impersonate Permissions | A cluster role that allows to impersonate any resource in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | |
Identity & Access Management | Cluster Role With Wildcard Jobs Permission | A cluster role that allows to perform any action on jobs in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | |
Identity & Access Management | Cluster Role With Wildcard List Permissions | A cluster role that allows to list any resource in the Kubernetes cluster, including secrets. OWASP K03:2022 Overly Permissive RBAC Configurations | An attacker with access to this cluster role can escalate privileges by listing powerful secrets and using their value. It is possible to obtain a secret token belongs to a service account with cluster-admin privileges. |
Identity & Access Management | Cluster Role With Wildcard Mutating Webhook Configurations Permissions | A cluster role that allows any action on mutating webhook configurations resource in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized |
Identity & Access Management | Cluster Role with Wildcard Permissions to any Resources on Non-K8s Core or Wildcard API Groups | A cluster role with wildcard permissions for any resource on API groups other than wildcard or the K8s core API. | An attacker with access to this cluster role can perform any action against the API groups defined in this cluster role. Possibly escalate his privileges and move laterally within the cluster. |
Identity & Access Management | Cluster Role With Wildcard Pods Permissions | A cluster role that allows to perform any action on pods in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | |
Identity & Access Management | Cluster Role With Wildcard ReplicaSets Permission | A cluster role that allows to perform any action on replicasets in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | |
Identity & Access Management | Cluster Role With Wildcard Replication Controllers Permission | A cluster role that allows to perform any action on replicationcontrollers in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | |
Identity & Access Management | Cluster Role With Wildcard Secrets Permissions | A cluster role with a wildcard in the verbs section on secrets resource. OWASP K03:2022 Overly Permissive RBAC Configurations | An attacker with access to that cluster role can view or edit all secrets in the cluster, and escalate his privileges using different methods to take over the cluster control by getting an admin secret. |
Identity & Access Management | Cluster Role With Wildcard StatefulSets Permissions | A cluster role that allows to perform any action on statefulsets in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | |
Identity & Access Management | Cluster Role With Wildcard Validating Webhook Configurations Permissions | A cluster role that allows any action on validating webhook configurations resource in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | |
Identity & Access Management | Cluster Role With Wildcard Verbs Permissions | A cluster role with a wildcard in the verbs section. OWASP K03:2022 Overly Permissive RBAC Configurations | An attacker with access to that cluster role can execute any action against the resources defined in that cluster role, and escalate his privileges using different methods to take over the cluster control. |
Identity & Access Management | Cluster Role With Wildcard View Permissions | A cluster role that allows to get any resource in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations | |
Identity & Access Management | User With Impersonate Group Permissions | A user with permission to Impersonate a group. OWASP K03:2022 Overly Permissive RBAC Configurations | An attacker with access to a service account with permissions to impersonate a privileged group may escalate his privileges to gain higher access permissions in the cluster. |
Cluster Role Binding
Cluster Role Binding
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Identity & Access Management | Cluster Role Binding Allows Unauthenticated Access | ClusterRoleBinding with 'system:unauthenticated' group allow to users are related to this group to perform the actions in the matched role. OWASP K03:2022 Overly Permissive RBAC Configurations | Attacker can perform action in the cluster without to authenticate. |
Identity & Access Management | Cluster role binding of service account to wildcard cluster role | OWASP K03:2022 Overly Permissive RBAC Configurations |
Deployment
Deployment
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Insecure Configurations | Kubernetes Dashboard With 'enable-skip-login'' Enabled | Kubernetes-dashboard was found with an "enable-skip-login" parameter enabled.While this parameter is enabled, Users can access the Kubernetes-dashboard without providing authentication details. OWASP K09:2022 Misconfigured Cluster Components | An attacker with network access to the Kubernetes-dashboard can take advantage of this configuration and get information about the cluster and its workloads. |
Pod
Pod
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Credentials Exposure | Container With Mounted Secret | K8s secret is mounted inside a container path. OWASP K01:2022 Insecure Workload Configurations | An attacker might use the secret value to laterally move inside the K8s cluster. |
Insecure Configurations | Container Running As Root Group | Container running as root group. OWASP K01:2022 Insecure Workload Configurations | An attacker with access to the container can use different methods to escape the container and have root privileges on the host. |
Insecure Configurations | Container Running As Root User | Container running as root user. OWASP K01:2022 Insecure Workload Configurations | An attacker with access to the container can use different methods to escape the container and have root privileges on the host. |
Insecure Configurations | Container With '/etc' Path Mounted | A container with a risky hostPath mount - mount to the /etc folder in the host filesystem. OWASP K01:2022 Insecure Workload Configurations | An attacker with access to that container can access the host's sensitive information and secret configuration in the host filesystem. |
Insecure Configurations | Container With '/root' Path Mounted | A container with a risky hostPath mount - mount to the host /root folder. OWASP K01:2022 Insecure Workload Configurations | An attacker with access to that container can access the host's sensitive information and other containers running on the same host. |
Insecure Configurations | Container With '/var' Path Mounted | A container with a risky hostPath mount - mount to the host /var folder. OWASP K01:2022 Insecure Workload Configurations | An attacker with access to that container can access the host's sensitive information and other containers running on the same host. |
Insecure Configurations | Container With '/var/lib/kubelet/pods' Path Mounted | A container with a risky hostPath mount - mount to the host /var/lib folder. OWASP K01:2022 Insecure Workload Configurations | An attacker with access to that container can access the host's sensitive information and other containers running on the same host. |
Insecure Configurations | Container With AllowPrivilegeEscalation | Container running with AllowPrivilegeEscalation flag set to true. OWASP K01:2022 Insecure Workload Configurations | The allowPrivilegeEscalation is part of the Pod Security Policy Parameters. The allowPrivilegeEscalation Gates whether or not a user is allowed to set the security context to allowPrivilegeEscalation=true in a container. This defaults to allowed so as not to break setuid binaries. An attacker with access to the container can gain more privileges than the container parent. |
Insecure Configurations | Container With Full File System Mounted | A container with mount of root directory. OWASP K01:2022 Insecure Workload Configurations | An attacker with access to that container can access the host and escape the container to gain higher privileges. |
Insecure Configurations | Container With Privileged Mode | Container running in privileged mode. OWASP K01:2022 Insecure Workload Configurations | An attacker with access to the container can access all devices on the host. |
Insecure Configurations | Container With Risky Path Mounted | A container with a risky hostPath mount - mount to the azure.json file. OWASP K01:2022 Insecure Workload Configurations | An attacker with access to that container can access the host configuration file and use its service principal credentials to escalate his Azure subscription privileges. |
Insecure Configurations | Container With CAP_SYS_ADMIN+K60 | Container with CAP_SYS_ADMIN capability. OWASP K01:2022 Insecure Workload Configurations | CAP_SYS_ADMIN its capability that allow some sensetive action like mount, without any enabled security application attacker can get access to the host. |
Insecure Configurations | Container Without Protection Against Root Privileged | Pod configuration without limition of user permission. No definition of runAsUser and runAsNonRoot values in securityContext. OWASP K01:2022 Insecure Workload Configurations | Attacker with access to the cluser can execute command inside container with root permmisions, also attacker can leverege his permissions to container escapes. |
Insecure Configurations | Container Without Read Only Filesystem | Container without read-only file system. Read-only filesystems are a key component to preventing container breakout. OWASP K01:2022 Insecure Workload Configurations | A malicious process or application can write back to the host system. |
Insecure Configurations | Container Without Resource Limits | A container without resource limits. OWASP K01:2022 Insecure Workload Configurations | An attacker with access to a container without resource limits may cause a denial of service for the hosts it's running on. |
Insecure Configurations | Pod With Apparmor Disabled | OWASP K01:2022 Insecure Workload Configurations | |
Insecure Configurations | Pod With 'docker.sock' Mounted | Container with docker.sock mounted. OWASP K01:2022 Insecure Workload Configurations | Attacker with access to container that has docker.sock mounted can run any container on the node, perform container escape, privilege escalation or lateral movements. |
Insecure Configurations | Pod With Full Capabilities | Pod gets all capabilities. OWASP K01:2022 Insecure Workload Configurations | Attacker with access to pod with all capabilities can leverage for container escape. |
Insecure Configurations | Pod With Log4j Vulnerable Hotpatch | AWS Hotpatch for Log4j Vulnerablity. This Hotpatch could be leveraged for container escape and privileged escalation OWASP K10:2022 Outdated and Vulnerable Kubernetes Components | An attacker can perform conainer escape and get access to underlying host from every container in your cluster. Also, unprivileged processes can exploit the Hotpatch to escalate privileges and gain root code execution. |
Insecure Configurations | Pod With '/proc' hostPath Mounted | A pod with a risky hostPath mount - mount to the host /proc directory. OWASP K01:2022<a href=""https://github.com/OWASP/www-project-kubernetes-top-ten/blob/main/2022/en/src/K01-insecure-workload-configurations.md""Insecure> Workload Configurations | Mounting the '/proc' host path could allow an attacker to modify kernel variables, access sensitive data and even container escape. |
Insecure Configurations | Pod With 'containerd.sock' Mounted | A pod with a risky hostPath mount - mount to the host /var/run/containerd/containerd.sock socket. OWASP K01:2022<a href=""https://github.com/OWASP/www-project-kubernetes-top-ten/blob/main/2022/en/src/K01-insecure-workload-configurations.md""Insecure> Workload Configurations | An attacker with access to a worker node's 'containerd.sock' socket can interact with the containerd daemon. This would allow him to list and terminate running containers, resulting in a denial of service (DoS). |
Insecure Configurations | Pod With '/dev' hostPath Mounted | A pod with a risky hostPath mount - mount to the host /dev directory. OWASP K01:2022<a href=""https://github.com/OWASP/www-project-kubernetes-top-ten/blob/main/2022/en/src/K01-insecure-workload-configurations.md""Insecure> Workload Configurations | Mounting the '/dev' host path could allow an attacker to access to host's devices and even to breakout of the container. |
Insecure Configurations | Pod With '/sys' hostPath Mounted | A pod with a risky hostPath mount - mount to the host /sys directory. OWASP K01:2022<a href=""https://github.com/OWASP/www-project-kubernetes-top-ten/blob/main/2022/en/src/K01-insecure-workload-configurations.md""Insecure> Workload Configurations | Mounting the '/sys' host path could allow an attacker to modify kernel variables, access sensitive data and even container escape. |
Role
Role
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Identity & Access Management | Cluster Role With View Secrets Permissions In Namespace | A role that allows to get secrets in the namespace. OWASP K03:2022 Overly Permissive RBAC Configurations | An attacker can leverage this permission to obtain a secret value and move laterally inside the cluster. |
Identity & Access Management | Role With Admin Permissions | A role with a wildcard in the verbs section. OWASP K03:2022 Overly Permissive RBAC Configurations | An attacker with access to that role can execute any action against the resources defined in that role, and escalate his privileges using different methods in the namespace. |
Role Binding
Role Binding
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Identity & Access Management | Role Binding Allows Anonymous Access | RoleBinding with 'system:anonymous' user allow to unauthenticated users to perform the actions in the role. | Attacker can perform action in the specific namespace without to authenticate. |
Identity & Access Management | Role Binding Allows Unauthenticated Access | RoleBinding with 'system:unauthenticated' group allow to users are related to this group to perform the actions in the matched role. OWASP K03:2022 Overly Permissive RBAC Configurations | Attacker can perform action in the specific namespace without to authenticate. |
Identity & Access Management | Role Binding To Default Service Account | OWASP K03:2022 Overly Permissive RBAC Configurations |
Source Code Management (SCM) - click to collapse
Source Code Management (SCM)
Click on a service name below to view a table of the risks Panoptica detects in your source code, along with brief descriptions and attack scenarios.
GitHub Organization
GitHub Organization
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Insecure Configurations | Two-Factor Authentication Should Be Enforced For The Organization | The two-factor authentication requirement is not enabled at the organization level. Regardless of whether users are managed externally by SSO, it is highly recommended to enable this option to reduce the risk of a deliberate or accidental user creation without MFA. | If an attacker gets the valid credentials for one of the organization’s users they can authenticate to your GitHub organization. |
Insecure Configurations | Default Workflow Token Permission Should Be Read Only | The default GitHub Action workflow token permission is set to read-write. When creating workflow tokens, it is highly recommended to follow the Principle of Least Privilege and force workflow authors to specify explicitly which permissions they need. | In case of token compromise (due to a vulnerability or malicious third-party GitHub actions), an attacker can use this token to sabotage various assets in your CI/CD pipeline, such as packages, pull-requests, deployments, and more. |
Insecure Configurations | Organization Webhooks Should Be Configured With A Secret | Webhooks are not configured with a shared secret to validate the origin and content of the request. This could allow your webhook to be triggered by any bad actor with the URL. | Not using a webhook secret makes the service receiving the webhook unable to determine the authenticity of the request.This allows attackers to masquerade as your organization, potentially creating an unstable or insecure state in other systems. |
Insecure Configurations | Organization Should Have Fewer Than Three Owners | Organization owners are highly privileged and could create great damage if they are compromised. It is recommended to limit the number of Organizational Admins to the minimum needed (recommended maximum 3 owners). | 1. An organization has a permissive attitude and provides an owner role to all developers.2. One of the developers has decided to collaborate with an evil ransomware gang, and uses his high privileges to add a malicious external collaborator3. The malicious collaborator, being an owner, has a wide range of destructive operations he can do (e.g. remove security settings) |
Insecure Configurations | Workflows Should Not Be Allowed To Approve Pull Requests | The default GitHub Actions configuration allows for workflows to approve pull requests. This could allow users to bypass code-review restrictions. | Attackers can exploit this misconfiguration to bypass code-review restrictions by creating a workflow that approves their own pull request and then merging the pull request without anyone noticing, introducing malicious code that would go straight ahead to production. |
Insecure Configurations | Organization Should Use Single-Sign-On | It is recommended to enable access to an organization via SAML single sign-on (SSO) by authenticating through an identity provider (IdP). This allows for central account control and for timely access revocations. | Not using an SSO solution makes it more difficult to track a potentially compromised user's actions accross different systems, prevents the organization from defining a common password policy, and makes it challenging to audit different aspects of the user's behavior. |
Insecure Configurations | Runner Group Should Be Limited to Private Repositories | Workflows from public repositories are allowed to run on GitHub Hosted Runners. When using GitHub Hosted Runners, it is recommended to allow only workflows from private repositories to run on these runners. to avoid being vulnerable to malicious actors using workflows from public repositories to break into your private network. In case of inadequate security measures implemented on the hosted runner, malicious actors could fork your repository and then create a pwn-request (a pull-request from a forked repository to the base repository with malicious intentions) that create a workflow that exploits these vulnerabilities and move laterally inside your network. | Hosted runners are usually part of the organization's private network and can be easily misconfigured.If the hosted runner is insecurely configured, any GitHub user could:1. Create a workflow that runs on the public hosted runner2. Exploit the misconfigurations to execute code inside the private network |
Insecure Configurations | Only Admins Should Be Able To Create Public Repositories | The organization should be configured to prevent non-admin members creating public repositories. Creating a public repository may expose sensitive organization code, which, once exposed, may be copied, cached or stored by external parties. Therefore, it is highly recommended to restrict the option to create public repositories to admins only and reduce the risk of unintentional code exposure. NOTE: You should also verify that repositories owners can't change existing repositories visibility to be public. If allowed, a malicious user could create a private repo and change it to public. See: https://docs.github.com/en/enterprise-cloud@latest/organizations/managing-organization-settings/restricting-repository-visibility-changes-in-your-organization for further information | A member of the organization could inadvertently or maliciously make public an internal repository exposing confidential data. |
Insecure Configurations | Runner Group Should Be Limited to Selected Repositories | Not limiting the runner group to selected repositories allows any user in the organization to execute workflows on the group's runners. In case of inadequate security measures implemented on the hosted runner, malicious insider could create a repository with a workflow that exploits the runner's vulnerabilities to move laterally inside your network. | Hosted runners are usually part of the organization's private network and can be easily misconfigured.If the hosted runner is insecurely configured, any user in the organization could:1. Create a workflow that runs on the hosted runner2. Exploit the runner misconfigurations/known CVE's to execute code inside the private network |
Insecure Configurations | Organization Admins Should Have Activity In The Last 6 Months | A member with organizational admin permissions did not perform any action in the last 6 months. Admin users are extremely powerful and common compliance standards demand keeping the number of admins to a minimum. Consider revoking this member’s admin credentials by downgrading to regular user or removing the user completely. | Stale admins are most likely not managed and monitored, increasing the possibility of being compromised. |
Insecure Configurations | GitHub Actions Should Be Limited To Verified or Explicitly Trusted Actions | It is recommended to only use GitHub Actions by Marketplace verified creators or explicitly trusted actions. By not restricting which actions are permitted, developers may use actions that were not audited and may be malicious, thus exposing your pipeline to supply chain attacks. | This misconfiguration could lead to the following attack:1. Attacker creates a repository with a tempting but malicious custom GitHub Action2. An innocent developer / DevOps engineer uses this malicious action3. The malicious action has access to the developer repository and could steal its secrets or modify its content |
Insecure Configurations | Organization Webhooks Should Be Configured To Use SSL | Webhooks that are not configured with SSL enabled could expose your software to man in the middle attacks (MITM). | If SSL verification is disabled, any party with access to the target DNS domain can masquerade as your designated payload URL, allowing it freely read and affect the response of any webhook request.In the case of GitHub Enterprise Server instances, it may be sufficient only to control the DNS configuration of the network where the instance is deployed, as an attacker can redirect traffic to the target domain in your internal network directly to them, and this is often much easier than compromising an internet-facing domain. |
Insecure Configurations | Organization Members Should Have Activity In The Last 6 Months | A member did not perform any action in the last 6 months. Stale members can pose a potential risk if they are compromised. Consider removing the user's access completely. | Stale members are most likely not managed and monitored, increasing the possibility of being compromised. |
Insecure Configurations | GitHub Actions Should Be Restricted To Selected Repositories | By not limiting GitHub Actions to specific repositories, every user in the organization is able to run arbitrary workflows. This could enable malicious activity such as accessing organization secrets, crypto-mining, etc. | This misconfiguration could lead to the following attack:1. Prerequisite: the attacker is part of your GitHub organization2. Attacker creates new repository in the organization3. Attacker creates a workflow file that reads all organization secrets and exfiltrate them4. Attacker trigger the workflow5. Attacker receives all organization secrets and uses them maliciously |
Insecure Configurations | Default Member Permissions Should Be Restricted | Default repository permissions configuration is not set in the organization, thus every new repository will be accessible by default to all users. It is strongly recommended to remove the default permissions and assign them on demand. | Organization members can see the content of freshly created repositories, even if they should be restricted. |
GitHub Repository
GitHub Repository
Category | Risk Name | Description | Attack Scenario |
---|---|---|---|
Insecure Configurations | Default Branch Should Restrict Who Can Dismiss Reviews | Any user with write access to the repository can dismiss pull-request reviews. Pull-request review contains essential information on the work that needs to be done and helps keep track of the changes. Dismissing it might cause a loss of this information and should be restricted to a limited number of users. | Allowing the dismissal of reviews can promote poor and vulnerable code, as important comments may be forgotten and ignored during the review process. |
Insecure Configurations | Default Branch Should Limit Code Review to Code-Owners | It is recommended to require code review only from designated individuals specified in CODEOWNERS file. Turning this option on enforces that only the allowed owners can approve a code change. This option is found in the branch protection setting of the repository. | A pull request may be approved by any contributor with write access. Specifying specific code owners can ensure review is only done by individuals with the correct expertise required for the review of the changed files, potentially preventing bugs and security risks. |
Insecure Configurations | GitHub Advanced Security – Dependency Review Should Be Enabled For A Repository | Enable GitHub Advanced Security dependency review to avoid introducing new vulnerabilities and detect newly discovered vulnerabilities in existing packages. | A contributor may add vulnerable third-party dependencies to the repository, introducing vulnerabilities to your application that will only be detected after merge. |
Insecure Configurations | Forking Should Not Be Allowed for This Repository | Forking a repository can lead to loss of control and potential exposure of the source code. If you do not need forking, it is recommended to turn it off in the repository configuration. If needed, forking should be turned on by admins deliberately when opting to create a fork. | Forked repositories cause more code and secret sprawl in the organization as forks are independent copies of the repository and need to be tracked separately, making it more difficult to keep track of sensitive assets and contain potential incidents. |
Insecure Configurations | Default Branch Should Be Protected | Branch protection is not enabled for this repository’s default branch. Protecting branches ensures new code changes must go through a controlled merge process and allows enforcement of code review as well as other security tests. This issue is raised if the default branch protection is turned off. | Any contributor with write access may push potentially dangerous code to this repository, making it easier to compromise and difficult to audit. |
Insecure Configurations | OSSF Scorecard Score Should Be Above 7 | Scorecard is an open-source tool from the OSSF that helps to asses the security posture of repositories. A low scorecard score means your repository may be at risk. | A low Scorecard score can indicate that the repository is more vulnerable to attack than others, making it a prime attack target. |
Insecure Configurations | Repository Webhooks Should Be Configured To Use SSL | Webhooks that are not configured with SSL enabled could expose your sofware to man in the middle attacks (MITM). | If SSL verification is disabled, any party with access to the target DNS domain can masquerade as your designated payload URL, allowing it freely read and affect the response of any webhook request.In the case of GitHub Enterprise Server instances, it may be sufficient only to control the DNS configuration of the network where the instance is deployed, as an attacker can redirect traffic to the target domain in your internal network directly to them, and this is often much easier than compromising an internet-facing domain. |
Insecure Configurations | Default Branch Should Require All Commits To Be Signed | Require all commits to be signed and verified | A commit containing malicious code may be crafted by a malicious actor that has acquired write access to the repository to initiate a supply chain attack. Commit signing provides another layer of defense that can prevent this type of compromise. |
Insecure Configurations | Repository Webhooks Should Be Configured With A Secret | Webhooks are not configured with a shared secret to validate the origin and content of the request. This could allow your webhook to be triggered by any bad actor with the URL. | Not using a webhook secret makes the service receiving the webhook unable to determine the authenticity of the request.This allows attackers to masquerade as your repository, potentially creating an unstable or insecure state in other systems. |
Insecure Configurations | Default Branch Should Require All Conversations To Be Resolved Before Merge | Require all Pull Request conversations to be resolved before merging. Check this to avoid bypassing/missing a Pull Reuqest comment. | Allowing the merging of code without resolving all conversations can promote poor and vulnerable code, as important comments may be forgotten or deliberately ignored when the code is merged. |
Insecure Configurations | Default Branch Deletion Protection Should Be Enabled | The history of the default branch is not protected against deletion for this repository. | Rewriting project history can make it difficult to trace back when bugs or security issues were introduced, making them more difficult to remediate. |
Insecure Configurations | Default Workflow Token Permission Should Be Set To Read Only | The default GitHub Action workflow token permission is set to read-write. When creating workflow tokens, it is highly recommended to follow the Principle of Least Privilege and force workflow authors to specify explicitly which permissions they need. | In case of token compromise (due to a vulnerability or malicious third-party GitHub actions), an attacker can use this token to sabotage various assets in your CI/CD pipeline, such as packages, pull-requests, deployments, and more. |
Insecure Configurations | Default Branch Should Require All Checks To Pass Before Merge | Branch protection is enabled. However, the checks which validate the quality and security of the code are not required to pass before submitting new changes. The default check ensures code is up-to-date in order to prevent faulty merges and unexpected behaviors, as well as other custom checks that test security and quality. It is advised to turn this control on to ensure any existing or future check will be required to pass. | Not defining a set of required status checks can make it easy for contributors to introduce buggy or insecure code as manual review, whether mandated or optional, is the only line of defense. |
Insecure Configurations | Default Branch Should Restrict Who Can Push To It | By defa |