Serangan DDoS HTTP/2 'Rapid Reset' yang Baru

 (cloud.google.com)
1 poin oleh GN⁺ 2023-10-11 | 1 komentar | Bagikan ke WhatsApp
  • DDoS Layer 7 berbasis HTTP/2 yang menargetkan layanan Google dan pelanggan Google Cloud mencapai puncaknya pada Agustus 2023, melampaui 398 juta permintaan per detik
  • Sebagian besar serangan diblokir oleh infrastruktur load balancing global Google sehingga tidak menyebabkan gangguan, dan setelah itu langkah perlindungan tambahan diterapkan untuk memitigasi serangan serupa
  • Rapid Reset membatalkan hanya stream dengan frame RST_STREAM segera setelah permintaan, sambil mempertahankan koneksi agar tetap hidup, sehingga pembuatan permintaan dapat diulang sambil menghindari batas stream simultan
  • Bahkan untuk permintaan yang dibatalkan, server tetap bisa melakukan pekerjaan seperti dekompresi header, pemetaan URL, dan proxy backend, sehingga asimetri biaya menjadi besar
  • Operator HTTP/2 harus memeriksa eksposur dan menerapkan patch, dan saat penyalahgunaan terdeteksi, mitigasi kuncinya adalah mengakhiri koneksi TCP itu sendiri alih-alih hanya permintaan individual

Skala serangan dan respons Google

  • Layanan Google dan pelanggan Cloud menjadi target serangan DDoS Layer 7 berbasis HTTP/2 yang mencapai puncaknya pada Agustus 2023
  • Serangan terbesar melampaui 398 juta permintaan per detik, jauh lebih besar dibanding serangan Layer 7 yang pernah dilaporkan sebelumnya
  • Infrastruktur load balancing global Google memblokir sebagian besar serangan di edge jaringan
    • Tidak terjadi gangguan
    • Dampaknya tetap terbatas
  • Google DDoS Response Team meninjau serangan tersebut lalu menerapkan langkah perlindungan tambahan untuk mengurangi serangan serupa
  • Google memimpin proses pengungkapan terkoordinasi bersama mitra industri untuk menangani vektor serangan HTTP/2 yang baru ini

Titik di mana HTTP/2 menjadi menguntungkan untuk DDoS

  • Sejak akhir 2021, banyak serangan DDoS Layer 7 yang diamati pada layanan 1st-party Google dan proyek Google Cloud yang dilindungi oleh Cloud Armor berbasis HTTP/2
    • Jumlah serangannya juga banyak
    • Tingkat permintaan maksimumnya juga tinggi
  • Efisiensi HTTP/2 tidak hanya meningkatkan efisiensi klien yang sah, tetapi juga dapat meningkatkan efisiensi serangan DDoS

  • Multiplexing stream

    • HTTP/2 mentransmisikan frame antara endpoint melalui stream yang merupakan abstraksi dua arah
    • Berkat multiplexing stream, beberapa permintaan dapat diproses secara bersamaan dalam satu koneksi TCP
    • Batasan utama serangan Layer 7 DoS adalah jumlah koneksi yang dapat ditransmisikan secara bersamaan
      • Setiap koneksi menggunakan memori sistem operasi untuk record socket dan buffer
      • TLS handshake memerlukan waktu CPU
      • Diperlukan 4-tuple unik yang terdiri dari pasangan alamat IP dan port di kedua sisi
    • HTTP/1.1 umumnya memproses permintaan secara serial, sehingga laju permintaan dalam satu koneksi mendekati 1 permintaan per round trip
    • Pada HTTP/2, beberapa stream simultan dapat dibuka dalam satu koneksi TCP, dan setiap stream merepresentasikan satu permintaan HTTP
    • Dalam praktiknya, klien dapat membuka 100 stream per permintaan dan server dapat memprosesnya secara paralel, sehingga throughput efektif satu koneksi dapat naik hingga sekitar 100 permintaan per round trip
    • Akibatnya, tingkat pemanfaatan koneksi bisa hampir 100 kali lebih tinggi dibanding HTTP/1.1

