Die US-amerikanische IT-Sicherheitsbehörde CISA warnt vor derzeit laufenden Angriffen auf Schwachstellen in Android, Linux und Sitecore. IT-Verantwortliche sollten die bereitstehenden Updates installieren, um die Lücken abzudichten.

Details nennt die CISA in ihrer Meldung nicht, sondern schreibt lediglich, auf welche Sicherheitslücken bereits Angriffe beobachtet wurden. Etwa im Linux-Kernel attackieren bösartige Akteure eine Time-of-Check Time-of-Use (TOCTOU)-Schwachstelle. Der Beschreibung nach handelt es sich um eine Race-Condition bei den Posix-TImern in den Funktionen handle_posix_cpu_timers() und posix_cpu_timer_del() (CVE-2025-38352 / EUVD-2025-22297, CVSS 7.4, Risiko „hoch„). Informationen zu der Schwachstelle sind seit dem 22. Juli des Jahres bekannt; Patches stehen bereit, die die Linux-Distributionen seitdem aufnehmen konnten. Anfällig sind laut Enisa-Eintrag die Linux-Versionen bis 2.6.36, 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3, 6.16-rc2 und 6.16.

Im Android-Betriebssystem können Angreifer aufgrund einer Use-after-Free-Schwachstelle aus der Chrome-Sandbox ausbrechen und system_server von Android attackieren. Das mündet in einer Rechteausweitung und erfordert keinerlei Nutzerinteraktion (CVE-2025-48543 / EUVD-2025-26791, CVSS 8.8, Risiko „hoch„). Die Lücke hat Google mit den Updates zum September-Patchday geschlossen. Sie betrifft Android 13, 14, 15 und 16.

CMS-Schwachstelle missbraucht

Zudem bestätigt die CISA auch den Missbrauch einer Schwachstelle im Sitecore-CMS. Es handelt sich um eine Schwachstelle des Typs „Deserialisierung nicht vertrauenswürdiger Daten“, durch die Angreifer Schadcode einschleusen können, der zur Ausführung gelangt (CVE-2025-53690 / EUVD-2025-26629, CVSS 9.0, Risiko „kritisch„). Die hat Mandiant bei der Untersuchung eines Angriffs entdeckt. Sie basiert auf einer fehlerhaften Konfiguration mit Beispiel-Maschinen-Schlüsseln in ASP.NET. Gegenmaßnahmen finden sich in unserer Schwachstellenmeldung.

Da Aktualisierungen zum Stopfen der Sicherheitslecks bereitstehen, sollten IT-Verantwortliche nicht zögern, diese auch anzuwenden.

(dmk)

Eine Zertifizierungsstelle (CA) aus Kroatien hat mehrere Zertifikate für die IP-Adresse 1.1.1.1 ausgestellt, ohne die notwendige Genehmigung dafür eingeholt zu haben. Die Adresse gehört zu Cloudflares frei nutzbarem DNS-Server, der auch Anfragen per verschlüsselter HTTP-Verbindung entgegennimmt. Publik wurde der Lapsus eher zufällig, die CA leistete sich jedoch noch mehr Schnitzer.

Digitale Zertifikate sind essenziell für die sichere Kommunikation im Web, daher ist ihre Vergabe an strenge Richtlinien gebunden. Die kroatische CA Fina hielt sich an diese Richtlinien offenbar nicht immer – und das, obwohl sie zumindest in Microsoft-Browsern und der EU-Infrastruktur für qualifizierte Webseiten-Zertifikate (QWAC) als vertrauenswürdig gilt.

Ein Nutzer des Forums Hacker News fand ein von Fina ausgestelltes Zertifikat, das ihm seltsam vorkam und mit dem er eine weitreichende Untersuchung in Gang setzte. Es war für die IP-Adresse 1.1.1.1 ausgestellt, die das US-Unternehmen Cloudflare seit 2018 für einen freien DNS- und VPN-Dienst verwendet. Dieser unterstützt auch DNS over HTTPS (DoH) und braucht dafür ein gültiges Zertifikat. Das stammt jedoch nicht von Fina, sondern von DigiCert – die kroatische CA hatte die IP-Adresse offenbar nur für Testzwecke verwendet.

Unerlaubte Test-Zertifikate für Cloudflare-IP

Das hätte sie aber nicht gedurft. Denn: Um ein digitales Zertifikat zu erhalten, muss der Antragsteller seine Berechtigung am Subjekt des Zertifikats – üblicherweise eines vollqualifizierten Domainnamens (FQDN) oder einer IP-Adresse – nachweisen. Das gilt auch, wenn die CA selber ein Zertifikat ausstellt, etwa zu Testzwecken. Und so landete der Vorgang rasch auf der zuständigen Mailingliste des Browserherstellers Mozilla und rief die Experten auf den Plan.

Die stellten fest, dass es beileibe nicht beim Einzelfall geblieben war – neben einem halben Dutzend Zertifikaten für 1.1.1.1 hatte Fina auch eines für die von Oracle verwaltete IP-Adresse 2.2.2.2 ausgestellt, einige für private IP-Adressen aus dem Netz 10.0.0.0/8 – und bisweilen hatten die Kroaten erstaunliche Kreativität beim Umgang mit Hostnamen bewiesen. Und das nicht seit gestern: Die Historie der 1.1.1.1-Testzertifikate beginnt im Februar 2024, mithin vor anderthalb Jahren.

Cloudflare zürnt, CA wiegelt ab

