התקפת NXNSAttack המשפיעה על כל פותרי ה-DNS

קבוצת חוקרים מאוניברסיטת תל אביב ומהמרכז הבינתחומי בהרצליה (ישראל) התפתח שיטת התקפה חדשה NXNSAtack (PDF), המאפשר לך להשתמש בכל סולבר DNS כמגברי תעבורה, תוך מתן קצב הגברה של עד פי 1621 מבחינת מספר החבילות (עבור כל בקשה שנשלחת לפותר, תוכל להשיג 1621 בקשות שנשלחות לשרת של הקורבן) ועד פי 163 מבחינת תעבורה.

הבעיה קשורה למוזרויות של הפרוטוקול ומשפיעה על כל שרתי ה-DNS התומכים בעיבוד שאילתות רקורסיבי, כולל BIND (CVE-2020-8616) קשר (CVE-2020-12667) PowerDNS (CVE-2020-10995) שרת DNS של Windows и unbound (CVE-2020-12662), כמו גם שירותי DNS ציבוריים של גוגל, Cloudflare, Amazon, Quad9, ICANN וחברות נוספות. התיקון תואם עם מפתחי שרתי DNS, שפרסמו בו זמנית עדכונים לתיקון הפגיעות במוצרים שלהם. הגנת תקיפה מיושמת במהדורות
לא קשור 1.10.1, פתרון קשרים 5.1.1, PowerDNS Recursor 4.3.1, 4.2.2, 4.1.16, BIND 9.11.19, 9.14.12, 9.16.3.

ההתקפה מתבססת על שימוש בבקשות המתייחסות למספר רב של רשומות NS פיקטיביות שלא נראו בעבר, אליהן מואצלת קביעת שמות, אך ללא ציון רשומות דבק עם מידע על כתובות ה-IP של שרתי NS בתגובה. לדוגמה, תוקף שולח שאילתה כדי לפתור את השם sd1.attacker.com על ידי שליטה בשרת ה-DNS האחראי על התחום attacker.com. בתגובה לבקשת הפותר לשרת ה-DNS של התוקף, יוצאת תגובה המאצילה את קביעת הכתובת sd1.attacker.com לשרת ה-DNS של הקורבן על ידי ציון רשומות NS בתגובה מבלי לפרט את שרתי ה-IP NS. מאחר ששרת ה-NS המוזכר לא נתקל בעבר וכתובת ה-IP שלו לא צוינה, הפותר מנסה לקבוע את כתובת ה-IP של שרת ה-NS על ידי שליחת שאילתה לשרת ה-DNS של הקורבן המשרת את דומיין היעד (victim.com).

הבעיה היא שהתוקף יכול להגיב עם רשימה ענקית של שרתי NS שאינם חוזרים על עצמם עם שמות תת-דומיין פיקטיביים של קורבנות (fake-1.victim.com, fake-2.victim.com,... fake-1000. victim.com). הפותר ינסה לשלוח בקשה לשרת ה-DNS של הנפגע, אך יקבל תשובה שהדומיין לא נמצא, ולאחר מכן ינסה לקבוע את שרת ה-NS הבא ברשימה, וכן הלאה עד שינסה את כל רשומות NS הרשומות על ידי התוקף. בהתאם, עבור בקשה של תוקף אחד, הפותר ישלח מספר עצום של בקשות לקביעת מארחי NS. מכיוון ששמות שרתי NS נוצרים באופן אקראי ומתייחסים לתת-דומיינים שאינם קיימים, הם אינם נשלפים מהמטמון וכל בקשה מהתוקף מביאה לשטף של בקשות לשרת ה-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 פעמים. אינדיקטורים בולטים יותר נצפים עבור
Level3 (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 פעמים) - 569 פעמים. עבור שרתים המבוססים על BIND 9.12.3, עקב הקבילה של בקשות, רמת ההגבר יכולה להגיע עד 1000. ב- Knot Resolver 5.1.0, רמת ההגבר היא בערך כמה עשרות פעמים (24-48), מאז קביעת שמות NS מבוצעים ברצף ונשענים על המגבלה הפנימית של מספר שלבי פתרון השמות המותרים עבור בקשה אחת.

ישנן שתי אסטרטגיות הגנה עיקריות. למערכות עם DNSSEC מוּצָע שימוש RFC-8198 כדי למנוע עקיפת מטמון DNS מכיוון שבקשות נשלחות עם שמות אקראיים. מהות השיטה היא ליצור תגובות שליליות מבלי ליצור קשר עם שרתי DNS סמכותיים, באמצעות בדיקת טווח דרך DNSSEC. גישה פשוטה יותר היא להגביל את מספר השמות שניתן להגדיר בעת עיבוד בקשה מואצלת בודדת, אך שיטה זו עלולה לגרום לבעיות בכמה תצורות קיימות מכיוון שהמגבלות אינן מוגדרות בפרוטוקול.

מקור: OpenNet.ru