PHP infiltrado con malware de backdoor

El servidor del lenguaje de programación de aplicaciones web se vio comprometido el domingo.

El proyecto PHP anunció el domingo que los atacantes pudieron obtener acceso a su servidor Git principal, cargando dos confirmaciones maliciosas, incluida una puerta trasera. Fueron descubiertos antes de que entraran en producción.

PHP es un lenguaje de programación de código abierto ampliamente utilizado para el desarrollo web. Se puede incrustar en HTML. Las confirmaciones se enviaron al repositorio php-src, ofreciendo así a los atacantes una oportunidad en la cadena de suministro de infectar sitios web que detectan el código malicioso creyendo que es legítimo.

Ambas confirmaciones afirmaron «corregir un error tipográfico» en el código fuente. Se cargaron con los nombres de los mantenedores de PHP, Rasmus Lerdorf y Nikita Popov, según un mensaje enviado por Popov a la lista de correo del proyecto el domingo. Añadió que no creía que fuera un simple caso de robo de credenciales.

“Aún no sabemos exactamente cómo sucedió esto, pero todo apunta a un compromiso del servidor git.php.net (en lugar de un compromiso de una cuenta individual de git)”, explicó.

En respuesta al hack, PHP está moviendo sus servidores a GitHub, haciéndolos canónicos.

“Si bien la investigación aún está en curso, hemos decidido que mantener nuestra propia infraestructura git es un riesgo de seguridad innecesario, y que descontinuaremos el servidor git.php.net”, explicó Popov. “En cambio, los repositorios en GitHub, que antes eran solo espejos, se volverán canónicos. Esto significa que los cambios deben enviarse directamente a GitHub en lugar de a git.php.net … Este cambio también significa que ahora es posible fusionar solicitudes de extracción directamente desde la interfaz web de GitHub «.

También señaló que PHP está revisando todos sus repositorios en busca de daños más allá de las dos confirmaciones que se encontraron.

«Tenemos suerte de que las confirmaciones maliciosas se hayan detectado antes de llegar a los sistemas de producción», dijo Craig Young, investigador principal de seguridad de Tripwire, por correo electrónico. “Si no se hubiera detectado, el código podría haber envenenado en última instancia los repositorios de paquetes binarios en los que innumerables organizaciones confían y confían. Los proyectos de código abierto que alojan automáticamente sus repositorios de código pueden tener un mayor riesgo de sufrir este tipo de ataque a la cadena de suministro y deben contar con procesos sólidos para detectar y rechazar confirmaciones sospechosas».