webtartalom-kezelő rendszer megjelenése . A kiadás jelentős a a digitális aláírás alapján történő frissítések és bővítmények ellenőrzésének megvalósítása.
Eddig a WordPress frissítések telepítésekor a biztonság fő tényezője a WordPress infrastruktúrájában és szervereiben való bizalom volt (a letöltés után a hash-ellenőrzés történt, forrás ellenőrzése nélkül). A projekt szervereinek kompromittálása esetén a támadók lehetőséget kaptak arra, hogy hamisítják a frissítéseket, és kártékony kódot terjesztenek a WordPress alapú webhelyek között, amelyek automatikus frissítési rendszert használnak. A korábban alkalmazott bizalmi modellel történő szállítás esetén a felhasználók oldalán az ilyen hamisítás észrevétlen maradt volna.
Figyelembe véve, hogy a w3techs projekten belül a WordPress platformot az interneten található webhelyek 33.8%-a használja, az incidens katasztrófa méreteket ölthetett volna. Ezen kívül a infrastruktúra kompromittálódásának veszélye nem volt hipotetikus, hanem teljesen valóságos. Például néhány évvel ezelőtt egy biztonsági kutató a sebezhetőséget, amely lehetővé tette a támadó számára, hogy kódot hajtson végre a api.wordpress.org szerver oldalán.
Digitális aláírások alkalmazása esetén a frissítések terjesztési szerverének ellenőrzésének megszerzése nem vezetne a felhasználói rendszerek kompromittálásához, mivel a támadás végrehajtásához külön szükséges lenne megszerezni a titkos kulcsot, aminek segítségével a frissítések aláírását végzik.
A digitális aláírás alapján történő frissítések forrásának ellenőrzésének bevezetését akadályozta, hogy a szükséges kriptográfiai algoritmusok támogatása a PHP alapkiadásában viszonylag nemrég jelent meg. A szükséges kriptográfiai algoritmusok integrálásával alakultak ki a a fő keretbe . De a WordPress által minimálisan támogatott PHP verzióként 5.2.4 (a WordPress 5.2-től - 5.6.20-ig) megjelenését jelentették be. A digitális aláírások támogatásának bevezetése jelentős követelményeket támasztana a minimálisan támogatott PHP verzióra, vagy külső függőség hozzáadását igényelné, amit a fejlesztők nem vállaltak a PHP verziók elterjedtsége miatt a tárhelyszolgáltatásokban.
A megoldás a és a WordPress 5.2 részévé válik a Libsodium kompakt változata — , amelyben PHP nyelven egy minimális algoritmuscsomag valósul meg a digitális aláírások ellenőrzésére. A megvalósítás teljesítménye kívánnivalót hagy maga után, de teljes mértékben megoldja a kompatibilitási problémát, és lehetővé teszi a plugin fejlesztők számára a modern kriptográfiai algoritmusok bevezetését.
A digitális aláírások létrehozásához a következő algoritmus kerül felhasználásra: , amelyet Daniel J. Bernstein közreműködésével fejlesztettek ki. A digitális aláírás a SHA384 hash értékhez képest keletkezik, amely a frissítési archívum tartalmából lett kiszámítva. Az Ed25519 magasabb biztonsági szinttel rendelkezik, mint az ECDSA és a DSA, és rendkívül gyorsan képes az aláírások ellenőrzésére és létrehozására. Az Ed25519 ellenállása a törésre körülbelül 2^128 (átlagosan a támadáshoz 2^140 bitművelet szükséges), ami egyenértékű az olyan algoritmusok ellenállásával, mint a NIST P-256 és az RSA 3000 bites kulcs mérettel, vagy egy 128 bites blokkszárral. Az Ed25519 nem szenved a hash ütközések problémáitól, nem érzékeny a cache-timing támadásokra és a külső csatornákon keresztüli támadásokra.
A WordPress 5.2 kiadásában a digitális aláírások ellenőrzése egyelőre csak a platform alapvető frissítéseit fedi le, és alapértelmezés szerint nem blokkolja a frissítéseket, csupán tájékoztatja a felhasználót a felmerült problémáról. Az alapértelmezett blokkolást azért döntötték el, hogy ne aktiválják, mert szükséges a teljes ellenőrzés és a A jövőben a digitális aláírások ellenőrzését is tervezik a témák és pluginok telepítési forrásának verifikálásához (a gyártók saját kulcsukkal aláírhatják a kiadásokat).
A digitális aláírások támogatásán kívül a WordPress 5.2-ben a következő változások emelhetők ki:
- A "Site Health" szekcióhoz két új oldal került hozzáadásra, amelyek a tipikus konfigurációs problémák hibakeresésére szolgálnak, valamint egy űrlap, amelyen a fejlesztők hibakeresési információkat küldhetnek a webhely rendszergazdáinak;
- Hozzáadva a „halál fekete képernyő” megvalósítása, amely súlyos hibák esetén jelenik meg, és segíti a rendszergazdát a pluginokkal vagy témákkal kapcsolatos problémák önálló megoldásában, belépve egy speciális helyreállítási módba a hiba után;
- Megvalósult a bővítmények kompatibilitási ellenőrzési rendszere, amely automatikusan ellenőrzi a bővítmény használatának lehetőségét a jelenlegi konfigurációban, figyelembe véve az alkalmazott PHP verziót. Ha a bővítmény működéséhez újabb PHP verzió szükséges, a rendszer automatikusan blokkolja a bővítmény engedélyezését;
- Hozzáadva a JavaScript-kódot tartalmazó modulok engedélyezésének támogatása a következőkkel: és ;
- Hozzáadva egy új privacy-policy.php sablon, amely lehetővé teszi a tartalom testreszabását a magánélet védelméről szóló feltételek oldalán;
- A téma designokhoz hozzáadva a wp_body_open hook kezelője, amely lehetővé teszi a kód beszúrását közvetlenül a body tag után;
- A minimális PHP verzió követelménye 5.6.20-ra emelkedett, a bővítményekben és a témákban megjelent a névterek és az anoním funkciók használatának lehetősége;
- Hozzáadva 13 új ikon.
Továbbá megemlíthető kritikus sérülékenység a WordPress bővítményben (CVE-2019-11185). A sérülékenység lehetővé teszi tetszőleges PHP kód végrehajtását a szerveren. A bővítményt több mint 27 ezer weboldalon használják interaktív csevegés lebonyolítására a látogatókkal, például olyan cégek weboldalain, mint az IKEA, Adobe, Huawei, PayPal, Tele2 és McDonald's (A Live Chat gyakran használják felugró, zavaró csevegések megvalósítására cégek weboldalain, ajánlva az alkalmazottal való beszélgetést).
A probléma a fájlok szerverre való feltöltésének kódjában jelentkezik, amely lehetővé teszi a megengedett fájltípusok ellenőrzésének megkerülését és egy PHP-szkript feltöltését a szerverre, majd annak közvetlen elérését a weben. Érdekesség, hogy tavaly a Live Chat-ben már felfedeztek hasonló sérülékenységet (CVE-2018-12426), amely lehetővé tette PHP-kód feltöltését képként, azáltal, hogy más tartalomtípust adtak meg a Content-type mezőben. A probléma javítása érdekében további ellenőrzéseket adtak hozzá a fehér listák és a MIME-típus ellenőrzésével. Kiderült, hogy ezeket az ellenőrzéseket helytelenül hajtottá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 nem került feketelistára, amely sok szerveren a PHP értelmezőhöz kapcsolódik. A fehér lista csak képek feltöltését teszi lehetővé, de kijátszható, ha dupla kiterjesztést adunk meg, például «.gif.phtml». A MIME-típus ellenőrzésének megkerüléséhez a fájl elején, a PHP kódot megnyitó címke előtt elegendő volt a «GIF89a» sor feltüntetése.
Forrás: opennet.ru
