Red Hat נפגע מהתקפת שרשרת האספקה של npm – הנה איך להישאר בטוח
עקוב אחר ZDNET: הוסף אותנו כמקור מועדף בגוגל.
נקודות המפתח של ZDNET
- Red Hat היה קורבן של פרצת אבטחה npm.
- החברה הסירה את החבילות שנפגעו.
- בדוק אם אתה משתמש במרחב השמות של @redhat-cloud-services npm.
מרחב השמות של מאגר npm — סביבת זמן הריצה של JavaScript Node.js מנהל החבילות — ידוע לשמצה בשל פרצות אבטחה. כעת, ל-Red Hat, שעם יבמ הכריזה זה עתה על Project Lightwell, יוזמה מונעת בינה מלאכותית לאיתור ותיקון פרצות תוכנה בקוד פתוח, יש בעיית npm משלה.
גַם: אבטחת קוד פתוח היא בלגן – יבמ ורד האט הימרו על 5 מיליארד דולר ו-20,000 מהנדסים יכולים לתקן את זה
עשרות חבילות JavaScript במרחב השמות @redhat-cloud-services של החברה היו מכוסות בדלת האחורית בסודות תוכנות זדוניות גניבות אישורים המתמקדות במערכות אינטגרציה מתמשכות של מפתחי Red Hat ובמערכות פריסה מתמשכת (CI/CD). חברת מחקר האבטחה אייקידו דיווחה שמרחב השמות היה "נפגע עם תולעת גניבת אישורים. בסך הכל, 96 גרסאות על פני 32 חבילות נפגעו, הורדו מצטבר 116,991 פעמים בשבוע."
לפי האבטחה של Red Hat, מישהו השתמש ב- פגע בחשבון GitHub כדי להחדיר קוד זדוני לתוך חבילות המתוחזקות בארגון Red Hat GitHub. החבילות המושפעות הן ספריות חזיתיות שנאספו וארוזות לתמונות מיכל במהלך תהליך בניית המוצר של Red Hat.
מה בדיוק קרה?
נראה שהתוכנה הזדונית נוספה באמצעות npm preinstall hooks: בכל פעם שמפתח או מערכת build הריצו "npm install" עבור חבילה מושפעת, הקוד הזדוני הופעל אוטומטית. לפי צוות מודיעין האיומים של מיקרוסופט, כל אחד חבילה שנפרצה הוסיפה סקריפט להתקנה מראש שהפעיל מטעין index.js מנופח ומעורפל, שלאחר מכן הוריד והוציא לפועל מטען שנועד לשאוב סודות מסביבות npm, GitHub, AWS, SSH וסביבות אחרות.
חוקרים קשרו את המתקפה במהירות למסע פרסום רחב יותר המבוסס על תוכנת הזדונית Mini Shai-Hulud, תולעת הפצת npm ששימשה בתקריות קודמות בשרשרת האספקה. במקרה של Red Hat, דיווחים מרובים מתייחסים למטען כגרסה חדשה המכונה Miasma, השומרת על התנהגות ההתפשטות העצמית של Mini Shai-hulud תוך הוספת ערפול נוסף ועיצוב טעינה רב-שלבי.
התולעת עושה יותר מסתם גניבת אישורים. ברגע שהוא פועל על מחשב עם גישה לחבילות npm אחרות, הוא מזהה כל חבילה שהמשתמש הנוכחי יכול לפרסם ומפרסם אותן מחדש עם אותו מטען זדוני מראש להתקנה. כלומר, כל קורבן הופך לתוקף חדש. חברות אבטחה טוענות שההתנהגות ה"ניתנת לתילוע" היא שאיפשרה למרחב השמות הקשור ל-Red Hat להיות מזוהם כל כך מהר. כמה הערכות מצביעות על כך שיותר מ-30 חבילות בוצעו בדלת אחורית תוך דקות ספורות.
גַם: Red Hat Desktop לעומת Fedora Hummingbird: איזה נתיב לינוקס לפיתוח AI מתאים לך?
למרות ש-Red Hat עדיין לא פרסמה נתיחה שלאחר המוות מפורטת, ניתוחים עצמאיים מצביעים על תשתית GitHub שנפגעה בתור וקטור הגישה הראשוני. Semgrep וחברות מחקר אבטחה אחרות מדווחות כי הזדוני חבילות בהיקף של Red Hat נדחפו באמצעות אסימוני GitHub Actions OpenID Connect (OIDC) המשויך למאגר RedHatInsights/javascript-clients.
ברגע שנכנסו, התוקפים החדירו את ה-Hook מראש למספר חבילות וגרסאות, לעתים קרובות ללא שינויים מתאימים במאגרי המקור הציבוריים. זהו סימן היכר קלאסי של פשרה לבנות-צינור.
הקוד המבוצע סורק ומנסה לסנן את הדברים הבאים:
- סודות ואסימוני גישה של GitHub Actions
- מפתחות SSH של GitHub ואסימוני גישה אישיים
- אישורי ענן של AWS, GCP ו-Azure
- תצורה ואסימונים של Kubernetes
- אסימוני HashiCorp Vault ונתוני מנהל סודי אחרים
- אסימוני npm ו- CircleCI, בתוספת סודות CI/CD אחרים המאוחסנים במשתני סביבה או בקובצי תצורה
גַם: Rust תציל את לינוקס מ-AI, אומר גרג קרוה-הרטמן
ספקי אבטחה מזהירים שכל מי שהתקין את הגרסאות המושפעות על תחנת עבודה למפתחים, סוכן בנייה או רץ CI צריך להניח שכל האסימונים והאישורים הנגישים מסביבה זו עשויים להיות כעת בידיו של התוקף.
עבור מפתחים, הנחיות ממספר חברות מפורשות:
- סובב סודות מיד.
- בדוק את פעילות GitHub וענן לאיתור גישה חשודה.
- בנה מחדש כל סביבה שעלולה להיות מזוהמת מקווי בסיס ידועים וטובים.
Red Hat אמרה לי, "התחלנו מיד בחקירה והסרנו את החבילות מהרישום של npm. החבילות מוגבלות בהחלט לפיתוח פנימי, והקוד הזדוני מעולם לא פורסם לצריכה של לקוחות דרך מערכת console.redhat.com. בזמן שהחקירה שלנו נמשכת, לא זיהינו כל השפעה על סביבות לקוחות או שותפים או מערכות הייצור של Red Hat".
בקיצור, זה יכול היה להיות הרבה יותר גרוע.
גַם: אובונטו 26.04 היא מערכת ההפעלה לעידן סוכן הבינה המלאכותית, אומר מארק Shuttleworth של Canonical
קודם לכן, הנחיות כלליות יותר לגבי התקפות שרשרת האספקה של npmRed Hat Product Security הצהירה כי מוצריה מסתמכים במידה רבה על הצמדת גרסאות קפדנית ומראות פנימיות, וכי לא שולבו חבילות npm שנפגעו בעבר בתוכנת Red Hat נתמכת.
עם זאת, בעקבות התקרית האחרונה, חוקרי אבטחה קוראים לארגונים לא להניח שהם בטוחים רק בגלל שהם משתמשים בהצעות של Red Hat. הם טוענים שיש להתייחס לכל זרימת עבודה של בנייה או מפתח שנגע בחבילות בדלת האחורית כעל פוטנציאל לפגיעה.
מה כדאי לעשות עכשיו?
בעוד Red Hat מבטיח לכולם שהקוד הרע לא הגיע לציבור, אני נשאר זהיר. אם אתה מסתמך על כלי שירותי ענן של Red Hat או שאי פעם משך חבילות @redhat-cloud-services לתוך ה-builds שלך, הייתי ממליץ לסרוק עצי תלות עבור הגרסאות המושפעות, לחסום את המהדורות הגרועות הידוע, ולשדרג לאחור או להחליפן ב-builds מהימן במידת הצורך.
יחד עם זאת, הייתי מניח שלכל סביבה שבה הותקנו החבילות הללו ייתכן שהסודות שלה נחשפו, וסובב את כל האישורים הרלוונטיים, למשל, GitHub PATs, מפתחות SSH, מפתחות API של ספק ענן ואסימוני CI.
גַם: עד כמה הארגון שלך ריבוני מבחינה דיגיטלית? כלי Red Hat זה יכול להגיד לך תוך דקות
בטווח הארוך, תקרית npm של Red Hat מראה שוב שמאגרי npm אינם כל כך אמינים. כאשר אפילו ספקי לינוקס וענן כבדי משקל פגיעים כעת באופן מוכח לתוכנות זדוניות ניתנות לתילוע של npm, הלחץ גובר הן על הסדרנים של npm והן על ספקי התוכנה הגדולים לספק ערבויות חזקות יותר לגבי המוצא והבטיחות של החבילות שלהם.
במילים אחרות, בעוד שלרד האט אולי יש עוגה על הפנים מהפרק הזה, זה גם מדגיש עד כמה חשוב Project Lightwell ומאמצים דומים, כגון המאמצים של Chainguard למצוא דרך לשפר את אבטחת הקוד הפתוח של כולםהם.