mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-23 05:03:35 +00:00
132 lines
11 KiB
Markdown
132 lines
11 KiB
Markdown
# Opgraderingskop Smokkelary
|
|
|
|
<details>
|
|
|
|
<summary><strong>Leer AWS-hacking vanaf nul tot held met</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
|
|
|
Ander maniere om HackTricks te ondersteun:
|
|
|
|
* As jy wil sien dat jou **maatskappy geadverteer word in HackTricks** of **HackTricks aflaai in PDF-formaat** Kontroleer die [**INSKRYWINGSPLANNE**](https://github.com/sponsors/carlospolop)!
|
|
* Kry die [**amptelike PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
|
* Ontdek [**Die PEASS Familie**](https://opensea.io/collection/the-peass-family), ons versameling eksklusiewe [**NFTs**](https://opensea.io/collection/the-peass-family)
|
|
* **Sluit aan by die** 💬 [**Discord-groep**](https://discord.gg/hRep4RUj7f) of die [**telegram-groep**](https://t.me/peass) of **volg** ons op **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
|
* **Deel jou haktruuks deur PR's in te dien by die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github-opslag.
|
|
|
|
</details>
|
|
|
|
**Probeer Hard Security Group**
|
|
|
|
<figure><img src="/.gitbook/assets/telegram-cloud-document-1-5159108904864449420.jpg" alt=""><figcaption></figcaption></figure>
|
|
|
|
{% embed url="https://discord.gg/tryhardsecurity" %}
|
|
|
|
***
|
|
|
|
### H2C Smokkelary <a href="#http2-over-cleartext-h2c" id="http2-over-cleartext-h2c"></a>
|
|
|
|
#### HTTP2 Oor Skoon Tekste (H2C) <a href="#http2-over-cleartext-h2c" id="http2-over-cleartext-h2c"></a>
|
|
|
|
H2C, of **http2 oor skoon teks**, wyk af van die norm van tydelike HTTP-verbindings deur 'n standaard HTTP **verbindings na 'n volgehoue een op te gradeer**. Hierdie opgegradeerde verbindings maak gebruik van die http2 binêre protokol vir voortdurende kommunikasie, in teenstelling met die enkelversoek-aard van platte teks HTTP.
|
|
|
|
Die kern van die smokkelprobleem ontstaan met die gebruik van 'n **omgekeerde proksi**. Gewoonlik verwerk en stuur die omgekeerde proksi HTTP-versoeke na die agterkant en stuur daarna die reaksie van die agterkant terug. Wanneer die `Connection: Upgrade`-kop teenwoordig is in 'n HTTP-versoek (gewoonlik gesien met websocket-verbindings), handhaaf die omgekeerde **proksi 'n volgehoue verbinding** tussen klient en bediener, wat die voortdurende uitruil wat deur sekere protokolle vereis word, fasiliteer. Vir H2C-verbindings vereis die RFC die teenwoordigheid van drie spesifieke koppe:
|
|
```
|
|
Upgrade: h2c
|
|
HTTP2-Settings: AAMAAABkAARAAAAAAAIAAAAA
|
|
Connection: Upgrade, HTTP2-Settings
|
|
```
|
|
Die kwesbaarheid ontstaan wanneer, na die opgradering van 'n verbinding, die omgekeerde proxy ophou om individuele versoek te bestuur, en aanneem dat sy taak van roeteverwerking voltooi is na die vestiging van die verbinding. Die uitbuiting van H2C Smuggling maak dit moontlik om omseiling van omgekeerde proxy-reëls wat toegepas word tydens versoekverwerking, soos pad-gebaseerde roeteverwerking, outentifikasie, en WAF-verwerking, toe te laat, mits 'n H2C-verbinding suksesvol geïnisieer word.
|
|
|
|
#### Kwesbare Proksi <a href="#exploitation" id="exploitation"></a>
|
|
|
|
Die kwesbaarheid is afhanklik van die omgekeerde proxy se hantering van `Upgrade` en soms `Connection` koppele. Die volgende proksi's stuur hierdie koppele inherent deur tydens proxy-pass, wat dus H2C-smuggling moontlik maak:
|
|
|
|
* HAProxy
|
|
* Traefik
|
|
* Nuster
|
|
|
|
Daarteenoor stuur hierdie dienste nie hierdie koppele inherent deur tydens proxy-pass nie. Nietemin kan hulle onveilig gekonfigureer word, wat ongefilterde deurstuur van `Upgrade` en `Connection` koppele toelaat:
|
|
|
|
* AWS ALB/CLB
|
|
* NGINX
|
|
* Apache
|
|
* Squid
|
|
* Varnish
|
|
* Kong
|
|
* Envoy
|
|
* Apache Traffic Server
|
|
|
|
#### Uitbuiting <a href="#exploitation" id="exploitation"></a>
|
|
|
|
Dit is noodsaaklik om daarop te let dat nie alle bedieners inherent die koppele deurstuur wat nodig is vir 'n voldoenende H2C-verbinding opgradering nie. Gevolglik blokkeer bedieners soos AWS ALB/CLB, NGINX, en Apache Traffic Server, onder andere, natuurlik H2C-verbindinge. Nietemin is dit die moeite werd om te toets met die nie-voldoenende `Connection: Upgrade` variant, wat die `HTTP2-Settings` waarde uit die `Connection` kop uitsluit, aangesien sommige agtergronde nie aan die standaarde voldoen nie.
|
|
|
|
{% hint style="danger" %}
|
|
Ongeag die spesifieke **pad** aangewys in die `proxy_pass` URL (bv., `http://backend:9999/socket.io`), gaan die gevestigde verbinding standaard na `http://backend:9999`. Dit maak dit moontlik om met enige pad binne daardie interne eindpunt te interaksieer deur van hierdie tegniek gebruik te maak. Gevolglik beperk die spesifikasie van 'n pad in die `proxy_pass` URL nie die toegang nie.
|
|
{% endhint %}
|
|
|
|
Die gereedskap [**h2csmuggler deur BishopFox**](https://github.com/BishopFox/h2csmuggler) en [**h2csmuggler deur assetnote**](https://github.com/assetnote/h2csmuggler) fasiliteer pogings om **omseiling van proxy-geïmplementeerde beskerming** te bewerkstellig deur 'n H2C-verbinding te vestig, wat sodoende toegang tot hulpbronne wat deur die proxy beskerm word, moontlik maak.
|
|
|
|
Vir addisionele inligting oor hierdie kwesbaarheid, veral met betrekking tot NGINX, verwys na [**hierdie gedetailleerde bron**](../network-services-pentesting/pentesting-web/nginx.md#proxy\_set\_header-upgrade-and-connection).
|
|
|
|
## Websocket Smuggling
|
|
|
|
Websocket-smuggling, in teenstelling met die skep van 'n HTTP2-tonnel na 'n eindpunt wat toeganklik is via 'n proxy, vestig 'n Websocket-tonnel om potensiële proxy-beperkings te omseil en direkte kommunikasie met die eindpunt te fasiliteer.
|
|
|
|
### Scenario 1
|
|
|
|
In hierdie scenario word 'n agtergrond wat 'n openbare WebSocket API bied saam met 'n ontoeganklike interne REST API geteiken deur 'n skadelike kliënt wat toegang tot die interne REST API soek. Die aanval ontvou in verskeie stappe:
|
|
|
|
1. Die kliënt begin deur 'n Opgraderingsversoek na die omgekeerde proxy te stuur met 'n onkorrekte `Sec-WebSocket-Version` protokolverise in die kop. Die proxy, wat nie die `Sec-WebSocket-Version` kop valideer nie, glo dat die Opgraderingsversoek geldig is en stuur dit na die agtergrond.
|
|
2. Die agtergrond reageer met 'n statuskode `426`, wat die onkorrekte protokolverise in die `Sec-WebSocket-Version` kop aandui. Die omgekeerde proxy, wat die agtergrond se reaksie-status oorsien, aanvaar gereedskap vir Websocket-kommunikasie en stuur die reaksie na die kliënt.
|
|
3. Gevolglik word die omgekeerde proxy mislei om te glo dat 'n Websocket-verbinding tussen die kliënt en agtergrond tot stand gebring is, terwyl die agtergrond in werklikheid die Opgraderingsversoek verwerp het. Ten spyte hiervan handhaaf die proxy 'n oop TCP- of TLS-verbinding tussen die kliënt en agtergrond, wat die kliënt onbeperkte toegang tot die private REST API deur hierdie verbinding bied.
|
|
|
|
Geraakte omgekeerde proksi's sluit Varnish in, wat geweier het om die probleem aan te spreek, en Envoy proxy weergawe 1.8.0 of ouer, met latere weergawes wat die opgraderingsmeganisme verander het. Ander proksi's kan ook vatbaar wees.
|
|
|
|
![https://github.com/0ang3el/websocket-smuggle/raw/master/img/2-4.png](https://github.com/0ang3el/websocket-smuggle/raw/master/img/2-4.png)
|
|
|
|
### Scenario 2
|
|
|
|
Hierdie scenario behels 'n agtergrond met beide 'n openbare WebSocket API en 'n openbare REST API vir gesondheidskontrole, saam met 'n ontoeganklike interne REST API. Die aanval, meer kompleks, behels die volgende stappe:
|
|
|
|
1. Die kliënt stuur 'n POST-versoek om die gesondheidskontrole-API te aktiveer, met 'n bykomende HTTP-kop `Upgrade: websocket`. NGINX, as omgekeerde proxy, interpreteer dit as 'n standaard Opgraderingsversoek gebaseer op slegs die `Upgrade`-kop, wat die versoek se ander aspekte ignoreer, en stuur dit na die agtergrond.
|
|
2. Die agtergrond voer die gesondheidskontrole-API uit, wat uitreik na 'n eksterne hulpbron wat deur die aanvaller beheer word en 'n HTTP-reaksie met statuskode `101` terugstuur. Hierdie reaksie, sodra dit deur die agtergrond ontvang en na NGINX gestuur word, mislei die proxy om te dink dat 'n Websocket-verbinding tot stand gebring is as gevolg van sy validasie van slegs die statuskode.
|
|
|
|
![https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-4.png](https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-4.png)
|
|
|
|
> **Waarskuwing:** Die kompleksiteit van hierdie tegniek neem toe omdat dit die vermoë vereis om met 'n eindpunt te interaksieer wat in staat is om 'n statuskode 101 terug te stuur.
|
|
|
|
Uiteindelik word NGINX mislei om te glo dat 'n Websocket-verbinding tussen die kliënt en die agtergrond bestaan. In werklikheid bestaan daar geen sulke verbinding nie; die gesondheidskontrole REST API was die teiken. Nietemin handhaaf die omgekeerde proxy die verbinding oop, wat die kliënt in staat stel om toegang tot die private REST API daardeur te verkry.
|
|
|
|
![https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-5.png](https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-5.png)
|
|
|
|
Die meeste omgekeerde proksi's is vatbaar vir hierdie scenario, maar die uitbuiting is afhanklik van die teenwoordigheid van 'n eksterne SSRF-kwesbaarheid, wat gewoonlik as 'n lae-sewiteit-kwessie beskou word.
|
|
|
|
#### Laboratoriums
|
|
|
|
Kyk na die laboratoriums om beide scenario's te toets op [https://github.com/0ang3el/websocket-smuggle.git](https://github.com/0ang3el/websocket-smuggle.git)
|
|
|
|
### Verwysings
|
|
|
|
* [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)
|
|
|
|
|
|
**Try Hard Security Group**
|
|
|
|
<figure><img src="/.gitbook/assets/telegram-cloud-document-1-5159108904864449420.jpg" alt=""><figcaption></figcaption></figure>
|
|
|
|
{% embed url="https://discord.gg/tryhardsecurity" %}
|
|
|
|
<details>
|
|
|
|
<summary><strong>Leer AWS-hacking van nul tot held met</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
|
|
|
Ander maniere om HackTricks te ondersteun:
|
|
|
|
* As jy wil sien dat jou **maatskappy geadverteer word in HackTricks** of **HackTricks in PDF aflaai**, kyk na die [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
|
* Kry die [**offisiële PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
|
* Ontdek [**The PEASS Family**](https://opensea.io/collection/the-peass-family), ons versameling eksklusiewe [**NFTs**](https://opensea.io/collection/the-peass-family)
|
|
* **Sluit aan by die** 💬 [**Discord-groep**](https://discord.gg/hRep4RUj7f) of die [**telegram-groep**](https://t.me/peass) of **volg** ons op **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
|
* **Deel jou haktruuks deur PR's in te dien by die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github-opslag.
|
|
|
|
</details>
|