Sono stati pubblicati i primi risultati dell'analisi dell'incidente relativo alla rilevazione di due commit malevoli con un backdoor nel repository Git del progetto PHP, attivabile tramite una richiesta con un'intestazione User Agent appositamente formattata. Durante lo studio delle tracce delle attività degli aggressori è stato concluso che il server git.php.net, su cui era ospitato il repository git, non è stato compromesso, ma il database contenente gli account degli sviluppatori del progetto è stato compromesso.
Non si esclude che i criminali informatici siano riusciti a scaricare il database degli utenti, conservato nel DBMS sul server master.php.net. Il contenuto di master.php.net è stato già trasferito su un nuovo server main.php.net, installato da zero. Tutte le password degli sviluppatori utilizzate per accedere all'infrastruttura php.net sono state reimpostate e è stato avviato il processo di cambio tramite un apposito modulo di recupero della password. I repository git.php.net e svn.php.net rimangono accessibili in modalità sola lettura (lo sviluppo è stato trasferito su GitHub).
Dopo la scoperta del primo commit malevolo, effettuato tramite l'account di Rasmus Lerdorf, fondatore di PHP, è stata avanzata l'ipotesi che il suo account fosse stato violato e che Nikita Popov, uno dei principali sviluppatori di PHP, avesse annullato le modifiche e bloccato i diritti di commit per l'account problematico. Dopo un certo tempo, è diventato chiaro 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 cambiamenti, inserendo un nome autore falso.
Successivamente, gli aggressori hanno inviato un commit malevolo a nome dello stesso Nikita. Attraverso l'analisi dei log del servizio gitolite, utilizzato per gestire l'accesso ai repository, è stato tentato di identificare il partecipante che aveva realmente apportato le modifiche. Nonostante il monitoraggio di tutti i commit fosse attivato, non sono state trovate registrazioni per due modifiche malevole. È diventato chiaro che c'era una compromissione dell'infrastruttura, poiché i commit erano stati aggiunti direttamente, bypassando la connessione tramite gitolite.
Il server git.php.net è stato disattivato in modo operativo e il repository principale è stato trasferito su GitHub. Nella fretta è stato trascurato che per accedere al repository oltre a SSH utilizzando gitolite esisteva anche un'altra via, che consentiva di inviare commit tramite HTTPS. In questo caso, per interagire con Git è stato utilizzato il backend git-http-backend, e l'autenticazione è avvenuta tramite il server HTTP Apache2, che ha verificato le credenziali tramite una consultazione del database, situato in un DBMS su server master.php.net. L'accesso era consentito non solo tramite chiavi, ma anche con una password comune. L'analisi dei log del server HTTP ha confermato che le modifiche dannose erano state aggiunte tramite HTTPS.
Esaminando i log è stato rilevato che gli aggressori si sono connessi non al primo tentativo, ma inizialmente hanno cercato di indovinare il nome dell'account, per poi entrare al primo tentativo, cioè sapevano già le password di Rasmus e Nikita, ma non conoscevano i loro logins. Se gli aggressori sono riusciti ad accedere al DBMS, non si capisce perché non abbiano subito utilizzato il login corretto indicato. Questa incongruenza non ha ancora avuto una spiegazione attendibile. L'hacking di master.php.net è considerato come lo scenario più probabile, poiché su questo server è stato utilizzato un codice molto obsoleto e un sistema operativo datato, che non era stato aggiornato da tempo e presentava vulnerabilità non corrette.
Tra le azioni intraprese si segnala la reinstallazione dell'ambiente del server master.php.net e il passaggio degli script a una nuova versione di PHP 8. Il codice per interagire con il DBMS è stato rifatto per utilizzare query parametrizzate, rendendo più complessa l'inserimento di codice SQL. Per memorizzare gli hash delle password nel DB è stato utilizzato l'algoritmo bcrypt (in precedenza le password erano conservate utilizzando un hash MD5 non affidabile). Le password esistenti sono state azzerate e è stato consigliato 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, è stato deciso di mantenere git.php.net e svn.php.net in modalità di sola lettura e di trasferire tutti i rimanenti repository di estensioni PECL su GitHub, analogamente al repository principale di PHP.
Fonte: opennet.ru
