סוכן ה-AI של Wiz פרץ לבד ל-Jira של Snowflake והצית מחלוקת
Red Agent של Wiz גילה וניצל אוטונומית חולשת GitHub Actions במאגר של Snowflake וחדר ל-Jira הפנימי. GitHub חולקת על תפקיד Copilot בסיפור.
חברת אבטחת הענן Wiz, מהיוניקורנים הבולטים שצמחו בישראל, פרסמה השבוע מחקר שנשמע כמו תסריט: סוכן ה-AI ההתקפי שלה, Red Agent, איתר לבדו חולשת GitHub Actions באחד המאגרים הציבוריים של Snowflake, ניצל אותה ללא כל התערבות אנושית, וחדר בהצלחה למופע ה-Jira הפנימי של ענקית הדאטה. החולשה הייתה חיה חמישה ימים בלבד לפני שסוכן אוטומטי מצא, אימת וניצל אותה. ואז הגיע החלק השנוי במחלוקת: השאלה מי בכלל כתב את הקוד הפגיע.
מה בדיוק קרה: מחולשה במאגר ציבורי ועד Jira פנימי
לפי הפרסום של Wiz בין ה-17 ל-19 באוגוסט, Red Agent הוא סוכן תקיפה אוטונומי שסורק נכסים חשופים ומחפש נתיבי חדירה, בדומה לצוות red team אנושי אבל בקצב של מכונה. במקרה הזה הסוכן זיהה קונפיגורציה פגיעה ב-workflow של GitHub Actions באחד המאגרים הציבוריים של Snowflake, בנה לבדו שרשרת ניצול, ובסופה השיג גישה למופע ה-Jira הפנימי של החברה.
הנקודה שהופכת את הסיפור מעוד גילוי חולשה לאירוע מכונן היא ציר הזמן. חלון של חמישה ימים בין הכנסת הקוד הפגיע לניצולו נחשב עד לא מזמן קצר מאוד. כשסוכנים אוטונומיים סורקים את GitHub ברציפות, חלון החשיפה האפקטיבי של טעות בקוד ציבורי מתכווץ מחודשים לימים, ובעתיד כנראה לשעות.
המחלוקת עם GitHub: מי אשם, אדם או Copilot?
בגרסה המקורית של המחקר טענה Wiz כי GitHub Copilot Autofix, הכלי שאמור לסקור ולתקן קוד אוטומטית, אישר את שינוי הקוד שהוביל לחולשה מבלי להבחין בבעיה הקריטית. GitHub לא נשארה חייבת: בדיקה פנימית שערכה העלתה, לטענתה, שהקוד הפגיע נכתב על ידי אדם וכלל לא נסקר על ידי Copilot. בעקבות זאת ריככה Wiz את הניסוח בפרסום.
אבל גם אחרי הריכוך, שלוש עובדות נותרו על כנן: החולשה הייתה אמיתית, הניצול האוטונומי היה אמיתי, והוויכוח על תפקידו של Copilot חשף בעיה שאין לה עדיין פתרון טוב: ייחוס (provenance). כשקוד עובר בין מפתחים אנושיים, כלי השלמה, סוכני תיקון אוטומטיים ו-pipelines של CI, כמעט בלתי אפשרי לשחזר מי בדיוק הכניס את השורה הבעייתית ומי היה אמור לתפוס אותה.
אנחנו נכנסים לתקופה שבה כל תקרית אבטחה תתחיל בשאלה: איזה חלק מהקוד כתב אדם, איזה חלק כתב מודל, ומי חתם על הסקירה. הכלים לענות על זה פשוט לא קיימים עדיין ברוב הארגונים.
למה זה משנה במיוחד לחברות ישראליות
לסיפור הזה יש רלוונטיות כפולה לישראל. ראשית, Wiz עצמה היא סיפור הצלחה ישראלי, והמחקר הזה ממצב אותה בחזית תחום חדש: סוכני AI התקפיים לצרכי בדיקות חדירה. שנית, וחשוב יותר, האקוסיסטם הישראלי בנוי על אלפי סטארטאפים עם מאגרים ציבוריים ב-GitHub, שרבים מהם מתחזקים workflows של GitHub Actions בלי סקירת אבטחה שוטפת.
המשמעות המעשית: אם עד היום ההנחה הייתה שחולשה במאגר ציבורי קטן ואנונימי לא תימצא כי אף תוקף לא יטרח לחפש, ההנחה הזאת מתה. סוכן אוטונומי לא מתעדף לפי גודל החברה, הוא סורק הכל. גם מאגר של סטארטאפ בן חמישה עובדים בתל אביב נמצא באותה רשימת סריקה כמו Snowflake.
אם יש לכם GitHub Actions במאגרים ציבוריים: בדקו הרשאות של GITHUB_TOKEN, הימנעו מ-pull_request_target עם checkout של קוד זר, ונעלו secrets ל-environments עם אישור ידני. אלו שלושת הווקטורים הנפוצים ביותר לניצול workflows.
הצעדים שכדאי לעשות עכשיו
- מיפוי כל ה-workflows במאגרים ציבוריים של הארגון, כולל מאגרים ישנים ונטושים שאיש לא נוגע בהם
- צמצום הרשאות ברירת המחדל של טוקנים ב-Actions לקריאה בלבד, והרחבה נקודתית רק היכן שנדרש
- הפרדה בין סביבת ה-CI הציבורית למערכות פנימיות כמו Jira ו-Confluence, כך שטוקן שדלף לא פותח דלת פנימה
- תיעוד provenance: מדיניות ברורה שמסמנת אילו שינויי קוד נכתבו או נסקרו על ידי כלי AI, לקראת היום שבו תצטרכו לשחזר תקרית
- הרצת בדיקות חדירה תקופתיות שמדמות תוקף אוטונומי, לא רק בודק אנושי שעובד לפי checklist
מה הלאה: מרוץ חימוש בין סוכנים
המחקר של Wiz הוא תמונת מקדימה של מה שמגיע לשני הצדדים של המתרס. סוכני תקיפה אוטונומיים יהפכו לכלי סטנדרטי אצל צוותי red team, ובמקביל, וזה החלק המדאיג, אצל תוקפים אמיתיים שלא מחכים לאישור לקוח. התשובה ההגיונית היא סוכני הגנה שסורקים את הקוד שלכם באותו קצב, וסביר שנראה גל של מוצרים כאלה, כולל מבית סטארטאפים ישראליים שכבר פועלים בתחום.
והמחלוקת עם GitHub לא הולכת לשום מקום. ככל שיותר קוד נכתב, נסקר ומתוקן על ידי מודלים, שאלת האחריות תעבור מדיון תיאורטי לחוזים, לביטוחי סייבר ולבתי משפט. מי שיתחיל לתעד כבר עכשיו מי כתב מה, יגיע מוכן.
שאלות נפוצות
מה זה Red Agent של Wiz?
Red Agent הוא סוכן AI התקפי של חברת אבטחת הענן Wiz, שמדמה צוות תקיפה אנושי: הוא סורק נכסים חשופים, מאתר חולשות, בונה שרשראות ניצול ומאמת אותן באופן אוטונומי לחלוטין. במקרה של Snowflake הוא ניצל חולשת GitHub Actions וחדר למופע Jira פנימי ללא התערבות אנושית.
האם GitHub Copilot אשם בחולשה אצל Snowflake?
זה שנוי במחלוקת. Wiz טענה בתחילה ש-Copilot Autofix אישר את שינוי הקוד הפגיע, אך GitHub ערכה בדיקה פנימית וטוענת שהקוד נכתב על ידי אדם ולא נסקר על ידי Copilot. בעקבות זאת Wiz ריככה את הניסוח, אבל החולשה עצמה והניצול האוטונומי אינם במחלוקת.
איך מגנים על GitHub Actions מפני ניצול?
הצעדים המרכזיים: צמצום הרשאות GITHUB_TOKEN לקריאה בלבד, הימנעות מ-pull_request_target עם checkout של קוד לא מהימן, נעילת secrets ל-environments עם אישור ידני, והפרדת ה-CI ממערכות פנימיות. מומלץ גם לסרוק מאגרים ישנים ונטושים שעדיין מכילים workflows פעילים.
דרגו את הכתבה
הדירוג עוזר לנו לדעת מה שווה לכם.
תגובות