Schlagwort: Schwachstelle

Schwachstelle

Die Perimeter-Schmelze

Warum VPN-Gateways und Legacy-Altlasten uns im Sommer 2026 einholen

Während Check Point und Palo Alto kritische bzw. hochriskante Authentifizierungsumgehungen offenlegten, zeigte FortiBleed eine parallele Schwächeklasse: massenhafte Kompromittierung durch wiederverwendete oder aus Konfigurationen extrahierte Zugangsdaten, begünstigt durch Legacy-Credential-Handling und exponierte Management-/VPN-Oberflächen. Das Perimeter-Modell erodiert strukturell. Check Point selbst beobachtete, dass dieselbe Bedrohungsakteur-Infrastruktur parallel auch Schwachstellen bei Palo Alto, Fortinet und F5 ausnutzt. Ein koordinierter Angriff auf die gesamte Gateway-Kategorie.

CVE-2026-50751 (CVSS 9.3) erlaubt unauthentifizierten Angreifern, eine VPN-Sitzung ohne gültiges Passwort aufzubauen. Entscheidend ist die Bedingung: Die Schwachstelle betrifft ausschließlich Deployments, die das veraltete IKEv1-Schlüsselaustauschprotokoll nutzen, bei denen Gateways Legacy-Remote-Access-Clients akzeptieren und kein Maschinenzertifikat verlangen. Die Ausnutzung begann bereits am 7. Mai, verstärkte sich Anfang Juni, und Check Point bewertet mit mittlerer Konfidenz, dass der Akteur finanziell motiviert ist und Qilin-Ransomware einsetzt. Das „Zero-Day“-Fenster ohne verfügbaren Patch dauerte rund einen Monat.

CVE-2026-0257 wirkt zunächst harmloser – ursprünglich nur mit CVSS 4,7 bewertet –, doch die Eskalation war dramatisch. Verwundbare PAN-OS-Versionen vertrauten jedem entschlüsselbaren Authentication-Override-Cookie, ohne zu prüfen, ob es legitim vom Gerät erzeugt wurde. Wird dasselbe Zertifikat für den HTTPS-Dienst und die Cookie-Verschlüsselung verwendet, kann ein Angreifer die öffentliche Zertifikatskette abrufen und gültige Cookies für beliebige Nutzer fälschen – inklusive Administratoren. Nach Rapid7s Proof-of-Concept und bestätigter Ausnutzung hob Palo Alto den Schweregrad auf 7,8 an; CISA nahm die Lücke am 29. Mai in den Known-Exploited-Vulnerabilities-Katalog (KEV-Katalog) auf. Bei acht von zehn betroffenen Rapid7-MDR-Kunden blieb es bei reinen Authentifizierungs-Sonden ohne vollständige VPN-Sitzung – ein Hinweis, dass die Angriffswelle noch breiter angelegt war als bislang sichtbar.

Was im Juni als Leak von rund 74.000 Fortinet-Zugangsdaten begann, hat sich zu einem der gravierendsten Vorfälle des Jahres entwickelt. Aktuelle SOCRadar-Recherchen beziffern die Kampagne auf über 430.000 angegriffene FortiGate-Firewalls weltweit mit mehr als 110 Millionen erbeuteten Zugangsdaten. Der technische Kern bleibt das Legacy-Data-Debt-Problem: Ältere Passwort-Hashes verbleiben nach einem Firmware-Update auf PBKDF2 so lange als schwächere SHA-256-Hashes gespeichert, bis sich ein Administrator nach dem Upgrade manuell neu anmeldet.

Die eigentliche Eskalation kam jedoch erst Anfang Juli: SOCRadars Threat Research Unit fand einen Operator, der gleichzeitig in den Verhandlungspanels von INC Ransom und Lynx eingeloggt war – der belastbare Beweis, dass FortiBleed direkt in die Ransomware-Ökonomie einspeist. Konkret bedeutet das: Scanning-Aktivität gegen rund 11.250 FortiGate-Portale, bestätigter Admin-Zugriff auf 409 Ziele, vollständiger Angriffsketten-Abschluss bei 354 davon, mit mindestens 12 bestätigten Ransomware-Deployments und hunderten verschlüsselten Endpunkten. Zusätzlich identifizierten die Forscher Hinweise auf einen Nextcloud-Zero-Day sowie Citrix-bezogene Artefakte, die auf eine Ausweitung über Fortinet hinaus deuten.

Drei unterschiedliche technische Ursachen – Protokoll-Legacy, Logikfehler, Krypto-Schulden – führen zum selben Ergebnis: kompromittierter Perimeter, Ransomware-Zugang. Patch-Management allein greift zu kurz. Notwendig sind die konsequente Deaktivierung von IKEv1, die Trennung von Zertifikatsverwendung pro Funktion, verpflichtende Passwort-Rotation nach jeder Krypto-Migration sowie der überfällige Umstieg von Perimeter-VPN auf identitätsbasierte Zero-Trust-Architekturen.

Quellen:

Check Point Blog: Hotfix für CVE-2026-50751
https://blog.checkpoint.com/security/check-point-releases-important-hotfix-for-vulnerabilities-in-deprecated-ikev1-vpn-protocol/

Rapid7: rapid7.com – CVE-2026-50751 & CVE-2026-0257 Threat Reports
https://www.rapid7.com/db/vulnerabilities/check-point-gaia-cve-2026-50751/
https://www.rapid7.com/blog/post/etr-rapid7-observed-exploitation-of-pan-os-globalprotect-authentication-bypass-vulnerability-cve-2026-0257/

BleepingComputer: Qilin-Attribution & FortiBleed-Berichterstattung
https://www.bleepingcomputer.com/news/security/fortibleed-credential-theft-campaign-linked-to-lynx-ransomware/

Palo Alto Networks Security Advisory
https://security.paloaltonetworks.com/CVE-2026-0257

Arctic Wolf: CVE-2026-0257 Analyse
https://arcticwolf.com/resources/blog/cve-2026-0257-pan-os-globalprotect-authentication-bypass/

SOCRadar: „FortiBleed — 86,644 Fortinet Firewalls Compromised“ https://socradar.io/blog/fortibleed-fortinet-firewalls-compromised/

