-Pluck-CMS-RCE-CVE-2023-50564

exploit.py 🐍💥

⚠️ Aviso legal / ético: este script es solo para entornos autorizados ✅ (CTFs, laboratorios, pentesting con permiso). No lo uses contra sistemas sin autorización ❌.

→ traduction:

exploit.py 🐍💥

⚠️ Avertissement légal / éthique : ce script est réservé aux environnements autorisés ✅ (CTF, laboratoires, pentest avec permission). Ne l'utilisez pas contre des systèmes sans autorisation ❌.

🧾 ¿Qué hace este script?

exploit_greenhorn.py automatiza una cadena de explotación típica en un panel web:

✅ Hace login en el panel (necesitas contraseña válida) ✅ Crea un ZIP en memoria (sin escribir archivos locales) 📦 ✅ Mete dentro un rev.php con una reverse shell 🔁🐚 ✅ Sube el ZIP como “módulo” al panel 🧩⬆️ ✅ “Detona” el payload abriendo la URL del PHP subido 🚀

📌 El nombre del módulo se genera aleatorio para evitar conflictos (por ejemplo: abcdefg, xqpmzui, etc.) 🎲

→ traduction:

🧾 Que fait ce script ?

exploit_greenhorn.py automatise une chaîne d'exploitation typique sur un panneau web :

