lanzamiento del sistema de gestión de contenido web . La salida es notable por la finalización sobre la implementación de verificar actualizaciones y complementos mediante firma digital.
Hasta ahora, al instalar actualizaciones en WordPress, el principal factor de seguridad era la confianza en la infraestructura y servidores de WordPress (después de la descarga, se realizaba una verificación de hash sin verificación de la fuente). En caso de compromiso de los servidores del proyecto, los atacantes podían sustituir la actualización y propagar código malicioso entre los sitios basados en WordPress que utilizaban el sistema de instalación automática de actualizaciones. De acuerdo con el modelo de entrega basado en confianza previamente aplicado, tal sustitución quedaría sin ser detectada por los usuarios.
Dado que según el proyecto w3techs la plataforma WordPress se utiliza en el 33.8% de los sitios de la red, el incidente tendría dimensiones catastróficas. Además, el peligro de comprometer la infraestructura no era hipotético, sino completamente real. Por ejemplo, hace varios años, uno de los investigadores de seguridad una vulnerabilidad que permitía a un atacante ejecutar su código en el lado del servidor api.wordpress.org.
En caso de aplicar firmas digitales, obtener control sobre el servidor de distribución de actualizaciones no llevaría a la compromisión de los sistemas de los usuarios, ya que para llevar a cabo el ataque también se necesitaría obtener la clave privada que se almacena por separado, con la cual se realizan las firmas de las actualizaciones.
La implementación de la verificación de la fuente de actualizaciones mediante firma digital se vio obstaculizada por el hecho de que el soporte para los algoritmos criptográficos necesarios apareció en la distribución estándar de PHP relativamente recientemente. Los algoritmos criptográficos necesarios aparecieron gracias a la integración de la biblioteca en el núcleo . Pero como la versión mínima soportada en WordPress la versión 5.2.4 (a partir de WordPress 5.2 — 5.6.20). La inclusión del soporte para firmas digitales habría llevado a un aumento significativo en los requisitos de la versión mínima de PHP o la adición de una dependencia externa, lo cual los desarrolladores no podían permitir considerando la prevalencia de las versiones de PHP en los sistemas de hosting.
La solución fue e inclusión en WordPress 5.2 de una versión compacta de Libsodium — , en la que se implementa un conjunto mínimo de algoritmos en PHP para verificar firmas digitales. La implementación deja mucho que desear en términos de rendimiento, pero resuelve completamente el problema de compatibilidad y permite a los desarrolladores de plugins comenzar a incorporar algoritmos criptográficos modernos.
Para la formación de firmas digitales se utiliza el algoritmo , desarrollado con la participación de Daniel J. Bernstein. La firma digital se genera para un valor hash SHA384, calculado del contenido del archivo con la actualización. Ed25519 cuenta con un nivel de seguridad más alto que ECDSA y DSA, y muestra una velocidad muy alta en la verificación y creación de firmas. La resistencia a ataques de Ed25519 es del orden de 2^128 (en promedio, se requerirán 2^140 operaciones de bits para atacar Ed25519), lo que es equivalente a la resistencia de algoritmos como NIST P-256 y RSA con una longitud de clave de 3000 bits o un cifrado de bloques de 128 bits. Ed25519 también es inmune a problemas de colisiones en hashes, no es sensible a ataques a través de análisis de temporización de caché y ataques de canal lateral.
En la versión de WordPress 5.2, la verificación de la firma digital abarca actualmente solo las actualizaciones principales de la plataforma y por defecto no bloquea la actualización, solo informa al usuario sobre el problema encontrado. La decisión de no incluir el bloqueo por defecto se debe a la necesidad de una verificación completa y a sortear . En el futuro, también se planea añadir la verificación de la firma digital para verificar la fuente de instalación de temas y plugins (los fabricantes podrán firmar las versiones con su propia clave).
Además del soporte para firmas digitales, se pueden notar los siguientes cambios en WordPress 5.2:
- Se han añadido dos nuevas páginas en la sección «Site Health» para depurar problemas típicos de configuración, así como un formulario a través del cual los desarrolladores pueden dejar información de depuración a los administradores del sitio;
- Se ha añadido la implementación de una "pantalla blanca de la muerte" que se muestra en caso de problemas fatales y ayuda al administrador a solucionar problemas relacionados con complementos o temas, accediendo a un modo especial de recuperación después de un fallo;
- Se ha implementado un sistema de verificación de compatibilidad con complementos que comprueba automáticamente la posibilidad de uso del complemento en la configuración actual, considerando la versión de PHP utilizada. Si el complemento requiere una versión más reciente de PHP, el sistema bloqueará automáticamente su activación;
- Se ha añadido soporte para la activación de módulos con código JavaScript utilizando y ;
- Se ha añadido una nueva plantilla privacy-policy.php que permite personalizar el contenido de la página con los términos de privacidad;
- Para los temas de diseño, se ha añadido un manejador para el hook wp_body_open, lo que permite insertar código justo después de la etiqueta body;
- Los requisitos de la versión mínima de PHP se han elevado a 5.6.20, y en los complementos y temas de diseño ahora es posible utilizar espacios de nombres y funciones anónimas;
- Se han añadido 13 nuevos iconos.
Adicionalmente, se puede mencionar de una vulnerabilidad crítica en el complemento de WordPress (CVE-2019-11185). La vulnerabilidad permite ejecutar código PHP arbitrario en el servidor. El complemento se utiliza en más de 27,000 sitios para organizar chats interactivos con los visitantes, incluidos sitios de empresas como IKEA, Adobe, Huawei, PayPal, Tele2 y McDonald's (Live Chat se utiliza a menudo para implementar molestos chats emergentes en los sitios web de las empresas ofreciendo interactuar con un empleado).
El problema se manifiesta en el código de carga de archivos en el servidor y permite eludir la verificación de tipos de archivos permitidos y cargar un script PHP en el servidor, que luego puede ser ejecutado mediante una solicitud directa a través de la web. Curiosamente, el año pasado ya se había descubierto una vulnerabilidad similar en Live Chat (CVE-2018-12426), que permitía cargar código PHP a modo de imagen al especificar un tipo de contenido diferente en el campo Content-type. Como solución al problema, se agregaron verificaciones adicionales mediante listas blancas y tipos MIME de contenido. Resulta que estas verificaciones se implementaron incorrectamente y son fáciles de eludir.
En particular, la carga directa de archivos con la extensión «.php» está prohibida, pero la extensión «.phtml», a menudo relacionada con el intérprete PHP, no se ha añadido a la lista negra. La lista blanca solo permite la carga de imágenes, pero se puede eludir indicando una doble extensión, por ejemplo, «.gif.phtml». Para eludir la verificación del tipo MIME al inicio del archivo, antes de abrir la etiqueta con el código PHP, solo era necesario incluir la línea «GIF89a».
Fuente: opennet.ru
