מתקפת הסייבר על Bitwarden: מה קרה וכיצד להגן על מערכות
ב-22 באפריל השנה, חבילת npm זדונית הופיעה תחת השם הרשמי @bitwarden/[email protected], וגרמה לחשש רב בקרב משתמשי Bitwarden. במשך 93 דקות, כל מי שהוריד את הכלי דרך npm נחשף לגרסה עם דלת אחורית, במקום הכלי החוקי. Bitwarden זיהתה במהירות את הפריצה, הסירה את החבילה והוציאה הצהרה שמרגיעה את המשתמשים כי לא נמצאו ראיות לכך שהתוקפים גשו לנתוני הכספות או פגעו במערכות הייצור.
חברת המחקר JFrog ניתחה את המטען הזדוני וגילתה שהתקיפה כוונה לטוקנים של GitHub, טוקנים של npm, מפתחות SSH, היסטוריית הפקודות, אישורי AWS, GCP, Azure, סודות של GitHub Actions וקבצי תצורה של כלי AI. אלו הם אישורים קריטיים לניהול תשתיות, מה שמצביע על כוונה לפגוע בתהליכי העבודה של ארגונים.
Bitwarden, המשרתת מעל 50,000 עסקים ו-10 מיליון משתמשים, מתארת את CLI שלה ככלי עוצמתי לניהול כספות בתהליכי עבודה אוטומטיים. השימוש ב-npm להתקנה הופך את ה-CLI לנקודת תורפה פוטנציאלית עבור תוקפים המחפשים גישה לסודות תשתית.
ההתקפה ככל הנראה ניצלה פעולה של GitHub Action שנפגעה בצנרת ה-CI/CD של Bitwarden, כחלק מקמפיין שרשרת האספקה של Checkmarx. המודל של npm לפרסום אמין נועד להתמודד עם סיכונים מסוג זה, על ידי שימוש באימות CI/CD מבוסס OIDC. עם זאת, לוגיקת השחרור עצמה, כגון תהליכי העבודה והפעולות המפעילות את שלב הפרסום, נותרה פגיעה.
הניתוח של JFrog מראה שמחשב נייד של מפתח שהתקין חבילה רשמית מזוהמת יכול להפוך לגשר שמאפשר גישה מתמשכת לתשתית האוטומציה של הארגון. האירוע מדגים את הצורך בהקשחת תהליכי העבודה והגנה על נתיבי ההפצה מפני תוקפים.
כיום, פרסום אמין מצמיד נתוני מקור לכל חבילה שפורסמה, ובכך מאשר את זהות המפרסם ברגיסטרי. אם הסטנדרט הזה יהפוך לנורמה, "רשמי" יתחיל להיות "נבנה על ידי תהליך העבודה הנכון תחת המגבלות הנכונות".
השאלה הגדולה שנותרת היא כיצד ניתן לחזק את מערכות ההגנה מפני סוג זה של מתקפות סייבר? האם אתם חושבים שמערכות האימות והפרסום הנוכחיות מספיקות או שיש צורך בשדרוגים נוספים? שתפו את מחשבותיכם והצעותיכם לשיפור האבטחה.