utgivelse av webinnholdsstyringssystem Problemet er bemerkelsesverdig for sin slutt for implementering sjekke oppdateringer og tillegg ved hjelp av digital signatur.
Frem til nå, når du installerer oppdateringer i WordPress Hovedfaktoren for å sikre sikkerhet var tillit til infrastrukturen og serverne WordPress (Etter nedlasting ble hashen sjekket uten å bekrefte kilden). Hvis prosjektets servere ble kompromittert, hadde angriperne muligheten til å erstatte oppdateringen og distribuere skadelig kode blant nettsteder basert på WordPress, ved hjelp av det automatiske installasjonssystemet for oppdateringer. Med den tidligere brukte pålitelige leveringsmodellen ville en slik erstatning ha gått uoppdaget forbi på brukersiden.
Tatt i betraktning at i henhold til w3techs plattformprosjekt WordPress brukt av 33.8 % av nettstedene på Internett, ville en hendelse vært katastrofal. Dessuten var faren for kompromittering av infrastrukturen ikke hypotetisk, men ganske reell. For flere år siden, for eksempel, en sikkerhetsforsker En sårbarhet som tillot en angriper å kjøre sin egen kode på api.wordpress.org-serveren.
Hvis digitale signaturer brukes, vil det å få kontroll over oppdateringsdistribusjonsserveren ikke føre til kompromittering av brukersystemer, siden det for å utføre et angrep ville være nødvendig å skaffe en separat lagret privat nøkkel som brukes til å signere oppdateringer.
Implementeringen av verifisering av oppdateringskilde ved hjelp av en digital signatur ble hemmet av at støtte for nødvendige kryptografiske algoritmer ble lagt til standard PHP-distribusjon relativt nylig. De nødvendige kryptografiske algoritmene ble lagt til gjennom bibliotekintegrasjon. til hovedlaget Men som et minimum støttet i WordPress PHP-versjoner Versjon 5.2.4 (fra og med WordPress 5.2–5.6.20). Å aktivere støtte for digitale signaturer ville ha økt kravene til den minimumsstøttede PHP-versjonen betydelig eller lagt til en ekstern avhengighet, noe utviklerne ikke kunne gjøre gitt utbredelsen av PHP-versjoner på hostingsystemer.
Løsningen var og inkludering i komposisjonen WordPress 5.2 kompakt variant av Libsodium - , som implementerer et minimalt sett med algoritmer for å verifisere digitale signaturer i PHP. Selv om implementeringen etterlater mye å være ønsket når det gjelder ytelse, løser den kompatibilitetsproblemet fullstendig og lar plugin-utviklere begynne å implementere moderne kryptografiske algoritmer.
En algoritme brukes til å generere digitale signaturer , utviklet med deltakelse fra Daniel J. Bernstein. Den digitale signaturen genereres for SHA384-hashverdien beregnet fra innholdet i arkivet som inneholder oppdateringen. Ed25519 tilbyr et høyere sikkerhetsnivå enn ECDSA og DSA, og viser svært høy verifiserings- og signaturopprettingshastighet. Angrepsmotstanden til Ed25519 er omtrent 2^128 (i gjennomsnitt ville et angrep mot Ed25519 kreve 2^140-bit operasjoner), noe som tilsvarer styrken til algoritmer som NIST P-256 og RSA med en nøkkelstørrelse på 3000 bit, eller en 128-bit blokkchiffer. Ed25519 er heller ikke utsatt for hashkollisjoner, cache-timing-angrep og sidekanalangrep.
I utgaven WordPress 5.2 Verifisering av digital signatur dekker for øyeblikket bare større plattformoppdateringer og blokkerer ikke oppdateringen som standard, men informerer kun brukeren om problemet. Det ble besluttet å ikke aktivere blokkering som standard på grunn av behovet for en fullstendig kontroll og omgåelse. I fremtiden er det også planlagt å legge til verifisering av digital signatur for å bekrefte installasjonskilden til temaer og plugins (produsenter vil kunne signere utgivelser med sin egen nøkkel).
I tillegg til å støtte digitale signaturer, WordPress 5.2 Følgende endringer kan bemerkes:
- Nettstedshelsedelen er oppdatert med to nye sider for feilsøking av vanlige oppsettproblemer, og det er lagt til et skjema der utviklere kan sende inn feilsøkingsinformasjon til nettstedsadministratorer.
- Lagt til en «hvit skjerm med dødsfall»-funksjon som vises ved fatale problemer og hjelper administratoren med å løse problemer relatert til pluginer eller temaer uavhengig ved å bytte til en spesiell krasjgjenopprettingsmodus;
- En kompatibilitetskontroll for plugin-moduler er implementert, som automatisk sjekker plugin-modulens kompatibilitet med gjeldende konfigurasjon basert på gjeldende PHP-versjon. Hvis en plugin-modul krever en nyere versjon av PHP, vil systemet automatisk blokkere inkluderingen.
- La til støtte for å aktivere moduler med JavaScript-kode ved hjelp av и ;
- En ny privacy-policy.php-mal er lagt til, slik at du kan tilpasse innholdet på siden med personvernregler.
- For temaer er hook-håndtereren wp_body_open lagt til, slik at du kan sette inn kode rett etter body-taggen;
- Minimumskravet for PHP-versjon er hevet til 5.6.20, og plugins og temaer støtter nå navnerom og anonyme funksjoner;
- La til 13 nye ikoner.
I tillegg kan du nevne kritisk sårbarhet i WordPress-plugin (CVE-2019-11185). Sårbarheten tillater at vilkårlig PHP-kode kjøres på serveren. Plugin-modulen brukes på over 27 000 nettsteder for å muliggjøre interaktiv chat med besøkende, inkludert besøkende fra selskaper som IKEA, Adobe, Huawei, PayPal, Tele2 og McDonald's. (Live Chat brukes ofte til å implementere irriterende popup-chatter på bedriftsnettsteder, der man tilbyr å chatte med en ansatt.)
Problemet manifesterer seg i filopplastingskoden og tillater omgåelse av filtypekontroller, opplasting av et PHP-skript til serveren og deretter kjøring av det direkte via nettet. Interessant nok ble et lignende sikkerhetsproblem (CVE-2018-12426) oppdaget i Live Chat i fjor, som tillot at PHP-kode lastes opp som et bilde ved å spesifisere en annen innholdstype i Content-type-feltet. Som en del av løsningen ble det lagt til ytterligere kontroller mot hvitelister og MIME-innholdstyper. Det viser seg at disse kontrollene ble implementert feil og enkelt kan omgås.
Spesielt er direkte opplasting av filer med filtypen «.php» forbudt, men filtypen «.phtml», som er knyttet til PHP-tolken på mange servere, ble ikke svartelistet. Hvitelisten tillater bare bildeopplasting, men dette kan omgås ved å spesifisere en dobbel filtypen, for eksempel «.gif.phtml». For å omgå MIME-typekontroll var det tilstrekkelig å ganske enkelt spesifisere strengen «GIF89a» i begynnelsen av filen, før åpningstaggen som inneholder PHP-koden.
Kilde: opennet.ru
