In betroffenen Builds ist das SSO-Ticket lediglich System.currentTimeMillis() (ein vorhersagbarer Zeitstempel), der beim Login des Opfers abgetastet wird, sodass es über das Cookie CUSTOM_SSO_TICKET replaybar ist, um diese Sitzung zu übernehmen. Der Fix ersetzt das Ticket durch UUID.randomUUID() (eine ausreichend zufällige Kennung). Der Replay-Pfad ist nur erreichbar, wenn das Produkt in AD360 integriert ist: ADSFilter macht ihn von isProductIntegrated() abhängig. Diese Hürde ist die Voraussetzung, die dieses Werkzeug prüft.

HINWEIS: Dieser Detektor bestätigt die Voraussetzung, nicht die Schwachstelle selbst. Ein POTENTIALLY_AFFECTED-Ergebnis ist kein bestätigtes „verwundbar“-Urteil – siehe unten für weitere Informationen.

Ist die Ausführung sicher?

Ja. Das Werkzeug ist für den Produktions- und Bewertungseinsatz konzipiert.

• Es wird nichts ausgenutzt. Die Sonde sendet ein ungültiges SSO-Ticket (1700000000000, ein Millisekundenwert, der so weit in der Vergangenheit liegt, dass er nie im Cache liegen kann), sodass niemals eine Sitzung erlangt wird. Der Server teilt uns lediglich mit, die gesendeten Cookies zu löschen.
• Keine Zustandsänderungen am Ziel. Jede Anfrage ist ein einfacher GET, und die einzigen betroffenen Cookies sind die Wegwerf-Cookies, die das Werkzeug sendet.
• Kein Brute-Forcing und keine Sitzungsauflösung. Das Werkzeug versucht nicht die aktive Zeitstempel-Ticket-Auflösung, die Ausnutzbarkeit beweisen würde; das ist Exploitation und nicht Erkennung und liegt außerhalb des Rahmens (siehe Einschränkungen).

Was dieses Werkzeug Ihnen sagen kann und was nicht

Der Patch für CVE-2026-11374 änderte nur, wie das Ticket erzeugt wird (von Millisekunden zu UUID); er änderte nicht den Cookie-Replay-Pfad, den diese Sonde testet. Daher antwortet eine gepatchte Installation Byte für Byte identisch zu einer anfälligen auf jede nicht authentifizierte Anfrage.

Was das Werkzeug ohne Authentifizierung und nicht destruktiv tun kann:

• Bestätigen, dass ein erreichbares, in Frage kommendes Produkt den CustomSSO-Cookie-Replay-Pfad aktiv hat (d. h. in AD360 integriert ist), was die Exploit-Voraussetzung für CVE-2026-11374 ist.
• Anhand des produktspezifischen Sitzungs-Cookies identifizieren, um welches der vier Produkte es sich handelt.
• Die Build-Nummer eines Assets bestmöglich als Hinweis auslesen. Dies ist bei ADSelfService Plus, ADAudit Plus und M365 Manager Plus verfügbar; bei RecoveryManager Plus nicht verfügbar.

Was es nicht kann:

• Anfällig von gepatcht unterscheiden. Dafür gibt es kein sicheres, passives, nicht authentifiziertes Signal. Ein POTENTIALLY_AFFECTED-Ergebnis bedeutet, dass die Voraussetzung erfüllt ist und Sie den Patch-Stand überprüfen sollten, nicht dass der Host als verwundbar bestätigt ist.
• Ausnutzbarkeit bestätigen. Der Nachweis, dass ein Host tatsächlich ausnutzbar ist, erfordert die Beobachtung des Formats eines ausgestellten Tickets (eine 13-stellige Zahl ist verwundbar, eine UUID ist gepatcht; beides erfordert authentifizierte Sicht oder Sicht auf dem Host), das lokale Lesen von conf/product.conf oder das aktive Auflösen eines Live-Tickets (echte Exploitation, die hier bewusst nicht implementiert ist).
• Einer Build-Nummer von ADSelfService Plus unterhalb des Fix-Builds vollständig vertrauen. ADSSPs ?build= ist manchmal der echte Build und manchmal ein eingefrorener Platzhalter, der unterhalb des Fix-Builds liegt. Ein Wert unterhalb des Fix-Builds ist daher mehrdeutig, und das Werkzeug markiert ihn als nicht schlüssig. Ein Wert auf oder über dem Fix-Build ist weiterhin ein vertrauenswürdiges „gepatcht“-Signal, da der Platzhalter immer zu niedrig ist, um ihn zu erreichen.

