מנגנוני זיהוי והגנה על תעבורת הדואר

(מאמר שני בסדרה)

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

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

למאמר המלא סיכונים, סימולציה והגנה על תעבורת הדואר

מנגנוני זיהוי ותעבורת הדואר

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

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

מנגנוני הזיהוי הקיימים כיום מכילים בעיקר שלושה מנגוני זיהוי המתבססים על זיהוי השולח.

מנגנון זיהוי SPF

מנגנון לזיהוי תעבורת דואר ממקור לא אמין, מטרתו העיקרית של מנגנון SPF הוא לוודא את זהות השולח ע”י מאפיינים שונים בין היתר:

• כתובת מול רשומת SPF (מבוסס TXT)
• דומיין אשר שולח את הדואר
• פרטי נמען עם ערכים, כגון: Mail From

בשירותי הדואר השונים ניתן להגדיר רשומת TXT לטובת SPF וצריך לשים לב לתרחישים בהם ישנם מצב היברידי או גורם חיצוני שמבצע סינון למיילים (third party emsil ecurity).
כמו שירותי ענן אחרים כך גם בשירות Exchange Online ישנם מספר תקנים כגון HIPPA שמחייב הגדרת SPF מול הדומיין, בכל המקרים האלה ישנה אינפורמציה רבה לגבי הגדרת SPF מול הארגון.

DKIM

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

מטרתו העיקרית של DKIM הוא לזהות מהיכן הגיעה תעבורת הדואר ע”י מספר פרמטרים:

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

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

DMARC

בשמו המלא נקרא Domain-based Message Authentication, Reporting and Conformance והוא מנגנון נוסף לזיהוי תעבורת דואר עם התמקדות בפישינג.
DMARC בודק הודעה שעברה בהצלחה מול SPF או DKIM ןלאחר מכן מבצע בדיקה מול שדות: Mail from וכן From,  במידה וישנו במייל בעיה שאינו תואם להגדרות DMARC המייל יוגדר כדואר זבל או פישינג ואינו יעבור אל שרתי הדואר, במידה והמייל יהיה תקין בהתאם להגדרות DMARC המייל ימשיך הלאה לשירות הדואר.
מעבר לבדיקה שמנגנון DMARC מבצע בשירות הדואר, מתבצעת בנוסף לכך דיווח לגבי מיילים ותעבורת דואר לא תקינה ובכדי לעבוד עם DMARC צריך להוסיף רשומת TXT בלבד ללא צורך בהגדרות נוספות ברמת שירות Office 365.

איפה הבעיה עם המנגונים הנ”ל?

אנו מכירים את מנגנוני הזיהוי שמענה לבעיות רבות ובעיקר מול Deception ופישינג, אך לא כך הדבר ואף גרוע מכך.
מנגוני הזיהוי של SPF וכן של DKIM הם מנגונים בני 10 שנים ויותר (בעיקר SPF), ומכייון שמנגנון הזיהוי של DMARC מתבסס על שניהם ובעיקר כל SPF, אין לנו אפשרות לבנות על מנגנוני היזהוי האלה כגורם להגנה על תעבורת הדואר ועל אחת כמה וכמה מול מתקפות דואר מתקדמות, מנגוני הזיהוי הנ”ל מכילים חסרונות ובעיות יותר מאשר יתרונות.

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

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

בעיה נוספת היא שמנגנון SPF אינו נותן מענה לפריטי דואר שנעשה להם forward, כלומר פעולה פשוטה של העברת דואר בין שני אובייקטים דואר שונים בין אם ידני או אוטומטי מספיקה בכדי לעשות bypass על מנגנון SPF.

בעיה נוספת היא במנגנון DKIM היא שמנגנון DKIM אינו בודק את החתימה או חלק ממנה בתוך envelope, ולכן השולח יכול לעדכן שהוא חתום בגלל מבנה המייל.

למשל אם נקח את הדוגמא הבאה:

• יש לנו שני שדות של from (המשתמ רואה רק אחת מהן, הראשונה)
• במקרים של שליחה אל DKIM ישנו שדה נוסף של h=From
• בשורה התחתונה הנמען Eli Gmail רואה רק את השדה from הראשון ולכן מנגנון זיהוי של DKIM רואה את ההועדה כהודעה בטוחה (DKIM-verified) ומעביר אותה למרות הכל.

Date: Thu, 8 Aug 2018 22:00:00 -0700
From: Barack Obama <barack@whitehouse.gov>
From: Eli Shlomo <eshlomo@eurekaps.com>
Reply-To: Eli Shlomo <eshlomo@eurekaps.com>
Subject: “DKIM is Good…?”
To: “Eli Gmail” <eligmail@gmail.com>

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

בנוסף לכך DMARC אינו בנוי לענן, בגלל שמכיל מגבלה של עד 10 דומיינים בבדיקה (domain lookups), כלומר כאשר מנגנון הזיהוי של SPF מוגדר יחד עם DKIM ועליו מתבסס DMARC מקבל מייל מתוך 10 דומיינים ומבצע את אותה בדיקה הוא יבצע חסימה לאותם מיילים בטענה שהם עלולים להיות מתקפה כלשהיא (למשל denial of service).

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

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

מידע על הסיכונים בתעבורת הדואר לשנת 2018

שנת 2018 היתה שנת הפריחה של מתקפות הדואר ובעית הפישינג והמידע הבא ממחיש את מה שעברנו השנה:

• מערכות מבוססות Windows 10 הם המערכות העיקריות שמותקפות בדואר
• אנדרואיד היא המערכת השניה הכי מטורגתת
• בכל יום מתווספים 230,000 malware samples חדשים
• כמות מתקפות הכופר היא 37% יותר מאשר שנת 2017
• 43% אחוז מכלל תקיפות הדואר הם מול ארגוני SMB
• זיהוי מתקפות דואר עם תוכן זדוני אורך עד 197 יום לזיהוי המתקפה
• רוב התוקפים מנסים לטשטש עקבות באמצעות תווך מוצפן

מענה והגנה על שירות הדואר

תשתיות הגנה מבוססות email gateway כמו שאנו מכירים אותם כבר 10 שנים ויותר אינן רלוונטיות! הסיבה לכך היא פשוטה, ניתן לבצע Bypass למערכות אלה ללא כל מאמץ ובאופן מאוד פשוט, מתקפות כגון Zero Font אינן ניתנות לזיהוי.

מה כן אפשר לעשות? ניתן לשלב עם מערכות מבוססות API, אנו נמצאים בנקודה שאנו מבינים כי דואר זדוני יעבור כל email gateway ולכן מערכת מבוססת API יודעת לתת יתרונות שונים, כגון:

• זיהוי מתקפות על גבי מאגר מידע של מתקפות דואר
• מענה ודיווח למתקפות ברמת משתמש ואטומציה מול כלל המשתמשים
• זיהוי מתקפות מבוססות Deception עם קבצים וקישורים (גם כאלה שפותחו לפני חצי שעה)
• זיהוי מתקפות על גבי מנגנון AI

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

אחת הדרכים מתוך רבות לבצע פישינג מוצלח מול דומיינים מבוססי DKIM הוא באמצעות הכלי  SocialFish