Sekelompok peneliti dari Universitas Tel Aviv dan Pusat Interdisipliner di Herzliya (Israel) metode serangan baru (), memungkinkan Anda untuk menggunakan penyelesai DNS apa pun sebagai penguat lalu lintas, memberikan tingkat amplifikasi hingga 1621 kali dalam hal jumlah paket (untuk setiap permintaan yang dikirim ke penyelesai, Anda dapat mencapai 1621 permintaan yang dikirim ke server korban) dan hingga 163 kali dalam hal lalu lintas.
Masalahnya terkait dengan kekhasan protokol dan mempengaruhi semua server DNS yang mendukung pemrosesan kueri rekursif, termasuk (CVE-2020-8616), (CVE-2020-12667), (CVE-2020-10995), ΠΈ (CVE-2020-12662), serta layanan DNS publik dari Google, Cloudflare, Amazon, Quad9, ICANN, dan perusahaan lainnya. Perbaikan ini dikoordinasikan dengan pengembang server DNS, yang secara bersamaan merilis pembaruan untuk memperbaiki kerentanan pada produk mereka. Perlindungan serangan diterapkan dalam rilis
, , , .
Serangan ini didasarkan pada penyerang yang menggunakan permintaan yang merujuk ke sejumlah besar catatan NS fiktif yang sebelumnya tidak terlihat, yang mana penentuan nama didelegasikan, tetapi tanpa menentukan catatan lem dengan informasi tentang alamat IP server NS dalam responsnya. Misalnya, penyerang mengirimkan kueri untuk menyelesaikan nama sd1.penyerang.com dengan mengendalikan server DNS yang bertanggung jawab atas domain penyerang.com. Menanggapi permintaan penyelesai ke server DNS penyerang, respons dikeluarkan yang mendelegasikan penentuan alamat sd1.reacher.com ke server DNS korban dengan menunjukkan catatan NS dalam respons tanpa merinci server IP NS. Karena server NS yang disebutkan belum pernah ditemukan sebelumnya dan alamat IP-nya tidak ditentukan, penyelesai mencoba menentukan alamat IP server NS dengan mengirimkan kueri ke server DNS korban yang melayani domain target (victim.com).
Masalahnya adalah penyerang dapat merespons dengan daftar besar server NS yang tidak berulang dengan nama subdomain korban fiktif yang tidak ada (fake-1.victim.com, fake-2.victim.com,... fake-1000. korban.com). Resolver akan mencoba mengirim permintaan ke server DNS korban, tetapi akan menerima respons bahwa domain tidak ditemukan, setelah itu akan mencoba menentukan server NS berikutnya dalam daftar, dan seterusnya hingga mencoba semua Catatan NS dicantumkan oleh penyerang. Oleh karena itu, untuk satu permintaan penyerang, penyelesai akan mengirimkan sejumlah besar permintaan untuk menentukan host NS. Karena nama server NS dibuat secara acak dan mengacu pada subdomain yang tidak ada, nama tersebut tidak diambil dari cache dan setiap permintaan dari penyerang menghasilkan banyak permintaan ke server DNS yang melayani domain korban.
Para peneliti mempelajari tingkat kerentanan pemecah masalah DNS publik terhadap masalah tersebut dan menentukan bahwa ketika mengirim kueri ke pemecah masalah CloudFlare (1.1.1.1), dimungkinkan untuk meningkatkan jumlah paket (PAF, Packet Amplification Factor) sebanyak 48 kali lipat, Google (8.8.8.8) - 30 kali, FreeDNS (37.235.1.174) - 50 kali, OpenDNS (208.67.222.222) - 32 kali. Indikator yang lebih nyata diamati
Level3 (209.244.0.3) - 273 kali, Quad9 (9.9.9.9) - 415 kali
SafeDNS (195.46.39.39) - 274 kali, Verisign (64.6.64.6) - 202 kali,
Ultra (156.154.71.1) - 405 kali, Comodo Secure (8.26.56.26) - 435 kali, DNS.Watch (84.200.69.80) - 486 kali, dan Norton ConnectSafe (199.85.126.10) - 569 kali. Untuk server berdasarkan BIND 9.12.3, karena paralelisasi permintaan, tingkat penguatan dapat mencapai hingga 1000. Dalam Knot Resolver 5.1.0, tingkat penguatan kira-kira beberapa puluh kali lipat (24-48), sejak penentuan Nama NS dilakukan secara berurutan dan bertumpu pada batas internal jumlah langkah penyelesaian nama yang diperbolehkan untuk satu permintaan.
Ada dua strategi pertahanan utama. Untuk sistem dengan DNSSEC untuk menggunakan untuk mencegah bypass cache DNS karena permintaan dikirim dengan nama acak. Inti dari metode ini adalah menghasilkan tanggapan negatif tanpa menghubungi server DNS resmi, menggunakan pemeriksaan jangkauan melalui DNSSEC. Pendekatan yang lebih sederhana adalah dengan membatasi jumlah nama yang dapat ditentukan saat memproses satu permintaan yang didelegasikan, namun metode ini dapat menyebabkan masalah dengan beberapa konfigurasi yang ada karena batasannya tidak ditentukan dalam protokol.
Sumber: opennet.ru