5 נקודות תורפה של Docker שאתם חייבים להכיר

הפופולריות הגואה של הקונטיינרים הווירטואליים מחייבת התייחסות לנקודות התורפה של פרויקט הקוד הפתוח המוביל בתחום. מהן 5 נקודות התורפה העיקריות וגם כמה טיפים לצמצום פוטנציאל הנזק שלהם

צילום / תמונה: Pixabay

מאת גבריאל אבנר

קונטיינרים וירטואליים הפכו לאחד הטרנדים המובילים בתחום פיתוח התוכנה בשנים האחרונות. מפתחים אוהבים את העובדה שהם יכולים לארוז, לבדוק ולפרוס קוד בלי כל המהמורות שבאות עם המעבר מסביבה אחת לשנייה. ההובלה בתחום הקונטיינרים הווירטואליים היא ללא ספק של פרויקט הקוד הפתוח DOCKER, שלוגו הלוויתן הכחול שלו הפך להיות מילה נרדפת לטכנולוגית קונטיינר.

יתרונות בתחום האבטחה

לקונטיינרים וירטואליים יש כמה יתרונות בתחום האבטחה. הראשון, הוא העובדה שהם יחידות תוכנה מבודדות, מה שמקשה על שחקנים פוגעניים להסלים מנקודת תורפה באפליקציה אחת לאחרת או למערכת ההפעלה עצמה. DOCKER משתמשת בפיצ’רים לבידוד של לינוקס כמו kernel namespaces ו- cgroups המאפשרים לקונטיינרים לפעול במסגרת שרת לינוקס (Linux instance) אחד.

היתרון השני הוא העובדה שהקונטיינרים של DOCKER הם קטנים ובדרך כלל מתרכזים ביחידות תוכנה שבאופן מובנה לא מאפשרות הרבה פתחים שיכולים להיות פגיעים, או מקומות להחביא תוכנות זדוניות יותר מורכבות.

עם זאת, עדיין ישנן דרכים בהן האקרים יכולים לברוח מהמגבלות של ה-kernel ולקבל גישה לחלקים אחרים במחשב או התשתית (על כך נרחיב כשנדבר על נקודת התורפה runC). בנוסף, למרות שממדים קטנים משמע שטח פנים התקפי קטן, הנטייה שלהם “לפטפט” מובילה לכך שישנם יותר חלקים שזזים היכולים להוות מטרה לכל יריב.

ההסתמכות על Linux karnel היא המקור לנקודות התורפה של DOCKER. בשנת 2018 דווח כי מעל 180 נקודות תורפה נמצאו ב-Linux kernel, מה שהשאיר משתמשי קונטיינר רבים חשופים למתקפות. מיותר לציין שאם האחסון שלך חשוף – כל הקונטיינרים שמשתמשים בו נמצאים בסיכון אף הם.

אז בואו נכיר מקרוב את 5 נקודות התורפה הקריטיות של DOCKER וטיפים לצמצום פוטנציאל הנזק שלהן:

מספר 1: runC Root Access Remote Execution

זירת הקונטיינרים הווירטואליים לא חוותה כזה סחרור מאז נקודת התורפה שהתגלתה ב-Kubernetes בדצמבר 2018.

פרויקט הקוד הפתוח runC, שמפעיל את יכולות ה-runtime כמעט בכל טכנולוגיות הקונטיינר של הספקים השונים, נמצא תחת סיכון השתלטות בשל נקודת תורפה שאפשרה לתוקפים root access למארח, זאת על ידי דריסה של הקוד הבינארי של ה-runC שלה.

התקלה עם ה-CVE-2019-5736 עברה שדרוג מדירוג ה-CVSS v3 הראשוני שלה ל-8.6 המתאים יותר. נקודת תורפה זו הדגישה את הסיכון שבתמונות הנשלטות על ידי התוקף וכן סיטואציות נוספות בהן התוקף הצליח לפרוץ מעבר לקונטיינר המבודד שעליו הצליח להשתלט כדי להגיע אל המארח.

DOCKER הוציאה גרסה חדשה שכוללת תיקון והמליצה למשתמשים לשדרג אליו בהקדם האפשרי.

