udgivelsen af systemet til webindholdsstyring . Udgivelsen er bemærkelsesværdig ved afslutningen for implementering af opdaterings- og tilføjelsesverifikation via digital signatur.
Indtil nu har tillid til infrastrukturen og serverne i WordPress været den primære sikkerhedsfaktor ved installation af opdateringer (efter upload blev en hash verificeret uden verifikation af kilden). I tilfælde af kompromittering af projektets servere havde angribere mulighed for at ændre opdateringen og sprede skadelig kode blandt WordPress-baserede hjemmesider, der bruger automatisk opdateringssystem. Ifølge den tidligere anvendte tillidsmodel for levering ville en sådan ændring for brugerne forblive uopdaget.
I betragtning af at ifølge projektet w3techs anvendes WordPress-platformen på 33,8% af hjemmesiderne på nettet, ville en sådan hændelse have katastrofale omfang. Denne risiko for kompromittering af infrastrukturen var ikke hypotetisk, men helt reel. For eksempel opdagede en sikkerhedsforsker for nogle år siden en sårbarhed, der gjorde det muligt for en angriber at udføre sin kode på api.wordpress.org serveren.
Ved anvendelse af digitale signaturer vil kontrol over distributionsserveren for opdateringer ikke føre til kompromittering af brugersystemer, da det for at kunne gennemføre et angreb desuden vil være nødvendigt at få fat i den separat opbevarede private nøgle, som bruges til at underskrive opdateringerne.
Implementeringen af opdateringskildeverifikation via digital signatur blev hindret af, at understøttelsen af de nødvendige kryptografiske algoritmer først for nylig blev en standarddel af PHP. De nødvendige kryptografiske algoritmer blev tilgængelige gennem integrationen af biblioteket i den grundlæggende del . Men som den minimalt understøttede version i WordPress er PHP version 5.2.4 (fra WordPress 5.2 – 5.6.20). Indførelsen af støtte til digitale signaturer ville have medført væsentlige krav til den minimalt understøttede version af PHP eller tilføjelse af en ekstern afhængighed, noget udviklerne ikke kunne gå med til i betragtning af udbredelsen af PHP-versioner i hosting-systemer.
Løsningen blev og inkorporeringen af en kompakt version af Libsodium i WordPress 5.2 — , hvor der er implementeret et minimalt sæt af algoritmer til verificering af digitale signaturer i PHP. Implementeringen efterlader meget at ønske med hensyn til ydeevne, men løser fuldt ud problemet med kompatibilitet og giver udviklere mulighed for at begynde at implementere moderne kryptografiske algoritmer.
Til dannelse af digitale signaturer bruges algoritmen , udviklet med deltagelse af Daniel Bernstein (Daniel J. Bernstein). Den digitale signatur dannes for værdien af hash SHA384, beregnet ud fra indholdet af arkivet med opdateringen. Ed25519 har et højere sikkerhedsniveau end ECDSA og DSA og viser meget høj hastighed i verificering og oprettelse af signaturer. Modstandsdygtigheden over for angreb for Ed25519 er omkring 2^128 (i gennemsnit kræver et angreb på Ed25519 2^140 bit-operationer), hvilket svarer til modstandsdygtigheden i algoritmer såsom NIST P-256 og RSA med en nøglelængde på 3000 bit eller 128-bit bloksymmetrisk kryptering. Ed25519 er heller ikke udsat for problemer med kollisioner i hashes, er ikke følsom over for cache-timing angreb og angreb via sidekanaler.
I udgaven af WordPress 5.2 dækker verificeringen af den digitale signatur kun de vigtigste opdateringer af platformen og medfører ikke som standard blokering af opdateringer, men informerer blot brugeren om et problem, der er opstået. Standardblokeringen er blevet besluttet ikke at inkludere straks på grund af behovet for en fuld verificering og omgåelse . I fremtiden planlægges det også at tilføje kontrollen af den digitale signatur til verificeringen af kilden til installationen af temaer og plugins (producenterne vil kunne signere udgivelser med deres nøgle).
Udover understøttelsen af digitale signaturer kan der i WordPress 5.2 også nævnes følgende ændringer:
- Der er tilføjet to nye sider i sektionen 'Site Health' til fejlfindingsnormale konfigurationsproblemer samt en formular, gennem hvilken udviklere kan efterlade fejlfindinginformation til webstedets administratorer;
- Der er tilføjet en implementering af 'den hvide dødsskærm', som vises ved fatale problemer og hjælper administratoren med selv at løse problemer relateret til plugins eller temaer ved at gå ind i en særlig genoprettelsestilstand efter fejl.
- Et kompatibilitetstjeksystem er implementeret, som automatisk kontrollerer, om en plugin kan bruges med den nuværende konfiguration med hensyn til den anvendte PHP-version. Hvis plugin'et kræver en nyere version af PHP for at fungere, blokerer systemet automatisk for aktiveringen af den pågældende plugin;
- Der er tilføjet støtte til aktivering af moduler med JavaScript-kode ved hjælp af og ;
- Der er tilføjet en ny skabelon privacy-policy.php, der giver mulighed for at tilpasse indholdet på siden med vilkårene for overholdelse af fortrolighed;
- For temaer er der tilføjet en behandler til wp_body_open hook, som gør det muligt at indsætte kode lige efter body-tagget;
- Kravene til minimum PHP-versionen er hævet til 5.6.20, og plugins og temaer har nu mulighed for at bruge navnerum og anonyme funktioner;
- Der er tilføjet 13 nye ikoner.
Desuden kan det nævnes kritisk sårbarhed i WordPress-pluginet (CVE-2019-11185). Sårbarheden giver mulighed for at eksekvere vilkårlig PHP-kode på serveren. Plugin'et anvendes på over 27.000 websteder til at organisere interaktiv chat med besøgende, herunder på websteder som IKEA, Adobe, Huawei, PayPal, Tele2 og McDonald's (Live Chat bruges ofte til at implementere påtrængende pop-up chats på virksomhedens websteder med et tilbud om at tale med en medarbejder).
Problemet opstår i koden til filupload til serveren og muliggør omgåelse af kontrol af tilladte filtyper og upload af en PHP-script til serveren, hvorefter den kan eksekveres ved direkte adgang via web. Det er interessant, at der sidste år allerede blev opdaget en lignende sårbarhed i Live Chat (CVE-2018-12426), som gjorde det muligt at uploade PHP-kode som et billede ved at angive en anden indholdstype i Content-type-feltet. I forbindelse med reparationen af problemet blev der tilføjet ekstra kontroller baseret på hvide lister og MIME-typer for indholdet. Det viste sig, at disse kontroller var implementeret forkert og nemt kunne omgås.
Specifikt er direkte upload af filer med filtypenavn „.php“ forbudt, men filtypen „.phtml“ blev ikke tilføjet til sortlisten, som på mange servere er tilknyttet PHP-interpretatoren. Den hvide liste tillader kun upload af billeder, men kan omgås ved at angive en dobbelt udvidelse, for eksempel „.gif.phtml“. For at omgå MIME-typen skulle der blot angives strengen „GIF89a“ før åbning af PHP-kodetags i starten af filen.
Kilde: opennet.ru
