Serangan DDoS Terbesar Sepanjang Masa Mencapai Puncak 398 Juta rps

 (cloud.google.com)
1 poin oleh GN⁺ 2023-10-11 | 1 komentar | Bagikan ke WhatsApp
  • Di tengah skala serangan DDoS yang tumbuh cepat, Google memitigasi serangan yang mencapai 398 juta rps pada Agustus 2023, yaitu 7,5 kali lebih besar daripada rekor tahun sebelumnya sebesar 46 juta rps
  • Penyerang menggunakan teknik Rapid Reset yang menyalahgunakan multiplexing stream pada HTTP/2, dan sejumlah perusahaan infrastruktur internet turut terdampak
  • Gelombang serangan dimulai pada akhir Agustus 2023 dan berlanjut hingga September, dengan penyedia infrastruktur utama termasuk layanan Google, infrastruktur Google Cloud, dan pelanggan Google menjadi sasaran
  • Google menyerap serangan di network edge dan memperbarui sistem pertahanannya, sementara pelanggan Application Load Balancer dan Cloud Armor juga menerima perlindungan berbasis fondasi yang sama
  • Server, proxy, application server, dan load balancer yang mendukung HTTP/2 dapat terdampak CVE-2023-44487, sehingga perlu memeriksa kerentanan dan menerapkan patch dari vendor

Skala serangan dan teknik Rapid Reset

  • DDoS Response Team Google mengonfirmasi tren bahwa skala serangan DDoS tumbuh secara eksponensial dalam beberapa tahun terakhir
  • Serangan yang diblokir pada Agustus 2023 memiliki skala 7,5 kali lebih besar dibanding rekor maksimum tahun sebelumnya
    • Mencapai puncak 398 juta requests per second (rps)
    • Serangan DDoS terbesar yang tercatat pada 2022 adalah 46 juta rps
  • Serangan yang berlangsung selama 2 menit ini menghasilkan lebih banyak permintaan daripada total tayangan artikel yang dilaporkan Wikipedia sepanjang September 2023
  • Teknik intinya adalah HTTP/2 Rapid Reset baru yang memanfaatkan fitur multiplexing stream pada HTTP/2

Target serangan dan dampak terhadap layanan

  • Gelombang serangan terbaru dimulai pada akhir Agustus 2023 dan terus diamati sepanjang September
  • Target serangan mencakup penyedia infrastruktur utama
    • Layanan Google
    • Infrastruktur Google Cloud
    • Pelanggan Google
  • Google terus mengoperasikan layanannya melalui global load balancing dan infrastruktur mitigasi DDoS
  • Melalui kerja sama dengan mitra industri, Google mengidentifikasi mekanisme serangan dan mengoordinasikan langkah mitigasi untuk melindungi Google, pelanggan, dan internet secara luas

Cara mitigasi Google dan perlindungan untuk pelanggan Cloud

  • Hasil investigasi menunjukkan bahwa serangan menggunakan teknik Rapid Reset yang memanfaatkan fitur multiplexing stream pada protokol HTTP/2 yang banyak digunakan
  • Google memitigasi serangan di network edge
    • Memanfaatkan investasi kapasitas edge agar layanan Google dan layanan pelanggan pada umumnya tidak terdampak
    • Mengembangkan langkah mitigasi setelah memahami metode serangan lebih lanjut
    • Memperbarui sistem proxy dan pertahanan penolakan layanan untuk mengurangi teknik ini secara efisien
  • Application Load Balancer dan Cloud Armor milik Google Cloud menggunakan infrastruktur hardware dan software yang sama dengan yang dipakai Google untuk menyediakan layanan internet-facing miliknya sendiri
  • Aplikasi web dan layanan internet-facing milik pelanggan Cloud yang menggunakan layanan tersebut juga menerima perlindungan serupa

CVE-2023-44487 dan respons bersama industri

  • Segera setelah mendeteksi serangan awal pada Agustus, Google menerapkan strategi mitigasi tambahan dan mengoordinasikan respons bersama industri dengan penyedia cloud serta pengelola software yang mengimplementasikan stack protokol HTTP/2
  • Selama serangan berlangsung, informasi serangan dan metode mitigasi dibagikan secara real time
  • Kolaborasi ini menghasilkan patch dan teknik mitigasi yang digunakan oleh sejumlah penyedia infrastruktur besar
  • Metode serangan baru ini beserta potensi kerentanan pada berbagai proxy, application server, dan load balancer open source maupun komersial diungkapkan melalui responsible disclosure bersama
  • Kerentanan kolektif terhadap serangan ini dilacak sebagai CVE-2023-44487
    • Tingkat keparahan: High
    • Skor CVSS: 7.5/10

Pihak yang mungkin terdampak dan tindakan yang diperlukan

  • Perusahaan maupun individu yang menyediakan workload berbasis HTTP di internet dapat terekspos pada risiko serangan ini
  • Aplikasi web, layanan, dan API di atas server atau proxy yang dapat berkomunikasi melalui HTTP/2 mungkin rentan
  • Organisasi harus memeriksa apakah server yang mendukung HTTP/2 tidak rentan
  • Jika mengoperasikan atau mengelola server dengan dukungan HTTP/2 sendiri, patch vendor terkait harus diterapkan segera setelah tersedia, baik untuk produk open source maupun komersial
  • Patch vendor untuk CVE-2023-44487 merupakan langkah untuk membatasi dampak dari vektor serangan ini

Rekomendasi pertahanan di lingkungan Google Cloud

  • Bertahan dari serangan DDoS skala besar itu sulit, dan untuk tetap menjalankan layanan saat menghadapi serangan skala menengah atau lebih besar, terlepas dari status patch, dibutuhkan investasi infrastruktur yang signifikan
  • Organisasi yang menjalankan layanan di Google Cloud dapat memanfaatkan investasi kapasitas berskala global dari Cross-Cloud Network untuk menyediakan dan melindungi aplikasi
  • Pelanggan Google Cloud yang mengekspos layanan melalui Application Load Balancer global atau regional dilindungi oleh Cloud Armor always-on DDoS protection
    • Serangan yang mengeksploitasi kerentanan seperti CVE-2023-44487 dimitigasi dengan cepat
  • Meskipun Cloud Armor always-on DDoS protection dapat menyerap sebagian besar dari ratusan juta request per detik di network edge Google, jutaan request tak diinginkan per detik masih dapat lolos
  • Untuk menghadapi serangan Layer 7, disarankan menerapkan custom security policies di Cloud Armor, aturan rate limiting yang proaktif, dan Adaptive Protection berbasis AI
  • Informasi teknis tentang gelombang serangan DDoS saat ini dapat dilihat di analisis serangan DDoS HTTP/2 Rapid Reset

Bacaan terkait

