Heute einige Sicherheits- und Störungsmeldungen, die mir die vergangenen Stunden und Tage untergekommen sind. Ein Leser fragte, ob Google gehackt worden sei – und die Nacht habe ich gesehen, dass eine Cybergruppe Google sowie T-Mobile als Opfer aufführt. Auch mit dabei: Die RedHat Repositories wurden gehackt. Und in USA wurden Admins der FEMA mutmaßlich gefeuert, weil eine Citrix-Sicherheitslücke einen Hack ermöglichte.
Redhat Repository gehackt
Das inzwischen zu IBM gehörende Unternehmen Red Hat (engl. für: ‚roter Hut') ist ein US-Softwarehersteller mit Sitz in Raleigh, North Carolina, der unter anderem die weit verbreitete Linux-Distribution Red Hat Enterprise Linux (RHEL) vertreibt und am Fedora-Projekt beteiligt ist. Redhat, ist Opfer eines Hacks geworden.
Die Nacht bin ich auf obigen Tweet gestoßen (ein Leser hat mich heute früh auch darauf hingewiesen – danke dafür), der angibt, dass das Crimson Collective behauptet, Zugriff auf über 28.000 (private) RedHat-Repositorys erhalten zu haben. Darunter sollen sich auch alle CERs (anhand des obigen Screenshots könnte CERs für 'Consulting Error Reports' stehen, diese Berichte enthalten oft Details über die Infrastruktur der Kunden) seiner Kunden und die privaten Repositories seiner 'anderen' Entwickler befinden. Andererseits heißt es in diesem Tweet, dass sich in den gestohlenen 28.000 privaten Repositories auch Anmeldedaten, CI/CD-Geheimnisse, Pipeline-Konfigurationen, VPN-Profile und Infrastruktur-Blueprints befinden sollen. Klingt alles nicht gut.
Die Kollegen von Bleeping Computer schreiben gerade, dass Redhat den Hack seiner GitHub-Präsenz bestätigt habe. "Red Hat ist über Berichte zu einem Sicherheitsvorfall im Zusammenhang mit unserem Beratungsgeschäft informiert und hat die erforderlichen Abhilfemaßnahmen eingeleitet." gab man gegenüber Bleeping Computer zu Protokoll.
Die Hacker gaben laut Bleeping Computer an, dass sie versucht hätten, Red Hat mit einer Erpressungsforderung zu kontaktieren. Sie erhielten aber eine Standard-Antwort, doch einen Schwachstellenbericht an das Sicherheitsteam zu senden. Dann versuchte die Cybergruppe das erstellte Ticket wiederholt an weitere Personen, darunter auch Mitarbeiter der Rechts- und Sicherheitsabteilung von Red Hat, zu schicken, so Bleeping Computer.
Ergänzung: Bleeping Computer schreibt hier, das Red Hat einen Angriff auf eine seiner GitLab-Instanzen, und nicht auf GitHub, bestätigt habe.
Noch ein Redhat-Klops
Die Nacht ist mir dann noch der folgende Tweet untergekommen, der auch nicht so sonderlich gut klingt. Demnach reicht ein einzelner Jupyter-Notebook-Benutzer könnte eine gesamte KI-Plattform kapern.
Ein Jupyter Notebook ist eine Open-Source-Webanwendung, mit der Data Scientists Dokumente erstellen und teilen können, die Live-Code, Gleichungen und andere Multimedia-Ressourcen enthalten. Hintergrund ist eine Sicherheitslücke (CVE-2025-10725) in Red Hat OpenShift AI. Red Hat OpenShift ist die IBM-Plattform zur Automatisierung repetitiver Aufgaben für Sicherheit, Bereitstellung & Lifecycle-Management. Und das AI dürfte für eine AI-Ergänzung stehen.
Dazu heißt es: In Red Hat Openshift AI Service wurde eine Schwachstelle CVE-2025-10725 entdeckt. Ein Angreifer mit geringen Berechtigungen, der Zugriff auf ein authentifiziertes Konto hat, beispielsweise als Datenwissenschaftler, der ein Standard-Jupyter-Notebook verwendet, kann seine Berechtigungen auf die eines vollständigen Cluster-Administrators erweitern.
Dadurch können die Vertraulichkeit, Integrität und Verfügbarkeit des Clusters vollständig kompromittiert werden. Der Angreifer kann sensible Daten stehlen, alle Dienste stören, sich zum vollständigen Cluster-Administrator hochstufen und die Kontrolle über die zugrunde liegende Infrastruktur übernehmen. Dadurch ist eine vollständige Übernahme der Plattform und aller darauf gehosteten Anwendungen möglich.
The Hacker News hat das Ganze in diesem Artikel präzisiert. Das Redhat Advisary zur Schwachstelle CVE-2025-10725 findet sich hier. Macht mehr in KI, haben sie gesagt, was kann da schon schief gehen.
Google, McDonald, Google von Scattered Spiders gehackt?
Die Tage erreichte mich bereits die Information einer ungenannt bleiben wollenden Quelle über eine private Nachricht, die kryptisch meinte, ich solle mal etwas Google beobachten. Es könnte sein, dass Google gehackt wurde, weil er glaubt, bei bestimmten Abrechnungsinformationen verdächtige Maßnahmen bemerkt zu haben. Details gab es aber keine – und ich habe es als Wasserstandsmeldung der Art "vage im Auge behalten" abgetan.
Die Nacht ist mir obiger Tweet von Cyber-Security-Analyst Dominic Alvieri, untergekommen, der möglicherweise ein weiteres Puzzleteil darstellt. Dort heißt es, dass die Cybergruppe Scattered Spiders demnächst mit einer neuen Leak-Seite auftauchen will. Als Opfer werden Google, T-Mobile, aber auch Dunkin' Donuts und McDonalds genannt.
Dunkin' Donuts hatte 2019 einen Vorfall und Mc Donalds war 2022 Opfer eines Angriffs. Zu Google gab es im Sommer Berichte, dass GMail-Konten gehackt wurden – was aber auf Nutzerfehler zurückzuführen war. Daher habe ich keine Ahnung, was Scattered Spider da leaken möchte und ob es neue Daten sind, die abgezogen wurden.
Alvieri vermutet in obigen Tweet, dass CrowdStrike die Schwachstelle gewesen sein könnte. Der Screenshot zeigt, wie ein Falcon Sensor abgeschaltet wird. Aber das Ganze ist äußerst vage.
Scans von Palo Alto Networks PAN-OS Global Protect
Laut nachfolgendem Tweet finden derzeit Scans von Palo Alto Networks PAN-OS Global Protect durch Angreifer statt. Es gebe einen deutlichen Anstieg von internetweiten Scans, die auf die kritische PAN-OS GlobalProtect-Sicherheitslücke (CVE-2024-3400) abzielen.
Es handelt sich bei CVE-2024-3400 um eine Command Injection-Schwachstelle in der GlobalProtect-Funktion der PAN-OS-Software von Palo Alto Networks für bestimmte PAN-OS-Versionen. Bestimmte Funktionskonfigurationen kann es einem nicht authentifizierten Angreifer ermöglichen, beliebigen Code mit Root-Rechten auf der Firewall auszuführen.
Ich hatte hier im Blog im April 2024 in den Beiträgen Neue Warnung vor Schwachstelle CVE-2024-3400 in Palo Alto Networks Firewalls und Warnung: Aktive Ausnutzung einer ungepatchten Schwachstelle CVE-2024-3400 in Palo Alto Networks Firewalls vor der Schwachstelle gewarnt. Im Beitrag Chinesische Hackergruppe Salt Typhoon greift weltweit (Telekommunikations-)Unternehmen an heißt es, dass die genannte Hackergruppe wohl auch die Schwachstelle für Angriffe ausnutze. Cyber Security News hat in diesem Artikel die entsprechenden Informationen über die aktuelle Kampagne zusammen gefasst.
Entlassungen nach FEMA-Hack über Citrix-Sicherheitslücke
Die Tage bin ich bei nextgov.com über den Artikel A Citrix vulnerability — suspected to have led to firings of multiple FEMA technology staff — enabled the breach, which let hackers pilfer data from FEMA servers connected to states at the southern border. gestolpert. Die FEMA (Federal Emergency Management Agency) ist die US-Behörde, die unserem Katastrophenschutz entspricht.
Der Artikel berichtet über einen Cybersicherheitsvorfall bei der Federal Emergency Management Agency (FEMA), bei dem es Hackern gelungen ist, Mitarbeiterdaten sowohl aus dem Katastrophenschutzamt als auch aus der US-Zoll- und Grenzschutzbehörde zu entwenden.
Der erste Angriff begann am 22. Juni 2025, als Hacker mit gestohlenen Anmeldedaten auf die virtuelle Desktop-Infrastruktur von Citrix innerhalb der FEMA zugreifen konnten. Die Daten wurden laut dem Screenshot von Servern der Region 6 gestohlen. Diese FEMA-Region umfasst Arkansas, Louisiana, New Mexico, Oklahoma und Texas sowie fast 70 Stammesnationen.
Der Hack soll später auch zur Entlassung von zwei Dutzend IT-Mitarbeitern der FEMA geführt haben. Das geht wohl aus internen Besprechungsnotizen und Angaben einer mit der Angelegenheit vertrauten Person hervor, schreibt das verlinkte Medium. Die Entlassungen der IT-Mitarbeiter der FEMA wurden am 29. August 2025, nach einer routinemäßigen Überprüfung der Systeme der Behörde bekannt gegeben, heißt es. Bei der Überprüfung wurde eine Schwachstelle entdeckt, "die es dem Angreifer ermöglichte, in das Netzwerk der FEMA einzudringen und die gesamte Behörde sowie die Nation als Ganzes zu gefährden", teilte das Ministerium für Innere Sicherheit damals mit. Im verlinkten Artikel werden den Entlassenen, betraf auch Führungskräfte, schwere Versäumnisse bei der IT-Sicherheit vorgeworfen.
MVP: 2013 – 2016
Boa, jetzt bin ich gespannt wie Red Hat seine Kunden informiert.
Ist doch garnix passiert, ist doch Open-Source, das ist sicher!
Der ist echt gut. Irgendwann versteht auch der Letzte, das jedes OS nun mal, auch gravierende Schwachstellen, aufweist.
Der übliche polemische Quatsch – wie so oft.
Vielleicht erstmal nen Duden kaufen, bevor du dich hier mal wieder von einer Peinlichkeit in die nächste schreibst?
> Ist doch garnix passiert, ist doch Open-Source, das ist sicher!
Man ist das stumpf und auch noch ein Strohmann-Argument.
Die Wahrheit ist: Mit OSS KANN man es auditieren. Ich KANN es ändern. Es KANN also maximal(!) so schlimm sein wie Clodes Source, wo ich diese Möglichkeit erst gar nicht habe. Ich KANN es bei Bedarf sogar selber bauen. Und das ist nunmal ein Fakt. Was man daraus macht ist ein anderes Blatt.
Wer daraus "OSS ist doch sicher" ableitet ist stumpf. Aber der, der dies als Scheinargument gegen die ungeliebte "Gegnerschaft" ins Felde führt, ist noch stumpfer.
Und: Red Hat muss bei ein paar Dingen wirklich auf die Bremse treten und bisschen aufräumen. Die systemischen Fehler scheinen dennoch gänzlich anderer Klasse zu sein als bei MS. Bonus: Ich kann ein OpenShift immerhin selber hosten. Schützt mich immerhin noch mein Netz. Mach das mal mit Azure.
Information kam bei mir bisher jedenfalls nicht an und im Kundenportal finde ich auch nichts. OpenShift haben wir allerdings nicht im Einsatz.
"Unbekannte erbeuten Identifizierungsdaten von Bonify-Nutzern. Darunter sind auch Ausweisdaten und Fotos." > https://www.golem.de/news/datenleck-schufa-tochter-bonify-bestaetigt-sicherheitsvorfall-2510-200731.html
Seiten mit Bezahlschranken im Link sind immer nicht so prickelnd. Golem gehört leider dazu.
Nachtrag: "Besuchen Sie Golem.de wie gewohnt mit Werbung und Tracking, indem Sie der Nutzung aller Cookies zustimmen. " das meine ich damit.
Der obige Artikel ist bei golem.de für mich frei abrufbar. Dass Golem, wie auch heise und viele andere Seiten inzwischen ausgesuchte Artikel nur noch gegen Abo oder Bezahlung anbieten, ist dem Trend geschuldet, dass diese ihr redaktionelles Angebot über Werbung nicht aufrechterhalten können. Das wird imho in Zukunft noch zunehmen.
Wenn man aus Sicherheitsgründen eben nicht alle Scripte zulässt ist Golem aber so nervig und ich lasse mich eben ungern tracken. Außerdem habe ich keine Lust mir über Javascript noch Malware zu holen.
Dieser ekelhafte Trend auf wirklich jeder Webseite wirklich alles über zahlreiche externe Scripte laufen zu lassen hebelt Addons wie No-Script immer mehr aus.
oder umgekehrt ;)
– wo ich ohne Javascripts zuzulassen nichts lesen kann, lasse ich es einfach und schaue wo anders !
Die Firefox-Extension "Adguard" kann solche Cookie-Banner automatisch entfernen.
Unter "Einstellungen", "Filter", "Belästigungen", die Schalter aktivieren.
Die Cookies werden dann allerdings trotzdem gespeichert.
Um diese Cookies zu blockieren braucht man noch einen Cookie-Manager und setzt damit die Cookies auf eine Blacklist.
Man braucht wirklich immer mehr Addons um vernüftig im Internet surfen zu können. Danke für den Tipp.
Da braucht es keinen Cookiemanager.
Beim Firefox gibts schon eingebaut eine Cookie Blacklist und eine Cookie Whitelist.
Da kann man z.B. einstellen: "Blockiere alle Cookies außer auf den Webseiten, wie auf der Whitelist stehen."
Wenn man die Cookies von Golem auf die Blacklist setzt, dann kann "Adguard" das Cookie-Banner nicht mehr automatisch entfernen und das Cookie-Banner spielt verrückt.
Es wird angezeigt "Zustimmung temporär erteilt" (vermutlich hat das Adguard automatisch gemacht), aber diese Zustimmung kann dann wegen der Cookie-Blacklist nicht im Cookie gespeichert werden und das Banner beendet sich nicht, auch nicht, wenn man nochmal manuell auf dne "Zustimmen" Button klickt. Nach mehreren Durchläufen verschwindet das Banner dann doch, aber dafür kann die Golem-Seite nicht mehr geladen werden mit Fehler: "Temporär nicht verfügbar".
Nach Entfernen von der Blacklist und Löschen der Cookies kann Adguard das Banner wieder automatisch entfernen.
Auch mit uMatrix kann man das Banner nicht entfernen, wenn man alle Kästchen in der Matrix sperrt.
Ebensowenig darf man im uBlock die Scripte
cdn-245.privacy-mgmt.com
cmp-cdn.golem.de
unterhalb von
privacy-mgmt.com
sperren, weil sonst Adguard das Banner nicht beenden kann.
Diese beiden Adressen scheinen die Ursache des Problems zu sein.
Golem und das Cookie-Banner speichern 14 Cookies.
3 für www. golem. de
11 für golem. de
Wenn man mit "Element entfernen" (von uBlock) alle 17 Elemente des Cookie-Banners entfernt, dann ist zwar das Banner weg, aber die eigentliche Webseite ist stark verschwommen (absichtliches Blur) und gesperrt.
Die selbe Art von Banner gibt es auch bei Heise.
Bisher ist der einzig funktionierende Weg über Adguard und ohne Cookie-Blacklist. Die Cookies tracken dann aber weiter.
Deshalb:
Im Adguard den "Tracking-Schutz" aktivieren und "Selbstzerstörung von Drittanbieter-Cookies" einschalten.
Wieviele Minuten wären da sinnvoll einzustellen? (30?)
Obwohl: Die 14 Cookies laufen ja leider unter der "golem"-Adresse, werden also vermutlich gar nicht als "Drittanbieter" gewertet.
Was nun?
Alternative:
Mit "Cookie AutoDelete" setzt man golem. de und *. golem. de auf die Greylist (also speichern erlauben, aber anhand von Regeln später wieder löschen).
In den Einstellungen setzt man die Haken bei
[x] Aufräumen der Greylist beim Domainwechel
[x] Aufräumen der Greylist beim Browser Neustart
[x] Alle abgelaufenen Cookies aufräumen
Der "Blur" ist hier ansprechbar:
.full #grandwrapper::afterIm Zweifelsfalle öffne ich eine Website in einer VM mit Snapshots und setzte die Maschine hinterher zurück.
Ich kann den Artikel ohne Anmeldung, noch sonstige Paywall was auch immer öffnen und durchlesen.
Dann hast Du irgendwann vorher "Zustimmen und weiter" geklickt.
Es wird von IDnow gesprochen, das sollte ich neulich benutzen, um eine SIM-Karte zu aktivieren, was ich (glücklicherweise?) nicht getan habe, da mir das Verfahren nicht geheuer ist.
Ich hoffe, dass das gute alte PostIdent in der Filiale sicherer ist.
Der Tweet von Alvieri "Bye Bye crowdstrike" stellt wie GB korrekt berichtet lediglich Vermutung dar. Der Screenshot ist allenfalls ein Gedankenspiel und wird unter Twitter ebenso hinterfragt. Er belegt keinesfalls wie ein Falcon-Sensor abgeschaltet wurde. Also abwarten.
Jeder EDR/XDR hatte schon diese Problem. Wenn es so sein sollte, hat es eben auch mal CS erwischt. Leider.
In Zeiten von "KI" Copy&Paste sind die meisten "Admins" nicht (mehr) in der Lage, einfache Shell Befehle und Ausgaben zu interpretieren.
?
@TBR – Anonym denkt vll. an KI-erstelltes copy-pastetes PoC und gleichzeitig an die Fähigkeit Ergebnisse nicht in Tiefe zu hinterfragen.
Dabei bin ich lange nicht nur Admin – viele können Detailprüfung hier jedoch immer noch ;-)
Erste offizielle Red Hat-Stellungnahmen ist da: https://www.redhat.com/en/blog/security-update-incident-related-red-hat-consulting-gitlab-instance
> Our next steps
> We are engaging directly with any customers who may be impacted.
Hallo Herr Born,
zwei kleine Anmerkungen.
Das Datum 29.08.2029 sollte wohl 2025 heißen ;))
Und bitte dafür sorgen, dass die Werbung nicht über dem Blogtext liegt, danke (beim iPhone über die Google App).
Datum korrigiert. Mit der Werbung ist der Anbieter dran, hat aber noch gewisse Probleme, die er hoffentlich in den Griff bekommt. Eigentlich sollte es imho behoben sein.
@Günter Born
Aktuell läuft eine größere SPAM-Welle, die vor allem aus/über Google-Mail gesendet wird. Teilweise auch Amazon. Keine Ahnung, ob das damit zu tun hat, aber selbst der NoSpamProxy hat Schwierigkeiten, dagegen anzukommen. Die Akteure scheinen immer die gleichen zu sein. Die Inhalte sind krude und es handelt sich dabei vor allem um Mails, die teilweise von den Firmen intern kommen wie weitergeleitete Abwesenheitsmitteilungen, Meldungen über aufgenommene Supportfälle usw. Die Absender (MAIL-FROM) sind pro Tag immer gleich *@zf.thesparklebar.com , *@af.fluidcom.com.br usw. aber immer in Wellen.
Es scheint sich da um einen Großteil gehackter Konten zu handeln.
Kann ich genau so bestätigen, zusätzlich auch:
ek.shirleyaraujo[.]com[.]br
Aktuell konnte ich bisher folgende Subdomains identifizieren:
ek.shirleyaraujo.com.br
zf.thesparklebar.com
af.fluidcom.com.br
ha.msw-bd.com
af.fluidcom.com.br
gh.onlinebildunchkeiten.de
Ich habe Privat und auf Arbeit im Mailserver genau die gleichen Domains in den Logs..
Nervt ziemlich.
Speziell zf.thesparklebar.com iteriert seit mehr als zwei Wochen bei mir eine Mail-Adresse durch und das über google.com. Scheint deren abuse@ nicht eirklich zu interessieren.
Es scheinen missbrauchte Google-Groups zu sein, konnte mich tatsächlich austragen. Aber es erfordert schon etwas Hingucken.
Bei uns hat sich niemand in die Groups eingetragen? warst du aktiv eingetragen ?
Hat der spam danach aufgehört?