Ivanti Connect Secure Zero-Day: Root trotz Patchstand

Volexity hat eine Ivanti Connect Secure Zero-Day-Kette entdeckt, mit der ein Angreifer ohne Anmeldung Root auf einer VPN-Appliance erlangte, die zu diesem Zeitpunkt den neuesten Build ausführte. Ivanti hat zwei der drei Lücken geschlossen. Stand 14. Oktober ist für die dritte, die Rechteausweitung, die den Zugang über den Webserver zu Root macht, kein Fix verfügbar. Ivantis eigenes Integrity Checker Tool erkennt diesen Angriff nicht.

Was ist passiert

Volexity begann am 5. Oktober mit der Untersuchung der Appliance eines Kunden. Sie lief mit Connect Secure 22.8R2.4, dem damals neuesten Build, und der Angreifer, bei Volexity als UTA0576 geführt, war mindestens seit dem 3. Oktober im System. Die Ivanti Connect Secure Zero-Day-Kette besteht aus drei Teilen. Der erste ist ein Authentifizierungs-Bypass: Eine Anfrage an die Login-Seite besteht die Prüfung anhand ihrer URL, während ein HTTP-Header ein geschütztes internes Skript als eigentliches Ziel benennt. Der zweite ist eine Race Condition, mit der der Angreifer ein als ZIP-Datei getarntes Perl-Skript hochlädt und ausführt, bevor der Server es löscht. Der dritte kapert einen Wartungsdienst mit Root-Rechten und hebt das Webserver-Konto auf Root. Die ersten beiden werden gemeinsam als CVE-2026-104935 (CVSS 8.6) geführt; die CISA hat die Lücke am 13. Oktober in den Katalog der aktiv ausgenutzten Schwachstellen (KEV) aufgenommen, Frist 16. Oktober. Ivanti bestätigt begrenzte Ausnutzung und sagt, einige Kunden seien vor der Offenlegung kompromittiert worden.

CVE-2026-104935 ist behoben. Die CISA nennt 25.1.1.1 und älter, 25.1.2.2 und älter sowie 22.8R2.4 und älter als betroffen. Der CVE-Eintrag, wie ihn The Hacker News zitiert, führt 22.8R2.5, 25.1.3.0 und 25.1.3.1 als nicht betroffen. Bitte die Build-Nummern im Ivanti-Advisory prüfen; wir haben es nicht geöffnet. Für die Rechteausweitung arbeitet Ivanti an einem Update, das laut Volexity in den kommenden Wochen erscheint. Volexitys Indikatoren aus seinem einen Vorfall: viele Anfragen an /dana-na/auth/url_default/welcome.cgi, ein X-DSCGI-PATH-Header, der nicht zum URL-Pfad passt, und ein Verzeichnis namens /data/.icscap/.

Warum das wichtig ist

Das Integrity Checker Tool prüft Dateien auf dem Datenträger. Dieser Exploit verändert Code im Arbeitsspeicher und stellt die berührten Konfigurationsdaten wieder her, daher sagt ein sauberes Ergebnis wenig. Laut CISA erfordert die Bestätigung einer Kompromittierung Netzwerk- und Speicherforensik. Der Angreifer hinterließ keine Web Shell, führte die Kette für jeden Befehl erneut aus und löschte ausgewählte Logeinträge, daher bleibt wenig zurück.

Nach dem Einstieg ging UTA0576 an die Zugangsdaten. Mit dem eigenen Servicekonto der Appliance durchsuchte der Angreifer das Active Directory nach LAPS-Passwörtern für lokale Administratoren und nach BitLocker-Wiederherstellungsschlüsseln, griff Klartext-LDAP-Zugangsdaten ab, die über das Gerät liefen, und führte Password Spraying durch. Volexity wertet dies als Vorbereitung lateraler Bewegung und sieht mit geringer Sicherheit ein kriminelles statt eines Spionagemotivs. Eine öffentliche Opferzahl gibt es nicht.

Ivanti sagte CyberScoop, man habe einen Teil der Lücke im Juni intern gefunden und den Fix für den normalen Release-Zyklus eingeplant, weil nichts ausgenutzt wurde und der Fall „die Schwelle für einen Out-of-Band-Release nicht erreichte“. Für DACH kennen wir keine Opfer und keine Expositionsdaten. Einschätzung: Ein Remote-Access-Gateway mit einem Verzeichnis-Servicekonto ist ein Speicher für Domänen-Zugangsdaten am Netzwerkrand, und die dritte SonicWall-Lücke, über die wir Anfang der Woche berichtet haben, zeigt dasselbe Muster.

Was Sie jetzt tun sollten

1. Spielen Sie einen behobenen Build ein (22.8R2.5, 25.1.3.0 oder 25.1.3.1 laut CVE-Eintrag) und bestätigen Sie die Nummern im Ivanti-Advisory.
2. Betrachten Sie ein sauberes Integrity-Checker-Ergebnis nicht als Entwarnung. Durchsuchen Sie Zugriffslogs seit Ende September nach den genannten Indikatoren und planen Sie Netzwerk- und Speicherforensik für exponierte Appliances.
3. Wenn Indikatoren passen, folgen Sie dem Wiederherstellungsverfahren der CISA: Konfiguration sichern, Werksreset und Upgrade (virtuelle Instanzen neu aufbauen), Konfiguration wiederherstellen, dann alle Domänen-, Administrator- und lokalen Passwörter zurücksetzen, gespeicherte Zertifikate neu ausstellen sowie API-Schlüssel und Lizenzserver-Zugangsdaten zurücksetzen. Prüfen Sie, wer BitLocker-Wiederherstellungsschlüssel gelesen hat.
4. Beschränken Sie das Verzeichniskonto der Appliance auf das nötige Minimum. Stand 14. Oktober existiert kein Fix für die Rechteausweitung. Die CISA weist zudem darauf hin, dass Connect Secure 22.8 am 31. Januar 2027 das Support-Ende erreicht; planen Sie den Wechsel auf 25.x.

DIESEC Einschätzung

Eine VPN-Appliance mit einem überprivilegierten LDAP-Konto macht aus einer Lücke ein Domänenproblem. Begrenzen Sie dieses Konto, bevor das nächste Advisory erscheint.

Nicht sicher, ob Ihre Remote-Access-Appliances oder deren Verzeichnis-Servicekonten diese Lücke haben? Kontaktieren Sie DIESEC für eine schnelle Kompromittierungsanalyse und eine Prüfung der Servicekonten.

Quellen: The Hacker News | CyberScoop | Security Affairs | Volexity
Veröffentlicht: 2026-10-16 | Kategorie: Tägliche News | ~4 Min. Lesezeit