¿Es este el peor hackeo en la historia de WordPress?

Españolالعربية Deutsch English Français हिन्दी Bahasa Indonesia 日本語 한국어 Português Русский 中文

AI/미래기술경제 뉴스컴퓨터/소프트웨어

Transcript

00:00:00WordPress ha tenido una serie de vulnerabilidades recientemente, y la última es tan grave

00:00:04que permite a los hackers tomar control total del panel de administración. Hablamos de inyección SQL, ejecución de

00:00:09comandos de shell, algo bastante grave. Tal vez no te interese WordPress, pero aún impulsa más del 44%

00:00:14de los sitios web del mundo, por lo que muchos de los sitios con los que interactúas y a los que das tus datos

00:00:19podrían estar ejecutando WordPress y esta versión vulnerable. Básicamente funciona así:

00:00:25Tengo instalada localmente una versión estándar de WordPress y puedo ejecutar este

00:00:29primer script para ver si la vulnerabilidad está presente, y como ven, obtenemos la respuesta

00:00:34HTTP 207, lo que significa que sí, efectivamente es vulnerable, y eso implica que ahora podemos ejecutar la segunda comprobación,

00:00:41que es entrar a la shell interactiva. Esto realiza la inyección SQL en el sitio, crea un nuevo usuario administrador

00:00:47y luego sube un plugin malicioso que me permite interactuar con cualquier archivo de este sitio web.

00:00:52Así que profundicemos en el problema y veamos exactamente cómo funciona.

00:00:58Este repositorio que estoy viendo muestra exactamente cómo inyectar SQL en sitios vulnerables de WordPress. Es decir,

00:01:06cualquier sitio entre la versión 6.90 y 6.94 o 7.00 y 7.01. Todo el ataque comienza llamando a un endpoint no autenticado

00:01:14batch v1, que te permite agrupar otras solicitudes que en sí mismas están validadas y con permisos verificados.

00:01:20El gestor de lotes tiene dos arreglos paralelos que se supone deben mantenerse sincronizados: validación y coincidencias.

00:01:26Pero un error hizo que cuando la función wp pass URL falla debido a una ruta no válida, solo se actualizara validación,

00:01:33por lo que ahora el mismo índice usado para consultar ambos arreglos producía resultados no coincidentes. La PoC aprovecha esto:

00:01:41envía un lote que contiene solo una solicitud, un POST al endpoint v2 post, que a su vez lleva un cuerpo de solicitud.

00:01:48Dado que la solicitud principal se validó correctamente como una solicitud POST, cualquier solicitud en el cuerpo termina eludiendo la lista de métodos permitidos,

00:01:56permitiéndote enviar solicitudes GET. Luego, dentro de ese lote interno, hay una solicitud GET a una publicación que no existe, lo que activa la

00:02:02desincronización anterior, haciendo que WordPress envíe la misma solicitud bajo una función llamada get items donde el campo author

00:02:10exclude se asigna a author not in, el cual la versión vulnerable interpola en SQL como una cadena. Básicamente, como todo esto se está ejecutando,

00:02:18el SQL no se escapa. La PoC utiliza una serie de solicitudes que finalmente permiten que una solicitud POST a v2 users cree

00:02:25una nueva cuenta de administrador. El repositorio detalla todos estos pasos: los primeros cinco son previos a la autenticación, por lo que aprovechan el error, pero el paso seis es solo el comportamiento normal de WordPress para

00:02:35usuarios autenticados, que consiste en subir un paquete malicioso. Muy bien, como se mencionó antes, esta es solo la versión estándar de WordPress, la vulnerabilidad no se accede a través de un plugin malicioso,

00:02:46puedes simplemente instalar un WordPress estándar. Primero ejecutamos este script de verificación que básicamente valida si la

00:02:52vulnerabilidad se puede ejecutar, y luego podemos ejecutar este comando de lectura, por ejemplo, que nos indica datos como el

00:02:57usuario y el nombre de la base de datos. Ahora también podemos ejecutar consultas SQL en el sitio web, para averiguar cosas como

00:03:03qué versión de la base de datos está ejecutando realmente, y nada de eso es lo realmente malo. Esto es lo verdaderamente grave,

00:03:07donde realmente creamos una cuenta de administrador que tiene acceso para subir un plugin malicioso; en este

00:03:15caso se llama web shell. Esto nos permite acceder a la shell del sitio web, lo que significa que ahora tenemos acceso a

00:03:22cualquier archivo en este sitio web. Este ataque ocurre de la manera que explicamos anteriormente en el video, así que

00:03:27después de crear el administrador, se sube el plugin y finalmente se elimina ese usuario, por lo que la existencia

00:03:34del plugin y lo que ha sucedido es ahora más discreto. Para demostrar también lo grave que es esto, he creado un script separado

00:03:38que creará un administrador y lo mantendrá en el sistema.

00:03:40Aquí tengo un nombre de usuario y una contraseña; de vuelta en el sitio web, si voy a la ruta wp-login, puedo ingresar ese

00:03:47nombre de usuario y contraseña, hacer clic en iniciar sesión y ahora tengo acceso total al panel de administración. Si algo de esto te resulta confuso, no te preocupes,

00:03:54a mí también me tomó mucho tiempo entenderlo. Se afirma que la cadena de explotación resultante fue tan absurdamente

00:04:00compleja que a un investigador humano de seguridad le habría llevado semanas, si no meses, descubrir y

00:04:05armar por sí solo. Ningún investigador de seguridad podría haber encontrado y completado esta cadena de explotación

00:04:10en 10 horas sin IA. Esto es bastante aterrador porque los atacantes podrían tener bots escaneando

00:04:17repositorios, verificando URLs, solo esperando a que aparezcan vulnerabilidades y explotándolas en tiempo récord usando IA.

00:04:23Un usuario en Reddit dijo que su sitio fue comprometido solo dos días después de que se descubriera,

00:04:27y como solo actualizan los fines de semana, un atacante pudo crear un nuevo administrador e iniciar sesión para aquellos

00:04:33que eran vulnerables. El exploit se solucionó en la versión 7.0.2, así que pueden actualizar a esa, pero este es un caso bastante increíble.

00:04:40Pueden encontrar el repositorio y el artículo que usé para ejecutar la PoC en los comentarios, y por qué no,

00:04:46suscríbanse a Better Stack para mantenerse al día con todas las noticias tecnológicas. Espero que les haya gustado esto, amigos, y

00:04:50por supuesto, como siempre, nos vemos en el próximo video.

Key Takeaway

Una falla técnica en el gestor de lotes de WordPress (versiones 6.90-6.94 y 7.00-7.01) permite a atacantes tomar el control total del servidor mediante la inyección de administradores no autorizados y web shells en un proceso optimizado por IA en solo 10 horas.

Highlights

WordPress impulsa más del 44% de los sitios web del mundo, lo que expande el impacto de sus fallos de seguridad a millones de usuarios.
Una vulnerabilidad crítica en las versiones de WordPress 6.90 a 6.94 y 7.00 a 7.01 permite la ejecución de comandos de shell e inyección SQL sin autenticación previa.
El fallo se origina en la desincronización de dos arreglos internos (validación y coincidencias) dentro del gestor de lotes al fallar la función wp pass URL.
Un exploit de seis pasos evade la lista de métodos permitidos, genera un usuario administrador sin permiso y sube un plugin ejecutable tipo web shell.
Herramientas de inteligencia artificial redujeron el tiempo necesario para armar esta compleja cadena de explotación a solo 10 horas, un proceso que a un investigador humano le tomaría meses.
La actualización a la versión 7.0.2 de WordPress corrige por completo este vector de ataque.

Timeline

Alcance global e impacto del fallo de seguridad

El 44% de los sitios web globales utilizan la infraestructura de WordPress.
Un fallo en el núcleo del sistema expone las bases de datos a inyecciones SQL y ejecución remota de comandos de shell.
La prueba de concepto confirma la vulnerabilidad al recibir una respuesta HTTP 207.

Las vulnerabilidades de seguridad en esta plataforma afectan masivamente a usuarios que entregan datos en la red sin saber que interactúan con instalaciones expuestas. Una verificación mediante script valida si el entorno es susceptible a la intrusión antes de iniciar el compromiso del sistema. Al obtener la respuesta HTTP 207, el atacante confirma la disponibilidad de los vectores de inyección.

Mecanismo técnico de la inyección SQL y desincronización

Las versiones afectadas comprenden de la 6.90 a la 6.94 y de la 7.00 a la 7.01.
El vector de entrada utiliza el endpoint no autenticado batch v1 para evadir la lista de métodos permitidos.
Un error en wp pass URL desincroniza los arreglos de validación y coincidencias.
El parámetro author exclude interpola cadenas directamente en SQL sin escapar los caracteres.

El ataque aprovecha la estructura interna del gestor de lotes, el cual maneja dos arreglos paralelos para procesar solicitudes. Cuando una ruta no válida hace fallar la función wp pass URL, solo el arreglo de validación se actualiza, dejando desalineados los índices de ambas listas. Esta falla permite transformar una solicitud GET en un POST no validado hacia el endpoint v2 post, logrando que el parámetro author exclude sea interpolado en la base de datos sin sanitización.

Escalación de privilegios y persistencia mediante web shell

El proceso no requiere plugins de terceros previa instalación, afectando a la versión estándar de WordPress.
La creación del usuario administrador abre la puerta al despliegue de un plugin ejecutable malicioso.
El atacante elimina la cuenta creada para borrar rastros mientras conserva el acceso por la shell.

Una vez explotada la inyección SQL, el atacante envía una solicitud POST a v2 users para dar de alta una cuenta con rango de administrador. Con este acceso, sube un paquete ejecutable conocido como web shell que le concede lectura y escritura sobre todos los archivos del servidor. Finalmente, el usuario administrador original se borra del sistema para evitar detecciones tempranas en el panel de control.

Automatización con IA y resolución en la versión 7.0.2

El desarrollo de esta cadena de explotación tomó 10 horas mediante el uso de inteligencia artificial.
Sitios no actualizados sufrieron intrusiones en un lapso de 48 horas tras la divulgación del fallo.
La versión 7.0.2 elimina la vulnerabilidad por completo.

La complejidad de esta vulnerabilidad habría requerido meses de análisis por parte de auditores humanos trabajando de forma manual. El uso de modelos de inteligencia artificial por parte de cibercriminales acorta drásticamente el tiempo entre el descubrimiento de un fallo y su explotación masiva mediante bots. Los administradores de sitios deben aplicar el parche a la versión 7.0.2 para cerrar los vectores de entrada.

Community Posts

Write about this video