438 items found
Weaknesses
Abstract
A program capable of creating a circular link in a data structure can cause stack exhaustion when the data structure is processed recursively.
Explanation
Using recursion is a staple for creating and managing linked data structures. Recursion also runs the risk of processing indefinitely if the data incorporates a circular link, which in turn will exhaust the stack and crash the program.

Example 1: The following code snippet demonstrates this vulnerability using Apache Log4j2.

Marker child = MarkerManager.getMarker("child");
Marker parent = MarkerManager.getMarker("parent");

child.addParents(parent);
parent.addParents(child);

String toInfinity = child.toString();


When child calls toString(), which includes a recursive processing method, it triggers a stack overflow exception (stack exhaustion). This exception occurs due to the circular link between child and parent.
References
[1] DOS-1: Beware of activities that may use disproportionate resources Oracle
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[6] Standards Mapping - Common Weakness Enumeration CWE ID 674
[7] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective C.3.3 - Web Software Attack Mitigation
desc.controlflow.java.code_correctness_stack_exhaustion
Abstract
Attackers might control data written to a spreadsheet, which could enable them to target users who open the file on certain spreadsheet processors.
Explanation
Popular spreadsheet processors such as Apache OpenOffice Calc and Microsoft Office Excel support powerful formula operations that might enable attackers in control of the spreadsheet to run arbitrary commands on the underlying system or leak sensitive information on the spreadsheet.

As an example, the attacker may inject the following payload as part of a CSV field: =cmd|'/C calc.exe'!Z0. If the user who opens the spreadsheet trusts the origin of the document, they might accept all the security prompts presented by the spreadsheet processor and let the payload (in this example, opening the Windows calculator) run on their system.

Example: The following example shows an ASP.NET Controller that generates a CSV response with non-sanitized user-controlled data:


public void Service()
{
string name = HttpContext.Request["name"];

string data = GenerateCSVFor(name);
HttpContext.Response.Clear();
HttpContext.Response.Buffer = true;
HttpContext.Response.AddHeader("content-disposition", "attachment;filename=file.csv");
HttpContext.Response.Charset = "";
HttpContext.Response.ContentType = "application/csv";
HttpContext.Response.Output.Write(tainted);
HttpContext.Response.Flush();
HttpContext.Response.End();
}
References
[1] Formula Injection Pentest Magazine
[2] Comma Separated Vulnerabilities Context
desc.dataflow.dotnet.formula_injection
Abstract
Attackers might control data written to a spreadsheet, which could enable them to target users who open the file on certain spreadsheet processors.
Explanation
Popular spreadsheet processors such as Apache OpenOffice Calc and Microsoft Office Excel support powerful formula operations that might enable attackers in control of the spreadsheet to run arbitrary commands on the underlying system or leak sensitive information on the spreadsheet.

As an example, the attacker may inject the following payload as part of a CSV field: =cmd|'/C calc.exe'!Z0. If the user who opens the spreadsheet trusts the origin of the document, they might accept all the security prompts presented by the spreadsheet processor and let the payload (in this example, opening the Windows calculator) run on their system.

Example: The following example writes to a csv file using non-sanitized user-controlled data:


func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
foo := r.FormValue("foo")
...
w := csv.NewWriter(file)
w.Write(foo)
}
References
[1] Formula Injection Pentest Magazine
[2] Comma Separated Vulnerabilities Context
desc.dataflow.golang.formula_injection
Abstract
Attackers might control data written to a spreadsheet, which could enable them to target users who open the file on certain spreadsheet processors.
Explanation
Popular spreadsheet processors such as Apache OpenOffice Calc and Microsoft Office Excel support powerful formula operations that might enable attackers in control of the spreadsheet to run arbitrary commands on the underlying system or leak sensitive information on the spreadsheet.

As an example, the attacker may inject the following payload as part of a CSV field: =cmd|'/C calc.exe'!Z0. If the user who opens the spreadsheet trusts the origin of the document, they might accept all the security prompts presented by the spreadsheet processor and let the payload (in this example, opening the Windows calculator) run on their system.

