सर्व DNS निराकरणकर्त्यांना प्रभावित करणारा NXNSAtack हल्ला

तेल अवीव विद्यापीठातील संशोधकांचा एक गट आणि हर्झलिया (इस्रायल) येथील इंटरडिसिप्लिनरी सेंटर विकसित झाले आहे नवीन हल्ला पद्धत NXNSAtack (PDF), तुम्हाला ट्रॅफिक अॅम्प्लीफायर म्हणून कोणतेही DNS रिझॉल्व्हर वापरण्याची परवानगी देऊन, पॅकेट्सच्या संख्येनुसार 1621 पट वाढीचा दर प्रदान करते (रिझोल्व्हरला पाठवलेल्या प्रत्येक विनंतीसाठी, तुम्ही पीडिताच्या सर्व्हरवर पाठवलेल्या 1621 विनंत्या साध्य करू शकता) आणि रहदारीच्या बाबतीत 163 वेळा.

समस्या प्रोटोकॉलच्या वैशिष्ट्यांशी संबंधित आहे आणि सर्व डीएनएस सर्व्हरवर परिणाम करते जे पुनरावृत्ती क्वेरी प्रक्रियेस समर्थन देतात, यासह बिंद (सीव्हीई -2020-8616), नॉट (सीव्हीई -2020-12667), पॉवर डीएनएस (सीव्हीई -2020-10995), विंडोज डीएनएस सर्व्हर и अनबाउंड (CVE-2020-12662), तसेच Google, Cloudflare, Amazon, Quad9, ICANN आणि इतर कंपन्यांच्या सार्वजनिक DNS सेवा. निराकरण DNS सर्व्हर विकासकांशी समन्वयित केले गेले होते, ज्यांनी त्यांच्या उत्पादनांमधील भेद्यता दूर करण्यासाठी एकाच वेळी अद्यतने जारी केली. रिलीझमध्ये आक्रमण संरक्षण लागू केले
अनबाउंड 1.10.1, नॉट रिझोल्व्हर 5.1.1, PowerDNS रिकसर ४.३.१, ४.२.२, ४.१.१६, BIND 9.11.19, 9.14.12, 9.16.3.

हल्ला आक्रमणकर्त्यावर आधारित आहे ज्यात पूर्वी न पाहिलेल्या काल्पनिक NS रेकॉर्डच्या मोठ्या संख्येचा संदर्भ असलेल्या विनंत्या आहेत, ज्यावर नाव निश्चिती सोपविली जाते, परंतु प्रतिसादात NS सर्व्हरच्या IP पत्त्यांबद्दल माहितीसह गोंद रेकॉर्ड निर्दिष्ट केल्याशिवाय. उदाहरणार्थ, आक्रमणकर्ता attacker.com डोमेनसाठी जबाबदार DNS सर्व्हर नियंत्रित करून sd1.attacker.com नावाचे निराकरण करण्यासाठी क्वेरी पाठवतो. हल्लेखोराच्या DNS सर्व्हरला रिझोल्व्हरच्या विनंतीला प्रतिसाद म्हणून, IP NS सर्व्हरचा तपशील न देता प्रतिसादात NS रेकॉर्ड दर्शवून पीडिताच्या DNS सर्व्हरला sd1.attacker.com पत्त्याचा निर्धार सोपविणारा प्रतिसाद जारी केला जातो. नमूद केलेल्या NS सर्व्हरचा यापूर्वी सामना झाला नसल्यामुळे आणि त्याचा IP पत्ता निर्दिष्ट केलेला नसल्यामुळे, निराकरणकर्ता लक्ष्य डोमेन (victim.com) वर सेवा देणाऱ्या पीडिताच्या DNS सर्व्हरला क्वेरी पाठवून NS सर्व्हरचा IP पत्ता निर्धारित करण्याचा प्रयत्न करतो.

समस्या अशी आहे की हल्लेखोर गैर-अस्तित्वात नसलेल्या काल्पनिक पीडित सबडोमेन नावांसह पुनरावृत्ती न होणाऱ्या NS सर्व्हरच्या मोठ्या सूचीसह प्रतिसाद देऊ शकतो (fake-1.victim.com, fake-2.victim.com,... fake-1000. बळी.com). रिझोल्व्हर पीडिताच्या DNS सर्व्हरला विनंती पाठवण्याचा प्रयत्न करेल, परंतु डोमेन सापडला नाही असा प्रतिसाद त्याला प्राप्त होईल, त्यानंतर तो सूचीतील पुढील NS सर्व्हर निर्धारित करण्याचा प्रयत्न करेल आणि तो सर्व प्रयत्न करेपर्यंत. हल्लेखोराने सूचीबद्ध केलेल्या NS रेकॉर्ड. त्यानुसार, एका आक्रमणकर्त्याच्या विनंतीसाठी, निराकरणकर्ता NS होस्ट निश्चित करण्यासाठी मोठ्या संख्येने विनंत्या पाठवेल. NS सर्व्हरची नावे यादृच्छिकपणे व्युत्पन्न केली जात असल्याने आणि अस्तित्वात नसलेल्या सबडोमेनचा संदर्भ देत असल्याने, ते कॅशेमधून पुनर्प्राप्त केले जात नाहीत आणि आक्रमणकर्त्याच्या प्रत्येक विनंतीमुळे पीडिताच्या डोमेनची सेवा करणार्‍या DNS सर्व्हरला विनंत्यांचा गोंधळ होतो.

संशोधकांनी सार्वजनिक DNS निराकरणकर्त्यांच्या समस्येच्या असुरक्षिततेच्या डिग्रीचा अभ्यास केला आणि निर्धारित केले की क्लाउडफ्लेअर रिझोल्व्हर (1.1.1.1) वर क्वेरी पाठवताना, पॅकेट्सची संख्या (PAF, Packet Amplification Factor) 48 पट वाढवणे शक्य आहे, Google (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 वेळा) - BIND 569 वर आधारित सर्व्हरसाठी, विनंत्यांच्या समांतरीकरणामुळे, लाभ पातळी 9.12.3 पर्यंत पोहोचू शकते. Knot Resolver 1000 मध्ये, फायद्याची पातळी अंदाजे दहापट (5.1.0-24) आहे. NS नावे क्रमाक्रमाने केली जातात आणि एका विनंतीसाठी परवानगी दिलेल्या नाव निराकरण चरणांच्या संख्येवर अंतर्गत मर्यादेवर अवलंबून असतात.

दोन मुख्य संरक्षण धोरणे आहेत. DNSSEC सह प्रणालींसाठी प्रस्तावित वापरा आरएफसी -8198 DNS कॅशे बायपास टाळण्यासाठी कारण विनंत्या यादृच्छिक नावांसह पाठवल्या जातात. DNSSEC द्वारे श्रेणी तपासणीचा वापर करून अधिकृत DNS सर्व्हरशी संपर्क न करता नकारात्मक प्रतिसाद निर्माण करणे हे या पद्धतीचे सार आहे. एक सोपा दृष्टीकोन म्हणजे एकल नियुक्त केलेल्या विनंतीवर प्रक्रिया करताना परिभाषित केल्या जाऊ शकणार्‍या नावांची संख्या मर्यादित करणे, परंतु या पद्धतीमुळे काही विद्यमान कॉन्फिगरेशनमध्ये समस्या उद्भवू शकतात कारण मर्यादा प्रोटोकॉलमध्ये परिभाषित केल्या जात नाहीत.

स्त्रोत: opennet.ru