טעות של תו אחד שהעבירה תוכנה זדונית
זה התחיל עם שגיאת הקלדה. איפשהו בתוך הגל העצום של קידום פיצ'רים ומיזוגי יחסי ציבור, מישהו הקליד @utils_core במקום @utils-core אל package.json. אות בודדת זו לא גרמה לשגיאה. במקום זאת, היא משכה בשקט חבילה זדונית דומה במהלך הבא CI/CD לרוץ, תוך מינוף אמון בגרסאות מוצמדות ואוטומציה. ברוכים הבאים לעולם של טיפוסקווטינג בקוד פתוח.
טיפוסקווטינג: וקטור ההתקפה שמשגשג על טעויות אנוש
טיפוסקווטינג זה בדיוק מה שזה נשמע: גורמים זדוניים רושמים חבילות עם שמות כמעט זהים לאלה לגיטימיים. בסביבות מהירות, זה עובד מכיוון שמפתחים סומכים על כך שהן package.json ו package-lock.json משקף את מה שהם מצפים לו. תו אחד שונה? זה יכול באותה מידה להיות בלתי נראה בהפרש יחסי ציבור.
NPM יש היסטוריה של ניצול באמצעות typosquatting. חבילות כמו קרוסאנב במקום סביבה צולבת or זרם אירועים דלתות אחוריות כבר הראו עד כמה יעילותן של חבילות דומות אלו יכולות להיות. חבילות מזויפות אלו עוברות לעיתים קרובות ביקורות פשוט משום שהן נראות נכון ואינן גורמות לשגיאות זמן ריצה מיידיות.
מלכודות נפוצות כוללות:
- מקף לעומת קו תחתון: lאודאש-ליבה vs לודש_ליבה
- רבים: לבקש vs בקשות
- תווים שהוחלפו: אקספרס במקום אקספרס
היכן ש-package-lock.json הופך לנקודה עיוורת
המפתח מתקן את שגיאת ההקלדה שלו. או לפחות כך הם חושבים. אבל עכשיו, package-lock.json כבר נעל את החבילה של התוקף. וכאן מסתתר הסיכון האמיתי.
שונה package.json, אשר נערך באופן ידני ועובר בדיקה מדוקדקת יותר, package-lock.json נוצר אוטומטית על ידי NPMכתוצאה מכך, לעתים קרובות מתייחסים אליו כאל פורמליות, מדלגים עליו, או רק מדלגים עליו. pull request ביקורות. לא נדיר שצוותים יסמנו אותו כ"רועש מדי" או יסמכו עליו באופן מרומז ללא בדיקה מעמיקה.
תוקפים יודעים זאת. הם מסתמכים על זה. ברגע ש... חבילה זדונית מופנית, הודות לשגיאת הקלדה ב package.json, package-lock.json מתעד את הגרסה שנפתרה. גם אם שגיאת ההקלדה מתוקנת מאוחר יותר, הערך הזדוני יכול להימשך אלא אם כן קובץ הנעילה נוצר מחדש במפורש.
וכדי להחמיר את המצב, הצמדת גרסאות, שאמורה להבטיח עקביות, יכולה לגרום לתוצאה הפוכה. תוקפים יכולים לגרסת את החבילה המזויפת שלהם באופן זהה לגרסה הלגיטימית. אם ה... CI/CD כאשר המערכת סומכת על גרסאות מוצמדות באופן עיוור, היא לא תזהה שהיא מתקינה חבילה עם מספר גרסה ידוע כתקין אך ממקור אחר וזדוני.
ההתמדה השקטה הזו היא מה שגורמת package-lock.json כל כך מסוכן. זה מבטיח בניות דטרמיניסטיות, כן, אבל זה גם מבטיח שחבילה פגומה תישאר בסביבה אלא אם כן היא נתפסת ונוקה ידנית.
CI/CDהיכן פוגעת התוכנה הזדונית – package.json
ב טיפוסי CI/CD pipeline, החבילה הזדונית לא צריכה לחכות עד לזמן הריצה. היא נפתרת ומופעלת הרבה יותר מוקדם בזרימה:
פתרון תלות
השמיים pipeline מושך את גרסאות התלות המדויקות מ-ppackage-lock.json, אשר כעת כולל את חבילה מסוג typosquatted עקב שגיאת הקלדה ב package.json.
שלב ההתקנה
במהלך npm ci, כל התלויות מותקנות, כולל התלויה הזדונית. אין אזהרות, אין הנחיות, רק התקנה שקטה.
ביצוע סקריפט לאחר ההתקנה
חבילת הדומה כוללת סקריפט לאחר ההתקנה שפועל אוטומטית לאחר השלמת ההתקנה. כאן מתרחשת הפגיעה.
דוגמה לפסאודו-קוד:
תיאור פסאודו-קוד:
במהלך שלב ההתקנה, אם קיים ה-hook של מחזור החיים שלאחר ההתקנה, החבילה המזויפת מפעילה את הלוגיקה הנסתרת שלה - לעתים קרובות עוד לפני ש-builds או בדיקות בכלל רצים. זה עשוי לכלול ביצוע בקשות חיצוניות, הזרקת דלתות אחוריות או פעולות לא מורשות אחרות.
⚠️ אזהרה: פסאודו-קוד זה מיועד למטרות הדגמה בלבד ואין להשתמש בו בסביבות אמיתיות.
לא מופעלות התראות. שום דבר לא נכשל. הסביבה כבר נפגעה, לפני שלך pipeline אפילו מגיע לשלב הבדיקה.
לזהות את ההבדל לפני שיהיה מאוחר מדי
טעות נפוצה: הנחה package.json מספר את הסיפור כולו. זה לא. הכוח האמיתי טמון בשילוב של package.json + package-lock.json.
הנה מה לחפש:
- האם package-lock.json לכלול חבילות בלתי צפויות?
- האם תלויות כלשהן מקורן ברישומים לא ידועים או שיש להן היקפים מוזרים?
- האם מספרי הגרסאות ספציפיים מדי או לא מיושרים?
השתמש בכלי CLI כמו:
- ביקורת npm לסמן בעיות ידועות
- npm ls כדי לצפות בעץ התלות המלא
- הבדל כדי להשוות גרסאות בין package.json ו package-lock.json
הקשח את שלך Pipelineהגנות שעובדות
כדי להתגונן מפני טיפוסקווטינג:
- אכיפת מגבלות היקף ב package.json.
- הוסף מיזוג מקדים hooks כדי לאמת תלויות.
- השתמש npm ci כדי למנוע סטייה לא מכוונת של הגרסה.
- סרוק באופן קבוע package-lock.json עבור אנומליות.
והכי חשוב: התייחסו לרשומות שלא אומתו ב package-lock.json כסיכונים פוטנציאליים. כל commit יש להתייחס אליהם כאל נקודת ביקורת בשרשרת האספקה.
זיהוי אוטומטי: כיצד כלים כמו Xygeni עוזרים
אמנם לא פתרון קסם, כלים אוטומטיים כמו קסיגני למלא תפקיד קריטי בהפחתת גורם השגיאות האנושיות, שממנו משגשגת typosquatting. Xygeni משתלב ישירות בתהליך העבודה של DevOps שלך, ומוסיף שכבת הגנה בזמן אמת מפני חטיפת תלויות עוד לפני שהיא מגיעה לביצוע.
כך Xygeni עוזר:
- זיהוי שם חבילה חשוד:
משתמש בהיוריסטיקה חכמה כדי לזהות דפוסי טיפוסקווטינג ב package.json, מחפש וריאציות קלות בשמות חבילות ידועים (כמו קווים תחתונים, טרנספוזיציות או החלפות אותיות). - אימות גיבוב לא ידוע:
משווה את ה-hash של כל תלות ב package-lock.json מול מסד נתונים של ארטיפקטים ידועים כתקינים מרישומים מהימנים. גם אם שם החבילה והגרסה נראים תקינים, אי התאמה ב-hash מעוררת דגל אדום. - חסימה לפני הבנייה:
מיירט וחוסם התקנה של חבילות לא מאומתות או חשודות לפני שהן מגיעות לשלבי ההתקנה או לאחר ההתקנה. CI/CD pipeline. - ניתוח גרף תלות:
בודק באופן רציף את עץ התלות המלא לאיתור ניסיונות typosquatting עקיפים או תלויות טרנזיטיביות זדוניות. - התראות ודיווח:
מספק התראות מפורטות ובעלות פעולה, המציגות מה סומן, מדוע ומהיכן הוא הגיע בשרשרת התלות.
ככל שמערכות אקולוגיות של חבילות הופכות מורכבות יותר, כלים כמו Xygeni הופכים חיוניים. סקירה ידנית אינה מתרחבת עם התפשטות תלויות או איטרציות מהירות. Xygeni נכנסת לתמונה כדי להפוך את הבדיקות הקריטיות לאוטומטיות. pipelineהצורך של זה, סגירת הפער בין אמון לאימות.
דמות אחת. השלכות אמיתיות.
זה לא היה אקזוטי אפס-יוםזו הייתה שגיאת הקלדה. תו אחד לא במקום package.json, מחוזק בשקט על ידי package-lock.jsonותוכנה זדונית נשלחה באופן אוטומטי במהלך שגרה CI/CD לָרוּץ.
זוהי הסכנה האמיתית של טיפוסקווטינג: זה לא צריך מורכבות. זה מנצל מהירות, אמון ואוטומציה. ניתן היה למנוע את הפשרה הזו בעזרת הבקרות הנכונות:
- סריקה אוטומטית כדי לתפוס שמות וגרסאות חשודות של חבילות לפני ההתקנה.
- ביקורת נעילת קבצים כדי לזהות ערכים שלא נבדקו או בלתי צפויים ב package-lock.json.
- היוריסטיקות לאימות שם לסמן התאמות כמעט מוחלטות לחבילות מהימנות.
תו אחד היה כל מה שצריך. הבדיקות הנכונות היו עוצרת את זה לפני שזה נגע בך pipelineאמון אינו מספיק. ב-DevSecOps מודרני, אתה מאמת הכל, או מסכן הכל.
