Hacking Zero-Health Part 1

Reconnaissance

The reconnaissance phase was divided into two distinct stages: Passive Reconnaissance, which focused on information gathering without direct interaction with the backend logic, and Active Reconnaissance, which involved traffic interception and runtime behavioral analysis of the application.

Passive Reconnaissance (Information Gathering)

The objective of this phase was to map the application's attack surface using publicly available information and documentation provided by the application.

Methodology:

1. Code Review (GitHub): I examined the application's source code repository to understand the project structure, identify hard-coded secrets, and locate route definitions. This helped reveal the API's general architecture.
2. API Documentation (Swagger UI): After deploying the app following the instructions in the README file on GitHub, I discovered that the application exposes an interactive documentation interface at http://localhost:5000/api/docs. This provided a preliminary list of available endpoints and their required parameters.

Findings:

Through documentation review and static analysis, the following endpoints were identified:

• Authentication:

POST /api/register (User registration)

POST /api/login (User authentication)

• System & Debugging:

GET /api/docs/ (Swagger UI)

GET /api/debug/connection (Database connectivity check)

GET /api/debug/token (Token debugging)

• Functionality:

POST /api/chatbot/chat (AI Assistant interface)

GET /api/admin/users (Administrative user management)

GET /api/reports/generate (Report generation)

Active Reconnaissance (Traffic Analysis)

The objective of this phase was to capture "hidden" or undocumented endpoints by intercepting the traffic between the frontend and the backend.

Methodology:

1. Proxy Configuration: I configured Postman to act as an HTTP Proxy Listener on port 5555 to capture and categorize requests.
2. Browser Routing: I used the FoxyProxy browser extension to route specific traffic from Firefox to the Postman listener. A special configuration (network.proxy.allow_hijacking_localhost) was required to ensure that localhost traffic was routed correctly.
3. Application "Click-Through": I manually navigated through every feature of the application (logging in, viewing profiles, chatting with the bot) to force the frontend to reveal its API calls.

Findings:

This active interception revealed several critical endpoints that were not fully detailed in the initial documentation:

• Sensitive Data Access:

GET /api/lab-results/:id (Retrieves specific medical records - Critical Target)

GET /api/prescriptions (Lists patient prescriptions)

GET /api/messages (Retrieves private patient-doctor communications)

• User Data:

GET /api/doctors (Lists available medical staff)

GET /api/users/profile (Retrieves current user details)

• Account Management:

POST /api/auth/forgot-password (Password recovery mechanism)

With the map in hand, I moved to exploitation.

Vulnerability 1: Broken Object Level Authorization (BOLA)

Severity: High | OWASP: API1:2023

The first crack appeared in the Lab Results endpoint. In a secure app, User A should never see User B's medical records. I wanted to test if Zero Health enforced this.

The Process:

In Burp Suite:

• I logged into the application using the Victim's credentials.
• I navigated to the "My Lab Results" page, triggering a request to retrieve the user's data.

• The request GET /api/lab-results was intercepted in Burp Proxy.
• The intercepted request was sent to Burp Repeater.
• The Authorization header containing the Victim's Bearer Token was left unchanged.

The server returned a 200 OK status code and a full JSON body containing the lab results for a different patient. The application failed to validate if the authenticated user (Victim) was the owner of the requested record (ID 1).

Impact & Risk Assessment

HIPAA Violation Analysis:

This vulnerability constitutes a direct violation of the HIPAA Privacy Rule (45 CFR § 164.502), which requires covered entities to protect the privacy of Protected Health Information (PHI).

• Violation: The exposure of Lab Results constitutes an unauthorized disclosure of PHI.
• Consequence: Zero Health could face significant civil penalties.

Risk Assessment:

• Confidentiality: High - Sensitive medical data is exposed to any authenticated user.
• Integrity: Low - The attacker could view but not modify the data in this specific instance
• Availability: Low - No service disruption occurred.

CVSS v3.1 Score: 6.5 (Medium-High)

Recommended Remediation

To effectively mitigate Broken Object Level Authorization (BOLA) vulnerabilities, the following security controls should be implemented at the architectural level:

1. Enforce Server-Side Ownership Checks: The application must validate that the authenticated user has explicit permission to access the requested resource before retrieving data from the database.
2. Adopt Non-Sequential Identifiers (UUIDs): Replace predictable, sequential integer IDs (e.g., 1, 2) with cryptographically secure, random identifiers such as Universally Unique Identifiers (UUIDs) (e.g., a0eebc99-9c0b...). While this does not fix the underlying permission flaw, it prevents attackers from easily guessing valid IDs (ID Enumeration), adding a critical layer of "Defense in Depth."

Vulnerability 2: Weak Cryptography & Privilege Escalation (JWT)

Severity: Critical (9.8)

OWASP Mapping: API2:2023 - Broken Authentication / API5:2023 - Broken Function Level Authorization

Tools Used: xjwt.io (Decoder & Cracker), Burp Suite

Following the successful exploitation of the BOLA vulnerability, I investigated the authentication mechanism itself to understand how the application validates user identity. The application uses JSON Web Tokens (JWT) for stateless authentication.

Analysis (xjwt.io):

Curious about the token's structure and strength, I used the valid JWT assigned to the victim account to analyze it with the online tool xjwt.io.

Decoding: The tool successfully decoded the token header and payload, revealing critical metadata:

• Signing Algorithm: HS256 (HMAC with SHA-256), a symmetric algorithm that relies on a single shared secret key.
• User Role: The payload explicitly contained a role claim set to "patient".