Hudson Rock: „FortiBleed 75,000 Fortinet Firewalls Compromised“ https://www.hudsonrock.com/blog/fortibleed-75000-fortinet-firewalls-compromised-global-enterprises-exposed-claim-your-ethical-disclosure

The Hacker News: FortiBleed-Ransomware-Link
https://thehackernews.com/2026/07/fortibleed-credential-theft-linked-to.html

SecurityWeek: FortiBleed & Check Point Berichterstattung
https://www.securityweek.com/fortibleed-86000-fortinet-device-credentials-compromised/

News

LiteLLM: Wenn das KI-Gateway selbst zum Einfallstor wird

LiteLLM ist ein Open-Source-Proxy und sitzt zwischen LLM-Anwendungen und den großen Modellanbietern, routet Anfragen, verwaltet API-Schlüssel und setzt Rate Limits durch. Genau diese zentrale Stellung im KI-Stack macht eine kürzlich bekanntgewordene Schwachstelle besonders brisant.

CVE-2026-42271 ist eine Command-Injection-Schwachstelle mit einem CVSS-Score von 8.7, die es jedem authentifizierten Nutzer erlaubt, beliebige Befehle auf dem Host auszuführen. Betroffen sind zwei Endpunkte, die eigentlich nur dazu gedacht waren, einen MCP-Server vor dem Speichern zu testen (POST /mcp-rest/test/connection und POST /mcp-rest/test/tools/list), die aber eine vollständige Serverkonfiguration inklusive command, args und env-Feldern für den stdio-Transport entgegennahmen. Die Endpunkte waren nur durch einen gültigen Proxy-API-Key geschützt und führten die stdio-Konfiguration als Subprozess aus; ein Rollencheck auf Admin-Rechte fehlte.

Richtig kritisch wird es in Kombination mit einer zweiten Lücke: Horizon3.ai verkettete CVE-2026-42271 mit CVE-2026-48710, einer „BadHost“ genannten Host-Header-Validierungslücke in der Starlette-Bibliothek, um die Authentifizierung vollständig zu umgehen und unauthentifizierte Remote Code Execution ganz ohne Zugangsdaten zu erreichen. Die CISA hat die Lücke inzwischen wegen Hinweisen auf aktive Ausnutzung in ihren Known-Exploited-Vulnerabilities-Katalog aufgenommen.

Wer nicht sofort patchen kann, sollte zumindest die betroffenen Endpunkte am Reverse Proxy oder API-Gateway blockieren, den Netzwerkzugriff auf vertrauenswürdige Segmente beschränken und alle vom Proxy verwalteten Zugangsdaten rotieren.

Ein weiteres Beispiel dafür, dass KI-Gateways längst kritische Komponenten sind und entsprechend rollenbasiert abgesichert und gepatcht werden müssen.

Horizon3.ai-Analyse zur Verkettung mit CVE-2026-48710: https://horizon3.ai/attack-research/vulnerabilities/cve-2026-42271-chained-with-cve-2026-48710/

GitHub Security Advisory (BerriAI/LiteLLM): https://github.com/advisories/GHSA-v4p8-mg3p-g94g, https://github.com/BerriAI/litellm/security/advisories/GHSA-v4p8-mg3p-g94g

NVD-Eintrag: https://nvd.nist.gov/vuln/detail/CVE-2026-42271

CISA KEV-Katalog (Filter auf diese CVE): https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-42271

News

Der Patch-Tsunami von 2026

Wenn KI-Fuzzing das klassische Schwachstellenmanagement ertränkt

Manche Zahlen lassen sich nicht mehr wegdiskutieren. Der Juni-Patchday 2026 markiert, wie Dustin Childs von der Zero Day Initiative feststellt, seit er 2017 begonnen hat, CVEs zu zählen, den größten monatlichen Release dieser Zeit – der bisherige Rekord lag bei 177. Je nach Zählmethode kommen Microsoft-eigene 198 bis 208 CVEs zusammen; rechnet man, wie ZDI es tut, Chromium und andere Drittanbieter-Bugs hinein, erreicht die Gesamtsumme im Juni 571 CVEs, davon 38 als Critical eingestuft. Das ist kein Ausreißer. Ein Microsoft Security Engineer bringt es auf den Punkt: „Der 200+-CVE-Count ist keine Anomalie. Es ist die neue Baseline. KI-gestützte Schwachstellenfindung (Fuzzing, statische Analyse, Variantensuche) verkürzt den Zeitraum zwischen ‚ein Bug existiert‘ und ‚ein Bug wird gefunden‘ dramatisch.“ Die Asymmetrie zwischen automatisierter Forschung und manueller Verteidigung hat eine neue Qualität erreicht.

Besonders aufschlussreich ist CVE-2026-49160. Wie N-able berichtet, credited Microsoft OpenAIs Codex mit der Meldung von CVE-2026-49160, einem der drei publik gemachten Zero-Days des Monats. Technisch handelt es sich, wie das SANS Internet Storm Center erklärt, um eine „HPACK“-Kompressionsalgorithmus-Implementierung in HTTP/2 und HTTP/3, die zu einer „Kompressionsbombe“ führen kann, die exzessive Ressourcen verbraucht. Microsoft reagierte mit einer neuen Registry-Option: einer MaxHeadersCount-Registry-Einstellung, die Administratoren erlaubt, die Anzahl akzeptierter Header in HTTP/2- und HTTP/3-Anfragen zu begrenzen.

Das Problem bleibt nicht bei Windows. Dieselbe SANS-Analyse notiert, dass Microsoft Patches für 204 Schwachstellen veröffentlichte, davon 38 als kritisch eingestuft, und zusätzlich 360 verschiedene Chromium-Schwachstellen in den Edge-Browser übernommen – und zieht daraus den direkten Schluss: „Dies ist zweifellos ein geschäftigerer Patch Tuesday als üblich. Insbesondere die große Zahl gepatchter Chromium/Edge-Schwachstellen unterstreicht die Auswirkungen von KI-Werkzeugen auf die Schwachstellenfindung.“ Zeitgleich brannte es bei Cisco: die Cisco Catalyst SD-WAN Controller-Authentifizierung funktionierte nicht ordnungsgemäß, und im Mai 2026 wurde dem Cisco PSIRT eine begrenzte Ausnutzung dieser Schwachstelle bekannt – mit einem CVSS-Wert von 10.0. Die Enterprise-Landschaft ist heute so verzahnt, dass ein einziger Dienstag die Kapazität einer ganzen IT-Abteilung wochenlang bindet.

