versión do sistema de xestión de contido web . O lanzamento destaca pola súa finalización para implementación verificación de actualizacións e engadidos mediante sinatura dixital.
Ata agora, ao instalar actualizacións en WordPress, o principal factor de seguridade era a confianza na infraestrutura e os servidores de WordPress (despois da descarga, o hash verificábase sen verificar a fonte). Se os servidores do proxecto estaban comprometidos, os atacantes puideron substituír a actualización e distribuír código malicioso entre os sitios baseados en WordPress que usan o sistema de instalación automática de actualizacións. De acordo co modelo de entrega de confianza utilizado anteriormente, tal substitución pasaría desapercibida para os usuarios.
Tendo en conta o feito de que proxecto w3techs plataforma WordPress utilízase no 33.8% dos sitios da rede, o incidente tomaría a escala dun desastre. Ao mesmo tempo, o perigo de comprometer a infraestrutura non era hipotético, senón bastante real. Por exemplo, hai varios anos un dos investigadores de seguridade unha vulnerabilidade que permitía a un atacante executar o seu código no lado do servidor api.wordpress.org.
No caso das sinaturas dixitais, conseguir o control do servidor de distribución de actualizacións non suporá un compromiso dos sistemas dos usuarios, xa que para realizar un ataque será necesario, ademais, obter unha clave privada almacenada por separado, que se utiliza para asinar. actualizacións.
A introdución da comprobación da fonte das actualizacións mediante a sinatura dixital viuse obstaculizada polo feito de que o soporte para os algoritmos criptográficos necesarios apareceu na distribución estándar de PHP hai relativamente pouco tempo. Apareceron os algoritmos criptográficos necesarios debido á integración da biblioteca ao equipo principal . Pero como a versión mínima compatible de PHP en WordPress versión 5.2.4 (desde WordPress 5.2 - 5.6.20). Habilitar o soporte para sinaturas dixitais levaría a un aumento significativo dos requisitos para a versión mínima compatible de PHP ou a adición dunha dependencia externa, cousa que os desenvolvedores non poderían facer, dada a prevalencia das versións de PHP nos sistemas de hospedaxe.
A saída foi e a inclusión en WordPress 5.2 da variante compacta de Libsodium - , que implementa un conxunto mínimo de algoritmos en PHP para verificar sinaturas dixitais. A implementación deixa moito que desexar en termos de rendemento, pero resolve completamente o problema de compatibilidade e tamén permite aos desenvolvedores de complementos comezar a implementar algoritmos criptográficos modernos.
Utilízase un algoritmo para xerar sinaturas dixitais , desenvolvido coa aportación de Daniel J. Bernstein. Xérase unha sinatura dixital para o valor hash SHA384 calculado a partir do contido do arquivo de actualización. Ed25519 ten un maior nivel de seguridade que ECDSA e DSA, e demostra unha velocidade moi alta de verificación e xeración de sinaturas. A forza contra o cracking para Ed25519 é duns 2^128 (de media, son necesarios operacións de 25519^2 bits para atacar a Ed140), o que corresponde á forza de algoritmos como NIST P-256 e RSA cun tamaño de chave de 3000 bits ou Cifrado de bloques de 128 bits. Ed25519 tamén é inmune a colisións de hash, ataques de temporización da caché e ataques de canle lateral.
No lanzamento de WordPress 5.2, a verificación da sinatura dixital só cobre as actualizacións principais da plataforma ata agora e non bloquea a actualización por defecto, senón que só informa ao usuario sobre o problema. Decidiuse non activar o bloqueo de forma predeterminada inmediatamente debido á necesidade dunha comprobación e desvío completos . No futuro, tamén está previsto engadir a verificación de sinatura dixital para verificar a fonte de instalación de temas e complementos (os fabricantes poderán asinar versións coa súa propia chave).
Ademais do soporte para sinaturas dixitais en WordPress 5.2, pódense observar os seguintes cambios:
- Engadíronse dúas páxinas novas á sección "Saúde do sitio" para depurar problemas de configuración comúns, e proporcionouse un formulario a través do cal os desenvolvedores poden deixar información de depuración aos administradores do sitio;
- Engadida a implementación da "pantalla branca da morte", que se mostra en caso de problemas mortais e axuda ao administrador a solucionar os problemas asociados con complementos ou temas cambiando a un modo especial de recuperación de fallos;
- Implementouse un sistema de comprobación de compatibilidade de complementos, que verifica automaticamente a posibilidade de utilizar o complemento na configuración actual, tendo en conta a versión de PHP utilizada. Se un complemento require unha versión máis nova de PHP, o sistema bloqueará automaticamente a inclusión deste complemento;
- Engadido soporte para habilitar módulos con código JavaScript usando и ;
- Engadiuse un novo modelo privacy-policy.php que che permite personalizar o contido da páxina da política de privacidade;
- Engadiuse o manejador de gancho wp_body_open para os temas, que lle permite inserir código inmediatamente despois da etiqueta do corpo;
- Os requisitos mínimos da versión de PHP eleváronse a 5.6.20, os complementos e os temas agora teñen a capacidade de usar espazos de nomes e funcións anónimas;
- Engadíronse 13 novas iconas.
Pódese facer mención adicional vulnerabilidade crítica no complemento de WordPress (CVE-2019-11185). A vulnerabilidade permite executar código PHP arbitrario no servidor. O complemento utilízase en máis de 27 sitios para organizar un chat interactivo cun visitante, incluídos nos sitios de empresas como IKEA, Adobe, Huawei, PayPal, Tele2 e McDonald's (o chat en directo adoita utilizarse para implementar chats emerxentes molestos). nos sitios de empresas que ofrecen falar cun empregado).
O problema maniféstase no código para cargar ficheiros ao servidor e permítelle ignorar a comprobación de tipos de ficheiros válidos e cargar un script PHP ao servidor e, a continuación, executalo mediante acceso directo a través da web. Curiosamente, unha vulnerabilidade similar (CVE-2018-12426) xa se identificou no Live Chat o ano pasado, o que permitiu cargar código PHP baixo o pretexto dunha imaxe especificando un tipo de contido diferente no campo Tipo de contido. Como parte da corrección, engadíronse comprobacións adicionais para a lista branca e o tipo de contido MIME. Como se viu, estas comprobacións implícanse incorrectamente e pódense evitar facilmente.
En particular, está prohibida a carga directa de ficheiros coa extensión ".php", pero a extensión ".phtml", asociada ao intérprete PHP en moitos servidores, non estaba na lista negra. A lista branca só permite cargar imaxes, pero pódese evitar especificando unha extensión dobre, como ".gif.phtml". Para evitar a comprobación do tipo MIME ao comezo do ficheiro, antes de abrir a etiqueta con código PHP, bastaba con especificar a cadea "GIF89a".
Fonte: opennet.ru