לאחרונה נודע דרך פוסט בבלוג, תוצאות כלי הבדיקה לזיהוי פגיעויות ללא תיקון ולזהות בעיות אבטחה בתמונות מיכל Docker מבודדות.
הבדיקה הראתה כי 4 מתוך 6 הסורקים תמונות Docker ידועות היו עם פגיעות קריטיות שאפשר לתקוף את הסורק עצמו ולהריץ את הקוד שלו במערכת, במקרים מסוימים (באמצעות Snyk למשל) עם הרשאות שורש.
להתקפה, תוקף רק צריך לבדוק את קובץ ה- Dockerfile שלו או manifest.json, שכולל מטא נתונים מעוצבים במיוחד, או הכניסו את קובץ ה- pods והדרגו קבצים בתוך התמונה.
אנו מצליחים להכין אבות-טיפוס למערכות WhiteSource, Snyk, Fossa ומעגן.
El paquete קלייר, נכתב במקור עם בטיחות בראש. הראה את הביטחון הטוב ביותר.
לא זוהו בעיות בחבילת Trivy וכתוצאה מכך, הגיעו למסקנה כי יש להריץ סורקי מכולות של Docker בסביבות מבודדות או להשתמש בהם רק כדי לאמת את התמונות שלהם, וכן להיזהר בעת חיבור כלים כאלה למערכות אינטגרציה רציפות אוטומטיות.
סורקים אלה עושים דברים מסובכים ומועדים לטעויות. הם מתמודדים עם העגינה, מחלצים שכבות / קבצים, מתקשרים עם מנהלי חבילות או מנתחים פורמטים שונים. ההגנה עליהם, תוך ניסיון להכיל את כל מקרי השימוש למפתחים, קשה מאוד. בואו נראה כיצד הכלים השונים מנסים ומצליחים לעשות זאת:
ציון הגילוי האחראי משקף את דעתי האישית: אני חושב שחשוב שספקי התוכנה יהיו פתוחים לבעיות אבטחה שדווחו להם, יהיו כנים ושקופים בנוגע לפגיעות, כדי להבטיח שאנשים שמשתמשים במוצריהם יידעו כדי לקבל החלטות על העדכון. זה כולל את המידע החשוב ביותר שלעדכון יש שינויים רלוונטיים לאבטחה, פתיחת CVE למעקב אחר תקשורת אודות הבעיה, ואולי להודיע ללקוחות שלך. אני חושב שזה סביר במיוחד להניח שאם המוצר עוסק ב- CVE, ומספק מידע על נקודות תורפה בתוכנה. כמו כן, אני מרגיע בשל התגובה המהירה, זמני התיקון הסבירים והתקשורת הפתוחה עם האדם המדווח על ההתקפה.
ב- FOSSA, Snyk ו- WhiteSource, הפגיעות הייתה קשורה עם התקשרות למנהל חבילות חיצוני כדי לקבוע את התלות ולאפשר לך לארגן את ביצוע הקוד שלך על ידי ציון פקודות המגע והמערכת בקבצי ה- gradlew ו- Podfile.
En Snyk ו- WhiteSource מצאו גם פגיעות הקשורה לפקודות מערכת ההשקה ארגון שניתח את Dockerfile (לדוגמה, ב- Snyk דרך Dockefile אתה יכול להחליף את השירות ls (/ bin / ls), הנגרם על ידי הסורק וב- WhiteSurce אתה יכול להחליף את הקוד באמצעות הטיעונים בצורה של "הד"; הקש / tmp / hacked_whitesource_pip; = 1.0 '«).
באנקורה, הפגיעות נגרמה על ידי השימוש בכלי השירות skopeo לעבוד עם תמונות העגינה. הפעולה הצטמצמה להוספת פרמטרים של הטופס '»os»: «$ (touch hacked_anchore)»' לקובץ manifest.json, אשר מוחלפים בעת קריאה ל- skopeo ללא בריחה מתאימה (רק התווים «; & <הוסרו > ", אבל הקונסטרוקציה" $ () ").
אותו מחבר ערך מחקר על יעילות זיהוי הפגיעות לא טלאים באמצעות סורקי אבטחה של מכולות העגינה ורמת התגובות השגויות.
מלבד המחבר טוען כי כמה מהכלים הללו השתמש ישירות במנהלי חבילות כדי לפתור תלות. זה מקשה עליהם במיוחד להתגונן. לחלק ממנהלי התלות יש קבצי תצורה המאפשרים הכללת קוד מעטפת.
גם אם מטפלים בדרך כלשהי בדרכים הפשוטות הללו, קריאה למנהלי חבילות אלה פירושה בהכרח הפגזת כסף. זה, בלשון המעטה, אינו מקל על הגנת הבקשה.
תוצאות הבדיקה של 73 תמונות המכילות נקודות תורפה ידוע, כמו גם הערכה של היעילות לקביעת נוכחותם של יישומים אופייניים בתמונות (nginx, tomcat, haproxy, gunicorn, redis, ruby, node), ניתן להתייעץ במסגרת הפרסום שנעשה בקישור הבא.