اولین نتایج تجزیه و تحلیل یک حادثه مربوط به شناسایی دو commit مخرب در مخزن Git یک پروژه PHP با درب پشتی فعال شده هنگام ارسال درخواست با هدر User Agent ویژه طراحی شده منتشر شد. در جریان بررسی ردپای فعالیت های مهاجمان به این نتیجه رسید که خود سرور git.php.net که مخزن git در آن قرار داشت هک نشده است، اما پایگاه داده با حساب های توسعه دهندگان پروژه به خطر افتاده است. .
این احتمال وجود دارد که مهاجمان بتوانند پایگاه داده کاربر ذخیره شده در DBMS را در سرور master.php.net دانلود کنند. محتویات master.php.net قبلاً به سرور جدید main.php.net که از ابتدا نصب شده است منتقل شده است. تمام رمزهای عبور توسعه دهندگان مورد استفاده برای دسترسی به زیرساخت php.net بازنشانی شدند و فرآیند تغییر آنها از طریق فرم بازیابی رمز عبور ویژه آغاز شد. مخازن git.php.net و svn.php.net فقط خواندنی باقی می مانند (توسعه به GitHub منتقل شده است).
پس از کشف اولین کامیت مخرب انجام شده از طریق حساب راسموس لردورف، بنیانگذار PHP، فرض بر این بود که حساب کاربری وی هک شده است و نیکیتا پوپوف، یکی از توسعه دهندگان کلیدی PHP، تغییرات را لغو کرد و حقوق commit را برای آن مسدود کرد. حساب مشکل ساز پس از مدتی، متوجه شدیم که مسدود کردن منطقی نیست، زیرا بدون تأیید تعهدات با استفاده از امضای دیجیتال، هر شرکت کننده ای که به مخزن php-src دسترسی داشته باشد می تواند با جایگزین کردن یک نام نویسنده ساختگی تغییری ایجاد کند.
سپس، مهاجمان یک ارتکاب مخرب از طرف خود نیکیتا ارسال کردند. با تجزیه و تحلیل گزارش‌های سرویس gitolite، که برای سازماندهی دسترسی به مخازن استفاده می‌شود، تلاش شد تا شرکت‌کننده‌ای که واقعاً تغییرات را ایجاد کرده است، مشخص شود. با وجود گنجاندن حسابداری برای همه تعهدات، هیچ ورودی برای دو تغییر مخرب در گزارش وجود نداشت. مشخص شد که زیرساخت‌ها به خطر افتاده است، زیرا commitها مستقیماً اضافه شدند و اتصال از طریق gitolite را دور زدند.
سرور git.php.net به سرعت غیرفعال شد و مخزن اولیه به GitHub منتقل شد. با عجله فراموش شد که برای دسترسی به مخزن، علاوه بر SSH با استفاده از gitolite، ورودی دیگری نیز وجود داشت که به شما امکان ارسال commit از طریق HTTPS را می داد. در این مورد، git-http-backend برای تعامل با Git استفاده شد، و احراز هویت با استفاده از سرور HTTP Apache2 انجام شد، که اعتبار را با دسترسی به پایگاه داده میزبانی شده در DBMS در سرور master.php.net تأیید می‌کرد. ورود نه تنها با کلیدها، بلکه با یک رمز عبور معمولی نیز مجاز بود. تجزیه و تحلیل گزارش‌های سرور http تأیید کرد که تغییرات مخرب از طریق HTTPS اضافه شده است.
هنگام مطالعه لاگ ها مشخص شد که مهاجمان بار اول وصل نشدند، بلکه ابتدا سعی کردند نام حساب کاربری را پیدا کنند، اما پس از شناسایی آن، در اولین تلاش وارد سیستم شدند، یعنی. آنها رمز عبور راسموس و نیکیتا را از قبل می دانستند، اما ورود آنها را نمی دانستند. اگر مهاجمان می توانستند به DBMS دسترسی پیدا کنند، مشخص نیست که چرا بلافاصله از ورود صحیح مشخص شده در آنجا استفاده نکرده اند. این اختلاف هنوز توضیح قابل اعتمادی دریافت نکرده است. هک master.php.net محتمل‌ترین سناریو در نظر گرفته می‌شود، زیرا این سرور از کد بسیار قدیمی و سیستم‌عامل قدیمی استفاده می‌کرد که برای مدت طولانی به‌روزرسانی نشده بود و دارای آسیب‌پذیری‌های اصلاح نشده بود.
اقدامات انجام شده شامل نصب مجدد محیط سرور master.php.net و انتقال اسکریپت ها به نسخه جدید PHP 8 است. کد کار با DBMS برای استفاده از پرس و جوهای پارامتری که جایگزینی کد SQL را پیچیده می کند، اصلاح شده است. الگوریتم bcrypt برای ذخیره هش های رمز عبور در پایگاه داده استفاده می شود (پیش از این، رمزهای عبور با استفاده از هش MD5 غیر قابل اعتماد ذخیره می شدند). گذرواژه‌های موجود بازنشانی می‌شوند و از شما خواسته می‌شود یک رمز عبور جدید از طریق فرم بازیابی رمز عبور تنظیم کنید. از آنجایی که دسترسی به مخازن git.php.net و svn.php.net از طریق HTTPS به هش های MD5 گره خورده بود، تصمیم گرفته شد که git.php.net و svn.php.net را در حالت فقط خواندنی رها کنیم و همچنین همه را جابجا کنیم. باقی مانده به آنها مخازن پسوند PECL در GitHub، شبیه به مخزن اصلی PHP.
منبع: opennet.ru