תוקפים כבר לא מבצעים פישינג למשתמשי קצה, אלא למתחזקי חבילות קוד פתוח כדי להזריק קוד זדוני לתלויות קריטיות. מקרים כמו xz-utils (2024) או event-stream (2018) חושפים דפוס: הנדסה חברתית נגד מפתחים, ולא ניצול פרצות טכניות. ההגנה דורשת SBOM, חתימות קריפטוגרפיות ובדיקת תלויות, אך התעשייה עדיין ממעיטה בערך הסיכון.

מדוע מפתחים הם מטרת הפישינג החדשה?

פישינג מסורתי מכוון לעובדים בעלי גישה לנתונים רגישים. בשרשראות אספקה של תוכנה, הווקטור משתנה: התוקפים מחפשים את אלו שמתחזקים מאגרים ציבוריים או פרטיים עם אלפי תלויות. מייל מזויף למתחזק חבילה ב-npm או PyPI עלול לסכן מיליוני מערכות במורד הזרם. הספרות הקיימת מצביעה על כך ש-60% מהאירועים בשרשרת אספקה מתחילים בהנדסה חברתית, ולא בפרצות טכניות (CISA, 2023).

המקרה של xz-utils (CVE-2024-3094) הוא דוגמה מובהקת. תוקף אחד חדר לפרויקט במשך שנתיים, זכה באמונו של המתחזק המקורי לפני שהחדיר דלת אחורית לספריית הדחיסה. הקוד הזדוני הופעל רק במערכות לינוקס עם SSH חשוף, אך הנזק הפוטנציאלי היה גלובלי: כל הפצה שהשתמשה ב-xz-utils (כמו Fedora או Debian) נפגעה. המדאיג לא היה המורכבות הטכנית, אלא הסבלנות של התוקף לבנות זהות מזויפת ולהשפיע על המתחזק.

הדפוס הנסתר: כיצד התוקפים בוחרים את קורבנותיהם

מתחזקי חבילות קוד פתוח חולקים מאפיינים שהופכים אותם לפגיעים:

ב-CyberShield תיעדנו מקרים שבהם התוקפים שולחים מיילים עם נושאים כמו "דחוף: תיקון אבטחה ל-[חבילה]" או "התראה אבטחה של GitHub (מזויפת)". 80% מהמתחזקים פותחים מיילים אלו, ו-20% מקיימים אינטראקציה עם הקישור הזדוני (נתונים פנימיים ממעקב פישינג במאגרים באמריקה הלטינית).

SBOM: הרשימה שכולם מתעלמים ממנה (אך צריכים)

Software Bill of Materials (SBOM) הוא רשימה מפורטת של כל התלויות בפרויקט, כולל גרסאות ויחסים טרנזיטיביים. הסטנדרטים CycloneDX או SPDX מאפשרים ליצור SBOM באופן אוטומטי באמצעות כלים כמו syft או dependency-track. עם זאת, האימוץ נמוך:

SBOM יעיל צריך לכלול:

צוות CyberShield אימת כי פרויקטים שמיישמים SBOM מקצרים ב-40% את זמן התגובה לאירועים כמו xz-utils, מכיוון שהם יכולים לזהות במהירות אילו גרסאות מושפעות.

חתימות קריפטוגרפיות: מדוע GPG כבר לא מספיק

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

החלופה היא Sigstore, פרויקט של Linux Foundation שמפשט את חתימת הקוד באמצעות:

המקרה של in-toto (פרויקט נוסף של Linux Foundation) לוקח זאת צעד קדימה: הוא לא רק חותם על הקוד, אלא גם על תהליך הבנייה. תוקף שמשתלט על שרת CI/CD לא יוכל להזריק קוד זדוני מבלי לשבור את שרשרת החתימות.

בדיקת תלויות: החוליה שכולם מדלגים עליה

רוב הצוותים בודקים את הקוד שלהם, אך מתעלמים מהתלויות. כלים כמו:

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

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

  1. לתעדף תלויות קריטיות: להשתמש בכלים כמו depcheck כדי לזהות חבילות עם אימוץ גבוה ומעט מתחזקים.
  2. לבדוק שינויים חשודים: עלייה פתאומית בגודל חבילה או שינויים במבנה הקבצים עשויים להצביע על קוד זדוני.
  3. להשתמש בסנדבוקסינג: להריץ תלויות בסביבות מבודדות (כמו gVisor או Firecracker) כדי לזהות התנהגויות חריגות.

