WordPress es seguro ¡difúndelo!

wordpress security

Creo que ya va siendo hora de aclarar esta cuestión, y zanjar del debate de una vez por todas. A pesar de las dudas, y algunos odiadores, el núcleo de WordPress es, sin duda alguna, el más seguro de todas las plataformas que puedas elegir para crear una web.

Me dirás que una instalación de WordPress puede verse comprometida por culpa de plugins, pero esa es otra cuestión, que además ya hemos tratado hace tiempo.

Recientemente hemos visto historias acerca de un bot que trataba de hacer ataques de fuerza bruta en sitios WordPress, pero debes tener claro que no podía entrar en sitios donde el usuario tenía contraseñas fuertes, tenían la última versión de WordPress y estaban comprometidos con la seguridad de todos los componentes de su instalación.

Pero cómo hay mucho escéptico, lo que no es malo de suyo, vamos a ver si terminamos de aclarar algunas cosas.

Críticas “amistosas”

Durante el verano de 2009 WordPress recibió algunos “toques” de la comunidad de publicación online, debido a cuestiones de seguridad explotadas esos días. Lo que pasaba es que WordPress estaba creciendo enormemente, y recibió algunas críticas, bien y mal intencionadas, que hubo de todo, cuestionando si WordPress era lo suficientemente seguro para los usuarios a los que atraía de manera importante.

Por decirlo de algún modo, lo que se decía era algo así:

“Eh, WordPress, sabemos que eres ambicioso, y eso nos encanta, pero debes asegurar que tu seguridad es a prueba de balas para los usuarios antes de ser tan popular”

Curioso ¿no?, sobre todo cuando en parte venía de usuarios de comunidades de software de publicación con problemas de seguridad sin solucionar hacía años, pero bueno, vamos al tema.

Los desarrolladores del núcleo de WordPress respondieron, y en los siguientes meses se añadieron parches y ajustes de seguridad para afianzar fuera de toda duda que WordPress es uno de los CMS más seguros de Internet. Eso fue hace cuatro años, una eternidad en términos de innovación tecnológica.

El verano de 2009

seguridad

En unas pocas semanas, en 2009, el equipo del núcleo de WordPress lanzó una serie de 4 parches de seguridad. El equipo cerró de manera rápida y sistemática cualquier factor remanente de inseguridad en el núcleo de WordPress. A finales de ese verano el código base de WordPress empezaba a parecer Fort Knox.

Sin embargo, si tenías alguna instalación en marcha de WordPress en esa época, tuviste que actualizar WordPress bastante a menudo, cada vez que se lanzaba un nuevo parche de seguridad. En total se emitieron seis versiones de WordPress, desde la 2.8.1 el 19 de Julio hasta la 2.8.6 antes de Navidad. Ciertamente fueron un buen montón de actualizaciones. ¿Te acuerdas?

Vale que actualizar WordPress no es difícil, pero actualizaciones cada pocas semanas se hacía pesado. Cada nueva actualización de seguridad implica comprobar compatibilidad de plugins y temas antes de lanzarse, y eso duele a veces. Y lo mismo en cada nueva actualización. Ahora bien, cualquier software solo es seguro en su última versión, así que hay que actualizar siempre a la última versión publicada, que no se te olvide.

Pero vaya, que tener que revisar todo, cada 2 o 3 semanas, en cada sitio que tengas, se hace cansino, y esto no nos tenía contentos, cómo se reconocía en muchos comentarios del blog, y con razón.

En solo 34 días hubo nada menos que 4 actualizaciones de seguridad para WordPress 2.8, y te recuerdo que esto era antes de que tuviésemos herramientas de gestión que nos facilitaran las instalaciones, así que todas las actualizaciones eran manuales.

Vamos, que era un puto infierno y un coñazo.

Y lo peor es que muchos usuarios no actualizaban … y algunos de los sitios de esos usuarios fueron hackeados al funcionar con versiones de WordPress anticuadas (y hablamos solo de unas semanas), lo que nos trae de nuevo la necesidad de tener WordPress actualizado. Así que grábatelo a fuego:

Si estás actualizado estás seguro

Si no estás actualizado eres un objetivo.

El hacking es noticia

wordpress seguro
En 2009 hubo muchas instalaciones de WordPress, cada vez más, y con toda esta retahíla de actualizaciones fuimos noticia. Hubo una buena cantidad de blogueros e incluso diarios digitales generalistas que ese año hablaron, y mucho, acerca de “los problemas de seguridad de WordPress“, y esto ha quedado en la memoria colectiva de Internet, a pesar de que 4 años en la red es una eternidad en términos de software, pero no es así con la mente humana.

Ahora, cuatro años después, aún no es posible tener un debate sobre WordPress sin que alguien te suelte eso de “Eh, espera ¿es WordPress inseguro?“.

De repente, WordPress tenía una reputación, merecida o no, de ser una plataforma que tenía que estar actualizándose constantemente, y que podría no ser lo suficientemente segura.

La realidad es que ya a finales de 2009 WordPress se había convertido en una plataforma segura y sin problemas para los millones de usuarios que la usábamos, lo mismo para sitios de alto tráfico cómo The New York Times.

La popularidad de WordPress se hacía patente en la ingente cantidad de grandes empresas y organizaciones que migraban a WordPress.

Responsabilidad compartida de los usuarios de WordPress

Los usuarios de WordPress debemos ser responsables de nuestra propia seguridad, de usar contraseñas fuertes y de mantener los plugins y el mismo WordPress actualizado.

Esta responsabilidad debemos asumirla cómo responsabilidad compartida, pues en la mayoría de las ocasiones compartimos alojamiento web con otros usuarios y sitios, que pueden también verse afectados por nuestras malas prácticas.

Suficientemente seguro para ser el más popular

El término “popular” quizás no sea el más acertado, pero a fin de cuentas es verdad y hay que asumirlo. Y es que con 64 millones de instalaciones de WordPress (el 17% de todas las webs están creadas con WordPress), y subiendo, los datos confirman que el partido está ganado. No hay ninguna otra plataforma (Ruby on Rails, Python, etc) que se acerque siquiera a tal nivel de aceptación.

El núcleo de WordPress es lo suficientemente seguro para ese uso masivo, lo que hace todavía más sorprendente que aún haya desarrolladores que sigan con la idea, anticuada y falsa, de una supuesta inseguridad de WordPress.

Es más, con el nivel de implantación actual de WordPress, incluso un 0,0001% de inseguridad sería un problema, pero WordPress sigue creciendo sin problemas y dando servicio a millones de usuarios, administradores y desarrolladores satisfechos.

Las evidencias son claras, así que hay que reabrir el debate de manera activa, blogueando sobre ello, explicando al mundo la realidad de que el núcleo de WordPress es seguro, y que todos los sepan, para cambiar esa falsa memoria colectiva, que sigue coleando desde hace nada menos que 4 años.

WordPress sigue creciendo, mejorando, y convenciendo a cada vez más usuarios, y es una plataforma segura, ágil, potente y sencilla de utilizar y mejorar, y además es software libre.

Así que WordPress merece que también Internet reconozca esa reputación de ser un CMS seguro, ¡difúndelo!, estoy deseando ver enlaces en los comentarios a las entradas de vuestros blogs explicando al mundo que WordPress es seguro.

Tomado está el testigo lanzado por Jason Cosper.

BuddyPress 1.7.2, actualización urgente de seguridad

Acaba de salir a la luz la versión 1.7.2 de BuddyPress, una actualización que soluciona un grave problema de seguridad detectado tras la actualización de la versión 1.7.1 por el que podría ser vulnerable de inyecciones SQL, así que actualiza ya mismo sin dudarlo.

Alerta de seguridad en WordPress: satan.php

ataque wordpress

Llevo un buen rato recibiendo avisos de que se están produciendo inyecciones de archivos, en concreto de uno denominado “satan.php” en la carpeta “upgrade” de WordPress, así que revisa urgentemente tu instalación para eliminarlo lo antes posible.

La carpeta upgrade, situada dentro de wp-content (o sea, en tusitio.es/wp-content/upgrade/) es la que usa WordPress para los archivos temporales en actualizaciones e instalaciones de plugins y temas.

Pues bien, sin interacción por parte del administrador están apareciendo dentro de esta carpeta archivos como si fueran de una instalación fallida de un tema, en concreto de uno llamado BoxTheme, y dentro de esa carpeta un archivo único denominado satan.php con código malicioso que puede comprometer toda tu instalación de WordPress.

