מה זה Subdomain Takeover ואיך שוכחים DNS הופך לחור אבטחה שלם¶
תארו לעצמכם שדף שיווקי זמני שבניתם לפני שנתיים ב-promo.company.com הוצמד לשירות אחסון בענן, הקמפיין נגמר, מישהו מחק את הפרויקט בענן, אבל אף אחד לא זכר למחוק את רשומת ה-DNS שמצביעה לשם. עכשיו יש לכם תת-דומיין שנראה כמו הדומיין שלכם לחלוטין, אבל שכל מי שיודע לחפש יכול פשוט "לתפוס" ולהשתלט עליו. זה בדיוק Subdomain Takeover, ובגלל שהוא נובע מטעות תפעולית ולא מבאג בקוד, הוא נשכח הרבה יותר קל ממה שאתם חושבים.
אז מה זה בעצם קורה שם¶
ארגונים מודרניים מריצים המון תת-דומיינים, ורבים מהם מוצבעים החוצה לשירותי צד שלישי - אחסון קבצים בענן, פלטפורמות בניית דפי נחיתה, שירותי אירוח, כלי תמיכה, ועוד. הדרך הטכנית לחבר תת-דומיין לשירות כזה היא בדרך כלל רשומת DNS מסוג CNAME, שאומרת בפועל "כל מי שמחפש את הכתובת הזאת, תפנו אותו לכתובת הזאת אצל הספק החיצוני".
הבעיה מתחילה כשהפרויקט אצל הספק החיצוני נמחק, פג תוקפו, או פשוט הוסר - אבל רשומת ה-CNAME באתר שלכם נשארת כמו שהיא. עכשיו יש לכם רשומת DNS "תלויה" - dangling DNS record - שמצביעה על משהו שכבר לא שייך לאף אחד. ובהרבה שירותי ענן פופולריים, כל מי שנרשם ומצהיר על אותו שם בדיוק שהיה שם קודם, פשוט מקבל את הבעלות עליו מחדש.
איך תוקף בפועל "תופס" את התת-דומיין¶
התהליך פשוט מדאיג ברוב המקרים:
התוקף מוצא תת-דומיין שמצביע על שירות חיצוני שכבר לא פעיל, בדרך כלל דרך בדיקת רשומות ה-DNS של הדומיין וניסיון לגשת לכל תת-דומיין שנמצא. אחר כך הוא בודק אם השירות שהצביע אליו עדיין "פנוי" להרשמה - אצל חלק גדול מספקי הענן, כל אחד יכול להירשם ולתבוע כל שם פרויקט שעדיין לא תפוס, בדיוק כמו שם משתמש פנוי. ברגע שהתוקף נרשם עם אותו שם בדיוק שהיה מוגדר ברשומת ה-CNAME, כל מי שנכנס לתת-דומיין המקורי מגיע עכשיו לתוכן שהתוקף שולט בו לגמרי, כי רשומת ה-DNS מעולם לא הפסיקה להצביע לשם.
מבחוץ, שום דבר לא נראה חשוד - הכתובת עדיין promo.company.com, אבל התוכן מאחוריה שייך עכשיו למישהו אחר לגמרי.
למה זה מסוכן יותר ממה שזה נשמע¶
ההשלכות של Subdomain Takeover הרבה מעבר ל"דף מביך שמישהו השתלט עליו". כמה סיבות שהופכות את זה לחמור באמת:
- דיוג תחת דומיין אמין - Phishing. תוקף יכול לבנות דף התחברות מזויף מתחת לדומיין האמיתי של החברה. משתמשים, ואפילו מערכות אבטחה שבודקות דומיינים, נוטים לסמוך על תת-דומיין שנמצא תחת הכתובת המוכרת.
- גניבת עוגיות והפעלות - Cookies ו-Sessions. אם עוגיות האתר מוגדרות עם scope רחב שחל על כל תתי הדומיינים, תוקף ששולט בתת-דומיין יכול לפעמים לקרוא או לקבוע עוגיות שתקפות גם באתר הראשי עצמו.
- עקיפת רשימות אמון של CSP ו-CORS. מדיניות אבטחה רבות מוגדרות לסמוך על כל תת-דומיין תחת הדומיין הארגוני. תת-דומיין שנתפס שובר את ההנחה הזאת, ופותח דרך לעקוף מדיניות שהוגדרה במיוחד כדי למנוע את הסוג הזה של תקיפה.
- פגיעה במוניטין ובאמון. גם בלי לגנוב שום דבר טכני, תוקף יכול פשוט להציב תוכן פוגעני תחת דומיין של חברה מוכרת, וזה לבד כבר נזק משמעותי.
איך מוצאים תת-דומיינים תלויים - כתחום מחקר¶
מציאת Subdomain Takeover היא אחד התחומים הפופולריים ביותר בתוכניות באג באונטי, בדיוק כי היא ניתנת לאיתור בצורה שיטתית וחוקית:
- מיפוי כל תתי הדומיין של הארגון. דרך רשומות DNS ציבוריות, תעודות SSL, וכלי איסוף מידע שסורקים מאגרי מידע פומביים על דומיינים קיימים.
- בדיקת כל רשומת CNAME מול הסטטוס בפועל אצל הספק. האם היעד עדיין קיים, האם הוא עדיין תחת בעלות הארגון, או שהוא כבר "פנוי" מחדש.
- אימות זהיר בלי לפגוע באף אחד. חוקר אחראי לא "תופס" את התת-דומיין בפועל בלי אישור, אלא מדווח על הרשומה התלויה כדי שהארגון יוכל לתקן אותה - למחוק את הרשומה או לחדש את הבעלות על השירות.
זה בדיוק סוג המחקר שמשלב יכולת טכנית עם סבלנות - צריך לעבור על עשרות ולפעמים מאות תתי דומיין כדי למצוא את אותם אחד או שניים ששכחו מהם.
איך מונעים את זה כארגון¶
ההגנה כאן היא בעיקר תהליכית ולא טכנית - כל פעם ששירות חיצוני מוסר או פרויקט נסגר, צריך תהליך מסודר שמוודא שרשומת ה-DNS המתאימה נמחקת באותו רגע. סריקה תקופתית של כל תתי הדומיין הארגוניים מול הסטטוס בפועל שלהם היא הדרך הכי בטוחה לתפוס את הבעיה לפני שמישהו אחר תופס אותה.
זה בדיוק סוג החולשה שממחיש למה מחקר אבטחה זה הרבה יותר מלחפש חתימות מוכרות בקוד - זה גם להבין איך תשתית שלמה מתנהלת סביב האתר עצמו. אנחנו נוגעים בזה, יחד עם עוד נושאי תשתית ו-DNS, בקורס פריצת אתרים מתקדם.
אם אתם רוצים לתרגל מיפוי תתי דומיין ולראות איך זה נראה בפועל, יש קהילה שלמה בדיסקורד שעוסקת בדיוק בזה.
לסיכום¶
Subdomain Takeover הוא תזכורת לכך שאבטחה לא נגמרת בקוד עצמו. לפעמים החולשה הכי מסוכנת היא לא שורה של קוד שגוי, אלא רשומת DNS ישנה שאף אחד לא טרח למחוק. ברגע שיודעים לחפש את זה, זו אחת הדרכים הכי מהירות למצוא בעיה אמיתית, בדיוק כי רוב הארגונים פשוט לא חושבים על זה בכלל.