DNS Tunneling

מנהור DNS הוא טכניקה שמסתירה נתונים שאינם DNS, כמו קבצים גנובים או תעבורת command-and-control, בתוך שאילתות ותשובות DNS רגילות. ה-implant מקודד את הנתונים לתוך ה-subdomains שהוא מבצע להם lookup, ושרת שמות בשליטת התוקף מפענח אותם ומשיב בחזרה. מכיוון שרשתות כמעט אף פעם לא חוסמות DNS, הערוץ מחליק מעבר לפילטרים שהיו עוצרים כמעט כל דבר אחר.

DNS הוא הפרוטוקול היחיד שכמעט כל רשת חייבת להשאיר פתוח, ולכן הוא הופך לדרך שקטה להעביר נתונים מעבר להגנות שעוקבות אחרי כל השאר. אותו טריק משרת שני תפקידים שונים, עובד עם כלים מהמדף, ונשא חלק מהחדירות החמורות ביותר שתועדו.

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

הסבירו לי כאילו אני בן 10

תארו לעצמכם בניין שבו פקיד דואר אחד רשאי להעביר כל מעטפה פנימה והחוצה, ואף אחד לא בודק מה בפנים, כי הדואר תמיד חייב להמשיך לנוע. אז במקום להסתיר הודעה בתוך המעטפה, מסתירים אותה בכתובת שעל החזית. הפקיד מעביר אותה למשרד היחיד שיודע להפוך את הכתובת בחזרה להודעה, ומביא את התשובה כתובה על הכתובת הבאה. מנהור DNS עובד באותו אופן: הוא מסתיר נתונים בכתובות שהמחשב מבצע להן lookup, כי ה-lookups האלה תמיד מורשים לעבור.

איך מנהור DNS באמת עובד

DNS רגיל הוא פשוט: מחשב שואל "מה הכתובת של השם הזה?" ושרת עונה. מנהור DNS מנצל את חילופי הבקשה-והתשובה האלה כדי להעביר נתונים שאין להם שום קשר לחיפוש אתר. זה עובד כי DNS resolution ישמח לנתב שאילתה על כל דומיין אל שרת השמות שאחראי עליו, והתוקף מחזיק בדומיין, ולכן הוא מחזיק בשרת שמקבל את השאילתה.

החצי היוצא: נתונים בשאילתה

כדי לשלוח נתונים החוצה, נוזקה מקודדת אותם לתוך ה-subdomain של lookup לדומיין שבשליטת התוקף. MITRE ATT&CK מתעדת את זה ישירות: נוזקת NightClub "יכולה להשתמש בתוסף מנהור DNS כדי לבצע הוצאת נתונים (exfiltration) על ידי הוספתם לחלק ה-subdomain של בקשת DNS." השאילתות נבנות במיוחד כך שייראו לא חשודות. ערכת הכלים Uroburos, למשל, "קידדה תקשורת C2 יוצאת בבקשות DNS שהורכבו ממחרוזות תווים שנועדו להיראות כמו שמות דומיין סטנדרטיים." לרשת זה נראה כמו מכונה שמבצעת resolution לשם מארח מוזר אבל סביר.

החצי הנכנס: נתונים בתשובה

התשובה חוזרת באותו אופן, מקודדת בתוך רשומות DNS. פקודות "עשויות להיות מוטמעות ברשומות DNS שונות, למשל רשומות TXT או A," וגם הפקודות וגם התוצאות שלהן נוסעות בתוך התעבורה שנראית רגילה. רשומות TXT הן מועדפות כי הן נועדו להחזיק טקסט שרירותי, מה שהופך אותן למיכלים מרווחים לנתונים מקודדים.

