خون‌ریزی ابری در Cloudflare!

این روزها اتفاقات زیادی در دنیای امنیت رخ داده است که شاید بزرگترین آن‌ها اولین حمله تصادم SHA-1 بوده باشد؛ اما اتفاقی که کمتر به آن پرداخته شد واقعه‌ی ناگوار Cloudbleed یا خون‌ریزی ابری هست که برای شرکت Cloudflare رخ داد.

شرکت Cloudflare به جهت سرویس گسترده CDN و DDoS Protection بسیار شناخته شده است و متاسفانه/خوشبختانه در ایران نیز کاربران فراوانی دارد. در حال حاضر حدود 4 میلیون دامنه (Domain) در بستر Cloudflare سرویس‌دهی می‌شوند.

جمعه‌ی گذشته آقای Tavis Ormandy از تیم معروف Google Project Zero متوجه شد که نسبت به برخی درخواست های HTTP که توسط سرورهای Cloudflare سرویس‌دهی می‌شدند، پاسخ‌های بی‌معنی دریافت می‌کند و نهایتاً به یک مشکل امنیتی جدی در سرویس Cloudflare پی بُرد که منجر به نشت اطلاعات فراوانی از وب‌سایت ها و Web Application های تحت سرویس CDN گردیده است. این اطلاعات می‌تواند شامل نام کاربری و رمز عبور، پیام‌های رد و بدل شده در چَت ها، و کلاً هرگونه اطلاعاتی که توسط آن می‌توان شخصی را شناسایی کرد (PII)، باشد.
متاسفانه عمق فاجعه جایی است که این اطلاعات توسط اغلب Search Engine ها Cache شده اند و احتمالاً در بسیاری از سرویس‌های تجزیه/تحلیل اطلاعاتی ذخیره شده اند.
در بین جستجوگرها می‌توان به Google، Bing، DuckDuckGo و Baidu اشاره کرد.

این اتفاق به این معنی است که اطلاعات شخصی میلیون ها کاربر اینترنتی در خطر قرار گرفته است!

این نشت اطلاعاتی از تاریخ 22 سپتامبر 2016 تا 18 فوریه 2017 ادامه داشته اما اوج آن بین 13 تا 18 فوریه بوده که از هر 3.300.000 درخواست HTTP، یک درخواست منجر به نشت اطلاعات گردیده است؛ یعنی روزانه حدود 100 تا 200 هزار صفحه با اطلاعات شخصی افراد!

چگونه این اتفاق رخ داده است؟

سرویس های CDN معمولاً از مفهومی بنام reverse-proxy استفاده می‌کنند، و در تعریف ساده و کلی، درخواست کاربر را بین سرورهای مختلف پخش کرده، یا ابتدا از Cache و سپس با درخواست از سرور اصلی، سرویس‌دهی می‌کنند. این عمل عموماً برای درخواست های رمزنگاری شده توسط SSL/TLS نیز رخ می‌دهد، یعنی بعنوان مثال وقتی شما درخواست HTTPS خود به وبلاگ شبکه‌ها را در مرورگر وارد می‌کنید، این سرورهای Reverse-proxyی Cloudflare هستند که درخواست شما را decrypt کرده و با انجام پردازشهایی چگونگی پاسخ به درخواست شما مشخص می‌شود.

نتیجه پردازش برای مدتی در RAM (حافظه تصادفی) Reverse-proxy باقی مانده (پاک نمی‌شود) و سیستم به پردازش درخواست‌های بعدی ادامه می‌دهد. حفره‌ای که در یکی از اجزاء این سیستم Cloudflare وجود داشت باعث می‌شد که کاربر نه تنها پاسخ صحیح نسبت به سرویس خود دریافت کند، بلکه بطور تصادفی محتوایی از RAM آن Reverse-proxy نیز دریافت کند؛ که احتمالاً این محتوای تصادفی شامل اطلاعات حیاتی کاربران دیگری بوده است مانند Cookieها، username و password های رمزگشایی شده (decrypted) و …

مثلاً، درحالی که مرورگر شما (کاربر A) در حال دسترسی به این مطلب روی Server A شرکت Cloudflare هست، ممکن است محتوایی کاملاً تصادفی از کاربر B که در حال دسترسی به یک وبسایت دیگر روی Server B شرکت Cloudflare هست، دریافت کند. در نظر داشته باشید درخواست شما و کاربر B ابتدا در یک Reverse-proxy بدست Cloudflare رسیده است و پردازش در آن Reverse-proxy صورت گرفته و نتیجه در RAM ذخیره شده، و سپس هر درخواست به سمت سرور مربوطه ارسال شده است.

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

اما رفتار موتورهای جستجوگر با رفتار مرورگر شما متفاوت است چرا که جهت افزایش بازدهی و اطلاعات آماری، تقریباً تمام اطلاعات Web Server های جهان را cache و تا مدت زمانی ذخیره می‌کنند. و این اتفاق یعنی بطور مثال Google اطلاعات session یک کاربر تصادفی مانند نام کاربری، رمز عبور و … را cache کرده است. این اطلاعات توسط دستورات جستجوی ساده قابل دسترسی هستند؛ اما حداقل تا این لحظه شرکت Google بطور مستقیم در حال همکاری با Cloudflare تا این اطلاعات را از بین ببرند (Cache purging)

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

