‏کور کردن نگهبان‌ها: سوءاستفاده از لاگ‌های ابری

سرویس‌های لاگ‌گیری ابری دید کاملی از هر اتفاقی که تو منابع ابری می‌افته می‌دن و برای پایش امنیتی حیاتی‌ان؛ ولی به گفتهٔ تیم Unit 42 پالو آلتو، همین وابستگی باعث می‌شه خودشون به یه هدف پرارزش برای مهاجم تبدیل بشن. مهاجمی که به این سرویس‌ها دست پیدا کنه می‌تونه نقاط کور بسازه، از شناسایی فرار کنه و تو بعضی سناریوها دید مداوم روی محیط قربانی نگه داره. تمرکز تحلیل روی دو سرویس پرکاربرد AWS CloudTrail و Google Cloud Logging هست.

برای درک حمله‌ها، اول باید سازوکار تحویل لاگ رو شناخت. تو AWS، منبع اصلی یه trail هست که تنظیم می‌کنه چطور فراخوانی‌های API ضبط بشن و لاگ‌ها معمولاً به یه سطل S3 نوشته می‌شن. تو گوگل کلاود، یه sink نقش مسیریاب رو داره و ورودی‌های لاگ رو به یه مقصد مشخص مثل log bucket می‌فرسته. حمله‌ها دقیقاً همین منابع پیکربندی رو هدف می‌گیرن.

دستهٔ اول حمله‌ها فرار از دفاع (Defense Evasion) هست و پنج تکنیک داره. ساده‌ترینش قطع کردن لاگ‌گیریه: مهاجمی با مجوز cloudtrail:StopLogging می‌تونه نوشتن لاگ یه trail رو متوقف کنه، و معادلش تو گوگل کلاود غیرفعال‌کردن sink با مجوز logging.sinks.update هست. تکنیک‌های بعدی شامل حذف مقصد ذخیره‌سازی لاگ (مثل حذف سطل S3) و حذف خود مسیریاب لاگ (trail یا sink) هستن که هر دو جریان لاگ رو قطع می‌کنن.

تکنیک چهارم ظریف‌تره: مهاجم به جای پاک‌کردن، لاگ‌ها رو ناخوانا می‌کنه. با تغییر کلید رمزنگاری (KMS تو AWS یا CMEK تو گوگل کلاود) به یه کلید تحت کنترل خودش و بعد قطع دسترسی به اون کلید، لاگ‌ها دیگه قابل رمزگشایی یا حتی قابل نوشتن نیستن؛ جالب اینه که کنسول یه خطای «دسترسی رد شد» نشون می‌ده انگار خود سطل مشکل داره، در حالی که سطل درست پیکربندی شده. تکنیک پنجم هم مسموم‌سازی لاگ (Log Poisoning) هست: چون لاگ‌ها به‌صورت JSON تو استوریج ذخیره می‌شن، مهاجمی با مجوز خوندن و نوشتن روی سطل می‌تونه یه فایل لاگ رو دانلود کنه، رویدادهای خاصی رو حذف یا تغییر بده و دوباره بارگذاری کنه؛ این کار زنجیرهٔ استناد رو می‌شکنه و ممکنه تحلیلگر SOC ناخواسته از لاگ دستکاری‌شده استفاده کنه.

دستهٔ دوم حمله‌ها دید مداوم (Continuous Visibility) هست؛ اینجا مهاجم به جای اجرای دستورهای پرسروصدای شناسایی، مسیر لاگ رو به محیط خودش منحرف می‌کنه تا بی‌صدا همه‌چی رو ببینه. یه راه ساختن یه مسیریاب لاگ جدید (create-trail تو AWS یا logging.sinks.create تو گوگل) هست که خروجی رو به سطل مهاجم می‌فرسته؛ راه دیگه هم بازمسیردهی مقصد لاگ هست که مقصد یه trail یا sink موجود رو به منبع مهاجم تغییر می‌ده. با این کار مهاجم می‌تونه استقرار VMهای جدید، تغییر سیاست‌های IAM و دسترسی به دادهٔ حساس رو در لحظه رصد کنه.

نویسنده برای پیشگیری تأکید می‌کنه دسترسی به منابع لاگ‌گیری باید فقط به کاربران خیلی پرمجوز محدود بشه و فراخوانی‌هایی مثل update-trail کنترل بشن. AWS یه تاریخچهٔ رویداد ۹۰ روزهٔ تغییرناپذیر (Event History) و امکان اعتبارسنجی یکپارچگی فایل لاگ (log file integrity validation) داره که البته وقتی از CLI یا API استفاده می‌شه به‌صورت پیش‌فرض روشن نیست. گوگل کلاود هم سطل‌های داخلی مثل _Required رو داره که تغییرناپذیرن؛ ولی سطل‌هایی که دستی برای یکپارچه‌سازی با ابزار بیرونی ساخته می‌شن همچنان در معرض این حمله‌ها می‌مونن.

نکات کلیدی:

• سرویس‌های لاگ‌گیری ابری چون قلب پایش امنیتی‌ان، خودشون به هدف اصلی مهاجم تبدیل می‌شن
• پنج تکنیک فرار: قطع لاگ‌گیری، حذف مقصد ذخیره‌سازی، حذف مسیریاب، ناخوانا کردن با کلید رمز مهاجم، و مسموم‌سازی لاگ
• دو تکنیک دیدبانی مداوم: ساختن مسیریاب لاگ جدید و بازمسیردهی لاگ‌ها به حساب مهاجم
• کلید دفاع، محدودکردن مجوزهایی مثل cloudtrail:StopLogging و logging.sinks.update به کاربران پرمجوزه
• سطل‌های تغییرناپذیر مثل _Required گوگل و اعتبارسنجی یکپارچگی لاگ AWS کمک می‌کنن، ولی سطل‌های دستی همچنان آسیب‌پذیرن