Ciberseguridad

Un hacker abrió con PHP2Shell un servidor con 2,000 dólares en bitcoin en 19 horas

Adrian Kessler
Añádenos en Google

Un servidor con una copia de PHP sin actualizar y conectado a internet, con la clave de una billetera de bitcoin en su interior como señuelo, no duró ni un día. Un investigador que usa el alias KillaBoi logró entrar mediante 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 administrado por el responsable de seguridad de Perplexity registró a un atacante haciendo lo mismo en un servidor real, lo que deja sin sustento la cómoda teoría de que estos errores eran demasiado difíciles de aprovechar.

Esto importa tanto a quienes administran un sitio web como a quienes tienen datos almacenados en uno. PHP está detrás de WordPress, Drupal, Joomla y la mayoría de los servicios de hosting compartido; estas vulnerabilidades pueden permitir que alguien sin una cuenta ejecute comandos en el servidor. Desde que se publicaron las correcciones, el principal argumento para esperar ha sido que los intentos de ataque detectados públicamente seguían fracasando. Ambos resultados desarman ese argumento.

El desafío, llamado Steal My Bitcoin, se publicó en un sitio web propio y se anunció en una entrada de un foro. Su creador, que publicó con el nombre cloudlandsdev, escribió: «Hice esto porque me da curiosidad saber si alguien por ahí descubrió cómo usar realmente este RCE de PHP; pasamos los últimos días con el corazón en la boca. ¡Diviértanse!». El premio comenzó en unos $502 y fue creciendo con las donaciones hasta llegar a 0.02511679 BTC, equivalentes a $2,021.22 cuando alguien lo reclamó, aproximadamente 19 horas después del lanzamiento, según Tom’s Hardware. El servidor cedió ante el tráfico de quienes lo intentaban y, por falta de espacio de almacenamiento, no pudo conservar todos sus registros.

Después, KillaBoi publicó una prueba de concepto en GitHub. Mark Maunder, fundador de la empresa de seguridad para WordPress Wordfence, calificó la explicación de «la mejor explicación que verán sobre lo difícil que es explotar #php2shell», y destacó la precisión que exigía el ataque. Resulta que difícil no significaba lento.

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

Ninguno de los dos resultados significa que todos los servidores sin actualizar vayan a caer mañana. La clave recuperada por KillaBoi no coincidía con la dirección de la billetera anunciada por el sitio; el organizador lo llamó un error de configuración y dijo que transferiría los fondos, según Cointelegraph. Además, 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 específica de PHP y falla con otras compilaciones de la misma versión, así que no es una herramienta de hacer clic y listo. Lo que ya no se puede sostener es que nadie haya logrado hacerlo funcionar.

La exposición es global. Agencias gubernamentales de Países Bajos, Australia, Japón y Finlandia desconectaron sitios web críticos mientras se preparaban los parches, informó Cointelegraph. Un recuento de Shodan realizado por la empresa de seguridad Mallory encontró unos 884,000 hosts expuestos a internet que anunciaban una versión de PHP que ya no recibe correcciones oficiales: el 59% de los aproximadamente 1.5 millones que revelan esa información, según Notebookcheck. Esas cifras se basan en los banners que muestran los servidores, no en víctimas confirmadas, porque las distribuciones de Linux suelen corregir paquetes antiguos sin cambiar el número de versión.

Para los propietarios de sitios, 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 calificadas con 9.2 sobre 10. En el hosting compartido, la actualización depende del proveedor, no de una actualización de WordPress o de un complemento; por eso, lo más útil es preguntarle qué compilación de PHP ejecuta tu sitio y cuándo la corrigió. La agencia de ciberseguridad de Estados Unidos, CISA, indicó a las organizaciones que no puedan actualizar o que todavía usen PHP 8.1 o una versión 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 medida provisional para una tercera vulnerabilidad 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». Mientras se publica una corrección, los desarrolladores de PHP recomiendan desactivar la opción session.upload_progress, el mismo paso que aconsejaron antes de los parches de PHP2Shell. El soporte de seguridad para PHP 8.2 termina el 31 de diciembre de 2026, y los servidores que nunca dejaron PHP 8.1 ya superaron su fecha límite.

Etiquetas: , , , , ,

Añádenos en Google

Debate

Hay 0 comentarios.