Los continuos problemas de seguridad de las soluciones «nuke» merecen
una reflexión acerca de la trayectoria de estos productos. 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.
shernando@hispasec.com
Más información:
PHP-Nuke
http://www.phpnuke.org
Critical SQL Injection PHPNuke <= 7.8 – Your_Account module
http://securityreason.com/securityalert/440
Deja un comentario