Así que revisa mediante FTP la carpeta upgrade y si encuentras algo así lo borras directamente (esta carpeta debería estar siempre vacía salvo mientras actualizas o instalas algo). A continuación instala algún plugin que te avise de modificaciones en tu instalación, cómo Wordfence o WordPress File Monitor, y protege la carpeta contra escritura cambiando los permisos de la misma a 444 (temporalmente).

Cambiar permisos a 444

Cambiar permisos a 444

Sobre todo, modifica las contraseñas de acceso FTP cuando antes. El fichero es un mal bicho, con 1.420 líneas, algunas ofuscadas, de código que no hace nada bueno, pues prácticamente da acceso a todo tu servidor. No es una amenaza nueva, pero si que hace meses que no se veía, y ahora parece haber renacido. Un posible culpable sería un timthumb sin actualizar.

satan.php

Si detectas algo más nos lo cuentas para actualizar la información y, por favor, difunde este aviso, que al menos estemos avisados.

Actualizaciones:

  • Algunos proveedores de alojamiento, cómo CDmon, reconocen el archivo como virus, y lo borra automáticamente (bien hecho).
    borrado satan.php por cdmon

Que WordPress no se acuerde de ti, o casi

Cómo hace tiempo que ya vimos cómo hacer para que WordPress se acuerde de ti lo más permanentemente posible, hoy toca justo lo contrario: evitar que WordPress mantenga la cookie de acceso las 2 semanas que dura por defecto.

Porque estar permanentemente conectado puede ser buena idea en el ordenador de tu casa, pero en absoluto es recomendable la conexión activa en tu ordenador portátil o tableta, no digamos en ordenadores compartidos.

Para estas situaciones, y sobre todo para evitar manías habituales, hay un plugin que elimina (no lo oculta) la casilla de “Recuérdame” de la pantalla de acceso, evitando la tentación de marcarla y que WordPress no corte tu conexión durante 14 días y lo haga en cada sesión del ordenador.

No hay nada que configurar, lo instalas, lo activas y listo, en la pantalla de acceso ya no estará la casilla para mantener la conexión 14 días, y la cookie de acceso caducará en cada sesión de tu ordenador o tableta, evitando accesos de extraños.

Antes Después

Grave amenaza de seguridad en los principales plugins de cache en WordPress

inyeccion de codigo wordpress

Ayer ha avisado Sucuri, web especializada en seguridad informática de una grave amenaza de seguridad que afecta a los dos plugins de cache más populares en WordPress: W3 Total Cache y WP Super Cache.

En el informe publicado en el blog de Sucuri, se da detalle del aviso que se hizo en los foros de WordPress.org al respecto de una vulnerabilidad que afectaría a estos plugins.

El problema es gordo, pues permitiría la ejecución de código remoto incluso de manera arbitraria.

La manera de comprobar si te has visto afectado es publicar en un comentario el siguiente código:

<!–mfunc echo PHP_VERSION; –><!–/mfunc–>

Y si tras publicarlo ves la versión de PHP de tu servidor mala noticia, podrías estar afectado. Porque lo que significa es que cualquiera puede ejecutar comandos de código en tu WordPress y se ejecutan gracias a que está habilitado mfunc por obra y gracia de estos plugins, en este caso una nadería pues solo muestras la versión de PHP mediante un echo, ya que es solo una comprobación.

Por cierto, si usas servicios externos cómo Disqus o similares no funcionará.

El problema viene porque los códigos insertados no solo pueden ser mediante mclude sino también mediante código PHP (mfunc), y siempre que abrimos la posibilidad de incluir código PHP directamente se abre la posibilidad de meter código ejecutable, y supone un riesgo.

Los plugins de cache, y en concreto WP Super Cache y W3 Total Cache, guardan las páginas completas en cache, comentarios incluídos, y si contienen trozos de código podrían ejecutarse desde esas versiones cacheadas por parte de alguien con malas intenciones, y cómo WordPress permite usar etiquetas HTML pues está casi todo preparado para que alguien aproveche esa puerta abierta.

Resumiendo … 

Si usas una versión de WP Super Cache anterior a la 1.3 o de W3 Total Cache anterior a la 0.9.2.9 corres el riesgo de una inyección de código PHP. Los comentarios de tu WordPress podrían incluir códigos dinámicos, mediante HTML, y el núcleo de WordPress no los filtraría para controlarlos.

