דוא״ל יכול לשקר… גם כשהבדיקות אומרות „OK”
מאחורי הקלעים של טכנולוגיה בת כמה עשורים, תוקפים למדו לשחק עם הכללים. לדוא״ל נוספו בדיקות זהות, והן עובדות. אבל הן עונות רק על שאלה אחת: מאיפה ההודעה הזאת הגיעה? אף פעם לא על השאלה החשובה ביותר: האם היא אומרת אמת?
השקר הראשון: „אני הבנק שלך”
הסיפור מתחיל בהודעת דוא״ל, כמו אלפי הודעות שמגיעות בכל יום:
מאת: support@mybank.example נושא: ⚠️ החשבון יושעה היום
הכול נראה רגיל: הלוגו, החתימה, הכתובת, הטון המקצועי. אבל מי באמת שלח את ההודעה?
כאן מתגלה מורשת מוזרה של האינטרנט: במקור, הדוא״ל לא תוכנן להוכיח את זהות השולח.
גלויה, לא דואר רשום
שליחת דוא״ל דומה קצת לשליחת גלויה: כותבים הודעה, כותבים שם שולח, והדוור מוסר אותה. אבל הדוור לא בודק שהשם שנכתב באמת שייך לאדם ששלח את הגלויה. (כדי ללוות את הדוור הזה צעד אחר צעד, ראו את המדריך איך הודעת דוא״ל עוברת מהשולח לנמען.)
פרוטוקולי הדוא״ל הראשונים נולדו באינטרנט זעיר, שבו כמעט כולם הכירו את כולם. האמון היה מובן מאליו. היום אותה טכנולוגיה מעבירה חלק עצום מהתקשורת שלנו. אי אפשר לכבות הכול ולבנות את הדוא״ל מחדש כמו שצריך: זה כמו להחליף מנועים של מטוס באמצע טיסה.
שלושה בודקים בכניסה: SPF, DKIM ו-DMARC
מכיוון שאי אפשר היה לבנות הכול מחדש, מהנדסים הוסיפו מעל הדוא״ל בדיקות זהות. במקום הגדרות טכניות, אפשר לדמיין אותן כשלוש דמויות שעומדות בכניסה לתיבת הדואר.
- SPF, הבלש: „האם המכונה הזאת רשאית לשלוח דוא״ל בשם הדומיין הזה?” הדומיין מפרסם את רשימת השרתים המורשים שלו, והבלש בודק אותה.
- DKIM, שומר החותם: „האם ההודעה נושאת את החתימה הדיגיטלית של הדומיין, והאם היא שלמה?” כמו חותם שעווה, היא מוכיחה שההודעה באמת יצאה מהתשתית של הדומיין ולא שונתה בדרך.
- DMARC, השומר בדלת: „מה עושים אם משהו לא מתאים?” הדומיין משאיר לו הוראה: להעביר, לשלוח לספאם או לדחות.
על הנייר זה נראה מוצק. אז איך תוקפים עדיין עוברים?
התפנית: הודעה אמיתית… שהיא בכל זאת הונאה
זה לב הבעיה. שלושת הבודקים מאמתים את הזהות הטכנית של ההודעה. אבל יש לפחות ארבע דרכים להשיג זהות טכנית תקפה לחלוטין.
מלכודת מס׳ 1: הדומיין המזויף כמעט המושלם
התוקף קונה שם דומיין משלו, שנראה זהה לזה של הבנק:
support@mybank-pr1vate.example(במקום mybank-private). הספרה „1” מחליפה את האות „i”. התוקף מגדיר נכון את SPF, DKIM ו-DMARC: זה הדומיין שלו, והוא רשאי. לכן הבודקים עונים בכנות מלאה: ✅ „הדומיין הזה אכן מורשה לשלוח את ההודעה”. ובאותו זמן, המוח של הקורא קורא: 😱 „זה הבנק שלי!”
הכלים בודקים מי שולח. הם לא מבינים את הכוונה של ההודעה.
מלכודת מס׳ 2: הדלת שנשכחה
לבנק גדול יש מאות תת-דומיינים: אחד למבצעים, אחד לתחרות ישנה, אחד לשירות שנסגר לפני חמש שנים… איפשהו עדיין קיים promo.old-bank.example, ואף אחד כבר לא באמת מטפל בו.
אם תת-הדומיין הזה עדיין מצביע על שירות שכבר לא קיים, או שהוא מוגן בצורה חלשה, תוקף יכול לפעמים להשתלט עליו. אין צורך לפרוץ את הדלת הראשית: מספיק לחפש דלת צדדית שכולם שכחו. וכל מה שיפורסם שם יישא את השם האמיתי של הבנק.
מלכודת מס׳ 3: לגנוב את המפתחות האמיתיים
ומה אם התוקף בכלל לא ייצור כתובת מזויפת? אם יגנוב את הסיסמה של עובד אמיתי, למשל באמצעות פישינג קודם, ההודעות שלו ייצאו מהתשתית האמיתית של החברה. SPF, DKIM ו-DMARC פועלים כרגיל, ובצדק: הכול אמיתי. הפעם זו כבר לא זהות מזויפת. זו זהות אמיתית שמשתמש בה האדם הלא נכון.
מלכודת מס׳ 4: להיטמע בכלים שכולם משתמשים בהם
חברות שולחות ניוזלטרים וקמפיינים דרך פלטפורמות ייעודיות, מוכרות ובעלות מוניטין טוב אצל המסננים. תוקפים עלולים לנסות לנצל את הפלטפורמות האלה כשהן מוגדרות בצורה רשלנית או כשחשבון לקוח בהן נפרץ. כך שהתוקף לא תמיד בונה מערכת משלו: לפעמים הוא מתגנב למערכת של מישהו אחר, ושם הוא לא בולט. המדריך פישינג: איך נוכלים מצליחים להעביר את ההודעות שלהם מפרט את שיטות השליחה האלה.
SPF, DKIM ו-DMARC עוזרים לאמת את הזהות הטכנית של הודעה. לבדם, הם לא יכולים לקבוע אם התוכן שלה נכון. זה כמו לוודא שהמעטפה אמיתית בלי יכולת להבטיח שהמכתב שבתוכה לא משקר.
לפעמים הבעיה מתחילה עוד לפני שהתוקף מגיע
נחזור לשטח. שרת דוא״ל אינו מאובטח רק משום שהוא עובד.
מלכודת ההעתק-הדבק
מנהל מערכת מחפש „התקנת שרת Postfix במהירות”. הוא מוצא מדריך, מעתיק את הפקודות, ו… זה עובד. סוף הסיפור? לא בהכרח. הגדרה שמאפשרת להתחיל מהר אינה בהכרח הגדרה מוקשחת, כלומר מכוונת לעמוד בפני התקפות.
השרת שהופך למכונת ספאם
הגדרה גרועה יכולה להפוך שרת לממסר פתוח (open relay): מכונה שמסכימה להעביר הודעות של כל אחד, כשהיא אמורה לשרת רק את המשתמשים שלה. בשביל תוקף זו מציאה: שרת הגון, בעל מוניטין טוב, ששולח את ההודעות שלו בשבילו.
ואין צורך לחפש ידנית. המחזור פשוט: לסרוק → לבדוק → למצוא → לנצל, והוא ניתן לאוטומציה בקלות רבה. כך שזה כבר לא בהכרח תוקף שיושב מול המסך ומחפש קורבנות. לעיתים קרובות אלה מכונות שמחפשות מכונות אחרות, יומם ולילה.
בזמן שאנחנו חושבים, המכונה כבר תוקפת
הודעה זדונית יכולה להישלח → להתקבל → להיפתח → לקבל לחיצה → להיות מנוצלת, והכול בתוך דקות ספורות. בינתיים, בצד ההגנה, המערכות צריכות לנתח את ההודעה, הצוותים צריכים לקבל התראות, מישהו צריך לפרש אותן, ואז צריך לעדכן את כללי הסינון. כל דקה חשובה.
מכאן רעיון פשוט: מערכת אבטחה שאף אחד לא מנטר מפסיקה בסופו של דבר להיות מאובטחת באמת. הכללים מתיישנים, התוקפים מסתגלים, וההתראות נערמות בלי שמישהו קורא אותן.
כדי לחסוך את הדקות האלה נבנה גם Baitback: מדביקים את ההודעה החשודה, הכלי מאתר את השרת ששלח אותה בפועל ואת ספק האחסון שלו, ומכין את הדיווח. ככל שמדווחים מוקדם יותר על שרת השליחה, כך אפשר להשבית אותו מהר יותר.
האם אפשר להפוך את הדוא״ל לחסין לחלוטין?
כנראה שלא בעזרת טכנולוגיה אחת, כי לבעיה יש כמה שכבות:
- 📨 הפרוטוקול: תוכנן בעידן אחר, לאינטרנט אחר.
- 🔐 התשתית: לפעמים מוגדרת לא נכון, לפעמים מיושנת, לפעמים נשכחת.
- 🤖 מערכות הזיהוי: מסוגלות לאתר המון דברים, אבל לא הכול.
- 🧑 האדם: מסוגל לחוש מלכודת… וגם להיות מתומרן.
אם הטכנולוגיה לבדה לא מספיקה, מה עושים החוקרים כדי להפוך את הזיהוי לחכם יותר? זה הנושא של המדריך הבא: פישינג: משחק החתול והעכבר בין חוקרים לתוקפים.
- הדוא״ל לא תוכנן להוכיח מי שולח: SPF, DKIM ו-DMARC נוספו מאוחר יותר.
- הבדיקות האלה מאמתות את הזהות הטכנית של הודעה (המעטפה), לא את כנות התוכן שלה (המכתב).
- דומיין דומה, תת-דומיין שנשכח, חשבון גנוב או פלטפורמת שליחה שנוצלה יכולים כולם לייצר הודעה „תקפה”.
- שרת שמוגדר לא נכון עלול להפוך לממסר לשולחי ספאם, ובוטים ימצאו אותו אוטומטית.
- המהירות חשובה: דיווח מוקדם על שרת השליחה, למשל בעזרת Baitback, מקצר את חייו של קמפיין.