Informe sobre o compromiso do repositorio git e da base de usuarios do proxecto PHP

Publicáronse os primeiros resultados da análise dunha incidencia relacionada coa identificación de dous commits maliciosos no repositorio Git dun proxecto PHP cunha porta traseira activada ao enviar unha solicitude cunha cabeceira de Axente de Usuario especialmente deseñada. Durante o estudo dos rastros das actividades dos atacantes, chegouse á conclusión de que o propio servidor git.php.net, no que se atopaba o repositorio de git, non foi pirateado, senón que se comprometeu a base de datos coas contas dos desenvolvedores do proxecto. .

É posible que os atacantes puidesen descargar a base de datos de usuarios almacenada no DBMS no servidor master.php.net. Os contidos de master.php.net xa foron migrados ao novo servidor main.php.net instalado dende cero. Restablecéronse todos os contrasinais de programador utilizados para acceder á infraestrutura php.net e iniciouse o proceso de cambialos mediante un formulario especial de recuperación de contrasinal. Os repositorios git.php.net e svn.php.net seguen sendo de só lectura (o desenvolvemento foi movido a GitHub).

Despois do descubrimento da primeira confirmación maliciosa realizada a través da conta de Rasmus Lerdorf, o fundador de PHP, supouse que a súa conta fora pirateada e Nikita Popov, un dos principais desenvolvedores de PHP, retirou os cambios e bloqueou os dereitos de commit para a conta problemática. Despois dun tempo, deuse conta de que o bloqueo non tiña sentido, xa que sen a verificación das confirmacións mediante unha sinatura dixital, calquera participante con acceso ao repositorio php-src podería facer un cambio substituíndo un nome de autor ficticio.

A continuación, os atacantes enviaron unha comisión maliciosa en nome do propio Nikita. Ao analizar os rexistros do servizo gitolite, usado para organizar o acceso aos repositorios, intentouse determinar o participante que realmente fixo os cambios. A pesar da inclusión da contabilidade de todas as confirmacións, non houbo entradas no rexistro para dous cambios maliciosos. Quedou claro que había un compromiso da infraestrutura, xa que engadíronse commits directamente, evitando a conexión vía gitolite.

O servidor git.php.net desactivouse de inmediato e o repositorio principal foi transferido a GitHub. Con présa, esqueceuse de que para acceder ao repositorio, ademais de SSH usando gitolite, había outra entrada que permitía enviar commits a través de HTTPS. Neste caso, utilizouse o git-http-backend para interactuar con Git, e a autenticación realizouse mediante o servidor HTTP Apache2, que verificaba as credenciais accedendo á base de datos aloxada no DBMS no servidor master.php.net. Permitiuse o inicio de sesión non só con claves, senón tamén cun contrasinal normal. A análise dos rexistros do servidor http confirmou que se engadiron cambios maliciosos a través de HTTPS.

Ao estudar os rexistros, revelouse que os atacantes non se conectaron a primeira vez, senón que inicialmente intentaron atopar o nome da conta, pero despois de identificalo, iniciaron sesión no primeiro intento, é dicir. coñecían de antemán os contrasinais de Rasmus e Nikita, pero non coñecían os seus inicios de sesión. Se os atacantes puideron acceder ao DBMS, non está claro por que non usaron inmediatamente o inicio de sesión correcto especificado alí. Esta discrepancia aínda non recibiu unha explicación fiable. O pirateo de master.php.net considérase o escenario máis probable, xa que este servidor utilizaba código moi antigo e un SO obsoleto, que levaba tempo sen actualizar e tiña vulnerabilidades sen corrixir.

As accións realizadas inclúen a reinstalación do contorno do servidor master.php.net e a transferencia de scripts á nova versión de PHP 8. O código para traballar co DBMS foi modificado para utilizar consultas parametrizadas que complican a substitución do código SQL. O algoritmo bcrypt úsase para almacenar os hash de contrasinais na base de datos (anteriormente, os contrasinais gardábanse mediante un hash MD5 pouco fiable). Os contrasinais existentes restablecéronse e pídese que estableza un novo contrasinal a través do formulario de recuperación de contrasinal. Dado que o acceso aos repositorios git.php.net e svn.php.net vía HTTPS estaba ligado a hash MD5, decidiuse deixar git.php.net e svn.php.net en modo de só lectura, e tamén mover todos os restantes repositorios de extensións PECL en GitHub, semellante ao repositorio principal de PHP.

Fonte: opennet.ru

Engadir un comentario