Rapportera om kompromissen mellan git-förvaret och användarbasen för PHP-projektet

De första resultaten av analysen av en incident relaterad till identifieringen av två skadliga åtaganden i Git-förrådet i ett PHP-projekt med en bakdörr aktiverad när en förfrågan skickas med en specialdesignad User Agent-header har publicerats. Under studien av spåren av angriparnas aktiviteter drogs slutsatsen att själva git.php.net-servern, på vilken git-förvaret fanns, inte hackades, men databasen med projektutvecklarnas konton äventyrades. .

Det är möjligt att angriparna kunde ladda ner användardatabasen lagrad i DBMS på master.php.net-servern. Innehållet i master.php.net har redan migrerats till den nya main.php.net-servern installerad från början. Alla utvecklarlösenord som användes för att komma åt php.net-infrastrukturen återställdes och processen för att ändra dem initierades genom ett speciellt lösenordsåterställningsformulär. Lagren git.php.net och svn.php.net förblir skrivskyddade (utvecklingen har flyttats till GitHub).

Efter upptäckten av den första skadliga commit som gjordes genom kontot av Rasmus Lerdorf, grundaren av PHP, antogs det att hans konto hade blivit hackat och Nikita Popov, en av de viktigaste PHP-utvecklarna, rullade tillbaka ändringarna och blockerade commit-rättigheter för det problematiska kontot. Efter en tid kom insikten att blockeringen inte var meningsfull, eftersom utan verifiering av åtaganden med hjälp av en digital signatur kunde vilken deltagare som helst med tillgång till php-src-förrådet göra en förändring genom att ersätta ett fiktivt författarnamn.

Därefter skickade angriparna ett skadligt åtagande på uppdrag av Nikita själv. Genom att analysera loggarna för gitolittjänsten, som används för att organisera åtkomst till arkiv, gjordes ett försök att fastställa vilken deltagare som faktiskt gjorde ändringarna. Trots införandet av redovisning för alla åtaganden, fanns det inga poster i loggen för två skadliga ändringar. Det blev tydligt att det fanns en kompromiss med infrastrukturen, eftersom commits lades till direkt, förbi anslutningen via gitolit.

Git.php.net-servern inaktiverades omedelbart och det primära arkivet överfördes till GitHub. I all hast glömdes det bort att för att komma åt förvaret, förutom att SSH använder gitolit, fanns det en annan ingång som gjorde att du kunde skicka commits via HTTPS. I det här fallet användes git-http-backend för att interagera med Git, och autentisering utfördes med hjälp av Apache2 HTTP-servern, som verifierade referenser genom att komma åt databasen som var värd i DBMS på master.php.net-servern. Inloggning var tillåten inte bara med nycklar, utan också med ett vanligt lösenord. Analys av http-serverloggarna bekräftade att skadliga ändringar lades till via HTTPS.

När man studerade loggarna avslöjades att angriparna inte kopplade upp sig första gången utan först försökte hitta kontonamnet, men efter att ha identifierat det loggade de in vid första försöket, d.v.s. de kände till Rasmus och Nikitas lösenord i förväg, men kände inte till deras inloggningar. Om angriparna kunde få tillgång till DBMS är det oklart varför de inte omedelbart använde den korrekta inloggningen som anges där. Denna diskrepans har ännu inte fått någon tillförlitlig förklaring. Hacket av master.php.net anses vara det mest sannolika scenariot, eftersom denna server använde mycket gammal kod och ett föråldrat operativsystem, som inte hade uppdaterats på länge och hade opatchade sårbarheter.

Åtgärderna inkluderar ominstallation av master.php.net-servermiljön och överföring av skript till den nya versionen av PHP 8. Koden för att arbeta med DBMS har modifierats för att använda parametriserade frågor som komplicerar ersättningen av SQL-kod. Bcrypt-algoritmen används för att lagra lösenordshash i databasen (tidigare lagrades lösenord med en opålitlig MD5-hash). Befintliga lösenord återställs och du uppmanas att ange ett nytt lösenord via formuläret för lösenordsåterställning. Eftersom åtkomst till git.php.net- och svn.php.net-lagren via HTTPS var knuten till MD5-hashar, beslutades det att lämna git.php.net och svn.php.net i skrivskyddat läge, och även flytta alla återstående till dem PECL-förlängningsförråd på GitHub, liknande PHP-huvudförvaret.

Källa: opennet.ru

Lägg en kommentar