Se han publicado los primeros resultados del análisis del incidente relacionado con la detección de dos commits maliciosos con un backdoor en el repositorio Git del proyecto PHP, que se activaban al enviar una solicitud con un encabezado User Agent especialmente diseñado. Durante el examen de los rastros de la actividad de los atacantes, se concluyó que el servidor git.php.net, donde se alojaba el repositorio git, no fue hackeado, pero se comprometió la base de datos con las cuentas de los desarrolladores del proyecto.
No se descarta que los delincuentes hayan podido descargar la base de usuarios almacenada en la base de datos en el servidor master.php.net. El contenido de master.php.net ya ha sido trasladado a un nuevo servidor main.php.net, instalado desde cero. Todas las contraseñas de los desarrolladores que se utilizaron para acceder a la infraestructura de php.net han sido restablecidas y se ha iniciado el proceso de cambio a través de un formulario especial de recuperación de contraseña. Los repositorios git.php.net y svn.php.net permanecen accesibles en modo de solo lectura (el desarrollo ha sido trasladado a GitHub).
Después de descubrir el primer commit malicioso, realizado a través de la cuenta de Rasmus Lerdorf, el fundador de PHP, se supuso que su cuenta había sido hackeada y que Nikita Popov, uno de los desarrolladores clave de PHP, había revertido los cambios y bloqueado los derechos de commit para la cuenta problemática. Después de un tiempo, se llegó a la conclusión de que el bloqueo no tenía sentido, ya que sin la verificación de los commits mediante firma digital, cualquier participante con acceso al repositorio php-src podía realizar cambios, sustituyendo un nombre de autor ficticio.
Luego, los atacantes enviaron un commit malicioso en nombre del mismo Nikita. A través del análisis de los registros del servicio gitolite, utilizado para organizar el acceso a los repositorios, se intentó determinar quién realmente realizó los cambios. A pesar de tener habilitado el registro de todos los commits, no había registros de los dos cambios maliciosos en el log. Quedó claro que había una compromiso de la infraestructura, ya que los commits se añadieron directamente, eludiendo la conexión a través de gitolite.
El servidor git.php.net fue desconectado de manera rápida, y el repositorio principal fue trasladado a GitHub. En la prisa, se pasó por alto que para acceder al repositorio, además de SSH utilizando gitolite, había otra entrada que permitía enviar commits a través de HTTPS. En este caso, se utilizó el backend git-http-backend para interactuar con Git, y la autenticación fue llevada a cabo mediante el servidor HTTP Apache2, que verificaba las credenciales a través de una base de datos alojada en el SGBD en servidor master.php.net. Se permitía la entrada no solo mediante claves, sino también a través de una contraseña común. El análisis de los registros del servidor http confirmó que los cambios maliciosos fueron añadidos a través de HTTPS.
Al estudiar los registros, se descubrió que los atacantes se conectaron no a la primera, sino que inicialmente intentaron adivinar el nombre de la cuenta, pero después de identificarlo, entraron a la primera. Es decir, ya conocían las contraseñas de Rasmus y Nikita, pero no conocían sus nombres de usuario. Si los atacantes lograron acceder al SGBD, no está claro por qué no utilizaron inmediatamente el nombre de usuario correcto indicado allí. Esta incongruencia aún no tiene una explicación confiable. El hackeo de master.php.net se considera el escenario más probable, dado que en este servidor se utilizó un código muy antiguo y un sistema operativo desactualizado que no había sido actualizado durante mucho tiempo y contenía vulnerabilidades no corregidas.
De las acciones emprendidas, se destaca la reinstalación del entorno del servidor master.php.net y la actualización de los scripts a una nueva versión de PHP 8. El código para interactuar con el SGBD ha sido reescrito para usar consultas parametrizadas, dificultando la inyección de código SQL. Para almacenar los hashes de las contraseñas en la base de datos, se ha empleado el algoritmo bcrypt (anteriormente, las contraseñas se almacenaban utilizando el hash MD5 poco fiable). Las contraseñas existentes han sido restablecidas y se ha propuesto establecer 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 los hashes MD5, se decidió mantener git.php.net y svn.php.net en modo de solo lectura, así como trasladar todos los repositorios restantes de extensiones PECL a GitHub, similar al repositorio principal de PHP.
Fuente: opennet.ru