1 komentar

 
GN⁺ 2023-10-11
Komentar Hacker News
  • Thread terkait yang sedang berlangsung:
    The novel HTTP/2 'Rapid Reset' DDoS attack - https://news.ycombinator.com/item?id=37830987
    HTTP/2 Zero-Day Vulnerability Results in Record-Breaking DDoS Attacks - https://news.ycombinator.com/item?id=37830998
  • Saya penasaran siapa yang punya insentif untuk menjalankan serangan DDoS seperti ini. Sulit melihat alasan untuk menanggung biaya besar dan pengembangan serangan yang canggih terhadap infrastruktur cloud perusahaan; jawaban yang paling masuk akal tampaknya pemerintah asing
    Meski begitu, jika hasilnya hanya membuat perusahaan teknologi AS dan pelanggannya tidak nyaman selama beberapa jam, saya tetap sulit memahami mengapa ini terus terjadi
    • Saya sudah menangani pertahanan DDoS sekitar 20 tahun, dan jawabannya kadang memang aktor negara, tetapi sering juga penipu dari Eropa Timur. Mereka melakukan serangan besar untuk membangun reputasi di komunitas bot
      Dengan reputasi itu, mereka dibayar oleh klien yang kurang bersih untuk menyerang pesaing; klien itu kadang pemerintah, kadang perusahaan mencurigakan. Tahun lalu, banyak perusahaan kripto saling menyerang situs web
      Orang-orang yang melakukan hal seperti ini biasanya punya kemampuan teknis tinggi, tetapi karena tempat tinggal atau lingkungan tumbuhnya, kesempatan menghasilkan uang dari kemampuan itu sering terbatas
    • Tujuannya promosi. Mereka menyerang Google atau Cloudflare, menunggu mereka menerbitkan tulisan blog “serangan terbesar sepanjang sejarah”, lalu memberi tahu calon pelanggan bahwa botnet mereka bisa melakukan serangan lebih besar daripada siapa pun, dengan tulisan itu sebagai buktinya
    • Jika penyerangnya amatir, tujuannya adalah mendapatkan pamer diri dan reputasi di komunitas peretasan, tidak berbeda dengan meninggalkan grafiti di jalan layang
      Jika penyerangnya tingkat lanjut, mereka sedang menguji kapabilitas dan respons. Taliban dulu membayar anak-anak di luar pangkalan untuk menyalakan petasan demi mengamati taktik, teknik, dan prosedur pertahanan, sekaligus membuat orang menjadi kebal terhadap suara tembakan
      Musuh yang benar-benar hebat tahu cara melakukan yang kedua sambil membuatnya terlihat seperti yang pertama
    • Ini memang informasi lama, tetapi dulu dengan membayar beberapa ratus dolar kepada pemilik botnet, seseorang bisa mengganggu server orang yang tidak ia sukai. Contohnya merusak pertandingan klan game kompetitif. Ada sangat banyak tindakan remeh seperti ini di dunia, sampai mengejutkan
      Dalam kasus botnet Mirai, sebagian pembuatnya juga menjalankan perusahaan mitigasi DDoS. Dengan kata lain, mereka menjual senjata di satu sisi, dan menjual pertahanan terhadap senjata itu di sisi lain
      Kadang motivasinya adalah reputasi, iseng, atau tantangan membuat botnet itu sendiri
    • Dalam serangan berskala besar serupa baru-baru ini, para penulis perangkat lunak botnet berasal dari perusahaan keamanan AS yang menjual solusi mitigasi DDoS(https://en.wikipedia.org/wiki/Mirai_(malware))
  • Di perusahaan saya sebelumnya, kami cukup sering menerima serangan dengan skala yang jauh lebih kecil. Secara internal kami berasumsi itu pesaing yang ingin mengganggu kami, tetapi pada akhirnya tetap menjadi misteri
    Entah itu menargetkan skala infrastruktur internet atau perusahaan tertentu, saya penasaran apakah ada orang yang pernah terlibat dalam serangan seperti ini yang cukup berani atau cukup gila untuk membuat akun sementara dan menceritakan motivasinya
    • Saya pernah mengalami hal serupa, dan awalnya mengira itu script kiddie yang melakukannya untuk bersenang-senang. Ternyata seseorang menulis microservice yang sangat buruk, dan kueri yang tidak efisien sesekali memicu semua alarm
    • Sebuah perusahaan hosting lokal menyerang dengan DDoS bisnis lokal yang memiliki infrastruktur TI, lalu mengiklankan solusi hosting mereka sendiri yang menyertakan perlindungan DDoS
    • Universitas-universitas Swedia diserang oleh “Turkey” setelah kontroversi pembakaran Al-Qur’an yang besar. Mereka juga membanggakannya lewat akun Twitter, tetapi tampaknya cukup jelas itu Rusia
    • Saya pernah mendengar ada serangan yang targetnya adalah subsistem. Caranya menyerang seluruh jaringan agar tidak menarik perhatian
    • Salah satu pelanggan kami diserang DDoS oleh para pesaingnya, tetapi besar kemungkinan para pesaing itu tidak sadar bahwa mereka sedang melakukan DDoS. Mereka melakukan scraping daftar produk dengan sangat agresif tanpa jeda atau pembatasan kecepatan sama sekali, dan akhirnya menjadi DDoS
      Mereka bukan bermaksud memperlambat situs target, tetapi mencoba mengambil data dengan laju yang membuat biaya server pelanggan berbayar sungguhan tidak tertahankan
      Serangan seperti ini berbeda dari serangan DDoS sungguhan, tetapi menurut pengalaman saya jauh lebih umum, dan bisa dimitigasi relatif mudah dengan sesuatu seperti Cloudflare atau Akamai, jadi saya biasanya menyarankan itu kepada pelanggan
  • Cloudflare juga mengalami serangan yang sama: https://blog.cloudflare.com/zero-day-rapid-reset-http2-recor...
  • Bagian yang mengatakan “Google dan AWS juga melihat serangan ini pada waktu yang sama” menarik. Jika ada orang yang bekerja di level seperti ini di penyedia besar, saya penasaran apa yang sebenarnya terjadi selama serangan sebesar ini
    Apakah orang-orang Cloudflare, Google, dan AWS masuk ke rapat video langsung dan saling berkoordinasi untuk mitigasi, atau masing-masing fokus memadamkan masalahnya sendiri sambil mengamati situasi di tempat lain dari jauh?
    • Biasanya masing-masing memadamkan apinya sendiri, tetapi jika seseorang melihat sesuatu yang menarik atau baru, setelah apinya padam mereka akan bertanya apakah tempat lain juga mengalami serangan serupa. Bisa jadi botnet baru, metode serangan baru, dan sebagainya
      Kali ini mereka menyadari bahwa semua orang melihat hal yang sama, dan karena dampaknya bisa sangat besar bagi target kecil, mereka bersama-sama memahami masalahnya serta mengoordinasikan respons keamanan dengan semua penyedia web server
  • Saya penasaran bagaimana mitigasi DDoS bekerja. Apa sebenarnya arti “menaruh situs web di belakang Cloudflare untuk memitigasi DDoS”?
    Apakah sekadar menyediakan bandwidth masuk yang cukup besar sehingga bisa bertahan saat dihantam beberapa Gb/s, sambil menyisakan kapasitas untuk trafik sah?
    • Itu termasuk di dalamnya, tetapi ada jauh lebih banyak unsur. Biasanya Anda harus bisa secara dinamis menambah bandwidth dan sumber daya komputasi untuk menangani banjir trafik masuk

Sebagian besar trafik DDoS bukan HTTP sungguhan, melainkan trafik sampah yang mengisi pipa menuju alamat IP. Pipa yang lebih besar dan banyak server yang tersebar secara geografis bisa membantu. Ada juga kasus seperti banjir TCP SYN, yang hanya membuka koneksi TCP hingga port yang tersedia habis. Permintaan tidak normal seperti ini sering kali bisa ditangani oleh beberapa reverse proxy sederhana di depan server
Kueri yang lebih canggih, yang tampak mengirim trafik HTTP normal, pada akhirnya tetap harus diproses. Caranya bisa dengan merespons dari cache, memasang CAPTCHA untuk memperlambat penyerang dan mengidentifikasi trafik normal, atau menerapkan pembatasan laju. Kita ingin menentukan apakah permintaan itu normal sebelum meneruskannya ke server sebenarnya, dan untuk itu berbagai alat dapat diterapkan

  • Cloudflare dan perusahaan lain dapat mendeteksi apakah sebuah permintaan adalah trafik DDoS, lalu membuang, membatasi, atau memverifikasinya alih-alih meneruskannya ke server
    Server cukup dikonfigurasi untuk membuang semua trafik yang tidak berasal dari Cloudflare, dan cara ini efisien
  • Saat di Google SRE, orang-orang sering bercanda bahwa “trafik DDoS tinggal dikirim ke Australia”
    Secara umum, trafik antar-datacenter internal Google jauh lebih besar daripada volume yang bisa dikirim siapa pun sebagai DDoS, sehingga selalu ada cara untuk menanganinya
  • Jika serangan DDoS itu berbasis kapasitas, satu-satunya cara mitigasinya adalah memiliki jaringan yang cukup tebal untuk menangani trafik tersebut dan bekerja sama dengan ISP untuk mulai memblokirnya di upstream
    Namun tidak semua DDoS berbasis kapasitas. Ada juga yang menyalahgunakan fungsi dasar protokol, seperti serangan slow loris
    https://www.cloudflare.com/learning/ddos/ddos-attack-tools/s...
  • Mitigasi yang umum dibicarakan berarti mengenali permintaan DDoS secara otomatis dan menanganinya dengan biaya lebih rendah tanpa berdampak pada pengguna normal
    Dalam kasus ini, caranya mungkin dengan mengenali apakah klien mereset stream dengan cepat, lalu mengirim trafik itu ke jalur lambat atau memfilternya sama sekali
  • Artikel ini menautkan informasi tambahan tentang fitur HTTP/2 Rapid Reset yang digunakan sebagai bagian dari DDoS: https://cloud.google.com/blog/products/identity-security/how...
  • Tidak ada penyebutan tentang sumber serangan ini? Sepertinya membutuhkan perangkat keras dalam jumlah luar biasa, dan kalau bukan botnet tertentu rasanya mudah dilacak
    • Kabar yang sangat buruk adalah serangan ini sebenarnya tidak membutuhkan botnet yang sangat besar
      https://blog.cloudflare.com/zero-day-rapid-reset-http2-recor...
      “Satu poin penting yang perlu dicatat dari serangan pemecah rekor ini adalah bahwa serangan tersebut melibatkan botnet berukuran sedang yang terdiri dari sekitar 20.000 mesin”
    • Mengingat skalanya, mengungkap sumbernya bisa sensitif secara politik dan hukum
    • Dugaan langsungnya adalah Iran yang melakukannya. Mereka sudah beberapa kali melakukannya sebelumnya dan bersekutu dengan Hamas. Saya belum melihat buktinya, tetapi tampaknya itu dugaan yang cukup aman
  • Tidak bisakah Cloudflare menampilkan halaman pada beberapa permintaan HTTP berikutnya dari IP tersebut yang memberi tahu bahwa “sesuatu di jaringan Anda sedang ikut serta dalam serangan DDoS”
    Sepertinya semua penyedia besar bisa melakukan ini, dengan menyisipkan semacam halaman Turnstile kecil sebelum situs Cloudflare berikutnya yang dikunjungi
    Kalau ada perangkat yang terinfeksi di jaringan saya, saya ingin mengetahuinya, dan saat ini saya juga tidak punya pemantauan nyata untuk mendeteksinya. Ini bukan solusi lengkap, tetapi setidaknya memberi tahu pengguna bahwa ada masalah adalah awal yang baik
    • Bagus. Kita bisa kembali ke era sebelum HTTPS, saat ISP menyisipkan iklan ke dalam HTML. Kali ini yang dinormalisasi adalah penyedia CDN yang melakukannya
    • Di era CGNAT, ini bukan ide yang bagus
  • Blog Cloudflare: https://blog.cloudflare.com/zero-day-rapid-reset-http2-recor...