Example: The following example shows a Spring Controller that generates a CSV response with non-sanitized user-controlled data:


@RequestMapping(value = "/api/service.csv")
public ResponseEntity<String> service(@RequestParam("name") String name) {

HttpHeaders responseHeaders = new HttpHeaders();
responseHeaders.add("Content-Type", "application/csv; charset=utf-8");
responseHeaders.add("Content-Disposition", "attachment;filename=file.csv");

String data = generateCSVFor(name);

return new ResponseEntity<>(data, responseHeaders, HttpStatus.OK);
}
References
[1] Formula Injection Pentest Magazine
[2] Comma Separated Vulnerabilities Context
desc.dataflow.java.formula_injection
Abstract
Attackers might control data written to a spreadsheet, which could enable them to target users who open the file on certain spreadsheet processors.
Explanation
Popular spreadsheet processors such as Apache OpenOffice Calc and Microsoft Office Excel support powerful formula operations that might enable attackers in control of the spreadsheet to run arbitrary commands on the underlying system or leak sensitive information on the spreadsheet.

As an example, the attacker may inject the following payload as part of a CSV field: =cmd|'/C calc.exe'!Z0. If the user who opens the spreadsheet trusts the origin of the document, they might accept all the security prompts presented by the spreadsheet processor and let the payload (in this example, opening the Windows calculator) run on their system.

Example: The following example shows a Spring Controller that generates a CSV response with non-sanitized user-controlled data:


@RequestMapping(value = "/api/service.csv")
fun service(@RequestParam("name") name: String): ResponseEntity<String> {
val responseHeaders = HttpHeaders()
responseHeaders.add("Content-Type", "application/csv; charset=utf-8")
responseHeaders.add("Content-Disposition", "attachment;filename=file.csv")
val data: String = generateCSVFor(name)
return ResponseEntity(data, responseHeaders, HttpStatus.OK)
}
References
[1] Formula Injection Pentest Magazine
[2] Comma Separated Vulnerabilities Context
desc.dataflow.kotlin.formula_injection
Abstract
Weak cryptographic hashes cannot guarantee data integrity and should not be used in security-critical contexts.
Explanation
MD2, MD4, MD5, RIPEMD-160, and SHA-1 are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. However, as recent cryptanalysis research has revealed fundamental weaknesses in these algorithms, they should no longer be used within security-critical contexts.

Effective techniques for breaking MD and RIPEMD hashes are widely available, so those algorithms should not be relied upon for security. In the case of SHA-1, current techniques still require a significant amount of computational power and are more difficult to implement. However, attackers have found the Achilles' heel for the algorithm, and techniques for breaking it will likely lead to the discovery of even faster attacks.
References
[1] Xiaoyun Wang MD5 and MD4 Collision Generators
[2] Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu Finding Collisions in the Full SHA-1
[3] Xiaoyun Wang and Hongbo Yu How to Break MD5 and Other Hash Functions
[4] SDL Development Practices Microsoft
desc.semantic.abap.weak_cryptographic_hash
Abstract
Weak cryptographic hashes cannot guarantee data integrity and should not be used in security-critical contexts.
Explanation
MD2, MD4, MD5, RIPEMD-160, and SHA-1 are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. Cryptanalysis research has revealed fundamental weaknesses in these algorithms and their use is not recommended in security-critical contexts.

Do not rely on MD and RIPEMD hashing algorithms for security. Effective techniques for breaking MD and RIPEMD hashes are widely available. In the case of SHA-1, current techniques still require a significant amount of computational power and are difficult to implement. However, attackers have discovered weaknesses in the algorithm and techniques for breaking it can lead to the discovery of even faster attacks.
References
[1] Xiaoyun Wang MD5 and MD4 Collision Generators
[2] Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu Finding Collisions in the Full SHA-1
[3] Xiaoyun Wang and Hongbo Yu How to Break MD5 and Other Hash Functions
[4] SDL Development Practices Microsoft
desc.semantic.apex.weak_cryptographic_hash
Abstract
Weak cryptographic hashes cannot guarantee data integrity and should not be used in security-critical contexts.
Explanation
MD2, MD4, MD5, RIPEMD-160, and SHA-1 are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. However, as recent cryptanalysis research has revealed fundamental weaknesses in these algorithms, they should no longer be used within security-critical contexts.

