Skip to content
KitploitKITPLOIT
ToolsExploitsBlog
Log in
Einreichen
ToolsExploitsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
CVE-2024-47051 — Mautic < 5.2.3 Authentifizierte RCE | Kitploit
Tools/GitHubGitHub/mallo-m/cve-2024-47051
SchwachstellenanalyseCode-AnalyseExploitationWebanwendungs-ExploitationPenetrationstestsPayload-Entwicklung
GitHubmallo-m/cve-2024-47051

CVE-2024-47051

Mautic < 5.2.3 Authentifizierte RCE

Repository anzeigen
510vor 1 JahrNoch nicht geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

Zusammenfassung

Eine schlechte Bereinigung des Inhalts, Typs und der Erweiterung einer hochgeladenen Datei in der Asset-Bearbeitungsfunktion ermöglicht es einem authentifizierten Angreifer, beliebigen PHP-Code im Webverzeichnis zu schreiben und den Speicherort dieser Datei zu finden. Dies führt zur Remote-Code-Ausführung.

Ein Path-Traversal-Angriff erlaubt es zudem, diese Funktionalität auszunutzen, um rekursiv jedes Verzeichnis im Dateisystem zu löschen, für das der Web-Benutzer Änderungsrechte besitzt.

Details - RCE

Beim Bearbeiten eines Assets über die Route /assets/view/{assetID} besteht die Möglichkeit, die Datei des Assets zu ändern.

Das Hochladen einer neuen Datei ruft letztlich die folgende Funktion in app/Bundles/AssetBundle/Controller/AssetController.php auf:

public function editAction(Request $request, UploaderHelper $uploaderHelper, AssetModel $model, $objectId, $ignorePost = false)

Die Upload-Logik befindet sich hier:

        if (!$ignorePost && 'POST' == $method) {
            $valid = false;
            if (!$cancelled = $this->isFormCancelled($form)) {
                if ($valid = $this->isFormValid($form)) {
                    $entity->setUploadDir($this->coreParametersHelper->get('upload_dir'));
                    $entity->preUpload();
                    $entity->upload();

Insbesondere interessieren uns die Methoden preUpload() und upload(), da sie das tatsächliche Schreiben der Datei auf die Festplatte übernehmen.

Der erste Fehler liegt in preUpload() in app/Bundles/AssetBundle/Entity/Asset.php, da die Implementierung es uns erlaubt, eine beliebige Dateierweiterung anzugeben (wodurch der Schutz umgangen wird, der normalerweise durch das Array allowed_extensions bereitgestellt wird):

            $filename  = sha1(uniqid(mt_rand(), true));
            $extension = $this->getFile()->guessExtension();

            if (empty($extension)) {
                // get it from the original name
                $extension = pathinfo($this->originalFileName, PATHINFO_EXTENSION);
            }

            $this->path = $filename.'.'.$extension;

Die Zeile $extension = $this->getFile()->guessExtension(); gibt NULL zurück, wenn wir einen Dateinamen angeben, der auf .php endet, und der Inhalt mit dem Tag <?php beginnt. Die Prüfung empty($extension) wird daher wahr ergeben, und die Dateierweiterung wird dann durch den Aufruf von pathinfo() extrahiert, sodass wir temporäre Dateien mit beliebigem Inhalt und beliebiger Erweiterung hochladen können. Wir können den tatsächlichen Dateinamen nicht kontrollieren, da er mit sha1() generiert wird.

Dann wird die Datei innerhalb der anschließenden upload()-Methode tatsächlich über den folgenden Aufruf im Webverzeichnis auf die Festplatte geschrieben:

$this->getFile()->move($this->getUploadDir(), $this->path);

Es verwendet unsere beliebige Erweiterung (enthalten in der Variable $this->path). Der Name der Datei kann dann durch Aktualisieren der Asset-Detailseite (/assets/view/{assetId}) unter dem Tabelleneintrag „Lokaler Dateiname“ abgerufen werden.

Hinweis: Dies funktioniert auch, indem die beim Erstellen eines neuen Assets gesendeten Anfragen geändert werden. Dadurch wird die Funktion newAction() aufgerufen, aber die Logik ist identisch und die Fehler liegen weiterhin in den Methoden preUpload() und upload().

PoC - RCE

Der PoC wird erst in etwa einem Monat veröffentlicht.

Dies soll den Organisationen, die auf diese Software angewiesen sind, Zeit geben, sie zu patchen, ohne befürchten zu müssen, dass Script-Kiddies ihre Sachen zerstören.

Danach wird dieses Repository mit dem vollständigen Exploit-Skript und den Beweisen aktualisiert. Es gibt auf dieser Seite bereits genug Informationen.

Details - Beliebiges Dateilöschen

Bei der Validierung eines temporären Uploads (über /s/assets/new oder /s/assets/edit/{assetId}) wird das Verzeichnis, in dem die temporäre Datei gespeichert ist, am Ende der Anfrage rekursiv gelöscht.

Der Parameter, der für den Namen des temporären Verzeichnisses zuständig ist, ist anfällig für Path-Traversal-Angriffe, wodurch ein authentifizierter Angreifer jedes Verzeichnis auf dem System löschen kann, sofern der Web-Benutzer die entsprechenden Berechtigungen hat.

Dies kann zu Datenverlust oder sogar zur Zerstörung des gesamten Dateisystems führen, falls der Server als Root-Benutzer ausgeführt wird.

PoC - Beliebiges Dateilöschen

Geben Sie eine beliebige Datei an, die auf dem System vorhanden ist, über den unten verwendeten Endpunkt. Wenn die Datei existiert, versucht der Server, das Verzeichnis, in dem sie gespeichert ist, zu löschen.

Auswirkungen

  • Server-Übernahme
  • Denial of Service
  • Datenverlust

Zeitplan

    1. Okt. 2024: Erste Kontaktaufnahme und Sicherheitshinweis an das Mautic-Team gesendet
    1. Nov. 2024: Exploit-Skript und Abhilfevorschläge an das Entwicklungsteam gesendet
    1. Dez. 2024: Zweite Kontaktaufnahme
    1. Jan. 2025: Patch bereit zur Bereitstellung
    1. Feb. 2025: CVE zugewiesen und veröffentlicht
Tool herunterladen