Megjelentek az els\u0151 eredm\u00e9nyek a PHP projekt Git-t\u00e1rol\u00f3j\u00e1ban \u00e9szlelt k\u00e9t h\u00e1ts\u00f3 ajt\u00f3val rendelkez\u0151 rosszindulat\u00fa commit elemz\u00e9s\u00e9b\u0151l, amelyeket a User Agent k\u00fcl\u00f6nleges fejl\u00e9cekkel ell\u00e1tott k\u00e9r\u00e9s\u00e9nek elk\u00fcld\u00e9sekor aktiv\u00e1ltak. A t\u00e1mad\u00f3k tev\u00e9kenys\u00e9g\u00e9nek nyomoz\u00e1sa sor\u00e1n arra a k\u00f6vetkeztet\u00e9sre jutottak, hogy a git.php.net szerver, ahol a git-t\u00e1rol\u00f3 tal\u00e1lhat\u00f3, nem volt felt\u00f6rve, de a fejleszt\u0151k fi\u00f3kjait tartalmaz\u00f3 adatb\u00e1zis kompromitt\u00e1l\u00f3dott. <\/p>\n
Nem z\u00e1rhat\u00f3 ki, hogy a b\u0171n\u00f6z\u0151k sikeresen let\u00f6lt\u00f6tt\u00e9k a felhaszn\u00e1l\u00f3i adatb\u00e1zist, amely a master.php.net szerveren t\u00e1rol\u00f3dott. A master.php.net tartalm\u00e1t m\u00e1r \u00e1ttelep\u00edtett\u00e9k az \u00faj, null\u00e1r\u00f3l telep\u00edtett main.php.net szerverre. Minden fejleszt\u0151i jelsz\u00f3t, amelyet a php.net infrastrukt\u00far\u00e1hoz val\u00f3 hozz\u00e1f\u00e9r\u00e9shez haszn\u00e1ltak, null\u00e1zni kellett, \u00e9s elindult a jelsz\u00f3-vissza\u00e1ll\u00edt\u00f3 \u0171rlapon kereszt\u00fcli megv\u00e1ltoztat\u00e1s folyamat\u00e1nak kezdem\u00e9nyez\u00e9se. A git.php.net \u00e9s az svn.php.net t\u00e1rol\u00f3k tov\u00e1bbra is csak olvas\u00e1si m\u00f3dban el\u00e9rhet\u0151k (a fejleszt\u00e9s GitHub-ra ker\u00fclt \u00e1t). <\/p>\n
Az els\u0151 rosszindulat\u00fa commit felfedez\u00e9se ut\u00e1n, amelyet Rasmus Lerdorf, a PHP alap\u00edt\u00f3ja nev\u00e9ben hajtottak v\u00e9gre, felt\u00e9telezt\u00e9k, hogy a fi\u00f3kj\u00e1t felt\u00f6rt\u00e9k, \u00e9s Nikita Popov, a PHP egyik kulcsfejleszt\u0151je, vissza\u00e1ll\u00edtotta a v\u00e1ltoztat\u00e1sokat, \u00e9s letiltotta a probl\u00e9m\u00e1s fi\u00f3k commit jogait. Egy id\u0151 ut\u00e1n azonban tudatosult, hogy a letilt\u00e1snak nem volt \u00e9rtelme, mivel digit\u00e1lis al\u00e1\u00edr\u00e1s szerinti commit-ellen\u0151rz\u00e9s n\u00e9lk\u00fcl b\u00e1rki, akinek hozz\u00e1f\u00e9r\u00e9se volt a php-src t\u00e1rol\u00f3hoz, v\u00e9gezhetett v\u00e1ltoztat\u00e1sokat, hamis szerz\u0151i nevet megadva. <\/p>\n
Ezut\u00e1n a t\u00e1mad\u00f3k rosszindulat\u00fa commitot k\u00fcldtek Nikita nev\u00e9ben. A gitolite napl\u00f3j\u00e1nak elemz\u00e9se, amelyet a t\u00e1rol\u00f3k hozz\u00e1f\u00e9r\u00e9s\u00e9nek megszervez\u00e9s\u00e9re haszn\u00e1lnak, megk\u00eds\u00e9relte azonos\u00edtani azt a r\u00e9sztvev\u0151t, aki val\u00f3ban v\u00e9grehajtotta a v\u00e1ltoztat\u00e1sokat. Annak ellen\u00e9re, hogy minden commit nyilv\u00e1ntart\u00e1sba volt v\u00e9ve, a k\u00e9t rosszindulat\u00fa m\u00f3dos\u00edt\u00e1sr\u00f3l nem voltak bejegyz\u00e9sek a napl\u00f3ban. Nyilv\u00e1nval\u00f3v\u00e1 v\u00e1lt, hogy az infrastrukt\u00fara kompromitt\u00e1l\u00f3dott, mivel a commitok k\u00f6zvetlen\u00fcl, a gitolite-on kereszt\u00fcli hozz\u00e1f\u00e9r\u00e9s megker\u00fcl\u00e9s\u00e9vel lettek hozz\u00e1adva. <\/p>\n
A git.php.net server was promptly taken offline, and the primary repository was moved to GitHub. In the rush, it was overlooked that there was an alternative access method to the repository, allowing commits to be sent via HTTPS in addition to SSH using gitolite. In this case, the git-http-backend was used for interaction with Git, and authentication was handled via the Apache2 HTTP server, which verified credentials by querying the database hosted in the DBMS on szerveren<\/a> master.php.net. Access was allowed not only through keys but also via a regular password. The analysis of the HTTP server logs confirmed that malicious changes were introduced via HTTPS. <\/p>\n Upon reviewing the logs, it was revealed that the attackers did not connect on the first attempt; initially, they tried to guess the account name but successfully entered on the first try after determining it, meaning they already knew the passwords of Rasmus and Nikita, but not their usernames. If the attackers managed to gain access to the DBMS, it is unclear why they did not immediately use the valid login indicated there. This discrepancy has not yet received a reliable explanation. The compromise of master.php.net is considered the most likely scenario, as this server szerveren<\/a> was running very old code and an outdated OS that had long been unmaintained and had unresolved vulnerabilities. <\/p>\n