mirror of
https://github.com/carlospolop/hacktricks
synced 2025-02-18 15:08:29 +00:00
103 lines
8.7 KiB
Markdown
103 lines
8.7 KiB
Markdown
# Kuboresha Kichwa cha Kuingiza
|
|
|
|
<details>
|
|
|
|
<summary><strong>Jifunze kuhusu kudukua AWS kutoka sifuri hadi shujaa na</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Mtaalam wa Timu Nyekundu ya AWS ya HackTricks)</strong></a><strong>!</strong></summary>
|
|
|
|
Njia nyingine za kusaidia HackTricks:
|
|
|
|
* Ikiwa unataka kuona **kampuni yako ikionekana kwenye HackTricks** au **kupakua HackTricks kwa PDF** Angalia [**MIPANGO YA KUJIUNGA**](https://github.com/sponsors/carlospolop)!
|
|
* Pata [**bidhaa rasmi za PEASS & HackTricks**](https://peass.creator-spring.com)
|
|
* Gundua [**Familia ya PEASS**](https://opensea.io/collection/the-peass-family), mkusanyiko wetu wa [**NFTs**](https://opensea.io/collection/the-peass-family) za kipekee
|
|
* **Jiunge na** 💬 [**Kikundi cha Discord**](https://discord.gg/hRep4RUj7f) au kikundi cha [**telegram**](https://t.me/peass) au **tufuate** kwenye **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
|
* **Shiriki mbinu zako za kudukua kwa kuwasilisha PRs kwa** [**HackTricks**](https://github.com/carlospolop/hacktricks) na [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos za github.
|
|
|
|
</details>
|
|
|
|
## Kuingiza H2C <a href="#http2-over-cleartext-h2c" id="http2-over-cleartext-h2c"></a>
|
|
|
|
### HTTP2 Juu ya Nakala Wazi (H2C) <a href="#http2-over-cleartext-h2c" id="http2-over-cleartext-h2c"></a>
|
|
|
|
H2C, au **http2 juu ya nakala wazi**, inatofautiana na kawaida ya mawasiliano ya HTTP ya muda mfupi kwa kuboresha **mawasiliano ya HTTP ya kawaida kuwa ya kudumu**. Mawasiliano yaliyoboreshwa hutumia itifaki ya binary ya http2 kwa mawasiliano endelevu, tofauti na asili ya ombi moja la HTTP ya maandishi ya kawaida.
|
|
|
|
Makali ya tatizo la kuingiza hutokea wakati wa matumizi ya **proxy ya kurudisha**. Kawaida, proxy ya kurudisha huprocess na kutuma maombi ya HTTP kwa seva ya nyuma, kurudisha jibu la seva ya nyuma baada ya hapo. Walakini, wakati kichwa cha `Connection: Upgrade` kipo katika ombi la HTTP (mara nyingi huonekana na mawasiliano ya websocket), **proxy ya kurudisha inaendeleza mawasiliano ya kudumu** kati ya mteja na seva, kurahisisha kubadilishana kwa mara kwa mara inayohitajika na itifaki fulani. Kwa mawasiliano ya H2C, kufuata RFC kunahitaji uwepo wa vichwa vitatu maalum:
|
|
```
|
|
Upgrade: h2c
|
|
HTTP2-Settings: AAMAAABkAARAAAAAAAIAAAAA
|
|
Connection: Upgrade, HTTP2-Settings
|
|
```
|
|
Mkazo unatokea wakati, baada ya kuboresha uhusiano, reverse proxy inakoma kusimamia maombi binafsi, ikidhani kazi yake ya kuongoza imekamilika baada ya kuanzisha uhusiano. Kuchexploit H2C Smuggling kuruhusu kuzunguka sheria za reverse proxy zilizotumika wakati wa usindikaji wa maombi, kama vile kuongoza kulingana na njia, uthibitishaji, na usindikaji wa WAF, ikidhani uhusiano wa H2C umefanikiwa kuanzishwa.
|
|
|
|
### Proxies Zenye Udhaifu <a href="#exploitation" id="exploitation"></a>
|
|
|
|
Mkazo unategemea jinsi reverse proxy inavyoshughulikia vichwa vya `Upgrade` na mara nyingine `Connection`. Proxies zifuatazo kwa asili huziendeleza vichwa hivi wakati wa kupeleka kwa proxy-pass, hivyo kwa asili kuruhusu H2C smuggling:
|
|
|
|
- HAProxy
|
|
- Traefik
|
|
- Nuster
|
|
|
|
Kinyume chake, huduma hizi kwa asili hazipeleki vichwa vyote viwili wakati wa kupeleka kwa proxy-pass. Hata hivyo, zinaweza kuwekwa kwa njia isiyo salama, kuruhusu kupeleka bila kufuatiliwa kwa vichwa vya `Upgrade` na `Connection`:
|
|
|
|
- AWS ALB/CLB
|
|
- NGINX
|
|
- Apache
|
|
- Squid
|
|
- Varnish
|
|
- Kong
|
|
- Envoy
|
|
- Apache Traffic Server
|
|
|
|
### Kuchexploit <a href="#exploitation" id="exploitation"></a>
|
|
|
|
Ni muhimu kutambua kwamba si seva zote kwa asili huzipeleka vichwa vinavyohitajika kwa ajili ya kuboresha uhusiano wa H2C kwa njia inayofuata sheria. Kwa hivyo, seva kama vile AWS ALB/CLB, NGINX, na Apache Traffic Server, miongoni mwa nyingine, kwa asili zinazuia uhusiano wa H2C. Hata hivyo, ni vyema kujaribu na toleo lisilofuata viwango vya `Connection: Upgrade`, ambavyo havijumuishi thamani ya `HTTP2-Settings` kutoka kwa kichwa cha `Connection`, kwani baadhi ya seva za nyuma hazizingatii viwango.
|
|
|
|
{% hint style="danger" %}
|
|
Bila kujali **njia** maalum iliyoteuliwa katika URL ya `proxy_pass` (k.m., `http://backend:9999/socket.io`), uhusiano ulioanzishwa unakuwa kwa chaguo la msingi `http://backend:9999`. Hii inaruhusu mwingiliano na njia yoyote ndani ya hatima hiyo, ikitumia mbinu hii. Hivyo, kutaja njia katika URL ya `proxy_pass` haitoi kizuizi cha ufikiaji.
|
|
{% endhint %}
|
|
|
|
Zana [**h2csmuggler na BishopFox**](https://github.com/BishopFox/h2csmuggler) na [**h2csmuggler na assetnote**](https://github.com/assetnote/h2csmuggler) huwezesha majaribio ya **kuzunguka ulinzi uliowekwa na proxy** kwa kuanzisha uhusiano wa H2C, hivyo kuruhusu ufikiaji wa rasilimali zilizolindwa na proxy.
|
|
|
|
Kwa habari zaidi kuhusu mkazo huu, hususan kuhusu NGINX, tazama [**rasilimali hii iliyodetauliwa**](../network-services-pentesting/pentesting-web/nginx.md#proxy\_set\_header-upgrade-and-connection).
|
|
|
|
# Websocket Smuggling
|
|
|
|
Websocket smuggling, tofauti na kuanzisha handaki ya HTTP2 kwa hatima inayopatikana kupitia proxy, inaanzisha handaki la Websocket kwa kuzunguka vizuizi vya proxy na kurahisisha mawasiliano moja kwa moja na hatima.
|
|
|
|
## Skenario 1
|
|
|
|
Katika skenario hili, hatima inayotoa API ya Websocket ya umma pamoja na API ya ndani ya REST isiyopatikana inalengwa na mteja mhalifu anayetafuta ufikiaji wa API ya ndani ya REST. Shambulio linajitokeza katika hatua kadhaa:
|
|
|
|
1. Mteja anaanza kwa kutuma ombi la Kuboresha kwa reverse proxy na toleo la itifaki la `Sec-WebSocket-Version` lisilo sahihi katika kichwa. Proxy, ikishindwa kuthibitisha kichwa cha `Sec-WebSocket-Version`, inaamini ombi la Kuboresha ni sahihi na kulipeleka kwa hatima.
|
|
2. Hatima inajibu na nambari ya hali `426`, ikionyesha toleo lisilo sahihi la itifaki katika kichwa cha `Sec-WebSocket-Version`. Reverse proxy, ikipuuza hali ya majibu ya hatima, inadhani kuwa tayari kwa mawasiliano ya Websocket na inapeleka majibu kwa mteja.
|
|
3. Kufuatia hivyo, reverse proxy inadanganywa kuamini kuwa uhusiano wa Websocket umewekwa kati ya mteja na hatima, wakati halisi, hatima ilikataa ombi la Kuboresha. Hata hivyo, proxy inadumisha uhusiano wa TCP au TLS wazi kati ya mteja na hatima, kuruhusu mteja ufikiaji usiozuiliwa wa API ya ndani ya REST kupitia uhusiano huu.
|
|
|
|
Proxies zenyeathiriwa ni pamoja na Varnish, ambayo ilikataa kushughulikia suala hilo, na proxy ya Envoy toleo 1.8.0 au la zamani, na toleo za baadaye zimebadilisha mbinu ya kuboresha. Proxies nyingine pia zinaweza kuwa na udhaifu.
|
|
|
|
![https://github.com/0ang3el/websocket-smuggle/raw/master/img/2-4.png](https://github.com/0ang3el/websocket-smuggle/raw/master/img/2-4.png)
|
|
|
|
## Skenario 2
|
|
|
|
Skenario hili linahusisha hatima yenye API ya Websocket ya umma na API ya REST ya afya kwa ukaguzi, pamoja na API ya ndani ya REST isiyopatikana. Shambulio, lenye utata zaidi, linajumuisha hatua zifuatazo:
|
|
|
|
1. Mteja anatuma ombi la POST kuanzisha API ya ukaguzi wa afya, likijumuisha kichwa cha HTTP cha ziada `Upgrade: websocket`. NGINX, ikifanya kazi kama reverse proxy, inachukulia hili kama ombi la Kuboresha la kawaida kulingana tu na kichwa cha `Upgrade`, ikipuuza vipengele vingine vya ombi, na kulipeleka kwa hatima.
|
|
2. Hatima inatekeleza API ya ukaguzi wa afya, ikifikia rasilimali ya nje inayodhibitiwa na mshambuliaji ambayo inarudisha jibu la HTTP lenye nambari ya hali `101`. Jibu hili, mara tu linapopokelewa na hatima na kusafirishwa kwa NGINX, linadanganya proxy kuamini kuwa uhusiano wa Websocket umewekwa kutokana na uthibitisho wake wa nambari ya hali pekee.
|
|
|
|
![https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-4.png](https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-4.png)
|
|
|
|
> **Onyo:** Utata wa mbinu hii unazidi kwani inahitaji uwezo wa kuingiliana na hatima inayoweza kurudisha nambari ya hali 101.
|
|
|
|
Hatimaye, NGINX inadanganywa kuamini kuwa uhusiano wa Websocket upo kati ya mteja na hatima. Kwa hakika, uhusiano kama huo haupo; API ya REST ya ukaguzi wa afya ilikuwa lengo. Hata hivyo, reverse proxy inadumisha uhusiano wazi, kuruhusu mteja kupata API ya ndani ya REST kupitia huo.
|
|
|
|
![https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-5.png](https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-5.png)
|
|
|
|
Proxies nyingi za reverse ziko hatarini kwa skenario hili, lakini kuchexploit kunategemea uwepo wa udhaifu wa SSRF wa nje, kawaida ukitazamwa kama suala la kiwango cha chini.
|
|
|
|
### Maabara
|
|
|
|
Angalia maabara ili kujaribu mizunguko yote miwili katika [https://github.com/0ang3el/websocket-smuggle.git](https://github.com/0ang3el/websocket-smuggle.git)
|
|
|
|
## Marejeo
|
|
|
|
* [https://blog.assetnote.io/2021/03/18/h2c-smuggling/](https://blog.assetnote.io/2021/03/18/h2c-smuggling/)
|
|
* [https://bishopfox.com/blog/h2c-smuggling-request](https://bishopfox.com/blog/h2c-smuggling-request)
|
|
* [https://github.com/0ang3el/websocket-smuggle.git](https://github.com/0ang3el/websocket-smuggle.git)
|