גורם בלתי מורשה השיג את פרטי הגישה של חשבון ה‑ AWS שבאמצעותו פועלת Qubole – פלטפורמה לעיבוד נתוני עתק בבעלות חברת Idera, בתוך הענן של לקוחותיה. בין 14 ל‑ 26 באוקטובר הוא השתמש בהם כדי להיכנס לחשבונות AWS של לקוחות, לקרוא סיסמאות ומפתחות שנשמרו בהם ולהוריד מידע ממאגרי האחסון. לפי Wiz, בחלק מהסביבות Qubole עדיין פעלה כרגיל. ברוב הסביבות שבדקה, הבקשות של התוקף היו הכניסות היחידות של חשבון הספק לאורך כל אוקטובר: שם החיבור כבר לא שימש לעבודה, אך עדיין התקבל.
את הפעילות זיהתה Sentra, חברה לאבטחת מידע שחלק מלקוחותיה נפגעו. היא העבירה את הממצאים ל‑ Wiz, שחקרה את האירוע יחד איתה ועם Mandiant ופרסמה ב‑ 9 בנובמבר ניתוח וסימנים לזיהוי.
איך מקבל ספק גישה לענן של הלקוח
בשיטת החיבור המקובלת, הספק אינו מחזיק סיסמה קבועה לחשבון של הלקוח. בכל פעם שהוא צריך לעבוד, AWS מנפיקה לו אישור גישה קצר מועד לתפקיד (IAM Role) שהלקוח הגדיר מראש. התפקיד הינו סל הרשאות שבהגדרותיו רשום איזה חשבון חיצוני רשאי לקבל את האישור. Qubole מאפשרת גם חיבור במפתחות גישה קבועים.
היתרון ברור: אצל הספק לא יושב סוד ארוך טווח של הלקוח. המחיר פחות גלוי. כל הלקוחות סומכים על אותו חשבון של הספק, כך שמי שמחזיק בפרטי הגישה של החשבון הזה יכול לבקש אישור לכל לקוח שעדיין סומך עליו.
AWS מאפשרת לחייב את הספק לצרף לכל בקשה גם קוד (External ID). תפקידו לקשור את הבקשה ללקוח מסוים, לא לשמש סיסמה. לפי ההנחיות של AWS, כפי שמביאה The Hacker News, הקוד אינו נחשב סוד. כל בקשה של התוקף כללה את הקוד הנכון.
לפי Sentra, הלקוחות שנפגעו הגדירו את החיבור כפי ש‑ AWS ממליצה, כולל הקוד. החשבון נכון, הקוד נכון. ההבדל היה בנקודת המוצא של הבקשות: כל התעבורה הלגיטימית של הפלטפורמה שראתה Wiz יצאה מתוך תשתית AWS, בעוד שהתוקף פעל דרך שירות ה‑ VPN Mullvad ומשרת שכור אצל OVH. תנאי האמון לא בדקו את כתובת המקור. לפי Wiz ו‑ Sentra, תנאי כזה לבדו היה חוסם כל כניסה לתפקיד שהן תיעדו. הוא אפשרי כשהספק מפרסם את טווחי הכתובות שלו. Wiz קוראת לספקים לעשות זאת.
איזה מידע נגנב
פרטי גישה נשמרים בענן במקומות צפויים, מפני שתוכנה צריכה אותם כדי לרוץ בלי שאדם יקליד סיסמה: משתני הסביבה של פונקציות Lambda, שירות Secrets Manager ומאגר הפרמטרים של SSM. לפי Wiz, התוקף פנה לשלושתם. Sentra מוסיפה את סקריפטי האתחול של שרתי EC2. לפי Sentra, כ‑ 100 סיסמאות ומפתחות נקראו בתוך שבע דקות.
חלק ממה שנמצא נבדק. TruffleHog, כלי קוד פתוח לאיתור סודות, ניסה את המפתחות מול השירותים שאליהם הם שייכים. לפי Wiz, המפתחות שנבדקו כך היו של הארגונים שנפגעו: מפתחות גישה ל‑ AWS, סודות של אפליקציות ב‑ Entra ID של מיקרוסופט ופרטי גישה של אפליקציות ב‑ Okta. Sentra מציינת שבין הסודות שנשלפו היו גם אסימונים וקודי External ID של Qubole עצמה. Entra ID ו‑ Okta הן מערכות ההזדהות של הארגון, כך שסוד תקף של אפליקציה באחת מהן עשוי לאפשר כניסה גם לשירותים שאינם קשורים ל‑ AWS.
במקביל ירדו קבצים ממאגרי האחסון (S3). לפי Wiz, נראה שההיקף נקבע לפי ההרשאות ולא לפי התוכן. בחלק מהסביבות הורדו מאגרים שלמים. לפי Sentra, הסבב האחרון הוריד גיבויים של מסדי נתונים מסביבת הייצור. Sentra מוסיפה שלא בוצעה אף פעולת כתיבה. כשלא משתנה דבר, אין שינוי שמערכת או אדם ישימו לב אליו. לדברי Sentra, זה מה שהקשה לזהות את המתקפה.
מה עוד לא ידוע
היקף הפגיעה אינו ברור. Wiz כותבת על "סביבות מרובות" וסירבה למסור ל‑ The Register מספר. Sentra כותבת במקום אחד על "יותר מתריסר ארגונים" ובמקום אחר על "עשרות" לקוחות של Qubole.
לא פורסם איך הושגו פרטי הגישה של Qubole. לפי The Hacker News, החוקרים גם לא מסרו אם הם הושבתו מאז. לפי Sentra, התוקף חדל לפעול בלי שאיבד את הגישה, מפני שמדיניות האמון נשארה בתוקף. Qubole ו‑ Idera לא פרסמו הודעה באתרים שלהן עד מועד הסיקור של The Hacker News. גם Qubole וגם AWS לא השיבו לפניות של The Register.
מי עומד מאחורי המתקפה ולמה – לא ידוע. Wiz לא שייכה אותה לגורם מוכר. לדבריה, בחירת המטרות נראית אופורטוניסטית ואינה תואמת דפוס מדינתי. Wiz גילתה גם, באמצעות שירות Validin, שבתקופה שבה שרת ה‑ OVH היה בשליטת התוקף אוחסן עליו קובץ ISO שנראה מיועד לאתחול מרחוק של מחשב קורבן. שימוש בו לא זוהה.
ערוץ נוסף שלא נקשר לאירוע הזה: בין 8 ל‑ 11 באוקטובר נוצלו מפתחות גישה קבועים של לקוחות, ככל הנראה כאלו שהוגדרו עבור Qubole. לפי Wiz, במספר קטן של מקרים הם הובילו לפריצה לסביבת הענן.
הסיכון לארגון שלכם
לפי Wiz, כפי שמסרה ל‑ The Register, ארגונים רבים השאירו את מדיניות האמון פעילה גם אחרי שהפסיקו להשתמש בפלטפורמה. זה תרחיש שכל ארגון מכיר: פיילוט שהסתיים, ספק שהוחלף, פרויקט שנסגר. ההרשאה בענן אינה נסגרת יחד איתם. לפי Sentra, התפקידים של Qubole עמדו ללא שימוש מאז האביב. לדבריה, כל סוד שדלף הגיע מהרשאות ש‑ Qubole מעולם לא נזקקה להן. המדיניות לדוגמה במדריך ההתקנה של Qubole עצמה מתירה קריאה מכל מאגר אחסון בחשבון, לא רק מהמאגרים שהוגדרו לעבודה איתה.
ב‑ 9 בנובמבר פורסם כאן מבזק על המתקפה על הבנק הצרפתי Crédit Mutuel Arkéa, שבה עבר התוקף דרך פלטפורמה של ספק. Qubole מציגה את אותו עיקרון בענן.
בחלק מהסביבות שנפגעו לא ניתן היה לקבוע אילו קבצים נקראו. לפי Wiz, הסיבה הייתה רישום חסר: יומני הניהול של CloudTrail מתעדים כניסה לתפקיד ורשימת מאגרים, לא קריאה של קובץ. Sentra שחזרה חלק מהרשימה בדרך עקיפה: היא הצליבה את רישומי הפענוח של קבצים מוצפנים עם הסשנים של התוקף. לדבריה, השיטה אינה רואה קבצים שמוגנים בהצפנת ברירת המחדל בלבד. לכן הרשימה חלקית. ארגון שאינו יודע מה נחשף מתקשה לענות ללקוחות ולרגולטור.
בישראל, תקנה 15 לתקנות הגנת הפרטיות (אבטחת מידע) מסדירה התקשרות עם גורם חיצוני שמקבל גישה למאגר מידע. ההסכם עם ספק כזה צריך לפרט, בין השאר, את מערכות המאגר שהוא רשאי לגשת אליהן, את משך ההתקשרות ואת השבת המידע והשמדתו בסיומה. מדריך יישום לתקנה, שמתפרסם באתר עיריית תל אביב‑יפו, ממליץ גם לפרט את מורשי הגישה מטעם הספק ולשקול מתן גישה מוגבלת בזמן לתקופת השירות. תפקיד בענן שמתיר כניסה לחשבון של ספק הינו הרשאת גישה מהסוג הזה. נוהל סיום התקשרות שמסתיים באישור מחיקה מהספק, בלי בדיקה שהתפקיד בענן הוסר, משאיר אותה בתוקף.
010 הגנה על מידע
סקר סיכונים: תקנה 15 מחייבת לבחון את סיכוני ההתקשרות עם ספק לפני שהיא מתחילה. המדריך ליישומה ממליץ לעשות זאת באמצעות סקר סיכונים. בענן, סקר כזה יכול להתחיל במועד השימוש האחרון בכל תפקיד שמדיניות האמון שלו מתירה כניסה לחשבון חיצוני. משם הוא ממשיך למה שכל תפקיד כזה יכול לקרוא ולשאלה אם הכניסה אליו מוגבלת לכתובות הספק. התוצר הינו רשימה מעשית: חיבורים רדומים למחיקה והרשאות רחבות לצמצום.
SIEM/SOC: האות המרכזי שמציינת Wiz הוא חשבון של ספק שנכנס מרשת שאינה שלו. במקרה הזה היו אלו VPN ושרת אירוח שכור במקום תשתית AWS. Sentra מוסיפה אות שני: פעולה ראשונה של תפקיד אחרי חודשים של שקט. שני האותות נראים רק אם יומני CloudTrail של כל חשבון שמחזיק תפקיד של ספק מגיעים ל‑ SIEM ונשמרים מספיק זמן. רישום של קריאות קבצים במאגרים שמחזיקים מידע רגיש הוא שמאפשר לענות אחר כך על השאלה מה נלקח.
מודיעין סייבר: הסימנים לזיהוי באירוע הזה פורסמו בידי Wiz. מודיעין סייבר עוקב אחר פרסומים כאלו על כל ספק שעדיין מופיע במדיניות אמון בענן של הארגון, גם אם ההתקשרות איתו הסתיימה. כל פרסום כזה הופך לבדיקה לאחור ביומנים.
בסביבות הקורבנות לא תועדו נוזקה, הודעת דוא"ל או ניצול של חולשה: התוקף השתמש בהרשאה תקפה. לפי Sentra גם לא שונה ולא נמחק דבר. לכן הגנה אקטיבית מכופרה, סינון דוא"ל, עדכוני תוכנה ואבטחה, גיבוי והמשכיות עסקית ומודעות עובדים לסייבר אינם התשובה לשלב שתועד אצל הלקוחות. המידע עבר ישירות ממאגרי S3 אל תשתית התוקף. המקורות אינם מתארים נקודה שבה הייתה בקרת מניעת דלף מידע רואה אותו. איך נפרץ הספק עצמו, כאמור, לא פורסם.
אם Qubole מחוברת אצלכם, או הייתה מחוברת – מומלץ מאד:
- לסגור את הגישה לפני הכול. אם החיבור אינו בשימוש, יש למחוק את התפקיד או להוציא את החשבון של Qubole ממדיניות האמון. אם הוא בשימוש, Wiz ממליצה, כשהספק תומך בכך, להגביל את הכניסה לישות הספציפית של Qubole ולטווחי הכתובות שהיא מפרסמת. Wiz ממליצה גם להחליף את הקוד בתיאום עם הספק.
- לשמור את יומני CloudTrail מ‑ 1 באוקטובר לפני שיפוגו.
- לחפש ביומנים כניסה לתפקיד מחשבון 805246085872 מכתובת שאינה של AWS, כל פעילות של המשתמש AIDA3W7DIFLYOLTK63SFS, שמות סשן שמתחילים ב‑ quiam- ופעילות מהכתובות שפרסמה Wiz. כתובות OVH: 57.129.54.120 ו‑ 2001:41d0:70d:7800::. כתובות Mullvad: 45.83.220.211, 185.209.199.73 ו‑ 89.37.63.175. כתובות Mullvad משותפות למשתמשי VPN רבים, כך שהתאמה אליהן לבדה אינה הוכחה.
- לבדוק גם ביומני הכניסה של Entra ID ו‑ Okta אם הופיע בהם סוכן המשתמש של TruffleHog.
- אם נמצאה כניסה: קודם לבטל את הסשנים הפעילים של התפקיד, כי אישור זמני שכבר הונפק ממשיך לפעול גם אחרי החלפת הסודות. אחר כך להחליף את כל מה שהתפקיד יכול היה לקרוא: סודות ב‑ Secrets Manager, פרמטרים ב‑ SSM, משתני Lambda וסקריפטי אתחול.
- מי שחיבר את Qubole במפתחות גישה קבועים צריך לבדוק את השימוש בהם מ‑ 1 באוקטובר ולהחליף אותם.
למקור הידיעה ולקריאה נוספת לחצו כאן