Effective techniques for breaking MD and RIPEMD hashes are widely available, so those algorithms should not be relied upon for security. In the case of SHA-1, current techniques still require a significant amount of computational power and are more difficult to implement. However, attackers have found the Achilles' heel for the algorithm, and techniques for breaking it will likely lead to the discovery of even faster attacks.
References
[1] Xiaoyun Wang MD5 and MD4 Collision Generators
[2] Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu Finding Collisions in the Full SHA-1
[3] Xiaoyun Wang and Hongbo Yu How to Break MD5 and Other Hash Functions
[4] SDL Development Practices Microsoft
desc.config.dotnet.weak_cryptographic_hash
Abstract
Weak cryptographic hashes cannot guarantee data integrity and should not be used in security-critical contexts.
Explanation
MD2, MD4, MD5, RIPEMD-160, and SHA-1 are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. However, as recent cryptanalysis research has revealed fundamental weaknesses in these algorithms, they should no longer be used within security-critical contexts.

Effective techniques for breaking MD and RIPEMD hashes are widely available, so those algorithms should not be relied upon for security. In the case of SHA-1, current techniques still require a significant amount of computational power and are more difficult to implement. However, attackers have found the Achilles' heel for the algorithm, and techniques for breaking it will likely lead to the discovery of even faster attacks.
References
[1] Xiaoyun Wang MD5 and MD4 Collision Generators
[2] Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu Finding Collisions in the Full SHA-1
[3] Xiaoyun Wang and Hongbo Yu How to Break MD5 and Other Hash Functions
[4] SDL Development Practices Microsoft
desc.semantic.cpp.weak_cryptographic_hash
Abstract
Weak cryptographic hashes cannot guarantee data integrity and should not be used in security-critical contexts.
Explanation
MD2, MD4, MD5, RIPEMD-160, and SHA-1 are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. However, as recent cryptanalysis research has revealed fundamental weaknesses in these algorithms, they should no longer be used within security-critical contexts.

Effective techniques for breaking MD and RIPEMD hashes are widely available, so those algorithms should not be relied upon for security. In the case of SHA-1, current techniques still require a significant amount of computational power and are more difficult to implement. However, attackers have found the Achilles' heel for the algorithm, and techniques for breaking it will likely lead to the discovery of even faster attacks.
References
[1] Xiaoyun Wang MD5 and MD4 Collision Generators
[2] Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu Finding Collisions in the Full SHA-1
[3] Xiaoyun Wang and Hongbo Yu How to Break MD5 and Other Hash Functions
[4] SDL Development Practices Microsoft
desc.semantic.cfml.weak_cryptographic_hash
Abstract
Do not use weak cryptographic hashes in security-critical contexts as data integrity is not guaranteed.
Explanation
MD2, MD4, MD5, RIPEMD-160, and SHA-1 are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. Cryptanalysis research has revealed fundamental weaknesses in these algorithms their use is not recommended in security-critical contexts.

Do not rely on MD and RIPEMD hashing algorithms for security. Effective techniques for breaking MD and RIPEMD hashes are widely available. In the case of SHA-1, current techniques still require a significant amount of computational power and are difficult to implement. However, attackers have discovered weaknesses in the algorithm and techniques for breaking it can lead to the discovery of even faster attacks.
References
[1] Xiaoyun Wang MD5 and MD4 Collision Generators
[2] Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu Finding Collisions in the Full SHA-1
[3] Xiaoyun Wang and Hongbo Yu How to Break MD5 and Other Hash Functions
[4] SDL Development Practices Microsoft
desc.semantic.golang.weak_cryptographic_hash
Abstract
Weak cryptographic hashes cannot guarantee data integrity and should not be used in security-critical contexts.
Explanation
MD2, MD4, MD5, RIPEMD-160, and SHA-1 are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. However, as recent cryptanalysis research has revealed fundamental weaknesses in these algorithms, they should no longer be used within security-critical contexts.