Der Zustand „vollständig gepatcht“ ist zur Fiktion geworden. Die strategische Antwort liegt in resilienten Architekturen: aggressives Network-Sandboxing und Mikrosegmentierung, kompensierende Kontrollen wie die Header-Begrenzung bei http.sys, und KI-gestütztes Patch-Testing auf Verteidigerseite. Die Zeit, in der Menschen im Monatstakt gegen Maschinen im Sekundentakt antraten, ist vorbei.

ZDI – „The June 2026 Security Update Review“
https://www.thezdi.com/blog/2026/6/9/the-june-2026-security-update-review

N-able – „June 2026 Patch Tuesday: A Record 198 CVEs…“
https://www.n-able.com/blog/june-2026-patch-tuesday-a-record-198-cves-three-zero-days-and-a-glimpse-of-the-ai-driven-future-of-vulnerability-research

SANS ISC – „Microsoft June 2026 Patch Tuesday“
https://isc.sans.edu/diary/33064

Cisco Security Advisory zu CVE-2026-20182
https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-sdwan-rpa2-v69WY2SW.html

Allgemein

Aktiv ausgenutzte Schwachstellen häufen sich: Sicherheitslage verschärft sich quer durch die IT-Infrastruktur

Browser, VPNs, SD-WAN, Domain-Controller, MFT-Server und Mobile-Plattformen: In den letzten vier Wochen haben sich die Meldungen zu bereits aktiv ausgenutzten Schwachstellen auffällig verdichtet. Bemerkenswert ist, dass die in den Quellen beschriebenen Fälle unterschiedliche Produktkategorien betreffen, darunter Browser, VPN-/Firewall-Produkte, SD-WAN-Management, Domain-Controller, MFT-Server sowie Android- und Linux-Systeme. Betroffen sind ausgerechnet die Systeme, die in Unternehmen als besonders kritische Kontrollpunkte gelten.

Mehrere Herstellerwarnungen, Medienberichte und neue bzw. aktualisierte Einträge im CISA-KEV-Katalog zeigen, dass zuletzt mehrere Schwachstellen als aktiv ausgenutzt gemeldet wurden. Dieser Eindruck wird durch den Known Exploited Vulnerabilities Catalog der US-Behörde CISA gestützt, der genau solche Fälle bündelt und ausdrücklich als Priorisierungsgrundlage für das Schwachstellenmanagement empfiehlt.

Auffällig ist vor allem, wie breit die aktuelle Welle streut. Google hatte am 9. Juni 2026 eine weitere aktiv ausgenutzte Chrome-Zero-Day in der V8-Engine geschlossen; laut SecurityWeek ist es bereits die fünfte aktiv ausgenutzte Chrome-Zero-Day des Jahres 2026. Fast zeitgleich warnte Check Point vor einer kritischen VPN-/Firewall-Schwachstelle, die laut SecurityWeek von Akteuren rund um Qilin-Ransomware als Zero-Day ausgenutzt wurde und umgehend im CISA-KEV-Katalog landete.

Hinzu kommen mehrere Fälle in klassischer Unternehmensinfrastruktur. Cisco warnte Anfang Juni vor der aktiv ausgenutzten Schwachstelle CVE-2026-20245 in Catalyst SD-WAN Controller, Manager und Validator. Laut Cisco kann ein authentifizierter Angreifer unter bestimmten Voraussetzungen durch das Hochladen einer präparierten Datei Befehle mit Root-Rechten ausführen. Wichtig für die Einordnung: Die Lücke wurde zunächst als Zero-Day bekannt, die inzwischen aktualisierte Cisco-Advisory nennt jedoch verfügbare Software-Updates und empfiehlt eine zeitnahe Aktualisierung sowie die Prüfung möglicher Kompromittierungsindikatoren.

BleepingComputer berichtet, dass die belgische Cybersicherheitsbehörde CCB vor einer aktiven Ausnutzung von CVE-2026-41089 in Windows Netlogon warnt. Microsoft erklärte gegenüber BleepingComputer jedoch, man habe derzeit keine eigenen Erkenntnisse, die diese Einschätzung bestätigen. Für Unternehmen bleibt die Schwachstelle dennoch relevant, da sie Domain Controller betrifft und laut Microsoft ohne vorherige Anmeldung zur Remote-Code-Ausführung ausgenutzt werden kann.

Auch bei exponierten Dateiübertragungs- und Plattformdiensten häufen sich die Warnungen. SecurityWeek und Help Net Security berichteten Anfang Juni über die aktive Ausnutzung von CVE-2026-28318 in SolarWinds Serv-U; CISA setzte für US-Bundesbehörden eine Frist bis zum 19. Juni 2026, um den Fall zu adressieren. Gleichzeitig warnte BleepingComputer unter Berufung auf CISA vor aktiven Angriffen auf Android und Linux, darunter eine Android-Schwachstelle, die laut Google ohne Nutzerinteraktion ausnutzbar ist, sowie eine Linux-Kernel-Lücke mit Privilegieneskalation.

Die genannten Fälle betreffen Systeme, die in vielen Unternehmen für Webzugriff, Remote-Zugänge, Netzwerkverwaltung, Dateiübertragung und Identitätsdienste eingesetzt werden.

Die betroffenen Produkte liegen in den berichteten Fällen unter anderem im Bereich Browser, Remote-Zugriff, Netzwerkverwaltung, Dateiübertragung, mobile Plattformen und Identitätsinfrastruktur. Welche Auswirkungen eine Ausnutzung im Einzelfall hat, hängt jedoch vom betroffenen Produkt, der konkreten Schwachstelle und der jeweiligen Umgebung ab.

Die aktuellen Herstellerwarnungen und CISA-KEV-Einträge sprechen dafür, aktiv ausgenutzte Schwachstellen in Patch- und Mitigationsprozessen kurzfristig zu prüfen und gegebenenfalls priorisiert zu behandeln. Wer sich im Patch- und Exposure-Management noch stark an CVSS-Werten oder festen Wartungsfenstern orientiert, läuft Gefahr, auf reale Angriffsmuster zu spät zu reagieren. Der KEV-Katalog und die jüngsten Herstellerwarnungen zeigen, dass die relevanten Fälle derzeit oft genau dort auftauchen, wo schnelle Entscheidungen über Abschottung, Mitigations und Notfall-Patching nötig sind.