Cara kerja Rapid Reset

  • HTTP/2 memungkinkan klien mengirim frame RST_STREAM untuk memberi tahu server bahwa stream sebelumnya dibatalkan
  • Pembatalan tidak memerlukan koordinasi terpisah antara klien dan server
    • Klien dapat membatalkan secara sepihak
    • Dapat diasumsikan bahwa server yang menerima frame RST_STREAM akan menerapkan pembatalan lebih dulu daripada data lain pada koneksi TCP yang sama
  • Rapid Reset bergantung pada pengiriman frame RST_STREAM segera setelah mengirim frame permintaan
    • Membuat endpoint lawan mulai bekerja lalu dengan cepat me-reset permintaan
    • Permintaan dibatalkan, tetapi koneksi HTTP/2 tetap terbuka
  • Prosedur serangannya sederhana
    • Membuka banyak stream sekaligus seperti serangan HTTP/2 standar
    • Tidak menunggu respons dari server atau proxy
    • Segera membatalkan setiap permintaan
  • Jika reset langsung dimungkinkan, setiap koneksi pada dasarnya dapat membuat sangat banyak permintaan berada dalam status in-flight tanpa batas waktu
    • Penyerang tidak secara eksplisit melampaui batas stream terbuka simultan
    • Jumlah permintaan in-flight ditentukan oleh bandwidth jaringan yang tersedia, bukan oleh round-trip time (RTT)
  • Implementasi server HTTP/2 yang umum mungkin tetap harus melakukan pekerjaan untuk permintaan yang dibatalkan
    • Mengalokasikan struktur data stream baru
    • Mengurai query
    • Mendekompresi header
    • Memetakan URL ke resource
  • Pada implementasi reverse proxy, permintaan dapat diproksikan ke server backend sebelum frame RST_STREAM diproses
  • Karena klien hampir tidak membayar biaya untuk mengirim permintaan, muncul asimetri biaya yang dapat dieksploitasi antara server dan klien
  • Jika permintaan dibatalkan sebelum respons ditulis, server reverse proxy tidak mengirim respons, sehingga bandwidth downlink yang keluar dari server atau proxy ke arah penyerang juga berkurang

Varian serangan yang diamati

  • Dalam beberapa minggu setelah DDoS awal, varian Rapid Reset diamati
  • Varian-varian tersebut tidak seefisien metode awal, tetapi masih bisa lebih efisien daripada serangan DDoS HTTP/2 standar

  • Varian pembatalan batch

    • Varian pertama tidak langsung membatalkan stream, tetapi membuka sekumpulan stream, menunggu sebentar, lalu membatalkannya sekaligus
    • Segera setelah pembatalan, sekumpulan besar stream baru kembali dibuka untuk melanjutkan serangan
    • Metode ini dapat menghindari mitigasi yang hanya didasarkan pada rasio frame RST_STREAM masuk
      • Contoh: kebijakan yang hanya mengizinkan maksimal 100 RST_STREAM per detik per koneksi dan menutup koneksi jika terlampaui
    • Karena tidak memaksimalkan pemanfaatan koneksi, keuntungan utama serangan pembatalan berkurang
    • Meski demikian, implementasinya masih bisa lebih efisien daripada serangan DDoS HTTP/2 standar, sehingga pembatasan rasio pembatalan stream saja akan membutuhkan batas yang cukup ketat

  • Varian tanpa pembatalan

    • Varian kedua sama sekali tidak melakukan pembatalan stream
    • Sebagai gantinya, varian ini mencoba secara optimistis membuka lebih banyak stream daripada jumlah stream simultan yang diumumkan server
    • Ini memungkinkan pipeline permintaan tetap terus penuh sehingga bottleneck RTT klien-proxy bisa dikurangi
    • Jika menargetkan resource yang ditanggapi server HTTP/2 secara instan, bottleneck RTT proxy-server juga dapat dihilangkan
    • RFC HTTP/2 saat ini, RFC 9113, menyarankan bahwa saat ada upaya membuka terlalu banyak stream, yang harus dibatalkan hanya stream yang melampaui batas, bukan seluruh koneksi
    • Dalam struktur sebagian besar server HTTP/2 yang tidak memproses stream berlebih, stream baru dapat diterima dan diproses hampir seketika setelah respons stream sebelumnya selesai, sehingga varian tanpa pembatalan menjadi mungkin

