Foram publicados os primeiros resultados da análise de um incidente relacionado à identificação de dois commits maliciosos no repositório Git de um projeto PHP com um backdoor ativado ao enviar uma solicitação com um cabeçalho de User Agent especialmente projetado. Ao estudar os vestígios das atividades dos invasores, concluiu-se que o próprio servidor git.php.net, onde estava localizado o repositório git, não foi hackeado, mas o banco de dados com as contas dos desenvolvedores do projeto foi comprometido .
É possível que os invasores tenham conseguido baixar o banco de dados do usuário armazenado no SGBD no servidor master.php.net. O conteúdo do master.php.net já foi migrado para o novo servidor main.php.net instalado do zero. Todas as senhas de desenvolvedor utilizadas para acessar a infraestrutura do php.net foram redefinidas e o processo de alteração das mesmas foi iniciado por meio de um formulário especial de recuperação de senha. Os repositórios git.php.net e svn.php.net permanecem somente leitura (o desenvolvimento foi movido para o GitHub).
Após a descoberta do primeiro commit malicioso feito através da conta de Rasmus Lerdorf, o fundador do PHP, presumiu-se que sua conta havia sido hackeada e Nikita Popov, um dos principais desenvolvedores de PHP, reverteu as alterações e bloqueou os direitos de commit para a conta problemática. Depois de algum tempo, percebeu-se que o bloqueio não fazia sentido, pois sem a verificação dos commits por meio de assinatura digital, qualquer participante com acesso ao repositório php-src poderia fazer uma alteração substituindo um nome de autor fictício.
Em seguida, os invasores enviaram um commit malicioso em nome do próprio Nikita. Ao analisar os logs do serviço gitolite, utilizado para organizar o acesso aos repositórios, procurou-se determinar o participante que efetivamente realizou as alterações. Apesar da inclusão da contabilização de todos os commits, não houve entradas no log para duas alterações maliciosas. Ficou claro que houve um comprometimento da infraestrutura, já que os commits foram adicionados diretamente, contornando a conexão via gitolite.
O servidor git.php.net foi imediatamente desativado e o repositório primário foi transferido para o GitHub. Às pressas, esqueceu-se que para acessar o repositório, além do SSH usando o gitolite, havia outra entrada que permitia o envio de commits via HTTPS. Neste caso, o backend git-http foi utilizado para interagir com o Git, e a autenticação foi realizada através do servidor HTTP Apache2, que verificou as credenciais acessando o banco de dados hospedado no SGBD no servidor master.php.net. O login foi permitido não apenas com chaves, mas também com uma senha normal. A análise dos logs do servidor http confirmou que alterações maliciosas foram adicionadas via HTTPS.
Ao estudar os logs, foi revelado que os invasores não se conectaram na primeira vez, mas inicialmente tentaram encontrar o nome da conta, mas após identificá-lo, efetuaram login na primeira tentativa, ou seja, eles sabiam as senhas de Rasmus e Nikita com antecedência, mas não sabiam seus logins. Se os invasores conseguiram obter acesso ao SGBD, não está claro por que eles não usaram imediatamente o login correto especificado lá. Esta discrepância ainda não recebeu uma explicação confiável. O hack do master.php.net é considerado o cenário mais provável, já que este servidor utilizava código muito antigo e um sistema operacional desatualizado, que não era atualizado há muito tempo e apresentava vulnerabilidades não corrigidas.
As ações realizadas incluem a reinstalação do ambiente do servidor master.php.net e a transferência de scripts para a nova versão do PHP 8. O código para trabalhar com o SGBD foi modificado para utilizar consultas parametrizadas que dificultam a substituição do código SQL. O algoritmo bcrypt é usado para armazenar hashes de senha no banco de dados (anteriormente, as senhas eram armazenadas usando um hash MD5 não confiável). As senhas existentes serão redefinidas e você será solicitado a definir uma nova senha por meio do formulário de recuperação de senha. Como o acesso aos repositórios git.php.net e svn.php.net via HTTPS estava vinculado a hashes MD5, decidiu-se deixar git.php.net e svn.php.net em modo somente leitura, e também mover todos restantes para os repositórios de extensão PECL no GitHub, semelhantes ao repositório PHP principal.
Fonte: opennet.ru