El stack que auditamos
El sitio WordPress de una pequeña empresa llegó para una auditoría de seguridad, y los hallazgos eran del tipo corriente que en silencio deja un sitio a un escaneo automatizado de distancia del compromiso. El maquetador de páginas, Elementor, estaba fijado en la versión 3.11.1, con cuatro CVE críticas, incluidas SQL injection y stored cross-site scripting. Contact Form 7 corría en la 5.8, expuesto a CVE-2023-6449, una subida arbitraria de archivos. Nada exótico, simplemente plugins desactualizados, que es la forma dominante en que los sitios WordPress resultan comprometidos.
Lo incómodo es lo normal que es esto. El sitio funcionaba. Tenía buen aspecto. El propietario no tenía motivos para sospechar nada, porque los plugins desactualizados no muestran síntomas hasta que se explotan. La auditoría existía para encontrar la brecha antes de que lo hiciera otro.
Los plugins desactualizados son la superficie de ataque
Un plugin es seguro mientras recibe parches. En el momento en que una vulnerabilidad se publica como CVE y no has actualizado, el exploit es conocimiento público y tu versión instalada es un objetivo identificado para los escáneres automatizados. Los ataques a WordPress son en su gran mayoría ciegos y automatizados, los bots barren la red en busca de versiones reconocidamente vulnerables de plugins populares, así que ejecutar un Elementor o un Contact Form 7 antiguo no es un riesgo abstracto. Es uno anunciado.
En este sitio:
- Elementor 3.11.1 llevaba cuatro CVE críticas (entre ellas SQL injection y stored cross-site scripting), mientras la línea parcheada ya había avanzado a la 3.17.3. Cada una de esas cuatro estaba activa.
- Contact Form 7 5.8 estaba expuesto a CVE-2023-6449, un fallo de subida de archivos por arrastrar y soltar que permitía a un usuario autenticado con permisos de editor subir archivos arbitrarios, una vía directa hacia la ejecución remota de código.
Ninguno de los plugins era inusual. Ambos están en una enorme proporción de sitios WordPress. Precisamente por eso sus vulnerabilidades conocidas valen el tiempo de un escáner.
Qué revisa la auditoría
Una auditoría de seguridad es metódica más que ingeniosa. Su núcleo:
- Inventariar cada plugin y tema instalado y cotejar cada versión con sus CVE conocidas y la versión mínima segura. Esto es lo que sacó a la luz aquí la exposición de Elementor y Contact Form 7.
- Probar el código personalizado y del tema frente a las bases de la seguridad de WordPress, verificaciones de nonce y de permisos en las acciones, entrada saneada antes de llegar a la base de datos, salida con escaping antes de llegar a la página y endpoints que exigen autorización.
- Revisar la exposición a nivel de servidor, un
xmlrpc.phpabierto, errores PHP mostrados en producción que filtran rutas, cabeceras de seguridad ausentes. - Revisar la postura de actualización y de copias de seguridad, porque un sitio sin mantenimiento vuelve a este estado en cuestión de meses.
El cotejo de versiones es la parte poco vistosa que más detecta, porque la vulnerabilidad WordPress más común no es un zero-day ingenioso. Es un plugin popular tres versiones por detrás de su parche.
Dónde lo empeoran las construcciones asistidas por IA
Esta auditoría trataba de plugins de terceros desactualizados, el patrón de descuido. Las construcciones asistidas por IA añaden una segunda capa encima. Instalan plugins deprisa, a menudo sin establecer ninguna rutina de actualización, por lo que las versiones se quedan atrás respecto a sus parches aún más deprisa. Y el código personalizado generado por IA se crea con frecuencia sin las verificaciones de nonce, de permisos y de saneamiento que WordPress espera, así que heredas a la vez un problema de plugins desactualizados y un problema de código generado. Por eso este tipo de auditoría forma parte de nuestro trabajo más amplio de rescate de webs hechas por IA, y por eso una auditoría de seguridad WordPress independiente empieza por el aburrido cotejo de versiones antes que por cualquier otra cosa.
Cómo es la reparación
El orden de la reparación sigue el riesgo, no la comodidad:
- Parchear o eliminar de inmediato los plugins con CVE activas, empezando por las vías de subida de archivos e injection, porque son las de mayor gravedad.
- Eliminar los plugins abandonados o ya innecesarios, reduciendo la superficie de forma permanente.
- Cerrar la exposición a nivel de servidor (
xmlrpc.php, visualización de errores en producción, cabeceras ausentes). - Poner en marcha una rutina real de actualización y de copias de seguridad, para que el sitio no vuelva a cuatro CVE activas en el plazo de un año.
Glosario
- CVE - un identificador de Common Vulnerabilities and Exposures, una entrada pública de catálogo para una vulnerabilidad conocida concreta.
- SQL injection - un ataque que cuela comandos de base de datos a través de entrada sin saneamiento.
- Stored cross-site scripting - script malicioso guardado en el sitio y servido a otros usuarios.
- Verificación de nonce / permisos - mecanismos de WordPress que confirman que una petición es intencionada y que el usuario tiene permiso para hacerla.
La conclusión
Un sitio WordPress no tiene por qué ser interesante para ser atacado. Le basta con ejecutar una versión reconocidamente vulnerable de un plugin popular, lo que describe una gran proporción de los sitios que no se han auditado. La buena noticia es que el riesgo dominante es también el más aburrido de arreglar, coteja cada versión de plugin con sus CVE, parchea o elimina a los culpables y pon en marcha una rutina de mantenimiento para que la brecha no vuelva a abrirse. El sitio de esta auditoría estaba a un escaneo de los problemas y no lo sabía. La mayoría de los sitios en esa situación tampoco.
