Joomla, el segundo sistema de administración de contenido web (CMS) más popular del mundo, ha estado bajo ataque sostenido durante varios días, gracias a un par de vulnerabilidades desagradables reveladas la semana pasada.
Los avisos de seguridad 20161001 (CVE-2016-8870) y 20161002 (CVE-2016-8869) describen cómo fallas en Joomla código de registro de usuario podría permitiendo a un atacante «registrarse en un sitio cuando el registro ha sido deshabilitado» y luego «registrarse… con privilegios elevados».
Si el significado de estas dos afirmaciones no se ha entendido por completo, déjame decirlo claramente: en conjunto, las vulnerabilidades se pueden usar para desbloquear cualquier sitio que ejecute Joomla, en cualquier lugar de Internet, con poco más que una solicitud cortés que detalla lo que harías. te gusta que te llamen y cuánto poder quieres.
Y hay millones de sitios Joomla vulnerables.
Las vulnerabilidades de Joomla fueron causadas por el «uso incorrecto de datos sin filtrar» y «controles inadecuados», explicaciones que se leen como un resumen enlatado de los últimos 20 años de vulnerabilidades web.
Todas las versiones de Joomla desde la 3.4.4 hasta la 3.6.3 están afectadas. Cualquiera que todavía esté ejecutando una versión sin parches del CMS debe actualizar a 3.6.4 sin demora y luego escanear su sistema en busca de signos de compromiso.
La actualización 3.6.4 simplemente elimina el código problemático por completo y corrige una tercera vulnerabilidad de alta prioridad asociada, 20161003 (CVE-2016-9081) en el proceso.
Ha habido tal aumento en los ataques desde que se revelaron las vulnerabilidades que la firma de seguridad web Sucuri sugiere que los propietarios de sitios asuman que sus sitios ya están comprometidos:
… debido al fuerte incremento [in attacks], creemos que todo Joomla! el sitio que no ha sido actualizado probablemente ya esté comprometido.
El mensaje recuerda una advertencia emitida en 2014 después de que se descubriera una vulnerabilidad igualmente crítica en Drupal, otro CMS web muy popular.
SA-CORE-2014-005 reveló que Drupal era vulnerable a un simple ataque de inyección SQL que podría otorgar a un atacante control total sobre un servidor comprometido.
Los ataques automatizados en los sitios de Dupal comenzaron horas después de que se lanzara el parche, dando a los propietarios de los sitios las ventanas más estrechas para implementar los parches.
El propio equipo de seguridad de Drupal estimó que esta ventana no superaba las siete horas:
Debe asumir que todos los sitios web de Drupal 7 se han visto comprometidos a menos que se actualicen o parcheen antes del 15 de octubre a las 23:00 UTC, que es 7 horas después del anuncio.
Si estaba dormido cuando llegó la alerta por correo electrónico del primer parche, que así sea…
El éxito de los CMS populares como WordPress, Drupal y Joomla los convierte en objetivos extremadamente atractivos: una sola vulnerabilidad puede dar a los delincuentes la capacidad de atacar millones de objetivos desde cualquier lugar con un solo exploit.
Las vulnerabilidades explotables de forma remota tan graves como las que se encontraron en Joomla la semana pasada son afortunadamente raras, pero con la web tan claramente subdividida en vastos monocultivos de CMS, una explotación remota puede barrerlos como el fuego en un bosque parcheado.
Y la amenaza que representan los sitios pirateados va mucho más allá de las personas que los poseen, los operan y los usan.
Los sitios y servidores comprometidos pueden agruparse en botnets y usarse para distribuir malware, enviar miles de millones de correos electrónicos no deseados o llevar a cabo devastadores ataques DDoS.
El estado actual de las contramedidas (enviar correos electrónicos o actualizaciones automáticas y esperar que los operadores del sitio los reciban, lean, entiendan y respondan en cuestión de horas) parece irremediablemente inadecuado en comparación.
El software CMS moderno tiene éxito en parte debido al poder que pone en manos de los usuarios no técnicos. Hacer de estos mismos usuarios el eje de nuestra seguridad colectiva no tiene sentido.
Como hemos dicho muchas veces antes en Naked Security, no importa cuándo esté disponible un parche, lo que cuenta es cuándo se aplica. Es por eso que creo que simplemente no hay otra opción para Drupal y Joomla que seguir el ejemplo de WordPress e implementar actualizaciones de seguridad automáticas de forma predeterminada.
