Detecting Authentication and Access Control issues in openIMIS

In this installment of our openIMIS security testing series, we will be discussing the issues with Authentication and Access Control mechanisms uncovered in the system. We will share our testing approach, and describe the identified vulnerabilities, along with mitigation strategies designed to resolve security issues and ensure better protection against threats.

Significance

The vulnerabilities discovered in openIMIS illustrate significant risks that can expose business operations and compromise data security. For instance, the absence of a robust password policy invites brute-force attacks, and easily guessable user accounts amplify the risk of unauthorized access. 

Furthermore, issues such as improperly managed permissions and unprotected direct API access expose the system to potential data breaches. These vulnerabilities highlight the essential need for stringent authentication measures and comprehensive access control systems in protecting sensitive information and maintaining operational integrity.

For a deeper exploration of the principles behind robust authentication and access control, we invite you to read our more theoretical article on these topics. The piece provides a broader context and discusses advanced security strategies that can help fortify your systems against similar vulnerabilities. Read our detailed article on authorization and authentication to equip yourself with knowledge and implement effective security safeguards in your projects.

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 tool ensures comprehensive coverage and precision in identifying potential security weaknesses.

Discovery

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

  • Encrypted channel security: We tested the security of credentials transmitted over encrypted channels to prevent interception by unauthorized parties.
  • Default and weak credentials: Searching for default and weak credentials helped us identify areas where brute-force attack could be easily executed. We used databases with most commonly used credentials to execute a controlled real-life attack with Burp Suite Intruder.
  • Authentication mechanisms: We tested for weaknesses in the lockout mechanisms, the possibility of bypassing authentication schemas, and vulnerabilities in the “Remember Password” functionality.
  • Browser and cache security: The investigation included testing for browser cache weaknesses that could expose sensitive data.
  • Password and authentication policies: Our team critically evaluated the system’s password policies and reset functionalities to check for any vulnerabilities that could allow easy password cracking or unauthorized access.
  • Access and privilege controls: We checked for insecure direct object references, bypassing authorization schemas, and possible privilege escalations, which are crucial for maintaining strict access controls.

The discovery process revealed several critical vulnerabilities, notably:

  1. Account enumeration and predictable usernames: We identified that the system allowed enumeration of usernames and had predictable user account names, making it easier for attackers to gain initial access.
  2. Weak password policy: The system permitted the creation of extremely weak passwords, including those with minimal length and complexity, greatly simplifying brute-force attacks.
  3. Bypassing authentication: Certain flaws allowed unauthorized users to bypass authentication mechanisms, accessing sensitive areas without proper credentials.
  4. Broken access control: Inadequacies in access control mechanisms enabled users to access information and functionalities beyond their permissions.
  5. Fragile reset password functionality: The password reset functionality was found to be susceptible to abuse, lacking robust verifications and allowing weak passwords.

This comprehensive testing and discovery process not only highlights specific vulnerabilities but also underscores the meticulousness of our approach in uncovering and understanding the nuances of each security flaw. This thoroughness is crucial in effectively mitigating risks and enhancing the overall security posture of systems like openIMIS.

Vulnerability analysis and mitigation

The following section is dedicated to the analysis of issues identified during openIMIS security testing. Each vulnerability is described individually, focusing on a few key areas – testing, discovery, potential impact, recommended solutions, and real-world resolutions. We’re hoping that these examples will provide you with a deeper understanding of Authentication and Access Control-related vulnerabilities and their mitigation.

Weak password policy

How we tested it

We analyzed the password policy settings within the openIMIS system, focusing on both the manually set and system-generated passwords. Our testing approach involved creating user accounts with various types of passwords, including extremely weak and complex ones. We specifically tested if the system allowed the creation of user accounts with minimal password requirements and assessed the strength of the generated passwords.

How we found it

During our assessment, we discovered that the system permitted administrators to create user accounts with passwords as short as one character. For instance, we successfully created a user account using ‘1’ as the password. This significant oversight in password policy poses severe security risks.

Impact

  • Likelihood: High, due to the system allowing extremely weak passwords.
  • Impact: High, as weak passwords significantly elevate the risk of unauthorized access, potentially leading to data breaches and compromised system integrity.

