דליפת מפתחות Stripe סיכנה 688,363 רשומות לקוחות

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

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

מי פרסם את המאגר?

החומרים יוחסו לגורם האיום Satanic, שלפי הדיווחים פרסם אותם ב־pwnforums ב־18 באוגוסט. הפרסום הוצע להורדה ולא למכירה.

עם זאת, המספרים שדווחו לגבי הפרסום הראשוני אינם זהים לנתונים שאומתו בהמשך. ניתוח קשור של Hudson Rock תיאר 669 תיקיות של ספקים, 1,033 מפתחות API שנפגעו, וארכיון שלטענת המפרסם גודלו 33 ג׳יגה־בייט.

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

Hudson Rock דיווחה גם על פער בין גודל הפרסום לבין קובץ ההורדה: בפורום הוצג ארכיון בנפח 33 ג׳יגה־בייט, בעוד שהקובץ שניתן להורדה היה בגודל של כ־2.37 ג׳יגה־בייט. הפער עולה בקנה אחד עם האפשרות שקיימים חומרים נוספים שלא פורסמו, אך אינו מוכיח זאת.

מדוע החוקרים לא מגדירים זאת כפריצה לתשתית של Stripe?

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

הדרכים האפשריות שבהן המפתחות נחשפו כוללות:

• יומנים של תוכנות לגניבת מידע, המכונות infostealers
• מפתחות שנשמרו ב־commits של קוד ציבורי
• קובצי .env חשופים
• גיבויים לא מאובטחים
• יומני CI/CD — תהליכי בנייה, בדיקה ופריסה אוטומטיים
• שרתי אינטרנט שהוגדרו באופן שגוי
• סריקה אוטומטית של משתני סביבה וסודות שלא הוגנו כראוי

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

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

מה אפשר לעשות באמצעות מפתח פעיל יחיד?

החוקרים דיווחו שמפתח פעיל אחד הספיק כדי לגשת לרשימת הלקוחות של בית עסק, ליצור Payment Link מזויף ולבצע חיוב בדיקה בתוך 17 שעות.

ההדגמה ממחישה מדוע יש להתייחס למפתח סודי פעיל ורחב־הרשאות כאירוע אבטחה מיידי. תוקף אינו חייב לפרוץ ל־Stripe אם המפתח שכבר בידיו מאפשר גישה לנתוני לקוחות ולפעולות תשלום.

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

מדוע סריקה של GitHub אינה מספיקה?

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

בדיווח נפרד נאמר כי החוקרים זיהו יותר מ־50,000 סודות של Stripe בקוד ציבורי, ביומני GitHub Actions ובשרתים שהוגדרו באופן שגוי. המספר הזה מתאר את בעיית החשיפה הרחבה יותר, ולא בהכרח מפתחות שאומתו כחלק ממאגר 18 באוגוסט.

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

מה בתי עסק המשתמשים ב־Stripe צריכים לעשות עכשיו?

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

1. לבטל או להחליף מיד מפתחות סודיים פעילים שעלולים להיחשף. מחיקת קובץ או רשומה ממאגר אינה מבטלת את המפתח.
2. לבדוק את פעילות ה־API והחשבון ב־Stripe ולחפש כתובות IP לא מוכרות, גישה לרשימות לקוחות, ייצוא נתונים, יצירת Payment Links, ניסיונות חיוב, החזרים ופעילות העברות חריגה.
3. לאמת את פרטי חשבון הבנק שאליו מועברים כספים ואת השינויים האחרונים בהעברות. במידת הצורך, יש להגביר את הניטור או להוסיף בקרות זמניות להעברות.
4. להחליף מפתחות רחבי־הרשאות במפתחות מוגבלים, שמאפשרים רק את פעולות ה־API שהיישום באמת צריך.
5. להעביר את הסודות למערכת ניהול סודות ייעודית ולהסיר אותם מקוד המקור, מקובצי סביבה, מיומנים ומגיבויים לא מאובטחים.
6. לחפש חשיפות גם במאגרים היסטוריים, ביומני CI/CD, בארטיפקטים, בשרתים ובגיבויים — ולא רק בקוד הציבורי העדכני.

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