כך תמנעו את חטיפת הדומיינים שלכם

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

מקור: Pixabay

מאת איתי ינובסקי

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

“חטיפת דומיין” (Subdomain Hijacking), הינה פגיעות שכיחה מאוד עמה נאלצים להתמודד ארגונים. ממחקר רחב שנעשה באחרונה, נמצא ש-12% מתוך 500 החברות המרוויחות בעולם (Fortune 500) פגיעות, בצורה כזו או אחרת למתקפה זו, אשר מאפשרת לתוקף “להשתלט” על דומיין או סאב דומיין של הארגון. סכנה זו רלוונטית לא רק לחברות בסדרי גודל של Furtune500, אלא גם לארגונים קטנים יותר. על פי הנתונים – מספר הארגונים הפגיעים הולך ועולה מיום ליום ככל שהשימוש בשירותי הענן גדל. סוג תקיפה זה מאפשר לתוקף לנצל את קיומן של רשומות DNS אשר מופנות לכתובות של שירותי ענן שאינן בשימוש ומאפשרות לתוקף פוטנציאלי לנצל משאב זה תחת הדומיין של הארגון הנתקף.

הנה דוגמה. אליס עובדת בארגון שהחליט לעשות שימוש בשירות ענן אשר מספק מערכת ניהול ותמיכה ללקוחות הארגון. אליס פתחה חשבון באותו שירות ולבסוף על מנת לחבר את הדומיין של הארגון למערכת התמיכה היא התבקשה ליצור רשומת CNAME שתפנה מהסאב-דומיין של הארגון אל כתובת של חברת שירות הענן. אליס יצרה את הכתובת הבאה: support.alice-corp.com —> CNAME —> customers.cloud-support-service.com. ברגע שרשומת ה-CNAME התעדכנה בשרתי ה-DNS בעולם, כל מי שגלש לכתובת הסאב דומיין של הארגון בו אליס עובדת הגיע למערכת התמיכה בשרתי הענן. במקרה זה הקשר הלוגי בין החשבון של אליס לסאב דומיין קיים כל עוד אליס משתמשת בשירות. כעבור שנה החליטה אליס להפסיק את השימוש בשירות וביטלה את החשבון שלה, ברגע זה ניתקה אליס את הקשר הלוגי בין החשבון המבוטל לסאב דומיין של הארגון. האקר “נחמד” בשם בוב שם לב כי לארגון של אליס יש סאב דומיין “נטוש” ומחליט לרשום את עצמו כבעלים החדשים של סאב-דומיין זה. בוב ההאקר מקצה את הסאב דומיין של הארגון של אליס למערכת התמיכה שלו. ההקצאה מתאפשרת, כאמור, מכיוון שהסאב דומיין פנוי וקיימת רשומת CNAME שאליס שכחה להסיר אשר מפנה לכתובת של חברת שירות הענן. מרגע זה בוב הינו ה”בעלים” של הסאב דומיין של הארגון של אליס ולכן הוא שולט בתוכן שיופיע בסאב-דומיין זה.

אז מה התוקף יכול לעשות עם זה?

Session hijacking ו-גניבת Cookies: השימוש היום בעוגיות קיים כמעט בכל אפליקציית web, ישנם מקרים בהם מפתח האפליקציה או האתר שומר את העוגיות בדפדפן של הגולש תחת wildcard דומיין על מנת לחלוק את התוכן או במקרים רבים session עם sub domains. הגדרה של עוגיה שתישמר תחת הדומיין .mydomain.com מבקשת מהדפדפן לשלוח את העוגיה לכל סאב דומיין תחת  mydomain.com. במידה והעוגיה הוגדרה כ-HTTP ONLY צפייה בתוכן שלה תתאפשר רק באמצעות קוד בצד השרת. במידה והעוגיה הוגדרה כ SECURED היא תשלח אך ורק בגלישה לדפים ב HTTPS.

צריכים לזכור כי לאחר השתלטות על סאב דומיין ניתנת לתוקף האפשרות לצפות בתוכן העוגיות המשותפות עימו, במידה והתוקף שולט בתוכן ברמה של הרצת קוד בצד שרת (HOSTING APPS) התוקף ייחשף לעוגיות המוגדרות לקריאה בצד שרת. במידה והתוקף יצליח להנפיק תעודת SSL ולהגדירה תחת הסאב דומיין , תתאפשר הקריאה של עוגיות המוגדרות SECURED.

פישינג (דיוג): ברגע שהתוקף יכול לייצר תוכן תחת הדומיין של הנתקף בין אם זה תוכן טקסטואלי או HTML. מתקפת הפישינג הופכת להרבה יותר מתוחכמת וקשה לזיהוי על ידי הנתקף ומערכות ההגנה בארגון. שילוב של הנפקת תעודת SSL עבור הדומיין יכול לגרום להתקפה להיות בלתי ניתן לזיהוי.

