Un hacker ético muestra cómo se explota PHP2Shell en un entorno controlado y comparte otros exploits
Elígenos como tu fuente preferida en Google.
Ha compartido una demostración de lo que puede hacer PHP2Shell y, además, otros exploits que se pueden utilizar para vulnerar los servicios web que usan el lenguaje PHP.
El caso de PHP2Shell ha despertado todas las alarmas e incluso ha llegado a provocar que numerosas páginas web directamente corten sus servicios para evitar males mayores, ya que al menos el 72% de todas las páginas web del planeta utilizan el lenguaje de programación PHP. Y, precisamente, este nuevo conjunto de vulnerabilidades apunta directamente a este entorno, con un puntuación muy grave de 9,2 sobre 10. Aquí es vital la figura de hackers éticos que muestran cómo funciona esto en un entorno controlado de pruebas, como ha hecho Fernando Conislla Murguia –que tiene en su haber potentes certificaciones como eJPT, eCPPT, eMAPT, eWPT y CEH–, quien ha compartido en una publicación de LinkedIn una demostración de laboratorio sobre la facilidad de explotar este tipo de vulnerabilidades, algo que está totalmente al alcance de personas con los conocimientos suficientes y que busquen hacer el mal.
Básicamente, el hacker ha demostrado cómo en cuestión de segundos el atacante puede hacerse con el control del servidor, inyectar una carga maliciosa e infectar al objetivo sin necesidad de tener que conseguir sus credenciales o contraseñas, mediante el envío de peticiones HTTP manipuladas que engañan al propio servidor para que ejecute órdenes arbitrarias.
En otros casos, he llegado a ver a "expertos de IA" cuestionarse en la misma plataforma que esto fuera tan grave; y, desafortunadamente, sí es muy grave y una de las peores noticias para la comunidad de ciberseguridad defensiva, ya que la solución no es un parche puntual que, aunque necesario, requerirá de otros procedimientos que llevarán semanas o meses para subsanar posibles intromisiones de actores maliciosos.
Más aún, PHP2Shell es un hecho histórico debido a que mantiene un alcance espectacular a nivel mundial, pero también a que es una vulnerabilidad que ha permanecido oculta al menos desde el año 2012 con la versión PHP 5.4.0 e incluso llegando a afectar a las más recientes, como la 8.2, la 8.3, la 8.4 y la 8.5.
Aunque al principio todo parecía estar restringido a las denominadas pruebas de concepto (PoC), lo cierto es que ya hay muchas publicaciones que alertan sobre el gran peligro de saltarse las protecciones de memoria de los sistemas operativos modernos.
Puede parecer otra vulnerabilidad más, pero es crítica para todo el sistema
Aunque haya resultado mediática para algunos, y menos peligrosa que el conjunto de las vulnerabilidades que aparecen cada día, lo cierto es que el laboratorio de Conislla demuestra todo lo contrario. En su demostración se pueden apreciar 2 paneles diferentes.
En la parte izquierda, una terminal de control con una consola de comandos sobre la distro Kali Linux en la que el hacker audita un script de explotación escrito en Python con una instrucción en la que se especifica la url de la víctima, además de la orden del sistema que desea ejecutar y el archivo de salida al que se redirige toda la información.
En el panel derecho, aparece el entorno objetivo PHP2Shell en el que se muestra un navegador web conectado al entorno objetivo –en este caso un laboratorio de investigación de vulnerabilidades en el núcleo de PHP–, con la versión 8.4.26 y una infraestructura de despliegue mediante Docker Lab.
Lo más curioso de este laboratorio de demostración es la velocidad pasmosa con la que se realiza el ataque, ya que en apenas unos segundos el script comienza a enviar diferentes paquetes HTTP diseñados para corromper la memoria del servidor objetivo y, con ello, ejecutar comandos con privilegios de usuario del servicio web en cuestión.
Para bajarlo a una comparación más práctica, imagina que reservas una habitación en un hotel y el encargado te ofrece las llaves de la habitación, pero también anota en un papel el registro con tu nombre. Todo lo apunta en un software que, desafortunadamente, falla y borra la reserva si el usuario no ha hecho el checkin en 5 minutos.
Al cabo de unos 10 minutos llega otro usuario y el encargado del hotel le ofrece la misma habitación al observar que no está ocupada –recuerda, por el fallo del software–, así que este nuevo usuario es capaz de entrar en tu habitación actual y, lógicamente, con las consecuencias negativas para todo. Esto es lo que se conoce en ciberseguridad como Use-After-Free (UAF) o Uso Después de Liberación si se traduce al español.
En PHP ocurre precisamente esto cuando se envía una petición de subida de archivos mediante un formulario web, que puede sufrir una pausa o interrupción de red que dure más que el parámetro configurado –los 5 minutos de la reserva–, pero PHP también mantiene la caché de punteros de memoria antiguos –la nota escrita a mano del trabajador del hotel con tu nombre y reserva–.
La conclusión es que los atacantes pueden fabricar, por decirlo de alguna forma, la memoria RAM liberada y colocar en ese punto exacto instrucciones maliciosas en lugar de los datos que el trabajador del hotel había apuntado; es decir, que alguien podría acceder a ese papel sin que el mismo se enterara y poner algo parecido a "se busca por la policía", "ha consumido del minibar de su habitación", etc.
Hay hasta 5 cadenas de ataque que pueden explotar estas vulnerabilidades
Al mismo tiempo que el hacker ético ha compartido esta demostración, también ha publicado otro tipo de laboratorios en los que se pueden apreciar hasta 5 vectores de ataque bastante diferenciados y que, lógicamente, pueden aprovechar los ciberdelincuentes.
El más peligroso de estos es la Cadena D, ya que no requiere que una aplicación web contenga ningún fallo de programación previo y se basa en un desbordamiento de memoria por falta de recursos (OOM) en el motor Zend Engine durante el proceso de decodificación HTTP. Recuerda que estos paquetes, en el laboratorio mostrado, ya aparecían infectados para mandar instrucciones falsas al servidor para engañarlo.
Aquí el manejador de archivos de PHP ejecuta esto antes que el propio código PHP de la página web, por lo que el ataque se completa incluso sobre páginas totalmente estáticas o sencillos mediante un simple comando.
A día de hoy, por supuesto, tampoco hay que ser alarmistas y al parecer se soluciona con los parches actualizados, pero hay un grave peligro: muchos servidores pertenecen a equipos que ni siquiera saben que mantienen este tipo de estructuras, por lo que es más que probable que los ataques e infecciones acaben llegando a muchos de estos e implicando a numerosos servicios de la web.