Jonathan Claudius, miembro del equipo de seguridad SpiderLabs perteneciente a la compañía Trustwave, ha publicado una nota de seguridad (o advisory) en la que presenta graves vulnerabilidades que afectan al gestor de contenidos Wordpress, para versiones 3.3.1 y anteriores.
Entre las vulnerabilidades tenemos Cross-Site Scriptings persistentes, Cross-Site Scriptings no persistentes ejecución de código PHP, fuga de información sensible de la configuración de la base de datos MySQL, ya que se permiten hacer consultas para averiguar el usuario y la contraseña sin tener límite de intentos. Todo esto es posible gracias al fichero de configuración de la instalación setup-config.php, que permite la instalación de Wordpress en bases de datos MySQL tanto locales como remotas. Si bien este script no puede ejecutarse si no se posee un usuario y contraseña válidos para el servidor MySQL...¿qué pasaría si configuráramos el Wordpress para que utilizase una base de datos propia, en vez de la original del servidor? Pues que a partir de ahí, "estamos vendidos".
Todo esto se ve claramente en el proceso descrito en el advisory, en el cual se presentan pruebas de concepto para las peticiones necesarias, y como aprovecharse de las vulnerabilidades encontradas para engañar a la instalación para que use nuestra base de datos, en vez de la original. Una vez el gestor de contenidos tiene configurada la base de datos para que conecte con una que hayamos alojado en un sitio accesible, podríamos inyectar código PHP mediante el editor de Temas incluído en Wordpress, o incluir código Javascript en el contenido o páginas del sitio, consiguiendo un Cross-Site Scripting persistente.
En la prueba de concepto, se detallan los siguientes pasos necesarios para el compromiso de un sistema Wordpress:
1) Configurar una base de datos MySQL en una dirección IP a la que tengamos acceso, y se tenga acceso desde el exterior. A esta base de datos es a la que apuntaremos para que se utilice como principal.
2) Peticiones contra el script vulnerable, "setup-config.php", modificando parámetros y valores de las peticiones POST (hacia setup-config.php) y GET (se llama a install.php para que realice la instalación) necesarias que configuren el Wordpress para conectar con nuestra base de datos.
3) Una vez se ha instalado el sistema Wordpress, se pueden realizar los dos tipos de ataques:
3.a) Ejecución de código PHP: Tras completar la instalación, se accede al editor de temas del sitio, y se modifica cualquiera de las plantillas para incluir código PHP, que se ejecutará al acceder a cualquier página construída con dichas plantillas (por ejemplo, y como se muestra en la prueba de concepto, la correspondiente con el aviso de página no encontrada, el 404.php)
3.b) Cross-Site Scripting persistente: Petición en la base de datos (que recordemos, tenemos el control por ser directamente nuestra) para actualizar contenido del blog e incluir una cadena de texto JavaScript.
Tenéis más información sobre estas acciones, además de los Cross-Site Scriptings no persistentes y la posible fuga de información de usuario y contraseña de MySQL realizando fuerza bruta, en la nota de seguridad TWSL2012-002 de Trustware
Y para acabar, vamos con la respuesta por parte del equipo de Wordpress, cuando se les notificó estos problemas: "Damos prioridad a tener una mejor experiencia del usuario en el proceso de instalación. No es muy corriente que un usuario se encuentra con el problema de instalar una copia de Wordpress y no finalizar el proceso de configuración de la instalación de forma inmediata. Las posibilidades de explotar dicha vulnerabilidad son muy pequeñas."
Todos más tranquilos, ¿verdad? Menos mal que seguro que no nos encontramos en ningún sitio un Wordpress cuyos archivos han sido subidos, y todavía no han comenzado la instalación.
[+] TWSL2012-002: Multiple Vulnerabilities in WordPress [blog de SpiderLabs]
5 comments :
Eso siempre ha sido así y no sólo en Wordpress sino en muchos CMS, lo suyo es hacer la instalación en cuanto subes los archivos.
Mejor experiencia de usuario => menos seguridad ( a veces se prefiere la mejor experiencia que implicara que más gente use ese software, triste pero cierto )
Estas "vulnerabilidades" son una farsa, es obvio que si mantienes un blog no instalado donde puedas usar una base de datos externa, cualquiera que descubra que no has instalado el CMS podrá finalizar la instalación. Este no es un fallo de Wordpress, es una estupidez considerarlo así, cualquier sistema que permita el uso de servidores externos de bases de datos tendrá el mismo problema.
Lo del código javascript que se ejecuta al introducirlo directamente en los campos del formulario de la base de datos también es falso, lo he probado y en ningún momento ejecuta el script.
Por otro lado, es bastante obvio que si te has robado la instalación de wordpress tendrás en tu poder el sistema y por ello registrar cuanta porquería quieras en las tablas. Que el usuario regrese a su propio sitio y se de cuenta que ya ha sido instalado y corran scripts maliciosos en él solo es consecuencia del descuido del usuario, en ningún caso es culpa del sistema, este hace lo que se supone debe hacer.
No veo inyecciones de código, modificaciones de cabeceras ni que estas "pruebas de concepto" sean aplicables en una instalación real, donde el usuario esté haciendo todo correctamente y que por fallas del sistema alguien pueda realizar un ataque desde otro servidor para influir directamente en el resultado.
Esto simplemente es querer alarmar por nada y tratar de dar mala fama a un sistema que es bastante decente en cuanto a seguridad. La gente que critica sin saber, primero debería intentar probar el ataque, revisar el código y ver si las cosas son como dicen ser. El que este Jonathan Claudius trabaje para una empresa de seguridad no lo convierte en experto, simplemente que bajo las circunstancias predefinidas por él y con los defectos que su instalación pueda tener (¿magic_quotes desactivado?) es obvio que cualquier sistema se convierte en un mar de errores.
Lo del ataque de fuerza bruta a la base de datos usando la instalación como proxy no es tampoco una novedad, puedes hacerlo de igual forma creando un fichero con una función de conexión a una base de datos, lo alojas en un servidor gratuito y lo usas como proxy, esto no es problema del sistema, es problema del servidor de base de datos y de cuántos intentos de conexión esté dispuesto a aceptar.
Vamos, que todo esto es un flame de los grandes, el título de este post da mucho que pensar de un sitio como este donde se supone son "expertos" en seguridad.
No soy experto en seguridad informática y, por lo tanto, me preocupo y me informo de aquellas cosas publicadas que puedan afectarme.
Yo uso Wordpress en muchos sitios y tengo que darte las gracias por ser tan minucioso en la contestación que das. Gracias porque ayudas a comprender a muchos usuarios y gestores de este CMS que la vulnerabilidad no está Wordpress propiamente dicho, sino en el fallo de realizar una instalación completamente desvariada de lo normal.
Un saludo.
Gracias por tus comentarios SecBS, de todas formas, vuelvo a hacer mención al último párrafo, y sigo viendo viable encontrar en algunos sitios, subidas de ficheros de un CMS sin ni siquiera haberlo utilizado ni instalado, y que te dan la bienvenida para comenzar con la instalación. Wordpress, Drupals sobre todo....
Luego además, yo personalmente, sin ser "experto" por supuesto, me decanto más por la opción de forzar los datos de configuración de la base de datos en un fichero config del servidor, que permitir que un magnífico PHP me deje meterlo en cajitas.
Cuando me venden una casa, prefiero que la promotora o el propiestario me de las llaves personalmente, y no que deje todas las llaves de cada piso puestas en sus puertas, por comodidad, hasta que yo llegue y entre por primera vez.
Es una opinión, que por supuesto puede estar equivocada. La intención con este post es hacer mención a un advisory que ha sacado una compañía de seguridad, y que quién sabe si alguna vez, puede dar la casualidad de que nos venga bien para aprovecharnos de un sistema con un administrador un poco perezoso, que deja el tar.gz descomprimido a las 4AM y "ya mañana a mediodia me pongo a tunear mi wordpress para escribir de mis gatos más tranquilamente que tengo que entrar a trabajar en 5 horas".
A mi me afectó esta vulnerabilidad ayer, aunque las posibilidades son mínimas existen y son un peligro latente
Publicar un comentario