Strategi mitigasi

  • Untuk keluarga serangan ini, memblokir permintaan individual saja sulit menjadi mitigasi yang praktis
  • Ketika penyalahgunaan terdeteksi, seluruh koneksi TCP harus ditutup
  • HTTP/2 mendukung penghentian koneksi melalui tipe frame GOAWAY
  • RFC mendefinisikan prosedur penghentian bertahap: pertama mengirim GOAWAY informasional yang tidak menetapkan batas pembukaan stream baru, lalu setelah satu round trip mengirim GOAWAY yang melarang pembukaan stream tambahan
  • Namun, prosedur GOAWAY bertahap seperti ini sering kali tidak cukup kuat terhadap klien berbahaya
    • Koneksi terlalu lama terekspos terhadap serangan Rapid Reset
    • Tidak dapat menghentikan permintaan masuk
  • Untuk tujuan mitigasi, GOAWAY harus dikonfigurasi agar segera membatasi pembuatan stream

  • Mengidentifikasi koneksi yang menyalahgunakan

    • Tindakan klien membatalkan permintaan itu sendiri tidak selalu merupakan penyalahgunaan
    • Fitur pembatalan pada HTTP/2 memang ditujukan untuk membantu pengelolaan pemrosesan permintaan dengan lebih baik
      • Saat pengguna meninggalkan halaman dan browser tidak lagi membutuhkan resource yang sebelumnya diminta
      • Pada aplikasi yang menggunakan long polling dengan timeout di sisi klien
    • Mitigasi berfokus pada pelacakan statistik koneksi dan penilaian kegunaan tiap koneksi dengan berbagai sinyal serta logika bisnis
    • Misalnya, jika satu koneksi memiliki lebih dari 100 permintaan dan lebih dari 50% di antaranya dibatalkan, koneksi itu dapat menjadi kandidat mitigasi
    • Besar dan jenis respons bergantung pada risiko tiap platform
      • Frame GOAWAY yang dipaksakan
      • Penghentian koneksi TCP secara langsung
    • Untuk memitigasi varian tanpa pembatalan, server HTTP/2 disarankan menutup koneksi yang melampaui batas stream simultan
      • Bisa langsung ditutup
      • Atau ditutup setelah sejumlah kecil pelanggaran berulang

Penerapan ke HTTP/3

  • Google tidak melihat metode serangan ini dapat diterapkan secara langsung ke HTTP/3 (QUIC) karena perbedaan protokol
  • Saat ini Google juga tidak melihat HTTP/3 digunakan sebagai vektor DDoS skala besar
  • Meski demikian, implementasi server HTTP/3 tetap disarankan secara proaktif menerapkan mekanisme untuk membatasi jumlah pekerjaan yang dapat dilakukan oleh satu koneksi transport
    • Arahannya mirip dengan mitigasi HTTP/2 yang dibahas

Koordinasi industri dan CVE

  • Sejak awal penyelidikan Google DDoS Response Team, jelas bahwa jenis serangan ini dapat berdampak luas pada semua layanan yang menyediakan HTTP/2
  • Google memimpin proses pengungkapan kerentanan terkoordinasi dengan memanfaatkan kelompok pengungkapan kerentanan terkoordinasi yang sudah ada
  • Proses pengungkapan difokuskan pada pemberitahuan kepada para implementer HTTP/2 skala besar
    • Perusahaan infrastruktur
    • Penyedia perangkat lunak server
  • Tujuan pemberitahuan awal adalah agar mitigasi dapat dikembangkan dan disiapkan sesuai jadwal pengungkapan terkoordinasi
  • Di masa lalu, pendekatan seperti ini juga menghasilkan penerapan perlindungan secara luas oleh penyedia layanan atau penyediaan pembaruan perangkat lunak untuk berbagai paket dan solusi
  • Dalam proses pengungkapan terkoordinasi, CVE-2023-44487 dicadangkan untuk melacak perbaikan pada berbagai implementasi HTTP/2