מספר 2: Docker Skeleton Runtime for Apache OpenWhisk

נקודת התורפה הזו היממה רבים בכך שאפשרה לתוקפים להחליף את פונקציית היוזר בתוך הקונטיינר במידה וקוד המשתמש חשוף לניצול קוד. מה שזוהו על ידי MITRE כ-CVE-2018-11757, גרסאות של תגית Docker openwhisk/dockerskeleton מ-1.3.0 או קודם, נמצאו כל כך חשופות, שהרשאות, הפריווילגיות וה-Access Control CWE קיבלו בצדק דירוג CVSS v3 של 9.8.

פרטים נוספים על התיקון בגרסה 1.3.1 ניתן למצוא בדף GitHub.

מספר 3: PHP Runtime for Apache OpenWhisk

נדמה ששנת 2018 לא היתה טובה במיוחד למשתמשי Apache OpenWhisk כפי שמודגש ב-CVE-2018–11756.

בו בזמן שה-the Skeleton Runtime CVE הסתובבה לה, פעולת ה-Docker שירשה את התגיות לפני openwhisk/action-php-v7.2:.0.0 או openwhisk/action-v7.1:1.0.1 יכלה לאפשר להאקר לשנות את פונקציית היוזר בתוך הקונטיינר.

בדומה לנקודת התורפה Skeleton runtime, ה-CVE הוא גם עניין של הרשאות, פריווילגיות ו-Access Control שבשל פוטנציאל הנזק האדיר שלו, קיבל דירוג CVSS v3 של 9.6 קריטיקל.

את התיקון ניתן למצוא בדף ה-GitHub של הפרויקט בגרסה 7.1@1.02.

