tamadon

سلام

OpenSSL MITM CCS injection attack (CVE-2014-0224)

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

در میان این مشکلات که در نسخه 1.0.1 پروژه OpenSSL رفع شدند، یکی از مهم ترین آنها که صحبت زیادی از آن می شود، یعنی حمله (Man-in-the-middle" (MITM" که توسط CVE-2014-0224 مستندسازی شده است، روی پروتکل های لایه سوکت امن (SSL) و امنیت لایه انتقال (TLS) تاثیر می گذارد.

CVE-2014-0224 چیست و آیا باید نگران آن باشیم؟

در جواب کوتاه می توانیم بگوییم : بستگی دارد. اما مانند تمامی مشکلات امنیتی، همیشه بهتر است که از آخرین پچ ها استفاده کنیم.

برای اکسپلوییت این مشکل، باید شرایط زیر حاضر باشند :

• هم کلاینت و هم سرور باید آسیب پذیر باشند. در تمامی نسخه های OpenSSL سمت کلاینت آسیب پذیر است. آسیب پذیری در سمت سرور در نسخه 1.0.1 و بالاتر وجود دارد. اگر در کلاینت یا سرور این مشکل رفع شود، دیگر اکسپلوییت  امکان پذیر نیست.

• یک مهاجم MITM در اصل توانایی جلوگیری بسته های در حال ارسال و تغییر آنها را دارد. ده سال پیش، این حمله تقریبا غیرممکن بود. البته فراهم آورندگان اینترنت یا همان ISP ها دسترسی لازم به شبکه ای که بیشتر اطلاعات از آن عبور می کرد، را داشتند، به همین دلیل این حمله برای آنها امکان پذیر بود.

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

این حمله چگونه کار می کند؟

نشست SSL/TLS توسط پیام های دست تکانی (Handshake Message) ارسالی از طرف کلاینت و سرور آغاز می شود. این قسمت از پروتکل برای مذاکره مشخصه های نشست استفاده می شود، مانند پروتکل رمزنگاری، کلید رمزنگاری، کد اهراز هویت پیام ها (MAC)، بردارهای مقداردهی اولیه(IV) و همینطور افزونه های پشتیبانی شده.

کلاینت یا سرور ممکن است به دلایلی تصمیم بگیرند که استراتژی رمزنگاری مربوط به کانکشن خود در مرحله دست تکانی (با پروتکل دست تکانی اشتباه نگیرید!) تغییر دهند. برای این کار، آنها باید از درخواست CCS یا همان ChangeCipherSpec  استفاده کنند. درخواست CCS شامل یک بسته می باشد که توسط کلاینت و سرور برای مشخص کردن این موضوع که رکوردهای بعدی توسط کلید جدید رمز می شوند، فرستاده می شود.

در هر دو استاندارد RFC 2246 و RFC 5246 پیغام CCS در طول دست تکانی بعد از اینکه پارامترهای امنیتی توافق شدند و قبل از اینکه پیغام تایید نهایی ارسال شود، رد و بدل می شود. اگرچه در OpenSSL این اتفاق نمی افتد اما این پروتکل، CCS را قبل از توافق پارامترهای امنیتی دریافت می کند. بخاطر درست‌نبودن ترتیب اتفاق‌ها، وضعیت سمت کلاینت و سرور ناهماهنگ پیش رفته و به طور معمول باعث قطع کردن ارتباط از هر دو سمت می شود (مگر اینکه یک خطای دیگر نیز اتفاق بیفتد.)

• برای یک ارتباط TLS و در ادامه دست تکانی کلاینت و سرور منتظر میماند.
• یک بسته CCS برای هر دو سمت می فرستد که باعث می شود  کد OpenSSL یک کلید رمز اصلی با طول صفر انتخاب کند. در ادامه تمامی کلید هایی که در این نشست استفاده می شود، از روی همان "کلید رمز اصلی با طول صفر" ساخته می شوند و این ضعف را در تمامی آنها مشاهده خواهد شد.
• مذاکره مجدد برای پارامترهای دست تکانی
• حالا مهاجم می تواند تمامی بسته های ارسالی از دو طرف را رمزگشایی کرده و حتی آنها را تغییر دهد.

OpenSSL این آسیب پذیری را با کنترل زمان دریافت بسته CCS و تغییر روش بررسی کلید رمز اصلی با طول صفر رفع کردند. در این پچ OpenSSL کلیدهای رمز اصلی با طول صفر قابل قبول نیستند. هم چنین دریافت بسته های CCS قبل از کلید رمز اصلی امکان پذیر نیست.

راه حل موجود :

راحت ترین راه ممکن نصب آخرین نسخه OpenSSL روی سرور می باشد. همچنین شما باید تمامی سرویس هایی که از OpenSSL استفاده می کنند را ریست کنید، چون این کار به صورت اتوماتیک انجام نمی شود.

آپدیت های مورد نیاز در هر نسخه در زیر آمده است :