CVE-2024-35232

Executive Summary

CVE-2024-35232 is a low-severity information disclosure vulnerability in the github.com/huandu/facebook Go package, which provides a client for the Facebook Graph API. The flaw allows an attacker to potentially obtain a user's access_token through error messages returned when an HTTP request fails. This token could then be used to impersonate the user or access their Facebook data. The vulnerability has been patched in version 2.7.2 of the package.

Supply Chain & Package Security

This vulnerability affects a Go package (github.com/huandu/facebook). Applications that include this package as a dependency are at risk. The attack surface is limited to scenarios where an attacker can observe or intercept error messages from the application, such as through verbose logging, API error responses, or debugging endpoints. The package is used to interact with the Facebook Graph API, making it a potential target for supply chain attacks if a malicious version were introduced.

CVSS Breakdown & Threat Level

• CVSS Score: 3.7 (Low)
• Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N
• Attack Vector (AV): Network – The vulnerability can be exploited remotely.
• Attack Complexity (AC): High – The attacker must be able to observe error messages, which may require specific conditions (e.g., verbose logging, debug mode).
• Privileges Required (PR): None – No authentication is needed to trigger the error.
• User Interaction (UI): None – The victim does not need to perform any action.
• Scope (S): Unchanged – The exploit does not affect other components.
• Confidentiality (C): Low – Only the access_token is exposed, not other data.
• Integrity (I): None – No data is modified.
• Availability (A): None – No denial of service.

Threat Level: Low. The vulnerability requires specific conditions to be exploitable and only exposes a single token.

Deep Dive & Mechanics

The github.com/huandu/facebook package handles HTTP requests to the Facebook Graph API. When a request fails (e.g., due to network issues, invalid parameters, or server errors), the package constructs an error message that includes the full request details, including the access_token parameter. This error message is then returned to the caller.

The vulnerable code path likely looks like this:

// Vulnerable code (simplified)
func makeRequest(url string, params map[string]string) (*http.Response, error) {
    req, err := http.NewRequest("GET", url, nil)
    if err != nil {
        return nil, fmt.Errorf("failed to create request: %v", err)
    }
    q := req.URL.Query()
    for k, v := range params {
        q.Add(k, v)
    }
    req.URL.RawQuery = q.Encode()
    resp, err := http.DefaultClient.Do(req)
    if err != nil {
        // Error message includes the full URL with access_token
        return nil, fmt.Errorf("request failed: %v (url: %s)", err, req.URL.String())
    }
    return resp, nil
}

The fix in version 2.7.2 sanitizes the error message to remove the access_token parameter before returning it.

Vulnerable vs. Patched Code

Vulnerable Code (before 2.7.2):

// In the error handling section of the HTTP request function
if err != nil {
    return nil, fmt.Errorf("request failed: %v (url: %s)", err, req.URL.String())
}

Patched Code (2.7.2 and later):

// Sanitize the URL to remove access_token
sanitizedURL := req.URL.String()
sanitizedURL = strings.ReplaceAll(sanitizedURL, "access_token="+params["access_token"], "access_token=REDACTED")
if err != nil {
    return nil, fmt.Errorf("request failed: %v (url: %s)", err, sanitizedURL)
}

The patched version replaces the actual token value with "REDACTED" in the error message.

Exploitation & Lab Setup

Red Team

Prerequisites:

• A Go application using github.com/huandu/facebook version < 2.7.2.
• Ability to trigger an HTTP request failure (e.g., by providing an invalid endpoint, causing a timeout, or network interruption).

Exploitation Steps:

1. Identify an endpoint in the target application that uses the vulnerable package.
2. Craft a request that will cause an HTTP error (e.g., invalid API version, malformed parameters).
3. Observe the error response. If the application returns the raw error from the package, the access_token will be visible in the URL string.
4. Extract the access_token from the error message.
5. Use the token to make authenticated requests to the Facebook Graph API on behalf of the victim.

Example Attack:

# Trigger an error by using an invalid API version
curl "https://target-app.com/api/facebook?endpoint=invalid&access_token=ACTUAL_TOKEN"
# Response might include: "request failed: ... (url: https://graph.facebook.com/v99.0/invalid?access_token=ACTUAL_TOKEN)"

Blue Team

Detection:

• Monitor for error messages containing access_token= in application logs.
• Alert on any HTTP 4xx/5xx responses that include the string access_token in the response body.
• Review application logs for unusual patterns of failed API calls to Facebook.

Prevention:

• Upgrade to github.com/huandu/facebook version 2.7.2 or later.
• Implement a global error handler that sanitizes all error messages before returning them to the client.
• Use a reverse proxy or API gateway to strip sensitive parameters from error responses.
• Enable logging of only sanitized error messages.

Indicators of Compromise (IOCs)

• Log Entries: Error messages containing access_token= followed by a 32-character alphanumeric string (Facebook token format).
• Network Traffic: HTTP responses with status codes 4xx or 5xx that include the access_token parameter in the response body.
• Application Behavior: Unusual number of failed API calls to graph.facebook.com from the same source IP.

Detection Engineering

YARA Rule

rule Detect_Facebook_Token_Leak {
    meta:
        description = "Detects error messages containing Facebook access_token"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-35232"
    strings:
        $token_pattern = /access_token=[A-Za-z0-9]{32,}/
    condition:
        $token_pattern
}

Sigma Rule

title: Facebook Access Token Leak in Error Messages
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects error messages containing Facebook access_token
author: Valters IT
date: 2024/01/01
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-35232
logsource:
    category: application
    product: generic
detection:
    selection:
        message|contains: "access_token="
    condition: selection
falsepositives:
    - Legitimate debugging with token in logs
level: medium

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-35232 Facebook Access Token Leak"; flow:to_client; content:"access_token="; http_server_body; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate:

1. Upgrade github.com/huandu/facebook to version 2.7.2 or later.
2. Rotate any access_token that may have been exposed in logs or error messages.

Long-term:

• Implement a centralized error handling middleware that sanitizes sensitive data (tokens, passwords, PII) from all error messages.
• Use a Web Application Firewall (WAF) to inspect and block responses containing access_token= in the body.
• Conduct a code review to identify other potential information disclosure vulnerabilities.
• Enable audit logging for all API calls and monitor for suspicious patterns.

Valters IT