Full Report
Facebook uses long-lived device identifiers to reduce friction for returning users to distinguish legitimate vs. illegitimate activity. A device that logs in repeatedly is considered trusted by the application, which relaxes some of the security requirements. One of the identifiers is datr. The application https://www.facebook.com/recover/account/ is used to verify an account via email or phone number. In cases where requests originate from a trusted device an alternative flow canbe used to recover the account via uploading a document. This process is automated and is supposed to help legitimate users regain access easily. A core invariant of this flow is that trusted device cannot be easily impersonated. The Facebook OAuth implementation, when interacting with the GraphQL API, can leak the datr value. When a datr is in the fields for an application with Facebook login, the machine_id is the same as this cookie. Although this data cannot be queried directly, Facebook's GraphQL allows chaining GraphQL API requests. By having multiple requests reference earlier responses, it's possible to propagate the machine_id to attacker-viewable output. Here's the full attack flow: Generate your own access code information for OAuth. This just makes the calls require less interactions from the user. Get user to visit your malicious website. Within an iframe, use the BATCH API to trigger the OAuth call that will return the machine_id and then post that to your own Facebook account. Initiate account recovery with the new datr value. This should be easy to bypass with public information and fake documents. A sick blog post on an account takeover on Facebook. I appreciate the knowledge around the importance of datr and the Batch API referencing previous values. Both of these require a lot of context, specifically on this target. They were awarded $24K for the bug, which is a solid payment. Another amazing write-up!
Analysis Summary
# Vulnerability: Facebook Trusted Device Recovery Bypass via DATR Cookie Theft
## CVE Details
- CVE ID: Not specified in the provided text. (Likely an internal finding or pending assignment)
- CVSS Score: Not specified in the provided text.
- CWE: CWE-307 (Improper Restriction of Sensitive Information Disclosure), potentially related to CWE-613 (Broken Authentication) or CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor).
## Affected Systems
- Products: Facebook (https://www.facebook.com/) OAuth Implementation, GraphQL API, and the Account Recovery flow.
- Versions: Undisclosed, prior to the fix deployed on January 27, 2025.
- Configurations: Systems relying on the `datr` cookie to establish "trusted device" status and subsequently relax security requirements during account recovery at `https://www.facebook.com/recover/account/`.
## Vulnerability Description
The vulnerability stems from two primary components: the leakage of the long-lived `datr` device identifier cookie, and the reliance of the account recovery flow on this identifier.
1. **DATR Leakage:** By exploiting a chain reaction involving the Facebook OAuth flow and the GraphQL **Batch API**, an attacker can force the system to inadvertently return the victim's secret `datr` cookie (exposed as the `machine_id` parameter) in a publicly viewable response (e.g., posted to a wall). This is achieved by referencing the initial OAuth response containing the `machine_id` within a subsequent, attacker-controlled Batch API request that posts content.
2. **Trusted Impersonation:** Once the `datr` cookie is stolen, the attacker can impersonate the victim's trusted device. This newly trusted session bypasses standard password/2FA checks during the account recovery process (`/recover/account/`) and enables an alternative flow requiring identity document verification.
3. **Recovery Bypass:** The subsequent automated document verification (using publicly available user data and AI-generated plausible documents) succeeded, allowing the attacker to reset account access credentials.
## Exploitation
- Status: Proof-of-Concept confirmed and described in detail; the vulnerability was addressed post-discovery.
- Complexity: Medium to High (Requires deep context regarding specific OAuth flows, Batch API referencing, and targeted application setup).
- Attack Vector: Network (Requires the victim to visit an attacker-controlled site, likely via an iframe injection or similar mechanism to trigger cookie exchange).
## Impact
- Confidentiality: High (The stolen `datr` is sensitive, leading directly to account takeover).
- Integrity: Critical (Full account takeover, allowing modification of account settings and data).
- Availability: Moderate (Victim loses access to the account).
## Remediation
### Patches
- The vulnerability was fixed by Facebook on January 27, 2025. Specific patch details/version numbers were not provided in the summary.
### Workarounds
- No specific vendor workarounds were provided, as the fix was released shortly after acknowledgment.
## Detection
- Indicators of Compromise: Unusual GraphQL Batch API requests referencing the OAuth endpoint concurrent with calls designed to post content to pages. Monitoring for the `machine_id` being propagated into non-secure output fields within the Graph API response chain.
- Detection Methods and Tools: Analysis of server-side logs for malformed or chained Batch API requests targeting OAuth endpoints originating from unexpected contexts (like iframes embedded on non-Facebook domains).
## References
- Vendor Advisories: N/A (Internal reporting timeline provided).
- Relevant Links:
- Youssef Sammouda's write-up (bounty awarded $24K): `hXXps://ysamm.com/` (Please use caution when visiting external researcher blogs).