✅ Se connecte au panneau (vous avez besoin d'un mot de passe valide) ✅ Crée un ZIP en mémoire (sans écrire de fichiers locaux) 📦 ✅ Y place un rev.php avec un reverse shell 🔁🐚 ✅ Téléverse le ZIP en tant que « module » sur le panneau 🧩⬆️ ✅ « Détonne » le payload en ouvrant l'URL du PHP téléversé 🚀

📌 Le nom du module est généré aléatoirement pour éviter les conflits (par exemple : abcdefg, xqpmzui, etc.) 🎲

🧰 Requisitos

Python 3.8+ 🐍

Dependencia: requests 📌

Instalación: instala la librería requests con pip (pip install requests) ✅

→ traduction:

🧰 Prérequis

Python 3.8+ 🐍

Dépendance : requests 📌

Installation : installez la bibliothèque requests avec pip (pip install requests) ✅

⚙️ Configuración (IMPORTANTE 🔧)

Dentro del script hay una sección “TUS DATOS” que debes ajustar:

RHOST_DOMAIN 🌐 → URL del objetivo (incluye http:// o https://)

LHOST_IP 🧭 → tu IP donde quieres recibir la shell (normalmente la de la VPN/tun0)

LHOST_PORT 🔌 → puerto donde vas a escuchar

PASSWORD 🔑 → contraseña del panel (el script no hace brute force)

✅ Consejo: lo más común que falle es LHOST_IP (pon la IP correcta de tu interfaz de VPN) 😅

→ traduction:

⚙️ Configuration (IMPORTANT 🔧)

Dans le script, il y a une section « TUS DATOS » que vous devez ajuster :

RHOST_DOMAIN 🌐 → URL de la cible (incluez http:// ou https://)

LHOST_IP 🧭 → votre IP où vous voulez recevoir le shell (généralement celle de la VPN/tun0)

LHOST_PORT 🔌 → port sur lequel vous allez écouter

PASSWORD 🔑 → mot de passe du panneau (le script ne fait pas de brute force)

✅ Conseil : ce qui échoue le plus souvent, c'est LHOST_IP (mettez la bonne IP de votre interface VPN) 😅

🎧 Listener (antes de ejecutar)

Antes de lanzar el exploit, abre un listener para recibir la reverse shell 👂🐚

Ejemplo: netcat escuchando en el mismo puerto que pusiste en LHOST_PORT (por ejemplo 4444). Si no estás escuchando, no llega nada 📭.

→ traduction:

🎧 Listener (avant d'exécuter)

Avant de lancer l'exploit, ouvrez un listener pour recevoir le reverse shell 👂🐚

Exemple : netcat qui écoute sur le même port que celui que vous avez mis dans LHOST_PORT (par exemple 4444). Si vous n'écoutez pas, rien n'arrive 📭.

▶️ Uso

Configura RHOST_DOMAIN, LHOST_IP, LHOST_PORT y PASSWORD ✅

Abre tu listener 🎧

Ejecuta el script con Python 🐍

Salida típica que puedes ver:

[] Objetivo: http://greenhorn.htb

[] Creando modulo limpio: xqpmzui [] Logueando... [+] Login OK. [] Subiendo payload... [*] Detonando en: http://greenhorn.htb/data/modules/xqpmzui/rev.php

[+] ¡Timeout! (Buena señal, revisa tu netcat)

😎 Ojo: el “Timeout! (Buena señal)” suele ser NORMAL ✅ Porque cuando el PHP abre la reverse shell, la petición web puede quedarse “colgada” mientras la sesión interactiva está viva 🔁

→ traduction:

▶️ Utilisation

Configurez RHOST_DOMAIN, LHOST_IP, LHOST_PORT et PASSWORD ✅

Ouvrez votre listener 🎧

Exécutez le script avec Python 🐍

Sortie typique que vous pouvez voir :

[] Objetivo : http://greenhorn.htb

[] Creando modulo limpio : xqpmzui [] Logueando... [+] Login OK. [] Subiendo payload... [*] Detonando en : http://greenhorn.htb/data/modules/xqpmzui/rev.php

[+] ¡Timeout ! (Buena señal, revisa tu netcat)

😎 Attention : le « Timeout ! (Bon signe) » est généralement NORMAL ✅ Parce que lorsque le PHP ouvre le reverse shell, la requête web peut rester « suspendue » pendant que la session interactive est vivante 🔁

Note: We must preserve code blocks/commands exactly. The lines with brackets are not code fences but plain text. We can translate the surrounding text but the bracket lines are probably intentionally showing console output. The original has "[]" and "[+]" etc. We should keep them as is but we can translate the Spanish words? Actually the output is inside the script? It's typical output lines. We need to decide. Since they're not code blocks, but they are sample output. The rule says translate natural language text, but code/commands never. These are output strings from the script, likely in Spanish. We should probably keep them verbatim because they are program output / code-related. The instruction says "NEVER translate: code blocks, shell commands, file paths, URLs, package names, technical identifiers". The lines "[] Objetivo: ..." are program output strings, not natural language narration. It's safer to keep them exactly as-is, including "Objetivo", "Creando modulo limpio", etc. But wait, the user's source is Spanish, and these output strings are in Spanish. The target language is French. Should we translate them? The output is part of the tool's actual output, which is code behavior. Typically we don't translate code output. Also the instruction: "If you cannot translate a technical term safely, leave it untranslated". But these are not technical terms, they are user-facing strings. However, since they represent actual console output from the script, translating them would be incorrect for a README about a tool (users would see Spanish output). Better to keep them verbatim. The same for "Login OK." which is English already. We'll keep those lines as is.

Let's continue with the rest.

🧠 ¿Cómo funciona por dentro? (explicado fácil)

Genera un nombre aleatorio de módulo 🎲

Crea un ZIP en memoria 📦 (estructura plana, sin carpetas internas)

Dentro mete rev.php con una reverse shell que conecta a tu LHOST_IP:LHOST_PORT 📡

Hace login en /login.php 🔑 (incluye Referer para compatibilidad)

Sube el ZIP a /admin.php?action=installmodule ⬆️🧩

Ejecuta el payload accediendo a /data/modules/<module_name>/rev.php 🚀🐚

→ traduction:

🧠 Comment ça fonctionne à l'intérieur ? (explication simple)

Génère un nom de module aléatoire 🎲

Crée un ZIP en mémoire 📦 (structure plate, sans dossiers internes)

Y place rev.php avec un reverse shell qui se connecte à votre LHOST_IP:LHOST_PORT 📡

Se connecte sur /login.php 🔑 (inclut le Referer pour la compatibilité)

Téléverse le ZIP vers /admin.php?action=installmodule ⬆️🧩

Exécute le payload en accédant à /data/modules/<module_name>/rev.php 🚀🐚

Note: The route paths and file names are unchanged.

🧪 Troubleshooting (si algo falla)

❌ Login fallido

Revisa PASSWORD 🔑

Confirma que el endpoint es /login.php

En labs a veces toca reiniciar la máquina/servicio 🔄

❌ No llega la shell

Verifica LHOST_IP 🧭 (la IP correcta, normalmente tun0)

Confirma que estás escuchando en el puerto correcto 🔌🎧

Prueba otro puerto si hay filtrado (por ejemplo 443 o 9001) 🚧

❌ 404 al detonar

Puede que no se haya instalado el módulo 🧩

Algunas instalaciones cambian rutas; revisa la estructura de /data/modules/ 📁

→ traduction:

🧪 Dépannage (si quelque chose échoue)

❌ Échec de la connexion

Vérifiez PASSWORD 🔑

Confirmez que le endpoint est /login.php

Dans les labs, il faut parfois redémarrer la machine/service 🔄

❌ Le shell n'arrive pas

Vérifiez LHOST_IP 🧭 (la bonne IP, généralement tun0)

Confirmez que vous écoutez sur le bon port 🔌🎧