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

מה החולשה?

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

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

לפי אדובי, במקרה הזה התוצאה היא הסלמת הרשאות.

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

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

מי מושפע?

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

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

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

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

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

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

מה עושים?

1. פתחו את עדכון האבטחה APSB26-144 של אדובי והשוו את הגרסה ואת מספר העדכון שרצים אצלכם למה שמופיע שם. הרשומה ב-NVD לא מפרטת גרסאות, ולכן זה המקור.

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

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

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