Effective techniques for breaking MD and RIPEMD hashes are widely available, so those algorithms should not be relied upon for security. In the case of SHA-1, current techniques still require a significant amount of computational power and are more difficult to implement. However, attackers have found the Achilles' heel for the algorithm, and techniques for breaking it will likely lead to the discovery of even faster attacks.
References
[1] Xiaoyun Wang MD5 and MD4 Collision Generators
[2] Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu Finding Collisions in the Full SHA-1
[3] Xiaoyun Wang and Hongbo Yu How to Break MD5 and Other Hash Functions
[4] SDL Development Practices Microsoft
desc.semantic.java.weak_cryptographic_hash
Abstract
Weak cryptographic hashes cannot guarantee data integrity and should not be used in security-critical contexts.
Explanation
MD2, MD4, MD5, RIPEMD-160, and SHA-1 are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. However, as recent cryptanalysis research has revealed fundamental weaknesses in these algorithms, they should no longer be used within security-critical contexts.

Effective techniques for breaking MD and RIPEMD hashes are widely available, so those algorithms should not be relied upon for security. In the case of SHA-1, current techniques still require a significant amount of computational power and are more difficult to implement. However, attackers have found the Achilles' heel for the algorithm, and techniques for breaking it will likely lead to the discovery of even faster attacks.
References
[1] Xiaoyun Wang MD5 and MD4 Collision Generators
[2] Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu Finding Collisions in the Full SHA-1
[3] Xiaoyun Wang and Hongbo Yu How to Break MD5 and Other Hash Functions
[4] SDL Development Practices Microsoft
desc.structural.javascript.weak_cryptographic_hash
Abstract
The identified call potentially uses weak cryptographic hashes. Weak cryptographic hashes cannot guarantee data integrity and should not be used in security-critical contexts.
Explanation
MD2, MD4, MD5, RIPEMD-160, and SHA-1 are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. However, as recent cryptanalysis research has revealed fundamental weaknesses in these algorithms, they should no longer be used within security-critical contexts.

Example 1: The following code utilizes a weak hashing algorithm (MD5):


NSData *imageData = [NSData dataWithContentsOfFile:file];
CC_MD5(imageData, [imageData length], result);


Effective techniques for breaking MD and RIPEMD hashes are widely available, so those algorithms should not be relied upon for security. In the case of SHA-1, current techniques still require a significant amount of computational power and are more difficult to implement. However, attackers have found the Achilles' heel for the algorithm, and techniques for breaking it will likely lead to the discovery of even faster attacks.
References
[1] Xiaoyun Wang MD5 and MD4 Collision Generators
[2] Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu Finding Collisions in the Full SHA-1
[3] Xiaoyun Wang and Hongbo Yu How to Break MD5 and Other Hash Functions
desc.semantic.objc.weak_cryptographic_hash
Abstract
Weak cryptographic hashes cannot guarantee data integrity and should not be used in security-critical contexts.
Explanation
MD2, MD4, MD5, RIPEMD-160, and SHA-1 are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. However, as recent cryptanalysis research has revealed fundamental weaknesses in these algorithms, they should no longer be used within security-critical contexts.

Effective techniques for breaking MD and RIPEMD hashes are widely available, so those algorithms should not be relied upon for security. In the case of SHA-1, current techniques still require a significant amount of computational power and are more difficult to implement. However, attackers have found the Achilles' heel for the algorithm, and techniques for breaking it will likely lead to the discovery of even faster attacks.
References
[1] Xiaoyun Wang MD5 and MD4 Collision Generators
[2] Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu Finding Collisions in the Full SHA-1
[3] Xiaoyun Wang and Hongbo Yu How to Break MD5 and Other Hash Functions
[4] SDL Development Practices Microsoft
desc.semantic.php.weak_cryptographic_hash
Abstract
Weak cryptographic hashes cannot guarantee data integrity and should not be used in security-critical contexts.
Explanation
MD2, MD4, MD5, RIPEMD-160, and SHA-1 are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. However, as recent cryptanalysis research has revealed fundamental weaknesses in these algorithms, they should no longer be used within security-critical contexts.

