mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['', 'src/pentesting-web/regular-expression-denial-of-service
This commit is contained in:
Translator
parent
a1150d4160
commit
89b3c7d386
@ -1,39 +1,68 @@
|
||||
# Denegación de Servicio por Expresión Regular - ReDoS
|
||||
# Regular expression Denial of Service - ReDoS
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
# Denegación de Servicio por Expresión Regular (ReDoS)
|
||||
# Regular Expression Denial of Service (ReDoS)
|
||||
|
||||
Una **Denegación de Servicio por Expresión Regular (ReDoS)** ocurre cuando alguien aprovecha las debilidades en cómo funcionan las expresiones regulares (una forma de buscar y hacer coincidir patrones en texto). A veces, cuando se utilizan expresiones regulares, pueden volverse muy lentas, especialmente si el fragmento de texto con el que están trabajando se hace más grande. Esta lentitud puede llegar a ser tan mala que crece muy rápido con incluso pequeños aumentos en el tamaño del texto. Los atacantes pueden usar este problema para hacer que un programa que utiliza expresiones regulares deje de funcionar correctamente durante mucho tiempo.
|
||||
A **Regular Expression Denial of Service (ReDoS)** ocurre cuando alguien se aprovecha de debilidades en el funcionamiento de las expresiones regulares (una forma de buscar y emparejar patrones en texto). A veces, cuando se usan expresiones regulares, pueden volverse muy lentas, especialmente si el fragmento de texto con el que trabajan aumenta de tamaño. Esta lentitud puede empeorar hasta crecer muy rápidamente con incluso pequeños incrementos en el tamaño del texto. Los atacantes pueden usar este problema para hacer que un programa que usa expresiones regulares deje de funcionar correctamente durante un largo periodo.
|
||||
|
||||
## El Algoritmo Naïve Problemático de Regex
|
||||
## The Problematic Regex Naïve Algorithm
|
||||
|
||||
**Consulta los detalles en [https://owasp.org/www-community/attacks/Regular*expression_Denial_of_Service*-\_ReDoS](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS)**
|
||||
**Check the details in [https://owasp.org/www-community/attacks/Regular*expression_Denial_of_Service*-_ReDoS](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS)**
|
||||
|
||||
## Regex Maliciosos <a href="#evil-regexes" id="evil-regexes"></a>
|
||||
### Engine behavior and exploitability
|
||||
|
||||
Un patrón de expresión regular malicioso es aquel que puede **quedarse atascado con una entrada diseñada causando un DoS**. Los patrones de regex maliciosos típicamente contienen agrupaciones con repetición y repetición o alternancia con superposición dentro del grupo repetido. Algunos ejemplos de patrones maliciosos incluyen:
|
||||
- La mayoría de los motores populares (PCRE, Java `java.util.regex`, Python `re`, JavaScript `RegExp`) usan una VM de **backtracking**. Entradas cuidadosamente creadas que generan muchas formas solapadas de emparejar un subpatrón fuerzan un backtracking exponencial o de alto polinomio.
|
||||
- Algunos engines/libraries están diseñados para ser **ReDoS-resilient** por construcción (sin backtracking), p. ej. **RE2** y ports basados en autómatas finitos que ofrecen tiempo lineal en el peor caso; usarlos para input no confiable elimina la primitiva DoS basada en backtracking. Consulta las referencias al final para más detalles.
|
||||
|
||||
## Evil Regexes <a href="#evil-regexes" id="evil-regexes"></a>
|
||||
|
||||
Un patrón de expresión regular malicioso es aquel que puede **quedarse atascado con una entrada especialmente creada causando un DoS**. Los patrones regex maliciosos suelen contener agrupaciones con repetición y repetición o alternancia con solapamiento dentro del grupo repetido. Algunos ejemplos de patrones maliciosos incluyen:
|
||||
|
||||
- (a+)+
|
||||
- ([a-zA-Z]+)\*
|
||||
- (a|aa)+
|
||||
- (a|a?)+
|
||||
- (.\*a){x} para x > 10
|
||||
- (.*a){x} for x > 10
|
||||
|
||||
Todos esos son vulnerables a la entrada `aaaaaaaaaaaaaaaaaaaaaaaa!`.
|
||||
|
||||
## Cargas Útiles de ReDoS
|
||||
### Practical recipe to build PoCs
|
||||
|
||||
### Exfiltración de Cadenas a través de ReDoS
|
||||
La mayoría de los casos catastróficos siguen esta forma:
|
||||
|
||||
En un CTF (o programa de recompensas por errores) tal vez **controlas la Regex con la que se coincide una información sensible (la bandera)**. Entonces, podría ser útil hacer que la **página se congele (timeout o tiempo de procesamiento más largo)** si la **Regex coincidió** y **no si no coincidió**. De esta manera podrás **exfiltrar** la cadena **carácter por carácter**:
|
||||
- Prefijo que te introduce en el subpatrón vulnerable (opcional).
|
||||
- Larga secuencia de un carácter que provoca coincidencias ambiguas dentro de cuantificadores anidados/solapados (p. ej., muchos `a`, `_`, o espacios).
|
||||
- Un carácter final que fuerza el fallo global para que el engine deba backtrackear por todas las posibilidades (a menudo un carácter que no coincidirá con el último token, como `!`).
|
||||
|
||||
- En [**esta publicación**](https://portswigger.net/daily-swig/blind-regex-injection-theoretical-exploit-offers-new-way-to-force-web-apps-to-spill-secrets) puedes encontrar esta regla de ReDoS: `^(?=<flag>)((.*)*)*salt$`
|
||||
Ejemplos mínimos:
|
||||
|
||||
- `(a+)+$` vs input `"a"*N + "!"`
|
||||
- `\w*_*\w*$` vs input `"v" + "_"*N + "!"`
|
||||
|
||||
Aumenta N y observa un crecimiento super‑lineal.
|
||||
|
||||
#### Quick timing harness (Python)
|
||||
```python
|
||||
import re, time
|
||||
pat = re.compile(r'(\w*_)\w*$')
|
||||
for n in [2**k for k in range(8, 15)]:
|
||||
s = 'v' + '_'*n + '!'
|
||||
t0=time.time(); pat.search(s); dt=time.time()-t0
|
||||
print(n, f"{dt:.3f}s")
|
||||
```
|
||||
## ReDoS Payloads
|
||||
|
||||
### String Exfiltration via ReDoS
|
||||
|
||||
En un CTF (o bug bounty) quizá tú **controlas la Regex con la que se compara una información sensible (la flag)**. Entonces, puede ser útil provocar que la **página se congele (timeout o mayor tiempo de procesamiento)** si la **Regex coincide** y **no si no coincide**. De este modo podrás **exfiltrar** la cadena **carácter por carácter**:
|
||||
|
||||
- En [**this post**](https://portswigger.net/daily-swig/blind-regex-injection-theoretical-exploit-offers-new-way-to-force-web-apps-to-spill-secrets) puedes encontrar esta regla de ReDoS: `^(?=<flag>)((.*)*)*salt$`
|
||||
- Ejemplo: `^(?=HTB{sOmE_fl§N§)((.*)*)*salt$`
|
||||
- En [**este informe**](https://github.com/jorgectf/Created-CTF-Challenges/blob/main/challenges/TacoMaker%20%40%20DEKRA%20CTF%202022/solver/solver.html) puedes encontrar este: `<flag>(((((((.*)*)*)*)*)*)*)!`
|
||||
- En [**este informe**](https://ctftime.org/writeup/25869) usó: `^(?=${flag_prefix}).*.*.*.*.*.*.*.*!!!!$`
|
||||
- En [**this writeup**](https://github.com/jorgectf/Created-CTF-Challenges/blob/main/challenges/TacoMaker%20@%20DEKRA%20CTF%202022/solver/solver.html) puedes encontrar esta: `<flag>(((((((.*)*)*)*)*)*)*)!`
|
||||
- En [**this writeup**](https://ctftime.org/writeup/25869) usó: `^(?=${flag_prefix}).*.*.*.*.*.*.*.*!!!!$`
|
||||
|
||||
### Controlando la Entrada y Regex de ReDoS
|
||||
### ReDoS Controlling Input and Regex
|
||||
|
||||
Los siguientes son ejemplos de **ReDoS** donde **controlas** tanto la **entrada** como la **regex**:
|
||||
```javascript
|
||||
@ -65,16 +94,35 @@ Regexp ([a-zA-Z]+)*$ took 773 milliseconds.
|
||||
Regexp (a+)*$ took 723 milliseconds.
|
||||
*/
|
||||
```
|
||||
## Herramientas
|
||||
### Notas de lenguaje/motor para atacantes
|
||||
|
||||
- JavaScript (browser/Node): El `RegExp` incorporado es un motor de backtracking y comúnmente explotable cuando regex+input están influenciados por un atacante.
|
||||
- Python: `re` usa backtracking. Secuencias largas y ambiguas más una parte final que falla suelen provocar retroceso catastrófico.
|
||||
- Java: `java.util.regex` usa backtracking. Si solo controlas el input, busca endpoints que usen validadores complejos; si controlas los patrones (p. ej., reglas almacenadas), ReDoS suele ser trivial.
|
||||
- Engines such as **RE2/RE2J/RE2JS** or the **Rust regex** crate están diseñados para evitar el retroceso catastrófico. Si te topas con estos, céntrate en otros cuellos de botella (p. ej., patrones enormes) o encuentra componentes que todavía usen motores de backtracking.
|
||||
|
||||
## Tools
|
||||
|
||||
- [https://github.com/doyensec/regexploit](https://github.com/doyensec/regexploit)
|
||||
- Encuentra regexes vulnerables y genera automáticamente inputs maliciosos. Ejemplos:
|
||||
- `pip install regexploit`
|
||||
- Analiza un patrón interactivamente: `regexploit`
|
||||
- Escanea código Python/JS en busca de regexes: `regexploit-py path/` y `regexploit-js path/`
|
||||
- [https://devina.io/redos-checker](https://devina.io/redos-checker)
|
||||
- [https://github.com/davisjam/vuln-regex-detector](https://github.com/davisjam/vuln-regex-detector)
|
||||
- Canal de extremo a extremo para extraer regexes de un proyecto, detectar las vulnerables y validar PoCs en el lenguaje objetivo. Útil para buscar en grandes bases de código.
|
||||
- [https://github.com/tjenkinson/redos-detector](https://github.com/tjenkinson/redos-detector)
|
||||
- CLI/JS simple que razona sobre backtracking para informar si un patrón es seguro.
|
||||
|
||||
## Referencias
|
||||
> Tip: Cuando solo controlas el input, genera cadenas con longitudes que se duplican (p. ej., 2^k caracteres) y registra la latencia. El crecimiento exponencial indica fuertemente un ReDoS viable.
|
||||
|
||||
- [https://owasp.org/www-community/attacks/Regular*expression_Denial_of_Service*-\_ReDoS](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS)
|
||||
## References
|
||||
|
||||
- [https://owasp.org/www-community/attacks/Regular*expression_Denial_of_Service*-_ReDoS](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS)
|
||||
- [https://portswigger.net/daily-swig/blind-regex-injection-theoretical-exploit-offers-new-way-to-force-web-apps-to-spill-secrets](https://portswigger.net/daily-swig/blind-regex-injection-theoretical-exploit-offers-new-way-to-force-web-apps-to-spill-secrets)
|
||||
- [https://github.com/jorgectf/Created-CTF-Challenges/blob/main/challenges/TacoMaker%20%40%20DEKRA%20CTF%202022/solver/solver.html](https://github.com/jorgectf/Created-CTF-Challenges/blob/main/challenges/TacoMaker%20%40%20DEKRA%20CTF%202022/solver/solver.html)
|
||||
- [https://github.com/jorgectf/Created-CTF-Challenges/blob/main/challenges/TacoMaker%20@%20DEKRA%20CTF%202022/solver/solver.html](https://github.com/jorgectf/Created-CTF-Challenges/blob/main/challenges/TacoMaker%20@%20DEKRA%20CTF%202022/solver/solver.html)
|
||||
- [https://ctftime.org/writeup/25869](https://ctftime.org/writeup/25869)
|
||||
- SoK (2024): Una revisión bibliográfica y de ingeniería de Regular Expression Denial of Service (ReDoS) — [https://arxiv.org/abs/2406.11618](https://arxiv.org/abs/2406.11618)
|
||||
- Why RE2 (linear‑time regex engine) — [https://github.com/google/re2/wiki/WhyRE2](https://github.com/google/re2/wiki/WhyRE2)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user