פגיעות SSRF קריטית ב-MLflow מנוצלת בפועל זמן קצר אחרי הגילוי

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

מה קרה

הפגיעות יושבת בנקודת הקצה /api/2.0/mlflow/webhooks/{id}/test, המשמשת לבדיקת התראות (webhooks) של מרשם המודלים ב-MLflow, וחשופה כברירת מחדל ללא צורך באימות. השרת אמור לוודא שכתובת ה-webhook אינה מצביעה על רשת פנימית, אך הבדיקה מתבצעת רק על הכתובת המקורית: אם השרת המרוחק מגיב בהפניה (redirect) לכתובת פנימית — כמו שירות המטא-דאטה של הענן בכתובת 169.254.169.254 או ה-loopback המקומי — MLflow עוקב אחרי ההפניה בלי לבדוק אותה מחדש, ומחזיר לתוקף את התוכן שהתקבל.

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

נקודות לשים לב

• עדכנו כל התקנת MLflow לגרסה 3.15.0 ומעלה בהקדם האפשרי — הניצול כבר פעיל ואינו דורש פרטי התחברות.
• בדקו האם שרת ה-MLflow Tracking Server שלכם חשוף לאינטרנט הפתוח; אם אין הכרח בכך, הגבילו גישה ברמת הרשת (VPN, allow-list) עד להשלמת העדכון.
• בסביבות ענן, שקלו לחסום גישה משרתי האפליקציה אל שירותי המטא-דאטה (למשל דרך IMDSv2 ב-AWS) כהגנת עומק נוספת, גם אחרי העדכון.
• חפשו בלוגים בקשות חריגות אל נתיב בדיקת ה-webhook, ובפרט בקשות שמקורן בכתובות חיצוניות בלתי מוכרות שהובילו לתגובות הפניה (HTTP 302).
• אם השרת נחשף בעבר לאינטרנט ללא הגבלה — יש להניח שאישורי הענן שהיו נגישים לו נחשפו, ולבצע רוטציה שלהם כאמצעי זהירות.

מקורות: Cyber Security News · GitLab Advisory Database