Sulmi mbi sistemet frontend-backend, duke lejuar ndërhyrjen në kërkesat e jashtme

Zbulimi detajet e një sulmi të ri ndaj faqeve të internetit që përdorin modelin frontend-backend, siç janë ato që punojnë përmes rrjetesh të shpërndarjes së përmbajtjes, balancuesve ose proksive. Sulmi lejon, përmes dërgimit të kërkesave të caktuara, të ndërhyjë në përmbajtjen e kërkesave të tjera që përpunohen në të njëjtin rrjedh midis frontendit dhe backendit. Metoda e propozuar është aplikuar me sukses për të organizuar një sulm që lejon kapjen e parametrave të autentifikimit të përdoruesve të shërbimit PayPal, i cili i ka paguar kërkuesve rreth 40 mijë dollarë në kuadër të programit të njoftimit për dobësi të papashtruara. Sulmi gjithashtu është i aplikueshëm për faqet që përdorin rrjetin e shpërndarjes së përmbajtjes Akamai.

Thelbi i problemit është se frontendet dhe backendet shpesh ofrojnë një nivel të ndryshëm mbështetjeje për protokollin HTTP, por ndërkohë inkapsulojnë kërkesat e përdoruesve të ndryshëm në një kanal të zakonshëm. Për të lidhur frontendin që pranon kërkesat me backendin që përpunon kërkesat, krijohet një lidhje TCP me jetëgjatësi të gjatë, përmes së cilës transmetohen kërkesat e përdoruesve, të dërguara në një zinxhir një pas një me ndarje përmes mekanizmave të protokollit HTTP. Për të ndarë kërkesat mund të përdoren titujt 'Content-Length' (i cili përcakton përgjithësisht madhësinë e të dhënave në kërkesë) dhe 'Transfer-Encoding: chunked‘ (lejon dërgimin e të dhënave në pjesë, duke e treguar bllokun në madhësi të ndryshme në formatin '{madhësia}\r\n{blloku}\r\n{madhësia}\r\n{blloku}\r\n0').

Problemi lind nëse frontend-i mbështet vetëm 'Content-Length', por injoron 'Transfer-Encoding: chunked' (p.sh., kështu vepronte CDN Akamai) ose anasjelltas. Në rast se 'Transfer-Encoding: chunked' mbështetet në të dyja anët, për sulmin mund të përdoren veçoritë e zbatimit të parserëve të titujve HTTP (p.sh., kur frontend-i injoron vargje si 'Transfer-Encoding: xchunked', 'Transfer-Encoding: chunked', 'Transfer-Encoding:[tab]chunked', 'X: X[\n]Transfer-Encoding: chunked', 'Transfer-Encoding[\n]: chunked' ose 'Transfer-Encoding : chunked', ndërsa backend-i i përpunon me sukses ato).

Në këtë rast, sulmuesi mund të dërgojë një kërkesë ku njëkohësisht janë të specifikuara header-at «Content-Length» dhe «Transfer-Encoding: chunked», por madhësia në «Content-Length» nuk përputhet me madhësinë e zinxhirit chunked, që është më e vogël se vlera reale. Nëse frontend-i e përpunon dhe e ridrejton kërkesën sipas «Content-Length», ndërsa backend-i pret përfundimin e bllokut bazuar në «Transfer-Encoding: chunked», atëherë fundi i të dhënave sipas «Transfer-Encoding: chunked» do të përcaktohet më herët dhe bishti i mbetur i kërkesës së sulmuesit do të jetë në fillim të kërkesës tjetër, dmth, sulmuesi do të ketë mundësinë të bashkëngjisë të dhëna të rastësishme në fillim të një kërkese të huaj, e cila do të dërgohet pas kësaj.

Sulmi mbi sistemet frontend-backend, duke lejuar ndërhyrjen në kërkesat e jashtme

Për të identifikuar problemin në lidhjen e përdorur mes frontend-it dhe backend-it, mund të dërgoni një kërkesë si vijon:

POST /about HTTP/1.1
Host: example.com
Transfer-Encoding: chunked
Content-Length: 4

1
Z
Q

Problemi është prezent nëse backend-i nuk e përpunon menjëherë kërkesën dhe pret për ardhjen e bllokut përfundimtar të zeros që kufizon të dhënat chunked. Për një verifikim më të plotë është përgatitur një utilitare speciale, e cila gjithashtu teston metodat e mundshme për të fshehur header-in «Transfer-Encoding: chunked» nga frontend-i.

Kryerja e një sulmi të vërtetë varet nga mundësitë e faqes së sulmuar, për shembull, gjatë sulmit ndaj aplikacionit web Trello, mund të zëvendësohet fillimi i kërkesës (të vendosen të dhëna si «PUT /1/members/1234… x=x&csrf=1234&username=testzzz&bio=cake») dhe të dërgohet një mesazh që përmban kërkesën origjinale të një përdoruesi të tretë dhe cookies e autentifikimit të specifikuara në të. Për sulmin ndaj saas-app.com, rezultoi e mundur të realizohej vendosja e kodit JavaScript në përgjigje, përmes vendosjes së tij në një nga parametrat e kërkesës. Për sulmin ndaj redhat.com, u përdor një përpunues i brendshëm për të ridrejtuar në faqen e sulmuesit (u vendos një kërkesë si «POST /search?dest=../assets/idx?redir=//redhat.com@evil.net/ HTTP/1.1»).

Përdorimi i metodës për rrjetet e shpërndarjes së përmbajtjes lejonte thjesht ndrimin e faqes së kërkuar përmes zëvendësimit të titullit "Host:". Sulmi është gjithashtu i aplikueshëm për organizimin e helmimit të përmbajtjes në sistemet e memorizimit të përmbajtjes dhe nxjerrjen e të dhënave konfidenciale të memorizuara. Kulmi i përdorimit të metodës ishte organizimi i një sulmi ndaj PayPal, i cili lejonte kapjen e fjalëkalimeve të dërguara nga përdoruesit gjatë autentifikimit (u realizua ndryshimi i kërkesës iframe për të ekzekutuar JavaScript në kontekstin e faqeve paypal.com/us/gifts, për të cilat nuk aplikohej CSP (Politika e Sigurisë së Përmbajtjes)).

Është interesante se në vitin 2005 ishte është propozuar një teknikë e ngjashme për ndrimin e kërkesave, e cila lejonte ndrimin e të dhënave në proxy të memorizimit (Tomcat, squid, mod_proxy) ose anashkalimin e bllokimeve të firewalle-ve përmes përcaktimit të disa kërkesave "GET" ose "POST" brenda një seance të vetme HTTP.

Burimi: opennet.ru

Blini hosting të besueshëm për faqe interneti me mbrojtje nga DDoS, serverë VPS VDS 🔥 Blini hosting të besueshëm për faqe interneti me mbrojtje nga DDoS, serverë VPS VDS | ProHoster