CVE-2025-32432: Hitelesítetlen távoli kódfuttatás a Craft CMS-ben

A munkafolyamat részletes elemzése során munkatársaink megállapították, hogy az AssetsController::actionGenerateTransform metódus minden alkalommal meghívásra kerül, amikor POST kérés érkezik a nyilvános végponthoz. Ez a függvény közvetlenül a kérés testéből veszi át a handle paramétert, és továbbítja azt a következő szakaszban történő további feldolgozás céljából.

A következő lépésben az ImageTransforms::normalizeTransform() metódus kerül meghívásra. Ez a metódus a felhasználó által megadott handle paramétert veszi át, és ImageTransform objektummá alakítja. Mivel az objektum közvetlenül megbízhatatlan bemeneti adatokból jön létre, ez kritikus kockázati pontot jelent a végrehajtási folyamatban.

Ezen folyamat során a felhasználó által vezérelt $transform tömb (a handle paraméterből származik) összes kulcs-érték párja összevonásra kerül egy konfigurációs tömbbe. A normalizeTransform metódus ezután továbbítja ezt a tömböt a Craft::createObject() metódusnak, amely felelős egy új ImageTransform objektum létrehozásáért.

A sebezhetőség abból ered, hogy a Craft::createObject() ( amely a Yii::createObject()-ot burkolja) a konfigurációs tömböket feldolgozza. Mivel ez a mechanizmus a DI konténert használja az objektumok instantiálására és konfigurálására közvetlenül a nem validált tömbből, a támadók átvehetik az irányítást az objektumok létrehozásának folyamatában.

Ha rosszindulatú payload kerül átadásra, az objektum konstruktora (amelyet a Model osztályból örökölt) meghívja az App::configure() metódust.

Ez a módszer végigfut a támadó által ellenőrzött tömb minden tulajdonságán, és azokat hozzárendeli az új objektumhoz.

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.

Egy ilyen rosszindulatú hasznos teher úgy alakítható ki, hogy kihasználja a Component::__set által az as előtaggal ellátott tulajdonságok feldolgozásának módját, például az exploit:

Elemzésünk szerint a Component::__set megvalósítása tartalmaz egy biztonsági intézkedést: amikor egy viselkedés ilyen tulajdonságon keresztül kapcsolódik, a keretrendszer ellenőrzi, hogy a konfigurációs tömbben megadott osztály érvényes alosztálya-e a yii\base\Behavior osztálynak. Ez az ellenőrzés megakadályozza, hogy tetszőleges osztályok közvetlenül kapcsolódjanak a komponensekhez.

Ez a védelem azonban nem olyan hatékony, mint amilyennek látszik. A gyengeség abból fakad, hogy a Yii::createObject hogyan kezeli a konfigurációs tömböket.

Objektumok létrehozásakor a Yii::createObject elsőbbséget ad a speciális __class paraméternek. Ha ez a kulcs jelen van, akkor annak értéke kerül felhasználásra a létrehozás célosztályaként, és a konfigurációs tömbben található standard class kulcs figyelmen kívül marad.

A támadó két kulcsot tartalmazó hasznos terhelést készíthet az as exploit viselkedéshez:

1. 'class' => '\craft\behaviors\FieldLayoutBehavior' - A yii\base\Behavior osztályt kiterjesztő érvényes osztály. Ez az érték kizárólag a Component::__set is_subclass_of ellenőrzésének teljesítésére szolgál, lehetővé téve a végrehajtás folytatását hibaüzenet megjelenítése nélkül.
2. '__class' => '\yii\rbac\PhpManager' - A támadó tényleges célpontja. Ez az a „gadget” osztály, amelyet instantiálni szeretnének.

A kód végrehajtásakor a Component::__set átmegy a biztonsági ellenőrzésen, mert csak az osztálykulcsot ellenőrzi. Azonban amikor a keretrendszer később a Yii::createObject metódust hívja meg a viselkedés hozzáadásához, akkor elsőbbséget ad a __class-nak, ami azt eredményezi, hogy a támadó által választott \yii\rbac\PhpManager objektum instantiálódik.

A \yii\rbac\PhpManager használata szándékos. Az objektum létrehozása önmagában nem elegendő a kihasználáshoz; az RCE eléréséhez olyan gadget osztályra van szükség, amelynek mellékhatásai fegyverként használhatók. A PhpManager inicializálási folyamatának köszönhetően gyakori célpontja a POI (PHP Object Injection) támadásoknak. Az instantiáláskor az init() metódusa meghívja a load() metódust, amely pedig a loadFromFile($this->itemFile) metódust hívja meg. A $this->itemFile feletti ellenőrzéssel a támadó rákényszerítheti az alkalmazást egy rosszindulatú fájl betöltésére, így az objektum létrehozását kód végrehajtássá alakítva.

A veszély a loadFromFile metódusban rejlik. A PHP-ben a require parancs a célfájlt kódként futtatja, így ha egy támadó ellenőrzi a fájl elérési útját, akkor tetszőleges kód futtatását indíthatja el.

A rosszindulatú kód szerverre való elhelyezéséhez a támadó a PHP munkamenetfájlokat használja ki. A PHP-t egy kérésparaméterbe beillesztve a Craft CMS az átirányítási folyamat során a hasznos adatokat egy munkamenetfájlba menti. Később, amikor a PhpManager betölti ezt a fájlt, a támadó kódja végrehajthatóvá válik.

A teljes támadási lánc három szakaszban működik. Először a támadó egy speciálisan kialakított URL-t küldve rosszindulatú PHP-kódot helyez el, amelyet a Craft CMS egy munkamenetfájlba ment. Ezután kihasználja a képátalakítási végpont __class bypass funkcióját, hogy betöltse a PhpManager modult, és azt a fertőzött munkamenetfájlra irányítsa. Végül, amikor a PhpManager betölti a fájlt, a támadó kódja végrehajtásra kerül, RCE-t és a szerver teljes irányítását biztosítva – gyakran webshell vagy reverse shell segítségével.