Afrikaans - Ht
HackTricks Training Twitter Linkedin Sponsor

Upgrade Header Smuggling

Support HackTricks

H2C Smuggling

HTTP2 Over Cleartext (H2C)

H2C, of http2 oor duidelike teks, deviates from the norm of transient HTTP connections deur 'n standaard HTTP verbinding na 'n volgehoue een op te gradeer. Hierdie opgegradeerde verbinding gebruik die http2 binêre protokol vir voortdurende 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 agterkant, en keer die agterkant se antwoord daarna terug. egter, wanneer die Connection: Upgrade kop in 'n HTTP versoek teenwoordig is (wat algemeen gesien word met websocket verbindings), hou 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, na 'n verbinding opgradeer, die omgekeerde proxy ophou om individuele versoeke te bestuur, en aanneem dat sy werk van routering voltooi is na die vestiging van die verbinding. 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 is afhanklik 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-verbindinge. 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.

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.

Die gereedskap h2csmuggler deur BishopFox en h2csmuggler deur assetnote fasiliteer pogings om proxy-opgelegde beskermings te omseil deur 'n H2C-verbinding te vestig, 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 deur 'n proxy toeganklik is, vestig 'n Websocket tonnel 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 protokolweergawe in die header. Die proxy, wat misluk om die Sec-WebSocket-Version header te valideer, glo die Upgrade versoek is geldig en stuur dit na die agtergrond.

  2. Die agtergrond antwoord met 'n statuskode 426, wat die verkeerde protokolweergawe 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 gevestig is, terwyl die agtergrond in werklikheid 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, wat kontak maak met '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 gevestig is as gevolg van sy validasie van slegs die statuskode.

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

Waarskuwing: Hierdie tegniek se kompleksiteit 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 in staat stel 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 is afhanklik 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

Ondersteun HackTricks
PreviousHTTP Response Smuggling / DesyncNexthop-by-hop headers

Last updated