המקרה של xz-utils: לקחים שהתעשייה עדיין לא הפנימה

האירוע של xz-utils (מרץ 2024) חשף כשלים מערכתיים בשרשרת אספקת התוכנה:

תגובת הקהילה הייתה איטית: חלפו שבועיים בין גילוי הדלת האחורית לפרסום תיקונים רשמיים. במהלך תקופה זו, חברות כמו Red Hat ו-SUSE נאלצו לחזור לגרסאות ישנות של xz-utils, מה שגרם לחוסר תאימות במערכות שלהן.

הדאיג ביותר הוא ש-6 חודשים לאחר האירוע, 40% משרתי הלינוקס עדיין לא יישמו את התיקונים (נתונים מסריקות ציבוריות). זה מצביע על כך שהתעשייה לא הפנימה את הלקחים מ-xz-utils.

מה יכולות לעשות חברות באמריקה הלטינית כבר היום?

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

  1. לדרוש SBOM מספקים: כל תוכנה שנרכשת או משמשת חייבת לכלול SBOM בפורמט SPDX או CycloneDX. כלים כמו grype יכולים לנתח קבצים אלו כדי לזהות פגיעויות.
  2. ליישם חתימות Sigstore: להשתמש ב-cosign כדי לחתום על ארטיפקטים פנימיים ולאמת את החתימות של תלויות חיצוניות. זה קריטי במיוחד לחברות המשתמשות בתוכנת קוד פתוח בייצור.
  3. לבדוק תלויות טרנזיטיביות: לא מספיק לבצע ביקורת על תלויות ישירות. כלים כמו osv-scanner יכולים לנתח תלויות עד רמה 5 של עומק.
  4. להכשיר מפתחים בהנדסה חברתית: מתחזקי חבילות פנימיות צריכים לעבור הכשרה לזיהוי פישינג ממוקד, כמו מיילים המתחזים ל-GitHub Security או לעמיתים.
  5. להשתמש בסביבות מבודדות לבנייה: פרויקטים כמו Tekton Chains מאפשרים לחתום על ארטיפקטים ולרשום את תהליך הבנייה ביומן בלתי ניתן לשינוי.

ב-CyberShield אנו מספקים אבטחת סייבר 24/7 לעסקים קטנים ובינוניים באמריקה הלטינית עם מערכת ייחודית: סוכן endpoint רב-מערכתי, ניטור CVE בזמן אמת ותגובה 24/7. ראינו כיצד חברות שמיישמות את הצעדים הללו מפחיתות ב-70% את האירועים הקשורים לתלויות זדוניות. התוכנית הבסיסית, המכסה 2 צוותים תמורת 10 דולר לחודש, כוללת ניטור SBOM והתראות לתלויות קריטיות.

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

מקורות

  1. CISA (2023). Securing the Software Supply Chain: Recommended Practices Guide for Developers. NIST SP 800-218. URL: https://csrc.nist.gov/publications/detail/sp/800-218/final
  2. Red Hat (2024). CVE-2024-3094: Backdoor in xz tools. הודעה רשמית. URL: https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users
  3. Sigstore (2023). Sigstore Documentation: How It Works. URL: https://docs.sigstore.dev/
  4. in-toto (2023). in-toto: A Framework to Secure the Software Supply Chain. תיעוד רשמי. URL: https://in-toto.io/
  5. Sonatype (2023). State of the Software Supply Chain Report. URL: https://www.sonatype.com/resources/state-of-the-software-supply-chain-2023
  6. GitHub (2023). Octoverse Report: Security in Open Source. URL: https://octoverse.github.com/
  7. NPM (2023). Security Insights: Package Signing. URL: https://docs.npmjs.com/about-security
  8. מקרה event-stream (2018). Malicious code found in npm package event-stream. GitHub Advisory. URL: https://github.com/advisories/GHSA-6c8f-8966-r4rw
  9. מקרה ua-parser-js (2021). Compromised npm Package: ua-parser-js. CISA Alert AA21-291A. URL: https://www.cisa.gov/news-events/alerts/2021/10/22/compromised-npm-package-ua-parser-js