תוצאות בדיקה עבור כלים לזיהוי פגיעויות שלא תוקנו וגילוי בעיות אבטחה בתמונות מכולות מבודדות של Docker גילו שארבע מתוך שישה סורקי תמונות Docker ידועים הכילו פגיעויות קריטיות שעלולות לאפשר לתוקפים לתקוף ישירות את הסורק ולבצע קוד במערכת, במקרים מסוימים (לדוגמה, בעת שימוש ב-Snyk) עם הרשאות root.
כדי לבצע מתקפה, תוקף פשוט צריך ליזום בדיקה של ה-Dockerfile או ה-manifest.json שלו, הכוללים מטא-נתונים בפורמט מיוחד, או למקם קבצי Podfile ו-gradlew בתוך התמונה. ניצול אבות טיפוס. עבור מערכות
, ,
и
החבילה הראתה את האבטחה הטובה ביותר. , נכתב במקור תוך מחשבה על אבטחה. גם בחבילה לא נמצאו בעיות. בסופו של דבר, הגענו למסקנה שיש להפעיל סורקי מכולות של Docker בסביבות מבודדות או להשתמש בהם רק לבדיקת תמונות מותאמות אישית, ויש לנקוט משנה זהירות בעת חיבור כלים כאלה למערכות אינטגרציה רציפה אוטומטיות.
ב-FOSSA, Snyk ו-WhiteSource, הפגיעות הייתה קשורה לקריאה למנהל חבילות חיצוני כדי לקבוע תלויות ואפשרה ביצוע קוד מותאם אישית על ידי ציון פקודות מגע ופקודות מערכת בקבצים. и .
גם לסניק ול-WhiteSource היו , עם ארגון הפעלת פקודות מערכת בעת ניתוח Dockerfile (לדוגמה, ב-Snyk, ניתן היה להחליף את כלי השירות /bin/ls שנקרא על ידי הסורק באמצעות Dockefile, וב-WhiteSource ניתן היה להחליף קוד באמצעות ארגומנטים בצורה "echo ';touch /tmp/hacked_whitesource_pip;=1.0′").
לאנקורה יש פגיעות שימוש בכלי השירות לעבודה עם תמונות Docker. הניצול כלל הוספת פרמטרים כמו "os": "$(touch hacked_anchore)" לקובץ manifest.json, אשר הוחלפו בעת קריאה ל-skopeo ללא תווי Escape מתאימים (רק התווים ";&<>" הוסרו, אך המבנה "$()" הותר).
אותו מחבר ערך מחקר על יעילות גילוי פגיעויות שלא תוקנו על ידי סורקי אבטחת קונטיינרים של Docker ועל רמת התוצאות החיוביות השגויות (false positives)., , להלן תוצאות בדיקת 73 תמונות המכילות פגיעויות ידועות, וכן הערכה של יעילות גילוי נוכחותן של יישומים אופייניים בתמונות (nginx, tomcat, haproxy, gunicorn, redis, ruby, node).
מקור: OpenNet.ru