Der US-Konzern ist wenig amüsiert und findet in einem ausführlichen Blogeintrag deutliche Worte für den Fauxpas: Es handele sich um einen „inakzeptablen Sicherheitsverstoß der Fina CA“. Wer ihr weiter vertraue, solle unmittelbar handeln, um diese Entscheidung zu überprüfen – offenbar ein Wink mit dem digitalen Zaunpfahl gen Redmond. Zudem führte Cloudflare eine Untersuchung durch, die weitere Sicherheitsverstöße ans Licht bringen sollte, etwa durch „Man in the Middle“-Angriffe oder BGP-Hijacks der IP-Adresse 1.1.1.1.

Cloudflare lobte zudem das Programm der „Certificate Transparency“, das seit Jahren CAs verpflichtet, jedes ausgestellte Zertifikat in ein „Ewiges Logfile“ zu schreiben, das über Dienste wie Censys oder crt.sh einsehbar ist. Doch auch deutliche Selbstkritik erspart der Internetkonzern sich nicht: Man habe das fälschlich ausgestellte Zertifikat zu spät bemerkt und werde nun zusätzliche Maßnahmen ergreifen, um künftig schneller von derlei Problemen zu erfahren.

Die betroffene CA hatte sich zunächst gegenüber Cloudflare gerechtfertigt, tat dies später aber auch öffentlich im Mozilla-Bugtracker. Man habe die IP-Adresse versehentlich zu Testzertifikaten hinzugefügt, die jedoch nie außerhalb der Fina-eigenen Testumgebung in Gebrauch gewesen seien. Alle Zertifikate seien mittlerweile zurückgezogen („revoked“) und werde interne Prozeduren und Dokumentation verbessern.

Auswirkungen: für Nutzer gering, Verursacher muss zittern

Ob dieses Versprechen den gestrengen Hütern der Web-PKI genügt, darf man getrost bezweifeln. Die im CA/Browser Forum (CAB) organisierten Hersteller von Webbrowsern und Vergabestellen digitaler Vertrauensnachweise nehmen Verstöße wie diesen nie auf die leichte Schulter. Microsoft bekommt dies derzeit zu spüren und muss wegen eines Tippfehlers bis November Millionen Zertifikate zurückziehen, anderen CAs entzogen CAB-Mitglieder kurzerhand das Vertrauen komplett.

Für die kroatische CA steht immerhin die Verankerung in Microsofts und Adobes Produkten auf dem Spiel und auch die Betreiber der EU-Infrastruktur für qualifizierte Webzertifikate (QWAC) dürften sich den Vorgang sehr genau anschauen. Nutzer des DNS-Dienstes 1.1.1.1 hingegen dürfen aufatmen: Dass ihnen Gefahr drohte, etwa durch abgefangene DNS-Abfragen, ist höchst unwahrscheinlich.

(cku)

Zum 1. Oktober 2025 will Microsoft die Anmeldung mit zweitem Faktor, die Mehrfaktorauthentifizierung oder kurz MFA, für weitere Azure-Cloud-Dienste zwingend einführen. Die Phase 1 der MFA-Erzwingung startete im Februar dieses Jahres, sie brachte die verbesserte Sicherheit für das Azure-Portal, Microsofts Entra-Admin-Center und das Intune-Admin-Center.

In einem Support-Artikel zu Entra-ID hat Microsoft jetzt die aktualisierten Daten vorgestellt. Demnach kommen die Dienste Azure CLI, Azure PowerShell, Azure Mobile App, IaC-Tools und REST-API-Endpunkte zu denjenigen hinzu, für die Microsoft eine erzwungene MFA vorsieht. Zumindest für die Operationen Create, Delete oder Update. Read-Operationen benötigen keine MFA, erörtert Microsoft, das weicht davon ab, was für die Phase-1-Apps gilt.

Auch für „Notfallzugriffskonten“ gelte die MFA-Anforderung, weshalb die Redmonder empfehlen, für diese bereits jetzt Passkeys (FIDO2) oder zertifikatsbasierte Authentifizierung einzurichten. Beides genüge den MFA-Anforderungen. Wer nutzerbasierte Konten für Dienste verwendet, sollte diese zudem auf „Workload Identities“ migrieren, was in der Regel Anpassungen an Skripten und Automatisierungsprozessen erfordert.

Verzögerungen möglich

Microsoft bietet betroffenen Kunden an, gegebenenfalls mehr Zeit für die MFA-Vorbereitungen zu erhalten. Das gilt für Kunden mit komplexen Umgebungen oder technischen Hürden. Die Phase 1 können sie bis zum 30. September hinauszögern. Das sorgt gleichzeitig dafür, dass Phase 2 bis zum selben Zeitpunkt verschoben wird. Für Phase 2 lässt sich jedoch ein späterer Startzeitpunkt auswählen – maximal bis zum 1. Juli 2026. Die Auswahl erlaubt dabei Drei-Monats-Sprünge.

Microsofts Artikel liefert noch Handreichungen für Admins, wie sie die MFA-Anforderungen erfüllen und etwa Tests ihrer Umgebungen vornehmen können. Zudem geben die Redmonder Hinweise, etwa für Anpassungen bei OAAuth-Systemen oder den Umgang mit föderierten Identitätsprovidern.

Die ersten Azure-MFA-Umstellungen sollten in der Mitte des vergangenen Jahres anfangen. Der Hintergrund ist IT-Sicherheit: Eine der effektivsten Sicherheitsmaßnahmen ist demnach die MFA. Microsoft hat herausgefunden, dass mit der Mehrfaktorauthentifizierung mehr als 99,2 Prozent der Angriffe zur Kompromittierung von Konten verhindert werden können.

(dmk)