https://api.msrc.microsoft.com/sug/v2.0/en-US/vulnerability/CVE-2026-41089

https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop_0153744567.html

https://documentation.solarwinds.com/en/success_center/servu/content/release_notes/servu_15-5-4-hotfix-1_release_notes.htm

https://msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2026-41089

https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sdwan-privesc-4uxFrdzx

https://source.android.com/docs/security/bulletin/2026/2026-06-01

https://www.bleepingcomputer.com/news/microsoft/critical-windows-netlogon-remote-code-execution-flaw-now-exploited-in-attacks

https://www.bleepingcomputer.com/news/security/cisa-warns-of-active-attacks-exploiting-android-linux-bugs/amp

https://www.bleepingcomputer.com/news/security/google-patches-fifth-chrome-zero-day-bug-exploited-in-attacks-this-year/amp

https://www.bleepingcomputer.com/news/security/new-cisco-sd-wan-flaw-exploited-in-zero-day-attacks-to-gain-root/amp

https://www.cisa.gov/known-exploited-vulnerabilities-catalog

https://www.cisa.gov/news-events/alerts/2026/06/08/cisa-adds-two-known-exploited-vulnerabilities-catalog

https://www.cisa.gov/resources-tools/resources/kev-catalog

https://www.helpnetsecurity.com/2026/06/08/cisa-patch-actively-exploited-solarwinds-serv-u-dos-vulnerability-cve-2026-28318

https://www.securityweek.com/check-point-vpn-zero-day-exploited-in-qilin-ransomware-attacks

https://www.securityweek.com/google-patches-5th-chrome-zero-day-exploited-in-2026

https://www.securityweek.com/solarwinds-patches-exploited-serv-u-vulnerability

Risikomanagement

Copy Fail, Dirty Frag, Dirty Pipe – Warum SELinux Ihr bester Schutz gegen Local Privilege Escalation ist

Copy Fail, Dirty Frag, Dirty Pipe: Unterschiedliche Exploits mit dem gleichen Ziel: Local Privilege Escalation (LPE). Diese Klasse von Verwundbarkeiten ist häufig anzutreffen. Wenngleich sie nicht so problematisch wie Remote Code Execution (RCE)-Schwachstellen sind, ermöglichen sie Angreifenden durch die Erhöhung der Rechte weitere Möglichkeiten zur Ausbreitung und zur Ausführung von Schadsoftware. Daraus lassen sich nun, je nach Bedarf, unterschiedliche Blickwinkel betrachten. Wir könnten technisch auf die Verwundbarkeiten eingehen und sie beschreiben. Auch spannend ist die Methodik der Sicherheitsforschenden, und ob und wie „künstliche Intelligenz“ dafür eingesetzt wurde. Oder wir könnten Unterschiede zu anderen Schwachstellen dieser Art hervorheben.

Aber in diesem Digest (und in unserer täglichen Arbeit) sind wir pragmatischer und stellen uns die Frage: Wie geht man mit diesen Schwachstellen um? Die Ausnutzung von Schwachstellen ist – außer bei bewusst implementierten Backdoors – auf die Existenz von Defekten angewiesen, sogenannten Bugs. Die Sicherheit eines Systems ist daher darauf angewiesen, dass alle Bestandteile von Hardwarelogik bis Applikation „korrekt“ funktionieren. Eine Möglichkeit, Fehler aufzufangen, ist die Verwendung von Mandatory Access Control (MAC) in Form der SELinux-Erweiterung. Dadurch können Policies festgelegt werden, die den Zugriff auf Dateien und Systemkomponenten festlegen. In dieser Konstellation reicht dann die Korrektheit der eingestellten Policies (und der SELinux-Implementierung), um einen sicheren Betrieb des Systems zu ermöglichen. Ein praktisches Beispiel bietet ein Blick auf Mobil-Betriebssysteme. GrapheneOS hat dazu einige erläuternde Hinweise.

Aus unserer Sicht unterstützen die Lücken unsere in einem vorherigen Digest formulierte Erwartung, dass sich das Security-Modell im Desktop- und Serverbereich sukzessive an das aus dem Mobilbereich anpassen wird. Auch wenn das Thema SELinux eher in den Aufgabenbereich der eingesetzten Distribution fällt, können Sie durch kleine Konfigurationen viel Angriffsoberfläche reduzieren. Sprechen Sie uns gerne an, wenn wir Sie dabei unterstützen können.

https://discuss.grapheneos.org/d/35110-grapheneos-is-protected-against-copy-fail-and-similar-vulnerabilities-by-selinux

https://en.wikipedia.org/wiki/SELinux

https://copy.fail

https://github.com/V4bel/dirtyfrag

https://infosec.exchange/@jrt/116537982697417546
News

Weitere News im Mai

Keine Publikation ohne AI

Gespannt kann man verfolgen, wie Daniel Stenberg (@bagder@mastodon.social) und das Open-Source-Projekt curl die Interaktion von KI-gestützten Werkzeugen mit Open-Source-Projekten erleben. Nach einer Welle von AI „Slop“, also KI-generierten Bugmeldungen ohne substanziellen Gehalt, welche zum temporären Schließen des Bug-Bounty-Programms führte, verzeichnet curl nun viele qualitativ hochwertige Meldungen. Im gleichen Post weist Daniel Stenberg aber auch darauf hin, dass dies ebenfalls eine höhere Last für Maintainer darstellt. Nutzen Sie dies doch als Motivation, in von Ihnen genutzten Projekten mitzuwirken oder finanziell zu unterstützen, um diese Belastung aufzufangen und die Möglichkeiten zur Verbesserung der Lösungen nutzbar zu machen.

Mythos, die von Anthropic hochgepriesene KI-basierte Exploit-Maschine, überzeugte beim Einsatz für curl weniger, vermutlich weil vorher verfügbare Werkzeuge schon viele Schwachstellen finden konnten. Für Entwickelnde und Interessierte eine empfehlenswerte Lektüre.

High-Quality Chaos
Mythos finds a curl vulnerability

