Te voy a hablar del ataque más eficaz que hay contra tu WordPress, y lo más probable es que ahora mismo no tengas ni una sola defensa puesta contra él.
No necesita tu contraseña, no necesita saltarse tu doble verificación, ni siquiera necesita tocar tu servidor, le basta con copiar la cookie que demuestra que has iniciado sesión y pegarla en otro navegador, y ya está dentro, como tú, con tus permisos.
Hace un par de años te conté que, según un estudio sobre más de 4,3 millones de webs hackeadas, el robo de cookies de sesión era el principal vector de infección de WordPress, por delante de los plugins y temas vulnerables.
Aquel artículo iba del dato y de la sorpresa, en este nos metemos en las tripas de ese secuestro, para saber cómo funciona la sesión de WordPress por dentro, por qué tu 2FA no te salva y qué puedes hacer hoy mismo para reforzar tu web todo lo posible.
Qué es el secuestro de sesión, y por qué el 2FA no te salva
Cuando entras en tu WordPress el sistema comprueba quién eres con tu usuario, tu contraseña y, si la tienes activa, la verificación en dos pasos. Una vez superado ese control te deja una cookie en el navegador que viene a decir «este es fulanito y ya ha pasado por caja».
A partir de ahí, en cada página que visitas, WordPress mira esa cookie en lugar de pedirte la contraseña otra vez, muy cómodo para ti, pero igual de cómodo para quien te robe la cookie.
Piénsalo como la pulsera de un festival, de heavy por ejemplo, que es lo que a mi me pone…
El de seguridad de la entrada te mira el DNI y la entrada, y si todo cuadra te pone la pulsera en la muñeca, una vez has entrado ya no te vuelve a pedir nada nadie, solo miran que lleves la pulsera. Si alguien te quita la pulsera y se la pone, entra en la zona VIP sin pasar por el control de la puerta, y el de seguridad ni se entera. Tu doble verificación es el de la puerta, la cookie es la pulsera.
Por eso, cuando te roban una cookie de sesión válida da exactamente igual que tengas doble verificación o incluso las modernísimas passkeys, toda esa protección vive en el momento del acceso, y la cookie robada ya está al otro lado de esa puerta.
El atacante no inicia sesión, no le hace falta, simplemente reutiliza tu pulsera cookie. A esto se le llama «pasar la cookie» (en inglés, pass the cookie), y es de lo más cabrón que hay, porque no deja casi rastro.
Y ojo, que esto no es un ataque de fuerza bruta, la fuerza bruta prueba contraseñas a saco contra tu login, y eso ya te lo explique´ aquí, el pase de cookie ni siquiera roza tu pantalla de acceso, es más sutil, e incluso más eficiente y rentable para el hacker.
Cómo funciona la sesión de WordPress por dentro
Aquí va un poco de fontanería, la justa para que entiendas por qué unas defensas sirven y otras no. WordPress no utilizla sesiones de PHP clásicas sino cookies firmadas. La prueba de que tú eres tú viaja en la propia cookie, no en un fichero de sesión guardado en el servidor.
Cuando inicias sesión WordPress te coloca un par de cookies:
- Una te identifica como usuario conectado en toda la web, la que empieza por
wordpress_logged_in_ - Otra más restringida que solo viaja al escritorio y solo por HTTPS, la
wordpress_sec_
Si abres la consola de tu navegador ahora mismo en tu WordPress no las vas a ver, y enseguida te explico por qué.
¿Qué llevan dentro esas cookies?
Tres cosas:
- Tu nombre de usuario en texto plano
- Una fecha de caducidad
- Un identificador de sesión (un token) y una firma.
La firma se calcula con las claves salt de tu wp-config.php y con un trocito del hash de tu contraseña, y de ahí salen dos cosas que te valen luego.
Por un lado, sin esas claves salt nadie puede crearte una cookie válida de la nada., y por otro, como la firma depende de tu contraseña, en cuanto la cambias, las cookies viejas dejan de servir.
Desde WordPress 4.0, además, cada sesión tiene su propio token guardado en la base de datos. Eso es lo que te permite cerrar la sesión de un dispositivo concreto sin echar a los demás, y lo que hay detrás del botón «Cerrar sesión en el resto de sitios» de tu perfil de usuario (apúntate ese botón, que lo vamos a usar).
Por último, la caducidad, y es que por defecto una sesión de WordPress dura 2 días, o 14 días si marcas la casilla «Recuérdame» al entrar.
Cuanto más dura la sesión, más tiempo le sirve la cookie a quien te la robe, y catorce días es un mundo para un atacante.
Para colmo, con una cookie aún válida el hacker puede ir refrescándola para alargarle la vida otros tantos días.
El mito del XSS que te roba la cookie
Llegamos al detalle que te decía, y sobre el que incluso yo tenía malentendidos. Me refiero a eso que leemos tantas veces de que «un ataque XSS roba tu cookie de sesión y se la manda al atacante».
Como afirmación general sobre cookies vale, pero con las cookies de autenticación de WordPress no es exactamente lo que parece decir, no es literal.
Esas cookies llevan el atributo HttpOnly desde WordPress 2.7, y HttpOnly significa una cosa muy concreta, que el JavaScript del navegador no puede leer esas cookies.
Compruébalo tú mismo, que es de las pocas cosas de seguridad que puedes verificar en diez segundos. Entra en tu WordPress, abre la consola del navegador, escribe document.cookie y dale a INTRO.
No vas a ver ni rastro de las cookies de sesión, y si un script no las puede leer, no las puede robar por esa vía.
¿Quiere eso decir que un XSS es inofensivo en WordPress? Ni de coña. Lo que pasa es que el daño de un XSS no viene de leer tu cookie, viene de actuar montado sobre tu sesión ya abierta.
Si un script malintencionado se ejecuta en el navegador de un administrador puede crear un usuario administrador nuevo, instalar un plugin o colar una puerta trasera haciendo peticiones en tu nombre, sin necesidad de ver la cookie para nada. Es igual de grave, solo que el mecanismo es otro.
Si quieres entender el XSS a fondo y cómo frenarlo, tienes la guía completa aquí.
Así que el XSS no es por donde te roban la cookie en WordPress. ¿Por dónde entonces? pues por donde menos miras.
Entonces, ¿cómo leches te roban la cookie?
El sitio del robo casi nunca es tu web, sino el equipo desde el que administras tu WordPress. Estas son las vías reales, de la más común a la más tonta.
Malware ladrón de información en tu ordenador
Los llamados infostealer (programas cuyo único trabajo es robar información) leen directamente la base de datos de cookies de tu navegador y se llevan de golpe todas las sesiones que tengas abiertas, la de tu WordPress, la del banco y la del correo.
Familias como Lumma, RedLine o Vidar hacen justo esto, y aquí el HttpOnly no te protege de nada, porque no hay JavaScript, hay un programa leyendo ficheros en tu disco.
En los últimos meses esto se ha disparado, y se manejan cifras de miles de millones de cookies robadas de esta manera.
Proxies de phishing que se ponen en medio
Te llega un enlace, entras en una página que es un calco de tu login, metes tus datos y tu doble factor tan tranquilo, y resulta que esa página hacía de intermediario entre tú y tu web de verdad.
Tú entras, sí, pero por el camino el atacante se queda con la cookie ya válida. Hay herramientas que automatizan esto, y por eso el 2FA no las para.
Conexión sin HTTPS
Si tu web, o aunque solo sea tu login, no fuerza HTTPS, la cookie viaja en texto plano y cualquiera en la misma red wifi la puede pescar.
Esto era el pan nuestro de cada día hace años, hoy mucho menos, pero todavía hay webs por ahí sin HTTPS forzado.
Acceso físico al equipo
El más tonto y, a la vez, de los más frecuentes en oficinas, el ordenador sin bloquear mientras te vas a por un café.
Treinta segundos dan de sobra para copiar una cookie.
Cómo saber si te han secuestrado la sesión
Mala noticia, es difícil, porque para WordPress esa cookie es legítima, la firmó él mismo. No vas a tener un cartel rojo avisándote, pero hay señales a las que prestar atención:
- Sesiones o dispositivos activos que no reconoces, si tu herramienta de seguridad te los muestra.
- En el registro de actividad, accesos a horas raras, desde IPs o países que no son los tuyos, o acciones que tú no has hecho, como un plugin recién instalado o un usuario nuevo.
- Cambios que aparecen en la web sin que nadie los haya hecho por las vías normales.
Por eso un registro de actividad es lo que te da la foto de lo que pasa en tu web. Sin él vas a ciegas.
Cómo protegerse del secuestro de cookies
No te pienses que hay una solución mágica, ni rápida, aquí no hay bala de plata, porque el robo casi siempre ocurre fuera de WordPress, en tu equipo o en una página de phishing.
Lo que sí está en tu mano es reducir la ventana de tiempo y la superficie de ataque, capa a capa.
Fuerza HTTPS en toda la web, sin excepciones
Es lo más básico y es lo que cierra de golpe el robo por red. Cualquier hosting decente te da el certificado gratis, así que no tienes excusa.
Acorta la vida de la sesión y olvídate de «Recuérdame»
Con el filtro auth_cookie_expiration bajas la caducidad de la cookie, y cuanto menos dure, menos le sirve al que te la roba.
Por ejemplo, para dejarla en un día:
// Acortar duración de sesión de login a 1 día
function ayudawp_short_auth_cookie( $expiration, $user_id, $remember ) {
return DAY_IN_SECONDS; // 1 día en segundos.
}
add_filter( 'auth_cookie_expiration', 'ayudawp_short_auth_cookie', 10, 3 );
Cierra la sesión cuando termines
Cerrar la pestaña del navegador no cierra la sesión, la cookie sigue viva y coleando. Acostúmbrate a darle a «Cerrar sesión» en tu WordPress, sobre todo en equipos que no son solo tuyos.
Echa a los inactivos y a las sesiones viejas
Desde tu perfil tienes el botón «Cerrar sesión en el resto de sitios» que te decía antes. Y si gestionas una web con varios usuarios, puedes forzar la desconexión de los usuarios inactivos cada cierto tiempo.
Cambia la contraseña para matar las cookies robadas
Como la firma de la cookie lleva un trozo del hash de tu contraseña, en cuanto la cambias, las cookies viejas dejan de valer.
Es de las poquísimas cosas que invalidan una cookie que ya te han robado, así que si sospechas algo, cambia la contraseña.
Rota las claves salt cuando sospeches
Cambiar las salt de tu wp-config.php cierra todas las sesiones de golpe, también la del intruso. Que quede claro, esto no evita el robo, es el interruptor de emergencia para echar a todo el mundo en un segundo.
Te conté cómo automatizarlo aquí.
Cuida el equipo desde el que administras, que es el eslabón de verdad
Antivirus al día, nada de instalar extensiones de navegador de dudosa procedencia, y ni se te ocurra administrar tu WordPress desde un ordenador público o compartido.
El infostealer entra por ahí, y mientras no limpies el equipo te van a robar la cookie las veces que haga falta.
Bloquea por IP y por user agent lo que no tenga sentido
Si a tu zona de administración solo entráis tú y dos personas más desde España, no hay motivo para permitir accesos desde medio mundo.
Limitar el acceso por IP ayuda, y bloquear agentes de usuario sospechosos suele ser todavía más eficaz.
Pon las cabeceras de seguridad y, si puedes, el atributo SameSite
Esto protege más contra el CSRF que contra el robo por infostealer, pero suma a la defensa general.
WordPress no pone el atributo SameSite en las cookies por defecto, lo tienes que añadir tú con un plugin, en el servidor o en tu CDN.
Para el resto de cabeceras tienes en analizador de seguridad con generador de cabeceras.
Pon verificación en dos pasos 2FA
Ya te he dicho que no te salva del pase de cookie, pero corta en seco el otro vector del estudio, el de las credenciales robadas, que era alrededor de siete de cada cien infecciones.
Tenlo activo, pero siendo consciente de qué cubre y qué no.
¿Y los plugins?
Para la gestión de sesiones Wordfence, Shield Security y Kadence Security tienen funciones específicas para esto.
En mi propio plugin gratuito, Vigilante, lo que te sirve aquí es el registro de actividad para cazar sesiones raras, la doble verificación, la URL de acceso personalizada y las reglas por IP para que cueste más robarte las credenciales, y la protección de la REST API para limitar lo que una sesión secuestrada puede tocar.
Lo que no hace WordPress, ni de serie ni la mayoría de plugins, es validar la sesión contra tu IP o tu dispositivo en cada visita.
El dato está ahí (desde WordPress 4.0 cada sesión guarda la IP y el navegador con que entraste, y los ves en plugins como Vigilante), pero en el núcleo de WordPress se decició no usarlo para cerrar sesiones, porque las IP cambian sin parar (móvil, VPN, IPv6) y acabaría echando a gente legítima a todas horas.
Ya me ha pasado, ¿qué hago ahora mismo?
Si tienes señales de que te han secuestrado la sesión, esto es lo que yo haría, en orden y sin perder tiempo:
- Rota las claves salt ya mismo: Echas a todo el mundo de golpe, incluido el intruso, así que es lo primero, porque corta el acceso al instante.
- Cambia las contraseñas de todos los administradores: Refuerza lo anterior e invalida cualquier cookie que siguiera viva.
- Busca usuarios administradores que no hayas creado tú y bórralos: Es lo primero que suelen dejar plantado.
- Pasa un escáner de integridad de archivos: Por si te han dejado una puerta trasera, y repasa el registro de actividad para saber qué tocaron y cuándo.
- Revisa el equipo desde el que administras: Si fue un infostealer, mientras no lo limpies te van a robar la cookie nueva en cuanto vuelvas a entrar.
Si te supera, que no pasa nada, hay por ahí profesionales especializados en limpiar y reforzar webs WordPress.
Si hoy solo vas a hacer 3 cosas que sean estas: forzar HTTPS en toda la web, acostumbrarte a cerrar sesión de verdad al terminar y dejar de marcar «Recuérdame» en las webs que administras.
Con eso solo ya le quitas al ladrón de cookies la mitad del negocio, el resto, capa a capa, cuando vayas pudiendo. Lo demás ya es cosa tuya.
¿Te ha pasado alguna vez, o te queda alguna duda rondando? Me tienes aquí abajo, en los comentarios.
¿Te gustó este artículo? ¡Ni te imaginas lo que te estás perdiendo en YouTube!
Excelente artículo. Y es que estamos cada vez más indefensos…
No nos hacemos una idea de lo jodida que está la cosa. Instala el Vigilante, echa un vistazo a la auditoría y vas a flipar 😮
Hola, Fernando.
Enhorabuena por la labor de ayuda que realizas. Querría consultarte algo, una vez instalado tu plugin Vigilante: antes de activar una dirección alternativa propia para el login, ¿debería eliminar el bloqueo previo que tengo instalado en el directorio wp-admin?
Mil gracias de nuevo por tu trabajo.
Guillermo Torres
Hola Guillermo,
Si te refieres a protección por htpasswd son perfectamente compatibles, pero quizás redundantes, el más potente es el de htpasswd, porque es antes incluso de cargar WordPress