Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-25 22:20:43 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/h2c-smuggling.md

11 KiB
Raw Blame History

Opgradering van Header Smuggling

{% hint style="success" %} Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Ondersteun HackTricks
{% endhint %}

Probeer Hard Veiligheidsgroep

{% embed url="https://discord.gg/tryhardsecurity" %}

H2C Smuggling

HTTP2 oor Duidelike Tegnologie (H2C)

H2C, of http2 oor duidelike teks, deviates van die norm van tydelike HTTP-verbindinge deur 'n standaard HTTP verbinding na 'n volgehoue een op te gradeer. Hierdie opgegradeerde verbinding gebruik die http2 binêre protokol vir voortgesette kommunikasie, in teenstelling met die enkele versoek-natuur van duidelike teks HTTP.

Die kern van die smuggling probleem ontstaan met die gebruik van 'n omgekeerde proxy. Gewoonlik verwerk die omgekeerde proxy en stuur HTTP versoeke na die agtergrond, en keer die agtergrond se antwoord daarna terug. Wanneer die Connection: Upgrade kop in 'n HTTP versoek teenwoordig is (wat algemeen gesien word met websocket verbindings), behou die omgekeerde proxy 'n volgehoue verbinding tussen kliënt en bediener, wat die voortdurende uitruil wat deur sekere protokolle vereis word, fasiliteer. Vir H2C verbindings vereis nakoming van die RFC die teenwoordigheid van drie spesifieke koppe:

Upgrade: h2c
HTTP2-Settings: AAMAAABkAARAAAAAAAIAAAAA
Connection: Upgrade, HTTP2-Settings

Die kwesbaarheid ontstaan wanneer die omgekeerde proxy, na 'n verbinding opgradering, ophou om individuele versoeke te bestuur, en aanneem dat sy werk van routering voltooi is na verbinding tot standkoming. Die benutting van H2C Smuggling maak dit moontlik om omgekeerde proxy reëls wat tydens versoekverwerking toegepas word, soos pad-gebaseerde routering, outentisering, en WAF verwerking, te omseil, mits 'n H2C verbinding suksesvol geïnisieer word.

Kwesbare Proxies

Die kwesbaarheid hang af van die omgekeerde proxy se hantering van Upgrade en soms Connection headers. Die volgende proxies stuur hierdie headers inherent deur proxy-pass, wat H2C smuggling inherent moontlik maak:

  • HAProxy
  • Traefik
  • Nuster

Aan die ander kant, hierdie dienste stuur nie inherent albei headers tydens proxy-pass nie. Hulle kan egter onveilig gekonfigureer word, wat ongefilterde forwarding van Upgrade en Connection headers toelaat:

  • AWS ALB/CLB
  • NGINX
  • Apache
  • Squid
  • Varnish
  • Kong
  • Envoy
  • Apache Traffic Server

Benutting

Dit is belangrik om op te let dat nie alle bedieners inherent die headers stuur wat benodig word vir 'n conforme H2C verbinding opgradering nie. Soos sodanig, bedieners soos AWS ALB/CLB, NGINX, en Apache Traffic Server, onder andere, blokkeer natuurlik H2C verbindings. Nietemin, dit is die moeite werd om te toets met die nie-conforme Connection: Upgrade variasie, wat die HTTP2-Settings waarde uit die Connection header uitsluit, aangesien sommige agtergronde dalk nie aan die standaarde voldoen nie.