DE-Zone für DNSSEC nicht verfügbar

Am 05.05. kam es zu einem kurzzeitigen Ausfall innerhalb der DE-Zone (im DNS-Jargon sind damit die „.de“-Domains gemeint) aufgrund eines Konfigurationsfehlers beim Signieren. Blackfort-tec hat eine gute Zusammenfassung, und auch DENIC hat derweil ein Post-Mortem veröffentlicht. Eine schöne Erinnerung, welche Abhängigkeiten in unserer zentralisierten Infrastruktur bestehen. Frohes Threat-Modelling!

https://blackfort-tec.de/insights/dnssec-denic-servfail-nsec3-fehler-de-zone

https://blog.denic.de/analyse-des-dns-ausfalls-vom-5-mai-2026

Android Intrusion Logging: Mehr Visibility in der Mobile-Vorfallsbehandlung

Alle Jahre wieder spendiert Google seinem Betriebssystem eine neue Version. Mit den jährlichen Versionssprüngen kommen auch regelmäßig neue Security- und Privatsphäre-Funktionen hinzu.

Neben verbesserter Betrugserkennung bei Anrufen erweitert Google in diesem Jahr Androids Advanced Protection Mode (AAPM), vergleichbar mit Apples Lockdown Mode, um neue Funktionen für die forensische Analyse von Mobilgeräten. Historisch sind die Logdaten von Androiden nicht für die forensische Analyse entwickelt, sondern für das Beheben von Fehlern. Diese Zweckentfremdung hat einige Nachteile. Logs sind im Regelfall nicht manipulationssicher, und möglicherweise relevante Ereignisse aus Forensikperspektive werden nicht geloggt, wenn sie für die Fehlerbehandlung nicht wichtig sind. Mit Android Intrusion Logging schafft Android eine neue Datenquelle für die Analyse von Mobilgeräten. Wir empfehlen besonders exponierten Personen und Organisationen mit erhöhtem Schutzbedarf die Aktivierung des Android Advanced Protction Mode (AAPM). Organisationen können über den DevicePolicyManager das Logging ebenfalls aktivieren und an eine Applikation delegieren.

https://blog.google/security/whats-new-in-android-security-privacy-2026

Android Intrusion Logging as a new source of data for consensual forensic analysis 

https://security.googleblog.com/2025/05/advanced-protection-mobile-devices.html

https://developer.android.com/reference/android/app/admin/DevicePolicyManager#DELEGATION_SECURITY_LOGGING

Schwachstelle

Stryker-Breach: Wenn das eigene MDM zur Waffe wird

Am 11. März 2026 löschte die iranisch-verlinkte Hacktivistengruppe Handala über Microsofts Intune-Wipe-Funktion nahezu 80.000 Geräte des Medizintechnik-Konzerns Stryker. Stryker meldete keine Hinweise auf Ransomware/Malware in der eigenen Umgebung. Der Angriff erfolgte durch den Missbrauch von cloud-basierten Diensten zur Administration der Endgeräte. Für die destruktive Phase war keine zusätzliche Malware auf den Endpoints nötig. Der Angriff missbrauchte legitime Intune‑Wipe‑Funktionen. Der initiale Angriffsweg, mit dem sich die Täter Zugang zur Cloud verschafften (Credential Theft), bleibt jedoch unklar.

Der Fall illustriert ein strukturelles Risiko, das viele Organisationen unterschätzen: Wenn eine einzelne Steuerungsebene Code ausrollen, Konfigurationen ändern oder Geräte auf Unternehmensebene löschen kann, ist sie kein „einfaches Endpoint-Management“ mehr, sondern verhält sich wie kritische Infrastruktur. Ein Angreifender mit Intune-Administrator-Zugang braucht keine Malware – er kann Konfigurationsänderungen verteilen, die VPN oder WLAN lahmlegen, Skripte laufen lassen, die Sicherheitsfunktionen deaktivieren, den Compliance-Status manipulieren – sodass Conditional-Access-Nutzer aussperrt werden – und gleichzeitig Endpoints aus der Ferne löschen, um die Recovery zu verlangsamen.

CISA reagierte am 18. März mit einem Alert und forderte US-Organisationen auf, ihre Intune-Umgebungen gegen ähnliche Angriffe zu härten. Die Kernempfehlungen: Einen Least-Privilege-Ansatz über Intunes RBAC realisieren, bei dem nur die tatsächlich benötigten Berechtigungen vergeben werden. Dazu kommen Multi-Faktor-Authentisierung (MFA) und privilegierte Zugriffshygiene über Conditional Access, Risk Signals und Microsoft Entra ID sowie Multi-Admin-Approval für sensible Aktionen wie Device Wipes, Anwendungsänderungen und RBAC-Modifikationen.

Das reicht allerdings nicht. Diese Empfehlungen härten zwar den administrativen Zugang, adressieren aber nicht die tieferliegende Architektur-Realität: Intune fungiert inzwischen als Teil der Identity Control Plane und muss wie Identity-Infrastruktur geplant, betrieben und überwacht werden. Konkret bedeutet das eine Tier-0-Behandlung: Für administrative Zugänge müssen phishing-resistente MFA-Verfahren wie FIDO2 oder Hardware-Token verbindlich sein; zugleich sollte der Zugriff auf die Intune-Administrationsoberfläche auf gemanagte und konforme Geräte beschränkt werden. Privilegierte Rollen dürfen nicht dauerhaft zugewiesen sein, sondern sollten über Privileged Identity Management (PIM) nur zeitlich begrenzt und nachvollziehbar aktiviert werden. Ebenso wichtig ist ein aktives Monitoring mit Alarmierung auf sicherheitskritische Ereignisse – insbesondere auf Anmeldungen privilegierter Konten sowie auf die Anlage, Änderung oder Rechteausweitung administrativer Identitäten. Schließlich müssen Audit- und Sign-in-Logs über die standardmäßigen Aufbewahrungsfristen hinaus gesichert werden, damit auch verzögert erkannte Kompromittierungen forensisch belastbar rekonstruierbar bleiben.

Das Fazit ist unbequem: Wenn eine Plattform Policies durchsetzen, Zugriff entziehen und den Betrieb auf Unternehmensebene mit Admin-Aktionen stören kann, verdient sie dieselbe architektonische Disziplin wie Identity-Systeme. Der Stryker-Breach ist der Proof of Concept dafür, dass MDM-Plattformen Tier-0-Assets sind – ob Organisationen sie so behandeln oder nicht.

