Exploiting Race Conditions

La siguiente aplicación pertenece a un operador móvil y permite transferencia de crédito móvil. En esta práctica comprobaremos si el sistema es susceptible de una vulnerabilidad race condition y trataremos de explotarla transfiriendo más crédito del que tenemos en la cuenta.

Primero necesitamos explorar y estudiar cómo la aplicación web objetivo recibe las peticiones HTTP y cómo responde a ellas. Usando Burp Suite, haz click en abrir navegador. De esta manera podemos explorar cómo procesa las peticiones HTTP y sus respuestas.

Loguéate en cualquiera de las cuentas y haz click en el botón Pay & Recharge. Hagamos una transferencia de crédito. Haz click en el botón Transfer e introduce el número de móvil de la otra cuenta junto con la cantidad que quieres transferir. Puedes intentar transferirte una cantidad que exceda tu balance actual y una cantidad pequeña, como 1$ para ver cómo se comporta el sistema en cada caso.

Burp Suite: Repeater

En la imagen de abajo podemos ver:

1. Una petición POST.
2. Los detalles muestran el número de teléfono y la cantidad a transferir.
3. En la respuesta, podemos ver que la transacción fue exitosa.

Ahora que hemos visto cómo reacciona el sistema a peticiones válidas, probemos a explotar una race condition. Haz click derecho en la petición POST que quieres duplicar y elige Send to Repeater.

En la pestaña del repetidor hacemos lo siguiente:

1. Click en el icono + y seleccionamos Create tab group.
2. Asignamos un nombre al grupo e incluimos la pestaña de la petición que acabamos de mandar al importer antes de hacer click en Create.
3. Hacemos click derecho en la pestaña de petición y elegimos Duplicate tab (si la opción no está disponible en nuestra versión podemos presionar Ctrl+R varias veces en su lugar).
4. Como punto de partida lo duplicaremos 20 veces.
5. Al lado del botón Send, la flecha que apunta hacia abajo abrirá un menú para decidir cómo queremos mandar las peticiones duplicadas.

Después, explotaremos la aplicación objetivo mandando peticiones duplicadas. Usando las funciones del Repetidor de Burp Suite, la flecha de abajo ofrece las siguientes opciones:

• Mandar grupo en secuencia (conexión única).
• Mandar grupo en secuencia (conexión separada/múltiple).
• Mandar grupo en paralelo.

Mandar Grupo de Peticiones en Secuencia

Mandar el grupo en secuencia ofrece dos opciones:

• Mandar grupo en secuencia (conexión única).
• Mandar grupo en secuencia (conexión separada/múltiple).

Mandar el Grupo en Secuencia a Través de una Única Conexión

Esta opción establece una única conexión al servidor y manda todas las peticiones del grupo de pestañas antes de cerrar la conexión. Puede ser útil para comprobar vulnerabilidades de desincronización potenciales del lado del cliente.

Mandar el Grupo en Secuencia a Través de Múltiples Conexiones

Como el nombre sugiere, esta opción establece una conexión TCP, manda una petición del grupo, cierra la conexión y repite el proceso con cada una de las peticiones.

Comprobamos esta opción en el ataque a la aplicación. La imagen de debajo muestra 21 conexiones TCP para las diferentes posiciones POST en el grupo.

• El primer grupo (etiquetado como 1), compete 5 peticiones exitosas. Podríamos confirmar que fueron exitosas comprobando las respuestas respectivas. Además notamos que cada una tomó alrededor de 3 segundos, como se indica en la duración (etiquetada como 3).
• El segundo grupo (etiquetado como 2), muestra 16 peticiones denegadas. La duración fue de unos 4 milisegundos. Es interesante observar el tiempo de comienzo relativo.

La imagen de debajo muestra la conexión TCP completa para una petición. Podemos confirmar que la petición POST fue mandada en un solo paquete.

Mandar Grupo de Peticiones en Paralelo

Elegir mandar el grupo de peticiones en paralelo dispararía al repetidor para que mandase las peticiones en un grupo a la vez. En este caso notaríamos lo siguiente, como se muestra en la imagen de abajo:

• En la columna de Comienzo Relativo, notamos que los 21 paquetes se andan en una ventana de 0,5 milisegundos (etiquetado con un 1).
• Todas las peticiones fueron exitosas, resultaron en una transferencia de crédito exitosa. Cada petición tomó alrededor de 3,2 segundos en completarse (etiquetado con un 2).

Prestando atención a la imagen de arriba, notamos que cada petición llevó a 12 paquetes, en el intento anterior vemos que sólo fueron 10. ¿Por qué pasa esto?

De acuerdo a la documentación de Burp Suite: Mandar Peticiones HTTP en Grupo, al mandar en paralelo, el repetidor implementa diferentes técnicas para sincronizar la llegada de las peticiones al objetivo. La técnica de sincronización depende del protocolo usado:

• En el caso de HTTP/2+, el repetidor intenta mandar el grupo entero en un único paquete. En otras palabras, un sólo paquete TCP podría llevar múltiples peticiones.
• En el caso de HTTP/1, el repetidor recurre a la sincronización del último byte. Este truco se consigue omitiendo el último byte de la solicitud. La imagen de abajo muestra nuestras peticiones POST mandadas en dos paquetes.

Challenge

En este reto debemos conseguir que una de las dos cuentas obtenga más de 100$ de crédito. Para ello se nos proporcionan las credenciales de las cuentas:

• User1: 07799991337

• Password: pass1234

• User2: 07113371111

• Password: pass1234

Vamos con la resolución.

1. Nos dirigimos a la página dada.
2. Nos logueamos en ambas cuentas y echamos un vistazo.
3. Probamos a mandar más del saldo que tenemos y luego una cantidad muy pequeña, para ver lo que pasa.
4. Ahora que sabemos cómo funciona, vamos a abrir Burp Suite y su navegador para intentar explotar la rece condition.
   1. Usando ahora el navegador de Burp Suite y con la interceptación encendida procedemos.
   2. La mandamos al repetidor así o con Ctrl+R.
   3. Creamos un grupo de pestañas.
   4. Le ponemos nombre.
   5. Duplicamos la pestaña.
   6. Mandamos las pestañas en paralelo.
   7. Ahora mandamos el dinero bien:
   8. Obtenemos la flag: