Mantenedores de PHP culpan a la filtración de la base de datos de master.php.net

A finales del mes pasado se dio a conocer la noticia de que un hacker comprometió el servidor utilizado para distribuir el lenguaje de programación PHP y agregó un backdoor al código fuente que habría dejado a los sitios web vulnerables a una adquisición completa, dijeron miembros del proyecto de código abierto.

El problema se suscitó en dos actualizaciones enviadas al servidor PHP Git durante el fin de semana del 27 de marzo en el cual agregaron una línea que, si fuera ejecutada por un sitio web impulsado por esta versión secuestrada de PHP, habría permitido a los visitantes no autorizados ejecutar el código de su elección.

Las confirmaciones maliciosas le dieron al código la capacidad de inyectar código en los visitantes que tenían la palabra «zerodium» en un encabezado HTTP. Las confirmaciones se realizaron en el repositorio php-src bajo los nombres de cuenta de dos conocidos desarrolladores de PHP, Rasmus Lerdorf y Nikita Popov.

Tras el compromiso, Popov explicó que los funcionarios de PHP concluyeron que su infraestructura Git independiente representaba un riesgo de seguridad innecesario.

Como resultado, decidieron cerrar el servidor git.php.net y hacer de GitHub la fuente oficial de repositorios PHP. En el futuro, todos los cambios en el código fuente de PHP se realizarán directamente en GitHub en lugar de en git.php.net.

El mantenedor de PHP, Nikita Popov, lanzó una actualización sobre cómo se comprometió el código fuente y se insertó el código malicioso, culpando a una fuga de la base de datos del usuario en lugar de un problema con el servidor en sí.

El equipo originalmente creía que el servidor que alojaba el repositorio había sido asaltado, pero en una nueva publicación, Popov dijo:

“Ya no creemos que el servidor git.php.net haya sido comprometido. Sin embargo, es posible que se haya filtrado la base de datos del usuario master.php.net ”. Además, master.php.net se ha migrado a un nuevo sistema main.php.net.

Aquí hay detalles que Popov dio sobre el progreso de la investigación:

“Cuando se realizó la primera confirmación maliciosa bajo el nombre de Rasmus, mi reacción inicial fue revertir el cambio y revocar el acceso a la confirmación de la cuenta de Rasmus, asumiendo que era un individuo hack de cuenta. En retrospectiva, esta acción realmente no tenía sentido, porque noEl empujón estaba sucediendo a través de la cuenta de Rasmus en particular. Cualquier cuenta con acceso al repositorio php-src podría haber realizado el envío con un nombre falso.

“Cuando se realizó la segunda confirmación maliciosa bajo mi propio nombre, miré los registros de nuestra instalación de gitolite para determinar qué cuenta se estaba utilizando realmente para enviar . Sin embargo, aunque se tuvieron en cuenta todas las confirmaciones adyacentes, no había entradas git-receive-pack para las dos confirmaciones maliciosas, lo que significa que estas dos confirmaciones omitieron por completo la infraestructura de gitolite. Esto se interpretó como prueba probable de un compromiso del servidor.

Las acciones que se han tomado ahora incluyen restablecer todas las contraseñas y modificar el código para usar consultas parametrizadas para protegerse contra ataques de inyección SQL.

El uso de consultas parametrizadas ha sido la mejor práctica recomendada durante muchos años, y el hecho de que el código que no se ha estado ejecutando durante tanto tiempo en el corazón de la infraestructura del código fuente de PHP muestra cuán inseguro es el código heredado en una organización si está funcionando y no está causando problemas obvios.

El sistema master.php.net, que se utiliza para la autenticación y varias tareas de administración, estaba ejecutando un código muy antiguo en un sistema operativo/versión PHP muy antiguo, por lo que algún tipo de vulnerabilidad no sería muy sorprendente. Los encargados del mantenimiento han realizado una serie de cambios para aumentar la seguridad de este sistema:

• master.php.net se ha migrado a un nuevo sistema (que ejecuta PHP 8) y se ha cambiado el nombre de main.php.net al mismo tiempo. Entre otras cosas, el nuevo sistema es compatible con TLS 1.2, lo que significa que ya no debería ver las advertencias de la versión TLS al acceder a este sitio.
• La implementación se ha trasladado al uso de consultas parametrizadas, para asegurarse de que no se puedan producir inyecciones de SQL.
• Las contraseñas ahora se almacenan usando bcrypt.
• Las contraseñas existentes se han restablecido (use main.php.net/forgot.php para generar una nueva).

Fuente: https://externals.io