NXNSAttack შეტევა გავლენას ახდენს ყველა DNS გადამწყვეტზე

მკვლევართა ჯგუფი თელ-ავივის უნივერსიტეტიდან და ჰერცლიის ინტერდისციპლინარული ცენტრიდან (ისრაელი) შეიმუშავა შეტევის ახალი მეთოდი NXNSA თავდასხმა (PDF), რომელიც საშუალებას გაძლევთ გამოიყენოთ ნებისმიერი DNS გადამწყვეტი, როგორც ტრაფიკის გამაძლიერებლები, რაც უზრუნველყოფს გაძლიერების სიჩქარეს 1621-ჯერ პაკეტების რაოდენობის მიხედვით (გამხსნელისთვის გაგზავნილი თითოეული მოთხოვნისთვის შეგიძლიათ მიაღწიოთ 1621 მოთხოვნის გაგზავნას მსხვერპლის სერვერზე) ხოლო მოძრაობის მხრივ 163-ჯერ.

პრობლემა დაკავშირებულია პროტოკოლის თავისებურებებთან და გავლენას ახდენს ყველა DNS სერვერზე, რომლებიც მხარს უჭერენ რეკურსიული შეკითხვის დამუშავებას, მათ შორის BIND (CVE-2020-8616) კვანძი (CVE-2020-12667) PowerDNS (CVE-2020-10995) Windows DNS სერვერი и unbound (CVE-2020-12662), ისევე როგორც Google, Cloudflare, Amazon, Quad9, ICANN და სხვა კომპანიების საჯარო DNS სერვისები. შესწორება კოორდინირებული იყო DNS სერვერის დეველოპერებთან, რომლებმაც ერთდროულად გამოუშვეს განახლებები თავიანთ პროდუქტებში დაუცველობის აღმოსაფხვრელად. თავდასხმისგან დაცვა განხორციელებულია რელიზებში
შეუზღუდავი 1.10.1, კვანძის გამხსნელი 5.1.1, PowerDNS რეკურსორი 4.3.1, 4.2.2, 4.1.16, BIND 9.11.19, 9.14.12, 9.16.3.

თავდასხმა დაფუძნებულია თავდამსხმელზე, რომელიც იყენებს მოთხოვნებს, რომლებიც ეხება მანამდე უხილავი ფიქტიური NS ჩანაწერების დიდ რაოდენობას, რომლებზეც სახელის განსაზღვრაა დელეგირებული, მაგრამ პასუხში NS სერვერების IP მისამართების შესახებ ინფორმაციის წებოვანი ჩანაწერების მითითების გარეშე. მაგალითად, თავდამსხმელი აგზავნის შეკითხვას სახელის sd1.attacker.com გადასაჭრელად DNS სერვერის კონტროლით, რომელიც პასუხისმგებელია attacker.com დომენზე. გადამწყვეტის მოთხოვნის პასუხად თავდამსხმელის DNS სერვერზე, გაიცემა პასუხი, რომელიც გადასცემს sd1.attacker.com მისამართის განსაზღვრას მსხვერპლის DNS სერვერზე, პასუხში NS ჩანაწერების მითითებით IP NS სერვერების დეტალების გარეშე. ვინაიდან აღნიშნული NS სერვერი აქამდე არ შეხვედრილა და მისი IP მისამართი არ არის მითითებული, გადამწყვეტი ცდილობს დაადგინოს NS სერვერის IP მისამართი, მოთხოვნის გაგზავნით მსხვერპლის DNS სერვერზე, რომელიც ემსახურება სამიზნე დომენს (victim.com).

პრობლემა ის არის, რომ თავდამსხმელს შეუძლია უპასუხოს არაგანმეორებადი NS სერვერების დიდი სიით, არარსებული ფიქტიური მსხვერპლის ქვედომენის სახელებით (fake-1.victim.com, fake-2.victim.com,... fake-1000. მსხვერპლი.com). გადამწყვეტი შეეცდება გააგზავნოს მოთხოვნა მსხვერპლის DNS სერვერზე, მაგრამ მიიღებს პასუხს, რომ დომენი ვერ მოიძებნა, რის შემდეგაც ის შეეცდება განსაზღვროს შემდეგი NS სერვერი სიაში და ასე შემდეგ მანამ, სანამ არ ცდის ყველა თავდამსხმელის მიერ ჩამოთვლილი NS ჩანაწერები. შესაბამისად, ერთი თავდამსხმელის მოთხოვნით, გადამწყვეტი გაუგზავნის უამრავ მოთხოვნას NS ჰოსტების დასადგენად. ვინაიდან NS სერვერის სახელები გენერირდება შემთხვევით და ეხება არარსებულ ქვედომენებს, ისინი არ არის ამოღებული ქეშიდან და თავდამსხმელის ყოველი მოთხოვნა იწვევს მოთხოვნებს DNS სერვერზე, რომელიც ემსახურება მსხვერპლის დომენს.

Google (1.1.1.1) - 48-ჯერ, FreeDNS (8.8.8.8) - 30-ჯერ, OpenDNS (37.235.1.174) - 50-ჯერ. უფრო შესამჩნევი მაჩვენებლები შეინიშნება
დონე3 (209.244.0.3) - 273 ჯერ, Quad9 (9.9.9.9) - 415 ჯერ
SafeDNS (195.46.39.39) - 274 ჯერ, Verisign (64.6.64.6) - 202 ჯერ,
Ultra (156.154.71.1) - 405-ჯერ, Comodo Secure (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-ის მქონე სისტემებისთვის შემოთავაზებული გამოყენება RFC-8198 DNS ქეშის გვერდის აცილების თავიდან ასაცილებლად, რადგან მოთხოვნები იგზავნება შემთხვევითი სახელებით. მეთოდის არსი არის უარყოფითი პასუხების გენერირება ავტორიტეტულ DNS სერვერებთან კონტაქტის გარეშე, დიაპაზონის შემოწმების გამოყენებით DNSSEC-ის საშუალებით. უფრო მარტივი მიდგომაა იმ სახელების რაოდენობის შეზღუდვა, რომლებიც შეიძლება განისაზღვროს ერთი დელეგირებული მოთხოვნის დამუშავებისას, მაგრამ ამ მეთოდმა შეიძლება გამოიწვიოს პრობლემები ზოგიერთ არსებულ კონფიგურაციასთან დაკავშირებით, რადგან ლიმიტები არ არის განსაზღვრული პროტოკოლში.

წყარო: opennet.ru