پی ایچ پی پروجیکٹ کے گٹ ریپوزٹری اور یوزر بیس کے سمجھوتہ پر رپورٹ

پی ایچ پی پروجیکٹ کے گٹ ریپوزٹری میں دو بدنیتی پر مبنی کمٹ کی شناخت سے متعلق ایک واقعے کے تجزیے کے پہلے نتائج شائع کیے گئے ہیں جب خصوصی طور پر ڈیزائن کردہ یوزر ایجنٹ ہیڈر کے ساتھ درخواست بھیجتے وقت بیک ڈور چالو کیا جاتا ہے۔ حملہ آوروں کی سرگرمیوں کے نشانات کے مطالعہ کے دوران، یہ نتیجہ اخذ کیا گیا کہ git.php.net سرور خود، جس پر گٹ ریپوزٹری واقع تھی، ہیک نہیں کیا گیا تھا، لیکن پروجیکٹ کے ڈویلپرز کے اکاؤنٹس کے ڈیٹا بیس سے سمجھوتہ کیا گیا تھا۔ .

یہ ممکن ہے کہ حملہ آور master.php.net سرور پر DBMS میں محفوظ صارف ڈیٹا بیس کو ڈاؤن لوڈ کرنے میں کامیاب ہو گئے ہوں۔ master.php.net کے مواد کو پہلے ہی شروع سے انسٹال کردہ نئے main.php.net سرور پر منتقل کر دیا گیا ہے۔ php.net انفراسٹرکچر تک رسائی کے لیے استعمال ہونے والے تمام ڈویلپر پاس ورڈز کو دوبارہ ترتیب دے دیا گیا تھا اور انہیں تبدیل کرنے کا عمل ایک خصوصی پاس ورڈ ریکوری فارم کے ذریعے شروع کیا گیا تھا۔ git.php.net اور svn.php.net کے ذخیرے صرف پڑھنے کے لیے رہتے ہیں (ترقی کو GitHub میں منتقل کر دیا گیا ہے)۔

پی ایچ پی کے بانی راسمس لیرڈورف کے اکاؤنٹ کے ذریعے کی گئی پہلی بدنیتی پر مبنی کمٹ کی دریافت کے بعد، یہ خیال کیا گیا کہ ان کا اکاؤنٹ ہیک ہو گیا تھا اور نکیتا پوپوف، جو پی ایچ پی کے اہم ڈویلپرز میں سے ایک ہیں، نے تبدیلیوں کو واپس لے لیا اور کمٹ کے حقوق کو بلاک کر دیا۔ مشکل اکاؤنٹ کچھ عرصے کے بعد، یہ احساس ہوا کہ بلاک کرنے کا کوئی مطلب نہیں ہے، کیونکہ ڈیجیٹل دستخط کا استعمال کرتے ہوئے کمٹ کی تصدیق کے بغیر، php-src ریپوزٹری تک رسائی کے ساتھ کوئی بھی شریک فرضی مصنف کا نام بدل کر تبدیلی کر سکتا ہے۔

اس کے بعد، حملہ آوروں نے خود نکیتا کی طرف سے ایک بدنیتی پر مبنی کمٹ بھیجا۔ ریپوزٹریز تک رسائی کو منظم کرنے کے لیے استعمال ہونے والی گیٹولائٹ سروس کے لاگز کا تجزیہ کرکے، اس شریک کا تعین کرنے کی کوشش کی گئی جس نے اصل میں تبدیلیاں کی تھیں۔ تمام وعدوں کے لیے اکاؤنٹنگ شامل کیے جانے کے باوجود، دو بدنیتی پر مبنی تبدیلیوں کے لیے لاگ میں کوئی اندراج نہیں تھا۔ یہ واضح ہو گیا کہ بنیادی ڈھانچے کا سمجھوتہ تھا، کیونکہ کمٹ کو براہ راست شامل کیا گیا تھا، گٹولائٹ کے ذریعے کنکشن کو نظرانداز کرتے ہوئے۔

git.php.net سرور کو فوری طور پر غیر فعال کر دیا گیا، اور بنیادی ذخیرہ GitHub میں منتقل کر دیا گیا۔ جلدی میں، یہ بھول گیا تھا کہ مخزن تک رسائی حاصل کرنے کے لیے، گیٹولائٹ کا استعمال کرتے ہوئے SSH کے علاوہ، ایک اور ان پٹ تھا جو آپ کو HTTPS کے ذریعے کمٹ بھیجنے کی اجازت دیتا تھا۔ اس صورت میں، گٹ کے ساتھ تعامل کرنے کے لیے git-http-backend کا استعمال کیا گیا، اور Apache2 HTTP سرور کا استعمال کرتے ہوئے توثیق کی گئی، جس نے master.php.net سرور پر DBMS میں میزبان ڈیٹا بیس تک رسائی حاصل کرکے اسناد کی تصدیق کی۔ لاگ ان کی اجازت نہ صرف چابیاں کے ساتھ، بلکہ باقاعدہ پاس ورڈ کے ساتھ بھی تھی۔ HTTP سرور لاگز کے تجزیے نے تصدیق کی کہ HTTPS کے ذریعے نقصان دہ تبدیلیاں شامل کی گئیں۔

لاگز کا مطالعہ کیا گیا تو یہ بات سامنے آئی کہ حملہ آوروں نے پہلی بار رابطہ نہیں کیا بلکہ ابتدائی طور پر اکاؤنٹ کا نام تلاش کرنے کی کوشش کی لیکن شناخت کرنے کے بعد انہوں نے پہلی کوشش میں ہی لاگ ان کیا، یعنی وہ راسمس اور نکیتا کے پاس ورڈ پہلے سے جانتے تھے، لیکن ان کے لاگ ان کو نہیں جانتے تھے۔ اگر حملہ آور DBMS تک رسائی حاصل کرنے میں کامیاب تھے، تو یہ واضح نہیں ہے کہ انہوں نے فوری طور پر وہاں بیان کردہ درست لاگ ان کا استعمال کیوں نہیں کیا۔ اس تضاد کی ابھی تک کوئی قابل اعتماد وضاحت نہیں ملی ہے۔ master.php.net کے ہیک کو سب سے زیادہ امکانی منظر نامہ سمجھا جاتا ہے، کیونکہ اس سرور نے بہت پرانا کوڈ اور ایک فرسودہ OS استعمال کیا تھا، جسے کافی عرصے سے اپ ڈیٹ نہیں کیا گیا تھا اور اس میں غیر پیچیدگیاں تھیں۔

اٹھائے گئے اقدامات میں master.php.net سرور ماحول کی دوبارہ تنصیب اور پی ایچ پی 8 کے نئے ورژن میں اسکرپٹس کی منتقلی شامل ہے۔ ڈی بی ایم ایس کے ساتھ کام کرنے کے کوڈ میں پیرامیٹرائزڈ سوالات استعمال کرنے کے لیے ترمیم کی گئی ہے جو ایس کیو ایل کوڈ کے متبادل کو پیچیدہ بناتے ہیں۔ bcrypt الگورتھم کو ڈیٹا بیس میں پاس ورڈ ہیشز کو ذخیرہ کرنے کے لیے استعمال کیا جاتا ہے (پہلے، پاس ورڈز کو ایک ناقابل اعتبار MD5 ہیش کا استعمال کرتے ہوئے ذخیرہ کیا جاتا تھا)۔ موجودہ پاس ورڈ دوبارہ ترتیب دیے جاتے ہیں اور آپ کو پاس ورڈ کی بازیابی کے فارم کے ذریعے ایک نیا پاس ورڈ سیٹ کرنے کے لیے کہا جاتا ہے۔ چونکہ HTTPS کے ذریعے git.php.net اور svn.php.net ذخیروں تک رسائی MD5 ہیشز سے منسلک تھی، اس لیے یہ فیصلہ کیا گیا کہ git.php.net اور svn.php.net کو صرف پڑھنے کے موڈ میں چھوڑ دیا جائے، اور تمام کو منتقل کر دیا جائے۔ باقی ان کے لیے GitHub پر PECL ایکسٹینشن ریپوزٹریز، جو کہ اہم PHP ریپوزٹری کی طرح ہے۔

ماخذ: opennet.ru