המדריך ליצירת תקשורת חשאית בין שני קונטיינרים - החלק השני

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

‍

פרק רביעי - תגובת Docker

‍

שלחתי כמובן את המידע לגבי החולשה לחברת Docker בצירוף הקוד, וכל השיחה איתם מופיעה ב-Github של הפרויקט, זה חלק מהתגובה שלהם:

Thanks for this report (and neat PoC), unfortunately we don't agree that
this is a vulnerability -- for a few reasons.

1. In order to exploit this you already have two containers that you
  wish to communicate on a target system -- which means that you
  already have code-execution within containers on the system and they
  are mutually co-operative. In other words, there is no "victim"
  process. I'm sure this would be a neat trick if you manage to get
  "blind container execution" to exfiltrate information between
  containers, but given that all the processes are co-operative I don't
  see this as an issue.

2. This issue is actually a kernel issue (/proc/meminfo and the other
  memory-info APIs aren't cgroup-aware, leading to information about
  global system resources being scoped inside the container). As you
  said, this issue has been known about for a really long time -- but
  kernel developers have categorically stated they aren't interested in
  /proc/meminfo becoming cgroup-aware because of how complicated the
  infrastructure would be to make it work. So, we don't really have the
  ability to fix the fundamental issue.

  There is a project called LXCFS which allows you to mask
  /proc/meminfo in containers, and you could use this to prevent some
  of the problem -- but there are other memory-info APIs that can't be
  fixed so easily. You could trick them with the new seccomp
  RET_USER_NOTIF API, but that would not help older kernels and so on
  (and ptrace would kill performance in containers by a fair amount,
  and break gdb).

3. Isolating machines to avoid side-channels like this is almost an
  intractable problem -- because at the end of the day you are running
  on the same hardware and there will always be hardware tells (latency
  in HDD access or even CPU load -- both can be limited with cgroups
  but you'd likely be able to tell). Even VMs are vulnerable to
  side-channels like this, because shared-tenant systems fundamentally
  have to share resources that aren't designed to be side-channel
  resistant.

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

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

בנוגע לנקודה השלישית, אמנם זה נכון שייתכנו מתקפות דומות גם על VM, אך הם יהיו הרבה יותר מסובכים עד כדי לא אפשריים לעומת החולשות המתוארות פה.(side channel attack in VM's here)

‍

פרק חמישי - מה עוד?

‍

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

Side channel attack
ואסביר קצת על הנושא :

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

סוג המתקפה השני, והמעט פחות מוכר, הינו התקפה עקיפה (או באנגלית Side channel attack). על הנושא נכתב בהרחבה מאמר מאת יובל סיני ופורסם בגיליון ה-79 של המגזין:

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

‍

‍

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

למרות שעל פי שתי הפסקאות האחרונות ניתן לחשוב בטעות כי סוג המתקפות השני הוא סוג מתקפות "חלש" יותר, אין לזלזל בו - בעזרת סוג מתקפות זה הצליחו בלא מעט פעמים לרסק אלגוריתמי הצפנה כבדים מאוד, וחולשות - מהמפורסמות ביותר - אשר מתבססות על קונספטים מסוג זה (Meltdown ו-Spectre לדוגמא, או BREACH ו-CRIME על TLS).

ובמקרה שלנו, כאשר אנו יכולים לדעת מה כמות ה-RAM בשימוש וכן מה הם מספר התהליכים הרצים כרגע ב-Host ועם מחקר מספיק מקיף נוכל להצליח לבצע המון מתקפות מסוג Side channel attack לדוגמא להצליח לשבור הצפנה של קונטיינר שמצפין מידע ונמצא גם על אותו Host, זיהוי של סוג השרת הנמצא בקונטיינר לידינו גם אם הוא מנסה לבלבל אותנו ומסתיר את סוג השרת (מוזמנים לקרוא עוד על הרעיון במאמר המצוין של אפיק קסטיאל, בכללי לא ארחיב כעת רק אומר שהתחלנו מחקר בנושא ויש לבינתיים תוצאות מאוד מעניינות ואולי בקרוב יתפרסם מאמר המשך עם מימוש של זה ;-) ) ועוד אינספור דברים שכבר בוצעו בעבר בנושא ודברים נוספים בסגנון שלהם.

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

● Hide and Seek with AVs
ערוץ שאינו מפוקח ע"י תוכנת ה-Antivirus: ע"י הרצת ה-sender.py וה-receiver.py על אותה המכונה, ניתן ליצור ערוץ תקשורת חשאי בין שני תהליכים שונים על אותו הקונטיינר ובכך להתחמק מתוכנות כגון Antivirus אשר מחפשות קישורים ישירים כגון יצירת קובץ, ובדיקה איזה תהליכים אחרים ניגשים אליו, או כתיבה ישירה לזיכרון של תהליך אחר. באמצעות יצירת פרוטוקול תקשורת המתבסס על הקצאת ושחרור זיכרון ניתן להעביר מידע בין תהליכים באופן עקיף.

● בחרתי להראות את הדוגמא ספציפית על Docker אבל כמו שכבר צוין היקף הבעיה הוא הרבה יותר גדול, ואפשר באמצעות החולשה הזאת להצליח להעביר מידע בין שני תהליכים גם על רכיב המריץ Linux בצורה רגילה ולהרוויח את היתרונות המוזכרים לעיל.

‍

פרק סיכום:

‍

הנקודה המרכזית שרציתי להראות במאמר זה שכאשר חושבים על כל הנושא של הפרדה רשתית חשוב לשים לב שאם ההפרדה באמת חשובה לנו גם מבחינת האבטחה, אנו צריכים תמיד לשקול את האפשרות להשתמש בהפרדה חזקה יותר מאשר ההפרדה הפשוטה שמקבלים באמצעות קונטיינרים, בדרך כלל נרצה להשתמש בהפרדה של vm-ים שהיא כידוע הרבה יותר חזקה, אך כמו שגם Docker בעצמם ציינו, גם בהפרדה באמצעות vm-ים ייתכנו מתקפות מסוג side channel attack או covert channel וכן ייתכנו התקפות של בריחה מ-vm אשר ראוי לקחת בחשבון ולכן לפעמים נרצה ממש הפרדת Air gap חשוב שוב לציין שאמנם ההתקפות מהסוג הנ"ל ייתכנו גם ב-VM אבל הם יהיו משמעותית הרבה יותר קשות עד בלתי אפשריות.

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

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

תוך כדי כתיבת המאמר, אפיק קסטיאל (המנהל של המגזין המעולה הזה) הפנה את תשומת ליבי למחקר מרתק שנעשה בתחום - מדובר על קבוצת חוקרים שיצרו כלי אוטומטי לזיהוי חולשות מסוג Side channel attack באנדרואיד המבוססות על פגיעויות הקשורות ב-proc/ ממליץ בחום רב לקרוא את המחקר שלהם.

‍

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

‍

רוצים להתעדכן בתכנים נוספים בנושאי קונטיינרים? הירשמו עכשיו לניוזלטר שלנו ותמיד תישארו בעניינים > להרשמה

‍