webtartalom-kezelő rendszer kiadása . A kiadás a befejezéséről nevezetes a végrehajtásról frissítések és kiegészítések ellenőrzése digitális aláírással.
Eddig a WordPress frissítéseinek telepítésekor a fő biztonsági tényező a WordPress infrastruktúrájába és szervereibe vetett bizalom volt (letöltés után a kivonatot a forrás ellenőrzése nélkül ellenőrizték). Ha a projekt szervereit feltörték, a támadók meg tudtak hamisítani egy frissítést, és rosszindulatú kódot terjesztettek a WordPress-alapú webhelyek között, amelyek automatikus frissítéstelepítő rendszert használnak. A korábban alkalmazott bizalmi kézbesítési modellnek megfelelően egy ilyen helyettesítés észrevétlen lett volna a felhasználók oldalán.
Figyelembe véve azt a tényt, hogy a w3techs projektből a WordPress platformot a hálózat oldalainak 33.8%-án használják, az incidens katasztrófa léptékű lett volna. Ugyanakkor az infrastruktúra-kompromittálódás veszélye nem hipotetikus, hanem valós volt. Például néhány évvel ezelőtt az egyik biztonsági kutató egy biztonsági rés, amely lehetővé tette a támadó számára, hogy az api.wordpress.org szerver oldalán végrehajtsa a kódját.
Digitális aláírások esetén a frissítés-elosztó szerver feletti irányítás megszerzése nem vezet a felhasználói rendszerek kompromittálásához, mivel a támadás végrehajtásához külön tárolt privát kulcsot is be kell szerezni, amellyel a frissítések aláírásra kerülnek.
A frissítések forrásának digitális aláírással történő ellenőrzésének megvalósítását nehezítette, hogy viszonylag nemrég jelent meg a szabványos PHP csomagban a szükséges kriptográfiai algoritmusok támogatása. A könyvtár integrációjának köszönhetően megjelentek a szükséges kriptográfiai algoritmusok a főcsapatba . De mint a PHP minimálisan támogatott verziója a WordPressben 5.2.4 kiadás (WordPress 5.2 - 5.6.20). A digitális aláírások támogatásának engedélyezése jelentősen megnövelné a PHP minimálisan támogatott verziójával szemben támasztott követelményeket, vagy egy külső függőség hozzáadásához vezetne, amit a fejlesztők nem tehetnének meg, tekintettel a PHP-verziók elterjedésére a hosting rendszerekben.
A megoldás az volt és a Libsodium kompakt verziójának beépítése a WordPress 5.2-be - , amelyben a digitális aláírások ellenőrzésére szolgáló algoritmusok minimális halmaza implementálva van PHP-ben. A megvalósítás sok kívánnivalót hagy maga után a teljesítmény tekintetében, de teljesen megoldja a kompatibilitási problémát, és lehetővé teszi a bővítmények fejlesztői számára, hogy megkezdjék a modern kriptográfiai algoritmusok megvalósítását.
A digitális aláírások generálására algoritmust használnak , amelyet Daniel J. Bernstein közreműködésével fejlesztettek ki. A frissítési archívum tartalmából kiszámított SHA384 hash értékhez digitális aláírás jön létre. Az Ed25519 magasabb szintű biztonságot nyújt, mint az ECDSA és a DSA, és nagyon gyors ellenőrzést és aláírás-létrehozást tesz lehetővé. Az Ed25519 feltörésekkel szembeni ellenállása körülbelül 2^128 (átlagosan az Ed25519 elleni támadás 2^140 bites műveleteket igényel), ami megfelel az olyan algoritmusok ellenállásának, mint a NIST P-256 és az RSA 3000 bites kulcsmérettel. vagy 128 bites blokk titkosítás. Az Ed25519 szintén nem érzékeny a hash ütközésekkel kapcsolatos problémákra, és nem fogékony a gyorsítótár-időzítési támadásokra vagy az oldalcsatornás támadásokra.
A WordPress 5.2-es kiadásában a digitális aláírás ellenőrzése jelenleg csak a nagyobb platformfrissítésekre terjed ki, és alapértelmezés szerint nem blokkolja a frissítést, hanem csak tájékoztatja a felhasználót a problémáról. Úgy döntöttek, hogy nem engedélyezik azonnal az alapértelmezett blokkolást, mivel teljes ellenőrzésre és kiiktatásra van szükség . A jövőben a tervek szerint digitális aláírás-ellenőrzést is hozzáadnak a témák és bővítmények telepítési forrásának ellenőrzéséhez (a gyártók a kulcsukkal aláírhatják a kiadásokat).
A WordPress 5.2 digitális aláírásának támogatása mellett a következő változások figyelhetők meg:
- A „Webhely állapota” részhez két új oldal került a gyakori konfigurációs problémák hibakeresésére, valamint egy űrlap is rendelkezésre áll, amelyen keresztül a fejlesztők a hibakeresési információkat a webhely rendszergazdáira hagyhatják;
- A „halál fehér képernyőjének” hozzáadott megvalósítása, amely végzetes problémák esetén jelenik meg, és segít a rendszergazdának a bővítményekkel vagy témákkal kapcsolatos problémák önálló megoldásában egy speciális összeomlás-helyreállítási módra váltva;
- A beépülő modulokkal való kompatibilitást ellenőrző rendszer került bevezetésre, amely automatikusan ellenőrzi a plugin használatának lehetőségét az aktuális konfigurációban, figyelembe véve a PHP használt verzióját. Ha egy beépülő modul működéséhez a PHP újabb verziója szükséges, a rendszer automatikusan blokkolja ennek a beépülő modulnak a felvételét;
- Támogatás hozzáadva a modulok JavaScript kóddal történő engedélyezéséhez и ;
- Új privacy-policy.php sablon hozzáadva, amely lehetővé teszi az adatvédelmi szabályzat oldal tartalmának testreszabását;
- A témákhoz egy wp_body_open hook kezelő került hozzáadásra, amely lehetővé teszi, hogy a kódot közvetlenül a body címke után illessze be;
- A PHP minimális verziójára vonatkozó követelmények 5.6.20-ra emelkedtek, a bővítmények és témák mostantól képesek névtereket és névtelen függvényeket használni;
- 13 új ikon hozzáadva.
Ezen kívül megemlítheti kritikus sérülékenység a WordPress bővítményben (CVE-2019-11185). A sérülékenység tetszőleges PHP-kód futtatását teszi lehetővé a szerveren. A beépülő modult több mint 27 ezer webhelyen használják interaktív csevegés megszervezésére a látogatóval, többek között olyan cégek webhelyein, mint az IKEA, az Adobe, a Huawei, a PayPal, a Tele2 és a McDonald's. chat a vállalati oldalakon ajánlatokkal chat az alkalmazottal).
A probléma a fájlok szerverre feltöltésének kódjában nyilvánul meg, és lehetővé teszi, hogy megkerülje az érvényes fájltípusok ellenőrzését, és egy PHP-szkriptet töltsön fel a szerverre, majd közvetlenül a weben keresztül hajtsa végre. Érdekesség, hogy tavaly már azonosítottak egy hasonló biztonsági rést a Live Chatben (CVE-2018-12426), amely lehetővé tette a PHP-kód betöltését egy kép leple alatt, a Content-type mezőben más tartalomtípust megadva. A javítás részeként további ellenőrzéseket adtunk az engedélyezési listákra és a MIME-tartalomtípusra vonatkozóan. Mint kiderült, ezeket az ellenőrzéseket helytelenül hajtják végre, és könnyen megkerülhetők.
Különösen a „.php” kiterjesztésű fájlok közvetlen feltöltése tilos, de a „.phtml” kiterjesztés, amely sok szerveren a PHP értelmezőjéhez kapcsolódik, nem került fel a feketelistára. Az engedélyezőlista csak a képek feltöltését teszi lehetővé, de ezt megkerülheti dupla kiterjesztéssel, például „.gif.phtml”. A fájl elején található MIME típusellenőrzés megkerüléséhez a PHP kóddal való tag megnyitása előtt elegendő a „GIF89a” sort megadni.
Forrás: opennet.ru