La semana pasada, los desarrolladores de CMS Drupal cerraron (las
noticias , más detalles
en su sitio web ) dos vulnerabilidades críticas
a la vez. Ambos problemas afectan a las versiones 7.x y 8.x de Drupal. La vulnerabilidad más grave se descubrió en el sistema integrado de envío de correo electrónico (DefaultMailSystem :: mail ()). Puede usarlo de tal manera que al procesar un mensaje, sea posible ejecutar código arbitrario. La razón de esto, como de costumbre, es la falta de verificación adecuada de una serie de variables.
La segunda vulnerabilidad se descubrió en el módulo de Enlaces contextuales: le permite modificar elementos de páginas web sin ir al panel de control. La falta de verificación de los parámetros pasados durante la ejecución de dicha solicitud también puede conducir a la ejecución del código. Es cierto que, a diferencia de la primera vulnerabilidad, esto se explota solo si el atacante ya tiene el derecho de editar el sitio.
Dichas noticias generalmente no caen en el resumen: ¡bien, encontrado, bien cerrado, bien hecho! Pero al menos una vez al año, vale la pena mirar los sistemas de administración de contenido más populares y comprender en el futuro cómo van las cosas con seguridad. ¿Existe una fragmentación de las versiones de CMS, similar, por ejemplo, a la fragmentación de la plataforma Android? ¿Es todo tan malo con la seguridad, como, por ejemplo, en la industria de esos dispositivos IoT, que parecen no ser dispositivos IoT, sino enrutadores y cámaras? A ver
Primero necesitas entender dónde mirar. Información suficientemente detallada sobre el uso de un CMS particular proporciona
encuestas de tecnología web . Los autores del recurso escanean regularmente los 10 millones de sitios más visitados en Internet (según la calificación del servicio de Alexa) y analizan los sistemas de gestión de contenido utilizados. Los resultados generales del estudio se pueden ver
en esta página , aquí hay un gráfico a partir de allí:
Bueno, en primer lugar, no fue posible obtener información sobre CMS para el 46,1% de los sitios, más precisamente, no se utiliza ninguno de los sistemas que este servicio puede identificar de manera confiable. Entre los sitios donde se determinó el CMS, el líder indiscutible es Wordpress, una especie de mercado de Android CMS. El segundo y tercer lugar con un retraso significativo están ocupados por Joomla y Drupal, y luego en Top10 hay principalmente servicios que ofrecen la creación de un sitio terminado en su propia plataforma, para aquellos que necesitan más fácil y más rápido. Juntos, Joomla, Drupal y Wordpress están instalados en el 68.8% de los sitios con CMS conocidos, o el 37.2% de todos los sitios de los 10 millones estudiados.
La fragmentación ya es evidente en el nivel de elección de CMS: Wordpress es el líder claro, pero se instala solo en un tercio de los recursos en línea, y la mitad de los sitios en general funcionan por alguna razón. Quizás hay un administrador sombrío que todavía descarga HTML estático a través de FTP de la vieja escuela. Es difícil sacar conclusiones de esta variedad: por un lado, la fragmentación complica la vida del atacante, por otro, nadie sabe realmente cómo están las cosas con la seguridad de aproximadamente la mitad de Internet. En criptografía, los algoritmos de cifrado autoescritos se han equiparado durante mucho tiempo a un rastrillo afilado. ¿La gestión web debería ser diferente?
Veamos la distribución de versiones para los tres CMS más populares. Aquí está la distribución de Wordpress. w3techs actualiza sus informes diariamente para que se espere que la información sea la última.
De alguna manera aburrido incluso. Veamos los detalles de la versión actual 4.x:
Algo más del 70% de los sitios web de Wordpress usan (a partir de la fecha de publicación) la versión más actualizada (excluyendo las actualizaciones periódicas de la versión principal). Esta, por supuesto, es una distribución más agradable que Android, donde la versión actual 8.x es
utilizada por el 19.2% de los dispositivos, pero no tanto como nos gustaría.
¿Hay algo que temer? Veamos la
historia de las versiones de Wordpress. La versión 4.9 se lanzó el 15 de noviembre de 2017, es decir, durante casi un año Wordpress 4.8 y las versiones anteriores son obsoletas. Desde la versión 4.9, al menos cuatro actualizaciones de CMS se han dirigido a corregir vulnerabilidades. La gravedad del riesgo de cada uno de ellos es un tema para un estudio más detallado, aunque no ha habido errores absolutamente críticos durante el año pasado. Sin embargo, la
versión 4.9.7 de julio cierra la vulnerabilidad, bajo ciertas condiciones, permitiéndole eliminar archivos fuera de la carpeta Cargas.
Veamos cómo está el héroe de la semana pasada: CMS Drupal.
Tales cosas La última versión de Drupal 8.x es utilizada por el 11.8% de los sitios que generalmente usan Drupal. La más popular es la versión anterior 7.x. W3techs no proporciona detalles sobre lanzamientos específicos dentro de la rama principal, así que supongamos que todos ya han sido actualizados (esto, por supuesto, es una suposición audaz). En cualquier caso, casi el 10% de los sitios de Drupal utilizan versiones no compatibles 4.x - 6.x.
La situación de CMS Joomla es la siguiente:
La versión actual de Joomla 3.8.13 se lanzó recientemente, el 9 de octubre. Puede ver cuántos sitios se han actualizado a la última versión en tan poco tiempo.
14.1% de todos los usuarios de la sucursal 3.8. O 5.8% de todos los usuarios de Joomla son aquellos que lograron actualizar el sitio a la última versión en 13 días. ¿Cuáles son las consecuencias si no actualiza el CMS a tiempo? Volveré a los ejemplos de Wordpress, ya que este es el sistema de administración de contenido web más popular y hackeado. Entonces (de repente), los mensajes sobre el secuestro práctico de sitios para actividades maliciosas en su mayor parte no mencionan el código principal de Wordpress, sino sus complementos.
Por ejemplo, las
noticias del año pasado sobre complementos realmente atacados, incluido, por ejemplo, el complemento de Flickr Gallery. En diciembre de 2017, Wordpress
bloqueó tres complementos más: todos fueron vendidos por los creadores y los nuevos propietarios implementaron puertas traseras en ellos. Aquí hay otro
análisis del uso de complementos que los desarrolladores han abandonado durante mucho tiempo, tienen vulnerabilidades críticas y todavía se usan en cientos de sitios.
Y no se trata solo de complementos. En repetidas ocasiones, se menciona una contraseña de fuerza bruta como un método de trabajo para atacar sitios de Wordpress (por ejemplo,
aquí y
aquí ). Y este problema también está más allá de las capacidades de los desarrolladores de Wordpress. Complicar la fuerza bruta y no usar las contraseñas más simples es tarea del administrador y los usuarios de los sitios, no de los desarrolladores.
¿Qué sucede cuando un sitio se piratea con éxito? Arriba, me refiero a las noticias sobre la instalación de mineros, aunque la mayoría de las veces aparecen scripts maliciosos clásicos en los sitios. Este verano ocurrió un caso importante: en julio, la plataforma de negociación CoinDash fue
pirateada , además, justo durante la recaudación de fondos como parte de la ICO. No se informa exactamente cómo fue pirateado el sitio, no necesariamente podría ser una vulnerabilidad en Wordpress. Pero el resultado es obvio: en la primera fase de recaudación de fondos de participantes privilegiados en el sitio, simplemente cambiaron el número de billetera para transferir fondos, como resultado de lo cual 7.7 millones de dólares en criptomonedas equivalentes fueron a los atacantes. Hay una
discusión interesante sobre Reddit sobre esto: ¿no será más confiable hacer una página estática en casos críticos? Oh, no estoy seguro de cuál es más confiable.
Según los resultados de este mini estudio, surge una pregunta clara: ¿es realmente necesario actualizar el código CMS, si las vulnerabilidades críticas no siempre están disponibles, los sitios a menudo se piratean a través de complementos, o incluso a través de la fuerza bruta de la contraseña? Como en el caso de los
enrutadores , un conjunto de medidas trae beneficios reales: actualizar el CMS, revisar la lista de complementos instalados y actualizar regularmente los realmente necesarios, cambiar la URL del administrador, las contraseñas seguras, la autenticación multifactor y solo la auditoría del usuario. La seguridad del sitio web (y cualquier otra cosa) es un proceso, no un resultado.
Agregar a la lista de tareas pendientes una verificación regular de la versión de CMS no es tan difícil. Si su sitio es administrado por una organización de terceros, no será superfluo discutir por separado el tema de las actualizaciones periódicas. Si ha sido "configurado un sitio" una vez, y desde entonces "simplemente funciona" sin ningún tipo de soporte, tiene problemas. Como vimos hoy, ni siquiera todos usan una medida tan simple para mejorar la seguridad de un sitio web como la actualización de un código.
Descargo de responsabilidad: las opiniones expresadas en este resumen pueden no coincidir siempre con la posición oficial de Kaspersky Lab. Los estimados editores generalmente recomiendan tratar cualquier opinión con escepticismo saludable.