https://www.bleepingcomputer.com/news/security/cisa-warns-businesses-to-secure-microsoft-intune-systems-after-stryker-breach

https://therecord.media/stryker-cyberattack-iran-hackers

Comment
byu/virtualbitz2048 from discussion
incybersecurity

https://petri.com/why-microsoft-intune-belongs-in-the-tier-0-identity-control-plane

News

Weitere News im April

BrowserGate: Clientseitige Telemetrie trifft Compliance

Die Webseite BrowserGate der Organisation Fairlinked wirft LinkedIn vor, beim Aufruf der Website systematisch auf installierte Browser-Erweiterungen zu prüfen und dabei zusätzliche Browser- bzw. Geräteinformationen zu erfassen und daraus ein weitreichendes Nutzerprofil abzuleiten. BleepingComputer hat wesentliche Teile der technischen Praxis unabhängig nachvollzogen. Demnach wurde beim Seitenaufruf ein Script geladen, das in Tests 6.236 Extensions per Resource-Probing prüfte und weitere Merkmale wie CPU-Kerne, Speicher, Bildschirmauflösung, Zeitzone, Spracheinstellungen und Batteriestatus erfasste. Nicht unabhängig verifiziert wurden dagegen die von Fairlinked behauptete konkrete Weitergabe der Ergebnisse an Dritte oder deren spezifische Nutzung.

LinkedIn bestreitet die Missbrauchs- bzw. „Spionage“-Deutung und erklärt, die Erkennung bestimmter Extensions diene dem Schutz der Plattform, der Durchsetzung der Nutzungsbedingungen, der Abwehr von Scraping sowie der Stabilität des Dienstes. Das Unternehmen erklärte außerdem, die Daten nicht zur Ableitung sensibler Eigenschaften von Mitgliedern zu verwenden.

In Europa wird in diesem Zusammenhang vor allem die Frage aufgeworfen, ob LinkedIn nach dem Digital Markets Act als „Gatekeeper“, also als Technologiekonzern mit besonderer Marktmacht, einzustufen ist, für den besondere regulatorische Vorgaben gelten. Diese Einordnung stammt bislang insbesondere aus dem Fairlinked/BrowserGate-Umfeld. Ob und in welchem Umfang daraus formelle Verfahren oder weitergehende Klagen entstehen, geben die Quellen nicht her.

Aus Compliance- und Security-Sicht zeigt der Fall, dass Extension-Scanning und Browser-Fingerprinting auch dann erhebliche Privacy-, Transparenz- und Governance-Risiken erzeugen können, wenn sie technisch mit Anti-Abuse-Zielen begründet werden. Ähnliche Techniken können zur Profilbildung und zum Tracking beitragen.

https://browsergate.eu

https://www.bleepingcomputer.com/news/security/linkedin-secretly-scans-for-6-000-plus-chrome-extensions-collects-data

https://www.linkedin.com/pulse/linkedin-accused-extensive-browser-surveillance-pdfze

https://www.msn.com/en-us/news/technology/browsergate-report-alleges-linkedin-scans-extensions-and-devices/ar-AA20kK5c

https://pipelab.org/blog/linkedin-browsergate-agent-fingerprinting

Quanten-Computer: Der Wendepunkt für Public-Key-Kryptografie ist erreicht

Noch vor wenigen Jahren galt der „quantum break of ECC“ als theoretisches Langzeitrisiko. Diese Einschätzung hat sich im März und April 2026 grundlegend geändert.

Auslöser ist eine ungewöhnlich dichte Abfolge belastbarer Signale aus Forschung und Industrie, zusammengefasst und klar eingeordnet von Filippo Valsorda (Kryptografie-Pionier und Betreuer der Kryptografie-Standardbibliothek der Programmiersprache Go). Seine zentrale Botschaft ist unmissverständlich: Die Migration zu Post‑Quantum‑Kryptografie ist kein strategisches Planungsprojekt mehr, sondern ein akutes Shipping‑Problem.

Nach Einschätzung von Filippo Valsorda erleben wir einen Risikokipppunkt. Selbst wenn sich einzelne Prognosen im Rückblick als zu pessimistisch erweisen sollten, ist Untätigkeit inzwischen die riskantere Entscheidung. Post‑Quantum‑Kryptografie ist seit 2026 weder Forschungs‑ noch Vorbereitungsthema – sie ist operative Sicherheitsarbeit.

https://words.filippo.io/crqc-timeline

Aktive Ausnutzung der Langflow-Schwachstelle CVE-2026-33017

In der Open-Source-Plattform Langflow, einem weitverbreiteten Werkzeug zum visuellen Erstellen und Betreiben von KI-Agenten und KI-Workflows, wurde im März 2026 eine kritische Sicherheitslücke unter der Kennung CVE-2026-33017 öffentlich bekannt. Die Schwachstelle ermöglicht es Angreifenden, ohne jegliche Authentifizierung beliebigen Programmcode auf betroffenen Servern auszuführen – ein Szenario, das in der Informationssicherheit als unauthentifizierte Remote Code Execution (RCE) klassifiziert wird und die höchste Risikostufe darstellt. Die US-amerikanische Cybersicherheitsbehörde CISA hat die Schwachstelle in ihren Katalog der nachweislich aktiv ausgenutzten Sicherheitslücken (Known Exploited Vulnerabilities, KEV) aufgenommen, was bedeutet, dass reale Angriffe in freier Wildbahn beobachtet wurden, und nicht lediglich ein theoretisches Risiko besteht.

Der technische Kern der Schwachstelle liegt in einem fundamentalen Design- und Implementierungsfehler im Zusammenspiel zwischen öffentlich zugänglichen Funktionen und der internen Code-Ausführung. Langflow bietet einen sogenannten „Public Flow Build“-Endpunkt an, der bewusst ohne Anmeldung erreichbar ist, damit öffentliche Flows – also vorgefertigte KI-Workflows – von externen Nutzern angestoßen werden können. Der Endpunkt ist absichtlich öffentlich gestaltet, weil er eine legitime Geschäftsfunktion – das Teilen und Ausführen öffentlicher Flows – bedient. Das eigentliche Versäumnis liegt darin, dass eine öffentlich zugängliche Funktion ausführbare, von außen kontrollierbare Definitionen annimmt und diese ohne ausreichende Validierung oder Isolation zur Ausführung bringt. Es handelt sich also um ein architektonisches Problem an der Schnittstelle zwischen Offenheit und Sicherheit.

Öffentlich zugängliche Funktionen, die „Code als Daten“ entgegennehmen und verarbeiten, stellen ein inhärent hohes Risiko dar. Die Kombination aus einem unauthentifizierten Endpunkt, der Annahme ausführbarer Definitionen von außen und einer fehlenden Sandbox bei der Code-Ausführung bildet genau jenes toxische Muster, das CVE-2026-33017 so gefährlich und so einfach ausnutzbar macht.

https://www.heise.de/news/Jetzt-patchen-Schadcode-Attacken-auf-KI-Tool-Langflow-beobachtet-11226852.html

https://www.cve.org/CVERecord?id=CVE-2026-33017

https://github.com/langflow-ai/langflow/security/advisories/GHSA-vwmf-pq79-vjvx

https://github.com/advisories/GHSA-rvqx-wpfh-mfx7

Iranische Hacker veröffentlichen private E-Mails von FBI-Direktor Kash Patel

Eine dem iranischen Staat zugerechnete Hackergruppe hat private E-Mail-Konten von FBI-Direktor Kash Patel kompromittiert und Teile der erbeuteten Korrespondenz öffentlich ins Netz gestellt. Das FBI hält technische Details zum konkreten Vorfall bislang zurück. Das US-Außenministerium reagierte mit einer öffentlichen Auslobung einer Belohnung von bis zu zehn Millionen US-Dollar für Hinweise, die zur Identifizierung oder Lokalisierung der verantwortlichen iranischen Cyber-Akteure führen.

Der Vorfall unterstreicht, wie staatlich gesteuerte Hackergruppen zunehmend persönliche Kommunikationskanäle hochrangiger Beamter ins Visier nehmen, um politischen Druck auszuüben. Selbst private Accounts von Entscheidungsträgern sind inzwischen ein erstrangiges Ziel geopolitisch motivierter Cyberoperationen.

https://therecord.media/fbi-confirms-theft-of-directors-personal-emails-iran-group

https://therecord.media/iran-hackers-state-department-reward

EU Top Officials & Signal

Politico berichtet, dass die Kommission eine Signal‑Gruppe hochrangiger Beamter auflösen ließ – präventiv, ohne bestätigte Kompromittierung.

Doch warum ist ausgerechnet Signal ein Problem – ein Messenger, der für seine starke Verschlüsselung bekannt ist? Die Antwort gilt nicht nur für Signal, sondern für nahezu alle privaten Messenger-Apps: Sie wurden für den persönlichen Gebrauch entwickelt und optimiert. Für den Einsatz in institutionellen Umgebungen – insbesondere in Regierungen und Behörden – fehlen ihnen entscheidende Funktionen:

  • zentrales User Management – Es gibt kein Onboarding/Offboarding durch IT-Administratoren.
  • Audit Trail – Es besteht keine nachvollziehbare Protokollierung von Aktivitäten.
  • Compliance-Archivierung – Es existiert keine rechtskonforme Aufbewahrung dienstlicher Kommunikation.
  • MDM-Integration – Private Messenger-Apps lassen sich als App per MDM verteilen, bieten aber keine nativen Enterprise‑Admin‑Funktionen wie zentrales User‑Management, Audit/Archive oder eDiscovery.
  • Geräte-Policy-Enforcement – Private Messenger-Apps selbst erzwingen keine institutionellen Richtlinien. Diese lassen sich nur über Geräte‑ und App‑Policies der MDM/EMM‑Plattform abbilden.
  • Sicherheitsfreigabe-Verknüpfung – Es erfolgt keine Kopplung an Freigabestufen oder Berechtigungskonzepte.
  • Kontrollierte Gruppenverwaltung – Es liegt keine abgesicherte Steuerung von Gruppenmitgliedschaften vor.
  • Forensische Auditierbarkeit – Es fehlt eine zentrale Auditierbarkeit/Archivierung. Forensik ist auf Endpoint‑Ebene möglich, aber stark vom Gerät und den Governance‑Rahmenbedingungen abhängig.

Kurz gesagt: Das Signal-Protokoll ist nicht das Problem. Das Problem ist, dass ein Werkzeug, das Einzelpersonen vor Überwachung schützen soll, für die gesteuerte und rechenschaftspflichtige Kommunikation einer Institution schlicht nicht vorgesehen ist.

https://www.politico.eu/article/top-eu-officials-signal-group-chat-hacking-fears

Allgemein, Schwachstelle

OWASP Top 10:2025 – Wenn Framework-Komplexität zum Geschäftsrisiko wird

Die OWASP Top 10 sind eine regelmäßig veröffentlichte Rangliste der zehn kritischsten Sicherheitsrisiken für Webanwendungen. Sie dienen als eine Art „Übersichtskarte“ für typische Schwachstellen wie Einschleusen von Code, Probleme bei der Zugriffskontrolle (Broken Access Control) oder fehlerhafte Sicherheitskonfigurationen. Erstellt und gepflegt wird die Liste vom gemeinnützigen Open Web Application Security Project (OWASP). Selbstverständlich bleibt die Entwicklung bei der Top 10 der Webschwachstellen nicht stehen. Aus diesem Grund wird im Abstand von etwa drei bis vier Jahren eine neue Version der Liste veröffentlicht. Die Version von 2021 wurde entsprechend im November vergangenen Jahres durch die OWASP Top 10:2025 ersetzt.

Dabei markiert die Veröffentlichung der OWASP Top 10:2025 einen Wendepunkt in der Applikationssicherheit.
Während die Version 2021 den Grundstein für ein modernes Risikoverständnis gelegt hat, reflektiert das Update 2025 eine Realität, in der Webanwendungen kaum noch „from scratch“ entwickelt werden.

Moderne Webanwendungen werden heute hochgradig modular aus mächtigen Frameworks und einer Vielzahl an Drittanbieter-Bibliotheken zusammengebaut. Diese Bausteine bringen wiederum ihre eigenen, unüberschaubaren Abhängigkeitsketten mit sich.

