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

מדוע דיג ההונאה בשרשרת האספקה הוא המתקפה שלא ראינו מגיעה?

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

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

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

הדפוס הנסתר: כיצד תוקפים מבצעים פישינג למפתחים (מבלי שהם ישימו לב)

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

  1. המפתח העוזר: תורמים תיקונים קטנים במשך חודשים, צוברים מוניטין. דוגמה: התוקף מאחורי xz-utils שלח עשרות קומיטים לגיטימיים לפני שהכניס את הדלת האחורית. הטכניקה ידועה בשם trust laundering (הלבנת אמון).
  2. המתחזק העייף: מזהים פרויקטים נטושים או עם תחזוקה מועטה ומציעים עזרה. בשנת 2021, החבילה ua-parser-js נפגעה כאשר תוקף הציע "להמודרניזציה" של הקוד. המתחזק, המוצף בבקשות, העביר את ההרשאות ב-npm.
  3. הספונסר המזויף: מתחזים לעובדים בחברות המשתמשות בחבילה ומציעים מימון או משאבים. בשנת 2020, תוקף התחזה למהנדס של מיקרוסופט כדי לקבל גישה למאגר של electron-native-notify.

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

מדוע אמצעי ההגנה המסורתיים נכשלים (ומה כן עובד)

חברות נוהגות ליישם בקרות אבטחה בשתי שכבות: לפני שהקוד נכנס למאגר (SAST/DAST) ואחרי שהוא מופעל (WAF, EDR). אך פישינג בשרשרת אספקה מתרחש במרחב שלישי: במהלך רכישת תלויות. כאן, הכלים המקובלים עיוורים:

אם כן, אילו אמצעי הגנה כן עובדים? אלה שהצוות של CyberShield אימת בסביבות ייצור:

  1. SBOM (רשימת חומרי תוכנה): מלאי מפורט של כל התלויות, כולל המתחזקים שלהן ו-hash של גרסאות. כלים כמו syft או dependency-track יוצרים SBOM באופן אוטומטי. אך שימו לב: SBOM סטטי אינו מזהה שינויים בהתנהגות של חבילה. נדרשים SBOM דינמיים המתעדכנים עם כל build.
  2. חתימות קריפטוגרפיות עם Sigstore: Sigstore (פרויקט של Linux Foundation) מאפשר לחתום על קומיטים ו-git tags עם מפתחות ארעיים, המקושרים לזהויות מאומתות. בשנת 2023, 30% מהחבילות ב-npm כבר השתמשו בחתימות Sigstore (Sigstore, 2023). אזהרה: חתימות אינן מונעות ממתחזק לגיטימי להיפגע, אך הן מאפשרות לעקוב אחר מקור הקוד.
  3. בדיקת תלויות עם ניתוח התנהגות: כלים כמו osv-scanner או dep-scan לא רק מחפשים פגיעויות ידועות, אלא מנתחים מה הקוד עושה בזמן ריצה. לדוגמה, אם חבילת לוגינג פתאום מנסה לפתוח סוקטים בפורטים לא סטנדרטיים, הכלי מסמן זאת כחשוד.
  4. מדיניות "תאמין אך ודא": להניח שכל תרומה חיצונית היא פוטנציאלית זדונית. ב-CyberShield, הטמענו תהליך שבו כל pull request ממפתח חדש נבדק על ידי שני מהנדסים ועובר סביבת בדיקה מבודדת לפני מיזוג. כן, זה מאט את הפיתוח. זה גם מונע דלתות אחוריות.

המקרה של xz-utils: אנטומיה של מתקפה שכמעט הצליחה

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

  1. שלב 1: הסתננות (2021-2022): התוקף, שהשתמש בכינוי Jia Tan, החל לתרום תיקונים קטנים לפרויקט. בתוך שנה, הפך לאחד מהתורמים הפעילים ביותר, וזכה באמונו של המתחזק המקורי, Lasse Collin.
  2. שלב 2: ניצול התשישות (2023): קולין, המוצף באחריות הפרויקט, הודיע ברשימות תפוצה שהוא שוקל לנטוש את התחזוקה. Jia Tan הציע עזרה, וקולין העניק לו הרשאות פרסום במאגר.
  3. שלב 3: הזרקת הדלת האחורית (פברואר 2024): בגרסאות 5.6.0 ו-5.6.1, Jia Tan הכניס קוד זדוני מוסתר בקבצי בדיקה (tests/files/bad-3-corrupt_lzma2.xz). הדלת האחורית שינתה את הפונקציה RSA_public_decrypt ב-liblzma, ואפשרה ביצוע קוד מרחוק אם החבילה שימשה את sshd.
  4. שלב 4: הפצה (מרץ 2024): התוקף לחץ על הפצות לינוקס (כמו Fedora ו-Debian) לעדכן לגרסאות הפגועות, בטענה ל"שיפורי ביצועים".

