Ciberseguridad

Un cebo de 2.000 dólares en bitcoin cayó en 19 horas ante el fallo PHP2Shell

Adrian Kessler
Añádenos en Google

Un servidor con una copia de PHP sin actualizar, expuesto en internet con la clave de un monedero de bitcoin como señuelo, no duró ni un día. Un investigador que usa el alias KillaBoi accedió a través de PHP2Shell, el par de vulnerabilidades críticas del lenguaje que está detrás de la mayor parte de la web, y extrajo la clave. Ese mismo fin de semana, un honeypot gestionado por el responsable de seguridad de Perplexity registró a un atacante haciendo lo mismo en un servidor real, lo que desmonta la cómoda teoría de que estos fallos eran demasiado complicados para aprovecharlos.

Esto importa a cualquiera que tenga una página web y a cualquiera cuyos datos estén en una. PHP está en la base de WordPress, Drupal, Joomla y la mayoría de los servicios de alojamiento compartido, y estos fallos pueden permitir que alguien sin cuenta ejecute comandos en el servidor. Desde que se publicaron las correcciones, el principal argumento para esperar ha sido que los intentos de ataque conocidos no habían tenido éxito. Los dos casos echan por tierra ese argumento.

El reto, llamado Steal My Bitcoin, se publicó en una web propia y se anunció en una entrada de un foro. Su creador, que firmaba como cloudlandsdev, escribió: «He montado esto porque tengo curiosidad por saber si alguien ha descubierto cómo aprovechar realmente esta ejecución remota de código (RCE) en PHP; llevamos los últimos días entrando en pánico. ¡Que os divirtáis!». El bote empezó en unos 502 dólares y fue creciendo con las donaciones hasta alcanzar los 0,02511679 BTC, valorados en 2.021,22 dólares cuando alguien se hizo con él, unas 19 horas después del lanzamiento, según Tom’s Hardware. El servidor se vino abajo por el tráfico de quienes lo intentaban y, debido a la capacidad de almacenamiento limitada, no pudo conservar todos los registros.

Después, KillaBoi publicó en GitHub una prueba de concepto. Mark Maunder, fundador de la empresa de seguridad para WordPress Wordfence, calificó el análisis de «la mejor explicación que vais a encontrar sobre lo difícil que es explotar #php2shell», y destacó la precisión que exigía el ataque. Pero, como se ha visto, difícil no quería decir lento.

El resultado más preocupante llegó de fuera del reto. Adel Karimi, responsable de detección y respuesta en Perplexity, afirmó que sus honeypots habían detectado una ejecución remota de código confirmada contra un servidor Apache con PHP 8.4.26. «Esto ya es una RCE confirmada con una filtración de memoria aprovechable, no solo un fallo seguido de un proceso sospechoso», escribió, según informó BleepingComputer. Marcus Hutchins, investigador de amenazas de Expel, que había estado siguiendo las afirmaciones sobre ataques exitosos, lo calificó como «con diferencia, la confirmación de mayor calidad de una explotación de php2shell en la vida real que he visto hasta ahora». Hasta entonces, Cloudflare, watchTowr, Patchstack y otras empresas de seguridad solo habían registrado intentos fallidos, y el equipo de inteligencia sobre amenazas de Amazon había detectado el inicio del escaneo cuatro días antes de que se publicaran los parches.

Ninguno de los dos casos significa que todos los servidores sin actualizar vayan a caer mañana. La clave recuperada por KillaBoi no coincidía con la dirección del monedero anunciada en la web; el organizador lo atribuyó a un error de configuración y dijo que transferiría los fondos, según Cointelegraph, y el sitio de seguridad Cyberpress señala que las pruebas públicas muestran que se recuperó una clave, no que se robara el premio. El exploit publicado también está ajustado a una compilación concreta de PHP y falla con otras compilaciones de la misma versión, así que no es una herramienta que cualquiera pueda usar con un clic. Lo que ya no se sostiene es la defensa de que nadie ha conseguido hacerlo funcionar.

El problema afecta a todo el mundo. Agencias gubernamentales de Países Bajos, Australia, Japón y Finlandia desconectaron páginas web críticas mientras se preparaban los parches, informó Cointelegraph. Un recuento de Shodan realizado por la empresa de seguridad Mallory encontró unos 884.000 equipos expuestos a internet que anunciaban una versión de PHP que ya no recibe correcciones oficiales: el 59 % de los cerca de 1,5 millones que revelan una versión, según Notebookcheck. Son recuentos basados en los avisos de versión, no víctimas confirmadas, porque las distribuciones de Linux suelen aplicar parches a paquetes antiguos sin cambiar el número de versión.

Para quienes gestionan sitios web, la solución no ha cambiado. Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, publicadas el 21 de octubre para CVE-2026-109618 y CVE-2026-109619, ambas con una puntuación de 9,2 sobre 10. En los servicios de alojamiento compartido, la actualización depende del proveedor, no de una actualización de WordPress o de un plugin, así que la pregunta útil es qué compilación de PHP utiliza tu web y cuándo se instaló el parche. La agencia estadounidense de ciberseguridad CISA ha indicado a las organizaciones que no puedan actualizar, o que todavía utilicen PHP 8.1 o anterior, que desconecten esos sistemas hasta que puedan hacerlo.

El siguiente problema ya está sobre la mesa. El viernes, el equipo de PHP publicó una solución provisional para un tercer fallo de ejecución remota de código, CVE-2026-115560, que todavía no tiene parche y solo afecta a sistemas «con una combinación inusual de configuración y código de aplicación». Hasta que se publique una corrección, los desarrolladores de PHP recomiendan desactivar el ajuste session.upload_progress, la misma medida que aconsejaron antes de los parches para PHP2Shell. El soporte de seguridad para PHP 8.2 termina el 31 de diciembre de 2026, y los servidores que nunca dejaron la versión 8.1 ya han superado su fecha límite.

Etiquetas: , , , , ,

Añádenos en Google

Debate

Hay 0 comentarios.