Generated password policy

Despite having a policy for generated passwords, the system still exhibits issues. The generated passwords are meant for first login only, but the system does not enforce a change upon the initial use. Generated passwords should be 10 characters long and include special characters, numbers, and letters, but the system fails to consistently meet these criteria. It is possible to generate a password lacking numbers, special characters, or alphabet letters, significantly reducing its strength.

Visualization of password strength

To understand password strength and estimate how long it would take to brute-force, we use the following approximations based on password length and character variety. We use the worst possible scenario, which is a database leak that would allow offline password cracking:

LengthNo. of charactersDescriptionBitsTime to break
1062Password without special characters (openIMIS generator)59.5410 days
1088Most secure password generated by openIMIS generator64.5910.6 months
1288Recommended password77.516,838.89 years

Form malfunction

Additionally, we found that user accounts could be created without a password, or with a password only entered in the confirmation field, allowing the creation of a user without proper password validation.

Implementation of recommendations

  1. Configurable password policy:
    • We introduced a flexible, configurable password policy that administrators can customize. This policy specifies:
      • The minimum length of the password.
      • The required number of uppercase letters, lowercase letters, and special characters.
    • This configurability allows administrators to enforce a baseline level of complexity suited to their specific security needs.
  2. Use of zxcvbn library:
    • In addition to the configurable policy, we integrated the zxcvbn library, which is recommended by OWASP for its comprehensive approach to evaluating password strength.
    • zxcvbn analyzes passwords for:
      • Common words or patterns (e.g. “Pa33word!”).
      • Common personal information like birth dates.
      • Sequences or repeated characters.
    • This analysis provides a password score ranging from 0 to 4:
      • Score 2: Medium strength, minimum acceptable level.
      • Score 3: Strong, with additional feedback for further improvement.
      • Score 4: Very strong, indicating optimal security.
    • zxcvbn prevents weak passwords that might pass the first policy but fail comprehensive strength checks.
  3. Enhanced auto-generated passwords:
    • Auto-generated passwords were made significantly longer to ensure higher security without compromising user experience.
    • These passwords meet both the configurable policy and achieve a high zxcvbn score, ensuring robust protection.
  4. Rate limiting and lockout mechanisms:
    • To combat brute-force attacks, we implemented rate limiting and account lockout mechanisms:
      • Rate limiting: Limits login attempts to one per minute, drastically reducing the feasibility of brute-force attacks.
      • Account lockout: Temporarily locks accounts after a certain number of failed attempts, adding an additional layer of security.
  5. Password hashing and history check:
    • Although we recommended saving hashes of the last few passwords to prevent immediate reuse, practical constraints led us to adjust our approach:
      • Decision: Due to the potential for minimal changes to bypass the history check (e.g. adding one character to the old password), we opted not to implement this feature to conserve resources and focus on more effective measures.

Outcome

By implementing these changes, openIMIS significantly strengthened its password policies and overall security posture. The combination of customizable password requirements, advanced strength analysis with zxcvbn, and enhanced security measures for login attempts, ensures that user accounts are well-protected against unauthorized access. This holistic approach balances robust security with user convenience, reducing the risk of password-related vulnerabilities without imposing undue burden on users.

In summary, our approach ensured that passwords are:

  • Complex and difficult to guess.
  • Evaluated for common weaknesses and patterns.
  • Generated with a high-security standard.
  • Protected against brute-force attacks through rate limiting and lockout mechanisms.

Reset password functionality

How we tested it

We examined the reset password functionality to identify any potential vulnerabilities and assess its overall security. Our testing involved:

  • Accessing the URL reset functionality to simulate the user experience.
  • Analyzing the security of the one-time token used for password recovery.
  • Using tools like Burp Suite to test for potential brute-force attack vectors and denial of service vulnerabilities.

How we found it

During our assessment, we discovered the following:

  • Users can access the URL reset functionality directly, the same URL that should be sent via email. However, due to the secure hashing (SHA-256) of the one-time token, it is not possible to forge the token or perform unauthorized actions.
  • The reset password process involves the user entering their username to receive a reset link via email. This step could potentially be exploited if not properly secured.
  • We identified a vulnerability where repeated requests could be sent using Burp Suite, highlighting a susceptibility to brute-force attacks or denial of service.

