Day 20: Toy to The World - Advent of Cyber 2025
xhetic
@xhetic
📚 Esta publicación pertenece a las colecciones:
Day 20: Toy to The World - Advent of Cyber 2025
Este writeup pertenece al evento Advent of Cyber 2025 de TryHackMe. Si quieres seguir toda la serie, consulta nuestra colección completa del Advent of Cyber 2025.
Hoy nos enfrentamos a una vulnerabilidad clásica pero devastadora en aplicaciones web: Race Conditions (Condiciones de Carrera). El sitio web de ventas de juguetes "Toy to The World" tiene un problema grave en cómo gestiona su inventario, y vamos a aprovecharlo para comprar más regalos de los que realmente existen.
Room: Race Conditions - Toy to The World
Dificultad: Easy
🏁 ¿Qué es una Race Condition?
Una Race Condition ocurre cuando un sistema realiza operaciones que dependen de una secuencia o tiempo específico, pero no controla adecuadamente el orden en que se ejecutan cuando hay múltiples procesos simultáneos.
En el contexto web, el tipo más común es TOCTOU (Time of Check to Time of Use). Imagina este flujo en una tienda:
- Check: ¿Hay stock del producto? (Sí, hay 1).
- Use: Procesar el pago y restar 1 al stock.
Si enviamos 10 peticiones al mismo tiempo exacto, es posible que las 10 pasen el "Check" antes de que la primera llegue al "Use" y actualice el stock. Resultado: vendemos 10 productos cuando solo había 1.
🛒 Explorando la Tienda
Al acceder a la web, vemos tres productos disponibles. Nos fijamos especialmente en el "SleighToy Limited Edition", del cual solo quedan 10 unidades en stock.
Si hacemos una compra normal:
- Añadimos al carrito.
- Vamos al Checkout.
- Confirmamos y pagamos.
El stock baja a 9. Todo correcto. Pero, ¿qué pasa si intentamos ser más rápidos que el sistema?
⚡ Explotando la Carrera (SleighToy)
Para probar la vulnerabilidad, necesitamos una herramienta que nos permita enviar múltiples peticiones en paralelo. Burp Suite es perfecto para esto.
- Configuramos el proxy de Burp Suite y realizamos una compra normal hasta el paso final.
- En el historial de Burp (
Proxy > HTTP history), localizamos la peticiónPOST /process_checkout. - Enviamos esta petición al Repeater (o usamos Intruder si queremos automatizarlo más).
- Creamos un grupo de pestañas en Repeater (por ejemplo, duplicamos la petición 10 veces) y las añadimos a un grupo.
- Configuramos el envío para que sea en paralelo (Send group in parallel).
Al lanzar las 10 peticiones simultáneamente, el servidor recibe todas casi al mismo tiempo. Verifica el stock para todas ellas antes de actualizarlo.
Resultado: Todas las compras se procesan con éxito. Al recargar la página, vemos que el stock del "SleighToy Limited Edition" muestra "Over-sold: -2" (o el número que hayamos logrado sobrepasar).
El sistema, al detectar el stock negativo, nos revela la primera flag:
Pregunta: What is the flag value once the stocks are negative for SleighToy Limited Edition?
Respuesta: THM{WINNER_OF_R@CE007}
🐰 Repitiendo la Hazaña (Bunny Plush)
El reto nos pide hacer lo mismo con el "Bunny Plush (Blue)".
- Verificamos el stock inicial: 5 unidades.
- Interceptamos la petición de compra.
- La duplicamos 10 veces en Burp Suite.
- Enviamos el grupo en paralelo.
A pesar de que solo había 5 peluches, el sistema procesa los 10 pedidos. Al volver a la página principal, el stock muestra "Over-sold: -5" y obtenemos la segunda flag.
Pregunta: Repeat the same steps as were done for ordering the SleighToy Limited Edition. What is the flag value once the stocks are negative for Bunny Plush (Blue)?
Respuesta: THM{WINNER_OF_Bunny_R@ce}
💥 Impacto Real
Aunque en este reto solo hemos conseguido juguetes extra, esta vulnerabilidad es crítica en el mundo real. Imagina este escenario con:
- Cupones de descuento: Tienes un cupón de 50€ de un solo uso. Si aplicas la Race Condition, podrías usarlo en 10 pedidos simultáneos, obteniendo 500€ de descuento.
- Transferencias bancarias: Enviar dinero desde una cuenta con saldo bajo a múltiples destinos antes de que el banco actualice el saldo.
- Votos online: Votar múltiples veces en encuestas limitadas a un voto por usuario.
🏁 Conclusión
Las Race Conditions son difíciles de detectar con pruebas funcionales normales porque dependen del timing y la concurrencia. Para prevenirlas, los desarrolladores deben implementar bloqueos (locks) en la base de datos o usar transacciones atómicas que aseguren que el stock se verifica y actualiza en una sola operación indivisible.
Si te perdiste el reto de ayer sobre sistemas SCADA y Modbus, puedes leerlo aquí: Día 19: Claus For Concern.
Recuerda que puedes seguir toda la serie de retos en nuestra colección completa del Advent of Cyber 2025.
¡Nos vemos mañana para el siguiente desafío del Advent of Cyber! 🎄