Anforderungen

• Python 3.7+ und die Bibliothek requests. Installation mit pip install requests.

Verwendung

Die Standard-Ports unterscheiden sich je nach Produkt (ADSelfService Plus 8888, ADAudit Plus 8081, M365 Manager Plus 8365, RecoveryManager Plus 8090); übergeben Sie daher eine URL oder host:port. Ein bloßer Host verwendet standardmäßig 8888.

Optionen

Beispiele

Eine in AD360 integrierte Konsole (ausführlich, Standard). Die zweite Zeile stellt klar, dass es sich um die Voraussetzung und nicht um ein „verwundbar“-Urteil handelt; die dritte ist der Best-Effort-Build-Hinweis:

Eine eigenständige Installation desselben Produkts, bei der der Replay-Pfad nicht aktiv ist:

Scannen einer Liste mit einer ausgerichteten Zeile pro Host (--brief). Der Exit-Status ist 1, wenn ein Host POTENTIALLY_AFFECTED ist, andernfalls 0, was in Skripten praktisch ist. Die abschließende Notiz zeigt das identifizierte Produkt sowie bei einem Befund die Build-Nummer:

Maschinenlesbare Ausgabe (--json). Jedes Ergebnis enthält das verdict, den zugrunde liegenden state und detail, das identifizierte product sowie – bei einem Befund – ein build-Objekt: build ist die gefundene Nummer, fixed_build der Schwellenwert für dieses Produkt, patch_hint die richtungsweisende Einschätzung (likely_patched bei oder über dem Fix-Build, andernfalls inconclusive) und note eine kurze Erklärung:

Bewertungen

Exit-Codes

So funktioniert es

Senden Sie ein ungültiges Ticket plus ein App-Tag an eine beliebige CustomSSO-URL (*.do):

Bei einer in AD360 integrierten Installation durchläuft die Kette ADSFilter → CustomSSOFilter → CookieSSOImpl ihren Auflösungszweig (das Tag benennt ein anderes Produkt, also appName != prodName), kann das gefälschte Ticket nicht auflösen und sendet Cookie-Aufräum-Response-Header:

Eine eigenständige Installation durchläuft diesen Pfad nie und sendet kein Aufräumen. Das Produkt wird anhand seines festen produktspezifischen Tomcat-Sitzungs-Cookies identifiziert (JSESSIONIDADSSP für ADSelfService Plus usw.), das bei jeder Antwort gesetzt wird. Die Prüfung stützt sich auf die Header und nicht auf den Statuscode, da ein integriertes ADSSP ein 302 zurückgibt, während ADAudit, M365 und RMP auf dieselbe Sonde mit 200 antworten.

Einschränkungen

• POTENTIALLY_AFFECTED ist nicht „bestätigt verwundbar“. Es ist die Exploit-Voraussetzung. Da der Patch diesen Codepfad nicht berührt hat, antwortet ein gepatchter Build identisch; Sie müssen den Patch-Stand also auf anderem Wege bestätigen (siehe nächste Schritte). Mehr kann ein nicht authentifizierter Beobachter nicht wissen.
• Keine aktive Bestätigung. Das Werkzeug versucht nie, ein echtes Ticket mit aktuellem Zeitstempel aufzulösen. Diese Technik kann einen Host positiv als verwundbar nachweisen, ist aber aktive Exploitation (sie übernimmt eine Live-Sitzung), ist drosselungsbegrenzt und probabilistisch und benötigt eine aktive Opfersitzung. Daher ist sie aus diesem Detektor ausgeschlossen.
• HTTP 400 kann eine Rate-Limit-Sperre und keine echte Antwort sein. Zoho IAM wendet eine rollierende URL-Drosselung an, die eine Quell-IP auf etwa 40 Anfragen pro 60 s begrenzt und diesen Pfad dann für ~60 s sperrt. Während einer Sperre geben Anfragen HTTP 400 zurück und das Integrationssignal ist maskiert. Das Werkzeug meldet diese als INCONCLUSIVE; versuchen Sie es von dieser IP nach etwa einer Minute erneut.
• Hinter einem Reverse-Proxy kann eine Konsole, die das Sitzungs-Cookie entfernt oder umschreibt, fälschlich als UNAFFECTED gemeldet werden. Bestätigen Sie direkt, wenn Sie dort ein ManageEngine-Produkt erwarten.
• Build-Nummern sind Hinweise, keine Bewertungen. ADAudit (?v=) und M365 (?bN=) legen immer den echten Build offen; ADSSPs ?build= ist manchmal echt und manchmal ein eingefrorener Platzhalter, der unterhalb des Fix-Builds liegt. Ein ADSSP-Wert unterhalb des Fix-Builds ist daher mehrdeutig; RMP legt keinen offen. In jedem Fall deutet ein Build auf oder über dem Fix-Build stark auf „gepatcht“ hin, und darunter ist er nicht schlüssig.

