פריצות לחשבונות GitHub: קמפיין wfx-loot גונב סודות

מהו קמפיין wfx-loot ב-GitHub?

wfx-loot הוא קמפיין שבו תוקף משתמש בפרטי גישה גנובים ל-GitHub כדי לדחוף workflow זדוני למאגרים שהחשבונות האלה יכולים לכתוב אליהם, וגונב סודות של GitHub Actions ופרטי גישה לענן ^[1]. Aikido Security, שדיווחה עליו ראשונה, קראה לו על שם השם שהתוקף עצמו נתן לתוכנה הזדונית (“wfx”) והמילה שהוא משתמש בה לסודות גנובים (“loot”) ^[1]. גם SafeDep מייחסת ל-Aikido את הדיווח הראשון ^[5].

StepSecurity מכנה את אותו גנב “wfx” ומדגישה נקודה מרכזית: התוקף אינו מנצל באג ב-GitHub Actions ^[2]. במקום זאת הוא משתמש בטוקנים תקפים של חשבונות אמיתיים של מפתחים ובוטים, פותח בקשות משיכה ודוחף commits כפי שמפתח היה עושה ^[2][4].

Aikido מאמינה שהמטרה העיקרית היא סודות CI ולא התפשטות דרך חבילות תוכנה, אף שה-payload הגיע לפחות לחבילת Packagist אחת ולחבילת Go אחת דרך מפעילי פרסום אוטומטיים ^[1]. BleepingComputer, בהסתמך על הניתוח של Aikido, מדווח שחלק מהחשבונות שנפרצו שייכים לארגונים גדולים ^[3].

עד כמה גדולה מתקפת wfx-loot?

Aikido סופרת 4,837 חשבונות שנפרצו ופתחו בקשות משיכה לבדיקה ב-61,764 מאגרים, כשהגנב רץ בלפחות 1,806 מאגרים ^[1]. המספרים שונים מעט בין חוקרים כי כל אחד חיפש ב-GitHub בזמן אחר בעוד הקמפיין עדיין פעיל.

• Aikido: 4,837 חשבונות, 61,764 מאגרים; 10,431 בקשות משיכה נכנסו למאגרים שאינם בבעלות החשבון; 92% עדיין פתוחות; לפחות 50 משתמשים שנפרצו מפרסמים חבילות ל-npm, Go, Packagist, PyPI או crates ^[1].
• Aikido (נתון מסכם): לפחות 1,835 מאגרים הריצו את ה-payload ופרטי גישה נלקחו; BleepingComputer משתמש במספר הזה ^[1][3].
• StepSecurity: יותר מ-63,000 בקשות משיכה לבדיקה נכון ל-07:40 UTC ב-12 בנובמבר, כ-90% מהן עדיין פתוחות ^[2].
• SafeDep: 8,093 מאגרים קיבלו commits זדוניים בין 10 ל-12 בנובמבר, נתון שכפי ש-SecurityWeek מציין אינו אומר בהכרח שהגנב הורץ ^[5][4].

Aikido מזהירה שספירת ההרצות שלה עשויה להמעיט בהיקף ההשפעה, כי יומני ההרצה נמחקו במאגרים שנפגעו ^[1].

איך פועל גנב wfx-loot?

לכל מאגר שטוקן גנוב יכול לכתוב אליו, התוקף בודק, דוחף את ה-payload ואז מנקה תוך כדקה בערך ^[1].

1. בדיקה: בקשת משיכה בשם “docs: dependency audit notes” מענף בשם wfx-docs מוסיפה קובץ הערות זעיר. “בקשת המשיכה אינה עושה דבר בעצמה”, אומרת StepSecurity; היא רק מראה שלטוקן יש הרשאת כתיבה ^[2][4].
2. Payload: סקריפט shell של כ-1,500 שורות מגיע באחת משלוש דרכים: מוזרק ל-workflow קיים (“ci: refresh build cache”), כסקריפט בתוספת hook מסוג npm postinstall (“chore: add ci helper”), או כ-workflow חדש בענף חד-פעמי chore/ (“chore: add dependency audit workflow”) ^[1].
3. ניקוי: התוקף מחזיר את השינוי לאחור ומוחק את הרצת ה-workflow ואת היומנים שלה ^[1]. מספר הרצה חסר הוא לעיתים קרובות העקבה היחידה ^[1].

