Se han publicado los primeros resultados del análisis de un incidente relacionado con la identificación de dos commits maliciosos en el repositorio Git de un proyecto PHP con una puerta trasera activada al enviar una solicitud con un encabezado User Agent especialmente diseñado. Durante el estudio de los rastros de las actividades de los atacantes, se concluyó que el servidor git.php.net en sí, en el que se encontraba el repositorio git, no fue pirateado, pero la base de datos con las cuentas de los desarrolladores del proyecto estaba comprometida. .
Es posible que los atacantes pudieran descargar la base de datos del usuario almacenada en el DBMS en el servidor master.php.net. El contenido de master.php.net ya se ha migrado al nuevo servidor main.php.net instalado desde cero. Todas las contraseñas de desarrollador utilizadas para acceder a la infraestructura de php.net se restablecieron y el proceso de cambio se inició a través de un formulario especial de recuperación de contraseña. Los repositorios git.php.net y svn.php.net siguen siendo de solo lectura (el desarrollo se ha trasladado a GitHub).
Después del descubrimiento de la primera confirmación maliciosa realizada a través de la cuenta de Rasmus Lerdorf, el fundador de PHP, se asumió que su cuenta había sido pirateada y Nikita Popov, uno de los desarrolladores clave de PHP, revirtió los cambios y bloqueó los derechos de confirmación para La cuenta problemática. Después de un tiempo, me di cuenta de que el bloqueo no tenía sentido, ya que sin la verificación de las confirmaciones mediante una firma digital, cualquier participante con acceso al repositorio php-src podría realizar un cambio sustituyendo un nombre de autor ficticio.
A continuación, los atacantes enviaron un compromiso malicioso en nombre del propio Nikita. Mediante el análisis de los registros del servicio gitolite, utilizado para organizar el acceso a los repositorios, se intentó determinar quién fue el participante que realmente realizó los cambios. A pesar de la inclusión de la contabilidad de todas las confirmaciones, no hubo entradas en el registro de dos cambios maliciosos. Quedó claro que había un compromiso de la infraestructura, ya que las confirmaciones se agregaron directamente, sin pasar por la conexión a través de gitolite.
El servidor git.php.net se deshabilitó rápidamente y el repositorio principal se transfirió a GitHub. De prisa, se olvidó que para acceder al repositorio, además de SSH usando gitolite, existía otra entrada que permitía enviar commits vía HTTPS. En este caso, se utilizó el backend git-http para interactuar con Git y la autenticación se realizó utilizando el servidor HTTP Apache2, que verificó las credenciales accediendo a la base de datos alojada en el DBMS en el servidor master.php.net. Se permitió iniciar sesión no solo con claves, sino también con una contraseña normal. El análisis de los registros del servidor http confirmó que se agregaron cambios maliciosos a través de HTTPS.
Al estudiar los registros, se reveló que los atacantes no se conectaron la primera vez, sino que inicialmente intentaron encontrar el nombre de la cuenta, pero después de identificarlo, iniciaron sesión en el primer intento, es decir. conocían de antemano las contraseñas de Rasmus y Nikita, pero no conocían sus inicios de sesión. Si los atacantes lograron acceder al DBMS, no está claro por qué no utilizaron inmediatamente el inicio de sesión correcto especificado allí. Esta discrepancia aún no ha recibido una explicación confiable. El hackeo de master.php.net se considera el escenario más probable, ya que este servidor utilizaba un código muy antiguo y un sistema operativo obsoleto, que no se había actualizado durante mucho tiempo y tenía vulnerabilidades sin parchear.
Las acciones tomadas incluyen la reinstalación del entorno del servidor master.php.net y la transferencia de scripts a la nueva versión de PHP 8. El código para trabajar con el DBMS se ha modificado para utilizar consultas parametrizadas que complican la sustitución del código SQL. El algoritmo bcrypt se utiliza para almacenar hash de contraseñas en la base de datos (anteriormente, las contraseñas se almacenaban utilizando un hash MD5 no confiable). Las contraseñas existentes se restablecen y se le solicita que establezca una nueva contraseña a través del formulario de recuperación de contraseña. Dado que el acceso a los repositorios git.php.net y svn.php.net a través de HTTPS estaba vinculado a hashes MD5, se decidió dejar git.php.net y svn.php.net en modo de solo lectura y también mover todos los restantes a los repositorios de extensiones PECL en GitHub, similar al repositorio principal de PHP.
Fuente: opennet.ru