Nächste Schritte für Verteidiger

Wenn ein Ziel POTENTIALLY_AFFECTED zurückgibt, behandeln Sie es als exponiert und bestätigenswert. Gehen Sie dann wie folgt vor:

1. Bestätigen Sie den Patch-Stand direkt (das Werkzeug kann das nicht). Lesen Sie conf/product.conf (build_number) auf dem Host und vergleichen Sie sie mit dem Fix-Build für dieses Produkt (ADSelfService Plus 6529, RecoveryManager Plus 6321, M365 Manager Plus 4817, ADAudit Plus 8703). Interpretieren Sie das richtungsweisend: Ein Build auf oder über dem Fix-Build ist ein starkes Indiz dafür, dass der Host gepatcht ist, da der UUID-Fix in diesem Zweig enthalten ist. Ein Build unterhalb des Fix-Builds ist nicht schlüssig und kein Beweis für eine Verwundbarkeit, da Out-of-Band-Hotfixes und Backports den UUID-Fix anwenden können, ohne die Build-Nummer zu erhöhen; in diesem Fall verwenden Sie die Ticket-Format-Prüfung unten.

2. Prüfen Sie das Format des ausgestellten Tickets, wenn Sie sich anmelden können. Das Cookie CUSTOM_SSO_TICKET ist nicht HttpOnly. Nach der Authentifizierung können Sie seinen Wert also lesen: Eine 13-stellige Zahl bedeutet verwundbar, eine UUID bedeutet gepatcht. Das ist die klarste positive Prüfung.

3. Aktualisieren Sie jeden Host, der verwundbar ist oder bei dem Sie nicht bestätigen können, dass er gepatcht ist, auf den Fix-Build (oder später). Der Fix ersetzt das vorhersagbare Ticket durch eine zufällige UUID.

4. Suchen Sie nach Exploitation-Versuchen. Auf dem Host zeichnet serverOut_<date>.txt die Drosselung als Ausbrüche von Folgendem auf:

   root@kitploit:~

   IAMSecurityException ErrorCode: URL_ROLLING_THROTTLES_LIMIT_EXCEEDED,
   RequestURI: "/showLogin.cc", RemoteAddr: <source IP>
   

   Ein Anstieg von URL_ROLLING_THROTTLES_LIMIT_EXCEEDED auf SSO-/Login-Dispatch-Pfaden von einer einzelnen Quell-IP ist ein starkes Indiz für Ticket-Brute-Forcing. Überprüfen Sie außerdem kürzlich erfolgreiche Logins und Sitzungsaktivität auf Anzeichen einer Übernahme.

5. Reduzieren Sie in der Zwischenzeit die Angriffsfläche. Beschränken Sie den Netzwerkzugriff auf die AD360-Suite (sie sollte nicht aus dem Internet erreichbar sein), und wenn der Replay-Pfad nicht benötigt wird, entfernt das Deaktivieren der CustomSSO-Integration die Voraussetzung vollständig.

Behebung

Aktualisieren Sie das betroffene Produkt auf mindestens den Fix-Build (ADSelfService Plus 6529, RecoveryManager Plus 6321, M365 Manager Plus 4817, ADAudit Plus 8703) oder später. Der Fix ersetzt das vorhersagbare SSO-Ticket System.currentTimeMillis() durch UUID.randomUUID().

Lizenz

Dieser Code wird unter einer MIT-Lizenz vertrieben.

Rechtlicher Hinweis

Die Verwendung dieses Werkzeugs zum Angriff auf Ziele ohne vorherige gegenseitige Zustimmung ist illegal. Es liegt in der Verantwortung des Endbenutzers, alle geltenden lokalen, Landes- und Bundesgesetze zu befolgen. Die Entwickler übernehmen keine Haftung und sind nicht verantwortlich für Missbrauch oder Schäden, die durch dieses Programm verursacht werden.

Siehe auch

• NVD: CVE-2026-11374
• ManageEngine-Servicepacks: ADSelfService Plus · RecoveryManager Plus · M365 Manager Plus · ADAudit Plus
• Bishop Fox Blog: Vollständige technische Analyse