Effective techniques for breaking MD and RIPEMD hashes are widely available, so those algorithms should not be relied upon for security. In the case of SHA-1, current techniques still require a significant amount of computational power and are more difficult to implement. However, attackers have found the Achilles' heel for the algorithm, and techniques for breaking it will likely lead to the discovery of even faster attacks.
References
[1] Xiaoyun Wang MD5 and MD4 Collision Generators
[2] Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu Finding Collisions in the Full SHA-1
[3] Xiaoyun Wang and Hongbo Yu How to Break MD5 and Other Hash Functions
[4] SDL Development Practices Microsoft
desc.semantic.sql.weak_cryptographic_hash
Abstract
Weak cryptographic hashes cannot guarantee data integrity and should not be used in security-critical contexts.
Explanation
MD2, MD4, MD5, RIPEMD-160, SHA-1 and Keccak are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. However, as recent cryptanalysis research has revealed fundamental weaknesses in these algorithms, they should no longer be used within security-critical contexts.

Effective techniques for breaking MD and RIPEMD hashes are widely available, so those algorithms should not be relied upon for security. In the case of SHA-1, current techniques still require a significant amount of computational power and are more difficult to implement. However, attackers have found the Achilles' heel for the algorithm, and techniques for breaking it will likely lead to the discovery of even faster attacks.
References
[1] Xiaoyun Wang MD5 and MD4 Collision Generators
[2] Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu Finding Collisions in the Full SHA-1
[3] Xiaoyun Wang and Hongbo Yu How to Break MD5 and Other Hash Functions
[4] SDL Development Practices Microsoft
desc.semantic.python.weak_cryptographic_hash
Abstract
Weak cryptographic hashes cannot guarantee data integrity and should not be used in security-critical contexts.
Explanation
MD2, MD4, MD5, RIPEMD-160, and SHA-1 are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. However, as recent cryptanalysis research has revealed fundamental weaknesses in these algorithms, they should no longer be used within security-critical contexts.

Effective techniques for breaking MD and RIPEMD hashes are widely available, so those algorithms should not be relied upon for security. In the case of SHA-1, current techniques still require a significant amount of computational power and are more difficult to implement. However, attackers have found the Achilles' heel for the algorithm, and techniques for breaking it will likely lead to the discovery of even faster attacks.
References
[1] Xiaoyun Wang MD5 and MD4 Collision Generators
[2] Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu Finding Collisions in the Full SHA-1
[3] Xiaoyun Wang and Hongbo Yu How to Break MD5 and Other Hash Functions
[4] SDL Development Practices Microsoft
desc.structural.ruby.weak_cryptographic_hash
Abstract
The identified call uses weak cryptographic hashes. Weak cryptographic hashes cannot guarantee data integrity and should not be used in security-critical contexts.
Explanation
MD2, MD4, MD5, RIPEMD-160, and SHA-1 are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. However, as recent cryptanalysis research has revealed fundamental weaknesses in these algorithms, they should no longer be used within security-critical contexts.

Example 1: The following code utilizes a weak hashing algorithm (MD5):


let encodedText = text.cStringUsingEncoding(NSUTF8StringEncoding)
let textLength = CC_LONG(text.lengthOfBytesUsingEncoding(NSUTF8StringEncoding))
let digestLength = Int(CC_MD5_DIGEST_LENGTH)
let result = UnsafeMutablePointer<CUnsignedChar>.alloc(digestLength)

CC_MD5(encodedText, textLength, result)


Effective techniques for breaking MD and RIPEMD hashes are widely available, so those algorithms should not be relied upon for security. In the case of SHA-1, current techniques still require a significant amount of computational power and are more difficult to implement. However, attackers have found the Achilles' heel for the algorithm, and techniques for breaking it will likely lead to the discovery of even faster attacks.
References
[1] Xiaoyun Wang MD5 and MD4 Collision Generators
[2] Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu Finding Collisions in the Full SHA-1
[3] Xiaoyun Wang and Hongbo Yu How to Break MD5 and Other Hash Functions
desc.structural.swift.weak_cryptographic_hash
Abstract
Weak cryptographic hashes cannot guarantee data integrity and should not be used in security-critical contexts.
Explanation
MD2, MD4, MD5, RIPEMD-160, and SHA-1 are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. However, as recent cryptanalysis research has revealed fundamental weaknesses in these algorithms, they should no longer be used within security-critical contexts.

