CVE-2024-50644

Executive Summary

CVE-2024-50644 is a critical authentication bypass vulnerability in the zhisheng17 blog application, version 3.0.1-SNAPSHOT. The vulnerability allows an unauthenticated attacker to access any API endpoint without providing a valid token. This effectively bypasses all authentication and authorization controls, granting the attacker full read and write access to the application's data and functionality. The CVSS score is 0.0 due to incomplete NVD data, but based on the nature of the flaw, the actual severity is critical. The vendor has not released a patch, and no official advisory exists. This report provides a comprehensive analysis, detection rules, and exploitation guidance.

Supply Chain & Package Security

This vulnerability is in a Java-based web application (likely Spring Boot). It is not an NPM, PyPI, Go, or Ruby package. The risk is primarily to the application's runtime environment and its data, not to the software supply chain of a package manager.

CVSS Breakdown & Threat Level

The official CVSS score is 0.0, but this is due to incomplete data. Based on the vulnerability description, a realistic CVSS v3.1 vector is:

• Attack Vector (AV): Network (N) - The vulnerability is exploitable remotely.
• Attack Complexity (AC): Low (L) - No special conditions are required.
• Privileges Required (PR): None (N) - No authentication is needed.
• User Interaction (UI): None (N) - No user action is required.
• Scope (S): Unchanged (U) - The vulnerable component is the only one affected.
• Confidentiality (C): High (H) - Full access to all data.
• Integrity (I): High (H) - Full write access to all data.
• Availability (A): High (H) - Ability to delete or corrupt data.

Calculated Score: 9.8 (Critical)

Threat Level: Critical. The vulnerability is trivial to exploit and provides complete control over the application.

Deep Dive & Mechanics

The zhisheng17 blog application uses a token-based authentication mechanism for its REST API. The vulnerability lies in the authentication filter or interceptor that is supposed to validate the presence and validity of a token (e.g., JWT) in the Authorization header of incoming requests.

Root Cause: The application fails to enforce authentication on certain API endpoints. This could be due to:

1. Missing Filter: The security filter chain does not cover all API routes.
2. Incorrect Configuration: The filter is configured to allow unauthenticated access to specific paths (e.g., /api/public/**) but the configuration is too broad or misapplied.
3. Logic Flaw: The filter checks for the presence of a token but does not validate it, or it accepts an empty/null token as valid.

Attack Vector: An attacker sends an HTTP request to any API endpoint (e.g., /api/admin/users, /api/posts, /api/settings) without including an Authorization header or with an invalid/empty token. The server processes the request as if it came from an authenticated administrator.

Impact:

• Data Breach: Read all blog posts, user data, comments, and configuration.
• Data Manipulation: Create, modify, or delete any content.
• Privilege Escalation: Gain administrative access to the application.
• Remote Code Execution (Potential): If the API allows file uploads or command execution, the attacker could achieve RCE.

Vulnerable vs. Patched Code

Since no patch is available, we can only describe the vulnerable code pattern.

Vulnerable Code (Conceptual - Spring Security Filter):

// Vulnerable: No authentication check on /api/**
@Override
protected void configure(HttpSecurity http) throws Exception {
    http
        .authorizeRequests()
            .antMatchers("/api/**").permitAll()  // <-- VULNERABLE: Allows all API access
            .anyRequest().authenticated()
        .and()
        .httpBasic();
}

Patched Code (Conceptual):

// Patched: Requires authentication for /api/**
@Override
protected void configure(HttpSecurity http) throws Exception {
    http
        .authorizeRequests()
            .antMatchers("/api/public/**").permitAll() // Only public endpoints
            .antMatchers("/api/**").authenticated()    // <-- FIXED: Requires auth
            .anyRequest().authenticated()
        .and()
        .httpBasic();
}

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• A running instance of zhisheng17 blog 3.0.1-SNAPSHOT.
• curl or any HTTP client.

Exploitation Steps:

1. Identify the target: Find a vulnerable instance (e.g., using Shodan dorks).

2. Access an API endpoint without a token:

   curl -X GET http://target.com/api/admin/users
   

   If the vulnerability exists, the server will return the list of users without asking for authentication.

3. Perform privileged actions:

   # Create a new admin user
   curl -X POST http://target.com/api/admin/users \
     -H "Content-Type: application/json" \
     -d '{"username":"attacker","password":"P@ssw0rd!","role":"admin"}'
   
   # Delete all posts
   curl -X DELETE http://target.com/api/posts
   

No Exploit-DB code was provided.

Blue Team (Detection & Forensics)

Detection:

• Monitor for API requests to sensitive endpoints (e.g., /api/admin, /api/settings) that lack an Authorization header.
• Look for a high volume of 401 Unauthorized responses followed by 200 OK from the same IP (indicating a bypass attempt).
• Check web server logs for requests to /api/** with no Authorization header.

Forensics:

• Examine application logs for unauthorized access to admin functions.
• Check for newly created users or modified content without a corresponding authenticated session.
• Review database logs for unusual queries or modifications.

Indicators of Compromise (IOCs)

• Network:
  • HTTP requests to /api/admin/*, /api/users, /api/settings without an Authorization header.
  • Unusual POST/PUT/DELETE requests to API endpoints from unknown IPs.
• Host:
  • New user accounts in the application database.
  • Modified or deleted blog posts.
  • Changes to application configuration files.
• Logs:
  • Web server logs showing 200 OK responses for API requests without a token.
  • Application logs showing "Authentication bypass" or similar errors (if logging is enabled).

Detection Engineering

YARA Rule

rule Detect_Zhisheng17_AuthBypass_Logs {
    meta:
        description = "Detects log entries indicating authentication bypass in zhisheng17 blog"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-50644"
    strings:
        $s1 = "Authorization" nocase
        $s2 = "/api/" nocase
        $s3 = "200" nocase
    condition:
        all of ($s1, $s2, $s3) and #s1 == 0
}

Sigma Rule

title: Authentication Bypass to zhisheng17 Blog API
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects HTTP requests to zhisheng17 blog API endpoints without an Authorization header.
author: Valters IT
date: 2024/01/01
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-50644
logsource:
    category: webserver
    product: apache
    service: access_combined
detection:
    selection:
        cs-uri-stem|startswith: '/api/'
        cs-uri-stem|contains: 
            - '/admin'
            - '/users'
            - '/settings'
            - '/posts'
    filter:
        cs-headers|contains: 'Authorization'
    condition: selection and not filter
falsepositives:
    - Legitimate public API endpoints (if any)
level: high

Suricata Rule

alert http $EXTERNAL_NET any -> $HOME_NET any (
    msg:"CVE-2024-50644 - zhisheng17 Blog API Authentication Bypass";
    flow:to_server,established;
    content:"/api/"; http_uri;
    content:!"Authorization"; http_header;
    classtype:attempted-admin;
    sid:1000001;
    rev:1;
)

Remediation & Mitigation

Immediate Actions:

1. Isolate the application: If possible, take the vulnerable instance offline or restrict network access to it.
2. Implement a WAF rule: Block all requests to /api/ that do not contain a valid Authorization header.
3. Apply a virtual patch: If using a reverse proxy (e.g., Nginx, Apache), add a rule to reject requests to /api/ without a token.

Long-term Fix:

1. Update the application: Contact the vendor (zhisheng17) for a patched version. If none is available, consider forking the project and applying the fix yourself.
2. Code Fix: Modify the security configuration to require authentication for all API endpoints except explicitly public ones (e.g., /api/public/**).
3. Implement proper token validation: Ensure the application validates the token's signature, expiration, and issuer.

Valters IT signature:

Report generated by Valters IT DevSecOps & CTI Expert System