Exploitation (Cracking the Secret):

Since HS256 relies on a shared secret, its security depends entirely on the complexity of that secret. I utilized the xjwt.io Cracker Tool, which performs a dictionary attack against the token's signature.

• Result: The tool cracked the signature in seconds, revealing the hardcoded secret key:
• Secret: zero-health-super-secret-key

Privilege Escalation (Token Forgery):

Armed with the valid signing secret, I performed a Vertical Privilege Escalation attack:

• I modified the payload of the victim's token, changing the role claim from "patient" to "doctor".
• I re-signed the modified token using the discovered secret zero-health-super-secret-key.
• The result was a syntactically valid JWT granting administrative/doctor privileges to the victim account.

Verification:

To confirm the privileges of the forged token, I returned to Burp Suite and replaced the original authorization header with the new "Doctor" token. I attempted to access privileged endpoints that were previously restricted:

• View All Doctors: Successfully accessed GET /api/doctors, revealing the full list of medical staff, including their hashed passwords.
• View All Patients: Successfully accessed GET /api/patients, retrieving the PII for every user in the system.
• Global Lab Results: The token granted unrestricted access to all patient lab results, bypassing the specific ownership checks that normally restrict access.

Impact & Risk Assessment

Impact Analysis:

This vulnerability represents a total compromise of the application's security model.

• Identity Theft: An attacker can forge a token for any user ID, effectively impersonating any patient or staff member without needing their password.
• Full System Takeover: By forging a token with the "admin" role, an attacker gains full control over the system, including the ability to delete users, modify medical records, or exfiltrate the entire database.
• Data Breach: Exposures in the /api/doctors and /api/patients endpoints leak sensitive PII and potentially credential hashes, enabling further offline cracking attacks.

CVSS v3.1 Score: 9.8 (Critical)

Recommended Remediation

To secure the JWT implementation, the following steps must be taken immediately:

1. Rotate the Signing Secret: The compromised secret zero-health-super-secret-key must be revoked immediately. Any existing tokens signed with this key should be invalidated.
2. Secure Secret Storage: Never hardcode secrets in the source code. Store the signing key in a secure environment variable or a dedicated secrets management vault (e.g., HashiCorp Vault, AWS Secrets Manager).
3. Enforce Strong Cryptography:

• Increase Entropy: Use a cryptographically secure random string with high entropy (at least 64 random characters) for the signing secret.
• Switch to Asymmetric Encryption: Move from HS256 (Symmetric) to RS256 (Asymmetric). In RS256, the token is signed with a private key (kept secure on the server) and verified with a public key. This prevents an attacker from forging tokens, even if they obtain the public key.

Vulnerability 3: SQL Injection (Authentication Bypass)

Severity: Critical (9.8)

OWASP Mapping: API8:2019 - Injection / A03:2021 - Injection

Endpoint Tested: POST /api/login

While assessing the authentication mechanisms, I identified that the login endpoint (/api/login) lacks proper input sanitization. The application appears to construct SQL queries by directly concatenating user input into the query string. This vulnerability, known as SQL Injection (SQLi), allows an attacker to manipulate the backend database query logic.

By injecting standard SQL comment syntax and boolean logic (OR 1=1), I forced the database to evaluate the password check as "True" for the first user in the users table, typically the Administrator.

The Process

I targeted the login API endpoint POST /api/login, which accepts JSON credentials (email and password).

• Payload Injection (Burp Suite):

I crafted a malicious JSON payload designed to alter the SQL query logic.

Theory: The injected payload likely transforms the backend query into something similar to:

SELECT * FROM users WHERE email = 'mel@test.com' OR '1'='1' --' AND password = '...'

The -- comments out the password verification, and '1'='1' ensures the condition is always true.

• Execution:

I sent the request via Postman.

• Verification (Admin Access):

The API responded with a 200 OK status code.

• Response Analysis: The JSON response contained an authentication token for the admin user. This confirms that the injection successfully logged us in as the highest-privileged user without knowing the correct password.
• Proof of Access: Using this stolen admin token, I successfully accessed the User Management Dashboard (/dashboard) and gained full control over all user accounts.

Impact & Risk Assessment

Impact Analysis:

This is a catastrophic vulnerability that compromises the entire application trust boundary.

• Authentication Bypass: Any attacker can log in as the Administrator instantly.
• Data Integrity Loss: An attacker can delete users, modify patient records, or plant backdoors.
• Confidentiality Breach: Full access to the entire database of patient records.

CVSS v3.1 Score: 9.8 (Critical)

Recommended Remediation

To permanently fix SQL Injection, the following coding practices must be enforced:

1. Use Parameterized Queries (Prepared Statements): Never concatenate user input directly into SQL strings. Use the database driver's parameterization feature, which treats user input as data rather than executable code.
2. Input Validation & Sanitization: Implement strict allow-listing for input fields. For example, ensure the email field strictly adheres to email format standards (regex) and rejects special characters like single quotes (') or dashes (--).
3. Principle of Least Privilege: Ensure the database user account used by the web application has only the minimum necessary permissions. It should not have DROP TABLE or GRANT privileges, limiting the potential damage if an injection occurs.

That's it!

That’s it for Part 1! In this initial phase, I successfully mapped the entire application surface through active and passive reconnaissance, bypassed authentication via SQL Injection to gain administrator access, escalated privileges by cracking weak JWT secrets, and exposed sensitive patient data through Broken Object Level Authorization (BOLA).

See you in Part 2!