mirror of
https://github.com/carlospolop/hacktricks
synced 2024-12-26 13:03:37 +00:00
261 lines
21 KiB
Markdown
261 lines
21 KiB
Markdown
# Envenenamento de Cache e Engano de Cache
|
|
|
|
<details>
|
|
|
|
<summary><strong>Aprenda hacking AWS do zero ao herói com</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
|
|
|
Outras maneiras de apoiar o HackTricks:
|
|
|
|
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF** Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
|
|
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
|
|
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
|
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
|
* **Compartilhe seus truques de hacking enviando PRs para o** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
|
|
|
|
</details>
|
|
|
|
<figure><img src="../../.gitbook/assets/image (48).png" alt=""><figcaption></figcaption></figure>
|
|
|
|
\
|
|
Use [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=cache-deception) para construir e **automatizar fluxos de trabalho** facilmente com as **ferramentas comunitárias mais avançadas do mundo**.\
|
|
Tenha Acesso Hoje:
|
|
|
|
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=cache-deception" %}
|
|
|
|
## A diferença
|
|
|
|
> **Qual é a diferença entre envenenamento de cache web e engano de cache web?**
|
|
>
|
|
> * No **envenenamento de cache web**, o atacante faz com que a aplicação armazene algum conteúdo malicioso no cache, e esse conteúdo é servido do cache para outros usuários da aplicação.
|
|
> * No **engano de cache web**, o atacante faz com que a aplicação armazene algum conteúdo sensível pertencente a outro usuário no cache, e o atacante então recupera esse conteúdo do cache.
|
|
|
|
## Envenenamento de Cache
|
|
|
|
O envenenamento de cache tem como objetivo manipular o cache do lado do cliente para forçar os clientes a carregar recursos inesperados, parciais ou sob o controle de um atacante. A extensão do impacto depende da popularidade da página afetada, pois a resposta contaminada é servida exclusivamente aos usuários que visitam a página durante o período de contaminação do cache.
|
|
|
|
A execução de um ataque de envenenamento de cache envolve várias etapas:
|
|
|
|
1. **Identificação de Entradas Não-Chaveadas**: Estes são parâmetros que, embora não sejam necessários para que uma solicitação seja armazenada em cache, podem alterar a resposta retornada pelo servidor. Identificar essas entradas é crucial, pois podem ser exploradas para manipular o cache.
|
|
2. **Exploração das Entradas Não-Chaveadas**: Após identificar as entradas não-chaveadas, o próximo passo envolve descobrir como abusar desses parâmetros para modificar a resposta do servidor de uma forma que beneficie o atacante.
|
|
3. **Garantir que a Resposta Envenenada seja Armazenada em Cache**: O último passo é garantir que a resposta manipulada seja armazenada em cache. Dessa forma, qualquer usuário que acesse a página afetada enquanto o cache estiver envenenado receberá a resposta contaminada.
|
|
|
|
### Descoberta: Verificar cabeçalhos HTTP
|
|
|
|
Normalmente, quando uma resposta foi **armazenada em cache**, haverá um **cabeçalho indicando isso**, você pode verificar quais cabeçalhos deve prestar atenção neste post: [**Cabeçalhos de Cache HTTP**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
|
|
|
|
### Descoberta: Códigos de erro de cache 
|
|
|
|
Se você suspeitar que a resposta está sendo armazenada em um cache, você poderia tentar **enviar solicitações com um cabeçalho ruim**, que deveria ser respondido com um **código de status 400**. Em seguida, tente acessar a solicitação normalmente e se a **resposta for um código de status 400**, você saberá que está vulnerável (e até poderia realizar um DoS).
|
|
|
|
Você pode encontrar mais opções em:
|
|
|
|
{% content-ref url="cache-poisoning-to-dos.md" %}
|
|
[cache-poisoning-to-dos.md](cache-poisoning-to-dos.md)
|
|
{% endcontent-ref %}
|
|
|
|
No entanto, observe que **às vezes esses tipos de códigos de status não são armazenados em cache** então este teste pode não ser confiável.
|
|
|
|
### Descoberta: Identificar e avaliar entradas não-chaveadas
|
|
|
|
Você poderia usar o [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) para **forçar parâmetros e cabeçalhos** que podem estar **alterando a resposta da página**. Por exemplo, uma página pode estar usando o cabeçalho `X-Forwarded-For` para indicar ao cliente para carregar o script de lá:
|
|
```markup
|
|
<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
|
|
```
|
|
### Obter uma resposta prejudicial do servidor back-end
|
|
|
|
Com o parâmetro/cabeçalho identificado, verifique como ele está sendo **sanitizado** e **onde** está **sendo refletido** ou afetando a resposta do cabeçalho. Você consegue abusar de alguma forma (realizar um XSS ou carregar um código JS controlado por você? realizar um DoS?...)
|
|
|
|
### Obter a resposta em cache
|
|
|
|
Depois de ter **identificado** a **página** que pode ser abusada, qual **parâmetro**/**cabeçalho** usar e **como** abusar dele, você precisa obter a página em cache. Dependendo do recurso que você está tentando colocar em cache, isso pode levar algum tempo, talvez seja necessário tentar por vários segundos.\
|
|
O cabeçalho **`X-Cache`** na resposta pode ser muito útil, pois pode ter o valor **`miss`** quando a solicitação não foi colocada em cache e o valor **`hit`** quando está em cache.\
|
|
O cabeçalho **`Cache-Control`** também é interessante para saber se um recurso está em cache e quando será a próxima vez que o recurso será colocado em cache novamente: `Cache-Control: public, max-age=1800`\
|
|
Outro cabeçalho interessante é o **`Vary`**. Esse cabeçalho é frequentemente usado para **indicar cabeçalhos adicionais** que são tratados como **parte da chave de cache** mesmo que normalmente não sejam chaveados. Portanto, se o usuário conhece o `User-Agent` da vítima que está visando, ele pode envenenar o cache para os usuários que usam esse `User-Agent` específico.\
|
|
Mais um cabeçalho relacionado ao cache é o **`Age`**. Ele define o tempo em segundos que o objeto está no cache do proxy.
|
|
|
|
Ao colocar uma solicitação em cache, tenha **cuidado com os cabeçalhos que você usa** porque alguns deles podem ser **usados inesperadamente** como **chaveados** e a **vítima precisará usar o mesmo cabeçalho**. Sempre **teste** um Envenenamento de Cache com **navegadores diferentes** para verificar se está funcionando.
|
|
|
|
## Exemplos de Exploração
|
|
|
|
### Exemplo mais simples
|
|
|
|
Um cabeçalho como `X-Forwarded-For` está sendo refletido na resposta sem ser sanitizado.\
|
|
Você pode enviar uma carga útil básica de XSS e envenenar o cache para que todos que acessem a página sejam afetados pelo XSS:
|
|
```markup
|
|
GET /en?region=uk HTTP/1.1
|
|
Host: innocent-website.com
|
|
X-Forwarded-Host: a."><script>alert(1)</script>"
|
|
```
|
|
_Nota que isso irá envenenar uma solicitação para `/en?region=uk` e não para `/en`_
|
|
|
|
### Envenenamento de cache para DoS
|
|
|
|
{% content-ref url="cache-poisoning-to-dos.md" %}
|
|
[cache-poisoning-to-dos.md](cache-poisoning-to-dos.md)
|
|
{% endcontent-ref %}
|
|
|
|
### Usando envenenamento de cache web para explorar vulnerabilidades de manipulação de cookies
|
|
|
|
Cookies também podem ser refletidos na resposta de uma página. Se você puder abusar disso para causar um XSS, por exemplo, você poderá explorar o XSS em vários clientes que carregam a resposta de cache maliciosa.
|
|
```markup
|
|
GET / HTTP/1.1
|
|
Host: vulnerable.com
|
|
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
|
|
```
|
|
Observe que se o cookie vulnerável for muito utilizado pelos usuários, as solicitações regulares limparão o cache.
|
|
|
|
### Envenenamento de cache com travessia de caminho para roubar chave de API <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
|
|
|
|
[**Este artigo explica**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) como foi possível roubar uma chave de API da OpenAI com uma URL como `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` porque qualquer coisa que corresponda a `/share/*` será armazenada em cache sem o Cloudflare normalizar a URL, o que foi feito quando a solicitação chegou ao servidor web.
|
|
|
|
### Usando vários cabeçalhos para explorar vulnerabilidades de envenenamento de cache na web <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
|
|
|
|
Às vezes, você precisará **explorar várias entradas sem chave** para poder abusar de um cache. Por exemplo, você pode encontrar um **redirecionamento aberto** se definir `X-Forwarded-Host` para um domínio controlado por você e `X-Forwarded-Scheme` para `http`. **Se** o **servidor** estiver **redirecionando** todas as **solicitações HTTP** para HTTPS e usando o cabeçalho `X-Forwarded-Scheme` como o nome de domínio para o redirecionamento. Você pode controlar para onde a página é apontada pelo redirecionamento.
|
|
```markup
|
|
GET /resources/js/tracking.js HTTP/1.1
|
|
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
|
|
X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/
|
|
X-Forwarded-Scheme: http
|
|
```
|
|
### Explorando com o cabeçalho `Vary` limitado
|
|
|
|
Se você descobrir que o cabeçalho **`X-Host`** está sendo usado como **nome de domínio para carregar um recurso JS** mas o cabeçalho **`Vary`** na resposta está indicando **`User-Agent`**. Então, você precisa encontrar uma maneira de exfiltrar o User-Agent da vítima e envenenar o cache usando esse user agent:
|
|
```markup
|
|
GET / HTTP/1.1
|
|
Host: vulnerbale.net
|
|
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
|
|
X-Host: attacker.com
|
|
```
|
|
### Fat Get
|
|
|
|
Envie um pedido GET com o pedido na URL e no corpo. Se o servidor web usar o do corpo, mas o servidor de cache armazenar o da URL, qualquer pessoa que acessar essa URL na verdade usará o parâmetro do corpo. Como a vulnerabilidade que James Kettle encontrou no site do Github:
|
|
```
|
|
GET /contact/report-abuse?report=albinowax HTTP/1.1
|
|
Host: github.com
|
|
Content-Type: application/x-www-form-urlencoded
|
|
Content-Length: 22
|
|
|
|
report=innocent-victim
|
|
```
|
|
### Ocultação de Parâmetros
|
|
|
|
Por exemplo, é possível separar **parâmetros** em servidores ruby usando o caractere **`;`** em vez de **`&`**. Isso poderia ser usado para colocar valores de parâmetros não-chave dentro de parâmetros chave e abusá-los.
|
|
|
|
Laboratório Portswigger: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking)
|
|
|
|
### Explorando a Poisoning de Cache HTTP abusando do HTTP Request Smuggling
|
|
|
|
Aprenda aqui sobre como realizar ataques de [Poisoning de Cache abusando do HTTP Request Smuggling](../http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-poisoning).
|
|
|
|
### Teste automatizado para Poisoning de Cache Web
|
|
|
|
O [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) pode ser usado para testar automaticamente a poisoning de cache web. Ele suporta muitas técnicas diferentes e é altamente personalizável.
|
|
|
|
Exemplo de uso: `wcvs -u example.com`
|
|
|
|
|
|
|
|
<figure><img src="../../.gitbook/assets/image (48).png" alt=""><figcaption></figcaption></figure>
|
|
|
|
\
|
|
Use [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=cache-deception) para construir e **automatizar fluxos de trabalho** facilmente com as **ferramentas comunitárias mais avançadas** do mundo.\
|
|
Acesse hoje:
|
|
|
|
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=cache-deception" %}
|
|
|
|
|
|
|
|
## Exemplos Vulneráveis
|
|
|
|
### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577))
|
|
|
|
ATS encaminhou o fragmento dentro da URL sem removê-lo e gerou a chave de cache apenas usando o host, caminho e consulta (ignorando o fragmento). Assim, a solicitação `/#/../?r=javascript:alert(1)` foi enviada para o backend como `/#/../?r=javascript:alert(1)` e a chave de cache não continha a carga útil dentro dela, apenas host, caminho e consulta.
|
|
|
|
### GitHub CP-DoS
|
|
|
|
O envio de um valor incorreto no cabeçalho content-type acionou uma resposta em cache 405. A chave de cache continha o cookie, então era possível atacar apenas usuários não autenticados.
|
|
|
|
### GitLab + GCP CP-DoS
|
|
|
|
O GitLab usa buckets GCP para armazenar conteúdo estático. **Buckets GCP** suportam o cabeçalho **`x-http-method-override`**. Assim, era possível enviar o cabeçalho `x-http-method-override: HEAD` e envenenar o cache para retornar um corpo de resposta vazio. Também poderia suportar o método `PURGE`.
|
|
|
|
### Rack Middleware (Ruby on Rails)
|
|
|
|
Em aplicações Ruby on Rails, o middleware Rack é frequentemente utilizado. O objetivo do código Rack é pegar o valor do cabeçalho **`x-forwarded-scheme`** e defini-lo como o esquema da solicitação. Quando o cabeçalho `x-forwarded-scheme: http` é enviado, ocorre um redirecionamento 301 para o mesmo local, potencialmente causando uma Negação de Serviço (DoS) para esse recurso. Além disso, a aplicação pode reconhecer o cabeçalho `X-forwarded-host` e redirecionar os usuários para o host especificado. Esse comportamento pode levar ao carregamento de arquivos JavaScript do servidor de um atacante, representando um risco de segurança.
|
|
|
|
### 403 e Buckets de Armazenamento
|
|
|
|
O Cloudflare anteriormente armazenava em cache respostas 403. Tentar acessar S3 ou Azure Storage Blobs com cabeçalhos de Autorização incorretos resultaria em uma resposta 403 que era armazenada em cache. Embora o Cloudflare tenha parado de armazenar em cache respostas 403, esse comportamento ainda pode estar presente em outros serviços de proxy.
|
|
|
|
### Inserindo Parâmetros Chaveados
|
|
|
|
Os caches frequentemente incluem parâmetros GET específicos na chave de cache. Por exemplo, o Varnish do Fastly armazenava o parâmetro `size` em solicitações. No entanto, se uma versão codificada em URL do parâmetro (por exemplo, `siz%65`) também fosse enviada com um valor incorreto, a chave de cache seria construída usando o parâmetro `size` correto. No entanto, o backend processaria o valor no parâmetro codificado em URL. Codificar em URL o segundo parâmetro `size` levou à sua omissão pelo cache, mas sua utilização pelo backend. Atribuir um valor de 0 a esse parâmetro resultou em um erro 400 Bad Request cacheável.
|
|
|
|
### Regras de User Agent
|
|
|
|
Alguns desenvolvedores bloqueiam solicitações com user-agents que correspondem a ferramentas de alto tráfego como FFUF ou Nuclei para gerenciar a carga do servidor. Ironicamente, essa abordagem pode introduzir vulnerabilidades como poisoning de cache e DoS.
|
|
|
|
### Campos de Cabeçalho Ilegais
|
|
|
|
O [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) especifica os caracteres aceitáveis nos nomes de cabeçalho. Cabeçalhos contendo caracteres fora do intervalo **tchar** especificado idealmente deveriam acionar uma resposta 400 Bad Request. Na prática, os servidores nem sempre seguem esse padrão. Um exemplo notável é a Akamai, que encaminha cabeçalhos com caracteres inválidos e armazena em cache qualquer erro 400, desde que o cabeçalho `cache-control` não esteja presente. Um padrão explorável foi identificado onde o envio de um cabeçalho com um caractere inválido, como `\`, resultaria em um erro 400 Bad Request cacheável.
|
|
|
|
### Encontrando novos cabeçalhos
|
|
|
|
[https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6](https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6)
|
|
|
|
## Decepção de Cache
|
|
|
|
O objetivo da Decepção de Cache é fazer com que os clientes **carreguem recursos que serão salvos pelo cache com suas informações sensíveis**.
|
|
|
|
Em primeiro lugar, observe que **extensões** como `.css`, `.js`, `.png` etc geralmente são **configuradas** para serem **salvas** no **cache**. Portanto, se você acessar `www.example.com/profile.php/nonexistent.js`, o cache provavelmente armazenará a resposta porque vê a extensão `.js`. No entanto, se a **aplicação** estiver **reproduzindo** com os **conteúdos sensíveis** do usuário armazenados em _www.example.com/profile.php_, você pode **roubar** esses conteúdos de outros usuários.
|
|
|
|
Outras coisas para testar:
|
|
|
|
* _www.example.com/profile.php/.js_
|
|
* _www.example.com/profile.php/.css_
|
|
* _www.example.com/profile.php/test.js_
|
|
* _www.example.com/profile.php/../test.js_
|
|
* _www.example.com/profile.php/%2e%2e/test.js_
|
|
* _Use extensões menos conhecidas como_ `.avif`
|
|
|
|
Outro exemplo muito claro pode ser encontrado neste relatório: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
|
|
No exemplo, é explicado que se você carregar uma página inexistente como _http://www.example.com/home.php/non-existent.css_, o conteúdo de _http://www.example.com/home.php_ (**com as informações sensíveis do usuário**) será retornado e o servidor de cache vai salvar o resultado.\
|
|
Então, o **atacante** pode acessar _http://www.example.com/home.php/non-existent.css_ em seu próprio navegador e observar as **informações confidenciais** dos usuários que acessaram antes.
|
|
|
|
Observe que o **proxy de cache** deve ser **configurado** para **armazenar** arquivos **com base** na **extensão** do arquivo (_.css_) e não com base no tipo de conteúdo. No exemplo _http://www.example.com/home.php/non-existent.css_ terá um tipo de conteúdo `text/html` em vez de um tipo mime `text/css` (que é o esperado para um arquivo _.css_).
|
|
|
|
Aprenda aqui sobre como realizar [ataques de Decepção de Cache abusando do HTTP Request Smuggling](../http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-deception).
|
|
## Ferramentas Automáticas
|
|
|
|
* [**toxicache**](https://github.com/xhzeem/toxicache): Scanner em Golang para encontrar vulnerabilidades de envenenamento de cache web em uma lista de URLs e testar múltiplas técnicas de injeção.
|
|
|
|
## Referências
|
|
|
|
* [https://portswigger.net/web-security/web-cache-poisoning](https://portswigger.net/web-security/web-cache-poisoning)
|
|
* [https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities](https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities)
|
|
* [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712)
|
|
* [https://youst.in/posts/cache-poisoning-at-scale/](https://youst.in/posts/cache-poisoning-at-scale/)
|
|
* [https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9](https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9)
|
|
* [https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/](https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/)
|
|
|
|
<figure><img src="../../.gitbook/assets/image (48).png" alt=""><figcaption></figcaption></figure>
|
|
|
|
\
|
|
Use [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=cache-deception) para construir facilmente e **automatizar fluxos de trabalho** com as ferramentas comunitárias mais avançadas do mundo.\
|
|
Acesse hoje:
|
|
|
|
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=cache-deception" %}
|
|
|
|
<details>
|
|
|
|
<summary><strong>Aprenda hacking na AWS do zero ao herói com</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
|
|
|
Outras formas de apoiar o HackTricks:
|
|
|
|
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
|
|
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
|
|
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
|
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
|
* **Compartilhe seus truques de hacking enviando PRs para os repositórios** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
|
|
|
</details>
|