Los plugins de cache, al guardar una versión de esas páginas, incluirían también el código PHP inyectado, y hasta que no se volviera a cachear la página o páginas afectadas, alguien podría ejecutar ese código, o se ejecutaría solo, depende de lo que te hayan metido.

La solución pasa por actualizar los plugins a las últimas versiones que los desarrolladores de ambos han lanzado ya ante la vulnerabilidad, y en las que desactivan mfunc por defecto, que es donde radicaba el problema.

Consejos para ataques de fuerza bruta a WordPress en el Codex

wordpress en la diana

Un día después del ataque mundial de fuerza bruta contra sitios creados con WordPress (y también Joomla), en el Codex de WordPress.org se ha tomado nota y se ha creado una página en la que se dan consejos para evitar este tipo de ataques.

Personalmente hubiese esperado algo más … no sé … ampliado, ya que los consejos que se dan son básicos, quizá demasiado, y ahí el que no me termine de convencer. Pero bueno, los consejos son buenos, y siempre los puedes ampliar con los que di yo el otro día, cuando se produjo el ataque y corrí a avisar.

Básicamente, por si no te manejas bien con el inglés, los consejos que se dan son estos:

Y te dejo unos trucos extra:

Para finalizar, comprueba si tu combinación usuario/clave está en la lista de abajo y cámbiala ya mismo, ya estás tardando:

Ataque masivo de fuerza bruta para acceder a sitios WordPress

ip trace

Hoy se está registrando un intento desproporcionado de intentos de acceso a sitios creados con WordPress que está provocando no pocos problemas a administradores de webs y sistemas.

El proceso está tratando de forzar accesos cómo administrador a través de la pantalla de login (wp-login.php) mediante scripts de ataque de fuerza bruta, con la intención de inyectar código script malicioso en el tema activo.

Si tienes activo el módulo de WordFence de bloqueo de IPs ante intentos masivos de acceso ya sabes de lo que estoy hablando porque habrás tenido, cómo yo, un día entretenido de avisos de IPs bloqueadas por este motivo, la mayoría desde Rusia o países de la antigua URSS.

Para evitar este tipo de ataques tenemos dos herramientas eficaces e inmediatas:

  1. Avisa a tu proveedor de alojamiento del problema y pide que te activen el módulo mod_security de Apache.
    Para saber más sobre mod_security te recomiendo descargar la guía que hizo Samuel Aguilera, que indica las protecciones que ofrece y cómo saltárselas puntualmente, pero siempre sabiendo lo que haces. Encuentras el enlace al PDF al final del artículo enlazado.
  2. Instala y activa el plugin Wordfence y comprueba que están activas las reglas de Firewall (por defecto no están activas), que podrían ser cómo en esta captura:
    firewall rules wordfence

    Nota: El valor de “If a human’s page views exceed” debes modificarlo de acuerdo al tráfico “normal” de tu sitio o bloquearás usuarios normales.

    También comprueba que tienes bien configuradas las reglas de control de accesos, cómo en esta otra captura por lo menos:
    wordfence login options

    Para asegurarte totalmente, si estás sufriendo un ataque inminente puedes cambiar el nivel de seguridad del plugin poniéndolo en el nivel 4, el de máxima seguridad:

    nivel 4 wordfence

Para todo lo demás, te recuerdo los consejos básicos para asegurar WordPress.

Gracias a Borja por avisar.

BuddyPress 1.6.5, actualización de seguridad

Acaba de salir a la luz la versión 1.6.5 de BuddyPress, el plugin que convierte WordPress en una red social. En concreto, esta actualización soluciona un grave fallo mediante el que usuarios sin permisos podrían acceder a los ajustes para borrar cuentas, así que es una actualización imprescindible.

Verificación de 2 pasos en WordPress

verificacion 2 pasos wordpress

La seguridad de una web es fundamental, y uno de los sitios más atacados en una instalación de WordPress es la pantalla de acceso, y sino instala Wordfence y podrás comprobar tu mismo la cantidad de intentos de ataques de fuerza bruta que se reciben a diario si tu sitio tiene cierta popularidad.

Es por este motivo que merece la pena valorar incorporar una de las últimas tecnologías de seguridad: la verificación en 2 pasos.

Este método, ya utilizado por servicios tan populares como Google y Dropbox, además de – seguramente – tu banca online, requiere que introduzcas para acceder, además de tu usuario y contraseña, un código adicional que se te facilitará por teléfono móvil u otros métodos.