מקצה לקצה, הסיבוב המלא הוא מה שהופך את זה לערוץ. המכונה של הקורבן מבצעת lookup לשם ארוך ומקודד; DNS resolution רגיל, שעושה בדיוק את עבודתו, מעביר את השאילתה מקפיצה לקפיצה עד שהיא מגיעה לשרת השמות האחראי על הדומיין של התוקף, שהוא השרת של התוקף עצמו. השרת הזה קורא את הנתונים מתוך ה-subdomain, פועל לפיהם, ומקודד את התשובה שלו לתוך הרשומה שהוא שולח בחזרה. אף צד לא פותח אף פעם חיבור שחומת אש הייתה חושבת לפקפק בו. במונחים הכלליים יותר של MITRE, זה protocol tunneling: "עטיפה מפורשת של פרוטוקול בתוך פרוטוקול אחר" כדי להימנע מזיהוי ומסינון רשתי.

שני תפקידים: command-and-control והוצאת נתונים

אותו מנגנון משרת שתי מטרות נפרדות, ושווה להחזיק אותן בנפרד.

כערוץ command-and-control, מנהור DNS מאפשר לתוקף לשלוח הוראות לנוזקה ולקבל תוצאות, הכל מעל DNS, כשהפקודות והתוצאות שלהן מוטמעות בתעבורת השאילתות שנראית רגילה. הוא עובד כערוץ ראשי חשאי, ועובד באותה מידה גם כגיבוי: כשערוץ רועש יותר כמו HTTP נחסם, הנוזקה יכולה לעבור בשקט ל-DNS ולהמשיך לפעול.

וריאנט הוצאת הנתונים

כהוצאת נתונים, זו דרך לגנוב נתונים מתוך רשת מעל פרוטוקול שאינו ערוץ ה-C2 הראשי, מה ש-MITRE מכנה exfiltration over an alternative protocol. יש כאן מלכוד שמעצב את האופן שבו תוקפים משתמשים בזה: DNS הוא צינור ברוחב פס נמוך. לדחוס נתונים דרך lookups זה איטי ורועש, ולכן הוצאת נתונים ב-DNS נוטה לשאת דברים קטנים ובעלי ערך גבוה, כמו פרטי הזדהות או מטא-נתונים של מערכת, ולא קבצים בכמות גדולה, ומפעילים זהירים מגבילים את הקצב בכוונה כדי להישאר שקטים. MITRE מקטלגת את זה תחת exfiltration over an alternative protocol, בוריאנטים שנעים מקידוד לא מוצפן ועד ערוצים מוצפנים לחלוטין, אבל צורת מנהור ה-DNS זהה בכל פעם.

הכלים, והמתקפות האמיתיות

מנהור DNS אינו תיאורטי, והוא לא נבנה ידנית בכל פעם. כלים מתועדים וקמפיינים בעלי שם השתמשו בו במשך שנים.

הכלים

שני כלים עולים שוב ושוב. iodine הוא כלי למטרות כלליות שבמילותיו שלו "מאפשר לכם למנהר נתוני IPv4 דרך שרת DNS," וזה גם תזכורת שלטכניקה יש שימושים לגיטימיים. dnscat2 הוא ממוקד יותר: הוא "תוכנן ליצור ערוץ command-and-control (C&C) מוצפן מעל פרוטוקול DNS, שהוא מנהרה יעילה החוצה מכמעט כל רשת." שניהם בשימוש של penetration testers, ובאותה נשימה, של פורצים אמיתיים.

המתקפות

המקרה הבולט הוא SUNBURST, הנוזקה מאחורי חדירת שרשרת האספקה של SolarWinds ב-2020, שהשתמשה ב-DNS לתעבורת command-and-control שתוכננה לחקות תקשורת API רגילה של SolarWinds. התחפושת היא העיקר: המנהרה נבנתה כך שתיראה כמו התעבורה שהתוכנה כבר הייתה אמורה לייצר, כך שהיא השתלבה בסביבה שסמכה עליה.

קמפיינים אחרים משלימים את התבנית:

• OilRig (איראן) השתמשה ב-DNS ל-C2, ונוזקת ISMAgent שלה "נופלת חזרה למנגנון מנהור ה-DNS שלה אם היא לא מצליחה להגיע לשרת ה-C2 מעל HTTP." המנהור כאן משמש גם כגיבוי עמיד למקרה שערוץ ראשי נחתך.
• ProjectSauron, פלטפורמת ריגול מתקדמת, הריצה את הוצאת הנתונים ב-DNS שלה במכוון "במצב רוחב פס נמוך" כדי להישאר מתחת לזיהוי רשתי, והשתמשה בה רק למטא-נתונים קטנים ובעלי ערך גבוה ולא לגניבה בכמות גדולה.
• DNSMessenger, שתועדה על ידי Cisco Talos ב-2017, הריצה לולאת פקודות שלמה מעל רשומות DNS TXT, בלי שקובץ כלשהו נכתב אי פעם לדיסק.

זו מגמה מדודה, לא קומץ אנקדוטות. Unit 42 של Palo Alto, שסקרה שנים של תעבורה, מצאה ש"קמפיינים ידועים שמשתמשים במנהור DNS כוללים את SUNBURST, OilRig, xHunt ו-DarkHydrus," לצד אשכולות חדשים יותר שעקבו אחריהם כ-FinCounter ו-Decoy Dog. הטכניקה ממשיכה להתקיים כי התמורה, ערוץ שמסתתר בתעבורה שאף אחד לא יכול לכבות, ממשיכה להיות שווה את רוחב הפס הנמוך.

למה אי אפשר פשוט לחסום DNS

השאלה המתבקשת היא למה מגנים לא פשוט חוסמים או מסננים החוצה את התעבורה הזו. התשובה היא ש-DNS הוא תשתית נושאת עומס. כפי ש-MITRE מנסחת, הפרוטוקול "משרת פונקציה מנהלית ברשתות מחשבים ולכן עשוי להיות נפוץ מאוד בסביבות," ו"תעבורת DNS עשויה להיות מורשית גם לפני שהאימות ברשת הושלם." הוא נוסע בדרך כלל על UDP port 53, שפתוח כברירת מחדל כמעט בכל לקוח, שרת וחומת אש. מכבים אותו וכלום לא עושה resolve. בנוסף לכך, "חבילות DNS מכילות שדות וכותרות רבים שבהם אפשר להסתיר נתונים," כך שגם בדיקה צמודה שלהן אינה טריוויאלית.

יש גם קמט של שימוש לגיטימי. אותה טכניקת מנהור משמשת להשיג חיבור אינטרנט רגיל מעבר ל-captive-portal Wi-Fi, וזה חלק מהסיבה ש-DNS נשאר פתוח כל כך בהיתר מלכתחילה. זה באמת dual-use, לא מתקפה בלבד.

בעיית ה-DoH

הקרקע גם זזה. DNS נשלח יותר ויותר מעל transports מוצפנים, ו-DNS over HTTPS (DoH) הוא זה שחשוב ביותר כאן. כששאילתות נוסעות בתוך HTTPS, הגישה הקלאסית של בדיקת payloads של DNS ברשת מפסיקה לעבוד. כפי שPalo Alto מציינת, "מכשירים שמנתבים שאילתות DNS מעל HTTPS (DoH) יכולים לעקוף בקרות DNS ארגוניות." זה לא הופך מנהור DNS לבלתי ניתן לזיהוי, אבל זה כן מעביר את האותות השימושיים מהכבל אל endpoints ולוגי resolver. זה פער אמיתי, וזו הסיבה שאסטרטגיית הזיהוי משתנה.

בפועל, זה מעביר את המקום שבו צריך לצפות. כשהרשת כבר לא יכולה לקרוא את השאילתות, האותות עוברים למקומות שבהם DNS עדיין גלוי בבהירות: ב-endpoint שמבצע את ה-lookups, ובלוגים של ה-resolver שעונה עליהם. צוותים שהסתמכו רק על ניטור DNS רשתי צריכים להוסיף טלמטריה של endpoint ו-resolver כדי לשמור על אותה נראות. זו עלות תפעולית אמיתית, לא מתג.

