CVE-2025-32432: ביצוע קוד מרחוק לא מאומת ב-Craft CMS

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

בשלב הבא, נקראת המתודה ImageTransforms::normalizeTransform() . מתודה זו לוקחת את פרמטר ה-handle שסופק על ידי המשתמש וממירה אותו לאובייקט ImageTransform . מכיוון שהאובייקט נוצר ישירות מקלט לא מהימן, זה מייצג נקודת סיכון קריטית בזרימת הביצוע.

במהלך תהליך זה, כל זוגות המפתח-ערך מהמערך $transform הנשלט על ידי המשתמש (שמקורו בפרמטר handle) ממוזגים למערך תצורה. לאחר מכן, המתודה normalizeTransform מעבירה מערך זה ל- Craft::createObject() , האחראית על יצירת אובייקט ImageTransform חדש.

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

כאשר מועבר מטען זדוני, בנאי האובייקט (שהועבר בירושה ממחלקת Model ) מפעיל את המתודה App::configure() .

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

When App::configure() assigns properties from the attacker-controlled configuration array, most keys are mapped directly onto the object. However, if a key begins with the prefix as, the assignment is routed through Component::__set, Yii’s magic setter. This method interprets as <name> as an instruction to attach a behavior (mixin) to the object.

ניתן ליצור מטען זדוני אחד כזה כדי לנצל את האופן שבו Component::__set מעבד מאפיינים עם קידומת as , כגון exploit :

מהניתוח שלנו, המימוש של Component::__set כולל אמצעי הגנה: כאשר התנהגות מצורפת דרך מאפיין כזה, המסגרת מאמתת שהמחלקה שצוינה במערך התצורה היא תת-מחלקה תקפה של yii\base\Behavior . בדיקה זו נועדה למנוע צירוף מחלקות שרירותיות ישירות לרכיבים.

עם זאת, אמצעי הגנה זה אינו יעיל כפי שנראה. החולשה נובעת מהאופן שבו Yii::createObject מטפל במערכי תצורה.

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

התוקף יכול ליצור מטען עבור התנהגות הניצול הכולל שני מפתחות:

1. 'class' => '\craft\behaviors\FieldLayoutBehavior' - מחלקה לגיטימית שמרחיבה את yii\base\Behavior. ערך זה קיים אך ורק כדי לספק את בדיקת is_subclass_of ב-Component::__set, מה שמאפשר לביצוע להמשיך מבלי לגרום לשגיאה.
2. '__class' => '\yii\rbac\PhpManager' - המטרה בפועל של התוקף. זוהי מחלקת ה"גאדג'ט" שהם רוצים ליצור.

כאשר הקוד מבוצע, Component::__set עובר את בדיקת האבטחה מכיוון שהוא בודק רק את מפתח המחלקה. עם זאת, כאשר ה-framework קורא מאוחר יותר ל-Yii::createObject כדי לצרף את ההתנהגות, הוא נותן עדיפות ל-__class, וכתוצאה מכך נוצר אובייקט \yii\rbac\PhpManager שבחר התוקף במקום זאת.

השימוש ב- \yii\rbac\PhpManager הוא מכוון. יצירת אובייקט בלבד אינה מספיקה לניצול; השגת RCE דורשת מחלקת גאדג'ט עם תופעות לוואי שניתן להפוך לנשק. PhpManager הוא מטרה נפוצה בהתקפות POI (PHP Object Injection) בגלל זרימת האתחול שלו. לאחר ההפעלה, המתודה init() קוראת ל- load() , אשר לאחר מכן מפעילה את loadFromFile($this->itemFile) . עם שליטה על $this->itemFile , תוקף יכול לאלץ את האפליקציה לטעון קובץ זדוני, ולהפוך יצירת אובייקט להרצת קוד.

הסכנה טמונה במתודה loadFromFile. ב-PHP, קוד requirement מבצע את קובץ היעד כקוד, כך שאם תוקף שולט בנתיב הקובץ, הוא יכול להפעיל ביצוע קוד שרירותי.

כדי להציב קוד זדוני בשרת, התוקף מנצל קבצי session של PHP . על ידי הזרקת PHP לפרמטר בקשה, Craft CMS שומר את המטען לקובץ session במהלך תהליך ההפניה. מאוחר יותר, כאשר PhpManager טוען קובץ זה, ניתן יהיה לבצע את קוד התוקף.

שרשרת ההתקפה המלאה פועלת בשלושה שלבים. ראשית, התוקף שותל PHP זדוני על ידי שליחת כתובת URL מעוצבת, אותה Craft CMS שומר בקובץ session. לאחר מכן, הוא מנצל את עקיפת __class בנקודת הקצה של transform image כדי לטעון את גאדג'ט PhpManager ולכוון אותו לעבר קובץ ה-session המורעל. לבסוף, כאשר PhpManager טוען את הקובץ, המטען של התוקף מבוצע, ומעניק RCE ושליטה מלאה בשרת - לעתים קרובות באמצעות webshell או reverse shell.