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

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

במהלך המחקר האחרון שלנו על פגיעויות אצל ספקי שירותי ענן, גילינו שלושה דפוסי תצורה שגויה שהתעלמו מהם, החושפים סביבות ענן לסיכוני התקפות בשרשרת האספקה של CI/CD. תצורות שגויות אלו מאפשרות לשחקנים זדוניים לבצע תנועה רוחבית (lateral movement) ולתפעל קוד מקור כדי לחבל בתוצרים (artifacts) של הארגון ולהפיץ קוד זדוני לשירותים פנימיים או ללקוחות חיצוניים.

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

מדוע צנרות (pipelines) של CI/CD הם יעדים אטרקטיביים לתוקפים?

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

צנרת CI/CD כוללת בדרך כלל את השלבים הבאים:

• קוד נכתב על ידי מפתחים ומועלה (committed) למערכת בקרת גרסאות, כגון Git.

• הקוד נבנה ונבדק אוטומטית באמצעות כלי אינטגרציה מתמשכת (⁦CI⁩), כמו ⁦Jenkins and CircleCI⁩.

• הקוד הבנוי נארז באופן אוטומטי ופרוס לסביבת שלב לבדיקה ואימות.

• אם הבדיקות והאימות מצליחים, הקוד נפרס לייצור או מאוחסן במאגר החפצים לצורך משיכה ושימוש בשירותים.

צנרות CI/CD הן יעדים פופולריים לתוקפים מכיוון שהן מכילות רכיבים מרכזיים רבים המשפיעים על שרשרת אספקת התוכנה של הארגון. טכנולוגיה אחת שנפגעת בצנרת עלולה לפיכך לסכן סביבות ומנויים רבים. לדוגמה, תוקף יכול להשתלט על מאגר רישום קונטיינרים (container registry) בסביבת ענן, ולאחר מכן להפיץ אימג'ים (container images) זדוניים לשירותים הפנימיים של החברה או ללקוחות חיצוניים דרך התוכנה שלה.

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

תצורות שגויות נפוצות ב-CI/CD וכיצד להימנע מהן

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

בהינתן שתוקפים מנצלים לעתים קרובות פגמי אבטחה מרובים כדי לסכן רכיב ⁦CI/CD⁩, רק טיפול באחת מהבעיות הבאות יכול להפחית באופן משמעותי את משטח ההתקפה של הארגון שלך.

1. גישת יתר לרישומי קונטיינרים (Container Registries)

רישומי קונטיינרים נפרסים בדרך כלל בסביבות ענן מבוססות קונטיינרים כדי לאחסן אימג'ים המשמשים בשלבי הבנייה והייצור. ניתן למשוך אימג'ים פרטיים אלו באמצעות אישורי הרישום, שנמצאים לעיתים קרובות במערכת הקבצים של המופעים (instances) המכולתיים.

אם תוקף מצליח להשתלט על מופע כזה, הוא יכול להשיג את אישורי הרישום ממערכת הקבצים ולגשת לכל האימג'ים השמורים ברישום.

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

זרימת התקפה לדוגמה:

• תוקף משתלט על שרת הפונה לאינטרנט בתוך סביבת קונטיינרים

• הוא מוצא אישורי רישום קונטיינרים במערכת הקבצים

• הוא משתמש באישורים אלו כדי למשוך אימג'ים פרטיים נוספים מהרישום

• הם מדביקים את התמונות בקוד זדוני

פתרון: גישה בעלת הרשאות מינימליות (Least Privilege) לרישומי קונטיינרים

ודא שפתרונות הרישום שלך אוכפים בקרות גישה והגדרות היקף מתאימות. בעוד שרוב ספקי הענן מספקים ניהול הרשאות רישום באמצעות זהויות IAM, ספקי SaaS מציעים זאת בדרך כלל דרך ממשק ה-Web או ה-API של השירות.

הקצה הרשאות קריאה בלבד או כתיבה בלבד לתפקידים, והגבל את ההרשאות למאגרים ולאימג'ים הנדרשים בלבד. לדוגמה, מפתחים אינם זקוקים להרשאות כתיבה, שכן הם לא אמורים לדחוף (push) אימג'ים ישירות לרישום או לשירותים רצים. באשר לתפקידים עם הרשאות דחיפה, עליהם להיות מעורבים רק בשלב האחרון של צנרת ה-CI/CD כדי לדחוף את האימג'ים הסופיים לרישום.

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

⁦Case Study⁩: גישה לחשבון שירות Pod לרישום מיכל

כדי למשוך אימג'ים פרטיים, צומת Kubernetes חייב להיות בעל גישה ל-Container Registry שבו הם מאוחסנים. האישורים לרישום זה נמצאים במשאב מסוג Secret. שם הסוד מוזכר בשדה imagePullSecrets של כל הגדרת Pod.

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

זרימת התקפה לדוגמה:

