Sono stati pubblicati i primi risultati dell'analisi di un incidente relativo all'identificazione di due commit dannosi nel repository Git di un progetto PHP con una backdoor attivata all'invio di una richiesta con un header User Agent appositamente progettato. Durante lo studio delle tracce delle attività degli aggressori, si è concluso che il server git.php.net stesso, su cui si trovava il repository git, non è stato violato, ma il database con gli account degli sviluppatori del progetto è stato compromesso .
È possibile che gli aggressori siano riusciti a scaricare sul server master.php.net la banca dati degli utenti memorizzata nel DBMS. I contenuti di master.php.net sono già stati migrati sul nuovo server main.php.net installato da zero. Tutte le password degli sviluppatori utilizzate per accedere all'infrastruttura php.net sono state reimpostate ed è stato avviato il processo di modifica delle stesse tramite un apposito modulo di recupero password. I repository git.php.net e svn.php.net rimangono di sola lettura (lo sviluppo è stato spostato su GitHub).
Dopo la scoperta del primo commit dannoso effettuato tramite l'account di Rasmus Lerdorf, il fondatore di PHP, si presumeva che il suo account fosse stato violato e Nikita Popov, uno dei principali sviluppatori PHP, ha annullato le modifiche e bloccato i diritti di commit per il conto problematico. Dopo qualche tempo si è capito che il blocco non aveva senso, poiché senza la verifica dei commit tramite firma digitale, qualsiasi partecipante con accesso al repository php-src poteva apportare una modifica sostituendo un nome di autore fittizio.
Successivamente gli aggressori hanno inviato un commit dannoso per conto dello stesso Nikita. Analizzando i log del servizio gitolite, utilizzati per organizzare l'accesso ai repository, si è cercato di determinare chi ha effettivamente apportato le modifiche. Nonostante l'inclusione della contabilità per tutti i commit, nel registro non erano presenti voci per due modifiche dannose. È diventato chiaro che c'era una compromissione dell'infrastruttura, poiché i commit venivano aggiunti direttamente, bypassando la connessione tramite gitolite.
Il server git.php.net è stato prontamente disabilitato e il repository primario è stato trasferito su GitHub. In fretta si è dimenticato che per accedere al repository, oltre a SSH tramite gitolite, c'era un altro input che permetteva di inviare commit tramite HTTPS. In questo caso, è stato utilizzato il backend git-http per interagire con Git e l'autenticazione è stata eseguita utilizzando il server HTTP Apache2, che ha verificato le credenziali accedendo al database ospitato nel DBMS sul server master.php.net. L'accesso era consentito non solo con le chiavi, ma anche con una password normale. L'analisi dei log del server http ha confermato che sono state aggiunte modifiche dannose tramite HTTPS.
Dall'analisi dei registri è emerso che gli aggressori non si sono collegati la prima volta, ma inizialmente hanno cercato di trovare il nome dell'account, ma dopo averlo identificato hanno effettuato l'accesso al primo tentativo, ad es. conoscevano in anticipo le password di Rasmus e Nikita, ma non conoscevano i loro accessi. Se gli aggressori sono riusciti ad accedere al DBMS, non è chiaro il motivo per cui non hanno utilizzato immediatamente il login corretto ivi indicato. Questa discrepanza non ha ancora ricevuto una spiegazione affidabile. L'hacking di master.php.net è considerato lo scenario più probabile, poiché questo server utilizzava codice molto vecchio e un sistema operativo obsoleto, che non veniva aggiornato da molto tempo e presentava vulnerabilità senza patch.
Le azioni intraprese includono la reinstallazione dell'ambiente server master.php.net e il trasferimento degli script alla nuova versione di PHP 8. Il codice per lavorare con il DBMS è stato modificato per utilizzare query parametrizzate che complicano la sostituzione del codice SQL. L'algoritmo bcrypt viene utilizzato per archiviare gli hash delle password nel database (in precedenza, le password venivano archiviate utilizzando un hash MD5 inaffidabile). Le password esistenti vengono reimpostate e ti viene richiesto di impostare una nuova password tramite il modulo di recupero password. Poiché l'accesso ai repository git.php.net e svn.php.net tramite HTTPS era legato agli hash MD5, si è deciso di lasciare git.php.net e svn.php.net in modalità di sola lettura e spostare anche tutti i restanti ai repository di estensione PECL su GitHub, simili al repository PHP principale.
Fonte: opennet.ru