זהו הפרק הראשון בסדרת מאמרים העוסקים בסוג התקפות שרשרת האספקה הנפוצות ביותר של תוכנה: אלו המשתמשות (לרעה) במרשם ציבורי של רכיבי תוכנה, המיועדים ל... פרויקטים של קוד פתוח להעלות תוכנות זדוניות שניתן לשתף עם משתמשים אחרים. כאשר הרעים מפרסמים שם תוכנות זדוניות, תוך שימוש ברישום ככלי להפצת תוכנות זדוניות, יש לנו מתקפת שרשרת אספקה כאשר הארגונים הקורבן מתקינים או מפעילים את רכיב התוכנה הנגוע.
כדי לפשט את הדיון נדבר על חבילות תוכנה:, רכיבים בצורה ארוזה המיוצרים על ידי צדדים שלישיים. זה כולל לא רק רכיבים המשמשים מנהלי חבילות כמו NPM או Poetry, אלא גם רכיבי מערכת ההפעלה כולל ספריות וקבצים בינאריים ניתנים להפעלה, תמונות של מיכלים, ומכונות וירטואליות, או תוספות כלים עבור כלי פיתוח, בנייה ופריסה. ראינו חבילות זדוניות בכל מקום. פושעי סייבר לא אכפת להם: הם מרוצים מהחלופות שמספקות תשתיות תוכנה מודרניות ומשתמשים ברישום ובכלי המתאימים ביותר לכוונתם. לכן אנא זכרו שחבילות תוכנה הן קיצור לתמונות מכולות, חבילות בינאריות, מאגרים בקוד פתוח, והרחבות או תוספים מכל הסוגים (IDEs, CI/CD מערכות, כלי בנייה). כולם נמצאים תחת מתקפה שגרתית.
לסדרה יהיו 5 פרקים:
- מה הבעיה עם חבילות קוד פתוח? זהו הנושא של הפוסט הזה. מדוע פושעים מכל הסוגים מפרסמים חבילות זדוניות? מדוע עליי להיות מודאג?
- אנטומיה של חבילות זדוניות: מהן המגמות? בפרק זה, נתמקד באיום שאנו עוקבים אחריו באמצעות מערכת MEW שלנו, יום אחר יום. עם רעש רקע גדול עקב מספר רב של חבילות זדוניות המשתמשות ב-typosquatting או בלבול תלויות, אחוז קטן יותר של התקפות הן הרבה יותר ערמומיות ומהוות סיכון גדול יותר. כיצד השתנתה התנהגותם של הגורמים הרעים בנוגע למערכת ההפעלה בעבר הקרוב? מהם המספרים? מהן הטקטיקות, הטכניקות והנהלים שבהם נעשה שימוש, והפעולות המזיקות שנצפו?
- הגנה מפני חבילות זדוניות בקוד פתוח: מה עובד (לא עובד)לרוב אנשי המקצוע המודעים לאבטחה יש רעיונות כיצד להתמודד עם איום זה. שמענו מנהלי אבטחה אומרים ללא היסוס ש... SCA כלים כבר אומרים לכם מתי גרסת חבילה היא תוכנה זדונית. או שהם תלויים ברכיבי תוכנה ידועים שנבדקו היטב, שבהם כל תוכנה זדונית תתגלה ותוסר במהירות. הם משתמשים בגרסאות פתוחות קטנות/תיקון כדי לקבל תיקוני פגיעויות באופן אוטומטי, וזו הדרך הנכונה והמומלצת להפחית את הסיכון בתלות בקוד פתוח, בהתאם לעיקרון "תיקון מוקדם, תיקון לעתים קרובות". בפרק זה נסקור מדוע רעיונות אלה שגויים, וכיצד תפיסות מוטעות כאלה תורמות לפופולריות של מנגנון תקיפה זה, ולסיכון עצום שארגונים חווים. נסיים עם מה שכן עובד, ומהם המאמץ והמשאבים הכרוכים בכך.
- חבילות זדוניות בקוד פתוח: גישת Xygeniבפרק זה, נציג את האסטרטגיה שאנו נוקטים בה ב-Xygeni עבור מערכת התרעה מוקדמת מפני תוכנות זדוניות (MEW) שלנו. כיצד מערכת רב-שלבית זו פועלת בזמן אמת כאשר מתפרסמת גרסת חבילה חדשה, כיצד נאספות ראיות ממקורות שונים, כיצד מתבצע מיון, אילו קריטריוני סיווג אנו פועלים לפיה, ומדוע עדיין נדרש ניתוח ידני כדי לאשר את אופיו של מועמד חבילה זדוני? כיצד המשוב מצוותי הפנים ומצוותי הרישום שלנו עוזר למערכת ללמוד מראיות שנאספו בעבר כדי להפחית למינימום תוצאות חיוביות שגויות. בנוסף, נסביר כיצד אנו עוזרים ל-NPM, GitHub, PyPI ותשתיות מפתח אחרות במערכות קוד פתוח של קוד פתוח להפחית את זמן השהייה..
- ניצול קוד פתוח: למה לצפות מהרעיםהסדרה מסתיימת תוך התמקדות בפעולות החדשות ביותר שהיריבים מאמצים כדי להפוך את ההתקפות לחשאיות יותר, קשות יותר לגילוי, ממוקדות יותר נגד תעשיות ספציפיות, ולהפיק תועלת רבה יותר מסוג זה של התקפות. האם התקפות כופר יבוצעו באמצעות כלי זה? כיצד הרעים ממנפים כלי בינה מלאכותית כדי לספק חבילות זדוניות מתוחכמות יותר? האם פרויקטים פופולריים נמצאים בסכנה? זאת כדי לתת לקוראים תחושה לגבי מרוץ החימוש הזה, ולמה לצפות בטווח הקצר (המחצית השנייה של 2024) ובטווח הבינוני (2025). נלמד כיצד התקפות כמו האחרונות... דלת אחורית של XZ-Utils, או מתקפת החיים מהאדמה על בונה אלקטרונים במרץ-מרץ 2024 מראים שעלינו להישאר ערניים לגבי התפתחות היריבים.
בואו נפתח את הבמה עם הפרק הראשון: מה קורה עם חבילות קוד פתוח זדוניות בקוד פתוח?
מה הבעיה עם חבילות קוד פתוח?
בשנים האחרונות, עבריינים מכל הסוגים השתמשו ברישומי תוכנה בקוד פתוח כדי לבצע התנהגות זדונית. פעילויות אלו עתיקות כמו הקוד הפתוח, אך תדירותן התפוצצה בשלוש השנים האחרונות.
פרסום רכיבים זדוניים ברישומים ציבוריים (התקפות מבוססות תלות) היא לוחמת גרילה אסימטרית שבה משתמשים גורמי איום כדי להפיץ תוכנות זדוניות, תוך מינוף האמון שארגונים נותנים ברכיבי קוד פתוח המגיעים ממפתחים לא ידועים (זכרו את קומיקס תלות xkcd?). מכיוון שאתם סומכים על חבילות ולא אכפת לכם לבדוק ידנית את תוכן החבילה והתלות שלהן, התקפות אלו יעילות בצורה יוצאת דופן. והאסימטריה נובעת מכך שהן יכולות להיות אוטומטיות במידה רבה והרעים אינם צריכים לתקשר עם הקורבן ישירות. הם פשוט מעלים את החבילה לרישום הציבורי ומשחררים אותה.
חבילות זדוניות זינק פי 6 בשנת 2022, והמשיכה לגדול פי 2.5 בשנת 2023. בשנה שעברה נצפו 245,000 חבילות זדוניות, נתון המכפיל את המספר הכולל משנים קודמות גם יחד. זוהי צמיחה אקספוננציאלית! החל מהסרת חבילות ועד תוכנות זדוניות מאושרות במאות במהלך 2021 ובאלפים במהלך 2022, ראינו הרבה יותר "רעשי" רקע במהלך 2023, עם קצב דומה לשנה זו. ובתוך הרקע הזה, שנגרם על ידי פושעי סייבר לא מתוחכמים שהלכו ב"דרך ההתנגדות הפחותה", מיעוט של התקפות מתוקשרות הגיעו לכותרות אפילו בתקשורת הכללית.
מדוע זו בעיה בסדר גודל כזה? יש עודף אמון בכל רחבי השרשרת. תוכנה בקוד פתוח מופצת עם קוד המקור שלה, ומשוחררת תחת רישיון נתון. כן, כל אחד יכול לבדוק את קוד המקור; אבל, מי עושה זאת באופן כללי? מי, לאחר שבדק שהתוכנה אינה מכילה תוכנות זדוניות, בונה את התוכנה ממקורות המקור? מי, לפני שהוא מעביר את הרכיב הארוז (הידוע גם בשם חבילה) במורד הזרם למנהל החבילות או לכלי הבנייה, מוודא שהחבילה אינה מלאה בתוכנות זדוניות ותואמת את קוד המקור שממנו היא אמורה להגיע?
מדוע התשתית מאפשרת התקפות כל כך קלות?
רישומי חבילות פתוחים, ולעתים קרובות דורשים אימות מינימלי של זהות המפרסם. "כל אחד מוזמן לפרסם את התוכנה שלו כאן!" הרף לתוקפים נמוך: הם משתמשים בכתובות דוא"ל חד פעמיות ובחשבונות GitHubGithub חד פעמיים כדי ליצור מאות חבילות זדוניות בקמפיינים קצרים, דמויי פישינג. רק עבור כאלה ממוקדים נדרשת תחכום גבוה יותר: ראינו אפילו יצירת מאגר מקורות אמין של GitHub עם כוכבים רבים ו commitמתורמים מזויפים מרובים ומדדים אחרים של פופולריות ותחזוקה. קבלת צופי כוכבים ומוניטין מתרומות מזויפות לא קשה לאוטומציה. ראינו שימוש לרעה בתשתיות תוכנה פתוחות מכל הסוגים, לא רק תוכנות זדוניות, כמו תקרית פרוטוקול התה.
מנהלי חבילות תוכננו לנוחות השימוש ולא למען אבטחההם יכולים להריץ סקריפטים לפני ואחרי ההתקנה (לפעמים יש צורך בקומפילציה של קוד מקורי עבור ספרייה). כמו כן, מנהלי חבילות להתקין חבילות ממקורות מרובים, ולפעמים ברירת המחדל היא להשתמש ברישומים ציבוריים. הם לא בדקו אי התאמה בין המטא-דאטה בבקשת הפרסום לבין המטא-דאטה בחבילה עצמה.
תלויות מקוננות ויוצרות גרף. במערכות אקולוגיות מסוימות כמו Node (JavaScript), תלויות קטנות מצטברות במאות או באלפים. דבר אחד הוא שליטה קפדנית על תלויות ישירות המוצהרות על ידי פרויקטי התוכנה שלי, אבל תלויות טרנזיטיביות קשה יותר לשלוט בהם. קוד פתוח פעל לפי "חבריהם של חבריי הם חבריי". אחווה היא הנורמה במזרח הרחוק הפרוע! גורמי איום יודעים זאת ומסתירים את ההתנהגות הזדונית עמוק בתלות לא מוכרות שלעתים קרובות אינן ידועות. זה היה המקרה עם ה- זרם אירועים אירוע שמכוון אל ארנק קופאיי.
כך עבדה תוכנה בקוד פתוח מאז הקמתה. זה לא ישתנה הרבה. חלק ממאגרי החבילות דורשים במקרה הטוב אימות דו-שלבי, ולעתים קרובות רק עבור החבילות הפופולריות ביותר. חלק מהמאגרי החבילות מספקים טווחים, מרחב שמות בבעלות ארגון מאומת, אבל... באופן טרגי אחרים אינם תומכים בו (PyPI) או הופכים אותו לאופציונלי (NPM). מעניין לציין שאפילו א תוכנית סינון פשוטה (מבוסס על שליטה במאגר/ארגון ה-DNS או GitHub התואמים את מזהה הקבוצה) וביצוע חתימות PGP חובה עבור כל הארטיפקטים מלבד סכומי בדיקה, מסיר את רוב ה"רעש", חבילות זדוניות דמויות typosquatting, ומגביל חלק ניכר מ בלבול תלותהתקפות מתוחכמות אפשריות אך קשות הרבה יותר, עם מעטות בלבד כמו זו com.github.codingandcoding:maven-compiler-plugin ידוע בזכות Maven Central. ולא כל רישומי Maven פועלים לפי אותן שיטות!
בקרות אבטחה על מנהלי חבילות עשויות להכביד אך לא להפריע להתקפות תלות. הבעיה עם אימות רב-גורמי היא שבשביל אוטומציה, נוצרים אישורים נגזרים כמו אסימוני גישה או מפתחות APIapi עבור חשבונות שישמשו בקריאות APIapi המבוצעות מסקריפטים של אוטומציה, ללא גיבוי של משתמש אינטראקטיבי המספק גורם שני. אימות רב-גורמי טוב להגנה על חשבונות משתמשים מפני דליפות סיסמאות, אך יש להגן על אסימוני הגישה או מפתחות ה-APIapi שנוצרו בזמן שהם פעילים, אחרת בעליהם יתחזות על ידי היריבים. חלק גדול מקמפיינים של שרשרת אספקה מבוססת חבילות מתחילים במפתח/אסימון שדלפו. רק זכרו מקרים כמו... פנקס, 3CX, ורבים אחרים, שבהם אישורים לא אינטראקטיביים חולצו לראשונה בפריצה ראשונית לצורך שיגור מתקפת שרשרת האספקה.
התגובה שניתנה לאיום זה לא הייתה חזקה מספיק. בפרק השלישי נתמקד במה שעבד, ובמה שנכשל כישלון חרוץ. התעשייה צריכה לעבוד יחד על... standard, תהליכים, חינוך וכלים להפחתת סיכונים לשרשראות אספקה גלובליות. זו אינה בעיה שארגון יחיד יכול לפתור בעצמו.
לסיום פרק זה, אי ההבנה המכרעת: אנחנו מדברים על זדוני חבילות, לא פגיע אלו. פגיעויות נובעות משגיאות עיצוב או קידוד, שהוכנסו בטעות, ללא כוונה רעה. הפגיעויות עשויות להיות מנוצלות, אך רבות מהן לא. חבילות זדוניות הן תמיד מכוונות, ויש ניצול של 100% אם הן מבוצעות. אין סיכון דומה! לכן פרדוקסלי לראות כמה מאמצים מושקעים בזיהוי ובמיתון פגיעויות, ואת היעדר אמצעים מקבילים עבור רכיבים זדוניים..
"אנחנו לוקחים את האבטחה ברצינות"
בואו נדמיין את המנהג תאגיד AcmeAcme, ספקית מרכזית של WileCoyote.com, מקבלת את רוב התוכנות שלה מצדדים שלישיים, כאשר יותר מ-80% מהן מגיעות מפרויקטים בקוד פתוח. הם מייצרים תוכנה לשימוש פנימי, אך הם גם מספקים תוכנה לשותפים, ספקים וללקוחות/משתמשי קצה. ל-Acme יש תוכנה שנכתבה ב-Go, JavaScript, Java, C# ו-Python, והיא מפעילה את רוב התוכנות שלה בענן, תחת אשכולות Kuberneteskubernetes. Acme בונה את התמונות המותאמות אישית שלה מתמונות בסיס שנלקחו מ-Docker Hub וממאגרי מידע אחרים. והם חולקים גם כמה ספריות, חבילות ותמונות מכולות במאגרי מידע ציבוריים.
Acme לוקחת את נושא האבטחה ברצינות. הם מודעים למדי לבעיית open source security, והסיכון שהוא טומן בחובו. כל המפתחים, מנהלי המערכת ומהנדסי DevOpsdevops משתמשים במפתחות הקריפטו הקטנים והחמודים האלה כאימות גורם שני. הכל commits כדי שמאגרי קוד ייחתמו, הגנת ענפים מופעלת עם סקירות קוד חובה, CI/CD נעולים, סודות מאוחסנים בכספת סודית, ועם רישום פנימי המשקף חלקית רישום חיצוני שבו מאוחסנים רק הרכיבים המותרים, המופיעים ברשימה הלבנה. נדרש שתוכנה שנבנתה על ידי Acme תיקח תלויות של צד שלישי מרישום זה.
כנראה שרוב הארגונים מתאימים לפרופיל הזה. קורא יקר, שלך בהחלט מתאים אם אתה כבר כאן, נכון?
ואז, יום אחד, מצער, מפתח פרונט-אנד חשוב באקמה רץ התקנת npm של acme-cute-lib, ושכח ש-@acme/cute-lib היה התלות הנכונה. הטעות המדויקת אינה חשובה, דברים רבים עלולים להשתבש גם כאשר מקבלים שליטה מושלמת על מחזור חיי התוכנה. המפתח שלנו לא ידע שקבוצת APT מכוונת ל-Acme ופרסם רכיב זדוני תחת שם זה, בצורה ערמומית כך שההתנהגות הזדונית מופעלת רק כאשר התוכנה מותקנת במחשבי Acme. החבילה לא זוהתה במשך שבועות לאחר פרסומה.
מופעל סקריפט התקנה המחפש אחר אישורים (היו הרבה אסימוני גישה עסיסיים במחשב הנייד של המפתח שלנו), המאפשר גישה למאגרי תוכנה פנימיים ולמאגר הפנימי שהוזכר לעיל, אשר נגיש כמובן רק דרך VPN. הקוד הזדוני הצליח להשתמש בחיבור ה-VPN הקיים ולפרסם רכיב זדוני בשלב שני ברישום הפנימי, ובכך משפיע על ספריית תוכנות עזר משותפת לרוב התוכנות שמספקת Acme.
שבועות לאחר מכן, ארגונים אחרים שהשתמשו בכלים שפורסמו על ידי Acme החלו לראות תעבורה מוזרה ברשתות שלהם, כאשר התעבורה משתמשת בפרוטוקול של Acme אך מופנית למארחים הדומים לדומיין של Acme. התעבורה הייתה מוצפנת אך כלי ניטור המערכת מצאו גישה לקבצים בלתי צפויים ולביצוע תהליכים שנראים כמו פקודות מערכת אך בסופו של דבר מפעילים קבצי הרצה שהורדו.
השאר היסטוריה: Acme הכחישה בתחילה כי התנהגות כזו מיוחסת לה וכי כל אמצעי האבטחה ננקטו. רק לאחר שתקשורת הסייבר החלה לשאול מדוע מקור ההתנהגות שזוהתה נובע מרכיבי Acme, וניתוח אבטחה פרסם עד כמה רכיבים אלה מלאים בתוכנות זדוניות חשאיות, Acme נאלצה לזהות את האירוע ולהזעיק חברת תגובה לאירועים. קמפיין שיווקי שלילי שפגע באמון שנצבר בעמל רב תוך שנייה.Acme הייתה במרחק התקנה אחת של npm מ-disaster"" הייתה כותרת נפוצה. לאחר מכן הלכו בעקבותיה תביעות משפטיות וחוזים שבוטלו.
האם אתה רואה דמיון עם אירועים ידועים מהעבר? Acme נפלה לתקרית בשרשרת האספקה בשני שלבים, תוך שימוש בשילוב של בלבול תלות/התעלמות מטעויות התקפות שהשתמשו בתחנת עבודה של מפתחים כבסיס להדבקת רכיבים שהגיעו לתוכנה בשימוש של צדדים שלישיים. כיצד ניתן למנוע או לצמצם זאת?
למה חבילות מורעלות כל כך פופולריות
תקרית היפותטית זו מראה שגם עם גישה סבירה לאבטחת קוד פתוח, ארגונים זקוקים לאמצעים ספציפיים כדי להימנע מליפול קורבן לתוכנות זדוניות ברכיבי קוד פתוח. באופן סכמטי, גורם האיום יכול:
- צור חבילה חדשה (בעקבות שיטת typosquatting או confusion dependency הידועה, זהו הנתיב הנפוצ ביותר על ידי הרעים בנפח);
- נסה להדביק קוד קיים, בין אם על ידי החדרתו לקוד המקור, או על ידי ניסיון להסוות אותו כתורם באמצעות pull request, או שימוש בהנדסה חברתית כדי להפוך לתחזוקן (כמו ש"ג'או טאן" עשה ב-XZ Backdoor או right9ctrl משתמש GitHub עשה זאת ב- זרם אירועים אירוע בסתיו 2018), או על ידי השגת אישורי מאגר קוד פתוח והתחזות לתחזוקה;
- הזרקת תוכנה זדונית במהלך בניית החבילה, בין אם על ידי הפעלת סקריפט בנייה זדוני, או הפרעה להורדות חבילות באמצעות יירוט מסוג man-in-the-middle (למרבה המזל, TLS נדרש כיום תמיד ברוב הרישומים).
- הזרק את הרכיב הארוז ישירות לתוך הרישום, בדרך כלל על ידי לכידת אישורי הרישום (האלטרנטיבה המועדפת עבור התקפות מתוחכמות רבות כמו זו של Acme, שבהן תחנת העבודה שנפגעה בשלב הראשון החזיקה באסימון גישה פנימי לרישום, למשל בדרך הרגילה). .v or ~/.m2/settings.xml: גורמים רעים אכן יודעים היכן לחפש סודות). גם פגיעויות במרשמים נוצלו.
הרעלת רישומי תוכנות זדוניות היא הבסיס להתקפות תלות. אין חדש תחת השמש: שכיחותה התפוצצה, אך אותן טכניקות פועלות כעת כמו לפני חמש שנים.
מקור: אוסף סכינים של דוקר גב.
החבילה הזדונית יכולה לפעול בעת ההתקנה, במהלך בניית התוכנה או בזמן ריצה. ההתנהגות נעה בין חילוץ מידע, למשל חילוץ סודות לניסיון שלב שני, ועד לחילוץ קוד מקור, שחרור תוכנות זדוניות נוספות. בפרק הבא ננתח את החבילות הזדוניות וכיצד הן מתפרסמות.
לקריאה נוספת
הפרק הבא אנטומיה של חבילות זדוניות: מהן המגמות? נתמקד במקרים אמיתיים שאנו עוקבים אחריהם באמצעות מערכת התרעה מוקדמת מפני תוכנות זדוניות שלנו, יום אחר יום. נסקור אילו סוגי תוכנות זדוניות נצפו, ואילו טקטיקות, טכניקות ונהלים הם המועדפים. נבחן ערפול וכיצד הם מנסים להסתתר מפני בודקים פוטנציאליים, טכניקות התחמקות כדי להימנע מגילוי, וכיצד הם מתפתחים עם טלמטריה ותנועה צידית. אנא הישארו מעודכנים!
הפניות
- אוסף סכינים של דוקרני גב: סקירה של מתקפות שרשרת אספקה של תוכנה בקוד פתוחמ. אוהם ואחרים, מאי 2020.
- הגנה מפני תוכנות זדוניות בקוד פתוחנייר עמדה מבית Xygeni.
- Software Supply Chain Security מבט לאחור: עיצוב שנת 2024 בטוחה יותרדו"ח מ-Xygeni.
