Serangan NXNSAttack mengaruhi kabeh solvers DNS

Klompok peneliti saka Universitas Tel Aviv lan Pusat Interdisipliner ing Herzliya (Israel) wis berkembang cara serangan anyar NXNSSerang (PDF), ngidini sampeyan nggunakake sembarang solvers DNS minangka amplifier lalu lintas, nyedhiyakake tingkat amplifikasi nganti 1621 kaping babagan jumlah paket (kanggo saben panjalukan sing dikirim menyang solver, sampeyan bisa entuk 1621 panjalukan sing dikirim menyang server korban) lan nganti 163 kaping babagan lalu lintas.

Masalah kasebut ana gandhengane karo kekhasan protokol lan mengaruhi kabeh server DNS sing ndhukung pangolahan pitakon rekursif, kalebu BIND (CVE-2020-8616) Knot (CVE-2020-12667) PowerDNS (CVE-2020-10995) Windows DNS Server ΠΈ diutyuli (CVE-2020-12662), uga layanan DNS umum Google, Cloudflare, Amazon, Quad9, ICANN lan perusahaan liyane. Perbaikan kasebut dikoordinasi karo pangembang server DNS, sing uga ngeculake nganyari kanggo ndandani kerentanan ing produke. Perlindhungan serangan sing ditindakake ing rilis
Unbound 1.10.1, Knot Resolver 5.1.1, PowerDNS Recursor 4.3.1, 4.2.2, 4.1.16, IKAT 9.11.19, 9.14.12, 9.16.3.

Serangan kasebut adhedhasar panyerang nggunakake panjalukan sing nuduhake akeh rekaman NS fiktif sing sadurunge ora katon, sing didelegasikan kanggo nemtokake jeneng, nanging tanpa nemtokake cathetan lem kanthi informasi babagan alamat IP server NS ing respon. Contone, panyerang ngirim pitakon kanggo ngrampungake jeneng sd1.attacker.com kanthi ngontrol server DNS sing tanggung jawab kanggo domain attacker.com. Nanggepi panjalukan solver menyang server DNS panyerang, respon ditanggepi sing utusan netepake alamat sd1.attacker.com menyang server DNS korban kanthi nuduhake cathetan NS ing respon tanpa rincian server IP NS. Wiwit server NS kasebut durung ditemoni sadurunge lan alamat IP ora ditemtokake, solver nyoba nemtokake alamat IP server NS kanthi ngirim pitakon menyang server DNS korban sing nglayani domain target (victim.com).

Serangan NXNSAttack mengaruhi kabeh solvers DNS

Masalahe yaiku penyerang bisa nanggapi kanthi dhaptar akeh server NS sing ora diulang kanthi jeneng subdomain korban fiktif sing ora ana (fake-1.victim.com, fake-2.victim.com,... fake-1000. korban.com). Penyelesai bakal nyoba ngirim panjalukan menyang server DNS korban, nanging bakal nampa respon yen domain kasebut ora ditemokake, sawise iku bakal nyoba nemtokake server NS sabanjure ing dhaptar, lan sateruse nganti nyoba kabeh. Cathetan NS kadhaptar dening panyerang. Patut, kanggo panyuwunan panyerang, solver bakal ngirim panjaluk akeh kanggo nemtokake host NS. Wiwit jeneng server NS digawe kanthi acak lan ngrujuk menyang subdomain sing ora ana, mula ora dijupuk saka cache lan saben panjaluk saka panyerang nyebabake panjaluk menyang server DNS sing nglayani domain korban.

Serangan NXNSAttack mengaruhi kabeh solvers DNS

Peneliti nyinaoni tingkat kerentanan pemecah DNS umum kanggo masalah kasebut lan nemtokake manawa nalika ngirim pitakon menyang solver CloudFlare (1.1.1.1), bisa nambah jumlah paket (PAF, Faktor Amplifikasi Paket) kaping 48, Google (8.8.8.8) - 30 kaping, FreeDNS (37.235.1.174) - 50 kaping, OpenDNS (208.67.222.222) - 32 kaping. Indikator liyane ngelingke diamati kanggo
Level3 (209.244.0.3) - 273 kaping, Quad9 (9.9.9.9) - 415 kaping
SafeDNS (195.46.39.39) - 274 kaping, Verisign (64.6.64.6) - 202 kaping,
Ultra (156.154.71.1) - 405 kaping, Comodo Secure (8.26.56.26) - 435 kaping, DNS.Watch (84.200.69.80) - 486 kaping, lan Norton ConnectSafe (199.85.126.10) - 569 kaping Kanggo server adhedhasar BIND 9.12.3, amarga paralelisasi panjalukan, tingkat gain bisa nganti 1000. Ing Knot Resolver 5.1.0, tingkat gain kira-kira kaping pirang-pirang (24-48), wiwit tekad Jeneng NS dileksanakake sequentially lan dumunung ing watesan internal ing nomer langkah rΓ©solusi jeneng diijini siji request.

Ana rong strategi pertahanan utama. Kanggo sistem karo DNSSEC diusulake nggunakake RFC-8198 kanggo nyegah cache DNS bypass amarga panjalukan dikirim kanthi jeneng acak. Inti saka metode kasebut yaiku ngasilake tanggapan negatif tanpa ngubungi server DNS sing otoritatif, nggunakake pamriksa jarak liwat DNSSEC. Pendekatan sing luwih prasaja yaiku matesi jumlah jeneng sing bisa ditemtokake nalika ngolah panjalukan sing didelegasikan, nanging cara iki bisa nyebabake masalah karo sawetara konfigurasi sing wis ana amarga watesan kasebut ora ditetepake ing protokol kasebut.

Source: opennet.ru

Add a comment