Un atac asupra sistemelor front-end-back-end care ne permite să intrăm în solicitări terță parte

Dezvăluit detalii despre un nou atac asupra site-urilor care utilizează un model front-end-back-end, cum ar fi cele care rulează prin rețele de livrare de conținut, echilibrare de încărcare sau proxy. Atacul permite, prin trimiterea anumitor solicitări, să pătrundă în conținutul altor solicitări procesate în același fir între frontend și backend. Metoda propusă a fost folosită cu succes pentru a organiza un atac care a făcut posibilă interceptarea parametrilor de autentificare ai utilizatorilor serviciului PayPal, care a plătit cercetătorilor aproximativ 40 de mii de dolari ca parte a unui program de informare cu privire la prezența unor vulnerabilități nepatchate. Atacul se aplică și site-urilor care utilizează rețeaua de livrare de conținut Akamai.

Cheia problemei este că front-end-urile și backend-urile oferă adesea niveluri diferite de suport pentru protocolul HTTP, dar în același timp încapsulează cererile de la diferiți utilizatori într-un canal comun. Pentru a conecta cererile de recepție frontend și cererile de procesare backend, se stabilește o conexiune TCP de lungă durată, prin care se transmit cererile utilizatorilor, transmise de-a lungul lanțului una după alta, separate prin protocolul HTTP. Pentru a separa cererile, anteturile „Lungimea conținutului” (determină dimensiunea totală a datelor din cerere) și „Transfer-Codificare: fragmentat„(vă permite să transferați date în părți, specificând blocuri de diferite dimensiuni în formatul „{size}\r\n{block}\r\n{size}\r\n{block}\r\n0”).

Problema apare dacă interfața acceptă doar „Lungimea conținutului”, dar ignoră „Codificarea transferului: fragmentat” (de exemplu, Akamai CDN a făcut acest lucru) sau invers. Dacă Transfer-Encoding: chunked este acceptat pe ambele părți, caracteristicile de implementare ale analizoarelor de antet HTTP pot fi utilizate pentru un atac (de exemplu, atunci când front-end-ul ignoră linii precum „Transfer-Encoding: xchunked”, „Transfer-Encoding: chunked ”, „Transfer-Encoding” :[fila]divizat”, „X: X[\n]Transfer-Encoding: fragmentat”, „Transfer-Coding[\n]: fragmentat” sau „Transfer-Coding: fragmentat” și backend-ul le procesează cu succes).

În acest caz, un atacator poate trimite o solicitare care conține atât anteturile „Content-Length” cât și „Transfer-Encoding: chunked”, dar dimensiunea din „Content-Length” nu corespunde cu dimensiunea lanțului chunked, care este mai mică decât valoarea reală. Dacă interfața procesează și redirecționează cererea conform „Lungimea conținutului” și backend-ul așteaptă ca blocul să se finalizeze pe baza „Transfer-Encoding: chunked”, atunci sfârșitul datelor bazat pe „Transfer-Encoding: chunked” va fi determinat mai devreme și coada rămasă a cererii atacatorul va fi la începutul următoarei cereri, i.e. atacatorul va putea atasa date arbitrare la inceputul cererii altcuiva transmisa in continuare.

Pentru a determina problema în combinația frontend-backend utilizată, puteți trimite o solicitare ca aceasta prin intermediul interfeței:

POST /despre HTTP/1.1
Gazdă: example.com
Transfer-Codificare: fragmentat
Content-Length: 4

1
Z
Q

Problema este prezentă dacă backend-ul nu procesează imediat cererea și așteaptă sosirea blocului final de limite zero de date fragmentate. Pentru o verificare mai completa pregătit un utilitar special care testează și metode posibile pentru a ascunde antetul „Transfer-Encoding: chunked” din frontend.

Efectuarea unui atac real depinde de capacitățile site-ului atacat, de exemplu, atunci când atacați aplicația web Trello, puteți înlocui începutul solicitării (înlocuiți date precum „PUT /1/members/1234... x=x&csrf =1234&username=testzzz&bio=cake”) și trimiteți un mesaj care include solicitarea inițială a unui utilizator terță parte și cookie-ul de autentificare specificat în acesta. Pentru un atac asupra saas-app.com, sa dovedit a fi posibilă înlocuirea codului JavaScript în răspuns, înlocuindu-l într-unul dintre parametrii de solicitare. Pentru atacul pe redhat.com, a fost folosit un handler intern pentru a redirecționa către site-ul web al atacatorului (o solicitare sub forma „POST /search?dest=../assets/idx?redir=//[e-mail protejat]/ HTTP/1.1").

Utilizarea metodei pentru rețelele de livrare de conținut a făcut posibilă înlocuirea pur și simplu a site-ului solicitat prin înlocuirea antetului „Gazdă:”. Atacul poate fi folosit și pentru a otrăvi conținutul sistemelor de stocare în cache și pentru a extrage date confidențiale stocate în cache. Punctul culminant al metodei a fost organizarea unui atac asupra PayPal, care a făcut posibilă interceptarea parolelor trimise de utilizatori în timpul autentificării (cererea iframe a fost modificată pentru a executa JavaScript în contextul paginii paypal.com/us/gifts, pt. căruia CSP (Politica de securitate a conținutului) nu a fost aplicată).

Interesant este că în 2005 a existat propus o tehnică de falsificare a cererilor în esență similară, care vă permite să falsificați datele în proxy-urile de cache (Tomcat, squid, mod_proxy) sau să ocoliți blocarea firewall-ului prin specificarea mai multor solicitări „GET” sau „POST” într-o sesiune HTTP.

Sursa: opennet.ru