lansering av webbinnehållshanteringssystem . Utgivningen är anmärkningsvärd för dess slutförande på genomförandet kontrollera uppdateringar och tillägg med en digital signatur.
Fram till nu, när du installerade uppdateringar i WordPress, var den huvudsakliga säkerhetsfaktorn förtroende för WordPress-infrastrukturen och servrarna (efter nedladdningen kontrollerades hashen utan att verifiera källan). Om projektets servrar äventyrades kunde angriparna spoofa en uppdatering och distribuera skadlig kod bland WordPress-baserade webbplatser som använder ett automatiskt installationssystem för uppdateringar. I enlighet med den tidigare använda modellen för förtroendeleverans skulle en sådan substitution ha gått obemärkt förbi på användarnas sida.
Med hänsyn till det faktum att av w3techs-projektet, WordPress-plattformen används på 33.8 % av webbplatserna i nätverket, skulle incidenten ha tagit omfattningen av en katastrof. Samtidigt var faran för infrastrukturkompromisser inte hypotetisk, utan ganska verklig. Till exempel för flera år sedan en av säkerhetsforskarna en sårbarhet som gjorde det möjligt för en angripare att köra sin kod på serversidan av api.wordpress.org.
När det gäller digitala signaturer kommer att få kontroll över uppdateringsdistributionsservern inte leda till att användarsystemen äventyras, eftersom för att utföra en attack måste du dessutom skaffa en separat lagrad privat nyckel, med vilken uppdateringar signeras.
Implementeringen av att kontrollera källan till uppdateringar med hjälp av en digital signatur försvårades av det faktum att stöd för de nödvändiga kryptografiska algoritmerna dök upp i PHP-standardpaketet relativt nyligen. De nödvändiga kryptografiska algoritmerna dök upp tack vare integrationen av biblioteket till huvudlaget . Men som den minsta versionen av PHP som stöds i WordPress version 5.2.4 (från WordPress 5.2 - 5.6.20). Att aktivera stöd för digitala signaturer skulle leda till en avsevärd ökning av kraven för den minsta versionen av PHP som stöds eller tillägg av ett externt beroende, vilket utvecklare inte kunde göra med tanke på förekomsten av PHP-versioner i värdsystem.
Lösningen var och införandet av en kompakt version av Libsodium i WordPress 5.2 - , där en minsta uppsättning algoritmer för att verifiera digitala signaturer är implementerad i PHP. Implementeringen lämnar mycket övrigt att önska när det gäller prestanda, men löser helt kompatibilitetsproblemet, och låter även plugin-utvecklare börja implementera moderna kryptografiska algoritmer.
En algoritm används för att generera digitala signaturer , utvecklad med deltagande av Daniel J. Bernstein. En digital signatur genereras för SHA384-hashvärdet som beräknas från innehållet i uppdateringsarkivet. Ed25519 har en högre säkerhetsnivå än ECDSA och DSA, och visar mycket hög hastighet för verifiering och signaturskapande. Resistansen mot hackning för Ed25519 är cirka 2^128 (i genomsnitt kommer en attack på Ed25519 att kräva 2^140 bitars operationer), vilket motsvarar motståndet hos algoritmer som NIST P-256 och RSA med en nyckelstorlek på 3000 bitar eller 128-bitars blockchiffer. Ed25519 är inte heller mottaglig för problem med hashkollisioner och är inte mottaglig för cache-timing-attacker eller sidokanalattacker.
I WordPress 5.2-versionen täcker verifiering av digital signatur för närvarande bara större plattformsuppdateringar och blockerar inte uppdateringen som standard, utan informerar bara användaren om problemet. Det beslutades att inte aktivera standardblockeringen omedelbart på grund av behovet av en fullständig kontroll och bypass . I framtiden är det också planerat att lägga till digital signaturverifiering för att verifiera källan för installation av teman och plugins (tillverkare kommer att kunna signera utgåvor med sin nyckel).
Förutom stöd för digitala signaturer i WordPress 5.2 kan följande ändringar noteras:
- Två nya sidor har lagts till i avsnittet "Site Health" för felsökning av vanliga konfigurationsproblem, och ett formulär har också tillhandahållits genom vilket utvecklare kan lämna felsökningsinformation till webbplatsadministratörer;
- Lade till implementering av "white screen of death", som visas i händelse av fatala problem och hjälper administratören att självständigt fixa problem relaterade till plugins eller teman genom att byta till ett speciellt kraschåterställningsläge;
- Ett system för att kontrollera kompatibilitet med plugins har implementerats som automatiskt kontrollerar möjligheten att använda plugin i den aktuella konfigurationen, med hänsyn till vilken version av PHP som används. Om ett plugin kräver en nyare version av PHP för att fungera, kommer systemet automatiskt att blockera inkluderingen av denna plugin;
- Lade till stöd för att aktivera moduler med JavaScript-kod med hjälp av и ;
- Lade till en ny privacy-policy.php-mall som låter dig anpassa innehållet på sidan med sekretesspolicy;
- För teman har en wp_body_open hook-hanterare lagts till, så att du kan infoga kod direkt efter body-taggen;
- Kraven på minimiversionen av PHP har höjts till 5.6.20, plugins och teman har nu möjlighet att använda namnrymder och anonyma funktioner;
- Lade till 13 nya ikoner.
Dessutom kan du nämna kritisk sårbarhet i WordPress-plugin (CVE-2019-11185). Sårbarheten tillåter att godtycklig PHP-kod exekveras på servern. Insticksprogrammet används på mer än 27 tusen webbplatser för att organisera en interaktiv chatt med en besökare, inklusive på webbplatser för företag som IKEA, Adobe, Huawei, PayPal, Tele2 och McDonald's (Live Chat används ofta för att implementera irriterande popup-fönster chattar på företagets webbplatser med erbjudanden chattar med den anställde).
Problemet visar sig i koden för att ladda upp filer till servern och låter dig kringgå kontrollen av giltiga filtyper och ladda upp ett PHP-skript till servern, och sedan exekvera det direkt via webben. Intressant nog, förra året identifierades en liknande sårbarhet redan i Live Chat (CVE-2018-12426), vilket gjorde det möjligt att ladda PHP-kod under sken av en bild, och ange en annan innehållstyp i fältet Innehållstyp. Som en del av korrigeringen har ytterligare kontroller lagts till för vitlistor och MIME-innehållstyp. Som det visar sig är dessa kontroller felaktigt implementerade och kan lätt kringgås.
I synnerhet är direkt uppladdning av filer med filtillägget ".php" förbjudet, men tillägget ".phtml", som är associerat med PHP-tolken på många servrar, lades inte till på den svarta listan. Vitlistan tillåter bara uppladdning av bilder, men du kan kringgå den genom att ange en dubbel tillägg, till exempel ".gif.phtml". För att kringgå MIME-typkontrollen i början av filen, innan taggen öppnades med PHP-kod, räckte det med att ange raden "GIF89a".
Källa: opennet.ru