پایان یک زامبی در سرور وب‌سایت رویداد WSS

ماجرا دقیقاً در روزهای پرفشار و حساس آماده‌سازی سایت رویداد WSS آغاز شد. در حالی‌که تمام تمرکز تیم فنی بر توسعه و پایداری سرویس‌ها برای روز رویداد بود، هشداری دقیق از سمت آقای آعلی دریافت کردیم. ایشان متوجه شده بود که بار پردازشی سرور اصلی سایت زیاد شده و عملاً تمام توان CPU توسط یک process ناشناس اشغال شده‌است.

وقتی نام process را بررسی کردم، در نگاه اول بسیار موجه و سیستمی به نظر می‌رسید: dhpcd. به‌طور ناخودآگاه آن را با سرویس استاندارد dhcpd (مدیریت آی‌پی‌های پویا) اشتباه گرفتم. اما همان لحظه تناقضی آشکار شد؛ روی یک سرور ابری Enterprise که از پیکربندی شبکۀ استاتیک استفاده می‌کند، وجود سرویس DHCP هیچ توجیه فنی‌ای نداشت. با دقیق‌تر شدن روی نام process، متوجه تکنیک کلاسیک فریب شدم. مهاجمان با جابه‌جا کردن حروف p و c (تکنیک Typosquatting)، تلاش کرده بودند تا در شلوغی مدیریت سرور، خود را پشت نام سرویس‌های حیاتی پنهان کنند.

در آن لحظه، به‌دلیل فشار کاری بالای رویداد WSS و اولویت‌های دیگر، تصور کردم با یک اسکریپت مزاحم ساده طرف هستم. بدون انجام فرایند‌ جرم‌شناسی رایانه‌ای دقیق، فایل اجرایی را حذف کردم تا منابع آزاد شود تا به‌سرعت به کارهای توسعه برسم. اما این یک اشتباه استراتژیک بود. ساعاتی بعد، پیام مجدد آقای آعلی مبنی بر این‌که «process دوباره برگشته‌است»، نشان داد که ما با یک بدافزار گذرا طرف نیستیم، بلکه سرور، میزبان یک مکانیزم پیشرفتۀ «پایداری» شده‌است.

کالبدشکافی فنی: معماری یک خانۀ امن

با تمرکز کامل به کالبدشکافی بدافزار پرداختم و متوجه شدم هدف نهایی، تبدیل سرور به یک زامبی برای استخراج رمزارز (Cryptojacking) بوده‌است. اما آن‌چه نگران‌کننده بود، ماینینگ نبود؛ بلکه تسلط پیچیدۀ مهاجم بر سیستم‌عامل بود. مهاجم تنها یک فایل اجرایی اجرا نکرده بود، بلکه با دانش عمیقی از لینوکس، لایه‌های دفاعی متعددی ایجاد کرده بود.

بررسی‌ها نشان داد که نقطۀ اولیۀ نفوذ، احتمالاً ناشی از هک شدن یک سرور جانبی دیگر بوده‌است که متعلق به یکی از اعضای تیم با دسترسی مجاز به سرور WSS بوده‌است. مهاجم پس از به دست آوردن کلید خصوصی SSH آن کاربر از روی سرور هک‌شدۀ ثانویه، توانست با کاوش در فایل‌های پیکربندی SSH آن سرور (مانند فایل‌های ~/.ssh/config و ~/.ssh/known_hosts)، آدرس IP و نام مستعار سرور WSS را شناسایی کند و سپس از کلید معتبر برای ورود مستقیم و بدون رمز عبور به‌عنوان کاربر مجاز استفاده نماید. با این کار، مهاجم توانست کلید عمومی خود را به فایل authorized_keys تزریق کند تا دسترسی دائم خود را تضمین کند.

بررسی‌ها نشان دادند که مهاجم برای حفظ کلیدهای SSH تزریق‌شده و فایل‌های پیکربندی خود، از سطوح دسترسی استاندارد عبور کرده‌است و به سراغ «ویژگی‌های فایل‌سیستم» رفته‌است. با فعال‌سازی فلگ «تغییرناپذیری»، فایل‌های حیاتی مانند authorized_keys و حتی باینری‌های مخرب قفل شده بودند؛ وضعیتی که در آن، کرنل لینوکس اجازۀ هیچ‌گونه ویرایش یا حذفی را حتی به کاربر root نمی‌دهد. هم‌زمان، فایل /etc/shadow نیز برای ایجاد کاربران مخفی یا تغییر hash پسورد دست‌کاری شده بود تا بک‌دور تضمین شود.

پیچیدگی ماجرا به این‌جا ختم نمی‌شد؛ مهاجم، پایگاه اصلی اسکریپت‌های خود را در پارتیشن /dev/shm/ یا همان Shared Memory قرار داده بود تا با اجرا از روی RAM، هم سرعت ماینینگ را بالا ببرد و هم از دید اسکنرهای دیسک مخفی بماند. برای تضمین بقا، مجموعه‌ای از وظایف زمان‌بندی‌شده نقش نگهبان را بازی می‌کردند تا در صورت حذف process، بی‌درنگ نسخۀ جدید را دانلود و اجرا کنند. همچنین، بدافزار دارای ماژول‌های تهاجمی بود که همواره پردازه‌های سنگین دیگر و حتی ماینرهای رقیب را شناسایی و Kill می‌کردند تا تمام توان سرور را تصاحب کنند.

خنثی‌سازی بمب ساعتی: پروتکل پاک‌سازی

در مواجهه با چنین بدافزاری، دستور rm ساده کارساز نیست و پاک‌سازی باید با یک «ترتیب مهندسی‌شده» انجام می‌شد. ابتدا باید چرخۀ حیات قطع می‌شد؛ بنابراین پیش از هر کاری، تمام وظایف زمان‌بندی‌شدۀ مربوط به تمام کاربران بررسی و پاک‌سازی شدند تا پردازه‌های نگهبان از کار بیفتند. در مرحلۀ بعد، نوبت به شکستن سپرهای دفاعی رسید. با استفاده از ابزارهای مدیریت ویژگی‌های فایل، صفت «تغییرناپذیری» از روی فایل‌های کلید SSH، فایل Shadow و باینری‌های مخرب برداشته شد تا امکان حذف آن‌ها فراهم شود.

پس از باز شدن قفل فایل‌ها، پاک‌سازی هویت انجام شد؛ کلیدهای عمومی مهاجم حذف شدند و فایل Shadow برای یافتن کاربران مخفی (به ویژه آن‌هایی که UID با مقدار صفر داشتند) پالایش شد. در نهایت، با اطمینان از قطع‌ شدن دسترسی‌ها، پروسه‌های مقیم در RAM کشته شدند و دایرکتوری /dev/shm/ و دیسک به‌طور کامل از باینری‌های مخرب پاک‌سازی شدند.

پایان باز: استراتژی ایمن‌سازی

تجربۀ نفوذ در جریان رویداد WSS نشان داد که پاک‌سازی بدافزار پایان کار نیست، بلکه شروع فاز ایمن‌سازی است. برای جلوگیری از تکرار چنین حوادثی، سیاست‌های سخت‌گیرانه‌ای اعمال شد. احراز هویت با رمز عبور به‌طور کامل غیرفعال شد و جای خود را به استفادۀ انحصاری از کلیدهای SSH داد. همچنین، دسترسی مستقیم کاربر root مسدود شد تا تمام فعالیت‌ها از طریق کاربران عادی و با نظارت انجام شود. در لایۀ شبکه نیز، با تغییر پورت پیش‌فرض SSH و پیاده‌سازی سیاست دیوار آتش مبنی بر مسدودسازی پیش‌فرض، سطح حمله به حداقل رسید.

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

جزئیات فنی دقیق این کمپین بدافزاری در گزارش تحقیقاتی Akamai موجود است.