{% hint style="danger" %} Ongeag die spesifieke pad wat in die proxy_pass URL aangedui word (bv. http://backend:9999/socket.io), val die gevestigde verbinding terug na http://backend:9999. Dit maak interaksie met enige pad binne daardie interne eindpunt moontlik, wat hierdie tegniek benut. Gevolglik beperk die spesifikasie van 'n pad in die proxy_pass URL nie toegang nie. {% endhint %}

Die gereedskap h2csmuggler deur BishopFox en h2csmuggler deur assetnote fasiliteer pogings om proxy-opgelegde beskermings te omseil deur 'n H2C verbinding tot stand te bring, wat toegang tot hulpbronne wat deur die proxy beskerm word, moontlik maak.

Vir addisionele inligting oor hierdie kwesbaarheid, veral rakende NGINX, verwys na hierdie gedetailleerde hulpbron.

Websocket Smuggling

Websocket smuggling, anders as die skep van 'n HTTP2 tonnel na 'n eindpunt wat via 'n proxy toeganklik is, stel 'n Websocket tonnel in om potensiële proxy beperkings te omseil en direkte kommunikasie met die eindpunt te fasiliteer.

Scenario 1

In hierdie scenario, 'n agtergrond wat 'n publieke WebSocket API bied saam met 'n ontoeganklike interne REST API, word geteiken deur 'n kwaadwillige kliënt wat toegang tot die interne REST API soek. Die aanval ontvou in verskeie stappe:

  1. Die kliënt begin deur 'n Upgrade versoek na die omgekeerde proxy te stuur met 'n verkeerde Sec-WebSocket-Version protokol weergawe in die header. Die proxy, wat nie die Sec-WebSocket-Version header valideer nie, glo die Upgrade versoek is geldig en stuur dit na die agtergrond.
  2. Die agtergrond antwoord met 'n statuskode 426, wat die verkeerde protokol weergawe in die Sec-WebSocket-Version header aandui. Die omgekeerde proxy, wat die agtergrond se antwoordstatus oor die hoof sien, neem aan dat dit gereed is vir WebSocket kommunikasie en stuur die antwoord 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 gekom het, terwyl die agtergrond die Upgrade versoek verwerp het. Ten spyte hiervan, hou 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 toelaat.

Geaffekteerde omgekeerde proxies 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 opgradering meganisme verander het. Ander proxies kan ook kwesbaar wees.

https://github.com/0ang3el/websocket-smuggle/raw/master/img/2-4.png

Scenario 2

Hierdie scenario behels 'n agtergrond met beide 'n publieke WebSocket API en 'n publieke 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, insluitend 'n addisionele HTTP header Upgrade: websocket. NGINX, wat as die omgekeerde proxy dien, interpreteer dit as 'n standaard Upgrade versoek gebaseer slegs op die Upgrade header, terwyl dit die ander aspekte van die versoek verwaarloos, en stuur dit na die agtergrond.
  2. Die agtergrond voer die gesondheidskontrole API uit, en kontak 'n eksterne hulpbron wat deur die aanvaller beheer word wat 'n HTTP antwoord met statuskode 101 teruggee. Hierdie antwoord, sodra dit deur die agtergrond ontvang en na NGINX gestuur is, mislei die proxy om te dink dat 'n WebSocket verbinding tot stand gekom het as gevolg van sy validasie van slegs die statuskode.

https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-4.png

Waarskuwing: Die kompleksiteit van hierdie tegniek neem toe aangesien dit die vermoë vereis om met 'n eindpunt te kommunikeer wat 'n statuskode 101 kan teruggee.

Uiteindelik word NGINX mislei om te glo dat 'n WebSocket verbinding tussen die kliënt en die agtergrond bestaan. In werklikheid bestaan daar geen sodanige verbinding nie; die gesondheidskontrole REST API was die teiken. Nietemin, die omgekeerde proxy hou die verbinding oop, wat die kliënt toelaat om toegang tot die private REST API deur dit te verkry.

https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-5.png

Meeste omgekeerde proxies is kwesbaar vir hierdie scenario, maar benutting hang af van die teenwoordigheid van 'n eksterne SSRF kwesbaarheid, wat tipies as 'n laag-severiteit probleem beskou word.

Laboratoriums

Kontroleer die laboratoriums om beide scenario's te toets in https://github.com/0ang3el/websocket-smuggle.git

Verwysings

Probeer Hard Veiligheid Groep

{% embed url="https://discord.gg/tryhardsecurity" %}

{% hint style="success" %} Leer & oefen AWS Hacking:HackTricks Opleiding AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Opleiding GCP Red Team Expert (GRTE)

Ondersteun HackTricks
{% endhint %}