ביום שישי הטוב, מפתח מיקרוסופט אנדרס פרוינד הטיל פצצת פסחא. בזמן פתרון בעיות של כמה בעיות ביצועים תמימות למראה במערכת דביאן לינוקס, הוא נתקל במה שהיה מְתוּאָר כמתקפת שרשרת האספקה "המבוצעת הטובה ביותר" שנראתה אי פעם.
יהיו לזה השלכות גדולות על צוותי אבטחת IT, ועל האופן שבו הם מנהלים סיכוני קוד פתוח בעתיד.
מה קרה?
ההתקפה הייתה מורכבת להפליא. אבל נראה שזה היה ניסיון בחסות המדינה להכניס דלת אחורית ברכיב קוד פתוח פופולרי המכונה xz Utils. ניתן למצוא את כלי דחיסת הנתונים כמעט בכל מערכות לינוקס. הדלת האחורית והפגיעות הנלווית, CVE-2024-3094, נועדה להחדיר קוד זדוני לשרת OpenSSH (SSHD) הפועל על המחשב של הקורבן. יש עוד פרטים כאן, אבל ה-tl;dr הוא שהוא יאפשר לתוקפים מרוחקים שברשותם מפתח פרטי ספציפי לחטוף מרחוק מחשב ממוקד.
בקיצור, זה רציני ככל שיהיה, וזו הסיבה שה-CVE קיבל ציון CVSS של 10.0. למרבה המזל, המתקפה זוהתה לפני שהעדכון הזדוני xz Utils מוזג להפצות עיקריות של לינוקס. בשלב זה, היא הייתה יכולה להעניק לשחקן האיום שמאחוריו גישה מרחוק למספר לא ידוע של מכונות גלובליות.
התחכום והתכנון הסבלני שנכנסו למתקפה זו מצביעים על גיבוי של מדינת הלאום. אנו יכולים להסיק זאת כי:
- לדלת האחורית עצמה יש שרשרת ביצוע מורכבת הכוללת מספר שלבים
- הדלת האחורית הוצגה על פני מספר התחייבויות
- התחייבויות אלו נכללו רק במהדורות Tarball של קוד המקור ולא נדחפו למאגר הגיט הציבורי - על מנת להסתיר אותן מבדיקה
- המבצע היה לפחות שנתיים בהתהוות. אז הצטרף 'המפתח' הזדוני הידוע בשם 'ג'יה טאן' לפרויקט הקוד הפתוח
- נראה שהקבוצה שמאחורי ג'יה טאן לחצה בכוונה על המתחזק המקורי, לאסה קולין, להעלות את טאן לסיפון. פרסונות מזויפות ככל הנראה, כולל 'ג'יגאר קומאר' ו'דניס אנס', כולן נערמו על הלחץ על ידי הפצצת לאסה בבקשות תכונה ותלונות על באגים
אתגר האבטחה בקוד פתוח
החדשות הרעות הן שידוע ש-Jia Tan עבד על כמה פרויקטים אחרים בקוד פתוח. לא ברור אם קוד זדוני כבר הוכנס בחשאי לאלו ומה ההשפעה עלולה להיות.
קוד פתוח הוא גם הבעיה וגם הפתרון כאן. גישת ה"עיניים הרבות" שלה לפיתוח תוכנה אמורה, בתיאוריה, לומר שמבחינים בבעיות בזמן. אבל כפי שניתן לראות במתקפה זו, שחקני איומים עושים מאמצים רבים כדי להגניב קוד זדוני שלא נראה לפרויקטים.
האתגר של צוותי אבטחה ומפתחים המשתמשים ברכיבי קוד פתוח הוא התלות הבלתי-טרנזיטיבית שלעתים קרובות הם מכניסים לקוד מבלי משים - כפי שהודגש על ידי סאגת Log4j. השגת נראות של סיכון כזה היא קריטית, לדברי ג'יימי סקוט, מנהל מוצר מייסד ב-Endor Labs.
"כשאתה סומך על חבילת Maven אחת, בממוצע, יש 14 תלות נוספות שאתה סומך עליהן באופן מרומז", הוא אומר ל-ISMS.online. "המספר הזה גדול אף יותר במערכות אקולוגיות מסוימות של תוכנה כמו npm, שבה אתה, בממוצע, מייבא 77 רכיבי תוכנה אחרים עבור כל מי שאתה סומך עליו. מערכת יחסי האמון הזו נוצרה עם כל המתחזקים של כל רכיבי התוכנה."
אז מה התשובה? ברמה אחת, צריך לעשות יותר על ידי ממשלות, חברות תוכנה גדולות שמשתמשות בקוד פתוח וקהילת הקוד הפתוח עצמה.
"התעשייה וקהילת הקוד הפתוח צריכות לעבוד באופן הדוק יותר כדי לאבטח את מערכת הסביבה הרחבה יותר של תוכנת אבטחת הסייבר", אומר CSO Cyberhaven, כריס הודסון, ל-ISMS.online. "הקווים בין תוכנות מסחריות לקוד פתוח אטומים. זה האינטרס של כולם לעשות טוב יותר".
סקוט של Endor Labs מוסיף שהתעשייה יכולה לעזור על ידי אימוץ חתימת חפצים.
"חתימת חפצים מספקת חוסן מסוים לסוג זה של התקפה על ידי הבטחה שרק צינורות מורשים יכולים לייצר חפצים תקפים חתומים", הוא טוען.
"אמנם זה לא יספק הגנה מושלמת, אבל זה מעלה משמעותית את העלות ליריב לאמץ חבילות זדוניות, וגם מסייע בתגובה יעילה לאירועים בכך שהוא מאפשר למגיבים לחסום במהירות ובדייקנות את השימוש בחבילה הזדונית ברגע שהיא מזוהה."
יוזמות תעשייה נחוצות אחרות כוללות אימוץ כברירת מחדל של מטא נתונים אבטחה כמו רשימות חומרי תוכנה (SBOMs) ו- Supply Chain Levels for Software Artifacts (SLSA), שיכולים לעזור ל-CISOs להבין טוב יותר את הסיכונים בשרשרת האספקה שלהם. יש גם יותר מימון לארגונים כמו OpenSSF, שבתורו מממן יוזמות אבטחה חשובות.
השלבים הבאים עבור צוותי אבטחה
בסופו של דבר, עבור צוותי CISO ו-DevSecOps, המפתח הוא השגת נראות לקוד הקוד הפתוח שלהם, במיוחד תלות בלתי-טרנזיטיבית, לפי Hodson.
"חשוב עבור CISOs להעריך את שרשרת האמון והתלות ההדדית של ספריית תוכנה וקובץ הפעלה. Xz Utils, בבידוד, מרגיש כמו רכיב תוכנה בסיכון נמוך למדי, אבל יריבים יחפשו לנצל תוכנה כזו כדי לפעול לפי המטרה שלהם", הוא טוען. "ארגוני CISO צריכים לקבל הבנה טובה יותר של שרשרת האספקה שלהם - לא רק את הספקים שהם משתמשים בהם עבור תוכנות מסחריות, אלא את רכיבי הקוד הפתוח בכל היישומים והשירותים שלהם. שלא לדבר על אלה של הצדדים השלישיים שלהם".
CSO של SoSafe, אנדרו רוז, חולק את רשימת המטלות הזו לניהול סיכונים, עם ISMS.online:
- צור ספרייה של תוכנות ונכסים מאושרים כדי להבטיח מעקות בטיחות ברורים למפתחים, ולהגביל קוד ותוכנה לא מאושרים. יש לאמת ולאשר תוכנה, אולי מספקים מוערכי סיכונים
- צור אגמי נתונים מזויפים למטרות בדיקה והטמיע פילוח רשת. המשמעות היא שלכל סביבות המפתחים, או המקומות עם בנייה בלתי מבוקרת, לא תהיה גישה לנתונים אמיתיים, או למערכות ייצור ולשירותים
- השתמש רק בייצורים מאושרים שפורסמו בייצור ובדוק אותם באופן קבוע כדי להבטיח שכל פעילות חשודה מנוטרת
- CISOs צריכים להישאר מחוברים לקהילות מפתחים כדי ללמוד על פגיעויות, דלתות אחוריות ובעיות כשהן מתעוררות
- סרוק באופן קבוע סביבות, גם לאחר ש-CISO ניקו את הבית. יש ליישם מודל 'בקר לא חיות מחמד' לניהול שירותים או תוכנה, כלומר הערכה מתמדת ובנייה מחדש כדי לוודא שהגרסאות המאושרות הנכונות נמצאות בשימוש
Scott של Endor Labs מוסיף את עצות ההגנה המעמיקות הבאות להפחתת הסבירות לניצול במקרה ששרשרת אספקת תוכנה נפגעת:
- הטמעת הרשאות לפחות: במקרה של xz Utils, גישת הרשאות הפחותות לתצורת שרת ומיכל הייתה עוזרת. מפתחות SSH בדלת אחורית מאפשרים לך לגשת ל-SSH כאשר שירותי SSH נגישים. נא לא לחשוף יציאות SSH לאינטרנט
- צור מדיניות ממשל לשימוש בקוד פתוח: אלה יכולים לנוע בין "הצמד את כל הגרסאות של תוכנת הקוד הפתוח המשמשת כך שלא תמיד תוריד את הגרסה העדכנית ביותר" ועד "אל תשתמש בגרסאות של תוכנת קוד פתוח בנות פחות מ-60 יום
- הסר תוכנה שאינה בשימוש כדי להפחית את הסיכון בשרשרת האספקה: תוכנה שאינה בשימוש יכולה ליצור נפיחות מיותרת בתוכנה שלך ולהציג סיכון שרשרת אספקה לאורך זמן. זה רק עניין של זמן עד שהמתקפה הבאה מסוג xz Utils תתגלה. על ידי נקיטת אמצעי זהירות נוספים כעת, ארגונים יכולים לבנות חוסן באופן יזום ולהבטיח שהדרך שלהם להחלמה תהיה מהירה יותר ופחות טראומטית.
