Compania Google a înregistrat cel mai mare atac DDoS asupra infrastructurii sale, cu o intensitate de 398 de milioane de solicitări pe secundă. Noua atacare depășește de 7 ori intensitatea precedentului atac DDoS record, în care infractorii cibernetici au reușit să genereze un flux de 47 de milioane de solicitări pe secundă. Spre comparație, întregul trafic pe Web este estimat la 1-3 miliarde de solicitări pe secundă. Pe lângă Google, companiile Amazon și Cloudflare s-au confruntat, de asemenea, cu acest atac. Posibilitatea de a efectua noul atac este legată de identificarea unei vulnerabilități în protocolul HTTP/2 (CVE-2023-44487), care permite, cu o sarcină minimă asupra clientului, să direcționeze un flux imens de solicitări către server.
Noua tehnică de atac a fost denumită „Rapid Reset” și beneficiază de pe urma faptului că facilitățile de multiplexare a canalelor de comunicare oferite în HTTP/2 permit formarea unui flux de solicitări în cadrul unei conexiuni deja stabilite, fără a deschide noi conexiuni de rețea și fără a aștepta confirmarea primirii pachetelor. Vulnerabilitatea este considerată o consecință a neajunsului protocolului HTTP/2, a cărui specificație prevede că, la încercarea de a deschide un număr excesiv de fluxuri, ar trebui să fie anulate doar fluxurile care depășesc limita, fără a închide întreaga conexiune de rețea.
În mod similar cu metodele anterioare utilizate pentru atacurile asupra HTTP/2, în noul atac este, de asemenea, creat un număr mare de fluxuri în cadrul unei singure conexiuni. Principala diferență a noului atac este că, în loc să aștepte un răspuns, după fiecare solicitare trimisă, este trimis un cadru cu flagul RST_STREAM, care anulează imediat solicitarea. Anularea solicitării într-un stadiu incipient permite eliminarea traficului de retur către client și ocolirea limitărilor existente pe serverele HTTP cu privire la numărul maxim de fluxuri deschise simultan într-o singură conexiune prin HTTP/2. Astfel, în noul atac, volumul solicitărilor trimise către serverul HTTP încetează să depindă de întârzierile dintre trimiterea solicitării și primirea răspunsului (RTT, time round-trip) și este limitat doar de lățimea de bandă a canalului de comunicație.
Deoarece pentru a efectua un atac din partea clientului este suficient să se trimită doar cereri, fără a aștepta răspunsuri, atacul poate fi realizat cu cheltuieli minime. De exemplu, atacul înregistrat de compania Cloudflare, cu 201 milioane de cereri pe secundă, a fost realizat cu ajutorul unui botnet relativ mic, format din 20.000 de computere. Pe partea server costurile de procesare a cererilor primite sunt semnificativ mai mari, în ciuda anulării acestora, deoarece trebuie efectuate operațiuni precum alocarea de structuri de date pentru noi fluxuri, analiza cererii, decomprimarea antetului și corelarea URL-ului cu resursa. În timpul atacului la proxy-urile inversate, atacul se poate extinde la backend-uri, deoarece proxy-ul poate redirecționa cererea către backend înainte de a procesa cadru RST_STREAM.
Atacul poate fi realizat doar asupra serverelor vulnerabile care suportă HTTP/2 (există un script pentru a verifica manifestarea vulnerabilității în servere și un instrument pentru realizarea atacului). Nu s-au înregistrat încă atacuri pentru HTTP/3 și posibilitatea lor nu a fost complet analizată, dar reprezentanții Google îi recomandă dezvoltatorilor servere să adauge în implementările HTTP/3 măsuri de protecție similare celor realizate pentru blocarea atacului la HTTP/2.
Vulnerabilitatea și existența corecțiilor pentru serverele HTTP și proxy-uri:
- nginx (anunț, explicație că vulnerabilitatea nu se manifestă pe deplin în nginx în configurația implicită, deoarece atacul se va opri la limita de cereri per conexiune (adică, după fiecare 1000 de cereri, conexiunea va fi resetată). Corecția a adăugat o protecție suplimentară prin restricționarea intensității cererilor prin directiva „limit_req”).
- În HAProxy, protecția eficientă împotriva depășirii limitei de fluxuri HTTP/2 a fost adăugată încă din 2018 și este activă începând cu versiunea 1.9-dev.
- Apache httpd (se creează o anumită încărcătură pe httpd, dar aceasta nu se propagă la backend-uri și este limitată de limitele de conexiuni pentru clienți în vigoare din 2016).
- mod_h2 pentru Apache httpd.
- caddy
- envoy
- golang (problema a fost rezolvată în versiunile Go 1.21.3 și 1.20.10).
- h2o (patch).
- grpc-go
- hyper (vulnerabilitatea nu se manifestă).
- jetty (corectat în 12.0.2, 11.0.17, 10.0.17 și 9.4.53.v20231009).
- netty
- nghttp2 (corectat în versiunea 1.57.0).
- Facebook proxygen
- .NET și ASP.NET Core (vulnerabilitatea afectează serverul HTTP ASP.NET Core Kestrel).
- Node.js
- proxygen
- swift-nio-http2 (corectat în versiunea 1.28.0).
- Apache Tomcat (corectat în versiunile 11.0.0-M12, 10.1.14, 9.0.81, 8.5.94).
- Apache Traffic Server (corectat în ramura 9.2.x).
Sursa: opennet.ro
