نگاهی به آسیب‌پذیری حیاتی و کلاسیک ICQ در سال ۱۹۹۸؛ وقتی یک سرریز بافر ساده حساب‌ها را می‌بلعید

تاریخ امنیت سایبری پر از خطاهای ساده‌ای است که امروزه مرور آن‌ها برای مهندسان نرم‌افزار هم عجیب و هم آموزنده به نظر می‌رسد. یکی از این موارد، بولتن امنیتی شماره ۲۲ منبع معروف Rootshell در اوت ۱۹۹۸ است که به یک نقص بحرانی در سرویس پیام‌رسان محبوب آن دوران یعنی ICQ (توسعه‌داده‌شده توسط Mirabilis) اشاره دارد.

زمینه و بستر تاریخی

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

جزئیات فنی آسیب‌پذیری

ماجرا از این قرار بود که سرورهای Mirabilis انتظار داشتند طول رمز عبور حداکثر ۸ کاراکتر باشد. اعتبارسنجی طول و محدودسازی آن در کلاینت رسمی انجام می‌شد و کلاینت هیچ‌گاه بیش از ۸ کاراکتر به سرور ارسال نمی‌کرد. اما کلاینت‌های جایگزین لینوکسی این محدودیت را اعمال نمی‌کردند.

مکانیزم این باگ و اکسپلویت آن به شرح زیر بود:

• سرریز بافر (Buffer Overflow): اگر کلاینتی رمز عبوری با ۹ کاراکتر یا بیشتر ارسال می‌کرد، بافر سمت سرور دچار سرریز می‌شد.
• دور زدن احراز هویت: این سرریز بافر نه تنها باعث کرش سرور نمی‌شد، بلکه به طرز عجیبی منطق احراز هویت را دور می‌زد و سرور درخواست ورود را معتبر تشخیص می‌داد.
• نحوه نفوذ: با تنظیم کردن UIN (شناسه کاربری منحصر‌به‌فرد در ICQ) روی حساب قربانی و قرار دادن یک رمز عبور ساختگی با طول ۹ کاراکتر یا بیشتر (مثل 123456789)، برنامه‌های کلاینت می‌توانستند مستقیماً به حساب کاربر مورد نظر لاگین کنند.

برخلاف تکنیک‌های Spoofing معمولی که صرفاً نام فرستنده را جعلی نشان می‌دادند، در این روش مهاجم رسماً به اکانت دسترسی کامل پیدا می‌کرد؛ پیام‌های آفلاین کاربر به دست او می‌رسید، می‌توانست پیام ارسال و دریافت کند و کنترل کامل حساب را در اختیار می‌گرفت.

بحث و تبادل نظر در Hacker News

کاربران Hacker News با مرور این خاطره تکنولوژیک، به نکات جالبی اشاره کردند:

• بسیاری از کاربران با حسرت و لبخند از دوران اولیه اینترنت یاد کردند که سیستم‌ها به این اندازه پیچیده و مجهز به لایه‌های دفاعی امروزی نبودند.
• برخی از کاربران قدیمی اعتراف کردند که احتمالا سرقت شدن حساب‌های کاربری قدیمی‌شان در آن زمان ناشی از همین باگ بوده است.
• بحث‌هایی پیرامون سایر خطاهای تاریخی احراز هویت در نرم‌افزارهای معروف (مانند خطاهای مشابه در MySQL یا پروتکل‌های AIM) شکل گرفت که نشان می‌دهد چقدر پیاده‌سازی صحیح پروتکل‌ها و اعتبارسنجی ورودی‌ها حیاتی است.

چرا این موضوع برای مهندسان نرم‌افزار مهم است؟

این داستان قدیمی بار دیگر اهمیت اصول بنیادین مهندسی نرم‌افزار را یادآوری می‌کند:

• اعتبارسنجی در سمت سرور (Server-side Validation): هیچ‌گاه نباید به پیاده‌سازی منطق امنیتی یا اعتبارسنجی داده‌ها در سمت کلاینت اعتماد کرد. کلاینت می‌تواند توسط کاربر دستکاری شود یا جایگزین گردد.
• مدیریت حافظه: خطاهای سرریز بافر دهه‌هاست که یکی از خطرناک‌ترین حوزه‌ها در امنیت نرم‌افزار هستند و این مسئله ضرورت استفاده از زبان‌ها و ابزارهای ایمن‌تر را توجیه می‌کند.