Apa yang harus dilakukan operator layanan HTTP/2

  • Serangan ini dapat memberikan dampak besar pada layanan dalam skala apa pun
  • Semua penyedia yang menawarkan layanan HTTP/2 harus mengevaluasi apakah mereka terekspos terhadap isu ini
  • Patch dan pembaruan perangkat lunak untuk web server umum dan bahasa pemrograman mungkin sudah tersedia sekarang atau akan tersedia dalam waktu dekat
  • Perbaikan yang tersedia direkomendasikan untuk diterapkan secepat mungkin
  • Untuk pelanggan Google Cloud, selain patch perangkat lunak, penggunaan Application Load Balancer dan Google Cloud Armor direkomendasikan
    • Google Cloud Armor telah melindungi Google dan pengguna lama Google Cloud Application Load Balancing

Bacaan terkait

1 komentar

 
GN⁺ 2023-10-11
Komentar Hacker News

  • Thread terkait yang sedang berlangsung:
    Serangan DDoS terbesar sejauh ini, memuncak di lebih dari 398 juta request per detik - https://news.ycombinator.com/item?id=37831062
    Kerentanan zero-day HTTP/2 memicu serangan DDoS yang memecahkan rekor - https://news.ycombinator.com/item?id=37830998

  • Bagus melihat tim HAProxy tampaknya sudah menemukan dan memitigasi masalah semacam ini di HTTP/2 sejak 2018: https://www.mail-archive.com/haproxy@formilux.org/msg44134.h...

  • Dalam implementasi server HTTP/2 pada umumnya, bahkan untuk request yang dibatalkan pun server tetap harus melakukan cukup banyak pekerjaan, seperti mengalokasikan struktur data stream baru, mem-parse query, mendekompresi header, dan memetakan URL ke resource
    Dalam implementasi reverse proxy, request bisa saja sudah diproksikan ke server backend sebelum frame RST_STREAM diproses. Sementara itu, klien nyaris tidak mengeluarkan biaya untuk mengirim request, sehingga muncul asimetri biaya yang dapat dieksploitasi antara server dan klien
    Mengejutkan bahwa hal ini tidak diantisipasi saat desain HTTP/2. Serangan amplifikasi di protokol lain sudah lama dikenal. Sama mengejutkannya juga bahwa serangan ini baru terungkap selambat ini, tetapi mungkin sampai baru-baru ini HTTP/2 belum cukup luas diterapkan sehingga belum menjadi target yang bernilai

    • Secara ketat, ini bukan serangan amplifikasi. Ini lebih seperti cara memakai koneksi TCP dengan jauh lebih efisien
    • Saya juga terkejut, tetapi kalau melihat linimasanya, RST_STREAM sudah ada di versi awal SPDY, dan SPDY tampaknya pada umumnya dirancang sekitar 2009
      Serangan seperti Slowloris juga muncul pada waktu yang hampir sama, tetapi saat itu belum dikenal luas. Di sisi lain, SYN cookie diperkenalkan pada 1996, jadi jelas ada preseden historis untuk jenis serangan ketika korban membayar Y sementara penyerang membayar X
    • Seperti kebanyakan hal semacam ini, kemungkinan besar sudah banyak orang yang tidak penting pernah melaporkan dan mencobanya
      Yang tidak biasa adalah ada yang mencobanya secara serius terhadap Google

  • Jadi kita memang butuh HTTP/2 untuk mengirim iklan, tracker, dan framework frontend yang bengkak dengan lebih cepat. Sekarang ia juga mengirim serangan dengan lebih cepat

    • HTTP/2 membuat pengalaman browsing pada koneksi berlatensi tinggi jauh lebih bisa ditoleransi. Secara umum, ia juga membuat halaman web dimuat lebih cepat
      Untungnya HTTP/1.1 masih berfungsi. Kalau tidak suka protokol itu, Anda selalu bisa mengaktifkan HTTP/1.1 di pengaturan browser dan server web
    • Maksudnya HTTP/2 tidak diperlukan? Kalau begitu, alternatif realistisnya apa?

  • Ini satu lagi alasan untuk menjaga protokol dasar tetap kecil. HTTP/2, kalau menghitung SPDY, sudah ada lebih dari 10 tahun, dan baru sekarang jenis serangan ini terungkap
    Saya penasaran kejutan apa yang tersembunyi di HTTP/3 dan QUIC

    • DNS adalah protokol kecil, tetapi tetap disalahgunakan oleh pelaku DDoS di seluruh dunia untuk serangan relay
    • QUIC tidak benar-benar mempertimbangkan serangan amplifikasi dalam desainnya, dan orang-orang yang sejak awal mempermasalahkan hal itu diabaikan
    • HTTP/2 tergolong cukup kecil

  • “Pembatalan” juga harus dimasukkan ke daftar “masalah ilmu komputer yang sulit”
    Seperti item lain di daftar itu, misalnya off-by-one error atau invalidasi cache, sebenarnya tidak luar biasa sulit, tetapi mudah diremehkan dan terlewat. Kalau saja separuh waktu yang dipakai untuk merancang pembuatan, konstruktor, dan inisialisasi juga dipakai untuk merancang penghancuran, pembersihan, pembongkaran, dan pembatalan, sepertinya bug kehabisan resource khususnya akan jauh berkurang

    • Async di Rust benar-benar bagus karena bisa membatalkan Future seketika di titik await mana pun tanpa kerja sama dari pemanggilan individual, sekaligus membatalkan seluruh call stack bersamanya
    • Untuk library C, ini jelas benar. Pembatalan thread POSIX adalah jenis fitur yang keberadaannya saja membuat implikasinya merembes ke mana-mana

  • Saya ingin mengingatkan semua orang bahwa Google adalah perusahaan yang membuat HTTP/2
    Sekarang mereka bercerita seolah-olah sedang menyelamatkan kita secara heroik dari masalah yang mereka ciptakan sendiri, tetapi tidak menyebut bagian bahwa merekalah yang membuatnya. Betapa tidak tahu malunya perusahaan-perusahaan teknologi ini. Microsoft juga sudah seperti ini selama puluhan tahun

    • Mereka mencoba menyelesaikan masalah yang sebenarnya tidak ada

  • Bisa jelaskan apa hal baru dari serangan ini dibanding banjir request biasa?

    • Tergantung apa yang Anda anggap sebagai serangan “banjir request”
      Di HTTP/1.1, Anda bisa mengirim satu request per round-trip time[0]. Dengan multiplexing HTTP/2, Anda bisa mengirim 100 per round-trip time. Dalam serangan ini, Anda bisa mengirim jumlah request yang secara praktis tak terbatas per round-trip time. Saya berharap diagram di tulisan ini menunjukkan perbedaannya, tetapi mungkin Anda sedang membicarakan bentuk serangan yang berbeda dari yang di atas
      [0] Jika mempertimbangkan pipelining HTTP/1.1, satu faktor round-trip time bisa dikurangi, tetapi klien nyata hampir tidak pernah memakai pipelining HTTP/1.1, sehingga penggunaannya sendiri menjadi sinyal yang sangat jelas bahwa trafik itu berbahaya
    • Teknik baru yang dijelaskan ini menghindari batas maksimum jumlah request per detik per klien yang bisa dipaksa penyerang untuk diproses server
      Dengan mengirim request dan reset stream dalam satu koneksi, penyerang bisa mengirim lebih banyak request per koneksi/klien dibanding sebelumnya, sehingga biaya serangan bisa lebih murah atau lebih sulit diblokir

  • Header blog terus muncul dan membuat halaman tidak bisa dibaca