درس اخلاقی!

جدای از مباحث فنی، در این اتفاق و نمونه‌های مشابه، نکاتی جالب وجود دارند که پرداختن به آنها خالی از لطف نیست.

شفافیت رسانه‌ای و مسئولیت پذیری

اولین نکته در نظر من شفافیت با جامعه و بازگو کردن مشکل است. در ادامه جدول زمانی Cloudbleed را مشاهده می‌کنید:

2017-02-18 0011 Tweet from Tavis Ormandy asking for Cloudflare contact information
2017-02-18 0032 Cloudflare receives details of bug from Google
2017-02-18 0040 Cross functional team assembles in San Francisco
2017-02-18 0119 Email Obfuscation disabled worldwide
2017-02-18 0122 London team joins
2017-02-18 0424 Automatic HTTPS Rewrites disabled worldwide
2017-02-18 0722 Patch implementing kill switch for cf-html parser deployed worldwide
2017-02-20 2159 SAFE_CHAR fix deployed globally
2017-02-21 1803 Automatic HTTPS Rewrites, Server-Side Excludes and Email Obfuscation re-enabled worldwide

از دیدگاه مسئولیت‌پذیری: علت اصلی این ماجرا بخاطر یک باگ در “نحوه‎ی استفاده Cloudflare از کامپایلِر Ragel جهت Parse کردن HTML” بوده و در گزارش Cloudflare بر این نکته کاملاً تاکید شده که Ragel به هیچ وجه نقشی در این اتفاق نداشته است.

اینجا گزاش کامل ماجرا در وبلاگ Cloudflare ارائه شده است که پیشنهاد می‌کنم حتماً مطالعه کنید، مخصوصاً برای علاقمندان به برنامه‌نویسی، مهندسی نرم‌افزار، Sys-admin ها و افرادی که با Webserver ها سروکار دارند.

مدیریت بحران (CIM) و کارِ تیمی

نکته‌ی جالب دیگر در این اتفاق، وجود روندهای مشخص و بهینه در مدیریت بحران، و همکاری خوب تیمی در Cloudflare است. با توجه به بحرانی بودن این رخداد، تیمی متشکل از متخصصین نرم‌افزار، امنیت و عملیات تشکیل شده تا درک کاملی از چگونگی بروز (Root Cause Analysis) بدست آمده و راهکار برطرف نمودن آن در کوتاه مدت (47 دقیقه) و سپس در بلند مدت (7 ساعت) برنامه‌ریزی شود. در همین حین نیز کانالی برای ارتباط با گوگل و سایر موتورهای جستجو تشکیل شد تا نسبت به پیدا کردن اطلاعات Cache شده و پاک کردن آن‌ها اقدام شود.

از دیدگاه کار تیمی، قرار گرفتن افراد در کنار هم با تخصص های مختلف، از ملیت‌های مختلف و دیدگاه‌های شخصی متفاوت، بسیار جالب است. نکته‌ی حائز اهمیت دیگر، مدلی است که شرکت‌های بین‌المللی ارائه کننده خدمات آنلاین دنبال می‌کنند که معروف به Follow the Sun هست. در این رخداد، یک تیم در سانفرانسیسکو به مدت 12 ساعت کار می‌کردند و سپس برای 12 ساعت بعدی کار با تمام جزئیات تحویل تیمی در لندن می‌گردید. بدین شکل بطور شبانه‌روزی روی این مشکل کار شد تا خطا کاملاً برطرف گردد.

بعنوان کاربر اینترنت چکاری میتوانم انجام دهم؟

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

شاید قصد داشته باشید فقط اطلاعات کاربری خود را برای وب‌سایت هایی که از Cloudflare استفاده می‌کنند تغییر دهید، اما متاسفانه ممکن است برخی web-service ها بطور غیر مستقیم از Cloudflare استفاده کنند که در اینصورت کاملاً از دیدگاه شما پنهان خواهند بود؛ لذا بهترین کار تغییر حداقل تمام پسوردهای مهم است.

بعنوان مشتری Cloudflare چکاری میتوانم انجام دهم؟

وجود یک معماری مشخص، مستندسازی و بروزرسانی آن از جمله موارد مهم در ارائه و راهبری وبسایت و Web application است که میتوانند سطح تاثیر برخی اتفاقات این چنینی را کمتر کنند؛ هرچند در این رخداد خاص احتمالاً کار خاصی از دست مشتریان Cloudflare بر نمی‌آمده است.

اما کلاً استفاده از CDN مزایای زیادی دارد که بطور خلاصه میتوان به افزایش دسترسی‌پذیری/سرعت پاسخگویی و حفاظت از سرویس شما در مقابل حملات اینترنتی اشاره کرد. CDN ها محتوای شما را از نزدیکترین نقطه‌ی ممکن به دست مخاطب شما می‌رسانند.