הגליון המאה שישים ושבעה של DigitalWhisper שוחרר!
ברוכים הבאים לדברי הפתיחה של הגליון ה-167 של DigitalWhisper!
לפני קצת יותר מ-18 שנים התגייסתי לצה"ל, שירתתי כלוחם בחטיבת כפיר, שזה עתה הוקמה. חטיבת חי"ר שאמונה על הלחימה באיו"ש. אני זוכר שבאחד משבועות השטח הראשונים בזמן שהייתי מפקד כיתה, אחד החיילים לא הקפיד על סימון אחת היתדות לאחר שהקים את האוהל שלו, ובערב, חייל אחר שעבר סמוך לשם - נתקל ביתד ונפל. החייל שנפל לא נפצע כלל, אך מפקד המחלקה בא אלי ויבקש ממנו שכשנחזור לבסיס, הוא רוצה שנבצע על כך תחקיר.
כשחזרנו עייפים בסוף אותו השבוע לבסיס, בא אלי אותו מ"מ וביקש שנערוך את התחקיר עם שני החיילים לפני שאשחרר אותם לסוף היום. שאלתי אותו אם זה באמת הכרחי, כי החיילים גמורים מהשבוע, והרי אף אחד לא באמת נפגע מהתקרית. אז הוא ענה לי שזה הכרחי, ושאם אנחנו רוצים לחנך את החיילים למצויינות, עלינו להתייחס למקרי רשלנות שהובילו לאירועי "כמעט ונפגע" כאילו הם מקרי "נפגע". כי זו הדרך למזער ולחסוך נזקים עתידיים. הרעיון מאחורי הגישה הזאת הוא שאין צורך לחכות למקרה אמת כדי ללמוד מהם. הלקח הזה, וחוכמתו של אותו מפקד מחלקה הולכים איתי עד היום.
לפני כשבוע, חבר הפנה את תשומת ליבי לסיפור הבא. אלו פרטיו: חברת Zendesk מציעה מערכת לניהול שירות לקוחות בעזרת אינטגרציה פשוטה. בחור בן 15 בשם דניאל גילה שהשירות שהיא מציעה חשוף למתקפה שמאפשרת Email Spoofing וניצול שלה מאפשר לו לזייף את כתובת המקור כאשר הוא שולח אליה מיילים (הכותב אינו מפרט אודות טכניקת ה-Spoofing שבה הוא עשה שימוש, אך לפי הקוד שצרף נראה שהשרתים של החברה לא קונפגו לתמוך בהגנות בסיסיות כגון SPF ו-DKIM לאימות השולח).
לשירות ש-Zendesk נותנים, יש פיצ'ר של Ticket Collaboration אשר מאפשר לצרף נמענים נוספים ל-Ticket שנפתח. ניתן לעשות זאת ע"י הוספת הכתובת שלהם ב-CC כאשר שולחים מייל להתכתבות קיימת. כל התכתבות חדשה (Ticket שניפתח ע"י לקוח) מקבל Ticket-ID שהוא חלק מכתובת האימייל שדרכה המערכת מתכתבת עם הלקוח. לתוקף קל יחסית לנחש כתובות של התכתבויות מכיוון שמדובר ב-ID שעולה בצורה לינארית.
בשלב זה, החולשה הנ"ל איפשרה לדניאל לצרף את עצמו ל-Ticket-ים שלקוחות אחרים פתחו, ע"י ניחוש צמד כתובת מוען (הלקוח שיצר את הפניה) ונמען התיבה עם ה-Ticket-ID שאותה הוא צריך לנחש (אך, כאמור, בקלות ניתן לעשות Brute Force מכיוון שמדובר ב-ID רץ).
דניאל דיווח על הבאג לחברת ZenDesk וטען שהוא יכול לקרוא כל Ticket שהוא רוצה. טענה די רצינית, מכיוון שבהרבה מקרים, כאשר לקוחות מתכתבים עם שירות התמיכה של חברה מסויימת, הם מרגישים מאוד בנוח לחשוף פרטים טכניים ורגישים מכיוון שהם מעוניינים לפתור את התקלה שלשמה הם פנו לאותו שירות לקוחות.
חברת ZenDesk השיבה שלא מדובר בכשל משמעותי, ולא רק - הוא אפילו חורג מה-Scope שהחברה סימנה בתוכנית ה-Bug Bounty ב-HackerOne שבמסגרתה דניאל החל לחקור את המערכת ולכן הם אינם מוכנים להכיר בממצא של דניאל.
עד כה, עוד סיפור קלאסי שאפשר למצוא בלא מעט מקרים ב-HackerOne: חוקר פונה לחברה עם ממצא די משמעותי והחברה מוצאת סיבה לא לייחס אליו חשיבות. אך בשלב זה דניאל כותב שהוא נתקל בפוסט ישן של חוקר אבטחה נוסף, שפרסם על חולשה עם אפקט דומה במערכות של ZenDesk. והבין שעם מספר שינויים ומעקפים לוגיים נוספים הוא יכול להשתמש ברעיון כדי להשיג אפקט משמעותי יותר: שימוש בפרימיטיב הזה כדי ליצור משתמש Slack שאיתו הוא יכול להתחבר ל-Slack של כל חברה שמשתמשת בשירות של ZenDesk (וכראה לשירותים נוספים של החברה שמשתמשים במנגנון הזדהות דומה).
עם היכולת הזאת דניאל כבר פנה למספר לקוחות של ZenDesk, שמאוד לא היו מרוצים שילד אקראי בן 15 עם סקריפט קצרצר ביד יכול לגשת לערוצי ה-Slack שלהם. מאותן החברות דניאל קיבל כסף כתמורה על הדיווח, אך מחברת ZenDesk הוא לא, למרות שהחברה תיקנה את הבאג. הפעם בטענה שבגלל שהוא שיתף את המידע על החולשה שהוא מצא עם לקוחותיה. וואלה.
מלבד העובדה הנהדרת שכיף לראות שילד בן 15 מצליח להשיג הישג משמעותי בזכות לא מעט יצירתיות ותושיה, ומלבד העובדה המבאסת (אך הברורה) שיש ארגונים שפשוט לא אכפת להם מאבטחת מידע או מזה שברשלנותם הם מסכנים את הלקוחות שלהם, ואת הלקוחות של הלקוחות שלהם, יש כאן עניין חשוב שלדעתי שווה לאמץ: אותו לקח שלימד אותי אז מפקד המחלקה.
כיום, בזכות חוקי ה-GDPR, חברות שאוספות מידע בצורה מרושלת, ומתייחסות ברשלנות לתשתיות שלהן, ובעקבות אותה רשלנות - מידע פרטי של לקוחותיהם ניזוק ונגנב עשויות לקבל קנסות גבוהים. שזה כמובן מצוין, אם החלטתם לאסוף מידע על הלקוחות שלכם - המינימום שמצופה מכם זה להגן עליו. הקנסות גדולים והחוקים האלה אכן מרתיעים חלק מהחברות.
אך הבעיה היא שהקנס שאותן חברות מקבלות, אומנם מלמד אותם לקח, אך הוא אינו מחזיר את הפרטיות לאותם משתמשים שהמידע שנשמר עליהם נגנב. זה נכון שניתן לשנות דברים שאבדו במאגרים שכללו כתובות אימייל, סיסמאות, מזהה פירסומי, כרטיס אשראי או חשבונות בנק, אך מידע כגון היסטוריית קניות, תיקים רפואיים, העדפות מיניות או פרטי DNA אין אפשרות להחזיר. ואת הנזק במקרים האלה אי אפשר להשיב.
במציאות כפי שהיא כיום, אנחנו כל פעם מחכים שהמשתמשים ייפגעו - ורק אז אנחנו מלמדים לקח את החברה הרשלנית. אך כמו שאנחנו מבינים - לימוד אותו הלקח לא באמת מחזיר למשתמש את הפרטיות שלו.
למה שלא נהיה מצויינים? למה שלא נאמץ את הגישה של אותו מפקד מחלקה. בואו נלמד את הלקחים מבלי לחכות שהמשתמשים באמת ינזקו. נלמד אותם במקרים של "כמעט ונפגע". איזה מקרים הם מקרים של "כמעט ונפגע"? בדיוק המקרה של דניאל: חברה עם מעל ל-200,000 לקוחות, שחלקם הם מהגדולים בשוק, שמתייחסת לאירוע אבטחתי שדווח אליה באופן רשלני שמסכן את לקוחותיה ביודעין. במקרה של דניאל, אם הוא לא היה מתעקש ומגדיל ראש, סביר להניח שהדיווח שלו היה מושתק, עד שארגון פשיעה קיברנטי היה מוצא את אותה החולשה ומציף את החנויות בדארקנט בעוד מידע פרטי של משתמשים ולקוחות.
יכול להיות מאוד שאם את הלקח הזה אימצו כבר אז ב-2006 בגדוד חי"ר קטנטן, אז הגיע הזמן שהיום, לקראת סוף 2024, אחד מענפי הטכנולוגיה המכניסים ביותר בשוק יתחיל לאמץ אותו גם כן.
אז זהו, לפני שניגש לתוכן הגליון, נרצה להגיד תודה לכל מי שישב והשקיע מזמנו וכתב לנו מאמר החודש. תודה רבה לספיר פדרובסקי, תודה רבה לדניאל קויפמן, תודה רבה לאלעד ישעיהו, תודה רבה לעומר כחלון, תודה רבה לרועי שרמן ותודה רבה לתומר גל נצר!
החודש, הגליון כולל את המאמרים הבאים:
-
Managed Identities Azure - מאת ספיר פדרובסקיManaged Identitiesהוא תת תחום של קונספט חדש לגמרי שתופס תאוצה בזמן האחרון בעולם הענן, הוא תחום הישויות המנוהלות בענן. במאמר זה ספיר סורקת את עולם ה-Managed Identities ב-Azure, מציגה מחקרים חקרים בנושא אבטחת מידע בנושא ועוד.
-
Detection Engineering בארץ הקודש - מאת דניאל קויפמןDetection Engineering הוא תחום העוסק ביצירה, פיתוח, ויישום של מערכות וטכנולוגיות לגילוי איומים, בעיקר בהקשרים של אבטחת מידע וסייבר. המטרה היא לזהות בצורה מהירה ויעילה ניסיונות חדירה, מתקפות סייבר או איומים פנימיים על מערכות המידע הארגוניות. בתחום זה מתמקדים בבנייה של חוקים, אלגוריתמים וכלים אוטומטיים שמסוגלים לזהות התנהגות חשודה או אנומליות במידע שמתקבל מרשתות, ממערכות הפעלה, מאפליקציות או ממכשירים מחוברים. במאמר הזה, מציג דניאל את הנושא והתחום.
-
Exploiting Legitimate APIs for Data Theft - מאת אלעד ישעיהואחת הדרכים שבהן ניתן לזהות התנהגות חשודה על עמדות קצה, היא באמצעות ניתוח דפוסי התקשורת שלהן, ובפרט לאילו כתובות חוץ אירגוניות הן מתקשרות. אך מה קורה אם תוכנה זדונית שולחת את המידע שהיא אוספת אל יעדים תמימים לשיתוף מידע כגון Virus Total ,Discord ו-Telegram? במאמר זה סוקר אלעד שיטה זאת על מנת לחמוק מתוכנות ה-Firewall המקומית ומוצרי ה-Firewall והארגוניים.
-
כל מה שרציתם לדעת על PsExec ומעולם לא העזתם לשאול - מאת עומר כחלוןPsexec הוא אחד הכלים החזקים והידועים מבית היוצר של Sysinternals. כעקרון, מטרתו הלגיטימית היא לאפשר ניהול של עמדות Windows ללא צורך בגישה פיזית לעמדה. הכלי מאפשר התחברות מרוחקת והרצת קוד על מכונת היעד. תוקפי סייבר לעיתים רבות מנצלים את הכלי על מנת לבצע Lateral Movement ובכך להתפשט לעמדות נוספות ברשת. כחוקרים, חשוב להבין איך עובד הכלי על מנת שנוכל לזהות שימוש שלו ברשתות. במאמר זה מסבירה עומר איך פועל הכלי מאחורי הקלעים.
-
על צוותים אדומים חלק ב' - מאת רועי שרמןצוותים אדומים יודעים היום להתמודד עם חדירה לארגון בכללותו, על ידי ניצול של כל הדרכים האפשריות ולהתמודד אקטיבית מול צוותי ההגנה וכל זאת על מנת לשפר את מצב הארגון בהיבט של אבטחת המידע. מאמר זה הינו מאמר המשך למאמר אשר נכתב על ידי רועי ופורסם בגליון ה-84 אשר פירט על תפקידם של הצוותים האדומים. עם זאת, במאמר זה רועי לא יתמקד בתפקיד של צוותים-אדומים במבדקי חדירות, אלא במהות הקונספט של הצוותים-האדומים כפי שהוא המוצא שנים לפני שפותחו המחשבים ורשתות התקשורת.
-
מהפכת הקול - מאת תומר גל נצרVoIP הינה טכנולוגיה המאפשרת לנהל שיחות טלפון אך ורק בעזרת האינטרנט. VoIP ממיר את הקול לפקטות ושולח אותן ל-IP בצד השני של השיחה. מכיוון שחוץ מחומרה בסיסית וחיבור לאינטרנט, VoIP כמעט לגמרי תוכנתי, אפשר להשתמש בו במחשבים, בטלפונים, בטאבלטים ובכל מכשיר התומך בתוכנה. עם זאת, החיסרון המרכזי של VoIP הוא דרישה לאינטרנט מהיר ויציב, אחרת איכות השיחה תרד משמעותית. הסיבה לכך היא שאיכות שיחה דרך VoIP היא מטבעה מאבדת מידע. על מנת לפתור בעיה זאת, נפתח חיפוש אחר פרוטוקול חדש, ובחיפוש זה מצאו את VoLTE. העברת קול על גבי LTE - טכנולוגיית תקשורת אינטרנטית למכשירים ניידים הדומה במטרתה ל-VoIP. במאמר זה מציג תומר את הפרוטוקול, כיצד הוא התפתח וכיצד הוא עונה על הבעיות שהשימוש ב-VoIP הביא.
קריאה נעימה,
אפיק קסטיאל