מספר 4: (Windows Host Compute Service Shim (hcsshim

CVE-2018-8115 הטיל איום לא נעים על משתמשי Docker ל- Windows כשהוא התגלה בפברואר 2018.

על פי הדיווחים במאי 2018, השימוש בפונקציית filepath.Join Go אפשרה השתלטות מרחוק מתוך קבצי האחסון. היא דורגה גבוה ב- CVSS v3 עם ציון של 8.6.

לשמחתנו, גרסה חדשה ל-(hcsshim (version 0.6.10 יצאה בשבוע הראשון של מאי 2018 וסיפקה למפתחים גרסה מתוקנת ובטוחה יותר. חוקר האבטחה מיקאל הנסלמן, שגילה את נקודת התורפה הזו, מציין שגרסאות Docker CE 18.03.1 ו- CE 17.05.0-rc1 כבר מכילות את טלאי התוכנה.

מספר 5: util.c ב-runV

מה שתואר כניהול לא נכון של שם משתמש מספרי, util.c ב-runV 1.0.0 עבור Docker התגלה כמאפשר להאקרים לקבל root access באמצעות ניצול הימצאותו של ערך מספרי בשורת סיסמה ואז להפיק פקודת docker exec עם אותו הערך ב-u argument.

על היכולת לתת לפולש רמה גבוהה של גישה, CVE-2018-9862 קיבלה דירוג 7.8 CVSS v3.

על פי הדיווחים, ה-CVE הזה היה דומה לנקודת תורפה ב-runC בשנת 2016, CVE-2016-3697 שגם כן אפשרה root access.

מידע על התיקון – אפשר לקרוא כאן.

אבטחת קונטיינרים: טיפים לצמצום נקודות התורפה

בכל מה שקשור לאבטחה, הצעד הראשון הוא לוודא כי כל האפליקציות שלכם מעודכנות לגרסה האחרונה. הדרך הקלה ביותר לעשות זאת היא דרך אוטומטיזציה וכלים שונים המסייעים לכם לבדוק שאתם עושים בדיוק את מה שעליכם לעשות.

Docker היו נחמדים ונתנו את הכלי הזה – Docker Bench for Security אותו ניתן להשיג ב-GitHub.

ישנם כלי Docker רבים, כמו למשל (Docker Content Trust (DCT שיכול להיות שימושי מאוד למי שרוצה להימנע ממתקפות גורם אמצעי בזמן שהוא מזיז את הקונטיינרים שלו ברחבי הרשת. השתמשו בכלי הזה לחתימת תמונות והצפנתן ברמה שתוכל לסייע לכם במידה וישנה בעיית אבטחה כלשהי.

בעוד שחלק מנקודות התורפה של Docker כמו אלו שראינו במקרה ה-runC יכולות לתת לתוקף את היכולת להשתחרר מהקונטיינר בשל פגם בקוד, תמיד ישנו העניין של הידרדרות פריווילגיות שיכולה להסתיים בהשתלטות מרחוק על ידי תוקף. כדי למזער את הסיכון שמשתמשים בלתי מורשים יחרגו מההרשאות שלהם, או שהאקר בר מזל יצליח לעבור את האבטחה שלכם, הגבילו את היכולות של כל קונטיינר בנפרד על ידי יצירת user namespaces מבודדים וממודרים לטווח החשיפה המינימאלי. צמצמו את מספר המשתמשים הידועים עם תפקידים מוגדרים שלא יקבלו root access.

העתיד מאובטח יותר

לבסוף, סרקו את הקונטיינרים כדי לדעת מה בהם נמצא בשימוש. אחת הדאגות הראשונות שעולות כשמשתמשים בקונטיינרים היא היעדר ניראות. נקודות תורפה מעצבנות יכולות להתחבא או לא בהכרח להיות ברורות בגלל האופן בו הקוד של האפליקציה ארוז בתוך הקונטיינר, כולל נקודות תורפה ידועות שבמצב אחר היו נתפסות דרך כלי אבטחה אחרים ב-SDLC שלכם.

הטכנולוגיה עוד צעירה ו-Docker וספקים נוספים ככל הנראה ימשיכו לחוות חבלי לידה. למרות החשש מנקודות התורפה, יש להן פוטנציאל לסייע לארגונים לעבור למודלים של מיקרו-שירותים ולנווט בים ה- DevOps בגמישות שתסייע להם להגביר את הפופולאריות שלהם.

יש לקוות שכל עוד משתמשי Docker מתכננים קדימה עם האסטרטגיות הנכונות ומיישמים את הכלים הנכונים, ניתן יהיה להתמודד יותר בקלות עם נקודות התורפה העתידיות הצפויות.

הכתבה בחסות WhiteSource

WhiteSource מציעה לצוותי פיתוח ואבטחה כלי אוטומטי לניהול יעיל של רכיבי הקוד הפתוח שלהם. המוצר של WhiteSource משתלב בקלות עם כלי הפיתוח של הארגון, כדי לטפל ברכיבים פגיעים או כאלה העלולים להפר רישיונות שימוש, מבלי להפריע או להאט את תהליכי הפיתוח של הארגון.
מאז הקמתה ב-2011, הצליחה WhiteSource לבסס עצמה כמובילה בתחום ניהול רכיבי קוד פתוח, עם למעלה מ-700 לקוחות מחברות ענק כמו Microsoft, GE, ו-Comcast, וסטארט-אפים, הודות ליכולת הייחודית שלה להציע פתרון שעונה על הצרכים העסקיים של הארגון עם טכנולוגיה שמשתלבת בקלות עם תהליכי הפיתוח השוטפים של צוותי התוכנה. למשרות הפתוחות שלנו, לחצו כאן.

כתב אורח

אנחנו מארחים מפעם לפעם כותבים טכנולוגים אורחים, המפרסמים כתבות בתחומי התמחות שלהם. במידה ואתם מעוניינים לפרסם פוסט בשמכם, פנו אלינו באמצעות טופס יצירת קשר באתר.

הגב

10 תגובות על "5 נקודות תורפה של Docker שאתם חייבים להכיר"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

* היי, אנחנו אוהבים תגובות!
תיקונים, תגובות קוטלות וכמובן תגובות מפרגנות - בכיף.
חופש הביטוי הוא ערך עליון, אבל לא נוכל להשלים עם תגובות שכוללות הסתה, הוצאת דיבה, תגובות שכוללות מידע המפר את תנאי השימוש של Geektime, תגובות שחורגות מהטעם הטוב ותגובות שהן בניגוד לדין. תגובות כאלו יימחקו מייד.

סידור לפי:   חדש | ישן | הכי מדורגים
מסיק זיתים
Guest

נראה שכונות הכותב טובות, אבל הוא טובע ומטביע אותנו בז’רגון שלו, וכולל פרטים ממש לא מעניינים עבור הקורא הממוצע, כמו CVE-2018-9862
מה אכפת לי הטכנוקרטיה הזו? שים לינק (“לפרטים נוספים לחץ כאן”) ותשחרר אותנו מהקודים ה-הו-כה-משמעותיים האלה.

כתבה שהיתה יכולה להיות נחמדה, ויצאה טו מאצ’. פשוט מייגע.

מישהו
Guest

זה מאוד רלוונטי למי שצריך. אם לא הבנת הכתבה לא היתה מיועדת אליך. קורה

לירן
Guest

לא רואה איך זה קשור. יש דרך להסביר דברים ויש דרך לזרוק מידע סתמי. זה שאני לא מבין לא אומר שזה לא מיועד אלי, וזה כמו שאני אגיד לך “אם לא התחברת לתגובה היא לא מיועדת אליך” גם אני קראתי, והייתי יכול לחיות טוב מאוד עם פחות מידע (למה שיהיה לי איכפת ש MITRE זיהה את הפרצה?) ופחות עברית-אנגלית-עברית במשפט אחד.

חיים
Guest

“עברית-אנגלית-עברית” במשפט אחד נגזרת מעצם העובדה שהמושגים המקצועיים הינם באנגלית.
מה לעשות, “root access” נשמע יותר מובן מאשר “גישת שורש”… :)

חיים
Guest

פרטים מדוייקים (כמו CVE-2018-9862) חשובים מאד למי שזה עיסוקו/אחריותו ורוצה לחפש חומר נוסף וקצת להעמיק.
אני דווקא רואה בזה מקצועיות וענייניות.
ובקשר ללינקים – בכתבה ישנם 9 לינקים בסגנון שאותו תיארת. – בגלל לינק אחד שלא מצא חן בעיניך הפכת כתבה שלמה ל”מייגעת”, ואת הכותב לכזה ש”מטביע”? דחילק…

מישהו
Guest

כלל ראשון באבטחה: פשטות. כלל ראשון בפשטות: אל תשתמשו בדוקר. באמת. אל

הכי טוב לא להפעיל מחשב בכלל
Guest
הכי טוב לא להפעיל מחשב בכלל

אתה רציני? דוקר זה הדבר הכי טוב שקרה לעולם פיתוח התוכנה והסרברים בעשור האחרון,
מה שנכון הוא שלא המציאו אותו במטרה להחליף מכונות וירטואלית בענן ציבורי ופחות חשבו על אבטחת מידע ולפיכך הוא לא מאובטח כרגע כמו מכונה וירטואלית אבל אני לא רואה סיבה שבעתיד לא ידעו לסתום את הפרצות ולהגן עליו כמו שצריך גם לצרכים האלו

מישהו
Guest

כן, אני רציני. אנשים לא מבינים מה ההבדל בין שימוש בדוקר לפיתוח, שזה סבבה, ולשימוש בסקייל גבוה, שזה מעולה, ופורסים סתם אפליקציות עם הדבר הזה. רוב המפתחים לא יודעים לקנפג טוב ufw שלא לדבר על ngnix אז להבין מה הולך עם דוקר? חה

חיים
Guest

“רוב המפתחים… אז להבין מה הולך עם דוקר? חה” – סוף ציטוט.
– בדיוק לכן יש DevOps! אבל דוקר הוא אכן דבר טוב ויעיל, מה שלא מוריד מחובת העירנות וההתעדכנות.

יוגב גרינברג
Guest

אני עובד עירייה (סגן מנהל אגף) עם שכר ותנאים (רכב ליסינג בתשלום מוזל) שמרוויח כמו הייטקיסט, ולא צריך לדעת את כל השטויות האלה.

wpDiscuz

תגיות לכתבה: