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

By דני ברדברי • 14 ביולי 2026 • 5 דקות קריאה

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

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

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

החקירה לא קבעה כיצד Icarus (קבוצה חדשה, פעילה רק מאפריל 2026) קיבלה את ה-PAT, אך ב-11 ביוני היא השתמשה באסימון כדי לדחוף קוד חדש לשכבת שירות האינטגרציה של Klue.

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

עדכון הקוד אסף את אסימוני OAuth (אסימוני הפעלה מתמשכים לגישה חוזרת ונשנית ללא סיסמה) ששמרה Klue כדי לגשת לנתוני לקוחותיה במערכות אלו. לאחר מכן, התוקפים השתמשו באסימונים אלו כדי לגזול נתונים ממערכות Salesforce ו-Gong של אותם לקוחות.

אסימוני OAuth כהלבנת לגיטימציה

לא היה קל לזהות את ההתקפה מכיוון שהשימוש באסימוני OAuth גנובים לא נראה כמו חדירה עד שאסימונים אלה מבוטלים. Icarus ביצעה קריאות REST ישירות כנגד מופעי Salesforce ו-Gong בדיוק כפי שכל לקוח לגיטימי היה עושה.

Salesforce היא זו שסיפרה לקלואה מה קרה ב-12 ביוני, מה שגרם לחברת המודיעין התחרותי להחליף את אסימוני ה-OAuth שלה.

רשימת הקורבנות שאושרו כללה את HackerOne, Huntress, Jamf, Recorded Future, Snyk ו-LastPass. היא נראית כמו מדריך של חברות שתפקידן היומיומי הוא להורות לחברות אחרות כיצד לנהל בדיוק את הסיכון הזה.

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

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

צַיֶדֶת ביצעו עדכונים מפורטים, והסביר כי Icarus פרסמה דוח נתונים באתר האפל שלה, ואיימה לשחרר נתונים נוספים, תוך ציטוט של למעלה מ-200 חברות קורבנות. היא זיהתה את אתר דליפת הנתונים כאתר המאוחסן ברוסיה.

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

מדוע זה הופך את ISO 27001 ליקר יותר

בקרות ניהול הספקים והגישה של ISO 27001 נועדו להגן מפני הכשלים ש-Icarus ניצלה.

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

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

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

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

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

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

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

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