הסקריפט אוסף סודות וטוקנים של GitHub Actions, את כל סביבת ה-runner, קובצי פרטי גישה של AWS, Azure, Google Cloud, Docker, Kubernetes, npm, PyPI, SSH ועוד, היסטוריות shell ומפתחות לספקי בינה מלאכותית ולכלי מפתחים ^[1][3]. הוא אפילו קורא את הזיכרון של תהליכים שרצים על ה-runner ^[1][4]. Aikido מצאה שההעתקים שניתחה שלחו את הנתונים הגנובים רק באמצעות HTTP POST לשרתים בשליטת התוקף ^[1]. StepSecurity ראתה אחר כך שינוי: מסביבות 05:30 UTC ב-12 בנובמבר, העתקים חדשים שלחו נתונים רק דרך Telegram, ולכן חסימה של כתובות השרתים שפורסמו לבדה כבר אינה עוצרת אותם ^[2].

למה החלפת סודות אינה מספיקה?

כי הגנב מנסה להטמין דלתות אחוריות ששורדות החלפת פרטי גישה ^[1][2]. Aikido מתארת שלושה טריקים להתמדה ^[1]:

• בדיקות סטטוס מזויפות: Aikido אומרת שהוא מפרסם בדיקות “הצלחה” מזויפות בשמות הבדיקות הנדרשות של המאגר, מה שיכול לעקוף שערי מיזוג של הגנת ענפים ^[1]. StepSecurity מצאה שהתכונה הזו כבויה בכל 101 הדגימות שבדקה ^[2].
• שכתוב מדיניות אמון ב-AWS: הוא יכול להגדיר את מדיניות האמון של תפקיד כך שתאפשר כל חשבון AWS ^[1].
• הזרקת זהות מאוחדת ב-Azure: הוא יכול להוסיף פרטי גישה מאוחדים בשם wfx-ci-… ליישומי Azure AD, כך ש-workflows במאגר שנפרץ יכולים להזדהות בלי סוד שמור ^[1].

הוא יכול גם להפיק טוקני OIDC של GitHub ולהחליף אותם בהפעלות של AWS, Google Cloud ו-Azure, להתחבר לשרשרת תפקידי IAM אחרים וליצור מפתחות גישה ארוכי טווח ב-AWS ^[1][3]. לכן StepSecurity אומרת “הסירו את ההתמדה, כי החלפה לבדה אינה עושה זאת” ^[2].

איך בודקים אם המאגרים שלי ב-GitHub נפגעו?

חפשו את בקשת המשיכה לבדיקה ואת הודעות ה-commit של התוקף מאז 10 בנובמבר, ואז חפשו פערים במספרי הרצה של workflow ^[2][1].

1. חפשו בבקשות משיכה “docs: dependency audit notes” וענפים בשם wfx-docs או chore/ ואחריו שמונה תווים ^[1][2].
2. חפשו בקומיטים מאז 10 בנובמבר את “ci: refresh build cache”, “ci: restore”, “ci: cleanup”, “chore: add ci helper” ו-“chore: add dependency audit workflow” ^[2].
3. לכל תוצאה, פתחו את לשונית Actions וחפשו מספר הרצה חסר מיד אחרי ה-commit; StepSecurity מכנה זאת הסימן האמין ביותר לכך שהגנב רץ ^[2].
4. שימו לב איזה חשבון דחף את ה-commits: הטוקנים של אותו חשבון גנובים ^[2]. אם קיימת בקשת משיכה לבדיקה, החשבון נפרץ גם אם לא רץ payload ^[1].

אל תסתמכו על ארטיפקטים חסרים. Aikido אומרת שהיעדר ארטיפקטים של wfx-loot, רשומות מטמון של wfx- או סיכומי שלבים מיוחדים אינו אומר שנתונים לא נלקחו, כי ערוצים אלה כובו בקמפיין הזה ^[1]. Aikido גם מציינת שייתכן שה-payload מוצב במאגרים פרטיים לצד ציבוריים ^[1].

מה לעשות אם הגנב רץ?

הניחו שכל סוד ותפקיד ענן שה-workflow שנפגע יכול היה להגיע אליהם נפרצו, החליפו אותם ואז חפשו התמדה ^[1][2].

