![¿Secuestro de cuenta? ¡De hecho, probé IDOR! [Resumen de HackTheBox sobre Armaxis]](https://hack-lab-256.com/wp-content/uploads/2025/12/hack-lab-256-samnail.png)
Las aplicaciones web suelen considerarse "seguras" simplemente por implementar mecanismos como la autenticación y los tokens.
Sin embargo, en realidad, determina qué datos de los usuarios pueden acceder , puede provocar el robo de cuentas.
En particular, IDOR (Referencia Directa a Objetos Insegura) es una vulnerabilidad que se produce cuando la entrada del usuario se utiliza directamente para referenciar un objeto interno, y puede ocurrir incluso con autenticación y tokens.
Como resultado, es posible manipular las cuentas de otros usuarios o acceder a sus privilegios.
En este artículo, utilizaremos el desafío CTF Armaxis como tema para recrear el malware IDOR que estaba acechando en la función de restablecimiento de contraseña y examinar cómo se puede lograr el secuestro de cuentas.
- ¡La sensación de escritura nítida exclusiva del sistema capacitivo sin contacto!
- ¡El primer dispositivo inalámbrico de REALFORCE! ¡También disponible con conexión por cable!
- A diferencia del HHKB, la distribución del teclado japonés no tiene peculiaridades y es fácil de usar para cualquiera.
- Equipado con una rueda para el pulgar, ¡el desplazamiento horizontal es muy fácil!
- ¡También tiene un excelente rendimiento de reducción de ruido, lo que lo hace silencioso y cómodo!
- ¡El desplazamiento se puede cambiar entre el modo de alta velocidad y el modo de trinquete!
Acerca de HackTheBox
Esta vez, utilizamos HackTheBox (HTB) para verificar vulnerabilidades.
HackTheBox es una plataforma práctica de CTF donde los participantes pueden practicar en diversas áreas de seguridad, incluyendo aplicaciones web, servidores y redes.
Su principal ventaja es que los participantes pueden aprender accediendo a las máquinas y aplicaciones que serán atacadas y poniéndose manos a la obra.
Armaxis que veremos en esta ocasión las categorías de Desafío que se ofrecía anteriormente en HackTheBox, y actualmente es un plan VIP o superior (tenga en cuenta que solo los desafíos activos están disponibles para los usuarios con el plan gratuito).
También hay máquinas y desafíos en una variedad de categorías, incluidas Web, Reversing, Pwn y Forensics, para que puedas abordarlos en un nivel que se adapte a ti.
Si quieres perfeccionar seriamente tus habilidades con HackTheBox, asegúrate al plan VIP y aprovechar al máximo las máquinas y los desafíos anteriores.
👉 Visita el sitio web oficial de HackTheBox aquí
👉 Para obtener información detallada sobre cómo registrarse en HackTheBox y las diferencias entre los planes, haga clic aquí.
Resumen del desafío: Armaxis
es una tarea CTF basada en una aplicación web, basada en
el sistema ficticio de control de armas "Armaxis". Los jugadores acceden al sistema como usuarios comunes, investigando sus funciones y explotando vulnerabilidades.
Además de las funciones de registro e inicio de sesión, Armaxis también ofrece funciones de restablecimiento de contraseña de envío de armas, disponibles solo para administradores .
Al enviar armas, los usuarios pueden introducir Markdown como campo de nota, y el contenido se procesa en el servidor antes de guardarse y mostrarse.
A primera vista, parece una aplicación web típica, pero la verificación de autorización del usuario para el restablecimiento de contraseña está implementada de forma deficiente una Referencia Directa a Objetos Insegura (IDOR) en ciertas circunstancias .
Al aprovechar este problema, se permite el acceso a otros usuarios, incluso cuentas de administrador, algo que no debería ser posible.
Obtener privilegios administrativos desbloquea nuevas capacidades y superficies de ataque adicionales, lo que en última instancia
permite que un jugador aproveche los efectos en cascada de múltiples fallas de diseño para obtener acceso a información sobre el servidor.
punto
- Tipo de desafío: Aplicación web
- Vulnerabilidad: IDOR, LFI
- Secuencia de ataque:
- Investigando las características como usuario general
- Explotación de fallas en los procesos de restablecimiento de contraseñas para obtener privilegios (IDOR)
- Acceda a las funciones de administración y descubra superficies de ataque adicionales
- Robo de información interna del servidor (LFI)
- Lo que puedes aprender
- La diferencia entre autenticación y autorización
- Cómo se establece IDOR
¿Qué es IDOR?
La autenticación y la autorización a menudo se confunden
cuando se habla de seguridad de aplicaciones web, pero distinguirlas correctamente es esencial para comprender IDOR.
La autenticación es un mecanismo para verificar quién eres, y el procesamiento de inicio de sesión y la validación de tokens desempeñan esta función.
Por otro lado, la autorización es un mecanismo para determinar qué puedes hacer
IDOR (Referencia Directa a Objetos Insegura) es una vulnerabilidad que se produce cuando
no se verifica esta autorización Se produce cuando se utiliza un valor especificado por el usuario (como un ID, una dirección de correo electrónico o un nombre de archivo) para referenciar directamente un objeto dentro del servidor, sin verificar su pertenencia real.
Es importante tener en que IDOR se mantiene incluso en presencia de autenticación :
estar conectado o tener un token válido no tiene sentido si no se han realizado verificaciones de autorización para el objeto referenciado.
Por ejemplo, si una implementación utiliza la dirección de correo electrónico en una solicitud para buscar o actualizar la información del usuario,
sería posible manipular la cuenta de otra persona simplemente reemplazando el valor de entrada.
Este es un ejemplo típico de un ataque IDOR.
El desafío CTF "Armaxis" analizado en este artículo también carecía de esta verificación de autorización en la función de restablecimiento de contraseña, lo que
finalmente condujo al secuestro de la cuenta.
¡Realmente probé IDOR!
Antes de lanzar nuestro ataque, primero revisemos la pantalla.
La primera es la pantalla de inicio de sesión de un sistema llamado Armaxis.
Parece que tanto los usuarios administradores como los usuarios generales usan la misma pantalla de inicio de sesión.
El segundo es un buzón. Aquí se prepara la dirección de correo electrónico del atacante.
test@email.htb es nuestra dirección de correo electrónico, así que vamos a comprobarlo.
Fase de reconocimiento: Crea una cuenta en test@email.htb
Primero, cree una cuenta usando la dirección de correo electrónico test@email.htb proporcionada.
Registrarse es sencillo: solo ingrese su correo electrónico y contraseña y haga clic en el botón "Registrarse".
Si se ha registrado correctamente, verá el mensaje "Registro exitoso".
Una vez que te hayas registrado, intenta iniciar sesión.
En este punto, debería aparecer "Aún no se han enviado armas".
Después, probablemente obtendrás privilegios de administrador y empezarás a enviar armas a esta cuenta.
Fase de reconocimiento: Revisión del código fuente
La fase de reconocimiento continúa, así que echemos un vistazo al código fuente.
Mientras miraba a mi alrededor, encontré una implementación que me llamó la atención en "/reset-password".
router.post("/reset-password", async (req, res) => { const { token, newPassword, email } = req.body; // Se agregó el parámetro 'email' if (!token || !newPassword || !email) return res.status(400).send("Se requieren token, correo electrónico y nueva contraseña."); try { const reset = await getPasswordReset(token); if (!reset) return res.status(400).send("Token inválido o caducado."); const user = await getUserByEmail(email); if (!user) return res.status(404).send("Usuario no encontrado."); await updateUserPassword(user.id, newPassword); await deletePasswordReset(token); res.send("Restablecimiento de contraseña exitoso."); } catch (err) { console.error("Error al restablecer la contraseña:", err); res.status(500).send("Error al restablecer la contraseña."); } });
Todo parece estar bien hasta que reviso el token, pero parece que no tiene ningún usuario asociado, así que intento obtenerlo del correo electrónico.
Revisemos getUserByEmail.
función asíncrona getUserByEmail(correo electrónico) { consulta constante = `SELECT * FROM users WHERE correo electrónico = ?`; intentar { usuario constante = await obtener(consulta, [correo electrónico]); devolver usuario; } capturar (error) { generar error; } }Cuando verifico el SQL, parece recuperar el usuario solo desde la dirección de correo electrónico.
Se llama a updateUserPassword con el ID de usuario y la nueva contraseña obtenidos del correo electrónico.
Comprobémoslo también.
función asíncrona updateUserPassword(id, newPassword) { consulta constante = `ACTUALIZAR usuarios ESTABLECER contraseña = ? DONDE id = ?`; intentar { esperar ejecutar(consulta, [newPassword, id]); } capturar (error) { generar error; } }Como no existe un control particular sobre el token, descubrimos que es posible cambiar la contraseña de otro usuario utilizando los parámetros de correo electrónico y newPassword.
Además, el código fuente contiene la dirección de correo electrónico del administrador.
Anote "admin@armaxis.htb", ya que la necesitará para iniciar sesión en la cuenta de administrador en el futuro.
Fase de reconocimiento: Comprobación de las solicitudes reales de cambio de contraseña
A continuación, utilicemos la pantalla y confirmemos la solicitud de cambio de contraseña.
En la pantalla de inicio de sesión, verá un mensaje que dice "¿Olvidó su contraseña?"; púlselo para acceder a la pantalla de restablecimiento de contraseña.
intentemos actualizar su contraseña con
la dirección de correo electrónico proporcionada " test@email.htb " test@email.htb " y haga clic en el botón "Solicitar código".
Aparecerá un cuadro de diálogo en la pantalla pidiéndole que ingrese su token y nueva contraseña.
Puedes comprobar el token recargando tu buzón de correo.
Cuando intenté actualizar mi contraseña ingresando el token y la nueva contraseña, encontré que se envió la siguiente solicitud.
Si puede configurar cada parámetro como se muestra a continuación, debería poder cambiar la contraseña de administrador.
- token: Token emitido por test@email.htb
- correo electrónico: dirección de correo electrónico del administrador
- newPassword: Cualquier contraseña
Ahora que tenemos toda la información disponible, lancemos un ataque basado en esta información.
Fase de ataque: Toma de control de la cuenta de administrador
Aprovechemos la vulnerabilidad IDOR y usemos el token emitido por test@email.htb para cambiar la contraseña de la cuenta de administrador y tomar control de la cuenta de administrador.
Primero, obtenga un token con "test@email.htb".
Una vez que llegues a esta pantalla, deberías haber recibido el token en tu buzón.
Llegó sano y salvo. (Accidentalmente presioné el botón dos veces, así que hay tres correos electrónicos).
Ahora, modifiquemos el JSON con la siguiente información:
- token: el token para test@email.htb obtenido anteriormente
- newPassword: Cualquier contraseña (prueba)
- Correo electrónico: admin@armaxis.htb (dirección de correo electrónico del administrador)
Ahora debería poder enviar una solicitud para cambiar la contraseña de otra cuenta utilizando el token de test@email.htb.
La respuesta es 200 OK, así que creo que salió bien.
Comprobémoslo en la pantalla.
Ingrese la dirección de correo electrónico como admin@armaxis.htb, ingrese la contraseña que estableció en newPassword y haga clic en el botón Iniciar sesión.
¡Ya hemos pirateado la cuenta de administrador!
Ahora que tenemos el Arma de Despacho, podemos usarla para conseguir la Bandera.
Bono: Consigue la bandera usando LFI
Dado que este artículo se centra en IDOR, resumiré brevemente los próximos pasos.
Primero, había un campo en la pantalla donde se podía ingresar Markdown. Esta vez, usaremos este campo para cargar un archivo en un servidor al que normalmente LFI no puede acceder.
El comando "COPY flag.txt /flag.txt" nos dice que flag.txt se encuentra directamente debajo del directorio raíz.
# Usar la imagen base de Node.js con Alpine Linux FROM node:alpine # Instalar las dependencias requeridas para MailHog y supervisord EJECUTAR apk add --no-cache \ wget \ supervisor \ apache2-utils \ curl \ build-base # Instalar el binario de MailHog WORKDIR / EJECUTAR wget https://github.com/mailhog/MailHog/releases/download/v1.0.1/MailHog_linux_amd64 EJECUTAR chmod +x MailHog_linux_amd64 # Preparar el directorio de correo electrónico y copiar los archivos de la aplicación EJECUTAR mkdir -p /email COPY email-app /email WORKDIR /email EJECUTAR npm install # Generar una contraseña aleatoria y crear un archivo de autenticación para MailHog EJECUTAR RANDOM_VALUE=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1) \ && htpasswd -nbBC 10 test "$RANDOM_VALUE" > /mailhog-auth \ && echo $RANDOM_VALUE > /email/password.txt # Establecer el directorio de trabajo para la aplicación principal WORKDIR /app # Copiar los archivos de desafío e instalar las dependencias COPY challenge . RUN npm install # Copiar la configuración de supervisord COPY config/supervisord.conf /etc/supervisor/conf.d/supervisord.conf # Exponer los puertos para la aplicación y el cliente de correo electrónico EXPOSE 8080 EXPOSE 1337 COPY flag.txt /flag.txt # Iniciar supervisord CMD ["supervisord", "-c", "/etc/supervisor/conf.d/supervisord.conf"]Markdown permite mostrar imágenes usando "".
Normalmente, se escribiría la ruta de la imagen aquí, pero intentemos configurar "txt" aquí.
Además, establezca la ruta en file:// en lugar de image://.
Una vez que haya creado Dispatch Weapon, inicie sesión con test@email.htb.
Por supuesto, la imagen no se mostrará, pero verás algún texto codificado en Base64 en Elements.
<img src="data:image/*;base64,SFRCe200cmtkMHduX2J1Z3NfMW5fdGgzX3cxbGQhfQo=" alt="Imagen incrustada">Vamos a decodificarlo como quieras.
Yo usaré CyberChef.
¡Logramos recuperar la bandera! En este caso, era flag.txt, pero si alguien recuperara un archivo de contraseña o algo similar, podría causar problemas graves, así que tengan cuidado.
Contramedidas: ¿Qué se puede hacer para prevenir IDOR?
El problema de IDOR con Armaxis no se debió a un problema con el método de generación de tokens ni a su aleatoriedad, sino la falta de comprobaciones de autorización . Por lo tanto, simplemente "reforzar el token" no es suficiente.
Aquí resumiremos medidas prácticas basadas en este estudio de caso.
No confíe en la entrada del cliente para las referencias de objetos
Lo más importante que se debe hacer no utilizar la información del cliente, como direcciones de correo electrónico o identificaciones, como referencias de objetos .
En este proceso de restablecimiento de contraseña, se utilizó la dirección de correo electrónico incluida en la solicitud para buscar al usuario que se iba a actualizar.
Este diseño permite manipular la cuenta de otra persona simplemente reemplazando el valor introducido.
Originalmente los usuarios a actualizar eran:
- Información del usuario que ha iniciado sesión
- El ID de usuario asociado con el token
La decisión debe tomarse en función de la información que se puede determinar en el lado del servidor , como por ejemplo
Personalmente he visto muchas aplicaciones que realmente se ejecutan utilizando referencias de objetos que dependen de la entrada del cliente, así que asegúrese de desarrollar con precaución.
Trate los tokens como "permiso de operación" en lugar de "verificación de identidad"
Un token de restablecimiento de contraseña hace más que simplemente verificar si es válido.
- esta ficha ?
- ¿Está siendo utilizado como una operación por ese usuario?
Debe verificarse en el lado del servidor .
En este problema, se verificó el token, pero se ignoró sobre qué usuario estaba autorizado a operar con el token
no deben tratarse como "prueba de identidad", sino "claves que autorizan operaciones específicas para usuarios específicos".
Esto es lo que suele pasar cuando se desarrolla con la actitud despreocupada de que no hay problema mientras se emitan tokens. Creo que
muchos ingenieros desarrollan sin comprender realmente el significado de los tokens.
Verifique las funciones del administrador y los flujos de excepciones de manera más estricta
Los flujos excepcionales, como el restablecimiento de contraseñas y las funciones exclusivas del administrador, tienden a tener una autorización más laxa que los procesos normales,
pero en realidad, estos flujos de excepción son el punto de partida de los ataques .
- Restablecer contraseña
- Recuperación de cuenta
- Operaciones solo para administradores
Funciones como estas requieren un diseño e implementación claros de quién puede operar los datos de quién y por qué.
Además, dado que hay momentos en que el público en general puede ser negligente, puede ser una buena idea tener funciones exclusivas para administradores en un sistema separado.
Resumen: IDOR y las trampas del diseño autorizado
En este desafío, que confiar en la información del usuario sin las comprobaciones de autorización necesarias resultó en el robo de cuentas. Incluso con tokens y autenticación, estos por sí solos no son suficientes para garantizar la seguridad.
La esencia del problema radica en que el servidor no determinó qué datos puede manipular.
Un diseño que utiliza direcciones de correo electrónico directamente como referencias a objetos es un ejemplo típico de IDOR.
Para evitar IDOR, es importante determinar de forma única el objetivo de la operación en el servidor y verificar explícitamente la autorización de cada proceso.
Esto no es una medida especial, sino un principio básico de diseño.
Al probarlo con CTF, pude comprobar la gravedad del problema de los fallos de autorización.
Si te interesa, te recomiendo Hack the Box .
👉 Para obtener información detallada sobre cómo registrarse en HackTheBox y las diferencias entre los planes, haga clic aquí.
![[Introducción a la seguridad de la IA] Deshabilitación de clases específicas mediante la manipulación de modelos | Informe sobre la crisis de combustible de HackTheBox](https://hack-lab-256.com/wp-content/uploads/2025/08/hack-lab-256-samnail-32-300x169.jpg)
![[Seguridad con IA] Ataque de ransomware gestionado por IA con inyección inmediata | Informe sobre el ransomware TrynaSob de HackTheBox](https://hack-lab-256.com/wp-content/uploads/2025/08/hack-lab-256-samnail-31-300x169.jpg)
![[Seguridad de IA] Secuestro de agentes de IA que explotan las llamadas a funciones de OpenAI: ¡Prácticas y estrategias de defensa explicadas! Informe de la encuesta de fidelización de HackTheBox](https://hack-lab-256.com/wp-content/uploads/2025/08/hack-lab-256-samnail-30-300x169.jpg)
![[Seguridad de IA] Cómo engañar a un LLM con una inyección de avisos | Informe de Asuntos Externos de HackTheBox](https://hack-lab-256.com/wp-content/uploads/2025/08/hack-lab-256-samnail-29-300x169.jpg)
![[Guía práctica] Hacking con RCE de la vulnerabilidad SSTI en HackTheBox. Descubre las causas y las contramedidas de las vulnerabilidades | Informe de Spookifier](https://hack-lab-256.com/wp-content/uploads/2025/08/hack-lab-256-samnail-28-300x169.jpg)
![[Box virtual en Windows 10] ¡Una explicación detallada de cómo instalar el cuadro virtual!](https://hack-lab-256.com/wp-content/uploads/2022/03/hack-lab-256-samnail-300x169.jpg)