SegmentSmack؛ آسیبپذیری TCP در کرنل لینوکس و ریسک DoS
SegmentSmack با شناسه CVE-2018-5390 یکی از آن آسیبپذیریهایی بود که نشان داد همیشه برای از کار انداختن یک سرویس، حمله پرحجم لازم نیست. در این ضعف، مهاجم میتوانست با ارسال بستههای TCP خاص، کرنل لینوکس را وارد پردازش سنگین کند و مصرف CPU را بالا ببرد. نتیجه عملی میتوانست کند شدن شدید سرویس یا حتی Denial of Service روی سرور باشد.
نکته مهم SegmentSmack این بود که موضوع فقط یک باگ ساده در یک سرویس خاص نبود؛ مسئله در لایه TCP stack کرنل بود. یعنی اگر سروری کرنل آسیبپذیر داشت و یک پورت TCP از بیرون در دسترس بود، ریسک باید جدی گرفته میشد. برای همین patch کردن کرنل و کنترل exposure سرورها در چنین مواردی اهمیت زیادی دارد.
SegmentSmack چه کاری میکرد؟
در این آسیبپذیری، بستههای خاص باعث میشدند کرنل لینوکس برای مدیریت segmentهای TCP خارج از ترتیب، مسیرهای پردازشی سنگینی مثل tcp_collapse_ofo_queue() و tcp_prune_ofo_queue() را بیش از حد درگیر کند. وقتی این اتفاق تکرار میشد، مصرف CPU بالا میرفت و سرور به جای سرویسدهی عادی، وقتش را صرف پردازش همین وضعیت غیرعادی میکرد.
چیزی که این ضعف را مهمتر میکرد، این بود که حمله الزاماً به ترافیک خیلی سنگین نیاز نداشت. در گزارشهای اولیه حتی به امکان ایجاد فشار با نرخ پایین ترافیک هم اشاره شده بود. این یعنی فقط تکیه کردن روی ظرفیت پهنای باند یا تجهیزات ضد DDoS همیشه کافی نیست؛ گاهی خود سیستمعامل در نقطهای آسیبپذیر میشود.
چه سیستمهایی درگیر بودند؟
این مشکل روی نسخههایی از کرنل لینوکس 4.9 به بعد مطرح شد و بعداً patch مربوط به آن منتشر شد. در عمل، هر سرور لینوکسی که در بازه آسیبپذیر قرار داشت و سرویس TCP قابل دسترس ارائه میکرد، باید بررسی میشد. این شامل وبسرورها، reverse proxyها، load balancerهای نرمافزاری، سرورهای VPN و هر سرویس عمومی دیگر میشود.
در محیط سازمانی، فقط اینترنت-facing بودن مهم نیست. اگر segmentation داخلی ضعیف باشد، همین نوع ضعف میتواند از داخل شبکه هم مشکل ایجاد کند. برای همین ارزیابی آسیبپذیری فقط نباید به IPهای public محدود شود.
روش برخورد درست با چنین آسیبپذیریهایی
اولین کار، شناسایی نسخه کرنل و وضعیت patch است. اگر نسخه آسیبپذیر باشد، باید update از مخزن معتبر سیستمعامل نصب شود. در توزیعهای enterprise مثل RHEL، CentOS، Debian، Ubuntu و SUSE، همیشه نسخه عددی kernel بهتنهایی معیار کافی نیست؛ چون vendorها patch امنیتی را backport میکنند. پس باید advisory همان توزیع هم بررسی شود.
بعد از patch، reboot یا live patching باید طبق سیاست عملیاتی انجام شود. خیلی وقتها package نصب میشود ولی سرور هنوز با kernel قدیمی بالا است. در این حالت روی کاغذ patch نصب شده، اما ریسک هنوز باقی مانده است. این مورد در auditهای امنیتی زیاد دیده میشود.
کنترلهای کمکی
Patch راهحل اصلی است، اما کنترلهای کمکی هم مهماند. محدود کردن دسترسی به سرویسهای غیرضروری، بستن پورتهایی که واقعاً لازم نیستند، قرار دادن سرویسها پشت فایروال یا load balancer مناسب، rate limit در لایه مناسب و مانیتورینگ مصرف CPU میتواند زمان تشخیص و واکنش را بهتر کند.
برای چنین ضعفهایی بهتر است alertهای ساده هم داشته باشیم: افزایش ناگهانی CPU روی process/kernel، افت پاسخگویی سرویس، افزایش تعداد connectionهای غیرعادی و تغییر رفتار TCP. اینها همیشه علت را دقیق نمیگویند، اما کمک میکنند زودتر بفهمیم یک اتفاق غیرعادی در حال رخ دادن است.
در اجرای SegmentSmack چه چیزی مهمتر است؟
SegmentSmack یادآوری خوبی بود که آسیبپذیریهای کرنل را نباید کماهمیت دید. حتی وقتی سرویس application از نظر تنظیمات درست است، ضعف در TCP stack میتواند availability را تحت تأثیر قرار دهد. مسیر درست هم روشن است: inventory دقیق سرورها، بررسی advisory، patch بهموقع، reboot کنترلشده و مانیتورینگ بعد از اصلاح.
قابلیت بازیابی اطلاعات؛ Backup امن در برابر حادثه و باجافزار
راهاندازی FortiWeb بدون دردسر False Positive؛ از Monitor تا Block
بکدور FIRESTARTER روی Cisco ASA/FTD؛ بعد از Patch هم تمام نمیشود
بعد از خبر سوءاستفاده فعال از آسیبپذیریهای Fortinet چه کار کنیم؟
کنترل امنیت شماره ۱۷: آموزش امنیتی؛ چیزی که ابزار جای آن را نمیگیرد
کنترل دسترسیهای مدیریتی؛ ادمین کمتر، امنیت بیشتر