• תוקף משתלט על Pod בתוך אפליקציה הפונה לאינטרנט

• הוא מוצא Token של חשבון שירות (service account) של Kubernetes במערכת הקבצים

• הוא משתמש ב-Token כדי לשלוף את הסוד של רישום הקונטיינרים מה-cluster

• הם ממנפים את האישורים כדי להביא תמונות פרטיות נוספות מהרישום

• הם מדביקים את התמונות בקוד זדוני

פתרון: הגבלת גישה והרשאות של חשבונות שירות (Service Accounts) ב-Pod

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

2. סודות נשכחים בתהליך הבנייה

סודות שנשכחו בסביבות ענן מהווים סיכון אבטחה חמור. סודות אלו, כגון מפתחות גישה לענן, סיסמאות, אישורי CI/CD ואסימוני גישה (API tokens), נותרים לעיתים קרובות בתוך תוצרי הייצור לאחר תהליכי הבנייה והפריסה.

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

זרימת התקפה לדוגמה:

• תוקף מתפשר על שרת הפונה לאינטרנט

• הם מוצאים אישורי CI/CD בקובץ .bash_history שנותרו מתהליך הבנייה של ה-OS image

• הסוד מעניק גישה לדלי אחסון (storage bucket) פנימי המכיל תוצרי ייצור המשמשים בתהליך הבנייה

• התוקף משנה את התוצרים כדי להפיץ קוד זדוני בבניות הבאות

זרימת התקפה דוגמה 2:

• תוקף מושך אימג'ים זמינים לציבור מהרישום הציבורי של החברה

• הם מוצאים סודות רגישים בקבצי ההיסטוריה של הקונטיינרים

• האימג'ים מכילים את כל הפקודות ההיסטוריות ששימשו לבנייתם, כמו גם מפתח לדלי אחסון פנימי

• דלי האחסון מכיל חפצים מוכנים לייצור המשמשים בתהליך בניית התמונות

• התוקף משנה את התוצרים בדלי כדי להפיץ קוד זדוני בבניות הבאות של האימג'ים

פתרון: סריקה מקיפה לאיתור סודות שעלולים להישכח

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

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

• היסטוריית הבש - ~/.⁦bash_history⁩ או ⁦/root/.bash_history⁩

• קובצי Linux Journal — /var/log/journal/*

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

3. נתיבי תנועה לרוחב בין ייצור וסביבות בנייה פנימיות

החיבור בין האפליקציות הפונות לאינטרנט של הארגון לבין רכיבי ה-CI/CD הפנימיים שלו יכול לספק לתוקפים את היכולת לבצע תנועה רוחבית.

במתקפת Hell's Keychain, היעדר בקרות רשת נאותות אפשר לחוקרים לגשת למאגר CI/CD פנימי. תצורה שגויה זו אינה ייחודית ל-IBM Cloud, שכן היא נצפתה אצל ספקי ענן רבים ובקרב לקוחותיהם. לדעתנו, נושא זה לעיתים קרובות אינו מקבל מספיק תשומת לב בדיונים בתעשייה ובפתרונות אבטחת ענן.

זרימת התקפה לדוגמה:

• תוקף מתפשר על שרת הפונה לאינטרנט

• הם מוצאים סודות רגישים בקובץ .⁦bash_history⁩ שהיו מתהליך הבנייה של התמונה ⁦OS⁩

• הסוד מעניק גישה לדלי אחסון פנימי

• התוקף מנסה להתחבר לדלי האחסון

• הם נכשלים עקב מדיניות משאבים מגבילה, המאפשרת חיבורים רק מהרשת הפרטית הווירטואלית (VPN) של ה-CI/CD

פתרון: בידוד נכסים קריטיים

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

במקרים של פתרונות SaaS CI/CD כמו GitHub, שבהם לא ניתן להגביל את הגישה לרשת, קריטי שלא יאוחסן אף אישור שירות או אסימון גישה באפליקציות הפונות לאינטרנט. אם תוקף יצליח להשתלט על אפליקציה כזו, הוא יוכל לעקוף את כל מגבלות הרשת ולגשת ישירות לשירות שמחזיק את קוד הייצור והתוצרים.

לבסוף, כדאי לשקול לאמץ אמצעי אבטחה כגון אימות דו-גורמי ובקרות גישה מבוססות תפקידים כדי להגן על הפתרונות ⁦SaaS⁩ ⁦CI/CD⁩ שלך.

תַקצִיר

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

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

המשך לקרוא

הצגת Azure Least Privilege: אכיפת גישה בעלת הרשאות מינימליות לסביבות Azure

Wiz מרחיבה את יכולות ה-CIEM שלה כדי לאפשר גישה בעלת הרשאות מינימליות עבור סביבות Azure.

⁦Top Security Talks⁩ מתוך ⁦AWS⁩ re:Invent 2022