Argo Rollouts מנהל פריסות של גרסאות ב-Kubernetes, ולצדו אפשר להריץ לוח בקרה גרפי. בגרסאות עד 1.10.0 ועד בכלל, לוח הבקרה הזה מאזין לכל ממשקי הרשת ומבצע פעולות שמשנות פריסות בלי לדרוש הזדהות, בלי לבדוק הרשאות ובלי לוודא מאיפה הגיעה הבקשה. הציון הוא 9.3 מתוך 10.

מה החולשה?

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

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

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

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

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

וההיקף אינו פריסה אחת. הפעולות זמינות בכל ה-namespace-ים שאליהם מגיע ה-kubeconfig של המפעיל, כלומר בכל מה שהמפעיל עצמו מורשה לגעת בו.

מי מושפע?

מי שמריץ את לוח הבקרה של Argo Rollouts בגרסה 1.10.0 או נמוכה ממנה. שימו לב לניסוח: החולשה היא בלוח הבקרה ולא בכל שימוש ב-Argo Rollouts. הלוח הוא רכיב שמריצים בנפרד, ולא כל מי שמשתמש בכלי מריץ גם אותו.

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

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

האם מנוצלת בפועל?

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

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

מה עושים?

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

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

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

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

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