آیا مرورگر من ایمن است؟

برای تست آسیب پذیر بودن مرورگر خود روی لینک زیر کلیک کنید.

http://amn.bayan.ir/poodle

توضیح فنی آسیب پذیری پودل

آسیب پذیری POODLE که امروز منتشر شده است، از یک ضعف در مبنای تئوری SSLv3 استفاده کرده است، نه یک مشکل پیاده سازی. به همین دلیل تنها راه برطرف کردن آن غیر فعال کردن کامل این پروتوکل می‌باشد.

اصل مبنای تئوری این آسیب پذیری توسط Serge Vaudenay در سال ۲۰۰۱ مطرح شده بود، اما او فکر می‌کرده است که امکان استفاده عملی از این آسیب پذیری وجود ندارد. هم اکنون یک روند عملی برای استفاده از این آسیب پذیری مطرح شده است. این روند عملی، اگر چه پیچیده، ولی قطعی است (احتمالی نیست) و فراهم کردن همه‌ی شرایط آن اگر چه نیاز به تلاش بسیاری دارد (و نوشتن یک اسکریپت برای آن شاید سخت باشد) ولی کاملا شدنی است.

شرایط لازم برای تحقق آسیب پذیری

تنها شروط پایه برای استفاده از این آسیب پذیری، این موارد است:

    حمله کننده در شبکه کاربر قرار گرفته باشد و بتواند درخواست‌ها را مشاهده کند و تغییر دهد.
        (مثلا کسی که به رایانه یا مودم ADSL کاربر دسترسی دارد، یا دانشگاه یا ISP ای که کاربر با آن به اینترنت متصل است)
    مرورگر کاربر (client) از SSLv3 پشتیبانی کند (که همه‌ی مرورگرهای قدیمی و جدید پشتیبانی می‌کنند)
    سایت مقصد (سرور) از SSLv3 پشتیبانی کند (که تقریبا همه‌ی سایت‌ها پشتیبانی می‌کنند)
        نکته این جاست که مرورگر IE6 تنها از SSLv3 پشتیبانی می‌کند، و اگر سایتی این ویژگی را غیر فعال کند، مرورگرهای IE6 دیگر امکان اتصال به آن را ندارند.

از نظر تئوری، این آسیب پذیری اجازه می‌دهد که حمله کننده قسمتی از درخواست را (با اینکه رمز شده است) بخواند و تشخیص دهد. این قسمت باید شرایط خاصی داشته باشد ولی برای مثال می‌تواند cookie کاربر باشد.

شرایط ثانویه استفاده از این آسیب پذیری موارد زیر است. دقت نمایید که همه‌ی این شرایط با فرض شماره ۱ قابل دستیابی هستند.

    حمله کننده می‌تواند هر کد <script> دلخواه را در سمت کاربر اجرا نماید. (چون در شبکه قرار گرفته است، و مثلا می‌تواند اسکریپت دلخواه را در پاسخ یک درخواست http (که رمز نگاری نشده است) inject کند)
    حمله کننده باید بتواند یک درخواست را بدون تغییر، به دفعات زیاد در طرف کاربر اجرا کند.
        درخواست‌های کاربر اصولا شامل url صفحه و header هاست. هدرها هم اصولا ثابت هستند (مثلا Accept و User-Agent و ...). هدر Cookie هم که حمله کننده می‌خواهد به محتوای آن دستیابی پیدا کند اصولا (حداقل چند دقیقه) ثابت است.
    حمله کننده دقیقا باید بداند که هدف (مثلا مقدار هدر Cookie) چند کاراکتر است و در کجای request قرار دارد (از کاراکتر چندم تا چندم).
        حمله کننده با مشاهده درخواست‌های رمز نگاری نشده و قبلی کاربر (که http هستند) می‌تواند این اطلاعات را کسب کند.
    حمله کننده باید بتواند که با یکسان نگه داشتن طول request. مقدار دلخواه خود را جلو و عقب ببرد (شیفت کند)
        حمله کننده به راحتی با اضافه کردن یک کاراکتر به url و تغییر body درخواست، می‌تواند این کار را انجام دهد. (دقت کنید که لازم نیست حمله کننده پاسخی دریافت کند، بنابراین CORS هم تأثیری ندارد)

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

بیشتر الگوریتم‌های رمز نگاری مورد استفاده در SSL روی block های ۸ یا ۱۶ بایتی از داده کار می‌کنند (در اینجا برای راحتی فرض می‌کنیم که از یک الگوریتم ۱۶ بایتی استفاده می‌شود) بنابراین مثلا داده باید به تکه‌های ۱۶ بایتی تقسیم شود و عملیات رمز نگاری روی این بسته‌های ۱۶ بایتی انجام می‌شود.

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

