Nueva inyección de código SQL en PHP-Nuke

Hoy le toca a PHP-Nuke ser protagonista de un nuevo incidente de seguridad debido a un código defectuoso.

PHP-Nuke es un software CMS (Content Management System, Sistema de Gestión de Contenidos) libre, ofrecido al público según GNU/GPL, y que permite disponer de un portal dinámico con escasos conocimientos de programación. PHP-Nuke es un derivado de Thatware, y su autoría corresponde a Franciso Burzi. PHP-Nuke necesita para su funcionamiento un servidor Web, habitualmente Apache, soporte PHP en el servidor y una base de datos, generalmente MySQL.

El último problema reportado por una de estas soluciones es un problema crítico que afecta a la versión 7.8, no descartándose que la falla sea aplicable en versiones anteriores de las ramas 6.x y 7.x. Estos problemas permiten la manipulación de datos remota y facultan a los atacantes a conducir inyecciones de código SQL, con la consiguiente peligrosidad de la exposición de datos sensibles.

El módulo defectuoso es uno de los principales, “Your_Account”, habilitado para que los usuarios del CMS gestionen la información del portal que les corresponda a título particular, tales como por ejemplo, los datos de autenticación de los usuarios. La inyección de código permite en este caso obtener el nombre de usuario y el MD5 de su clave, información suficiente para poder tomar control de la aplicación, tal y como veremos ahora.

Imaginemos que instalamos PHP-Nuke y seleccionamos, para poder administrarlo, un nombre de administrador y como clave, una clave poco robusta de ocho caracteres. Es muy frecuente que estas soluciones posean claves débiles, con pocos caracteres y por tanto, potencialmente peligrosas para su adivinación, ya que estos productos se caracterizan por una instalación muy sencilla y por tanto, suelen ser escogidos por usuarios con pocas nociones de programación dinámica que buscan soluciones rápidas a sus necesidades de interactividad Web.

PHP-Nuke, es, por tradición, un producto muy popular y extendido por tanto, el grado general de seguridad que le aplican los administradores a la solución es muy heterogéneo, primando las instalaciones por defecto y sobre todo, versiones con módulos adicionales que en numerosas ocasiones restan seguridad a la infraestructura.

Cualquier base de datos que permita obtener la palabra a partir del hash, nos permitiría obtener la clave. Así pues, ejecutando la inyección en el módulo, obtendríamos dos datos en nuestro PHP-Nuke: la inyección revela, en nuestro caso de estudio, que el usuario administrativo es “admin” y el hash MD5 de su clave es 4b8007a57b557d4d6a84e813fa62de08. Sólo nos falta acudir a una base de datos de hashes MD5, por ejemplo la que existe en http://gdataonline.com/seekhash.php, introducir el hash y obtendríamos que la clave de administración es, para el hash citado, la palabra “hispasec”. Con esos datos, podemos autenticarnos mediante el script admin.php, consiguiendo privilegios administrativos plenos y acceso total a la aplicación.

Los problemas, en este caso, han sido resueltos por la versión 7.9 con parche 3.1, si bien existe un parque de usuarios PHP-Nuke muy grande cuyos tiempos de reacción ante estos problemas son, al igual que su grado de conocimiento de seguridad Web, muy heterogéneo. Desde los primeros adoptantes más proactivos, que parchean inmediatamente, a usuarios rezagados que ni siquiera advierten el problema hasta que descubren un “defacement”, un borrado su base de datos, o un “take over” que les prive de un uso normal del producto. Todas estas situaciones se tornan especialmente críticas cuando hacemos de estos productos nuestra ventana de comunicación corporativa con clientes y proveedores, por motivos obvios.

Desde Hispasec transmitimos a los administradores PHP-Nuke la necesidad de ser proactivos en caso de escoger esta solución. Si no se posee conocimiento o tiempo para llevar la administración de seguridad de este CMS con la suficiente atención, quizás sea buena opción plantearse, a costa de una curva de aprendizaje mayor, migrar a soluciones libres equivalentes, con un histórico de seguridad menos deficitario que PHP-Nuke, como por ejemplo, Postnuke o Drupal. Algunas medidas que pueden evitar que futuros problemas como el descrito afecten al parque de usuarios PHP-Nuke son deshabilitar la opción de mostrar mensajes de error, que ofrecen información y pistas a los atacantes; desactivar variables del entorno PHP que pueden repercutir en una menor seguridad, como “register_globals”; hacer uso de los modos seguros “safe”; cambiar los prefijos de las tablas SQL que aporta la instalación por defecto y sobre todo, no aplicar módulos en el CMS que exijan, por funcionalidad, desactivar medidas de seguridad del servidor, como por ejemplo, los editores “What You See Is What You Get” (WYSIWYG), que penalizan la seguridad global del sitio a costa de permitir, en este caso, edición de texto dinámica, vistosa y bonita, pero a todas luces innecesaria e insegura.

Es preciso destacar que infinidad de servicios de hospedaje que ofrecen como valor añadido a sus clientes preinstalaciones PHP-Nuke para que los clientes desplieguen un portal en cuestión de segundos, caso típico de productos en la línea de “Installatron” que permiten a los usuarios activar soluciones dinámicas sin necesidad de recurrir al proceso clásico de descargar y subir por FTP, precisando únicamente configuraciones mínimas y fáciles. En todos los casos, la ventana de tiempo para explotar el problema es muy amplia, y las potenciales víctimas, muy numerosas.

PHP-Nuke es un producto pionero en lo que se viene a denominar Web 2.0. Sin duda alguna, es probablemente el producto que ha popularizado de una manera masiva el concepto de Web dinámica, al menos en los albores de este nuevo movimiento, constituyendo uno de los principales puntos de ruptura con la Web 1.0, estática y desordenada, que ha dado paso a este nuevo concepto de información ordenada, integrada, accesible y dinámica que tan popular se está volviendo estos días, no sólo con los sistemas CMS, sino sobre todo, con los blogs, fotologs, e incluso con aplicaciones empresariales cliente servidor como los CRM, ERP y similares.

A todos los administradores de estas soluciones 2.0 les proponemos que adopten un grado proactivo de seguridad. Empieza a ser a todas luces insuficiente aplicar únicamente remedios paliativos cuando se nos informa de un problema en nuestro producto, con lo que los usuarios deberían, en aras de la mejor seguridad posible, documentarse adecuadamente sobre los productos que emplean, ya sea con los canales del fabricante o bien con los canales de las comunidades de usuario que habitualmente acarrean este tipo de soluciones.

Igualmente recordamos que la dinamización y complejidad de los despliegues y servicios implica, forzosamente, mayores requisitos de seguridad que no deben ser menospreciados. El menoscabo de los peligros en la red es, especialmente en los casos descritos, un camino seguro hacia los problemas.