Hoy quiero compartir con vosotros mi propia experiencia con las vulnerabilidades de uno de los gestores de contenidos de uso más extendido, y uno de los objetivos más apetitosos para los hackers y los cibercriminales en los últimos años. Si, me refiero a WordPress.
WordPress como objetivo de los hackers
Hay varias razones para que sea uno de los CMS (Content Management System) más empleados en todo el planeta. En primer lugar, que es gratuito y de código abierto. Por lo que la gran mayoría de servicios de Hosting lo incluyen en su oferta combinada de dominio, alojamiento , y herramienta para desarrollar webs. Pero además, hay que tener en cuenta que tanto la creación de contenidos, como la administración del sitio es muy sencilla gracias a una interfaz gráfica muy intuitiva. Por este motivo es un CMS accesible a muy diferentes tipos de perfiles de usuario; que van desde un blogger con conocimientos mínimos de creación de páginas web, pasando por los especialistas en medios, y publicidad; hasta desarrolladores web que además pueden programar sus propios complementos o plugins y compartirlos con la comunidad.
Tanto los hackers como los cibercriminales encuentran muy atractivos los sitios creados con WordPress. Y ello es principalmente debido al gran número de instalaciones que hay desplegadas en producción. Cuanto mayor es el número de posibles víctimas, mayor es la probabilidad de que un cibercriminal la elija como objetivo.
El riesgo de usar WordPress se incrementa por el hecho de que al ser software libre, implica que la responsabilidad de su mantenimiento recaiga en su comunidad; que aunque ésta sea muy numerosa y activa, no está respaldada por una firma comercial con los recursos suficientes para las distintas fases de desarrollo del software. Por lo que la expectativa de que se liberen versiones no suficientemente testeadas aumenta.
Hoy en día es una realidad que los hackers y cibercriminales disponen de herramientas muy eficaces que permiten rastrear la red de redes para ayudar a localizar objetivos con características concretas; como pudiera ser sitios con la última versión de WordPress con errores de seguridad. Algunas de estas herramientas son de acceso público como las búsquedas avanzadas de Google y Bing; o el motor de búsqueda Shodan, que encuentra dispositivos específicos conectados a Internet a través del banner sus servicios. Sin embargo también es posible adquirir en la “Deep Web”, previo pago, herramientas más sofisticadas que facilitan el trabajo a los cibercriminales.
Vulnerabilidad CVE-2017-5611
Me he decidido a escribir sobre la última vulnerabilidad de WordPress CVE-2017-5611, porque ha sido explotada en el sitio web de uno de mis clientes. Se trata de una vulnerabilidad crítica de tipo inyección SQL registrada por la organización Mitre el 28 de enero de 2017; y calificada con una puntuación de 9.8 sobre 10.
El fallo de seguridad CVE 2017-5611 permite la ejecución de instrucciones SQL de forma remota. Este error facilita la alteración del contenido de las tablas de la base de datos que da servicio a WordPress, produciendo graves de consecuencias como cambiar o eliminar el contenido de artículos y comentarios, extraer información de los editores y administrador del sitio, o añadir usuarios ilegítimos.
Podemos encontrar páginas hackeadas con esta vulnerabilidad buscando la firma del hacker más activo que ha explotado este fallo de WordPress; el cual firma en las páginas de sus víctimas con la cadena de caracteres “by w4l3XzY3”. Por esta razón se puede buscar con la ayuda de Google páginas web que contengan su firma de la siguiente forma:
La lista de resultados devolvía el día 19 de febrero 74.900 páginas; pero va disminuyendo día a día, y no todas tienen por qué estar actualmente comprometidas. Hoy la lista de resultados es de 77.100 páginas.
Mi primer contacto con CVE 2017-5611
El día 7 de febrero cuando abrí mi correo me quedé muy extrañada al leer un mensaje de mi sitio web, en el que se indicaba que se ha había cambiado la contraseña del administrador WordPress.
“Este aviso confirma que tu contraseña ha cambiado en Atenea TICs. Si no has cambiado la contraseña, contacta con el administrador del sitio”
Mi primer reacción fue pensar que me habían hackeado la página; pero al revisar el resto de correos, pude ver otro de la empresa de hosting donde tengo alojado mi sitio web, que decía:
“Confirmarle que hemos detectado la presencia de código malicioso bajo el dominio. El problema era la versión usada de WordPress 4.7.1 que tenía un bug, hemos actualizado a la 4.7.2 que solventa el problema.”
Inmediatamente recurrí a Virus Total para comprobar que el sitio no estaba infectado, como podéis ver en la siguiente imagen
A continuación abrí un ticket de consulta en el hoster preguntando por la incidencia. Su respuesta fue bastante rápida, y me comunicaron que no había sido encontrado código malicioso, y que simplemente se trataba de la aplicación de la actualización de seguridad. Pero tanta rapidez y eficacia por parte del hoster me hizo sospechar de que se trataba de algo verdaderamente importante para que la empresa se tomara la libertad de actualizar la versión de WordPress sin preguntar a sus clientes. Por ello mi siguiente paso fue buscar en la base de datos de Mitre la última vulnerabilidad de WordPress, y efectivamente encontré que se acababan de encontrar fallos de seguridad en las versiones anteriores a WordPress 4.7.2.
Contenta y satisfecha por la protección que me proporciona hoster, procedí a cambiar rápidamente la contraseña del administrador para prevenir posibles ataques en el caso de que alguien hubiera aprovechado la vulnerabilidad para robar mis datos.
Quizás alguno os preguntéis por qué el hoster cambió mi contraseña de administrador y cómo lo hizo. Pues bien, para ejecutar la actualización de WordPress se puede hacer de varias formas. La más sencilla para el propietario del blog es autenticarse como administrador WordPress y actualizar desde el menú de Actualizaciones como veis en la siguiente imagen.
Pero si quien efectúa la actualización es el soporte técnico del hoster, tiene que obtener primero las credenciales. Lo más rápido, al tener acceso al panel Plesk o Cpanel del alojamiento, es cambiar o resetear la contraseña desde el menú de phpMyAdmin como se indica en este enlace del sitio oficial de WordPress
Otro procedimiento para realizar la actualización sin cambiar la contraseña del administrador WordPress es ejecutar un upgrade. Para ello se siguen los siguientes pasos:
- Backup del sitio (WordPress + Base de Datos)
- Descarga de la versión WordPress a instalar desde el sitio oficial http://wordpress.org/download/.
- Subida de la versión WordPress al hosting
- Ejecución del programa de Upgrade accediendo al script php de vuestra propia página : http://example.com/blog/wp-admin/upgrade.php
- Instalación de plugins y temas empleados
- Verificar el contenido de los siguientes ficheros de configuración: .htaccess y wp-config.php
Podéis obtener más información de cómo hacer el upgrade en este enlace del sitio oficial de WordPress
Dada la gravedad de la vulnerabilidad, informé sobre ella a mis clientes, y les aconsejé la actualización inmediata.
Un caso real de ataque
Unos días más tarde, concretamente el 13 de febrero recibí un mensaje de un cliente notificándome que le habían cambiado 2 noticias de su sitio web; es decir, lo que se conoce en el argot de seguridad informática como un defacement.
Para solucionar el incidente procedí realizando los siguientes pasos
- Actualización de la versión de WordPress para que no pudieran seguir atacando.
- Ejecución de salvaguarda del sitio (WordPress + Base de Datos). Además contaba con otra salvaguarda hecha por mi en enero.
- Comprobé las noticias comprometidas de forma visual, y también en la Base de Datos con la ayuda de phpMyAdmin
- Restauré los contenidos de las noticias y eliminé los registros inválidos añadidos por el ataque desde la herramienta phpMyAdmin
- Verifiqué que las noticias habían quedado correctamente restablecidas mediante la consulta de las páginas del sitio desde un navegador.
- Me aseguré con la herramienta gratuita de Sucuri de que el sitio de mi cliente no estaba infectado.
El trabajo de restaurar los contenidos fue una tarea minuciosa; pues el modificar manualmente los registros de las tablas del CMS siempre supone un riesgo.
La tabla afectada por el ataque es la que usa WordPress para almacenar la información de cada artículo ó post. Esta tabla se denomina wp_posts; y se compone de distintos campos entre los que cabe destacar los siguientes:
- ID: Identificador único secuencial del post.
- post_author: Identificador de usuario del autor del post
- post_date: Hora y fecha de creación del post
- post_content: Contenido del post
- post_title: Título del post
- post_status: Estado del post. En el caso estudiado hay valores inherit (revisión de post) y public (post publicado).
- comment_status: Estado del comentario del post. En el caso estudiado hay valores open y closed.
- post_name: dirección URL del post publicado, o dirección URL de la revisión.
- post_modified: Hora y fecha de actualización del posts
- post_type: Tipo de post. En el caso estudiado se dan los valores post y revision.
Al analizar la primera noticia hackeada observé que aunque el contenido había sido modificado, el título se conservaba. Por lo que hice una búsqueda de registros con el filtro del título que conocía.
Este es el resultado del SELECT ejecutado con phpMyAdmin desde el panel del host
En la imagen podemos observar distintos aspectos:
- Hay 4 registros de la tabla correspondientes al título seleccionado.
- El registro 673 es el artículo original, y se ha alterado el contenido del campo post_content con “Hello World”
- El registro 673 fue creado por el usuario 2 (editor de artículos)
- La fecha de creación del registro 673 es 2016-10-18; y aunque no se ve en la imagen, la fecha de actualización es 2017-02-12 (la fecha de ataque)
- Han sido insertados los registros 771 y 772 en la fecha 2017-02-11 (fecha de ataque)
- Los registros 771 y 772 han sido añadidos por el usuario 0; que no existe en la tabla wp_users.
- Los contenidos de los registros 771 y 772 (<p>Hello world!</p> y [insert_php] print md5(‘tujjfdfjkh’); [/insert_php.) no corresponden con el texto original del artículo .
- El registro 675 es una revisión del post 673 puesto que ha si lo indican los campos GUID y post_type
- El registro 675 no ha sido alterado en el ataque, por lo podemos aprovechar el valor de su campo post_content.
A partir de las conclusiones del anterior análisis procedo a restaurar la noticia ejecutando las siguientes operaciones:
- Actualizo el campo post_content del registro 673 con el texto del registro 675
- Elimino los registros 771 y 772
La siguiente noticia adulterada por el hacker afecta al título y al contenido del artículo.
Para analizar el ataque, primero se realiza un SELECT en la tabla post a partir del contenido de la firma del hacker “by w4l3XzY3”, y se observa la fecha de creación del post. A continuación se buscan todas las entradas de ese día para comprobar que no se hubieran alterado revisiones o registros asociados a ese mismo post.
En la Imagen se advierte la siguiente información:
- El post atacado tiene el ID 669
- El post con ID 669 ha sido modificado en los valores de los campos título y contenido a fecha 2017-02-09.
- El post 671 es una revisión del post 669 (lo indican los campos GUID y post_type); y está intacto pues su fecha de actualización es la misma que la de creación. Por lo que se puede recuperar el contenido a partir de él.
- Los dos registros han sido creados por el usuario con el usuario 2 (editor de artículos)
- No hay otros registros actualizados con esa fecha. Por lo que se supone que la noticia no tiene asociados otros ficheros que pudieran haber sido vulnerados.
La restauración de este post es más sencilla que el anterior; pues sólo hay que actualizar los valores post_content y post_title del registro 669 con los del registro con ID 671
Conclusiones
Es indudable que la actualización de software es una tarea no ya importante, sino imprescindible en cualquier sistema informático; y que las herramientas de software libre como WordPress, gracias al carácter gratuito de muchas de ellas, y a la facilidad de su uso están siendo empleadas por perfiles de usuarios muy distintos.
Me refiero a que una página hecha con WordPress puede estar administrada por un departamento informático, o simplemente por un blogger cuyo objetivo principal es la dviulgación de contenidos. Este tipo de usuario habitualmente no tiene conocimientos suficientes, no ya de la seguridad, sino en muchas ocasiones tampoco de los procedimientos para la actualización de los plugins que va añadiendo. En este sentido, cualquiera se podría hacer estas preguntas:
¿Quien debería ser responsable de cubrir las tareas de mantenimiento general del WordPress?
¿Debería contratar un blogger los servicios de un técnico informático?
¿Debería proporcionar el hoster estos servicios?
En mi opinión hay aún mucho desconocimiento entre los usuarios digamos “finales” de los CMS más asequibles, como WordPress y Joomla, a cerca de las tareas de mantenimiento recomendadas; y sobre todo de las medidas de seguridad que deberían tomar dada la gran cantidad de fallos de seguridad que se descubren, y el elevado número de víctimas que sufren ataques.
Por otro lado, las empresas de hosting, sea cual sea el precio de su servicio deberían, por una parte incluir información sobre avisos de seguridad, y por otra aplicar actualizaciones de software con carácter obligatorio de al menos las releases con resolución de fallos de seguridad.
Dicho esto, aunque sea repetitivo, insisto en tres recomendaciones básicas para mejorar la seguridad de un blog WordPress:
- Elegid para el alojamiento de vuestro blog un proveedor con unas medidas de seguridad mínimas. Lo más barato, en ocasiones sale caro.
- Aplicad las ACTUALIZACIONES del software de WordPress , sus plugins, y sus temas.
- Instalad y configurar un plugin de seguridad que envié notificaciones de seguridad a una cuenta de correo.
Si queréis profundizar en el conocimiento de la seguridad en WordPress os aconsejo la Guía de Seguridad de WordPress del CCN-CERT
Hasta pronto !!