frigivelse af webindholdsstyringssystem . Udgivelsen er bemærkelsesværdig for sin færdiggørelse om implementering kontrollere opdateringer og tilføjelser ved hjælp af en digital signatur.
Indtil nu, når du installerede opdateringer i WordPress, var den vigtigste sikkerhedsfaktor tillid til WordPress-infrastrukturen og serverne (efter download blev hashen kontrolleret uden at verificere kilden). Hvis projektets servere blev kompromitteret, var angriberne i stand til at forfalske en opdatering og distribuere ondsindet kode blandt WordPress-baserede websteder, der bruger et automatisk opdateringsinstallationssystem. I overensstemmelse med den tidligere anvendte tillidsleveringsmodel ville en sådan substitution være gået ubemærket hen på brugernes side.
Under hensyntagen til, at af w3techs-projektet, bliver WordPress-platformen brugt på 33.8% af websteder på netværket, ville hændelsen have taget omfanget af en katastrofe. Samtidig var faren for infrastrukturkompromis ikke hypotetisk, men ganske reel. For eksempel for flere år siden en af sikkerhedsforskerne en sårbarhed, der gjorde det muligt for en angriber at udføre sin kode på serversiden af api.wordpress.org.
I tilfælde af digitale signaturer vil det at få kontrol over opdateringsdistributionsserveren ikke føre til kompromittering af brugersystemer, da for at udføre et angreb, skal du desuden anskaffe en separat gemt privat nøgle, som opdateringer signeres med.
Implementeringen af at kontrollere kilden til opdateringer ved hjælp af en digital signatur blev hæmmet af det faktum, at understøttelse af de nødvendige kryptografiske algoritmer dukkede op i standard-PHP-pakken relativt for nylig. De nødvendige kryptografiske algoritmer dukkede op takket være integrationen af biblioteket til hovedholdet . Men som minimum understøttet version af PHP i WordPress udgivelse 5.2.4 (fra WordPress 5.2 - 5.6.20). Aktivering af understøttelse af digitale signaturer vil føre til en betydelig stigning i kravene til den mindste understøttede version af PHP eller tilføjelse af en ekstern afhængighed, hvilket udviklere ikke kunne gøre i betragtning af udbredelsen af PHP-versioner i hostingsystemer.
Løsningen var og medtagelsen af en kompakt version af Libsodium i WordPress 5.2 - , hvor et minimumssæt af algoritmer til verificering af digitale signaturer er implementeret i PHP. Implementeringen lader meget tilbage at ønske med hensyn til ydeevne, men løser fuldstændigt kompatibilitetsproblemet og giver også plugin-udviklere mulighed for at begynde at implementere moderne kryptografiske algoritmer.
En algoritme bruges til at generere digitale signaturer , udviklet med deltagelse af Daniel J. Bernstein. En digital signatur genereres for SHA384-hashværdien beregnet ud fra indholdet af opdateringsarkivet. Ed25519 har et højere sikkerhedsniveau end ECDSA og DSA, og demonstrerer meget høj hastighed for verifikation og signaturoprettelse. Modstanden mod hacking for Ed25519 er omkring 2^128 (i gennemsnit vil et angreb på Ed25519 kræve 2^140 bit operationer), hvilket svarer til modstanden af algoritmer som NIST P-256 og RSA med en nøglestørrelse på 3000 bit eller 128-bit blokchiffer. Ed25519 er heller ikke modtagelig for problemer med hash-kollisioner og er ikke modtagelig for cache-timing-angreb eller sidekanalangreb.
I WordPress 5.2-udgivelsen dækker verifikation af digital signatur i øjeblikket kun større platformopdateringer og blokerer ikke opdateringen som standard, men informerer kun brugeren om problemet. Det blev besluttet ikke at aktivere standardblokeringen med det samme på grund af behovet for en fuld kontrol og bypass . I fremtiden er det også planlagt at tilføje digital signaturverifikation for at verificere kilden til installation af temaer og plugins (producenter vil være i stand til at signere udgivelser med deres nøgle).
Ud over understøttelse af digitale signaturer i WordPress 5.2 kan følgende ændringer bemærkes:
- To nye sider er blevet tilføjet til "Site Health"-sektionen til fejlfinding af almindelige konfigurationsproblemer, og der er også leveret en formular, hvorigennem udviklere kan overlade fejlfindingsoplysninger til webstedsadministratorer;
- Tilføjet implementering af den "hvide dødsskærm", der vises i tilfælde af fatale problemer og hjælper administratoren med selvstændigt at løse problemer relateret til plugins eller temaer ved at skifte til en speciel nedbrudsgendannelsestilstand;
- Der er implementeret et system til kontrol af kompatibilitet med plugins, som automatisk tjekker muligheden for at bruge pluginnet i den aktuelle konfiguration under hensyntagen til den anvendte version af PHP. Hvis et plugin kræver en nyere version af PHP for at fungere, vil systemet automatisk blokere inkluderingen af dette plugin;
- Tilføjet understøttelse for at aktivere moduler med JavaScript-kode ved hjælp af и ;
- Tilføjet en ny privacy-policy.php-skabelon, der giver dig mulighed for at tilpasse indholdet på siden med privatlivspolitik;
- For temaer er der tilføjet en wp_body_open hook-handler, så du kan indsætte kode umiddelbart efter body-tagget;
- Kravene til minimumsversionen af PHP er blevet hævet til 5.6.20, plugins og temaer har nu mulighed for at bruge navnerum og anonyme funktioner;
- Tilføjet 13 nye ikoner.
Derudover kan du nævne kritisk sårbarhed i WordPress plugin (CVE-2019-11185). Sårbarheden gør det muligt at udføre vilkårlig PHP-kode på serveren. Pluginnet bruges på mere end 27 tusind websteder til at organisere en interaktiv chat med en besøgende, herunder på websteder for virksomheder som IKEA, Adobe, Huawei, PayPal, Tele2 og McDonald's (Live Chat bruges ofte til at implementere pop-up irriterende chats på virksomhedens websteder med tilbud chat med medarbejderen).
Problemet viser sig i koden til at uploade filer til serveren og giver dig mulighed for at omgå kontrollen af gyldige filtyper og uploade et PHP-script til serveren og derefter eksekvere det direkte via nettet. Interessant nok, sidste år blev en lignende sårbarhed allerede identificeret i Live Chat (CVE-2018-12426), som gjorde det muligt at indlæse PHP-kode under dække af et billede, der specificerede en anden indholdstype i feltet Indholdstype. Som en del af rettelsen er der tilføjet yderligere kontrol for hvidlister og MIME-indholdstype. Som det viser sig, er disse kontroller implementeret forkert og kan nemt omgås.
Især direkte upload af filer med filtypenavnet ".php" er forbudt, men filtypenavnet ".phtml", som er forbundet med PHP-fortolkeren på mange servere, blev ikke tilføjet til sortlisten. Hvidlisten tillader kun upload af billeder, men du kan omgå den ved at angive en dobbelt udvidelse, for eksempel ".gif.phtml". For at omgå MIME-typekontrollen i begyndelsen af filen, før du åbnede tagget med PHP-kode, var det nok at angive linjen "GIF89a".
Kilde: opennet.ru