llançament del sistema de gestió de contingut web . El llançament destaca per la seva finalització sobre la implementació comprovar les actualitzacions i les addicions mitjançant una signatura digital.
Fins ara, a l'hora d'instal·lar actualitzacions a WordPress, el principal factor de seguretat era la confiança en la infraestructura i els servidors de WordPress (després de la descàrrega, es verificava el hash sense verificar la font). Si els servidors del projecte estaven compromesos, els atacants podien falsejar una actualització i distribuir codi maliciós entre els llocs basats en WordPress que utilitzen un sistema d'instal·lació d'actualització automàtica. D'acord amb el model de lliurament de confiança utilitzat anteriorment, aquesta substitució hauria passat desapercebuda per part dels usuaris.
Tenint en compte el fet que del projecte w3techs, la plataforma WordPress s'utilitza en el 33.8% dels llocs de la xarxa, l'incident hauria pres l'escala d'un desastre. Al mateix temps, el perill de comprometre la infraestructura no era hipotètic, sinó força real. Per exemple, fa uns quants anys un dels investigadors de seguretat una vulnerabilitat que permetia a un atacant executar el seu codi al costat del servidor d'api.wordpress.org.
En el cas de les signatures digitals, obtenir el control del servidor de distribució d'actualitzacions no comportarà un compromís dels sistemes dels usuaris, ja que per dur a terme un atac, caldrà, a més, obtenir una clau privada emmagatzemada per separat, amb la qual es signen les actualitzacions.
La implementació de la comprovació de la font de les actualitzacions mitjançant una signatura digital es va veure obstaculitzada pel fet que el suport per als algorismes criptogràfics necessaris va aparèixer relativament recentment al paquet PHP estàndard. Els algorismes criptogràfics necessaris van aparèixer gràcies a la integració de la biblioteca a l'equip principal . Però com a versió mínima compatible de PHP a WordPress versió 5.2.4 (de WordPress 5.2 - 5.6.20). L'habilitació del suport per a signatures digitals comportaria un augment significatiu dels requisits per a la versió mínima compatible de PHP o l'addició d'una dependència externa, cosa que els desenvolupadors no podrien fer donada la prevalença de les versions de PHP als sistemes d'allotjament.
La solució era i la inclusió d'una versió compacta de Libsodium a WordPress 5.2 - , en què s'implementa un conjunt mínim d'algorismes per verificar signatures digitals en PHP. La implementació deixa molt a desitjar en termes de rendiment, però resol completament el problema de compatibilitat i també permet als desenvolupadors de connectors començar a implementar algorismes criptogràfics moderns.
S'utilitza un algorisme per generar signatures digitals , desenvolupat amb la participació de Daniel J. Bernstein. Es genera una signatura digital per al valor hash SHA384 calculat a partir del contingut de l'arxiu d'actualització. Ed25519 té un nivell de seguretat més alt que ECDSA i DSA i demostra una velocitat molt alta de verificació i creació de signatures. La resistència a la pirateria per a Ed25519 és d'uns 2^128 (de mitjana, un atac a Ed25519 requerirà operacions de 2^140 bits), que correspon a la resistència d'algorismes com NIST P-256 i RSA amb una mida de clau de 3000 bits. o xifratge de blocs de 128 bits. Ed25519 tampoc és susceptible a problemes amb col·lisions hash i no és sensible als atacs de temps de memòria cau i als atacs de canals laterals.
A la versió de WordPress 5.2, la verificació de signatura digital actualment només cobreix les actualitzacions principals de la plataforma i no bloqueja l'actualització per defecte, sinó que només informa l'usuari sobre el problema. Es va decidir no habilitar el bloqueig predeterminat immediatament a causa de la necessitat d'una comprovació completa i una derivació . En el futur, també està previst afegir la verificació de signatura digital per verificar la font d'instal·lació de temes i complements (els fabricants podran signar comunicacions amb la seva clau).
A més del suport per a signatures digitals a WordPress 5.2, es poden observar els canvis següents:
- S'han afegit dues pàgines noves a la secció "Salut del lloc" per depurar problemes de configuració habituals, i també s'ha proporcionat un formulari mitjançant el qual els desenvolupadors poden deixar la informació de depuració als administradors del lloc;
- S'ha afegit la implementació de la "pantalla blanca de la mort", que es mostra en cas de problemes fatals i ajuda a l'administrador a solucionar de manera independent els problemes relacionats amb els connectors o els temes canviant a un mode especial de recuperació d'accidents;
- S'ha implantat un sistema de comprovació de la compatibilitat amb els connectors, que comprova automàticament la possibilitat d'utilitzar el connector en la configuració actual, tenint en compte la versió de PHP utilitzada. Si un connector requereix una versió més nova de PHP per funcionar, el sistema bloquejarà automàticament la inclusió d'aquest connector;
- S'ha afegit suport per habilitar mòduls amb codi JavaScript и ;
- S'ha afegit una nova plantilla privacy-policy.php que us permet personalitzar el contingut de la pàgina de política de privadesa;
- Per als temes, s'ha afegit un controlador de ganxo wp_body_open, que us permet inserir codi immediatament després de l'etiqueta body;
- Els requisits per a la versió mínima de PHP s'han elevat a la 5.6.20, els connectors i els temes ara tenen la capacitat d'utilitzar espais de noms i funcions anònimes;
- S'han afegit 13 icones noves.
A més, podeu esmentar vulnerabilitat crítica al connector de WordPress (CVE-2019-11185). La vulnerabilitat permet executar codi PHP arbitrari al servidor. El connector s'utilitza en més de 27 mil llocs per organitzar un xat interactiu amb un visitant, inclosos els llocs d'empreses com IKEA, Adobe, Huawei, PayPal, Tele2 i McDonald's (el xat en directe s'utilitza sovint per implementar finestres emergents molestes). xats als llocs de l'empresa amb ofertes de xat amb l'empleat).
El problema es manifesta en el codi per carregar fitxers al servidor i us permet ometre la comprovació de tipus de fitxers vàlids i carregar un script PHP al servidor i, a continuació, executar-lo directament a través del web. Curiosament, l'any passat ja es va identificar una vulnerabilitat similar al xat en directe (CVE-2018-12426), que va permetre carregar codi PHP sota l'aparença d'una imatge, especificant un tipus de contingut diferent al camp Tipus de contingut. Com a part de la correcció, s'han afegit comprovacions addicionals per a les llistes blanques i el tipus de contingut MIME. Com a resultat, aquestes comprovacions s'implementen incorrectament i es poden evitar fàcilment.
En particular, es prohibeix la càrrega directa de fitxers amb l'extensió ".php", però l'extensió ".phtml", que està associada amb l'intèrpret PHP en molts servidors, no s'ha afegit a la llista negra. La llista blanca només permet pujar imatges, però podeu evitar-la especificant una extensió doble, per exemple, ".gif.phtml". Per evitar la comprovació del tipus MIME al començament del fitxer, abans d'obrir l'etiqueta amb codi PHP, n'hi havia prou amb especificar la línia "GIF89a".
Font: opennet.ru