גוגל הציעה SLSA כדי להגן מפני שינויים זדוניים במהלך הפיתוח

גוגל הציגה את מסגרת SLSA (Supply-chain Levels for Software Artifacts), המסכמת את הניסיון הקיים בהגנה על תשתיות פיתוח מפני התקפות המתבצעות בשלב של כתיבת קוד, בדיקה, הרכבה והפצה של מוצר.

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

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

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

  דוגמה למתקפה: "Hypocrite Commits" - ניסיון לקדם תיקונים עם נקודות תורפה לתוך ליבת לינוקס.

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

• ב. התפשרות של פלטפורמת בקרת קוד המקור.

  דוגמה למתקפה: הזרקת התחייבויות זדוניות עם דלת אחורית למאגר Git של פרויקט PHP לאחר שסיסמאות מפתחים דלפו.

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

• ג. ביצוע שינויים בשלב העברת קוד ל-build או מערכת אינטגרציה רציפה (נבנה קוד שאינו תואם לקוד מהמאגר).

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

  שיטת הגנה מוצעת: בדיקת תקינות וזיהוי מקור הקוד בשרת ה-assembly.

• ד. פשרה של פלטפורמת ההרכבה.

  דוגמה להתקפה: מתקפת SolarWinds, שבמהלכה הובטחה התקנת דלת אחורית למוצר SolarWinds Orion בשלב ההרכבה.

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

• ה. קידום קוד זדוני באמצעות תלות באיכות נמוכה.

  דוגמה להתקפה: הכנסת דלת אחורית לספריית זרם האירועים הפופולרית על ידי הוספת תלות לא מזיקה ולאחר מכן הכללת קוד זדוני באחד מהעדכונים של התלות הזו (השינוי הזדוני לא בא לידי ביטוי במאגר git, אלא היה קיים רק בחבילת MNP המוגמרת).

  שיטת הגנה מוצעת: החל רקורסיבית דרישות SLSA על כל התלות (במקרה של זרימת אירועים, הבדיקה תגלה את מכלול הקוד שאינו תואם את התוכן של מאגר Git הראשי).

• ו. העלאת חפצים שלא נוצרו במערכת ה-CI/CD.

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

  שיטת הגנה מוצעת: שליטה במקור ובשלמות החפצים (במקרה של CodeCov, ניתן היה לגלות שהתסריט של Bash Uploader שנשלח מאתר codecov.io אינו תואם לקוד ממאגר הפרויקט).

• ז. פשרה של מאגר החבילות.

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

  שיטת הגנה מוצעת: אימות שהפריטים המופצים מורכבים מקודי המקור המוצהרים.

• ח. בלבול את המשתמש להתקין את החבילה הלא נכונה.

  דוגמה להתקפה: שימוש ב-Typosquatting (NPM, RubyGems, PyPI) כדי למקם חבילות במאגרים הדומים בכתב ליישומים פופולריים (לדוגמה, coffe-script במקום coffee-script).

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

• SLSA 1 מחייב שתהליך הבנייה יהיה אוטומטי לחלוטין וייצור מטא-נתונים ("מקור") לגבי אופן בניית החפצים, כולל מידע על מקורות, תלות ותהליך הבנייה (מחולל מטא-נתונים לדוגמה לביקורת מסופק עבור פעולות GitHub). SLSA 1 אינו כולל אלמנטים של הגנה מפני שינויים זדוניים, אלא פשוט מזהה קוד ומספק מטא נתונים לניהול פגיעות וניתוח סיכונים.
• SLSA 2 - מרחיב את הרמה הראשונה על ידי דרישת שימוש בשירותי בקרת גרסאות והרכבה המייצרים מטא נתונים מאומתים. השימוש ב-SLSA 2 מאפשר לך להתחקות אחר מקור הקוד ומונע שינויים לא מורשים בקוד במקרה של שירותי בנייה מהימנים.
• SLSA 3 - מאשר שקוד המקור ופלטפורמת הבנייה עומדים בדרישות של תקנים המבטיחים יכולת ביקורת על הקוד ומבטיחים את שלמות המטא-נתונים שסופקו. ההנחה היא שמבקרים יכולים לאשר פלטפורמות כנגד דרישות התקנים.
• SLSA 4 היא הרמה הגבוהה ביותר, משלימה את הרמות הקודמות עם הדרישות הבאות:
  • בדיקה חובה של כל השינויים על ידי שני מפתחים שונים.
  • יש להצהיר באופן מלא על כל שלבי הבנייה, הקוד והתלות, יש לחלץ ולאמת את כל התלות בנפרד, ותהליך הבנייה חייב להתבצע במצב לא מקוון.
  • שימוש בתהליך בנייה שניתן לחזור עליו מאפשר לך לחזור על תהליך הבנייה בעצמך ולהבטיח שקובץ ההפעלה נבנה מקוד המקור שסופק.
  
  
  מקור: OpenNet.ru