זהו הפרק הרביעי בסדרה סדרת פוסטים אודות רכיבים זדוניים, שם אנו מציגים את קסיגני גישה להתמודדות עם איום זה, כחלק מהסיקור שלנו עבור Open Source Security.
ראינו שאמון מופרז ברכיבי קוד פתוח בעלי מקור לא ודאי מנוצל על ידי עבירות מכל הסוגים כדי ליצור התנהגות בלתי צפויה שתרוץ במכונות מפתחים, CI/CD מערכות, או מוטמעות בתוכנה של הארגון הקורבן, כך שהן מועברות ללקוחות הארגון. ניתחנו ב פרק מספר 2 ההתקפות המשתמשות ברישומים ציבוריים כדי להעביר תוכנות זדוניות ומה שלמדנו לאחר שצפינו כיצד הגורמים הרעים פועלים, ובמקרים הקודמים פרק מספר 3 נבחנו הבקרות שעובדות (ואלו שנכשלות) כנגד איום זה.
עכשיו הגיע הזמן לבחון את הגישה שלנו לבעיה. בפרק זה, נציג את האסטרטגיה שאנו נוקטים בה ב-Xygeni עבורנו התרעה מוקדמת על תוכנות זדוניות מערכת (MEW). כיצד מערכת רב-שלבית זו פועלת בזמן אמת כאשר גרסת חבילה חדשה יוצאת, כיצד נאספות ראיות ממקורות שונים, כיצד מתבצע מיון, אילו קריטריוני סיווג אנו פועלים לפיה, ומדוע עדיין נדרש ניתוח ידני כדי לאשר את אופיו של מועמד חבילה זדוני. כמו כן, נסביר כיצד אנו עוזרים ל-NPM, GitHub, PyPI ותשתיות מפתח אחרות במערכות אקולוגיות של קוד פתוח להפחית את זמן השהייה של תוכנות זדוניות.
השמיים pipeline
התרעה מוקדמת של Xygeni Malware (MEW) מעבדת באופן רציף רכיבים, בין אם קבצי tarball של חבילות עבור ספריות ומסגרות עבור מערכות אקולוגיות תכנות נתמכות כמו JavaScript/Node או Python, תמונות של מכולות Docker / OCI, או הרחבות ותוספים עבור כלים כמו IDEs או CI/CD מערכות. רכיבים כאלה מתפרסמים ברישומים ציבוריים עם רמות שונות של סינון משתמשים.
להלן תמונה סכמטית של אופן פעולת המערכת:
השמיים מְגַלֶה התהליך מקבל את הזנת אירועי הפרסום. אירוע פרסום הוא יצירת גרסה חדשה של רכיב חדש או קיים. מכיוון שרישומים פופולריים אינם מספקים מנגנון פרסום-סאב עבור צרכנים המעוניינים בכך, הדבר נעשה לעתים קרובות על ידי סקר הרישום לאירועים אחרונים. פרויקט מצוין של OSSF, הזנות חבילות, תְמִיכָה רישומים פופולריים כמו PyPI או Maven Central, ומספקים ממשק מאוחד מבוסס הזנה. ב-MEW הוספנו כמה יישומים ספציפיים שמפחיתים את זמן ההמתנה, למשל עם העתק של מסד הנתונים CouchDB בו משתמש NPM אשר מסונכרן עם מסד הנתונים הציבורי של הרישום.
ב-Xygeni, יש לנו מלאי[1] של כל הרכיבים (באופן ישיר או עקיף) המשמשים את תוכנת הלקוחות שלנו. קואורדינטות הרכיבים של הלקוחות מוזנות באופן קבוע ל-MEW לצורך קביעת סדרי עדיפויות לניתוחים: רכיבים המשמשים את לקוחותינו מעובדים מוקדם יותר. העדיפות מבוססת גם על המוניטין של המוציא לאור ועל קריטיות הרכיב, כך שגם רכיבים המגיעים ממוציאים לאור עם מוניטין נמוך מקבלים עדיפות.
השמיים מנתחים לאחר מכן צורכים את הרכיבים הממתינים בתור העדיפויות. כאשר גרסת רכיב נבחרת לניתוח, ה-tarball שלה מורדת מהרישום. שים לב שהרכיב הבינארי הארוז מנותח: רוב רכיבי הקוד הפתוח מגיעים בדרך כלל ממאגר קוד פתוח, לרוב ב-github.com, המשמש להקשר בלבד, והתוכנה הזדונית תמיד מחפשת ב-tarball של הרכיבים מכיוון שגורמי איום משקרים באופן שיטתי לגבי המקורות שהם טוענים שהשתמשו בהם כדי לבנות את tarball הרכיבים שהם משחררים.
מנקודת מבטו של המשתמש
אני שומע אותך חושב: איך אני יכול להפיק תועלת מידיעה מוקדמת על גרסת חבילה זדונית? בפרק "אנטומיה של חבילות זדוניות: מהן המגמות?" ראינו שזמן השהייה הכולל הוא בטווח של ימים, בעוד שההודעה הראשונה מ-MEW ללקוחות המשתמשים ברכיב המושפע היא בטווח הדקות. עם מעקה בטיחות פשוט[2] באפשרותך לחסום את הבנייה (ישנן שתי רמות התראה, אחת אוטומטית לחלוטין כאשר המנוע מסיק שיש תוכנה זדונית פוטנציאלית והודעה מאוחרת יותר כאשר צוות האבטחה שלנו מאשר על ידי בדיקה ידנית את נוכחות התוכנה הזדונית). ההמתנה עד שהרישום יאשר את התוכנה הזדונית ומסיר אותה מהרישום היא בדרך כלל מאוחרת מדי עקב חלון החשיפה הארוך.
הארגון עשוי להשתמש במעקה בטיחות שבודק אם קיים רכיב עם תוכנה זדונית פוטנציאלית (באחת משתי רמות ההתראה) או, באמצעות API, לדעת במהירות אם אחת מהתלות הישירות או העקיפות בפרויקט תוכנה משתמשת ברכיב זדוני.
איך MEW עובד: פרטים פנימיים
הליבה: מנוע זיהוי תוכנות זדוניות
המנתח משתמש בגלאים שונים כדי ללכוד ראיות לעבירה. הגלאים משלבים ניתוח סטטי, ניתוח יכולות וניתוח הקשר.[3], כפי שתואר בפוסט הקודם בסדרה זו.
ב-Xygeni, יש לנו צוות הנדסה עם ניסיון רב בניתוח סטטי, וזה ההבדל העיקרי לעומת פתרונות אנטי-וירוס אחרים. שימו לב שעבור חלק מהמערכות האקולוגיות, ה-tarball הארוז מכיל קוד מקור (למשל, קוד JavaScript או TypeScript עבור חבילות NPM, מקורות Python עבור חבילות PyPI), או קוד מהודר קרוב מספיק לקוד המקור עבור ניתוח סטטי (למשל, קוד בייט בקבצי JAR עבור Maven). עבור אחרים, כגון תמונות קונטיינרים, קבצי הרצה בינאריים נפוצים, כך שהסקת יכולות היא הטכניקה שבה משתמשים, יחד עם זיהוי וירוסים קונבנציונלי המבוסס על כללי YARA וחתימות וירוסים.
שימו לב שטכנולוגיות פשוטות כמו ביטויים רגולריים או חתימות אינן מתאימות לגילוי התנהגות זדונית. דמיינו גילוי של קובץ הורדה או הורדה: קוד או קובץ בינארי כלשהו נמצאים בחבילה או שהורדים מדומיין חיצוני, שאינם קשורים לרכיב (יכול להיות מ... רשימה ארוכה של דומיינים שנרכשו על ידי גורם האיום[4], או דומיין לגיטימי כדי להתחמק מגילוי). קוד זה מבוצע לאחר מכן באמצעות אחת הפונקציות עבור זה. ניתן להמיר את הקוד כדי להסתיר את כתובת ה-URL להורדה או את הפונקציה המשמשת להרצת הקוד שהורד. נדרש ניתוח זרימת נתונים מלא כדי לזהות זאת, תוך שימוש במנגנון המלא של ניתוח סטטי, או ביצוע בארגז חול (אם התנאים להפעלת התנהגות זדונית מתקיימים בפועל) יכול לזהות זאת במקרה הכללי.
גורמי איום פועלים לפי אותן טכניקות וגלאים שתוכננו ויושמו עבורם. ישנם גם כמה שלבי עיבוד מקדים, למשל להסרת ערפול, שלעתים קרובות נדרשים כדי לחשוף את ההתנהגות הנסתרת.
הוספת הקשר
חלק מהגלאים משתמשים במידע הקשרי. לדוגמה, אי התאמה בין הגרסה ברישום הרכיבים לבין התג/מהדורה במאגר GitHub המשויך מהווה ראיה חזקה לכך שאולי גורם פוגע השיג אישורי פרסום עבור הרישום אך לא עבור מאגר GitHub. התקפות כמו זו שמשפיעה על ספק ארנקי קריפטו. פנקס ניתן היה לזהות אותו בקלות על ידי אי התאמה זו.
A ציון זדון (MS) מחושב מממצאי הפעלת הגלאים, בהתבסס על עוצמת הראיות שנלכדו. לא כל הממצאים זהים, וסדר הביצוע רלוונטי.
מוניטין של משתמשים ורכיבים
לא כל מפתחי הקוד הפתוח נוצרו שווים!
ייתכן שחשבון ה-NPM של מפתח בעל מוניטין יפרוץ (זה קורה אפילו עם אנשים מודעים לאבטחה), ותוכנות זדוניות יפורסמו באמצעות חשבון זה. ברור שהמוניטין אמור לרדת בפתאומיות, ולהתאושש רק לאחר שהחשבון שנחטף יוחזר והמפתח יתקן את התנאים שהובילו להשתלטות על החשבון. קשה לצבור מוניטין, אך ניתן לאבד אותו בן רגע.
ב-MEW, יישמנו מערכת מקיפה לניהול מוניטין כדי לתגמל התנהגות חיובית ולעניש פעילויות חשודות. מערכת זו מתחילה עם משתמשים חדשים בעמדה ניטרלית ומתאימה את המוניטין שלהם בהתבסס על פעילותם המתמשכת.
המוניטין של משתמש משתפר באמצעות פעולות חיוביות כגון שמירה על חשבונות מדיה חברתית פעילים, הפעלת אימות רב-גורמי, תרומה קבועה לפרויקטים וחתימה commitעם מפתחות ניתנים לאימות. לעומת זאת, המוניטין מתדרדר עקב פעולות עוינות כמו פרסום תוכנות זדוניות, שימוש בכתובות דוא"ל חד פעמיות, אי חתימה commits, או הצגת דפוסים יוצאי דופן בתרומות.
המטרה העיקרית של המערכת שלנו היא להבטיח סביבה בטוחה ואמינה. היא משיגה זאת על ידי התאמה דינמית של מוניטין המשתמשים בהתבסס על גורמים שונים, תוך כיבוד חששות פרטיות ומגבלות של רישומים שונים.
ציון מוניטין פנימי מחושב עבור המשתמש (הצטרפות לרישום ולחשבון גיטהאב במידת האפשר), יחד עם ציון הזדון המשמש במהלך סיווג הרכיב הנמצא תחת ניתוח, ולסיווג טוב יותר של מי נמצא תחת פרסום הרכיב.
נמצאו ראיות להתנהגות זדונית. אז מה? תהליך הבדיקה הידנית
המסווג הנוכחי מגדיר את גרסת הרכיב המנותחת לאחת מהקטגוריות "אושרה כזדונית", "כנראה זדונית", "סיכון גבוה", "סיכון נמוך" או "לא זדונית" בהתבסס על ספים של הציונים המרכזים את הממצאים ואת מוניטין המשתמש/רכיב. סיווג לקטגוריות "סיכון גבוה" או "כנראה זדוני" מפעיל את הבדיקה הידנית ואת ההודעה הראשונה. הקטגוריה "אושרה כזדונית" נקבעת לאחר בדיקה ידנית או כאשר הראיות תואמות את אותן ראיות עבור גרסה קודמת שאושרה כזדונית.
כאשר קיימות מספיק ראיות להתנהגות זדונית פוטנציאלית, נשלחת התראה ראשונה (התראת הסגר) לארגונים שנפגעו. כפי שצוין קודם לכן, התראה זו עשויה לחסום את ההתקנה או הבנייה של תוכנה התלויה ברכיב שהוכנס להסגר.
זה יוצר בעיה פנימית ב-MEW dashboard כך שאנליסטים של אבטחה יכולים להתחיל בתהליך הבדיקה הידני של הרכיב. לצוות יש כלים ייעודיים (ארגז חול, כלי הסרת ערפל, הפצה למחקר תוכנות זדוניות, כלי דיווח על תוכנות זדוניות) להערכה מהירה של אופי גרסת הרכיב הנחקרת. רוב התוכנות הזדוניות ("האנשובי" או רכיבים זדוניים לא מתוחכמים) נבדקות.
תוצאת הסקירה מסתכמת באחת משתי האפשרויות: בטוח, כך שמנוע הניתוח האוטומטי מצא תוצאה חיובית כוזבת המשמשת כמשוב למסווג למידת המכונה כדי ללמוד את התבנית; או אושר זדוני, כך שהרכיב נחשף באחריות כזדוני למרשם הציבורי, לאחר תהליך הדיווח. הודעה שנייה נשלחת לארגונים שנפגעו, אשר בתורם עשויים לבטל את הסגר של הרכיב, או לחסום אותו באופן מוחלט מתהליך שדרוג הגרסה שלהם או מחומת האש של הרכיבים המשמשת ברישום הפנימי שלהם.
הגדרה זו מאפשרת לנו לנתח עשרות אלפי גרסאות חדשות מדי יום ולזהות את עשרות הרכיבים שכנראה זדוניים, שאותם אנו בודקים ידנית. זכרו מהפרק הקודם שאחד לעשרת אלפים הוא שיעור הרכיבים הזדוניים שאנו רואים כיום בטבע.
דיווח לרשם
מצאנו שרוב הרישומים הציבוריים, אחד מעמודי התווך של תשתית הקוד הפתוח, מספקים מנגנונים מוגבלים למדי לדיווח על בעיות אבטחה, ובפרט על רכיבים זדוניים. אנו מתקשים לשפר את הארגון הבסיסי של תהליך הדיווח. בדרך כלל אנו מקבלים לכל היותר דוא"ל משוב מצוות האבטחה ברישום המאשר שהרכיב הוסר מהרישום.
לעיתים, הרישום מנוצל לרעה, תוך הפרת תנאי השימוש שלו, אך לא גורמת להתנהגות זדונית בתוכנה המסופקת. דבר זה מדווח גם לרישום, אך אינו מודיע לארגונים כדי להגביל את הרעש.
עבודה עתידית
שיפורים רבים נמצאים כעת על הפרק. ראשית, א פורטל ציבורי לבריאות רכיבי מערכת ההפעלה, במיוחד בנוגע לראיות שנמצאו לפוטנציאל לתוכן זדוני, נמצא כעת בפיתוח. תרומה צנועה לקהילת הקוד הפתוח. הישארו מעודכנים.
פיתוח מתמשך נוסף הוא שיפור מסווג למידת מכונהMEW ילמד מסיווגים קודמים. וקטור הממצאים מגלאי המנוע, בתוספת ציון הזדון הנגזר וציון המוניטין עבור הרכיב והמפרסם ("הראיות שנמצאו") משמש כקלט למערכת למידת מכונה שמעדכנת את מודל המסווג. משתנה הפלט הוא פשוט אם הרישום אישר אם הרכיב היה זדוני. זה נקרא "האורקל" ויעזור עם בדיקה מקדימה יותר.cisזיהוי e, שנועד להיות תקין (זכירה גבוהה, כלומר לא לפספס רכיבים זדוניים) אך עם פחות תוצאות חיוביות שגויות (לא לדווח על רכיבים בטוחים כזדוניים).
A ציון קריטיות יתווספו לקריטריוני תעדוף, מלבד שייכות לקבוצת התלות של הלקוחות, והמוניטין הנמוך של המוציא לאור. ברור שיש לשקול מוקדם יותר פרויקטים בעלי השפעה וחשיבות רבה יותר לניתוח. לא נמציא כאן את הגלגל מחדש, ונמשיך את ציון קריטיות פרויקט קוד פתוח.
תמיכה במערכות אקולוגיות נוספות נמצאת בפיתוח. טכנולוגיות וכלים נרחבים כמו תוספים של PHP או Jenkins נמצאים במפת הדרכים.
אנו בוחנים גם האם ניתן לסייע בתהליך הבדיקה הידנית באמצעות בינה מלאכותית כדי לייעל את הניתוח עבור רכיבים זדוניים מתוחכמים יותר.
בפרק הבא והאחרון בסדרה זו, "ניצול קוד פתוח: למה לצפות מהרעים", נתמקד בדרכים האחרונות שבהן נוקטים היריבים כדי להפוך את ההתקפות לחשאיות יותר, קשות יותר לגילוי, ממוקדות יותר לתעשיות ספציפיות ורווחיות יותר. האם מתקפות כופר יבוצעו באמצעות כלי זה? כיצד הרעים ממנפים כלי בינה מלאכותית כדי לספק תוכנות זדוניות מתוחכמות יותר? האם פרויקטים פופולריים נמצאים בסיכון? זאת כדי לתת לקוראים תחושה של מרוץ חימוש זה, ולמה לצפות בטווח הקצר (המחצית השנייה של 2024) ובטווח הבינוני (2025).
נסיים בכמה מחשבות על הצעדים הקטנים שהקהילה יכולה לנקוט מבלי לשנות יותר מדי את הפתיחות של עולם הקוד הפתוח. לדוגמה, מנגנון יעיל יותר לדיווח על תוכנות זדוניות למאגרי מידע ציבוריים, ושיתוף ראיות לרכיבים זדוניים פוטנציאליים עם המאגרים והקהילה יהיו צעד קטן בכיוון הנכון לקראת המטרה של סגירת הדלתות בפני גורמי איום.
תוכנות זדוניות ברכיבי קוד פתוח לא צריכות לשבש את היתרונות העצומים שהביאה קהילת הקוד הפתוח לחברה שלנו.
- [1] הסורק שלנו מזהה רכיבי קוד פתוח שאליהם מתייחסים פרויקטי התוכנה שנותחו, כך שגרף התלות המלא והמעודכן ידוע, לפחות עבור פרויקטים שנסרקים באופן קבוע. מערכת ההפעלה Xygeni OSS חושפת ממשק API שלקוחות עשויים להשתמש בו גם במהלך הוספה לרשימת הלבנים של רכיב שמעניין אותם, כולל מידע על פגיעויות וראיות זדוניות.
- [2] מעקה בטיחות עלול לשבור את הבנייה אם יתגלה מצב התואם לבעיות אבטחה. ממצאי אבטחה כמו פגיעות קריטית וניתנת לגישה או שימוש ברכיב בהסגר עלולים להיחשב חמורים מספיק כדי לשבור את הבנייה עבור התוכנה המושפעת.
- [3]אנליסטים של האבטחה שלנו מפעילים את הרכיב או את סקריפטי ההתקנה שלו בסביבת ארגז חול בעת הצורך. עם זאת, MEW אינו מבצע ניתוח דינמי, בעיקר משום שההתנהגות הזדונית לא תמיד מתבצעת בהתקפות ממוקדות ובגלל לוגיקת ההתחמקות שבה משתמשים גורמי איום כדי להתחמק מניתוח דינמי.
- [4] טכניקה זו קיבלה שם, אלגוריתמים ליצירת דומיינים רשומים או RDGA, וגורמי איום חדשים כמו מה שנקרא ארנב אקדח השקיעו עד מיליון דולר ב-500,000 דומיינים, מה שמראה עד כמה רווחית תעשיית פשיעת הסייבר.