Effective techniques for breaking MD and RIPEMD hashes are widely available, so those algorithms should not be relied upon for security. In the case of SHA-1, current techniques still require a significant amount of computational power and are more difficult to implement. However, attackers have found the Achilles' heel for the algorithm, and techniques for breaking it will likely lead to the discovery of even faster attacks.
References
[1] Xiaoyun Wang MD5 and MD4 Collision Generators
[2] Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu Finding Collisions in the Full SHA-1
[3] Xiaoyun Wang and Hongbo Yu How to Break MD5 and Other Hash Functions
[4] SDL Development Practices Microsoft
desc.config.xml.weak_cryptographic_hash
Abstract
Weak cryptographic hashes cannot guarantee data integrity and should not be used in security-critical contexts.
Explanation
MD2, MD4, MD5, RIPEMD-160, and SHA-1 are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. However, as recent cryptanalysis research has revealed fundamental weaknesses in these algorithms, they should no longer be used within security-critical contexts.

Effective techniques for breaking MD and RIPEMD hashes are widely available, so those algorithms should not be relied upon for security. In the case of SHA-1, current techniques still require a significant amount of computational power and are more difficult to implement. However, attackers have found the Achilles' heel for the algorithm, and techniques for breaking it will likely lead to the discovery of even faster attacks.
References
[1] Xiaoyun Wang MD5 and MD4 Collision Generators
[2] Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu Finding Collisions in the Full SHA-1
[3] Xiaoyun Wang and Hongbo Yu How to Break MD5 and Other Hash Functions
[4] SDL Development Practices Microsoft
desc.structural.vb.weak_cryptographic_hash
Abstract
A Terraform configuration enables public access to a Google Cloud SQL Database instance.
Explanation
Failure to block unwanted network traffic expands a cloud service's attack surface. Services open to interaction with the public are subjected to almost continuous scanning and probing by malicious entities.

By default, Terraform deploys a Google Cloud SQL Database instance that only accepts connections from private IP addresses. Optional Authorized Networks settings define acceptable ranges of public IP addresses.

Example 1: The following Terraform configuration sets value to 0.0.0.0/0 in the authorized_networks block. A CIDR block of /0 accepts connections from any IP address between 0.0.0.0 and 255.255.255.255.