Damit verschiebt sich das Risiko und es geht nicht mehr nur um den Code, den die Entwickler selbst schreiben, sondern um die Integrität und Sicherheit des gesamten Ökosystems, auf dem die Webanwendung fußt.

Die wesentlichen Verschiebungen

Der Vergleich zwischen 2021 und 2025 zeigt, dass Angriffsvektoren, die nur eine bestimmte Schwachstellenklassifikation repräsentieren, in systemische Kategorien überführt wurden.

Für IT-Verantwortliche und Sicherheitsverantwortliche ist das wichtige Signal: Sicherheit lässt sich nicht mehr über eine einfache Checkliste von Schwachstellen-Typen verwalten.

1. Die Einordnung von SSRF in die Zugriffskontrolle (A01)

Ein markantes Detail ist der Wegfall von Server-Side Request Forgery (SSRF), zu Deutsch “server-seitige Anfragenfälschung”, als eigenständige Top-10 Kategorie. Das bedeutet keine Entwarnung für dieses Risiko. Vielmehr folgt das OWASP der Erkenntnis, dass SSRF im Kern ein strukturelles Problem der Broken Access Controls ist.

Eine Herausforderung dabei ist, dass automatisierte Scanner zwar teilweise technisch in der Lage sind, die Endpunkte zu ermitteln, aber die zugrundeliegende Geschäftslogik und den Kontext nicht verstehen können. Die Scanner Software allein kann deshalb gar nicht umfassend bewerten, ob ein für SSRF anfälliger Endpunkt missbraucht werden kann, um interne Systemressourcen, Metadaten oder sensible Informationen zu exfiltrieren. Hierfür bedarf es der Zusammenarbeit von Mensch und Maschine und einer kontextsensitiven Einschätzung eines Security Auditors oder Pentesters.

2. Vertrauen ALS GEWAGTE Strategie – Software Supply Chain (A03)

Neu priorisiert wurde die Integrität von Code und Software Dritter. Angesichts der Tatsache, dass moderne Webanwendungen zu einem Großteil aus fremdem Code bestehen, ist die Software Supply Chain eine kritische Sollbruchstelle geworden. Angreifende zielen heute immer öfter darauf ab, die Zulieferer- und Build-Pipeline anzugreifen, anstatt sich in die Komplexität der Custom Features einer Webanwendung einzuarbeiten.

Die Nutzung von Frameworks und Bibliotheken vereinfacht im Alltag die Entwicklung von Webanwendungen und klingt nach einer massiven Zeitersparnis, jedoch verstecken sich Schwachstellen oft tiefer in der Integration dieser Frameworks und Bibliotheken.

3. Resilienz unter Last – Mishandling of Exceptional Conditions (A10)

Neu in der Liste ist das „Mishandling of Exceptional Conditions (A10)“. Hier geht es um die Stabilität des Systemsselbst. Wie verhält sich die Webanwendung bei Fehlern zur Laufzeit oder unter extremen Bedingungen?
Ein System, das im Fehlerfall „offen“ bleibt (Fail-Open), stellt ein massives Sicherheitsrisiko dar, das oft erst durch gezielte Stress-Simulationen oder einem kontextsensitiven manuellen Pentest sichtbar wird.

Fazit: Sicherheit als begleitender Qualitätsprozess im gesamten Software Development Life Cycle (SDLC)

Die OWASP Top 10:2025 zeigt deutlich, wie wichtig es wird, eine kontextsensitive Bewertung durch Experten vornehmen zu lassen. So lässt sich sicherstellen, dass die komplexen Webanwendungen in der Praxis standhalten und Angriffsversuche applikationsseitig ordentlich vereitelt werden. Im Idealfall versteht auch die Sicherheit bei modernen Webanwendungen im Jahr 2026 als Prozess, der den gesamten Software Development Life Cycle begleitet.

Woher kommen eigentlich Zero-Days?
Schwachstelle, Zeroday

Woher kommen eigentlich Zero-Days?

Nachtrag (2025-05-16): Nach Hinweisen einiger Lesender haben wir die Definition von Zero-Days am Anfang des Artikels angepasst. Vorher benannten wir Zero-Days als „Lücken, die am heutigen Tage bekannt werden“. Dies sorgte daraufhin intern für eine (akademische) Diskussion zu dem Thema, die allerdings am Ziel des Beitrages vorbei ging. Insbesondere war dies verwirrend im Kontext des referenzierten Beitrages der GTIG, deren Definition wir in der aktuellen Version übernommen haben. Vielen Dank für die Hinweise!

Sicherheitslücken ohne verfügbaren Patch oder Mitigation, die bereits ausgenutzt werden, nennt man Zero-Days. Besonders interessant sind diese Lücken offensichtlich für Angreifende, wenngleich auch Admins Diese im Blick behalten sollten. Aber wer findet eigentlich Zero-Days?

Ein prominenter Player in dem Bereich ist die Google Threat Intelligence Group (GTIG). Im Jahresbericht zu 2024 zieht sie Bilanz zu Zero-Day-Aktivität und -Attribution und was man daraus lernen kann. Neben einigen durchaus spannenden Zahlen zum Thema „ausgenutzte Systeme“ war für uns vor allem der Absatz zu Attribution relevant. Solche Zahlen sind zwar grundsätzlich mit Vorsicht zu genießen, da eine direkte Zuordnung oft sehr schwierig ist. Die GTIG hat „nur“ 34 der 75 erkannten Zero-Days attributiert. Wenn man die Methodik akzeptiert, dann ordnet sie 15 Ausnutzungen staatlichen Akteuren zu. Weitere acht wurden durch kommerzielle Anbieter, wie z. B. Cellebrite, genutzt.

Da auch diese Händler oftmals für staatliche Akteure tätig sind, kann man einen beunruhigenden Trend erkennen: Die Ausnutzung von Zero-Days wird vermehrt durch staatliche Akteure gesteuert und finanziert, also auch direkt durch Steuergeld.

https://www.heise.de/news/Steuergeld-finanziert-Angriffe-mit-Zerodays-10367137.html

https://cloud.google.com/blog/topics/threat-intelligence/2024-zero-day-trends?hl=en

Hier gibt es weitere News aus dem Mai