איך Red Agent של Wiz ניצל חולשה ב-GitHub Actions והגיע ל-Jira הפנימי של Snowflake

גם העובדה שהזרימה הופעלה רק באירוע

issues: opened

ב-commit צוין “Copilot Autofix powered by AI” כשותף לכתיבה, והבדיקה בסיוע ה-AI לא התריעה על הבעיה. עם זאת, הראיות הזמינות אינן קובעות אם Copilot יצר את השינוי הלא בטוח או רק היה מעורב בו ובדק אותו מבלי לזהות את ההזרקה. לכן הניסוח המדויק הוא ש-Copilot היה קשור לשינוי ולא הצליח לזהות את הסיכון — לא שהוכח בוודאות שהמודל כתב את הקוד.

איך Red Agent מצא את החולשה

Red Agent סרק את הארגון הציבורי של Snowflake ב-GitHub וחיפש דפוסי CI/CD מסוכנים. הוא זיהה שזרימת ה-Jira מעבירה נתוני Issue שאינם מהימנים לתוך בלוק run: של Shell, והסיק שכותרת ציבורית שעוצבה במיוחד תוכל להוביל להרצת פקודות שרירותיות על ה-runner של GitHub Actions.

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

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

איזו גישה נחשפה

לזרימת העבודה שנפרצה הייתה גישה להגדרות Jira הפנימי של Snowflake, ובהן כתובת ה-Jira, כתובת הדוא״ל של המשתמש ואסימון API. האסימון שאוחזר היה משויך ל-qa@snowflake.net; Wiz השתמשה בו כדי להתחבר לפורטל ה-Jira הפנימי ולבחון את היקף החשיפה.

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

הרכיב שנפגע היה האוטומציה של ה-CI/CD במאגר. לא דווחה גרסה מופצת של Snowflake Connector for .NET שנפגעה, משום שהבעיה הייתה בזרימת GitHub Actions ולא בקוד זמן הריצה של המחבר.

התגובה של Snowflake

Wiz דיווחה על הבעיה ב-23 ביוני. Snowflake תיקנה את זרימת העבודה באותו יום וסובבה את פרטי הגישה ל-Jira שנחשפו ביום שלאחר מכן.

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

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

הלקח לאבטחת CI/CD

המסקנה חורגת מהמקרה של Snowflake או מ-Copilot. כותרות של Issues ושל Pull Requests, שמות ענפים ותגובות משתמשים צריכים להיחשב קלט עוין בכל פעם שהם עוברים לתוך פקודת Shell.

תכנון בטוח יותר של זרימות עבודה כולל:

• העברת ערכים לא מהימנים דרך משתני סביבה במקום אינטרפולציה ישירה שלהם בסקריפטים של run:.
• שימוש בכלים מובנים כמו jq ליצירת JSON, במקום הרכבת מחרוזות Shell ידנית.
• ציטוט ואימות של נתונים בגבול שבין הקלט לבין ה-Shell.
• הימנעות מהצבת פרטי גישה בשלבים שמעבדים תוכן בשליטת התוקף, ככל שניתן.
• בדיקה של שינויי אבטחה שנוצרו בעזרת AI באותה קפדנות שבה נבדק קוד שנכתב בידי אדם.

זהו מקרה ממוקד שממחיש אתגר אבטחה חדש: מערכת AI אחת יכולה לפספס שינוי מסוכן ב-CI/CD, וסוכן תקיפה אוטונומי אחר יכול למצוא אותו ולאמת את ההשפעה בתוך ימים. אוטומציה עשויה להאיץ גם את התיקון וגם את הניצול — אבל היא אינה מחליפה ביקורת בלתי תלויה.