Si estás comprometido con la seguridad de tu sitio hay varias maneras de disponer de verificación de 2 pasos en WordPress, vamos a ver algunos … 

  1. 2 step auth – Este plugin añade la verificación de 2 pasos a WordPress, pudiendo decidir la segunda verificación entre uno de estos 3 métodos:
    • mensaje SMS, para lo que tendrás que tener activo el sistema TextMagic o SMS Global Account
    • lista de códigos de seguridad
    • envío de código por email

    Sea cual sea el método elegido la verificación en 2 pasos se activará para los usuarios con privilegios de administrador, incluso en WordPress multisitio, mientras que los usuarios con menos permisos seguirán usando la pantalla de acceso habitual.

    Para poner en marcha el plugin sigue los 3 pasos de su página de ajustes y lo tendrás en marcha.
    ajustes 2 pasos wordpress codigo 2 pasos movil wordpress codigo 2 pasos clave wordpress codigo 2 pasos email wordpress

    Es una solución completa, integrada y que no requiere de servicios externos (salvo que uses la verificación por SMS), así que ofrece todo lo que necesitas.

  2. Google Authenticator – El sistema de verificación en 2 pasos de Google también puedes activarlo en WordPress. En este caso deberás instalar la aplicación para tu móvil, disponible para los principales sistemas operativos móviles cómo Android o iOS y algún plugin que conecte tu WordPress con el servicio. El proceso sería más o menos así, independientemente del plugin utilizado:
    • Instala el plugin para conectar con Google Authenticator. Te recomiendo WP 2 step verification o Google Authenticator plugin
    • Accede a la página de ajustes del plugin y elige un nombre a mostrar en Google Authenticator.
    • Genera una clave secreta y un código QR, este último léelo con tu aplicación móvil.
      ajustes 2 pasos wordpress
    • En la aplicación del móvil se generará un código, introdúcelo en la página de ajustes.
      codigo generado google authenticator wordpress
    • A partir de ahí, cada vez que quieras acceder a WordPress tendrás que generar un nuevo código en la aplicación Google Authenticator de tu móvil e introducirla en la pantalla de acceso modificada.
      pantalla acceso con google authenticator wordpress

    Cómo has comprobado el proceso de configuración inicial es algo más tedioso, pero una vez hecho el acceso es inmediato, generando un código rápidamente en tu móvil cuando quieras acceder.

Nada más, simplemente recomendarte que lo pruebes, pues mejora muchos enteros la seguridad de WordPress.

Evita hackeos en WordPress desde .htaccess

seguridad wordpress

El fichero .htaccess es la primera barrera que puedes usar en un sistema basado en servidores Linux con Apache, pues dispone de una buena cantidad de reglas que podemos aplicar y, gracias a ello, y como es el caso de hoy, proteger WordPress de hackers.

El siguiente código, añadido al archivo .htaccess de tu instalación (fichero oculto situado en la carpeta raíz) evitará un buen montón de sistemas habituales de inyectar código y hackear WordPress.

Simplemente añade estas líneas:

RewriteEngine On
 
# sin acceso a proc/self/environ
RewriteCond %{QUERY_STRING} proc/self/environ [OR]
 
# bloquear cualquier script que trate de establecer un valor mosConfig a través de una URL
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|\%3D) [OR]
 
# bloquear cualquier script que trate de colocarte código codificado base64_encode a través de una URL
RewriteCond %{QUERY_STRING} base64_encode.*(.*) [OR]
 
# bloquea cualquier script que incluya la tag <script> en la URL
RewriteCond %{QUERY_STRING} (<|%3C).*script.*(>|%3E) [NC,OR]
 
# bloquea cualquier script que trate de establecer la variable PHP GLOBALS a través de una URL
RewriteCond %{QUERY_STRING} GLOBALS(=|[|\%[0-9A-Z]{0,2}) [OR]
 
# bloquea cualquier script que trate de modificar una variable _REQUEST a través de una URL
RewriteCond %{QUERY_STRING} _REQUEST(=|[|\%[0-9A-Z]{0,2})
 
# manda a todas las peticiones bloqueadas a la página principal con un error de 403 Prohibido
RewriteRule ^(.*)$ index.php [F,L]

Guarda los cambios y vivirás más tranquilo pues te habrás quitado un buen montón de amenazas.