צינורות פיתוח תוכנה מציעים לפושעי סייבר גישה 'חופשית' לענן, מקומית

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

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

ב-Black Hat USA ביום רביעי, 10 באוגוסט, יעלו לבמה Iain Smart וויקטור Gazdag מחברת הייעוץ האבטחה NCC Group במהלך "RCE-as-a-Service: לקחים שנלמדו מ-5 שנים של התפשרות CI/CD Pipeline בעולם האמיתי", כדי לדון בשורה של התקפות מוצלחות של שרשרת האספקה ​​שהם ביצעו בצינורות ייצור CI/CD עבור כמעט כל חברה שהחברה בדקה.

קבוצת NCC פיקחה על כמה עשרות פשרות מוצלחות של יעדים, החל מעסקים קטנים ועד חברות Fortune 500. בנוסף ל באגי אבטחה, החוקרים אומרים כי שימוש לרעה חדשני בפונקציונליות המיועדת בצינורות אוטומטיים אפשרו להם להמיר צינורות משירות מפתח פשוט לביצוע קוד מרחוק (RCE)-as-a-service.

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

טרה סילס, העורכת המנהלת של Dark Reading לחדשות, ישבה עם ויקטור גזדג, יועץ האבטחה המנהל של NCC Group, כדי לברר עוד.

טרה כלבי ים: מהן כמה מחולשות האבטחה הנפוצות יותר בצינורות CI/CD, וכיצד ניתן לנצל אותן לרעה?

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

1) אישורים מקודדים במערכת בקרת גרסאות (VCS) או ניהול בקרת מקור (SCM).

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

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

2) תפקידים מתירניים מדי.

למפתחים או לחשבונות שירות יש לעתים קרובות תפקיד המשויך לחשבונות שלהם (או יכולים להניח כזה) שיש לו יותר הרשאות מהנדרש כדי לבצע את העבודה הנדרשת.

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

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

3) היעדר ביקורת, ניטור והתראה.

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

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

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

VG: כמה התקפות בחדשות הקשורות להתקפות CI/CD או צינור כוללות:

• התקפה של CCleaner, מרץ 2018
• Homebrew, אוגוסט 2018
• אסוס ShadowHammer, מרץ 2019
• הפרת צד שלישי של CircleCI, ספטמבר 2019
• השמש, דצמבר 2020
• תסריט להעלאת bash של Codecov, אפריל 2021
• TravisCI גישה לא מורשית לסודות, ספטמבר 2021

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

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

TS: מהן חלק מתוצאות ההתקפה שחברות עלולות לסבול אם יריב יצליח לחתור תחת צינור CI/CD?

VG: תוצאות התקיפה יכולות לכלול גניבת קוד מקור או נתונים אינטלקטואליים, כניסה אחורית לאפליקציה שנפרסת לאלפי לקוחות (כמו SolarWinds), השגת גישה (ומעבר חופשי בין) סביבות מרובות כגון פיתוח וייצור, הן במקום והן ב- ענן, או שניהם.

TS: כמה מתוחכמים צריכים היריבים להיות כדי להתפשר על צינור?

VG: מה שאנחנו מציגים ב-Black Hat הן לא פגיעויות של יום אפס (למרות שמצאתי כמה פגיעויות בכלים שונים) או כל טכניקה חדשה. פושעים יכולים לתקוף מפתחים באמצעות דיוג (חטיפת הפעלה, עקיפת אימות רב-גורמי, גניבת אישורים) או צינור ה-CI/CD ישירות אם הוא אינו מוגן ופונה לאינטרנט.

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

TS: עד כמה נפוצים סוגי התקפות אלה וכמה רחב של משטח התקפה מייצגים צינורות CI/CD?

VG: ישנן מספר דוגמאות להתקפות בעולם האמיתי בחדשות, כאמור. ואתה עדיין יכול למצוא, למשל, Jenkins מופעים עם Shodan באינטרנט. עם SaaS, פושעים יכולים למנות ולנסות להפעיל סיסמאות בכוח כדי לקבל גישה, מכיוון שאין להם אימות רב-גורמי מופעל כברירת מחדל או הגבלות IP, והם פונים לאינטרנט.

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

לצינורות יש בדרך כלל גישה לרשת למספר סביבות (שלא כדאי להם), ויש להם גישה למספר אישורים עבור כלים וסביבות שונות. הם יכולים לשמש כגשר בין On Prem לענן, או מערכות ייצור ובדיקה. זה יכול להיות משטח התקפה רחב מאוד והתקפות יכולות להגיע ממספר מקומות, אפילו כאלה שאין להם שום קשר לצינור עצמו. ב-Black Hat, אנו מציגים שני תרחישים שבהם התחלנו במקור עם בדיקת יישומי אינטרנט.

TS: מדוע צינורות CI/CD נשארים נקודה עיוורת ביטחונית עבור חברות?

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

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

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

TS: מהן כמה שיטות עבודה מומלצות לחיזוק האבטחה של צינורות?

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

TS: האם יש מחשבות נוספות שתרצה לחלוק?

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