המתקפה התגלתה במקרה כאשר מהנדס במיקרוסופט, Andres Freund, הבחין כי sshd צורך 500% יותר מעבד בגרסאות החדשות של xz-utils. ניתוח מאוחר יותר גילה כי הדלת האחורית הופעלה רק אם התהליך האב היה sshd, ובכך נמנעה גילויה בסביבות בדיקה.

לקחים מרכזיים מהמקרה:

מדוע עסקים קטנים ובינוניים באמריקה הלטינית הם המטרה המושלמת (וכיצד להגן על עצמך)

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

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

אלה הצעדים המינימליים שאנו ממליצים עליהם, בהתבסס על מה שהטמענו ב-CyberShield עבור לקוחות באזור:

  1. יצירת SBOM לכל הפרויקטים: שימוש בכלים כמו syft או trivy ליצירת מלאי של תלויות. זה לא אופציונלי: בשנת 2023, 70% מהפגיעויות בתוכנה מסחרית הגיעו מתלויות צד שלישי (Sonatype, 2023).
  2. אימות חתימות חבילות עם Sigstore: לפני התקנת תלות, לוודא שהיא חתומה עם זהות מאומתת. כלים כמו cosign מאפשרים אוטומציה של תהליך זה ב-CI/CD.
  3. הטמעת "בידוד" לתלויות חדשות: כל חבילה חדשה חייבת לעבור סביבת בדיקה מבודדת שבה מנתחים את התנהגותה (רשת, מערכת קבצים, קריאות ל-API). ב-CyberShield, אנו משתמשים ב-falco לניטור התנהגויות חריגות בזמן אמת.
  4. הגבלת הרשאות מתחזקים: שימוש במודלים כמו two-person rule לשינויים קריטיים. ב-GitHub, זה מוגדר באמצעות CODEOWNERS ובדיקות חובה.
  5. ניטור שינויים במתחזקים: כלים כמו deps.dev מתריעים כאשר חבילה מחליפה בעלים. בשנת 2022, 15% מהחבילות ב-npm עם יותר ממיליון הורדות החליפו מתחזק ללא הודעה (npm, 2022).

העתיד: האם נוכל לסמוך על קוד פתוח?

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

הצעות קונקרטיות להפחתת הסיכון:

קוד פתוח אינו הבעיה. הבעיה היא ההנחה כי מכיוון שהוא פתוח, הוא בטוח. כפי שאמר דן לורנס (יוצר Sigstore): "קוד פתוח אינו מודל אבטחה. הוא מודל שקיפות. האבטחה צריכה להיבנות מעליו".

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

מקורות

  1. CISA (2023). Software Supply Chain Risk Management. מדריך לשיטות עבודה מומלצות. https://www.cisa.gov/resources-tools/services/software-supply-chain-risk-management
  2. NIST (2024). CVE-2024-3094 Detail. פגיעות ב-xz-utils. https://nvd.nist.gov/vuln/detail/CVE-2024-3094
  3. Sigstore (2023). Sigstore Annual Report. אימוץ חתימות קריפטוגרפיות בחבילות קוד פתוח. https://blog.sigstore.dev/sigstore-2023-year-in-review-2a35e4e0154a
  4. Sonatype (2023). State of the Software Supply Chain Report. ניתוח פגיעויות בתלויות צד שלישי. https://www.sonatype.com/resources/state-of-the-software-supply-chain-2023
  5. Freund, A. (2024). Backdoor in xz/liblzma: Leading to ssh server compromise. ניתוח טכני של CVE-2024-3094. https://www.openwall.com/lists/oss-security/2024/03/29/4
  6. npm (2022). npm Acquires Lift Security and its Node Security Platform. סטטיסטיקות על שינויים במתחזקים בחבילות npm. https://blog.npmjs.org/post/626173315965468672/npm-acquires-lift-security-and-its
  7. in-toto (2023). in-toto: Framework for Supply Chain Integrity. תיעוד רשמי. https://in-toto.io/
  8. SLSA (2024). Supply-chain Levels for Software Artifacts. מפרט רמות אבטחה לשרשראות אספקה. https://slsa.dev/
  9. OpenSSF (2024). Scorecard: Security Health Metrics for Open Source. כלי להערכת סיכונים במאגרים. https://github.com/ossf/scorecard
  10. Lorenc, D. (2022). Sigstore: Bringing Trust to Open Source Software. הרצאה בכנס Open Source Summit. https://www.youtube.com/watch?v=Jp0lP4zybQI