مشکل کلاودفلر چی بود و ما باید چیکار کنیم

من آخر هفته خیلی شلوغی داشتم. درست‌تر بگم، هفته خیلی شلوغی و اگر دقیق تر بخوام حرف بزنم؛ ماه خیلی شلوغی! این وسط هم کلی خبر خوب داشتیم که خب نرسیدیم در موردشون حرف بزنیم. اما به نظرم یکی از جالبترین‌هاش که جاش اینجا بود، بحث مشکل امنیتی نشت اطلاعات کلاودفلر بود. توضیحات اشتباه هم در موردش خیلی زیاد داده شده، حتی سایت های معتبر خارجی.

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

اما چند روز قبل کلاودفر یک خبر بزرگ منتشر کرد: باگ گزارش شده توسط تاویس اورماندی از پروژجت زیرو گوگل بهشون خبر داده که در بعضی صفحات اطلاعات غیر عادی وجود داره! خیلی غیرعادی؛ در حد توکن لاگین یوزرها، پسوردهاشون، ای پی آی کال ها و غیره و غیره. در واقع اطلاعاتی که باید بین هر یوزر کاملا مخفی باشه، حالا به عنوان بخشی از یک صفحه وب در گوشه ای از اینترنت قابل دیدن است!

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

این مساله به خاطر باگ موسوم به Buffer Overrun ایجاد شده بود. باگی که در زبان های سی و سی پلاس پلاس برنامه نویس موظف به مواظب بودن در موردش است و در نتیجه بارها و بارها اشتباها از زیر دست تست ها در می ره و باعث مشکلات امنیتی بزرگ می شه. این باگ اینطوری کار می کنه که یک متغیر از جای تعیین شده برای خودش بیرون می زنه و با بقیه حافظه قاطی می شه! کد زیر دقیقا خطی است که باعث شد کلاودفلر دچار مشکل بشه:

if ( ++p == pe )
    goto _test_eof;

یک ابزار که قراره صفحه رو بهینه کنه، این رو صدا می زنه و تا وقتی که پوینتر به جای مورد نظر «برسه». حالا چی می شه اگر پوینتر در یک حالت خاص از اینجا بپره؟ تا مدت ها پیش می ره و بقیه اطلاعات حافظه رو توی متغیر مورد نظر می ریزه! همین می شه که سرور کلاود فلری که مثلا صفحه من رو بر می گردونه ممکنه بخشی از حافظه خودش که حاوی اطلاعات حساسه رو هم ته صفحه من برگردونه!

کلاود فلر می گه فقط در ۷ ساعت این مشکل رو حل کرد؛ از طریق درگیر کردن تیم‌هاش در تمام جهان. البته این باگ از هر سه میلیون و سیصد درخواست اچ تی تی پی فقط ۱ دونه رو درگیر می کرد ولی همین هم کافی بود که هنوزم اگر توی گوگل بگردین، ممکنه بتونین توکن های مشابهی رو پیدا کنین!

چه باید کرد

این هم یکی دیگه از اشتباه‌های بعضی منابع است؛ در واقع من و شما به عنوان یوزر کار چندانی نمی تونیم بکنیم. عوض کردن پسورد همیشه ایده خوبیه ولی در بسیاری از این موارد چیزی که لو می ره پسورد نیست (چون اون فقط یکبار رد و بدل می شه). اکثر سرورها برای نگهداری اطلاعات از توکن ها استفاده می کنن (مثلا قسمت هفتم بستون رو ببینین) و این توکن ها دائما دست به دست می شن. حتی اگر شما پسورد رو عوض کنین این توکن احتمالا کماکان در سرور فعال و معتبر است.

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

بهترین نکته؟ شفافیت کلاودفلر که حتی کدهای مشکل دار رو هم نشونمون داد (: