NXNSAtack حملو سڀني DNS حل ڪندڙن کي متاثر ڪري ٿو

تل ابيب يونيورسٽي مان محققن جو هڪ گروپ ۽ هرزليا (اسرائيل) ۾ انٽرنيشنل ڊسيپلينري سينٽر ترقي ڪئي نئين حملي جو طريقو NXNSAttack (ڪر PDF)، توهان کي اجازت ڏئي ٿو ته ڪنهن به DNS حل ڪندڙ کي ٽريفڪ ايمپليفائر جي طور تي استعمال ڪريو، پيڪٽن جي تعداد جي لحاظ کان 1621 ڀيرا وڌائڻ جي شرح مهيا ڪري ٿي (هر هڪ درخواست لاءِ جيڪو حل ڪندڙ ڏانهن موڪليو ويو، توهان حاصل ڪري سگهو ٿا 1621 درخواستون جيڪي مقتول جي سرور ڏانهن موڪليا وڃن ٿيون) ۽ ٽرئفڪ جي لحاظ کان 163 ڀيرا تائين.

مسئلو پروٽوڪول جي خاصيتن سان لاڳاپيل آهي ۽ سڀني DNS سرورز کي متاثر ڪري ٿو جيڪي ٻيهر ورجائي سوال پروسيسنگ جي حمايت ڪن ٿا، بشمول BIND (CVE-2020-8616) ، ٻٽ (CVE-2020-12667) ، پاور ڊي ايس (CVE-2020-10995) ، ونڊوز DNS سرور и Unbound (CVE-2020-12662)، گڏوگڏ گوگل، Cloudflare، Amazon، Quad9، ICANN ۽ ٻين ڪمپنين جون عوامي DNS خدمتون. حل ڪيو ويو DNS سرور ڊولپرز سان همراه ڪيو ويو، جن هڪ ئي وقت پنهنجي پروڊڪٽس ۾ ڪمزورين کي درست ڪرڻ لاءِ تازه ڪاريون جاري ڪيون. ريليز ۾ لاڳو ٿيل حملي جي حفاظت
اڻڄاتل 1.10.1, ڳٽ حل ڪندڙ 5.1.1, پاور ڊي اين ايس ريڪرسر 4.3.1، 4.2.2، 4.1.16, بينڊ 9.11.19، 9.14.12، 9.16.3.

حملو حملي آور تي مبني آهي درخواستون استعمال ڪندي جيڪي اڳ ۾ ئي اڻ ڏٺل جعلي NS رڪارڊن جي وڏي تعداد جو حوالو ڏين ٿا، جنهن لاءِ نالي جو تعين ڪيو ويو آهي، پر جواب ۾ NS سرورز جي IP پتي بابت معلومات سان گڏ گلو رڪارڊ جي وضاحت ڪرڻ کان سواءِ. مثال طور، هڪ حملو ڪندڙ هڪ سوال موڪلي ٿو sd1.attacker.com جو نالو حل ڪرڻ لاءِ DNS سرور کي ڪنٽرول ڪندي حملي ڪندڙ.com ڊومين لاءِ ذميوار. حملي ڪندڙ جي ڊي اين ايس سرور کي حل ڪندڙ جي درخواست جي جواب ۾، هڪ جواب جاري ڪيو ويو آهي جيڪو sd1.attacker.com پتي جي تعين کي قرباني جي DNS سرور ڏانهن نمائندو ڪري ٿو جواب ۾ اين ايس رڪارڊ کي اشارو ڪندي IP NS سرور جي تفصيل کان سواءِ. جيئن ته ذڪر ڪيل NS سرور اڳ ۾ سامهون نه آيو آهي ۽ ان جي IP پتي جي وضاحت نه ڪئي وئي آهي، حل ڪندڙ NS سرور جي IP پتي کي طئي ڪرڻ جي ڪوشش ڪري ٿو هڪ سوال موڪلي قرباني جي DNS سرور کي ٽارگيٽ ڊومين (victim.com) جي خدمت ڪندي.

NXNSAtack حملو سڀني DNS حل ڪندڙن کي متاثر ڪري ٿو

مسئلو اهو آهي ته حملو ڪندڙ غير ورهائيندڙ اين ايس سرورز جي وڏي لسٽ سان غير موجود جعلي قرباني ذيلي ڊومين نالن سان جواب ڏئي سگهي ٿو (جعلي-1.victim.com، fake-2.victim.com،... fake-1000. قرباني.com). حل ڪندڙ قرباني جي ڊي اين ايس سرور ڏانهن هڪ درخواست موڪلڻ جي ڪوشش ڪندو، پر هڪ جواب حاصل ڪندو ته ڊومين نه مليو، جنهن کان پوء اهو فهرست ۾ ايندڙ اين ايس سرور کي طئي ڪرڻ جي ڪوشش ڪندو، ۽ ائين ئي جيستائين اهو سڀ ڪوشش ڪري چڪو آهي. حملو ڪندڙ پاران درج ڪيل اين ايس رڪارڊ. ان جي مطابق، هڪ حملي ڪندڙ جي درخواست لاء، حل ڪندڙ اين ايس ميزبان کي طئي ڪرڻ لاء وڏي تعداد ۾ درخواستون موڪليندو. جيئن ته NS سرور جا نالا بي ترتيب ٺاهيا ويا آهن ۽ غير موجود ذيلي ڊومينز جو حوالو ڏنو ويو آهي، اهي ڪيش مان حاصل نه ڪيا ويا آهن ۽ حملي ڪندڙ جي هر درخواست جي نتيجي ۾ DNS سرور کي درخواستن جي ڀڃڪڙي ۾ متاثر ٿيل ڊومين جي خدمت ڪندي.

NXNSAtack حملو سڀني DNS حل ڪندڙن کي متاثر ڪري ٿو

محققن مسئلي جي حل لاءِ عوامي DNS حل ڪندڙن جي ڪمزوري جي درجي جو مطالعو ڪيو ۽ اهو طئي ڪيو ته جڏهن CloudFlare حل ڪندڙ (1.1.1.1) ڏانهن سوال موڪلي رهيا آهن، اهو ممڪن آهي ته پيڪيٽس جي تعداد (PAF، Packet Amplification Factor) کي 48 ڀيرا وڌائي، گوگل (8.8.8.8) - 30 ڀيرا، FreeDNS (37.235.1.174) - 50 ڀيرا، OpenDNS (208.67.222.222) - 32 ڀيرا. وڌيڪ قابل ذڪر اشارن لاء مشاهدو ڪيو ويو آهي
سطح 3 (209.244.0.3) - 273 ڀيرا، Quad9 (9.9.9.9) - 415 ڀيرا
SafeDNS (195.46.39.39) - 274 ڀيرا، Verisign (64.6.64.6) - 202 ڀيرا،
الٽرا (156.154.71.1) - 405 ڀيرا، ڪموڊو سيڪيور (8.26.56.26) - 435 ڀيرا، DNS.Watch (84.200.69.80) - 486 ڀيرا، ۽ Norton ConnectSafe (199.85.126.10-569 ڀيرا) BIND 9.12.3 تي ٻڌل سرورز لاءِ، درخواستن جي متوازي ٿيڻ جي ڪري، نفعي جي سطح 1000 تائين پهچي سگھي ٿي. Knot Resolver 5.1.0 ۾، حاصل ڪرڻ جي سطح لڳ ڀڳ ڪيترائي ڀيرا (24-48) آھي، جڏھن کان NS نالن کي ترتيب سان انجام ڏنو ويندو آهي ۽ هڪ درخواست لاءِ اجازت ڏنل نالي جي قرارداد جي قدمن جي تعداد تي اندروني حد تي ٻڌل آهي.

اتي ٻه مکيه دفاعي حڪمت عمليون آهن. DNSSEC سان سسٽم لاءِ تجويز ڪيل استعمال ڪريو آر ايف سي -8198 DNS ڪيش بائي پاس کي روڪڻ لاءِ ڇو ته درخواستون بي ترتيب نالن سان موڪليا وڃن ٿيون. طريقي جو جوهر اهو آهي ته منفي جواب پيدا ڪرڻ بغير مستند DNS سرور سان رابطو ڪرڻ، استعمال ڪندي رينج چيڪنگ ذريعي DNSSEC. ھڪڙو آسان طريقو نالن جي تعداد کي محدود ڪرڻ آھي جيڪي ھڪڙي نمائندي درخواست جي پروسيسنگ دوران وضاحت ڪري سگھجن ٿيون، پر اھو طريقو ڪجھ موجوده ترتيبن سان مسئلا پيدا ڪري سگھي ٿو ڇاڪاڻ ته حدون پروٽوڪول ۾ بيان نه ڪيون ويون آھن.

جو ذريعو: opennet.ru

تبصرو شامل ڪريو