resource "google_sql_database_instance" "db-demo" {
...
settings {
...
ip_configuration {
...
authorized_networks {
name = "any ip"
value = "0.0.0.0/0"
}
...
}
...
}
...
}
References
[1] HashiCorp google_sql_database_instance
[2] Google Cloud Authorize with authorized networks
[3] Google Cloud Disable public IP
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.5
[5] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[8] Standards Mapping - CIS Google Cloud Computing Platform Benchmark partial
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[10] Standards Mapping - CIS Kubernetes Benchmark partial
[11] Standards Mapping - Common Weakness Enumeration CWE ID 284
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-001084, CCI-002165
[13] Standards Mapping - FIPS200 AC
[14] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-6 Least Privilege (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-6 Least Privilege
[17] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[18] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[19] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 4.1.3 General Access Control Design (L1 L2 L3)
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 7.3.2
[23] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[26] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II
desc.structural.hcl.gcp_terraform_misconfiguration_cloud_sql_database_publicly_accessible
Abstract
A Terraform configuration sets up a Compute Engine instance without using Identity and Access Management (IAM) roles to manage SSH access.
Explanation
The IAM-based access control reduces human errors and promotes efficiency. Enabling the OS Login permits the use of IAM roles to automate the lifecycle management of Linux accounts for accessing all Compute Engine instances in the same project or organization.

Example 1: The following example shows a Terraform configuration that disables the use of IAM roles to manage SSH access by setting enable-oslogin to false in the metadata argument.

resource "google_compute_instance" "compute-instance-demo" {
...
metadata = {
enable-oslogin = false
...
}
...
}
References
[1] HashiCorp google_compute_instance
[2] Google Cloud About OS Login
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Cloud Computing Platform Benchmark partial
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[9] Standards Mapping - CIS Kubernetes Benchmark partial
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000015, CCI-002121
[11] Standards Mapping - FIPS200 AC
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[14] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.1.6 Secure Software Development Lifecycle (L2 L3), 1.4.1 Access Control Architectural Requirements (L2 L3)
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 8.2.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 8.3.1
[18] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.3 - Authentication and Access Control
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.3 - Authentication and Access Control
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.3 - Authentication and Access Control, Control Objective C.2.1.2 - Web Software Access Controls
[21] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000280 CAT II, APSC-DV-002880 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000280 CAT II, APSC-DV-002880 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000280 CAT II, APSC-DV-002880 CAT II
desc.structural.hcl.gcp_terraform_misconfiguration_compute_engine_access_control
Abstract
A Terraform configuration creates a Compute Engine instance with a default service account.
Explanation
If a Compute Engine instance is created without a user-managed service account specification, Google Cloud assigns a default service account to the instance. The access rights of the default service account are often beyond what the instance needs to operate. This violates the least privilege principle.

Example 1: The following example shows a Terraform configuration that creates a Compute Engine instance without a user-managed service account specification. The service_account block is missing.

resource "google_compute_instance" "instance-demo" {
name = "name-demo"
machine_type = "e2-micro"
boot_disk {
...
}
network_interface {
...
}
}
References
[1] Dylan Ayrey & Allison Donovan Compromise any GCP Org Via Cloud API Lateral Movement and Privilege Escalation
[2] Google Cloud Best practices for securing service accounts
[3] HashiCorp google_compute_instance
[4] Google Cloud Service accounts
[5] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.5
[6] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[7] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[8] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[9] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[10] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[11] Standards Mapping - CIS Kubernetes Benchmark complete
[12] Standards Mapping - Common Weakness Enumeration CWE ID 250
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000381, CCI-002233, CCI-002235
[14] Standards Mapping - FIPS200 AC
[15] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-6 Least Privilege (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-6 Least Privilege
[18] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[19] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[20] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[21] Standards Mapping - OWASP Application Security Verification Standard 4.0 4.1.3 General Access Control Design (L1 L2 L3), 4.1.4 General Access Control Design (L1 L2 L3)
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 7.1.2
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 7.2.2
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[27] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000500 CAT II, APSC-DV-000510 CAT I, APSC-DV-001500 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000500 CAT II, APSC-DV-000510 CAT I, APSC-DV-001500 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000500 CAT II, APSC-DV-000510 CAT I, APSC-DV-001500 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000330 CAT II
desc.structural.hcl.gcp_terraform_misconfiguration_compute_engine_default_service_account
Abstract
A Terraform configuration sets up a Compute Engine instance that enables IP forwarding.
Explanation
Failure to block unwanted network traffic expands a cloud service's attack surface.

By default, IP forwarding is disabled in a Compute Engine instance. IP forwarding allows sending and receiving packets with non-matching source or destination IPs. An attacker can exploit this by routing packets through the Compute Engine instance to bypass network access control.

Example 1: The following Terraform configuration enables IP forwarding by setting can_ip_forward to true.

resource "google_compute_instance" "compute_instance_demo" {
...
can_ip_forward = true
...
}
References
[1] HashiCorp google_compute_instance
[2] Google Cloud Enabling IP forwarding for instances
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.5
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Cloud Computing Platform Benchmark partial
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[9] Standards Mapping - CIS Kubernetes Benchmark partial
[10] Standards Mapping - Common Weakness Enumeration CWE ID 441
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[12] Standards Mapping - FIPS200 AC
[13] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 CA-3 System Interconnections (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 CA-3 Information Exchange
[16] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[17] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[18] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[19] Standards Mapping - OWASP Application Security Verification Standard 4.0 4.1.1 General Access Control Design (L1 L2 L3)
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[23] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[25] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
desc.structural.hcl.gcp_terraform_misconfiguration_compute_engine_ip_forwarding_enabled