התקנת תוכנות זדוניות: התוקף יכול ליצור אתר אשר נראה לגיטימי ומבקש מהמשתמש להתקין תוכנות זדוניות.

הנפקת תעודות SSL: רוב החברות אשר מנפיקות תעודות SSL עושות אשרור להוכחת בעלות על דומיין או סאב דומיין על ידי יצירת קובץ בתיקייה מסוימת עם תוכן ייחודי. מאחר ולתוקף יש גישה לתוכן האתר הוא יכול לבצע את האשרור בצורה פשוטה ומהירה ולהנפיק את התעודה עבור הדומיין / סאב דומיין. מאחר ולתוקף יש את התעודה הלגיטימית הוא יכול להגיש את התוכן בצורה מוצפנת, לצפות בעוגיות אשר הוגדרו כ- SECURED ולחתום קבצי הרצה על מנת לעקוף הגנות של אנטי וירוסים.

גניבת טראפיק: בהרבה מאוד מהמקרים הדומיינים אשר “נחטפו” עדיין פופולאריים בתוצאות האורגניות של מנועי חיפוש כמו גוגל ובינג. תוקף יכול לנצל את התעבורה לאתר על מנת להציג פרסומות או להעביר את הגולשים לאתרים ממומנים ובכך להרוויח כסף מחברות פרסום.

איך ניתן להתגונן מפני התקפה זו?

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

הכותב הוא מייסד משותף וסמנכ”ל אסטרטגיה בחברת CyberInt

 

 

כתב אורח

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

הגב

19 תגובות על "כך תמנעו את חטיפת הדומיינים שלכם"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
תהילים נ טילים
Guest
תהילים נ טילים

מה הקשר בין שם דומיין למיחשוב ענן? ואם הסאב-דומיין מפנה לשרת שהוא לא “שירותי ענן” – אז אני לא חשוף לחטיפת הדומיין?

A2A2el
Guest

בכדי לאפשר ששרות הענן (תמיכה,ניהול לקוחות,מרקטינג וכו) יופיע תחת הדומיין של הארגון ישנו צורך להפנות רשומות DNS כלשהי (CNAME .A).
הכותב התייחס לשרותי ענן SAAS ולא “מיחשוב ענן” (לא יודע איפה ראית את האזכור הזה?).

כלי לבדיקה האם הדומיין שלכם פגיע:
https://takeover.cyberint.com

Idan
Guest

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

nuyh
Guest

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

mishu
Guest

לא הצלחתי להבין איך החטיפה מתבצעת ברמה הטכנית.
מאיפה לאיפה ההאקר עושה את ההפניה ב DNS העולמי?

nuyh
Guest

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

mishu
Guest

אבל אתה לא יכול להפנות סאבדומיין שלא שייך לך לאתר שאתה רוצה….
כדי לבצע את ההפניה אתה צריך להוכיח בעלות על הדומיין ע”י העלאת רשומת טקסט עם עדיפות נמוכה (ככה שבפועל היא לא משפיעה על כלום) ושברשומה הזאת יהיה טקסט מיוחד שהספק של הדומיין נותן לך. אחרי שהשינוי מתרפלק המערכת של הספק בודקת שהטקסט הזה קיים ברשומה של הדומיין שלך וככה היא יודעת שזה שייך לך….

עדיין לא הבנתי איך ההאקר יכול לשייך לעצמו את הסאבדומיין שלי?

