Translated ['pentesting-web/race-condition.md'] to es

This commit is contained in:
Translator 2024-08-18 15:56:43 +00:00
parent fb8ba0a514
commit 21929d814a

View file

@ -18,7 +18,7 @@ Aprende y practica Hacking en GCP: <img src="../.gitbook/assets/grte.png" alt=""
* Revisa los [**planes de suscripción**](https://github.com/sponsors/carlospolop)!
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **síguenos** en **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Comparte trucos de hacking enviando PRs a los** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositorios de github.
* **Comparte trucos de hacking enviando PRs a los** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos de github.
</details>
{% endhint %}
@ -33,12 +33,12 @@ El principal obstáculo para aprovechar las condiciones de carrera es asegurarse
Aquí puedes encontrar algunas técnicas para Sincronizar Solicitudes:
#### Ataque de Paquete Único HTTP/2 vs. Sincronización del Último Byte HTTP/1.1
#### Ataque de Paquete Único HTTP/2 vs. Sincronización de Último Byte HTTP/1.1
* **HTTP/2**: Soporta el envío de dos solicitudes a través de una sola conexión TCP, reduciendo el impacto del jitter de la red. Sin embargo, debido a las variaciones del lado del servidor, dos solicitudes pueden no ser suficientes para un exploit de condición de carrera consistente.
* **Sincronización del 'Último Byte' HTTP/1.1**: Permite el pre-envío de la mayoría de las partes de 20-30 solicitudes, reteniendo un pequeño fragmento, que luego se envía junto, logrando una llegada simultánea al servidor.
* **HTTP/2**: Soporta el envío de dos solicitudes a través de una única conexión TCP, reduciendo el impacto del jitter de red. Sin embargo, debido a las variaciones del lado del servidor, dos solicitudes pueden no ser suficientes para un exploit consistente de condición de carrera.
* **Sincronización de 'Último Byte' HTTP/1.1**: Permite el pre-envío de la mayoría de las partes de 20-30 solicitudes, reteniendo un pequeño fragmento, que luego se envía junto, logrando una llegada simultánea al servidor.
**La preparación para la Sincronización del Último Byte** implica:
**La preparación para la Sincronización de Último Byte** implica:
1. Enviar encabezados y datos del cuerpo menos el byte final sin finalizar el flujo.
2. Pausar durante 100ms después del envío inicial.
@ -51,7 +51,7 @@ El envío posterior de los cuadros retenidos debería resultar en su llegada en
Entender la arquitectura del objetivo es crucial. Los servidores front-end pueden enrutar las solicitudes de manera diferente, afectando el tiempo. El calentamiento proactivo de la conexión del lado del servidor, a través de solicitudes insignificantes, podría normalizar el tiempo de las solicitudes.
#### Manejo del Bloqueo Basado en Sesiones
#### Manejo de Bloqueo Basado en Sesiones
Frameworks como el manejador de sesiones de PHP serializan las solicitudes por sesión, potencialmente oscureciendo vulnerabilidades. Utilizar diferentes tokens de sesión para cada solicitud puede eludir este problema.
@ -75,7 +75,7 @@ engine.queue(target.req, password, gate='race1')
Si la web no soporta HTTP2 (solo HTTP1.1) usa `Engine.THREADED` o `Engine.BURP` en lugar de `Engine.BURP2`.
{% endhint %}
* **Tubo Intruder - ataque de paquete único HTTP2 (Varios puntos finales)**: En caso de que necesites enviar una solicitud a 1 punto final y luego múltiples a otros puntos finales para activar el RCE, puedes cambiar el script `race-single-packet-attack.py` por algo como:
* **Tubo Intruder - ataque de un solo paquete HTTP2 (Varios puntos finales)**: En caso de que necesites enviar una solicitud a 1 punto final y luego múltiples a otros puntos finales para activar el RCE, puedes cambiar el script `race-single-packet-attack.py` por algo como:
```python
def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
@ -114,7 +114,7 @@ engine.openGate(currentAttempt)
<figure><img src="../.gitbook/assets/image (58).png" alt=""><figcaption></figcaption></figure>
* **Script de python automatizado**: El objetivo de este script es cambiar el correo electrónico de un usuario mientras se verifica continuamente hasta que el token de verificación del nuevo correo llegue al último correo (esto se debe a que en el código se estaba viendo un RC donde era posible modificar un correo electrónico pero tener la verificación enviada al antiguo porque la variable que indicaba el correo ya estaba poblada con el primero).\
* **Script de python automatizado**: El objetivo de este script es cambiar el correo electrónico de un usuario mientras se verifica continuamente hasta que el token de verificación del nuevo correo llegue al último correo (esto se debe a que en el código se estaba viendo un RC donde era posible modificar un correo pero tener la verificación enviada al antiguo porque la variable que indicaba el correo ya estaba poblada con el primero).\
Cuando se encuentra la palabra "objetivo" en los correos electrónicos recibidos, sabemos que hemos recibido el token de verificación del correo cambiado y terminamos el ataque.
```python
# https://portswigger.net/web-security/race-conditions/lab-race-conditions-limit-overrun
@ -244,7 +244,7 @@ response = requests.get(url, verify=False)
En la investigación original se explica que este ataque tiene un límite de 1,500 bytes. Sin embargo, en [**esta publicación**](https://flatt.tech/research/posts/beyond-the-limit-expanding-single-packet-race-condition-with-first-sequence-sync/), se explicó cómo es posible extender la limitación de 1,500 bytes del ataque de paquete único a la **limitación de ventana de 65,535 B de TCP utilizando la fragmentación de capa IP** (dividiendo un solo paquete en múltiples paquetes IP) y enviándolos en un orden diferente, lo que permitió evitar la reensambladura del paquete hasta que todos los fragmentos llegaran al servidor. Esta técnica permitió al investigador enviar 10,000 solicitudes en aproximadamente 166 ms.&#x20;
Tenga en cuenta que, aunque esta mejora hace que el ataque sea más confiable en RC que requiere que cientos/miles de paquetes lleguen al mismo tiempo, también puede tener algunas limitaciones de software. Algunos servidores HTTP populares como Apache, Nginx y Go tienen un ajuste estricto de `SETTINGS_MAX_CONCURRENT_STREAMS` a 100, 128 y 250. Sin embargo, otros como NodeJS y nghttp2 lo tienen ilimitado.\
Tenga en cuenta que, aunque esta mejora hace que el ataque sea más confiable en RC que requiere que cientos/miles de paquetes lleguen al mismo tiempo, también puede tener algunas limitaciones de software. Algunos servidores HTTP populares como Apache, Nginx y Go tienen una configuración estricta de `SETTINGS_MAX_CONCURRENT_STREAMS` de 100, 128 y 250. Sin embargo, otros como NodeJS y nghttp2 lo tienen ilimitado.\
Esto significa básicamente que Apache solo considerará 100 conexiones HTTP de una sola conexión TCP (limitando este ataque RC).
Puede encontrar algunos ejemplos utilizando esta técnica en el repositorio [https://github.com/Ry0taK/first-sequence-sync/tree/main](https://github.com/Ry0taK/first-sequence-sync/tree/main).
@ -346,15 +346,15 @@ La precisión en el tiempo de las solicitudes puede revelar vulnerabilidades, es
## Estudios de caso de subestados ocultos
### Pagar y añadir un ítem
### Pagar y añadir un artículo
Revisa este [**PortSwigger Lab**](https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-insufficient-workflow-validation) para ver cómo **pagar** en una tienda y **añadir un extra** que **no necesitarás pagar**.
Revisa este [**PortSwigger Lab**](https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-insufficient-workflow-validation) para ver cómo **pagar** en una tienda y **agregar un extra** que **no necesitarás pagar**.
### Confirmar otros correos
### Confirmar otros correos electrónicos
La idea es **verificar una dirección de correo electrónico y cambiarla a una diferente al mismo tiempo** para averiguar si la plataforma verifica la nueva que se cambió.
### Cambiar correo a 2 direcciones de correo basadas en cookies
### Cambiar correo electrónico a 2 direcciones de correo basadas en cookies
Según [**esta investigación**](https://portswigger.net/research/smashing-the-state-machine), Gitlab era vulnerable a una toma de control de esta manera porque podría **enviar** el **token de verificación de correo de un correo al otro correo**.
@ -364,7 +364,7 @@ Según [**esta investigación**](https://portswigger.net/research/smashing-the-s
Si se utilizan **2 escrituras diferentes** para **agregar** **información** dentro de una **base de datos**, hay una pequeña porción de tiempo donde **solo los primeros datos han sido escritos** dentro de la base de datos. Por ejemplo, al crear un usuario, el **nombre de usuario** y **contraseña** pueden ser **escritos** y **luego el token** para confirmar la cuenta recién creada es escrito. Esto significa que durante un breve tiempo el **token para confirmar una cuenta es nulo**.
Por lo tanto, **registrar una cuenta y enviar varias solicitudes con un token vacío** (`token=` o `token[]=` o cualquier otra variación) para confirmar la cuenta de inmediato podría permitir **confirmar una cuenta** donde no controlas el correo.
Por lo tanto, **registrar una cuenta y enviar varias solicitudes con un token vacío** (`token=` o `token[]=` o cualquier otra variación) para confirmar la cuenta de inmediato podría permitir **confirmar una cuenta** donde no controlas el correo electrónico.
**Revisa esto** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-partial-construction) **para probar esto.**
@ -385,7 +385,7 @@ Así que, hasta aquí, solo un inicio de sesión común con google/linkedin/gith
#### Condición de carrera en `authorization_code`
El **problema** aparece cuando **lo aceptas** y automáticamente envía un **`authorization_code`** a la aplicación maliciosa. Luego, esta **aplicación abusa de una Condición de Carrera en el proveedor de servicios OAUth para generar más de un AT/RT** (_Token de Autenticación/Token de Refresco_) a partir del **`authorization_code`** para tu cuenta. Básicamente, abusará del hecho de que has aceptado la aplicación para acceder a tus datos para **crear varias cuentas**. Luego, si **dejas de permitir que la aplicación acceda a tus datos, un par de AT/RT será eliminado, pero los otros seguirán siendo válidos**.
El **problema** aparece cuando **lo aceptas** y automáticamente envía un **`authorization_code`** a la aplicación maliciosa. Luego, esta **aplicación abusa de una Condición de Carrera en el proveedor de servicio OAUth para generar más de un AT/RT** (_Token de Autenticación/Token de Refresco_) a partir del **`authorization_code`** de tu cuenta. Básicamente, abusará del hecho de que has aceptado la aplicación para acceder a tus datos para **crear varias cuentas**. Luego, si **dejas de permitir que la aplicación acceda a tus datos, un par de AT/RT será eliminado, pero los otros seguirán siendo válidos**.
#### Condición de carrera en `Refresh Token`
@ -402,6 +402,7 @@ En [**WS\_RaceCondition\_PoC**](https://github.com/redrays-io/WS\_RaceCondition\
* [https://hackerone.com/reports/55140](https://hackerone.com/reports/55140)
* [https://portswigger.net/research/smashing-the-state-machine](https://portswigger.net/research/smashing-the-state-machine)
* [https://portswigger.net/web-security/race-conditions](https://portswigger.net/web-security/race-conditions)
* [https://flatt.tech/research/posts/beyond-the-limit-expanding-single-packet-race-condition-with-first-sequence-sync/](https://flatt.tech/research/posts/beyond-the-limit-expanding-single-packet-race-condition-with-first-sequence-sync/)
{% hint style="success" %}
Aprende y practica Hacking en AWS:<img src="../.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../.gitbook/assets/arte.png" alt="" data-size="line">\
@ -421,7 +422,7 @@ Aprende y practica Hacking en GCP: <img src="../.gitbook/assets/grte.png" alt=""
<figure><img src="../.gitbook/assets/image (48).png" alt=""><figcaption></figcaption></figure>
\
Usa [**Trickest**](https://trickest.com/?utm\_source=hacktricks\&utm\_medium=text\&utm\_campaign=ppc\&utm\_term=trickest\&utm\_content=race-condition) para construir y **automatizar flujos de trabajo** fácilmente con las herramientas comunitarias **más avanzadas** del mundo.\
Usa [**Trickest**](https://trickest.com/?utm\_source=hacktricks\&utm\_medium=text\&utm\_campaign=ppc\&utm\_term=trickest\&utm\_content=race-condition) para construir y **automatizar flujos de trabajo** fácilmente impulsados por las **herramientas comunitarias más avanzadas** del mundo.\
Obtén acceso hoy:
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=race-condition" %}