lanzamiento del sistema de gestión de contenido web . El lanzamiento destaca por su finalización. sobre la implementación comprobar actualizaciones y adiciones mediante firma digital.
Hasta ahora, al instalar actualizaciones en WordPress, el principal factor de seguridad era la confianza en la infraestructura y los servidores de WordPress (tras la descarga, se comprobaba el hash sin verificar la fuente). Si los servidores del proyecto estaban comprometidos, los atacantes podían falsificar una actualización y distribuir código malicioso entre sitios basados en WordPress que utilizan un sistema de instalación automática de actualizaciones. De acuerdo con el modelo de entrega de confianza utilizado anteriormente, tal sustitución habría pasado desapercibida por parte de los usuarios.
Teniendo en cuenta el hecho de que Según el proyecto w3techs, la plataforma WordPress se utiliza en el 33.8% de los sitios de la red, el incidente habría adquirido dimensiones de desastre. Al mismo tiempo, el peligro de comprometer la infraestructura no era hipotético, sino bastante real. Por ejemplo, hace varios años uno de los investigadores de seguridad una vulnerabilidad que permitió a un atacante ejecutar su código en el lado del servidor de api.wordpress.org.
En el caso de las firmas digitales, obtener el control del servidor de distribución de actualizaciones no comprometerá los sistemas de los usuarios, ya que para realizar un ataque será necesario obtener adicionalmente una clave privada almacenada por separado con la que se firman las actualizaciones.
La implementación de la verificación de la fuente de actualizaciones mediante una firma digital se vio obstaculizada por el hecho de que el soporte para los algoritmos criptográficos necesarios apareció en el paquete PHP estándar hace relativamente poco tiempo. Los algoritmos criptográficos necesarios aparecieron gracias a la integración de la biblioteca. al equipo principal . Pero como la versión mínima soportada de PHP en WordPress versión 5.2.4 (de WordPress 5.2 - 5.6.20). Habilitar el soporte para firmas digitales conduciría a un aumento significativo en los requisitos para la versión mínima admitida de PHP o a la adición de una dependencia externa, lo que los desarrolladores no podrían hacer dada la prevalencia de las versiones de PHP en los sistemas de alojamiento.
La solución fue y la inclusión de una versión compacta de Libsodium en WordPress 5.2 - , en el que se implementa en PHP un conjunto mínimo de algoritmos para verificar firmas digitales. La implementación deja mucho que desear en términos de rendimiento, pero resuelve completamente el problema de compatibilidad y también permite a los desarrolladores de complementos comenzar a implementar algoritmos criptográficos modernos.
Se utiliza un algoritmo para generar firmas digitales. , desarrollado con la participación de Daniel J. Bernstein. Se genera una firma digital para el valor hash SHA384 calculado a partir del contenido del archivo de actualización. Ed25519 tiene un nivel de seguridad más alto que ECDSA y DSA y demuestra una velocidad muy alta de verificación y creación de firmas. La resistencia al pirateo de Ed25519 es de aproximadamente 2 ^ 128 (en promedio, un ataque a Ed25519 requerirá operaciones de 2 ^ 140 bits), lo que corresponde a la resistencia de algoritmos como NIST P-256 y RSA con un tamaño de clave de 3000 bits. o cifrado en bloque de 128 bits. Ed25519 tampoco es susceptible a problemas con colisiones de hash y no es susceptible a ataques de sincronización de caché o ataques de canal lateral.
En la versión WordPress 5.2, la verificación de firma digital actualmente solo cubre las principales actualizaciones de la plataforma y no bloquea la actualización de forma predeterminada, sino que solo informa al usuario sobre el problema. Se decidió no habilitar el bloqueo predeterminado de inmediato debido a la necesidad de una verificación completa y una omisión. . En el futuro, también está previsto agregar verificación de firma digital para verificar la fuente de instalación de temas y complementos (los fabricantes podrán firmar lanzamientos con su clave).
Además de la compatibilidad con firmas digitales en WordPress 5.2, se pueden observar los siguientes cambios:
- Se agregaron dos páginas nuevas a la sección "Salud del sitio" para depurar problemas de configuración comunes y también se proporcionó un formulario a través del cual los desarrolladores pueden dejar información de depuración a los administradores del sitio;
- Se agregó la implementación de la "pantalla blanca de la muerte", que se muestra en caso de problemas fatales y ayuda al administrador a solucionar de forma independiente problemas relacionados con complementos o temas cambiando a un modo especial de recuperación de fallas;
- Se ha implementado un sistema de verificación de compatibilidad con complementos, que verifica automáticamente la posibilidad de utilizar el complemento en la configuración actual, teniendo en cuenta la versión de PHP utilizada. Si un complemento requiere una versión más reciente de PHP para funcionar, el sistema bloqueará automáticamente la inclusión de este complemento;
- Se agregó soporte para habilitar módulos con código JavaScript usando и ;
- Se agregó una nueva plantilla Privacy-policy.php que le permite personalizar el contenido de la página de política de privacidad;
- Para los temas, se ha agregado un controlador de gancho wp_body_open, que le permite insertar código inmediatamente después de la etiqueta del cuerpo;
- Los requisitos para la versión mínima de PHP se han elevado a 5.6.20, los complementos y temas ahora tienen la capacidad de utilizar espacios de nombres y funciones anónimas;
- Se agregaron 13 íconos nuevos.
Además, puedes mencionar 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 mil sitios para organizar un chat interactivo con un visitante, incluidos sitios de empresas como IKEA, Adobe, Huawei, PayPal, Tele2 y McDonald's (el chat en vivo se utiliza a menudo para implementar molestas ventanas emergentes). chats en sitios de la empresa con ofertas chat con el empleado).
El problema se manifiesta en el código para cargar archivos al servidor y le permite omitir la verificación de tipos de archivos válidos y cargar un script PHP en el servidor y luego ejecutarlo directamente a través de la web. Curiosamente, el año pasado ya se identificó una vulnerabilidad similar en Live Chat (CVE-2018-12426), que permitía cargar código PHP bajo la apariencia de una imagen, especificando un tipo de contenido diferente en el campo Tipo de contenido. Como parte de la solución, se agregaron comprobaciones adicionales para las listas blancas y el tipo de contenido MIME. Resulta que estos controles se implementan incorrectamente y pueden eludirse fácilmente.
En particular, está prohibida la carga directa de archivos con la extensión “.php”, pero la extensión “.phtml”, que está asociada con el intérprete PHP en muchos servidores, no se agregó a la lista negra. La lista blanca solo permite la carga de imágenes, pero puedes omitirla especificando una extensión doble, por ejemplo, “.gif.phtml”. Para evitar la verificación del tipo MIME al comienzo del archivo, antes de abrir la etiqueta con código PHP, bastaba con especificar la línea “GIF89a”.
Fuente: opennet.ru