פשוט
Guest
אני אנסה להסביר את התהליך בצורה פשוטה יותר: רוב שירותי הענן שמאפשרים לך להפנות סאבי דומיין אליהם, לא דורשים משהו מיוחד ומורכב שתעשה אלא רק הפניה פשוטה של הסאב דומיין שלך אל הכתובת אותה קיבלת באותו שירות. (הפניה של CNAME או A record). בוא נגיד שיש לך דומיין: example.com וסאב דומיין: my-subdomain.example.com באחד הימים חיברת את הסאב דומיין שלך אל שירות ענן מסויים לדוגמא: abc.cloudservice.test (החיבור בוצע על ידך בכך שהוספת לסאב דומיין שלך רשומת CNAME ב-DNS). עד לכאן הכל תקין…. הזמן עבר והחלטת להוריד את השירות בענן (שכבר אין לך צורך בו), אבל שכחת להוריד את הרשומת ה DNS… Read more »
mishu
Guest
מה שאני לא מבין זה, ביטלת את שירות הענן בכתובת abc.cloudservice.test ועדיין השארת את ההפנייה (בעולם). ואז בא ההאקר ורוצה לקנות את abc.cloudservice.test ולהפנות אותו אל הדומיין שלו sub.hacker.com. למה שירות הענן מבקש מההאקר הוכחת בעלות על הדומיין שלי במקום על הדומיין שלו? הרי אם אני ביטלתי את השירות שלי (שבזמן שהיה פעיל היה בכתובת abc.cloudservice.test), הם אמורים “לאפס” את הכתובת הזאת ככה שאם מישהו חדש יקנה אותה הם צריכים לבקש הוכחת בעלות מול הסאבדומיין של אותו לקוח חדש לא? הרי אם אני עכשיו עושה הפנייה מסאב דומיין שלי sub.mishu.com לכתובת של google.com. ואז בא האקר נחמד עם הסאבדומיין שלו… Read more »
פשוט
Guest
יש משהו שאתה מפספס, המאמר הנ”ל מציג דרך שתוקף יכול “לחטוף” לך את הסאב דומיין שלך (sub.mishu.com) (אין קשר לסאב דומיין של התוקף: sub.hacker.com) איך תוקף יכול “לחטוף” לך את האסב דומיין ? הוא הרי לא שולט על הדומיין הראשי שלך … (ואין לו אפשרות לשנות את ההפניה בDNS שאתה הוספת) מה הוא כן יכול ?: הסאב דומיין שלך sub.mishu.com מפנה את כל הבקשות אל השירות abc.cloud-service.com ואז יוצג לו התוכן של אותו שירות. (תוכן שאתה בוחר) אם תבטל את השירות בענן שאותו רכשת, ולא תוריד את ההפניה, מה יקרה ? כל מי שיפנה אל הסאב דומיין שלך sub.mishu.com יקבל… Read more »
mishu
Guest
תודה רבה מר פשוט על ההסבר הסבלני. עכשיו הבנתי איך זה מתבצע. תקן אותי אם אני טועה אבל אם אני רוכש שירות ענן abc.cloud-service.com בפועל הABC הזה הוא לא באמת משהו כזה גנרי. כלומר זה לא אותו ABC לכל הלקוחות של השירות הזה. בפועל זה יותר משהו בסגנון של hakv734bv93bvc.cloud-service.com שהג’יבריש הזה זה בעצם איזשהו מספר לקוח מוצפן או משהו בסגנון. זה אומר שאם אני מפסיק את השירות חברת השירות הענני חייבת להרוג את הכתובת הזאת שהיתה שייכת לי! ואז כשיבוא בוב ההאקר הנחמד וינסה לקנות את אותו hakv734bv93bvc.cloud-service.com הוא לא יצליח כי הכתובת הספציפית הזאת שייכת ללקוח על שמי… Read more »
פשוט
Guest

שמח שהבנת :)

לגביי מה שרשמת, רוב שירותי הענן הגדולים מאפשרים ללקוחות שלהם לבחור את השם של הסאב דומיין בשירות עצמו (לפי הדוגמא – ABC)
כלומר, התוקף יכול לרכוש את אותו סאב דומיין שלפני זה היה שלך:
abc.cloud-service.com

וכן, כמו שמרשמת shopify מאפשר את זה, וישנם עוד הרבה שירותי ענן שמאפשרים את זה.

Yaron
Guest

לא מובן לי למה התכוון המשורר.
אליס עדיין הבעלים של alice-corp.com? אם כן, אז איך הצליח בוב לקבל את הסאב דומיין? ומה היה הקשר לכך שהכתובת support.alice-corp.com מופנת לכתובת אחרת?

חנן
Guest

כי הוא יכול להרשם לאותו שירות שאירח את הכתובת support.alice-corp.com בחשבון משלו ולדלג על השלב של הוספת cname כי אליס כבר הוסיפה אותו.
מאותו רגע הוא שולט בsubdomain.
כששולטים בסאב דומיין ניתן גם לקרוא cookies של הדומיין הראשי אם הן הוגדרו בצורה פתוחה מדי.
אפשר לעשות עוד המון דברים, הכתבה מסבירה חלק מהן.
כתבה טובה, אנשים צריכים להיות מודעים לסכנות האלו ובדרך כלל לא לוקחים אותן בחשבון.

Yaron
Guest

תודה על ההסבר, אבל מה שלא מובן לי הוא המשפט הבא:
“ההקצאה מתאפשרת, כאמור, מכיוון שהסאב דומיין פנוי וקיימת רשומת CNAME שאליס שכחה להסיר אשר מפנה לכתובת של חברת שירות הענן”.

קיימת הפנייה מ-support.alice-corp.com ל-customers.cloud-support-service.com.

כיצד זה גורם לכך שבוב יכול לבקש בעלות על הסאב דומיין ולשנות אותו למה שהוא רוצה?
אם בוב קונה את customers.cloud-support-service.com זה משהו אחר, אבל לא מה שכתוב בכתבה.

A2A2el
Guest

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

Yaron
Guest

תודה רבה זה מה ששיערתי אבל לא היה לי מובן. לא ראיתי / פספסתי שאליס התבקשה להוסיף את ה-CNAME היתה בשביל הוכחת בעלות.

שדגשד
Guest

שאלו יהיו הצרות שלנו…

שם טוב
Guest

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

wpDiscuz

תגיות לכתבה: