DNS Tunneling

טכניקת ה-DNS tunneling מסתירה נתונים שאינם DNS, כמו קבצים גנובים או תעבורת שליטה ובקרה (Command and Control, C2), בתוך שאילתות ותגובות DNS רגילות. שתל מקודד את הנתונים בתוך תת-הדומיינים שהוא מחפש, ושרת השמות (name server) שבשליטת התוקף מפענח אותם ועונה בחזרה. מכיוון שרשתות חוסמות DNS לעיתים רחוקות, הערוץ הזה עוקף מסננים שהיו עוצרים כמעט כל דבר אחר.

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

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

תסבירו לי כמו לילד בן 10

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

איך טכניקת ה-DNS tunneling עובדת בפועל

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

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

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

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

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

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

שני תפקידים: שליטה ובקרה והוצאת נתונים

מנגנון ה-DNS tunneling משרת שתי מטרות שונות. כדאי להבחין ביניהן.

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

גרסת הוצאת הנתונים

כהוצאת נתונים (exfiltration), טכניקת ה-DNS tunneling היא דרך לגנוב נתונים מהרשת דרך פרוטוקול שאינו ערוץ ה-C2 הראשי. MITRE קוראת לזה הוצאה דרך פרוטוקול חלופי. יש כאן מכשול שמעצב איך תוקפים משתמשים בטכניקה: DNS הוא ערוץ עם רוחב פס נמוך. העברת נתונים דרך שאילתות היא איטית ורועשת. לכן הוצאת נתונים דרך DNS נוטה לכלול פריטים קטנים ובעלי ערך רב, כמו פרטי הזדהות או metadata של המערכת, ולא קבצים גדולים. מפעילים זהירים מאטים אותה בכוונה כדי להישאר בשקט. MITRE מקטלגת את זה תחת הוצאה דרך פרוטוקול חלופי, בגרסאות שנעות מקידוד לא מוצפן ועד ערוצים מוצפנים לחלוטין. אבל צורת ה-DNS tunneling נשארת זהה בכל פעם.

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

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

הכלים

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

המתקפות

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

קמפיינים נוספים משלימים את הדפוס:

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

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

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

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

יש גם סיבוך נוסף שקשור לשימוש לגיטימי. אותה טכניקת DNS tunneling משמשת גם כדי לעקוף את ה-captive portal (רשת Wi-Fi ציבורית שמצריכה הרשמה בדף נחיתה לפני גישה לאינטרנט) ולקבל גישה רגילה לאינטרנט. זו אחת הסיבות לכך ש-DNS נשאר פתוח באופן כה מתירני מלכתחילה. הטכניקה באמת דו-שימושית ולא רק מתקפה.

בעיית ה-DoH

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

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

איך מגינים מזהים בפועל את טכניקת ה-DNS tunneling

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

אותות המטען

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

אותות התעבורה

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

כלים אמיתיים

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

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

אין כדור כסף

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

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

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