سیر تکاملی امنیت: داستان کُد رد

۱۴۰۱/۵/۱۵امنیت اطلاعات

روابط عمومی شرکت ایدکو (توزیع‌کننده‌ی محصولات کسپرسکی در ایران)؛ کُد رد[1] کرمی بود که با Microsoft [2]IIS به سیستم‌های مبتنی بر ویندوز حمله می‌کرد. قصه آن دست‌کم شروعِ خوشی دارد: توزیع بدافزار درست همان اول وقوع رخداد شناسایی شد. کاشفان Code Red در واقع محققینی بودند از مرکز eEye Security که در زمان شناسایی (13 جولای 2001) از قضا در حال توسعه‌ی سیستمی بودند برای پیدا کردن آسیب‌پذیری‌های Microsoft IIS. ناگهان آزمایشی آن‌ها دیگر پاسخ نداد. بعدش هم آن‌ها شبی داشتند بدون خواب و پراسترس که مجبور شدند لاگ‌های سیستم را زیر و رو کنند تا رد آلودگی را بزنند. آن‌ها اسم این بدافزار را بر اساس اولین چیزی که به چشمشان خورد انتخاب کردند: یک قوطی نوشابه با نام تجاری Mountain Dew Code Red. با این حال، این شناسایی نسبتاً زودهنگام به متوقف کردن این اپیدمی چندان کمکی نکرد. بدافزار از قبل داشت از سیستم‌های آلوده برای حملات آتی استفاده می‌کرد و ظرف چند روز قرار بود در کل جهان توزیع شود. بعدها، مرکز تحلیل کاربردی داده‌های اینترنتی[3] (CAIDA) در تاریخ 19 جولای از آمار و ارقام خود پرده برداشت؛ آمار و ارقامی که نشان‌دهنده سرعت توزیع کد رد بود. بر اساس منابع مختلف، بیش از 300 هزار سرور به طور کلی مورد حمله قرار گرفتند.

ساز و کار کُد رد

این کرم اینترنتی یک آسیب‌پذیری بی‌اهمیت در ماژول‌های وب‌سرور را اکسپلویت کرده بود؛ دقیق‌تر بگوییم یک افزونه برای فهرست‌گذاری داده‌ها[4]. در آرشیو idq.dll یک خطای سرریز بافر[5] وجود داشت. به این آسیب‌پذیری شناسه  MS01-33 داده شد- باگی که راحت می‌شد آن را اکسپلویت کرد؛ فقط کافی بود به سرور درخواست طولانی‌ای با این سر و شکل ارسال شود:

GET /default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a  HTTP/1.0

در نتیجه، داده بعد از تعداد زیادی حرف   N به عنوان دستور تعبیر شده و اجرا می‌گردد. کل پی‌لود مخرب در این درخواست موجود است؛ یعنی با توجه به نصبِ آسیب‌پذیر Microsoft IIS، سیستم تضمین داده می‌شود که بلافاصله آلوده شود. مشهودترین پیامدهای این ابتلا در واقع تخریب سایت‌های ارائه‌شده توسط وب‌سرور بود. به جای محتوای همیشگی‌شان محتوای زیر نمایش داده می‌شد:

طبق گزارشات کسپرسکی، تخریب دائمی نبوده است: 10 ساعت بعد از حمله موفق، کرم محتوای نرمال وبسایت را ریستور کرده بوده است. بقیه اقدامات نیز به تاریخ بستگی داشتند. بین 1 تا 19 هر ماه، کرم خود را منتشر نموده و به یک سری آدرس رندوم درخواست آلوده ارسال می‌کرده است. بین 20 تا 27 هر ماه چندین آدرس آی‌پی ثابت DDoS می‌شدند؛ از جمله وبسایت دولت ریاست جمهوری آمریکا. از 28 تا آخر ماه هم کد رد استراحتی نه چندان شایسته داشت.

نگاه به کد رد یا دیدِ سال 2022

رخدادهای مشابه هنوز هم اتفاق می‌افتند اما معمولاً به آسیب‌پذیری‌های روز صفر مربوطند که بیشتر مواقع موقع بررسی حمله‌ای فعال شناسایی می‌شوند. نمونه معمولی‌اش سری آسیب‌پذیری‌های میل سرور Microsoft Exchange که مدام در زمان شناسایی‌اش اکسپلویت می‌شد. بیش از 30 هزار سازمان در سراسر جهان آلوده‌ی آن شدند و ادمین‌های میل سرویس در بسیاری از شرکت‌ها احساس کردند باید زودتر از اینها پچ نصب می‌کردند و درمواقع آلودگی، پروسه ممیزی راه می‌انداختند. این نمونه نشان می‌دهد نه تنها حملات پیچیده‌تر شده‌اند که همچنین روش‌های دفاعی نیز پیشرفت قابل‌ملاحظه‌ای داشته‌اند.

کد رد نه یک آسیب‌پذیری روز صفر که آنی را که یک ماه قبل از همه‌گیری‌اش شناسایی و بسته شده بود اکسپلویت می‌کرد. آن زمان کُندی در نصب آپدیت‌ها، نبود ابزارهای نصب خودکار و آگاهی کمِ کاربران سازمانی هم بی‌تأثیر نبودند. فرق مهم دیگر بین کد رد و حملات مدرن امروز نیز نبود درآمدزایی است. این روزها هک کردن سرور آسیب‌پذیر یک شرکت ناگزیردر ادامه سرقت داده یا رمزگذاری به اضافه درخواست باج را خواهد داشت. همچنین مجرمان سایبری دنیای مدرن به ندرت سایت‌های هک‌شده را خراب می‌کنند؛ برعکس آن‌ها بیشتر تمایل دارند همه تلاش خود را بکنند تا رد پای خود را در زیرساخت آی تی شرکت پنهان کنند.

درسی تلخ

باید گفت کد رد خیلی سریع صحنه را ترک کرد. آگست 2001 شاهد نسخه دستکاری‌شده آن بودیم (Code Red II) که می‌توانست سیستم‌هایی را که قبلاً توسط اولین نوع کرم "بازدید شده بودند" آلوده کند. با این حال به طور کلی اوایل دهه 2000 حملات مختلف دیگری نیز با سناریوی مشابه اتفاق افتاد. در سپتامبر 2001 نیز شاهد اپیدمی کرم  Nimda بودیم؛ که به شکل مشابهی دست روی آسیب‌پذیری‌هایی (در Microsoft IIS) می‌گذاشت که خیلی وقت بود پچ شده بودند. سال 2003 هم کرم  Blaster شیوع گسترده‌ای داشت. در آخر خبر رسید پچ‌های آسیب‌پذیری‌های مهم در نرم‌افزارهای سازمانی باید سریعاً نصب شوند. وقتی آپدیت منتشر شد، مجرمان سایبری به دقت آن را بررسی کردند و شروع کردند به اکسپلویت مستقیمِ آسیب‌پذیری آن هم به امید اینکه برخی کاربران هنوز آن‌ها را پچ نکرده‌اند.

اما همین الان هم نمی‌توان گفت که مشکل حل شده است. نمونه‌های جدیدتری مانند حمله WannaCry در سال 2017 وجود دارد. با این حال، آنچه می‌توان گفت این است که Code Red و بسیاری از برنامه‌های مخرب دیگر که مسئول آلوده کردن صدها هزار سیستم در سراسر جهان هستند، به شکل‌گیری رویکردهای امنیتی شرکتی که امروز ما را راهنمایی می‌کنند، کمک کردند.

 برخلاف 21 سال پیش، ما اکنون برای همه چیز، از ارتباطات گرفته تا پرداخت، زیرساخت‌های حیاتی را که دیگر نگوییم، کاملاً به سیستم‌های فناوری اطلاعات وابسته هستیم. در حقیقت یاد گرفته‌ایم چگونه در برابر حملات سایبری دفاع کنیم، اما هنوز این امکان بوجود نیامده که برای همه مشکلات تجاری در فضای سایبری یک نسخه درمان واحد تولید کنیم. همچنان که امنیت سایبری ناگزیر رشد می‌کند باید این را نیز بدانیم که امنیت بی‌نقص داشتن یک وضعیت ثابت نیست بلکه کشمکش و تقلایی مداوم است.

 

[1] Code Red

[2]سرویس‌های اطلاعات اینترنتی برای ویندوز سرور

[3]  Applied Internet Data Analysis

[4] data indexing

[5]  buffer overflow error، در امنیت کامپیوتر و برنامه نویسی، سرریز بافر، یا تاخت و تاز کردن بافر، یک استثنا است که در آن برنامه، هنگامی که در حال نوشتن داده‌ها به بافر است، از مرز بافر تخطی می‌کند و باعث رونویسی حافظه مجاور می‌شود. این یک مورد خاص از نقض ایمنی حافظه‌است.

 

منبع: کسپرسکی آنلاین (ایدکو)

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