WordPress 7.1.4 corrige una race condition del actualizador: así la bloquea Hive
WordPress 7.1.4 corrige una race condition en el actualizador del núcleo que permitía a un atacante sin cuenta hacerse con un sitio durante los pocos segundos que dura una actualización. Ya hay atacantes buscándola, y ReportedIP Hive bloquea estas solicitudes en cada instalación.
Actualiza WordPress primero. El resto de este artículo explica el fallo, por qué la mayoría de los cortafuegos en forma de plugin no ven el ataque y qué hace Hive al respecto.
¿Qué es la race condition del actualizador que corrige WordPress 7.1.4?
En una actualización completa del núcleo, WordPress descomprime todo el paquete en una carpeta dentro de wp-content/upgrade/. Antes de la 7.1.4, esa carpeta tenía un nombre predecible: el nombre del paquete más un sufijo aleatorio corto. Además, el paso de limpieza eliminaba el archivo index.php que normalmente protege la carpeta.
Durante unos segundos, la carpeta contiene una copia completa y ejecutable de WordPress. Un atacante que llame en ese momento al wp-admin/setup-config.php o al install.php de esa copia puede conectarla a una base de datos que controla y acabar ejecutando su propio código en el servidor. No necesita iniciar sesión ni ninguna acción de un usuario.
El fallo lo notificó Umut Bayram. El anuncio oficial de WordPress 7.1.4 lo describe como una debilidad en el proceso de actualización que puede llevar a la ejecución remota de código durante la actualización. En el momento de escribir esto no tiene identificador CVE.
¿Qué versiones de WordPress están afectadas y cuáles lo corrigen?
| Dato | Detalle |
|---|---|
| Versiones afectadas | WordPress 4.7 a 7.1.3 |
| Cuándo está expuesto un sitio | Solo mientras un paquete completo del núcleo está descomprimido durante una actualización |
| Corregido en | 7.1.4, 7.0.8, 6.9.11, 6.8.12 |
| Ramas anteriores | Parches retroportados hasta la 4.7.39 |
| Notificado por | Umut Bayram |
| CVE | Ninguno asignado en el momento de escribir esto |
La corrección cambia tres cosas. El nombre de la carpeta de descompresión termina ahora en 16 caracteres aleatorios. El index.php que la protege se mantiene. Y wp-config.php ya no se copia desde la carpeta de trabajo. Patchstack y HOL explican el parche en detalle.
¿Ya hay atacantes buscando el fallo de actualización?
Los escaneos empezaron justo después de la publicación. Wordfence contó más de 18.500 solicitudes dirigidas a rutas de instalación descomprimidas en las primeras 21 horas, según GBHackers. Los escáneres consultan una y otra vez los nombres de carpeta probables y esperan a que un sitio inicie una actualización.
¿Por qué los cortafuegos habituales de WordPress no ven este ataque?
La copia descomprimida arranca desde sus propios archivos. Una solicitud a wp-content/upgrade/…/wp-admin/setup-config.php nunca carga el WordPress real del sitio, así que no se ejecuta ninguno de sus plugins. Un cortafuegos dentro de un plugin no puede bloquear una solicitud que nunca ve. Patchstack y Wordfence dicen lo mismo sobre los cortafuegos a nivel de PHP.
¿Cómo protege ReportedIP Hive frente a esta race condition?
Protegemos a nuestros clientes. El WAF de Hive bloquea estas solicitudes, y la actualización Hive 3.0.6 ya se ha distribuido para cerrar la ventana de actualización en Apache.
Una nueva firma WAF en el feed de reglas
El feed de reglas que recibe cada instalación de Hive incluye una firma para este ataque. Se aplica a cualquier solicitud de un archivo PHP dentro de wp-content/upgrade/ o wp-content/upgrade-temp-backup/. Ninguna solicitud legítima carga PHP desde ahí, así que la regla no interfiere con las actualizaciones normales.
- Está activa en todos los planes, también en Free.
- Los sitios en modo Community Network la reciben automáticamente. No hace falta cambiar ningún ajuste.
- Ante una coincidencia, Hive responde con un 403 y bloquea la IP desde la primera solicitud.
- La IP se comparte con el Community Network, de modo que las IP que escanean acaban en la lista de bloqueo compartida para cada sitio conectado.
Cuando la solicitud llega a WordPress, Hive la bloquea
Un WAF dentro de WordPress solo puede actuar sobre las solicitudes que llegan a WordPress. En Apache, las solicitudes a rutas de descompresión que no existen terminan en WordPress, así que los escáneres que adivinan nombres de carpeta erróneos se detectan y se bloquean ahí. Los sitios con la protección ampliada activada ejecutan el cortafuegos antes de WordPress y están protegidos incluso mientras se descomprime una actualización.
Hive 3.0.6 cierra la ventana de actualización en Apache
Queda la carpeta que sí existe durante una actualización. Hive 3.0.6 la resuelve según el servidor web:
- Apache: Hive escribe automáticamente una regla de reescritura en el archivo
.htaccessde la raíz del sitio. Envía cada solicitud PHP dentro dewp-content/upgrade/a WordPress, donde el WAF la bloquea, también en plena actualización. - nginx: nginx no lee archivos
.htaccess. Los ajustes del cortafuegos de Hive muestran un fragmento listo para añadir al bloque server:location ^~ /wp-content/upgrade/ { rewrite ^ /index.php last; } - Local Shield: la regla también viene en el conjunto de reglas base incluido en el plugin, así que los sitios sin conexión al feed la reciben con la actualización.
La actualización llega por la pantalla de actualizaciones normal de WordPress, igual que la versión Hive 3.0.5.
¿Qué deben hacer ahora los propietarios de sitios WordPress?
- Actualiza WordPress a la versión corregida de tu rama: 7.1.4, 7.0.8, 6.9.11, 6.8.12 o el parche retroportado de una rama anterior.
- Busca en los registros de acceso solicitudes a
setup-config.phpoinstall.phpdentro de/wp-content/upgrade/. - Comprueba que
wp-content/upgrade/no contiene nada más queindex.php. - Busca cuentas de administrador que no conozcas y archivos PHP en
wp-content/uploads/.
Sin Hive, puedes bloquear la carpeta a nivel de servidor. Estas reglas rechazan cualquier solicitud a ella:
# nginx, dentro del bloque server
location ^~ /wp-content/upgrade/ { deny all; }
# Apache, en el .htaccess de la raíz
RedirectMatch 403 ^/wp-content/upgrade/Cualquiera de las dos reglas encaja bien en la lista de bastionado de WordPress, con Hive o sin él.
Preguntas frecuentes sobre la versión de seguridad WordPress 7.1.4
¿Tienen que hacer algo los usuarios de Hive?
Los usuarios de Hive solo tienen que actualizar WordPress. La firma WAF llega sola a los sitios conectados a través del feed de reglas, y la actualización Hive 3.0.6 escribe la regla de Apache automáticamente. En nginx, añade el fragmento que muestran los ajustes del cortafuegos de Hive para cerrar también la ventana de actualización.
¿Corre riesgo un sitio cuando no se está actualizando?
Un sitio solo está expuesto mientras un paquete completo del núcleo está descomprimido en wp-content/upgrade/, lo que dura unos segundos por actualización. Fuera de esa ventana, el instalador descomprimido no existe. Los sitios con actualizaciones automáticas del núcleo pasan por esa ventana por sí solos, así que actualizar a 7.1.4 sigue siendo importante.
¿Bloquea la regla de Hive las actualizaciones normales de WordPress?
La regla de Hive no bloquea las actualizaciones. WordPress descomprime y copia los archivos directamente en el servidor y nunca carga PHP desde la carpeta de descompresión por HTTP. Solo las solicitudes externas a esos archivos PHP activan la regla, y ningún visitante o servicio legítimo las envía.
ReportedIP Hive bloquea ataques como este en cada sitio conectado y comparte las IP atacantes con el Community Network. El plan Free incluye el feed de reglas WAF.