איך מגנים באמת מזהים מנהור DNS

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

אותות Payload

תוכן השאילתות מוסר את זה. מנהור "כולל לעתים קרובות שמות דומיין ארוכים מדי, שלפעמים מגיעים למגבלה המקסימלית של 255 תווים," והשמות האלה "מציגים בדרך כלל entropy גבוה, כלומר הם מכילים רצפים שנראים אקראיים וחסרים תבניות לשוניות נפוצות." גם סוגי הרשומות הם סימן: רשומות TXT, NULL ו-CNAME "מנוצלות לעתים קרובות להוצאת נתונים, כי הן מאפשרות אחסון של טקסט שרירותי או נתונים מקודדים."

אותות Traffic

גם ההתנהגות מוסרת את זה. מנהור מסתמך על lookups רבים, כך ש"קפיצה פתאומית בתעבורת בקשות DNS יכולה להצביע על מנהור," ומכיוון שכלים עוברים במחזור על שמות שנוצרו, מגנים מחפשים "נפח שאילתות DNS גבוה ל-subdomains אקראיים מאותו second-level domain." גם lookups שנכשלו מצטברים: "תשובות NXDOMAIN מופרזות עשויות להצביע על פעילות זדונית."

כלים אמיתיים

האותות האלה מובנים במוצרי זיהוי. Elastic מספקת כלל מוכן מראש שמסמן הרצות nslookup חוזרות עם סוג שאילתה מפורש ממארח אחד כפעילות אפשרית של "command and control שמשתמשת בפרוטוקול DNS." כללים כמוהו הופכים את האותות המופשטים למעלה למשהו ש-SIEM יכול להתריע עליו.

ספרות המחקר דוחפת הלאה לסטטיסטיקה. מחקר שעבר peer-review מצא שShannon entropy, מדד לאקראיות, "מודד אי-ודאות של שם הדומיין הנתון ומספק תוצאות מהירות ומדויקות בזמן אמת," וזו הסיבה שציון entropy מופיע בזיהויים רבים כל כך בפרודקשן.

אין כדור כסף

שום דבר מזה אינו כדור כסף. שירותים לגיטימיים כמו רשתות להעברת תוכן וחלק מטלמטריית האבטחה יכולים להיראות כמו מנהור, כך שאלה אותות עם false positives שדורשים כוונון, לא אמון עיוור. וככל ש-DoH מתפשט, חלק מהם עוברים מהרשת אל ה-endpoint. זיהוי מעלה את הסיכויים שתפסו מנהרה; הוא לא מבטיח את זה. נקודת ההתחלה המעשית היא baseline של איך DNS רגיל נראה בסביבה שלכם, כדי שלחריגים הארוכים, האקראיים ובעלי הנפח הגבוה יהיה מול מה לבלוט.

הדבר האחד לזכור

מנהור DNS עובד על ידי ניצול הפרוטוקול היחיד שאי אפשר לכבות. העובדה הבודדת הזו מניעה את כל השאר: לא תחסמו את הדרך החוצה מזה, אז העבודה היא לקרוא התנהגות DNS, לעקוב אחרי התבניות הארוכות, בעלות ה-entropy הגבוה והנפח הגבוה ש-lookups רגילים לא מייצרים, ויותר ויותר לעקוב אחרי ה-endpoint כש-DNS מוצפן מעביר את הראיות מהרשת. אם אתם רוצים את הצעד הבא, שם נכנס detection engineering, כתיבת כלל ספציפי לתבניות האלה, והוא יושב ממש ליד השאלה הרחבה יותר של איך ערוצי command-and-control עובדים באופן כללי.