راه‌کارهایی برای جلوگیری از سوء‌استفاده از آسیب‌پذیری پودل

به گزارش پایگاه خبری بانکداری الکترونیک،به نقل از مرکز ماهر آسیب‌پذیری Poodle در تاریخ 14 اکتبر 2014 توسط تیم امنیت اطلاعات شرکت گوگل منتشر اعلان شده است.

این آسیب‌پذیری ناشی از مشکل در پیاده سازی پروتکل نیست بلکه از یک ضعف ذاتی در پروتکل SSLv3 سرچشمه می‌گیرد.بنابراین تنها راه برطرف کردن این آسیب‌پذیری، غیر فعال کردن کامل این پروتکل است. این آسیب‌پذیری به مهاجم این  امکان  را می‌دهد که از محتوای حساس کاربر در حین یک اتصال  sslرمزگشایی نماید (به عنوان نمونه به اطلاعات هویتی در کوکی دسترسی پیدا کند). این امر امکان سواستفاده ازحساب های بانکی و… را فراهم می‌نماید.

SSLV3 یک پروتکل برای رمزنگاری ارتباط بین کلاینت و سرور است تا محتوای رد و بدلی بین آنها قابل مشاهده توسط بقیه نباشد. اما این پروتکل منسوخ و ناامن است (بیش از 18 سال از عمر این پروتکل می‌گذرد). جایگزین این پروتکل TLS(Transport Layer Secure) می‌باشد که چنین ضعف ساختاری در برقراری ارتباط امن در آن وجود ندارد. اما در برقراری ارتباط امن بینclient  و Server و به منظور سازگاری با تمامی نسخه های مرورگرها، پروتکل های قدیمی‌تر همچنان پشتیبانی می‌گردند. بنابراین وقتی یک تلاش برای اتصال امن TLSبین client و server با مشکل روبرو می‌شود، سرور از پروتکل قدیمی‌تر مانند sslv3 استفاده می‌نماید. شخص مهاجم از این ویژگی استفاده کرده و در فرایند مذاکره بین client و server با شبیه سازیشرایطی که نشانگر عدم برقراری ارتباط امن بین client  و  server است، سرور  را مجبور می‌کند از پروتکل SSLv3 استفاده نماید  و آنگاه از ضعف ساختاری پروتکل SSLV3 با استفاده از حمله مرد میانی سودجویی می‌نماید.

شرایط اجرای حمله

به منظور بهره برداری موفق، مهاجم بایستی بتواند کدهای مخرب javascript  را در مرورگر قربانی تزریق نماید. همچنین بایستی توانایی مشاهده و دستکاری ترافیک رمز شده را داشته باشد (در حقیقت بایستی شرایط حمله مرد میانی مهیا باشد).

ریشه‌یابی آسیب‌پذیری

بیشتر الگوریتم‌های رمز نگاری مورد استفاده در SSL روی block های 8 یا 16بایتی از داده کار می‌کنند (در ادامه فرض می‌شود که از یک الگوریتم 16 بایتی استفاده می‌شود). بنابراین بایستی داده‌ها به تکه‌های 16 بایتی تقسیم شده و عملیات رمزنگاری روی این بسته‌های 16 بایتی انجام شود.

چون ممکن است طول داده مضربی از 16 نباشد، ابتدا باید با اضافه کردن چند کاراکتر اضافی به انتهای داده (که به آنpaddingمی‌گویند)، طول آن را به مضربی از 16 تغییر داد. روش مورد استفاده در SSLv3 این طور است که آخرین کاراکتر نشان می‌دهد که چند کاراکتر padding وجود دارد. برای مثال، در شکل زیر هر خط 16 کاراکتر و بنابراین یک بلوک است:

در مثال فوق، کاراکترهای مشکی رنگ خود درخواست(plaintext)و کاراکترهای سبز سبز رنگ، مقدار درهم آن است (که برای ما مهم نیست). مقدار 123 که با رنگ زرد مشخص شده، مقداری است که حمله کننده آنرا نمی‌داند و می‌خواهد آن را بیابد.

کاراکترهای قرمز padding هستند و آخرین کاراکتر که 03 است، نشان می‌دهد که 3 کاراکتر قبل آن نیز جزو paddingاست. در SSLv3 مقدار 3 کاراکتر قبلی اصلا مهم نیست (برای همین با XX نشان داده شده است) در صورتی‌که در نسخه‌های بعد، این کاراکترها باید مساوی با همان کاراکتر آخر باشند. همین تفاوت است که باعث آسیب‌پذیر شدن SSLv3 شده است.دقت کنید که در SSLv3 کاراکترهای padding در hash محاسبه نمی‌شوند و این نکته هم یکی از مبانی این آسیب‌پذیری است.

نحوه سوءاستفاده از آسیب‌پذیری

ابتدا حمله کننده باید طول درخواست را به گونه‌ای تغییر دهد که یک کاراکتر (مثلا آخرین کاراکتر کوکی) در آخر یک بلوک قرار بگیرد (طبق فرض، طول و جای کوکی مشخص است). ضمناً بایستی طول درخواست به‌گونه‌ای باشد که یک بلوک کامل به padding اختصاص داده شود.

هر بلوک رمزنگاری نشده از P1 تا P5 نام گذاری شده است.دقت کنید که حمله کننده با استفاده از جاواسکریپت می‌تواندurlو body درخواست را تغییر دهد اما دسترسی‌ای به محتوای کوکی ندارد.

متن بالا برای ارسال به سرور در سمت کاربر (کلاینت) رمز می‌شود و محتوای رمز شده به سمت سرور ارسال می‌شود. حمله کننده در بین راه محتوای رمز شده را چیزی مانند شکل زیر می‌بیند:

هر بلوک رمزنگاری شده از C1 تا C5 نام گذاری شده است.البته او می‌داند که بلوک آخر متناظر padding و بلوک C2 هم متناظر با P2 است.

به صورت پیش‌فرض SSL از روش CBC برای زنجیه‌سازی بلوک‌ها استفاده می‌کند

.

بنابراین حمله کننده می‌داند که این روابط صادق هستند:

Encrypt(C1 ⊕  P2) = C2

Encrypt(C4 ⊕  P5) = C5
 

P5[16] = 0x0F