47 45 54 20 2F 3F 61 62 0D 0A 43 6F 6F 6B 69 65   GET /?ab↲↲Cookie
3A 20 73 65 63 72 65 74 3D 31 32 33 0D 0A 0D 0A   : secret=123↲↲↲↲
72 65 71 75 65 73 74 20 62 6F 64 79 YY YY YY YY   request body----
YY YY YY YY YY YY YY YY YY YY YY YY XX XX XX 03   ------------••••

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

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

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

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

P1:47 45 54 20 2F 3F 61 62 63 64 65 66 0D 0A 43 6F  GET /?abcdef↲↲Co
P2:6F 6B 69 65 3A 20 73 65 63 72 65 74 3D 31 32 33  okie: secret=123
P3:0D 0A 0D 0A 72 65 71 75 65 73 74 20 62 6F 64 79  ↲↲↲↲request body
P4:YY YY YY YY YY YY YY YY YY YY YY YY YY YY YY YY  ----------------
P5:XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 0F  ••••••••••••••••

(هر بلاک رمزنگاری نشده (یا plaintext) از P1 تا P5 نام گذاری شده است)

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

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

C1:28 DA 27 4E C1 41 34 32 5A 68 53 BB 32 20 CA 69  (Ú'NÁA42ZhS»2 Ê~
C2:27 CC DF 89 7B 4F 2A 69 32 5A E4 BD 24 3A DE 79  'Ì߉{O*i2Zä½$:Þy
C3:CA FE D8 6F DD D9 38 7C 76 FF 61 D7 64 78 45 FE  ÊþØoÝÙ8|vÿa×dxEþ
C4:F0 69 F1 8E C6 C3 73 52 20 EE 7E E2 F1 AF 62 37  ðiñŽÆÃsR î~âñ¯b7
C5:8A 5D 74 7B 31 28 41 61 B6 62 7C 97 80 F7 9E 63  Š]t{1(Aa¶b|—€÷žc

(هر بلاک رمزنگاری شده (یا ciphertext) از C1 تا C5 نام گذاری شده است)

البته او می‌داند که بلاک آخر متناظر padding و بلاک C2 هم متناظر با P2 است.

به صورت پیش‌فرض SSL از روش CBC برای chain کردنِ بلاک‌ها استفاده می‌کند (برای اطلاعات بیشتر می‌توانید به ویکی پدیا مراجعه کنید)

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

Encrypt(C1 ⊕  P2) = C2
Encrypt(C4 ⊕  P5) = C5

و می‌داند که P5[16] = 0x0F است (چون padding یک سطر کامل است)

در این حال حمله کننده (که بین کلاینت و سرور حائل شده است)، بلاک C5 را (که متناظر با padding است) دستکاری می‌کند و آنرا مساوی C2 قرار می‌دهد:

C1:28 DA 27 4E C1 41 34 32 5A 68 53 BB 32 20 CA 69  (Ú'NÁA42ZhS»2 Ê~
C2:27 CC DF 89 7B 4F 2A 69 32 5A E4 BD 24 3A DE 79  'Ì߉{O*i2Zä½$:Þy
C3:CA FE D8 6F DD D9 38 7C 76 FF 61 D7 64 78 45 FE  ÊþØoÝÙ8|vÿa×dxEþ
C4:F0 69 F1 8E C6 C3 73 52 20 EE 7E E2 F1 AF 62 37  ðiñŽÆÃsR î~âñ¯b7
C5:27 CC DF 89 7B 4F 2A 69 32 5A E4 BD 24 3A DE 79  'Ì߉{O*i2Zä½$:Þy

در این صورت خواهیم داشت:

C5 = C2 ⇒
  Encrypt(C1 ⊕  P2) = Encrypt(C4 ⊕  P5) ⇒
    C1 ⊕  P2 = C4 ⊕  P5 ⇒
       P2 = C1 ⊕ C4 ⊕ P5

سپس حمله کننده رشته‌ی جدید را به سرور ارسال می‌کند.

حمله کننده مقدار C5 را (که رمز شده‌ی padding بوده) دستکاری کرده است و بنابراین مقدار padding را به رشته نامعلومی تغییر داده است. اما می‌داند که سمت سرور فقط آخرین کاراکتر padding مهم است نه بقیه آن. در بیشتر موارد مقدار کاراکتر آخر مخالف 0x0F است و سرور تشخیص می‌دهد که پیام ارسال شده خراب شده است و ارتباط را قطع می‌کند. اما از هر ۲۵۶ مورد یک مورد امکان دارد که کاراکتر آخر دقیقا برابر 0x0F باشد. در این صورت پیام، صحیح تلقی شده و پاسخ به کلاینت برگردانده می‌شود. حمله کننده به راحتی (مثلا با بررسی اندازه پاسخ) می‌تواند تشخیص دهد که آیا این دستکاری، پیام را خراب کرده است یا نه.

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

P2[16] = C1[16] ⊕ C4[16] ⊕ P5[16]

مقدار P5[16] = 0x07 است و مقدار C1 و C4 نیز جزو ciphertext (درخواست رمز شده) است.

به این ترتیب حمله کننده حدودا با ۲۵۶ تلاش می‌تواند یک کاراکتر از کوکی کاربر را استخراج کند. حال کاربر با اضافه کردن یک کاراکتر به url و حذف یک کاراکتر از body می‌تواند مقدار کوکی را یک کاراکتر به جلو شیفت کند و با تکرار روند بالا (حدودا ۲۵۶ درخواست) کاراکترهای کوکی را یک به یک استخراج نماید.

47 45 54 20 2F 3F 61 62 63 64 65 66 67 0D 0A 43   GET /?abcdefg↲↲C
6F 6F 6B 69 65 3A 20 73 65 63 72 65 74 3D 31 32   ookie: secret=12
33 0D 0A 0D 0A 72 65 71 75 65 73 74 20 62 6F 64   3↲↲↲↲request bod

بنابراین یک حمله کننده برای یافتن یک کوکی به طول ۴۰ کاراکتر، حدودا باید ۱۰،۰۰۰ درخواست از سمت کاربر ارسال کند. این تعداد بسیار کم است و با سرعت ۲۰ درخواست در ثانیه، در کمتر از ۱۰ دقیقه قابل انجام می‌باشد.

SSL چیست؟

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

آسیب‌پذیری چیست؟

در هنگام اولین اتصال به سرویس‌دهنده (وب سرور)،  سرویس‌گیرنده (مرورگر کاربر) سعی می‌کند از طریق بالاترین نسخه‌ای که  پشتیبانی می‌کند (مثلاً TLS 1.2) ارتباط را ایجاد کند. اگر وب سرور نیز  قابلیت پشتیبانی از این نسخه را داشته باشد ارتباط برقرار می‌شود در غیر  این صورت اگر مثلاً وب سرور از نسخه‌ی TLS 1.0 استفاده کند، مرورگر کاربر  نیز به نسخه‌ی پایین‌تر یعنی TLS 1.0 سوییچ می‌کند. به این رویکرد  downgrade گفته می‌شود می‌تواند توسط یک نفوذگر داخل شبکه‌ی کاربر نیز  اتفاق بیافتد. که در اینجا نفوذگر مرورگر کاربر را وادار می‌کند تا از طریق  SSLv3 اتصال را برقرار نماید. در SSLv3 برای رمزنگاری از روش‌های RC4 و یا  یک روش رمز بلوکی در حالت CBC استفاده می‌شود. در ساختار رمز بلوکی در  حالت CBC این پروتکل مشکلی وجود دارد که باعث می‌شود نفوذگر بتواند با  آزمون خطا، با تعداد درخواست های اندکی، قسمتی از درخواست رمز شده بین  مرورگر و وب سرور را حدس بزند. این داده‌ی حدس زده شده می‌تواند کوکی کاربر  باشد که نفوذگر با استفاده از آن می‌تواند وارد حساب کاربر بشود.اصل مبنای تئوری این آسیب پذیری توسط Serge Vaudenay در سال ۲۰۰۱ مطرح شده بود، اما او فکر می‌کرده است که امکان استفاده عملی از این آسیب پذیری وجود ندارد و نهایتا این آسیب‌پذیری توسط مهندسان گوگل اعلام شد و Poodle نام گرفت.

چه کسی تحت تأثیر این آسیب‌پذیری قرار می‌گیرد؟

کاربران هر وب‌سایتی (سرویس دهنده) که از SSLv3 پشتیبانی کند (در تنظیمات وب سرور غیر فعال نکرده باشد)، آسیب‌پذیر می‌باشند. در‌ واقع حتی اگر وب سایت از نسخه‌های TLS استفاده کند به دلیل قابلیت downgrade (بازگشت به نسخه‌ی قبلی) آسیب‌پذیر می‌باشد زیرا نفوذگر داخل شبکه می‌تواند مرورگر کاربر را وادار کند تا از طریق SSLv3 اتصال برقرار کند.
کاربر چگونه تحت تأثیر این آسیب‌پذیری قرار می‌گیرد؟

نفوذگر (داخل شبکه‌ی کاربر) با بهره‌برداری از این آسیب‌پذیری می‌تواند اطلاعات حساس کاربر مانند (کوکی که هویت کاربر است) را برباید و در نهایت وارد حساب کاربر شود.
راه‌حل پیشنهادی چیست؟

همان‌طور که نیمه شب گذشته از طریق اکانت توییتر بیان اعلام شد بهترین راه حل برای این آسیب‌پذیریی عدم استفاده از SSLv3 توسط سرویس‌دهنده (وب سرور) و سرویس‌گیرنده (کاربر) می‌باشد. البته اگر سرویس دهنده‌ای تنها از SSLv3 استفاده کند، غیرفعال کردن آن در سمت کاربر (سرویس گیرنده) می‌تواند باعث عدم دسترسی به سرویس‌دهنده شود.

 
نحوه غیر فعال کردن SSL 3.0 در مرورگرهای مختلف در سیستم عامل ویندوز

مرورگر Internet Explorer

 از منوی Tools گزینه Internet Options را انتخاب کنید.

صفحه Internet Options باز می شود.

در این صفحه برگه Advanced را انتخاب کنید. (نام برگه ها به صورت افقی در بالای صفحه لیست شده است)
    در این برگه تعداد زیادی گزینه (چک باکس) وجود دارد که با کلیک بر روی هر کدام می توانید آن گزینه را تیک دار کنید یا تیک آن را بردارید. این گزینه ها در دسته های مختلفی دسته بندی شده اند.
    با اسکرول صفحه به سمت پایین به مجموعه گزینه هایی که در دسته Security قرار گرفته اند برسید.
    در این دسته، تیک مربوط به گزینه هایی که با عنوان Use SSL شروع شده اند را بردارید (اگر تیک دارند). معمولا دو گزینه Use SSL 2.0 و Use SSL 3.0 باید وجود داشته باشند.
    در همین دسته، گزینه هایی که با عنوان Use TLS شروع می شوند را تیک بزنید (اگر تیک ندارند). معمولا گزینه Use TLS 1.0 وجود دارد و ممکن است گزینه های Use TLS 1.1 و Use TLS 1.2 نیز وجود داشته باشند.

در نهایت صفحه شما باید مشابه شکل زیر شده باشد (ممکن است بعضی از گزینه ها وجود نداشته باشند):

دکمه Ok را بزنید تا تغییرات شما ذخیره شوند.

 مرورگر Firefox

راه اول: استفاده از افزونه ارائه شده توسط موزیلا. توجه کنید که این راه فقط برای نسخه های 26 به بالای Firefox قابل استفاده است.

    توسط مرورگر خود به این آدرس بروید:
    https://addons.mozilla.org/en-US/firefox/addon/ssl-version-control
    در این صفحه، دکمه Add to Firefox را کلیک کنید.
    از پنجره ای که باز می شود دکمه Allow را انتخاب کنید.
    پس از مدتی پنجره دیگری باز می شود. در این پنجره دکمه Install Now (که در پایین پنجره قرار گرفته است) را کلیک کنید.
    پس از مدتی پیغامی مبتنی بر نصب موفقیت آمیز افزونه به شما داده می شود.
    این افزونه به طور اتوماتیک همه کارها را انجام می دهد.

راه دوم: استفاده از تنظیمات پیشرفته (فقط برای کاربران حرفه ای)

    عبارت about:config را در قسمت آدرس بار مرورگر خود تایپ کنید.
    در صفحه باز شده در قسمت جستجو عبارت tls را وارد کنید و دکمه Enter را بزنید.
    بر روی سطری که دارای عنوان security.tls.version.min می باشد "دبل کلیک" کنید.
    پنجره ای باز می شود که می توانید در آن مقدار وارد کنید.
     عدد 1 را وارد کنید و سپس دکمه Ok را بفشارید.

مرورگر Chrome

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

    بر روی میانبر Chrome بر روی دسکتاپ کلیک راست کنید و گزینه Properties را از منوی باز شده انتخاب کنید.
    در صفحه باز شده به فیلد Target را پیدا کنید و بر روی جعبه ورودی مقابل آن کلیک کنید.
    به انتهای مقدار وارد شده در این جعبه بروید که عبارت chrome.exe” می باشد.
    با گذاشتن یک فاصله (space) این عبارت را پس از عبارت بالا وارد کنید:   
    --ssl-version-min=tls1
    دکمه Ok را بزنید.

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