Afrikaans - Ht
HackTricks Training Twitter Linkedin Sponsor

Upgrade Header Smuggling

Leer AWS-hacking vanaf nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

Probeer Hard Security Group

H2C Smokkelary

HTTP2 Oor Skoon Tekste (H2C)

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

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

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.

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.

Die gereedskap h2csmuggler deur BishopFox en h2csmuggler deur assetnote 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.

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.

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.

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.

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

Verwysings

Try Hard Security Group

Leer AWS-hacking van nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

PreviousHTTP Response Smuggling / DesyncNexthop-by-hop headers

Last updated