ביוני 2026 עשרות חברות - ובהן ספקי סייבר מהשורה הראשונה כמו Huntress, Recorded Future, Tanium ו-BeyondTrust - גילו שנתוני ה-CRM שלהן נשאבו מסביבת ה-Salesforce שלהן. הפרט המטריד: אף אחת מהן לא נפרצה ישירות. איש לא ניחש סיסמה, לא עקף אימות דו-שלבי ולא ניצל חולשה בפלטפורמת Salesforce. התוקף פשוט השתמש באינטגרציה מהימנה שכל אחת מהן חיברה מרצונה - פלטפורמת המודיעין התחרותי Klue - ובטוקני ה-OAuth שהיא החזיקה בשמן.[1][2]
זו אינה תקלה חד-פעמית של ספק אחד. זהו דפוס תקיפה שחוזר על עצמו: החוליה החלשה בשרשרת האספקה של ה-SaaS אינה בהכרח היישום שאתם מריצים, אלא ההרשאה שנתתם ליישום אחר לגעת בו. המאמר מסביר איך טוקן OAuth של אינטגרציה הופך לנקודת כשל של עשרות ארגונים בבת אחת, ואילו בקרות ממפות את ההרשאות האלה ומצמצמות אותן - אותן בקרות שעומדות בלב שירות "רב מגן" וסקר הביטחון 360° של KPLNS.
מה קרה ב-Klue - פריצה בלי לגעת באף לקוח
Klue היא פלטפורמת SaaS למודיעין תחרותי, שמתחברת ל-Salesforce של לקוחותיה כדי למשוך נתוני עסקאות ולהזרים אליהם תובנות. כדי לעשות זאת היא מחזיקה, בשם כל לקוח, טוקן OAuth שמעניק לה גישה מתמשכת לאותה סביבת Salesforce. כאשר תשתית האינטגרציה של Klue נפרצה - כל הטוקנים האלה הפכו למפתח מוכן לשימוש.[1][3]
🔴 שרשרת האירועים - יוני 2026
נקודת הכניסה הייתה אישור ותק (credential) ישן שנוצר לצורכי אב-טיפוס - נותר פעיל אך מזמן לא בשימוש. דרכו הפיק התוקף טוקני OAuth של חשבונות השירות שחיברו את Klue ל-Salesforce, והריץ סקריפטים אוטומטיים שמשכו כמויות גדולות של רשומות דרך Salesforce REST API לאורך כ-24 שעות. התבנית זוהתה: שלב סיור אטי עם User-Agent של python-urllib, ואז זינוק של כמעט אלף שאילתות בחלון של 15 דקות.[2]
הכשל התגלה ב-12 ביוני 2026; Klue ביטלה את אישורי ה-OAuth לכל הלקוחות והשביתה זמנית את האינטגרציות, ו-Salesforce ניתקה את חיבור אפליקציית Klue מצדה. קבוצת הסחיטה Icarus נטלה אחריות והחלה לשלוח מיילי סחיטה לקורבנות.[1][4]
Salesforce הבהירה במפורש: "הבעיה מוגבלת לחיבור האפליקציה של Klue ואינה נובעת מחולשה בפלטפורמת Salesforce".[1] וזו בדיוק הנקודה - מנגנוני ההגנה של הלקוח (סיסמאות, MFA, מדיניות התחברות) לא נגעו לאירוע, כי התוקף לא נכנס דרך הדלת הקדמית. הוא נכנס דרך אינטגרציה שהלקוח עצמו אישר.
המשמעות עבור ספק בשרשרת אספקה
הנתונים שנחשפו כללו אנשי קשר עסקיים, הצעות מחיר, פרטי מנוי והתכתבויות מכירה - בדיוק סוג המידע שספק ביטחוני או תעשייתי מחזיק על לקוחותיו ועל הפרויקטים שלו. מבחינת הלקוח שלכם, אין הבדל אם הדליפה יצאה מה-CRM שלכם ישירות או מאינטגרציה שחיברתם אליו. האחריות - ולעיתים גם החשיפה המשפטית - נשארת אצלכם.
OAuth בגובה העיניים - למה טוקן שווה סיסמה (ולעיתים יותר)
OAuth הוא המנגנון שמאפשר לאפליקציה אחת לגשת לנתונים באפליקציה אחרת בלי לחשוף סיסמה. במקום למסור ל-Klue את סיסמת ה-Salesforce שלכם, אתם מאשרים לה גישה, ובתמורה היא מקבלת טוקן - מחרוזת סודית שמייצגת את ההרשאה. הרעיון מצוין; הבעיה היא בתכונות שהופכות את הטוקן ליעד תקיפה אידיאלי:
טוקן עוקף אימות דו-שלבי
MFA מגן על תהליך ההתחברות. טוקן OAuth תקף כבר אחרי ההתחברות - הוא מייצג הרשאה שכבר אושרה. מי שמחזיק בטוקן ניגש לנתונים בלי סיסמה ובלי אתגר MFA. זו הסיבה שגניבת טוקן היא כה אפקטיבית: היא מדלגת מעל שכבת ההגנה החזקה ביותר של הלקוח.
Refresh Token = גישה מתמשכת
אינטגרציות רבות מחזיקות refresh token שמאפשר להן לחדש את הגישה שוב ושוב, לאורך חודשים, בלי מעורבות המשתמש. טוקן כזה שנגנב מעניק לתוקף דריסת רגל שקטה ומתמשכת - עד שמישהו יבטל אותו יזומות. בפרשת Klue ובפרשת Drift כאחת, ביטול מסיבי של refresh tokens היה צעד הכיבוי המרכזי.
הרשאות רחבות מדי (Over-scoping)
אינטגרציה שביקשה גישת "קריאה לכל האובייקטים" מקבלת בדיוק את זה - גם אם בפועל היא צריכה שלושה שדות. טוקן עם scope רחב שנגנב שווה הרבה יותר לתוקף. מזעור ההרשאות (least privilege) הוא ההבדל בין דליפה של מספר טלפון לבין שאיבה של כל בסיס הלקוחות.
ריכוזיות: ספק אחד, עשרות קורבנות
ספק SaaS שמחזיק טוקנים של מאות לקוחות הוא נקודת כשל בודדת בקנה מידה עצום. פריצה אחת אליו = גישה בו-זמנית לכל הלקוחות. זה בדיוק מה שהפך אירוע בודד ב-Klue לדליפה חוצת-תעשייה, וזה מה שהפך את Salesloft Drift למתקפה שנגעה ב-700+ ארגונים.
למה זו בעיית שרשרת אספקה - לא בעיה של SaaS בודד
קל להתייחס לפרשת Klue כתקרית של ספק אחד. אבל אותו דפוס בדיוק התרחש כמעט שנה קודם לכן, בקנה מידה גדול יותר - סימן שמדובר במחלקה של תקיפות, לא במקרה קצה. זהו בדיוק סוג מתקפת שרשרת אספקת התוכנה שבה החוליה הנפרצת אינה הארגון המותקף אלא ספק שהוא סומך עליו.
🟠 תקדים: Salesloft Drift / UNC6395 (אוגוסט 2025)
בין 9 ל-17 באוגוסט 2025 ניצלה קבוצת התקיפה UNC6395 טוקני OAuth שנגנבו מאינטגרציית הצ'אטבוט Drift של חברת Salesloft, וגישה דרכם למאות סביבות Salesforce. התוקפים שאבו רשומות מ-700+ ארגונים, בהם Cloudflare, Google, Palo Alto Networks, Proofpoint ו-Zscaler. הטוקנים נגנבו מסביבת ה-AWS של Drift; ב-20 באוגוסט ביטלו Salesloft ו-Salesforce את כל טוקני ה-OAuth של Drift והסירו את האפליקציה מ-AppExchange.[5][6]
המכנה המשותף - וזה מה שחשוב
בשני המקרים הפלטפורמה (Salesforce) לא נפרצה. בשני המקרים נפרץ ספק-ביניים מהימן שהחזיק טוקני OAuth של לקוחותיו. בשני המקרים הכיבוי היה ביטול מסיבי של טוקנים וניתוק האינטגרציה. וברוב המקרים הקורבנות גילו את הדליפה מהתוקף, לא ממערכות ההגנה שלהם - כי אף אחד לא ניטר את התנהגות האינטגרציה. שרשרת האספקה של ה-SaaS גדולה בדיוק כמו רשימת האפליקציות שחיברתם, ורוב הארגונים לא יודעים כמה ארוכה הרשימה הזו.
נקודות הכשל של אינטגרציית OAuth - ואיפה נשברת השרשרת
כשמפרקים את שני האירועים למרכיבים, מתגלה שרשרת של כשלים שאפשר לחתוך בכל אחת מחוליותיה. זה מה שהופך את הסיכון לניתן לניהול - בתנאי שממפים אותו:
הבקרות שממפות ומצמצמות את ההרשאות
ההגנה מפני סיכון אינטגרציות ה-SaaS אינה טכנולוגיה חדשה - היא היגיינת הרשאות. אותן משפחות בקרה שעומדות בבסיס סקר "רב מגן" - 44 בקרות אבטחת מידע ממפות בדיוק את נקודות הכשל שלמעלה: ניהול זהויות והרשאות, ניטור, ותגובה לאירועים. הנה כיצד הן מתורגמות לעולם ה-OAuth:
מיפוי (Inventory) - אי אפשר להגן על מה שלא רשום
הצעד הראשון הוא רשימה מלאה של כל היישומים המחוברים (Connected Apps) לכל מערכת SaaS מרכזית - מי הם, מי אישר אותם, אילו הרשאות (scopes) יש להם, ומתי נעשה בהם שימוש בפועל. אינטגרציות "יתומות" שאיש כבר לא זוכר - הן הראשונות שיש לנתק. ברוב הארגונים מספר האפליקציות המחוברות גדול בהרבה מההערכה.
מזעור הרשאות (Least Privilege) - לצמצם את ערך הטוקן הגנוב
לכל אינטגרציה יש להעניק את ה-scope המינימלי שנדרש לתפקודה - קריאה בלבד במקום כתיבה, אובייקטים ספציפיים במקום גישה גורפת. כך, גם אם טוקן נגנב, מה שהתוקף יכול לעשות איתו מוגבל. זו הבקרה היחידה שהייתה מצמצמת ישירות את היקף הדליפה בשתי הפרשות.
הגבלת מקור וניטור - לזהות את החריגה בזמן אמת
IP allowlisting על חשבונות האינטגרציה מגביל את הגישה לכתובות הספק בלבד. במקביל, ניטור התנהגותי על קצב ונפח ה-API של החשבונות המחוברים - וזיהוי גישה מכתובת לא מוכרת - הוא מה שהופך שאיבה של 24 שעות לאירוע שנעצר תוך דקות. יש להתייחס לזהות של אפליקציה מחוברת, לטוקנים שלה ולתעבורה היוצאת ממנה באותה קפדנות כמו לחשבון משתמש בעל הרשאות-על.
סבב וביטול מהיר - לקצר את חלון החשיפה
נוהל מוגדר לסבב תקופתי של סודות האינטגרציה (client secrets, refresh tokens) ולביטול מיידי בעת חשד. כשפרשת Klue התפוצצה, הצעד המומלץ היה לאפס ולהנפיק מחדש הכול - סיסמת חשבון השירות, refresh tokens, client secrets וכל מענקי ה-OAuth הפעילים. ארגון שיש לו נוהל כזה מראש מכבה אירוע בשעות, לא בימים.
צ'קליסט היערכות - אבטחת אינטגרציות SaaS
- הפקת רשימת מלאי מלאה של כל היישומים המחוברים (Connected Apps / OAuth) לכל מערכת SaaS מרכזית.
- סקירת ה-scope של כל אינטגרציה וצמצומו למינימום הנדרש - קריאה בלבד ואובייקטים ספציפיים ככל הניתן.
- ניתוק אינטגרציות "יתומות" ובלתי-מזוהות, וביטול טוקנים שאינם בשימוש.
- הפעלת IP allowlisting על חשבונות שירות ואינטגרציה, כולל ממשקי SIEM/SOAR.
- ניטור נפח וקצב שאילתות API של חשבונות מחוברים, והתראה על גישה מכתובת לא מוכרת.
- הגדרת נוהל סבב תקופתי ל-client secrets ו-refresh tokens.
- הגדרת נוהל ביטול מהיר (kill-switch) של טוקנים ואינטגרציה בעת חשד לאירוע.
- הכללת ספקי ה-SaaS בהערכת סיכוני צד-שלישי - מי מהם מחזיק טוקנים בשמכם, ומה מדיניות האבטחה שלהם.
- עיגון בחוזה מול הספק של חובת דיווח על אירוע ושל בקרות מינימום על תשתית האינטגרציה.
השורה התחתונה
פרשת Klue (יוני 2026) ופרשת Salesloft Drift (2025) מספרות את אותו סיפור: החוליה החלשה בשרשרת האספקה של ה-SaaS אינה המערכת שאתם מריצים, אלא ההרשאה שנתתם למערכת אחרת לגעת בה. טוקן OAuth עוקף MFA, מעניק גישה מתמשכת, ולעיתים קרובות רחב הרבה מהנדרש - ומי שמחזיק אותו לא צריך לפרוץ אליכם כדי לשאוב את הנתונים שלכם.
הבשורה הטובה: זו בעיה של היגיינת הרשאות, ויש לה תשובה מוכרת. מיפוי היישומים המחוברים, מזעור ה-scope, הגבלת מקור, ניטור וסבב טוקנים - אלה בדיוק הבקרות ש-KPLNS ממפה ומיישמת במסגרת "רב מגן" וסקר הביטחון 360°. השאלה אינה אם ספק ה-SaaS הבא שלכם ייפרץ, אלא כמה מהנתונים שלכם הוא יוכל לחשוף כשזה יקרה.
מקורות
- The Hacker News — Salesforce Disables Klue App Integration After OAuth Token Abuse Exposes Customer Data (June 2026)
- ReliaQuest — Threat Spotlight: Klue Integration Abused in CRM Data Theft (OAuth token generation, Salesforce REST API, recommended controls)
- BankInfoSecurity — Klue Confirms OAuth Token Theft Led to Salesforce Data Heist
- RH-ISAC — Icarus Threat Group Claims Salesforce Data Theft in Klue Supply Chain Breach
- Anomali — Reviewing the Salesforce–Salesloft Drift OAuth Supply Chain Breach (UNC6395, Aug 2025)
- AppOmni — Drift Breach Salesforce (UNC6395): Why Salesforce OAuth Integrations Are a Growing Risk
- Field Effect — Klue Integration Breach Exposes Salesforce Customer Data