Contenido original, no generado por IA y basado en dos reportes realizados por mi persona. Además, lo curioso es que no he visto a nadie explotándola o hablando de ella. En el contexto adecuado, esta vulnerabilidad puede resultar crítica y provocar que la aplicación (o partes de ella) quede fuera de servicio.
TL;DR: Encontré y exploté una vulnerabilidad de Mass Assignment que me permitió forzar un campo entero hasta su límite máximo (2³¹–1) y, con ello, provocar una condición de tipo Sequence Exhaustion que derivó en un DoS a nivel de aplicación.
Para neófitos en la materia
Primero vamos con la parte NO técnica, me suele encantar esta parte por si se la tienes que explicar a un CEO, ejecutivos, a tus abuelos o a tu hijo/a de 5 años.
Imagina el sistema de turnos de una carnicería. Normalmente coges un papel y te toca, por ejemplo, el 10; el siguiente coge el 11, y así hasta 999.
El fallo (Mass Assignment): consiste en que vez de darte el número una máquina, tú puedes escribir el que quieras en un papel en blanco.
El ataque (Sequence Exhaustion): un hacker llega a la carnicería y, en vez de seguir por el 10, escribe 999.999.999. El carnicero acepta ese número y lo mete en el sistema. La máquina piensa que el siguiente turno debe ser ese más uno, pero ese número ya no cabe en el papel.
Cuando llega la siguiente persona, la máquina intenta imprimir un número imposible, se rompe y nadie más puede sacar turno.
Para frikis y otros expertos
Explicado técnicamente. En la muchas las bases de datos, los campos id se definen como INT o INTEGER. Este es un tipo de dato de 32 bits, siendo en la mayoría de los casos su capacidad máxima (2³¹–1), es decir 2.147.483.647.
Por otro lado, el mecanismo de AUTO_INCREMENT funciona manteniendo un contador interno que indica el siguiente valor a asignar cuando una tabla tiene una columna configurada como AUTO_INCREMENT (o SERIAL en Postgres). El comportamiento crítico aparece cuando un atacante realiza un INSERT manual especificando un ID (posible gracias al Mass Assignment ) y la base de datos acepta ese valor. Tras ello, el motor sincroniza su contador de auto‑incremento estableciéndolo en ID_insertado + 1 para evitar colisiones en futuras inserciones.
Prueba de Concepto (PoC)
La vulnerabilidad la exploté de la siguiente manera: un usuario tenía permitido añadir publicaciones, al realizar una publicación era posible indicar en el cuerpo de la petición POST un parámetro llamado id :
POST https://target.com/api/v1/add-publication Host: target.com
id=2147483645
El valor anterior (2.147.483.645) estaba muy cerca del límite para un entero int32 (2.147.483.647). Por lo tanto, gracias al mecanismo de AUTO_INCREMENT, bastaba con que cualquier usuario legítimo publicara dos artículos más para que el contador superara su capacidad máxima, provocando un DoS y dejando a la plataforma y a sus usuarios sin posibilidad de publicar nuevos artículos.
Solo bastó esperar unos minutos para que la secuencia alcanzara el valor máximo permitido para un entero (2³¹‑1) y se desbordara. En otras palabras, la aplicación quedó inutilizable y ningún usuario pudo publicar comentarios.
Esta vulnerabilidad dependiendo de la facilidad de explotación y el impacto suele estar clasificada como P2 o P3 en la taxonomía de Bugcrowd.
Dicha vulnerabilidad no tiene ningún tipo de denominación aún y Mass Assignment + Integer Sequence Exhaustion quedaba bastante poco original, así que la he bautizado como Int Apocalypse. La gente de OWASP Top Ten debe estar ahora mismo abriendo un champán…