Impact

  • Likelihood: Very low, as the secure hashing of the token prevents unauthorized password resets.
  • Impact: Low, as the main risk lies in potential abuse of the username input form and repeated request vulnerability.

Recommendations

To enhance the security and usability of the reset password functionality, we recommend the following:

  1. Rate limiting and CAPTCHA verification:
    • Implement rate limiting at the initial stage of sending the reset link to prevent abuse.
    • Integrate CAPTCHA verification to further mitigate automated attacks.
  2. Eliminate username input requirement:
    • Remove the need for users to input their username when requesting a password reset link. This can reduce the risk of errors and misuse.
  3. Implement strict rate limiting and request throttling:
    • Enforce strict rate limiting and request throttling to prevent brute-force attacks.
    • Introduce an account lockout mechanism after a series of failed attempts to enhance system resilience.
  4. Comprehensive password policy:
    • Ensure the password reset process adheres to the comprehensive password policy previously recommended, including mandatory complexity and regular updates.

By following these recommendations, the reset password functionality can be made more secure and user-friendly, reducing the risk of abuse and enhancing overall system integrity.

Account enumeration and predictable usernames

How we tested it

We conducted a detailed examination of the Single Sign-On (SSO) mechanism within the openIMIS web application to identify potential security flaws. Our testing involved:

  • Utilizing Burp Suite Repeater and Comparer to send multiple authentication requests.
  • Comparing the responses to identify patterns that could reveal the existence of usernames.
  • Analyzing the system constraints and configuration, particularly the restriction on username length.

How we found it

During our assessment, we uncovered a critical security flaw that allowed for username enumeration:

  • The system required usernames to be no longer than 8 characters, simplifying the process for attackers to guess or brute-force credentials.
  • By using Burp Suite Repeater and Comparer, we noticed a distinguishable difference in the content length of responses based on whether the username existed:
    • Responses with a content length of 115 bytes indicated existing usernames.
    • Responses with a content length of 111 bytes indicated non-existing usernames.

Example responses

Non-existing username:

HTTP/1.1 200 OK
content-length: 115
{"errors":[{"message":"Please enter valid credentials","locations":[{"line":2,"column":13}],"path":["tokenAuth"]}]}

Existing username:

HTTP/1.1 401 Unauthorized
content-length: 111
{"errors":[{"message":"","locations":[{"line":2,"column":13}],"path":["tokenAuth"]}],"data":{"tokenAuth":null}}

Impact

  • Likelihood: High, due to the absence of a robust password policy and lack of rate limiting.
  • Impact: High, as attackers could enumerate usernames and use this information to launch targeted brute-force attacks.

Recommendations and mitigations

Implementation of recommendations

  1. Increased username length limit:
    • We increased the maximum length for usernames to complicate enumeration attempts. Although some constraints remained due to application configuration, the new limit significantly reduces the risk of successful username guessing.
  2. Account lockout policies:
    • Account lockout: We implemented a lockout mechanism for the authentication process, limiting the number of allowed attempts and preventing attackers from repeatedly spamming the authentication endpoint.
  3. Uniform error responses:
    • We mapped the entire authentication process and adjusted the code to process only authenticated users.
    • Consolidated error handling to ensure uniform error messages, thus:
      • Replaced specific error messages with a generic response: “Username or password is incorrect.”
      • Eliminated differences in response sizes by ensuring all error responses have the same content length, regardless of whether the username exists.

By implementing these changes, openIMIS has significantly enhanced its security posture, reducing the risk of account enumeration and brute-force attacks. These measures ensure a more secure authentication process, protecting user accounts and sensitive information from potential threats.

Outcome

By addressing these vulnerabilities, we have:

  • Increased the difficulty for attackers to enumerate usernames.
  • Enhanced the resilience of the authentication system against brute-force attacks.
  • Ensured uniform error messaging to prevent attackers from deducing valid usernames.

