Por Canuto  

Un investigador de seguridad utilizó inteligencia artificial para analizar el código de WordPress y construir una compleja cadena de exploits en poco más de 10 horas. El experimento costó cerca de USD $25, pero su verdadero impacto está en cómo reduce la barrera económica para investigar vulnerabilidades sofisticadas.
***

  • Una IA conectó fallos en la API de lotes, las consultas SQL, la caché y los permisos de WordPress para crear una cadena previa a la autenticación.
  • El investigador Adam Kues tuvo que diseñar los prompts, coordinar agentes, verificar los resultados y comprender la explotación final.
  • El bajo costo de estos experimentos podría permitir más ataques, mientras los equipos defensivos tardan mucho más en reproducir, corregir y distribuir parches.

 

Un investigador de seguridad entregó a un modelo avanzado de inteligencia artificial el código fuente de WordPress y le pidió encontrar una ruta desde una solicitud no autenticada hasta la ejecución remota de código. Poco más de 10 horas después, el sistema había construido una cadena de exploits contra una instalación predeterminada de uno de los gestores de contenido más utilizados de internet.

El uso del modelo costó aproximadamente USD $25. En contraste, los corredores de exploits han anunciado recompensas de hasta USD $500.000 por vulnerabilidades comparables en WordPress, indica XDA Developer.

La cifra más importante no es únicamente la diferencia entre el costo del experimento y el valor potencial del fallo. El caso muestra que la IA puede encargarse de buena parte del trabajo lento y especializado que antes limitaba la investigación ofensiva a expertos con mucho tiempo y recursos.

Una cadena de fallos, no un escaneo automático

Según XDA Developers, el investigador Adam Kues no utilizó un escáner convencional para esperar una alerta sobre código sospechoso. Descargó el código fuente actual de WordPress, eliminó su historial de Git y ordenó al modelo trabajar directamente con el código, sin buscar parches conocidos ni informes públicos.

Kues también impuso requisitos estrictos para la investigación. El ataque debía funcionar antes de la autenticación, contra una configuración de producción relativamente normal y utilizando MySQL, lo que descartaba errores útiles únicamente después del inicio de sesión o bajo configuraciones poco habituales.

El primer hallazgo relevante apareció en la API de lotes de WordPress. El sistema utilizaba arrays separados para seguir los controladores de solicitudes coincidentes y los resultados de sus validaciones.

Una solicitud malformada podía desalinear esos arrays. Como consecuencia, una petición podía ser comprobada con las reglas de validación correspondientes a otro endpoint, lo que abría una brecha en el proceso de sanitización.

El modelo conectó después ese comportamiento con otro error en el manejo de entradas. La combinación permitía que un valor no sanitizado llegara hasta una consulta SQL y habilitara una inyección previa a la autenticación.

El modelo resolvió una restricción técnica clave

La primera ruta vulnerable hacia la base de datos normalmente se alcanzaba mediante una solicitud GET. Sin embargo, la API de lotes rechazaba ese tipo de solicitudes, por lo que la identificación del fallo no bastaba para completar el ataque.

El modelo encontró una forma de sortear esa limitación. Anidó una solicitud de lotes dentro de otra y aprovechó dos veces la inconsistencia de validación.

El resultado fue una inyección SQL capaz de leer valores arbitrarios de la base de datos. La vulnerabilidad entregaba inicialmente acceso de lectura, pero no concedía de manera automática una cuenta administrativa funcional.

Esa diferencia era importante porque WordPress almacena las contraseñas como hashes. Una contraseña administrativa robusta podía resultar impráctica de descifrar, de modo que el modelo tuvo que buscar una ruta distinta para convertir la lectura de datos en privilegios elevados.

La investigación avanzó mediante la combinación de comportamientos poco conocidos del sistema. Ninguna de las piezas individuales ofrecía ejecución remota de código, pero juntas podían producir una secuencia de ataque mucho más grave.

De la base de datos al control administrativo

La inyección SQL podía fabricar registros de publicaciones devueltos por la base de datos. Esos objetos se colocaban temporalmente en la caché de publicaciones en memoria de WordPress.

El modelo utilizó después el comportamiento de incrustación de la plataforma para transformar algunos objetos temporales en registros persistentes de la base de datos. Esto creó una diferencia entre una publicación almacenada en caché y su versión permanente.

WordPress debía reconciliar y actualizar ambas versiones. El exploit aprovechaba ese proceso para influir en la manera en que el sistema manejaba los datos y sus permisos.

La cadena incorporó cambios en los conjuntos de personalización de temas, una corrección del ciclo de jerarquía de publicaciones y el sistema de ganchos dinámicos de WordPress. Cada componente aportaba un comportamiento necesario para avanzar.

El ataque provocaba temporalmente que WordPress operara con la autoridad del administrador principal. Luego utilizaba el gancho parse_request para repetir la solicitud de lotes original mientras esa ventana privilegiada seguía activa.

La creación de un administrador abrió la puerta final

El primer intento para crear una nueva cuenta administrativa fracasó porque la solicitud se ejecutó como invitado. La repetición dentro de la ventana privilegiada permitió que el segundo intento tuviera éxito.

Una vez creada la cuenta, el atacante podía iniciar sesión con privilegios administrativos. Desde allí, podía cargar un plugin que funcionara como puerta trasera.

La instalación de ese plugin completaba la ruta hacia la ejecución de código en el servidor. El proceso ilustra por qué una vulnerabilidad de lectura puede adquirir un impacto mucho mayor cuando se combina con fallos de lógica y permisos.

La cadena cruzó la validación de la API, la construcción de consultas SQL, la caché de objetos, las incrustaciones, la reconciliación de publicaciones, los conjuntos de cambios, la jerarquía de contenido, los ganchos dinámicos y el despacho de solicitudes.

El caso no representa un ataque de un solo clic. Su funcionamiento dependía de una secuencia muy específica y de la comprensión de múltiples comportamientos desconectados dentro de una base de código extensa.

La experiencia humana siguió siendo indispensable

Kues escribió un prompt detallado, adaptó ideas de un prompt de investigación existente, proporcionó el árbol de código fuente e impuso restricciones para orientar el análisis. También dirigió a varios agentes que exploraron diferentes partes del problema durante al menos seis horas.

El modelo realizó una parte considerable del trabajo, pero no recibió una orden vaga para “hackear WordPress”. La investigación necesitó objetivos concretos, condiciones técnicas y una estrategia diseñada por una persona con conocimientos especializados.

El investigador verificó cuidadosamente los resultados. Reprodujo la inyección SQL contra una instalación remota de WordPress y confirmó que podía recuperar el correo electrónico del administrador utilizado durante la configuración.

Después, Kues impulsó al modelo a buscar métodos de escalamiento. Dedicó buena parte del día siguiente a desentrañar la cadena final antes de reportarla de forma responsable.

La inyección SQL resultó relativamente comprensible para el investigador. En cambio, los pasos posteriores a la explotación le tomaron más tiempo para entender que el proceso que el modelo había utilizado para generarlos.

El bajo costo puede multiplicar los intentos ofensivos

La participación humana no elimina la preocupación. Cuando un intento extenso cuesta cerca de USD $25, un atacante puede repetirlo contra distintas aplicaciones, ajustar los prompts y conservar los hallazgos intermedios.

El costo citado corresponde al uso del modelo durante esta investigación específica. No incluye el tiempo del investigador, su experiencia en seguridad, la infraestructura, la verificación ni el esfuerzo necesario para comprender y divulgar la cadena.

Los modelos todavía producen callejones sin salida, suposiciones inválidas y código que parece correcto sin funcionar. Una persona con menos experiencia podría recibir una respuesta plausible y no saber si se trata de un hallazgo válido o de una construcción defectuosa.

Kues incorporó controles adversariales e instrucciones para reducir esos problemas. También evitó que cada agente siguiera la misma idea prometedora, con el objetivo de ampliar la exploración y disminuir los sesgos del proceso.

Por eso, el experimento no demuestra que cualquiera pueda producir de manera confiable un exploit valorado en USD $500.000 durante una tarde. Sí demuestra que un investigador experimentado puede dirigir mucho más trabajo ofensivo con un presupuesto suficientemente bajo para repetir el proceso.

Los defensores podrían enfrentar una nueva asimetría

Los proveedores de software ya enfrentan dificultades para procesar reportes, reproducir errores complejos, construir parches, probar regresiones y convencer a los usuarios de instalar actualizaciones. La IA puede abaratar el descubrimiento sin acelerar por igual todas esas tareas defensivas.

Un investigador podría gastar USD $25 y medio día en hallar un fallo. El proveedor, en cambio, podría necesitar días para comprender la cadena y semanas para corregirla sin romper otras funciones.

WordPress hace especialmente visible ese riesgo porque su software central sostiene una enorme cantidad de sitios web. Una vulnerabilidad en una función predeterminada puede crear un grupo amplio de objetivos antes de que los administradores conozcan el problema.

Kues retrasó la publicación para dar tiempo a los usuarios a actualizar sus instalaciones. Aun así, otros investigadores lograron reproducir la cadena antes de que apareciera un código público de prueba de concepto.

La reproducción independiente ayuda a validar un hallazgo, pero también muestra la velocidad con que una vulnerabilidad protegida puede ser comprendida por más personas. La ventana entre el descubrimiento y la explotación podría estrecharse.

La defensa deberá adoptar herramientas similares

Los proveedores podrían necesitar auditorías continuas de código asistidas por IA. También tendrían que examinar combinaciones inusuales de comportamientos ordinarios, en lugar de concentrarse únicamente en funciones identificadas como sospechosas.

Las correcciones deberían probarse contra rutas de ataque que un revisor humano quizá nunca consideraría. La IA puede ayudar a generar esas rutas y a evaluar si un parche bloquea la cadena sin introducir nuevos problemas.

Los equipos también necesitarán inventarios más completos de software. Tras una divulgación, deberán identificar con rapidez qué sistemas utilizan la versión vulnerable y qué instalaciones permanecen expuestas.

Estas medidas requieren tiempo, dinero y personal especializado. Sin embargo, podrían convertirse en una condición necesaria si la investigación de vulnerabilidades asistida por IA pasa de ser excepcional a rutinaria.

El desafío no consiste únicamente en encontrar más fallos. Los defensores deben cerrar la diferencia entre descubrir una vulnerabilidad, entender su impacto, corregirla y lograr que los usuarios instalen la actualización.

La verdadera advertencia está en la economía del exploit

El experimento no prueba que la inteligencia artificial pueda reemplazar a los investigadores de seguridad experimentados. Más bien, muestra que una persona con experiencia ahora puede supervisar una cantidad mucho mayor de trabajo investigativo.

El modelo revisó código, propuso técnicas poco comunes, abandonó rutas fallidas y conectó partes distantes de WordPress en una cadena funcional. El humano siguió siendo esencial, pero la cantidad de trabajo utilizable aumentó drásticamente.

La barrera de experiencia todavía existe. La diferencia es que el costo de aportar horas adicionales de investigación especializada disminuyó de forma significativa.

Ese cambio puede beneficiar a la seguridad del software cuando investigadores responsables y proveedores emplean la IA para anticipar ataques. También puede ampliar el acceso a capacidades ofensivas para grupos criminales pequeños y operadores independientes.

La comparación con USD $500.000 atrae la atención, pero el problema central es la distancia entre el valor del exploit y el costo de buscarlo. Si esa búsqueda continúa abaratándose, los defensores no podrán trabajar al ritmo anterior.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados