سرو شدن پوشهٔ گیت: تجربه‌ای از مواجهه با یک آسیب‌پذیری

شنبه ۷ اردیبهشت ۹۸ کافه بازار با یک مشکل امنیتی مواجه شد. چنان که در دنیای فناوری‌ مرسوم است، زمانی که شرکت‌ها با مشکلی فنی مواجه می‌شوند، پس از گذر از آن موقعیت، تجربیات خود از آن را با جامعهٔ متخصص به اشتراک می‌گذارند. ما نیز در این مطلب قصد داریم با دید فنی در مورد تجربه‌ای که از این ماجرا داشتیم توضیح دهیم.


شروع ماجرا

صبح روز شنبه خبری در شبکه‌های اجتماعی پخش شد که ادعا می‌کرد «کدها و دیتابیس کافه‌بازار» لو رفته است و در آن تصویری از یک فایل حاوی تنظیمات اتصال به یک پایگاه‌ دادهٔ Postgres و دو پایگاه‌ دادهٔ Redis وجود داشت. از روی این تنظیمات متوجه شدیم که این تصاویر مربوط به یکی از پروژه‌هایمان به نام «پنجره» است.


تصویر منتشر شده از تنظیمات پروژهٔ پنجره
تصویر منتشر شده از تنظیمات پروژهٔ پنجره


این پروژه یکی از مایکروسرویس‌های کافه بازار است که وظیفه‌ی سرو کردن صفحات وبسایت (cafebazaar.ir) را به عهده دارد. تا مدتی تمام اطلاعاتی که در اختیار داشتیم دو تصویر منتشر شده بود که برای تشخیص آسیب‌پذیری کافی نبود. بنابراین همهٔ فرضیات ممکن برای دسترسی به کدها را با بالاترین درجهٔ آسیب‌پذیری ممکن در نظر گرفتیم و برای مقابله با هریک گروه‌هایی تشکیل دادیم و به صورت همزمان دست به کار شدیم. در ادامه دو تا از مهم ترین فرضیات را شرح می‌دهیم.


بررسی امکان نفوذ به سرور گیت (Git)

ما در کافه‌بازار برای کنترل مخازن کد از Gitlab استفاده می‌کنیم. یکی از فرضیه‌ها این بود که کد، به دلیل آسیب‌پذیری این ابزار به دست مهاجم افتاده باشد.

یکی از اشتباهات ممکن، قرار دادن اطلاعات حساس نظیر رمزها و کلیدها در مخازن کنترل نسخه (Version Control) است. تیم‌های فنی باید تلاش کنند با پیروی از فرآیندها، و تولید ابزارهای مناسب این ریسک را به حداقل برسانند. با این حال ممکن است در روند توسعه، این جنس اطلاعات به کد راه پیدا کرده باشند. در راستای مقابله با این فرض، از همه‌ی تیم‌ها خواستیم کدهای خود را بررسی کنند و در صورت وجود این گونه اطلاعات، آن‌ها را تغییر، و به خارج از مخازن گیت انتقال دهند.

از طرف دیگر، این امکان وجود داشت که مهاجم از طریقی موفق به گذشتن از سیستم احراز هویت و ورود به پنل گیت شده باشد. با توجه به فعال بودن احراز هویت دو مرحله‌ای، تمام نشست‌های (sessions) فعال گیت را نامعتبر کردیم تا تمام دسترسی‌های فعلی قطع شود. سپس مشغول بررسی لاگ‌های سرور گیت برای یافتن رفتار مشکوک شدیم که در نهایت رفتار مشکوکی در این لاگ‌ها دیده نشد.

همچنین ممکن بود نسخه‌‌ٔ Gitlab مورد استفاده‌ی ما دارای آسیب‌پذیری امنیتی باشد. برای بررسی این فرضیه نیز تیم زیرساخت مشغول بررسی آسیب‌پذیری‌های شناخته شده‌ی Gitlab شد. در بسیاری از موارد، مشکلات امنیتی شرکت‌ها ناشی از به‌روز نبودن ابزارهای مورد استفاده‌شان است. در حالی که اکثر ابزارهای معتبر در صورت کشف آسیب پذیری به سرعت به‌روزرسانی‌های لازم را منتشر می‌کنند. در این مورد به‌روزرسانی‌های لازم بر روی Gitlab اعمال شده بود.


بررسی امکان نفوذ به سرور پنجره

ما در کافه‌بازار از معماری مایکروسرویس‌ها استفاده می‌کنیم. در این معماری سعی می‌شود هر مایکروسرویس تنها به داده‌های مورد نیاز خود دسترسی داشته باشد. پنجره نیز به عنوان مایکروسرویس صفحات وب کافه‌بازار، جدول نشست کاربرانِ وارد شده به وبسایت را در اختیار داشت.

با اینکه هیچ‌گونه شواهدی مبنی بر نفوذ به سرور پنجره وجود نداشت، در راستای مقابله با آن اقداماتی انجام دادیم.

پنجره از ابتدا به صورت یک مایکروسرویس منزوی طراحی شده بود و نباید به سرورهای دیگر دسترسی می‌داشت. با این حال تمام ارتباطات بین سرورها را بازنگری کردیم و مطمئن شدیم که سرور پنجره به هیچ سرور دیگری دسترسی مستقیم ندارد. همچنین بررسی کردیم که تمامی سرویس‌ها در شبکه داخلی دارای فرآیند احراز هویت باشند.

از طرفی با فرض نفوذ مهاجم، برای اطمینان از ادامهٔ عملکرد صحیح این پروژه، سرور را از دسترس خارج کردیم و پروژه‌ی پنجره را روی یک سرور جدید و با تغییر تمامی رمز‌ها راه‌اندازی کردیم.

در کنار این اقدام‌ها، برای پیدا کردن ردپایی از دسترسی غیر معمول به تحلیل لاگ‌ها پرداختیم. علاوه بر این، در گروه دیگری مشغول ارزیابی امکان نفوذ به سرور شدیم. اما در هیچ کدام از این مسیرها مشکلی پیدا نکردیم.


اما مشکل چه بود؟

بعد از دسترسی به کدهای منتشر شده و بررسی آن‌ها متوجه دو نکتهٔ مهم شدیم. یکی وجود تفاوت در بعضی از فایل‌های منتشر شده با نسخهٔ روی گیت و مطابقت آن‌ها با نسخهٔ روی سرور بود. این نکته فرضیه اول یعنی نفوذ به سرور گیت را رد می‌کرد. نکته‌ی دیگر این که برخی از فایل‌های موجود روی سرور در نسخهٔ منتشرشده وجود نداشتند. هیچ یک از این فایل‌ها، هیچ وقت روی گیت نبوده‌اند. این نکته نیز امکان درستی فرضیه دوم را کمرنگ می‌کرد.

در ادامهٔ بررسی‌ها، در میان لاگ‌های وب‌سرور Nginx متوجه وجود تعدادی درخواست موفق به مسیر git./ و فایل‌های پروژه شدیم. این درخواست‌ها دقیقا مطابق با فایل‌های منتشرشده بود. با بررسی تنظیمات Nginx فهمیدیم که وجود یک خطا در این تنظیمات باعث می‌شد پوشهٔ کدهای پروژه توسط وب‌سرور قابل دسترسی باشد. مهاجم با استفاده از این خطا ابتدا موفق به استخراج پوشهٔ git. مربوط به پروژهٔ پنجره شده بود، سپس با استخراج آدرس فایل‌های موجود در پوشهٔ گیت توانسته بود تنها همین فایل‌ها را از روی سرور دانلود کند و مجموع این اتفاقات توسط لاگ‌های سرور تایید می‌شد. با همخوانی همه‌ٔ شواهد و کشف دقیق آسیب‌پذیری، فرضیه‌های بالا رد شد و مشخص شد که مهاجم هیچ گونه دسترسی به سرور و دیتابیس نداشته است.

این آسیب پذیری از نوع Source Code Disclosure است که با مراجعه به این لینک می‌توانید اطلاعات بیشتری در مورد آن کسب کنید.


جمع‌بندی

ما در کافه‌بازار عادت داریم پس از اتفاق‌های فنی، مانند از دسترس خارج شدن سرویس‌ها، مشکلات امنیتی و ایرادات جدی محصولی، جلسات Postmortem برگزار کنیم تا زوایای مختلف مسئله را بازنگری کنیم و برای آینده تصمیمات اثرگذار بگیریم. این ماجرا نیز نهایتاً باعث شد که ما بررسی گسترده‌ای روی روال‌های امنیتی گذشته انجام دهیم و برای بهبود آن‌ها تصمیمات مهمی بگیریم.

همچنین از همهٔ کسانی که در طول این ماجرا با همراهی خود از ما حمایت کردند صمیمانه تشکر می‌کنیم.