This holistic approach has strengthened the overall security of the openIMIS system, balancing robust protection with user convenience. Our implemented measures provide a strong defense against unauthorized access, ensuring that user accounts remain secure and the system’s integrity is maintained.

Bypassing authentication

How we tested it

We conducted a comprehensive security assessment of the openIMIS web application’s navigation and rights management system to identify potential vulnerabilities. Our testing approach included:

  • Analyzing each request and path during the authentication and authorization processes.
  • Utilizing manual inspection with tools like Burp Suite to manipulate the list of user rights and observe the effects.
  • Attempting to access unauthorized pages by modifying client-side data and JWT tokens used for backend requests.

How we found it

During our manual assessment, we discovered a critical security issue that allowed for bypassing authentication:

  • Client-side rights manipulation: We found that the list of user rights sent from the backend could be manipulated. By altering this list using Burp Suite, we were able to gain unauthorized access to pages and functionalities.
  • Accessing sensitive data: By changing the “current_user” request response and altering IDs in generated reports, we could enumerate users’ personal information and access sensitive data.
  • Open source vulnerability: Given that openIMIS is open-source, attackers could potentially obtain rights from the public GitHub repository or enumerate all possible rights, further exacerbating the issue.

Impact

  • Likelihood: High, due to the ease of manipulating client-side data and the open-source nature of the application.
  • Impact: Low, as the risk is primarily related to unauthorized access to certain pages and functionalities rather than a full system compromise.

Recommendations and mitigations

Implementation of recommendations

  1. Server-side validation of user rights:
    • Implement robust server-side validation for each request to ensure that user rights are properly checked and unauthorized access is prevented based on manipulated client-side data.
    • This ensures that even if client-side data is altered, the backend will enforce the correct permissions.
  2. Encrypt sensitive client-side data:
    • Utilize secure storage solutions such as EncryptedStorage + MMKV in combination with redux-persist to encrypt sensitive data stored on the client side.
    • This approach enhances security and performance compared to traditional async storage, protecting personal data from tampering.
  3. Unique, instance-specific keys for user rights:
    • Use unique keys for user rights that are specific to each instance of openIMIS. This prevents attackers from easily guessing or enumerating rights across different instances.
    • By ensuring keys are instance-specific, the risk of attackers leveraging publicly available information from the openIMIS repository is minimized.
  4. Ensure backend authentication for all functionalities:
    • Require proper JWT authentication for all backend functionalities, including those executed via direct requests or GraphQL.
    • This ensures that no backend process is accessible without appropriate authentication, safeguarding against unauthorized access attempts.

Mitigation

Given the complexity and resource constraints associated with fully addressing this architectural vulnerability, we implemented the following practical solutions:

  1. Comprehensive backend authentication:
    • Ensured that every available component on the frontend is secured with robust backend authentication.
    • Despite the open source nature of openIMIS making it possible for users to set up their own instances and examine the application, we focused on securing backend data and functionalities to prevent unauthorized access.
  2. Securing data and functionalities:
    • Made certain that no data is leaked and no functionality is left without backend authorization.
    • This approach prioritizes securing the backend processes, ensuring that even if frontend measures are bypassed, unauthorized access is effectively blocked.
  3. Resource optimization:
    • By addressing the issue within the existing architectural constraints, we optimized resource usage while enhancing the overall security of the application.
    • This pragmatic approach allowed us to improve security without undertaking a complete architectural overhaul, which would have been resource-intensive.

Outcome

By implementing these changes, we have:

  • Strengthened server-side validation to ensure user rights are properly enforced.
  • Enhanced the security of client-side data storage through encryption.
  • Utilized unique, instance-specific keys to mitigate the risk of rights enumeration.
  • Ensured comprehensive backend authentication to prevent unauthorized access.

This balanced approach effectively mitigates the risk of bypassing authentication, improving the security of the openIMIS web application while maintaining practical resource usage. Our solutions ensure robust protection against unauthorized access, securing both user data and system integrity.

Technologies used

Access Control authentication
Access Control burp suite authentication

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.


openIMIS security testing

Learn more about our extensive openIMIS security testing with these real-life examples:

Author

You might also like

Subscribe

Don't miss new updates!

GDPR Information*
Scroll to Top