• החליפו: כל סוד של מאגר, סביבה וארגון שה-job יכול היה להגיע אליו, לא רק אלה שה-workflow מציין בשמם; טוקני פרסום של npm, PyPI ואחרים; ומפתחות ענן שנשמרו כסודות ^[2].
• בדקו חבילות: חפשו גרסאות חבילה שפורסמו אחרי ה-commit הזדוני ^[2].
• AWS: חפשו מדיניות אמון שמאפשרת כל principal של AWS, מפתחות גישה של IAM שנוצרו מאז 10 בנובמבר, והפעלות CloudTrail שמתחילות ב-wfx- ^[2].
• Azure: מחקו פרטי גישה של זהות מאוחדת בשם wfx-ci-* ברישומי יישומים ^[2].
• Google Cloud, Vault, Kubernetes: סקרו הפקת טוקנים והתחברויות שבוצעו עם טוקני כניסה של GitHub Actions ^[2].
• GitHub: מחקו ענפים שנותרו, סגרו בקשות משיכה לבדיקה, בדקו שדבר לא מוזג על בדיקה מזויפת, וביטלו את הטוקנים, ההרשאות של OAuth ומפתחות ה-SSH של החשבון ^[2].
• טוקנים, לפי התיעוד של GitHub: סקרו את טוקני הגישה האישיים שלכם תחת Settings, Developer settings ומחקו כאלה שאינכם מכירים או זקוקים להם; GitHub ממליצה על טוקנים מדויקים (fine-grained), על ההרשאות המינימליות הנחוצות בלבד ועל תאריך תפוגה, כי טוקן קלאסי יכול לגשת לכל מאגר שאתם יכולים לגשת אליו ^[6].

ה-hook של npm רץ גם על מכונות של מפתחים: מי שהריץ npm install בחלון הקצר הריץ את הגנב מקומית וצריך להחליף גם את פרטי הגישה שלו ^[2]. SecurityWeek מסכם את העצה של כמה חברות אבטחה: לבטל טוקנים שנפרצו, להחליף סודות חשופים ולבדוק שינויי ענן לא מורשים ^[4]. לגבי חשבונות בוט, StepSecurity מציעה גם לבדוק אם הם בכלל זקוקים להרשאה לעקוף הגנת ענפים ^[2]. הגנת כניסה חזקה מקשה על קמפיינים של חשבונות גנובים; ראו אימות דו-גורמי מוסבר: איזו שיטת 2FA בטוחה ביותר?.

אילו חבילות הושפעו?

Aikido מציינת חבילת Packagist ומודול Go שקלטו את ה-payload דרך פרסום אוטומטי ^[1].

• Packagist: digitalelvis/neuronai-studio גרסה 3.14.3; Aikido אומרת להתייחס לכל מכונה שהתקינה או פתחה אותה כאל נפרצת ^[1].
• Go: github.com/onuragtas/docker-env v1.0.278 ו-v1.0.280; ה-payload נמצא רק בקובץ workflow של GitHub Actions, קוד המקור של Go והקבצים הבינאריים לא השתנו, ובניות Go לעולם אינן מריצות קובצי workflow, אך Aikido עדיין ממליצה להסיר את הגרסאות האלה ^[1].

המספרים שונים: SafeDep אומרת ששלוש חבילות ב-Packagist וב-proxy של מודולי Go נושאות את ה-payload, ו-SecurityWeek מזכיר גרסאות של שני מודולי Go ^[5][4]. SafeDep מוסיפה שה-payload לא רץ אצל צרכנים רגילים שמתקינים את החבילות האלה עם composer require או go get ^[5]. בדקו את הרשימה העדכנית של כל חוקר לפני שאתם מסתמכים על אחת מהן.

מי עומד מאחורי wfx-loot ואיך השיגו את הטוקנים?

אף אחד מהדיווחים שמוזכרים כאן אינו מזהה את התוקף, ו-StepSecurity אומרת שלא קבעה איך הטוקנים הושגו ^[2][4].

StepSecurity מצאה 173 בקשות משיכה לבדיקה, מ-19 חשבונות, שנעשו באמצעות טוקנים שהונפקו ליישום GitHub של Fly.io; היא אמרה שלא יכלה לקבוע איך הושגו ושאין לה ראיות לכך שתשתית Fly.io נפרצה ^[2][4].

Aikido מצאה חפיפה עם חשבונות שנפגעו בגל GhostAction של אוקטובר, וראתה את wfx-loot מוזרק לקובצי workflow של GhostAction ביותר מ-100 מאגרים, אך העריכה ששני הקמפיינים נפרדים ומופעלים ככל הנראה על ידי גורמים שונים, כי פרטי גישה גנובים מגיעים לא פעם לכמה קבוצות ^[1]. היא גם הבחינה בהערות בשפה האינדונזית בחלק מהגרסאות החדשות יותר של התוכנה הזדונית ^[1]. שמירה זהירה של טוקנים חשובה כאן; מנהלי סיסמאות מוסברים: איך הם עובדים והאם הם בטוחים מכסה את היסודות.