حمله‌ cross-protocol در سرورهایی که از پروتکل SSLv2 (که در OpenSSL و دیگر محصولات استفاده می‌شود) استفاده می‌کنند، کشف شده بود که می‌توانست منجر به رمزگشایی جلسه‌های TLS شود. توجه کنید که ترافیک بین سرویس‌گیرنده‌ها و سرویس‌دهنده‌هایی که آسیب‌پذیر نیستند، می‌تواند از طریق سرویس‌گیرنده‌های دیگری که SSLv2 را پشتیبانی می‌کنند و کلیدهای RSA را با سرویس‌دهنده‌هایی که آسیب‌پذیر نیستند به اشتراک می‌گذارند، مورد حمله واقع شوند. این آسیب‌پذیری به عنوان DROWN شناخته می‌شود[۱].

این مشکل در OpenSSL 1.0.1s برطرف شده است، اما نسخه‌های زیر آسیب‌پذیرند:

۱٫۰٫۱r, 1.0.1q, 1.0.1p, 1.0.1o, 1.0.1n, 1.0.1m, 1.0.1l, 1.0.1k, 1.0.1j, 1.0.1i, 1.0.1h, 1.0.1g, 1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1

این مشکل در OpenSSL 1.0.2g برطرف شده است، اما نسخه‌های زیر آسیب‌پذیرند:

۱٫۰٫۲f, 1.0.2e, 1.0.2d, 1.0.2c, 1.0.2b, 1.0.2a, 1.0.2

۱ میزان تأثیر آسیب‌پذیری CVE-2016-0800

۱-۱ جدول تأثیر آسیب‌پذیری بر اساس شاخص شدت و معیارهای CVSS نسخه ۲ [۲]

CVSS

۲-۱ جدول تأثیر آسیب‌پذیری بر اساس شاخص شدت و معیارهای CVSS نسخه ۳ [۲]

CVSS v3

۲ آنالیز آسیب‌پذیری CVE-2016-0800

۱-۲ بررسی اجمالی آسیب‌پذیری

آسیب‌پذیری DROWN که مخفف کلمات Decrypting RSA using Obsolete and Weakened eNcryption است در تاریخ ۱ مارس ۲۰۱۶ برای عموم فاش شد و به عنوان یک آسیب‌پذیری در دسته آسیب‌پذیری‌های مهم قرار گرفت.

گروهی از محققان امنیتی کشف کردند که SSLv2 نسبت به حمله Bleichenbacher RSA padding oracle آسیب‌پذیر است که می‌تواند برای رمزگشایی متون رمزی RSA بدون داشتن آگاهی از کلید خصوصی RSA مورد استفاده قرار گیرد. این امر می‌تواند توسط مشاهده پاسخ‌های دریافت شده از یک سرور که کلید خصوصی را در اختیار دارد و اجرای عملیات رمزگشایی متون رمزی ارائه شده توسط مهاجم و با استفاده از کلید، انجام شود. محققان همچنین به علت ضعف کشف شده در SSLv2، یک حمله cross-protocol جدید را اثبات کردند که اجازه رمزگشایی جلسات SSL/TLS را با استفاده از نسخه‌های جدیدتر پروتکل یعنی SSLv3 یا نسخه‌های کنونی TLS یعنی ۱٫۱ و ۱٫۲ می‌دهد. این آسیب‌پذیری یک مشکل پروتکل SSLv2 است و بر روی تمامی پیاده‌سازی‌های این پروتکل تأثیرگذار است. محققان از این حمله به عنوان general DROWN یاد می‌کنند.

۲-۲ حمله DROWN

DROWN یک آسیب‌پذیری جدی است که روی HTTPS و سرویس‌های دیگری که روی SSL و TLS تکیه می‌کنند و همین‌طور روی برخی از پروتکل‌های مهم معماشناسی برای امنیت اینترنت، تأثیر می‌گذارد. این پروتکل‌ها به افراد اجازه می‌دهند تا کاوش کردن در وب، استفاده از پست الکترونیک، خرید آنلاین و همین‌طور ارسال پیام را بدون اینکه شخص ثالثی بتواند اطلاعات را بخواند، انجام دهند.

DROWN به مهاجم اجازه می‌دهد تا رمزنگاری را بشکند و ارتباطات حساس مانند رمز عبور، شماره کارت اعتباری و یا اطلاعات مالی را بخواند و یا بدزدد. طبق بررسی انجام شده، حدود ۳۳ درصد از سرویس‌دهنده‌های HTTPS در مقابل این حمله آسیب‌پذیرند.

۱-۲-۲ مهاجم به چه اطلاعاتی می‌تواند دسترسی پیدا کند؟

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

۲-۲-۲ چه کسانی آسیب‌پذیرند؟

وب‌سایت‌ها، سرویس‌دهنده‌های پست الکترونیک و دیگر سرویس‌های وابسته به TLS ممکن است در برابر این حمله، آسیب‌پذیر باشند. با استفاده از Internet-wide scanning می‌توان نتایج زیر را در ارتباط با تعداد وب‌سایت‌های آسیب‌پذیر به دست آورد:

DROWN

۳-۲-۲ چه وب‌سایت‌هایی آسیب‌پذیر هستند؟

سرویس‌دهندگان و سرویس‌گیرندگان جدید از پروتکل رمزنگاری TLS استفاده می‌کنند. بااین‌حال، با توجه به انجام ندادن درست تنظیمات، بسیاری از سرویس‌دهندگان همچنین از SSLv2 نیز پشتیبانی می‌کنند. این پشتیبانی در عمل دارای اهمیت نبود چراکه هیچ‌کدام از سرویس‌گیرندگان به‌روز شده از SSLv2 استفاده نمی‌کردند. بنابراین، بااینکه SSLv2 به عنوان یک پروتکل بسیار ناامن شناخته‌شده بود، تا به امروز، صرف پشتیبانی از SSLv2 به عنوان یک مشکل امنیتی شناخته نمی‌شد، چراکه سرویس‌گیرندگان به‌ندرت از آن استفاده می‌کردند.

DROWN نشان داد همین صرف پشتیبانی از SSLv2 یک نوع تهدید برای سرویس‌دهندگان و سرویس‌گیرندگان جدید به‌حساب می‌آید. این امر به یک مهاجم اجازه می‌دهد تا ارتباطات TLS جدید رابین سرویس‌گیرندگان به‌روز شده و سرویس‌دهندگان، رمزگشایی کند. این کار توسط فرستادن probeها به سرویس‌دهنده‌ای که از SSLv2 پشتیبانی می‌کند و از کلید خصوصی مشابه استفاده می‌کند، انجام می‌شود.

SSLv2

یک سرویس‌دهنده نسبت به حمله DROWN آسیب‌پذیر است، اگر:

اجازه ارتباطات SSLv2 در آن داده شود. این امر به طور شگفت‌آوری رایج است. دلیل آن تنظیمات نادرست و تنظیمات پیش‌فرض نامناسب است. بررسی‌ها نشان داده است که ۱۷ درصد از سرویس‌دهندگان HTTPS همچنان از ارتباطات SSLv2 نیز استفاده می‌کنند.

اگر یک سرویس‌دهنده از کلید خصوصی‌ای استفاده کند که در دیگر سرویس‌دهندگان استفاده می‌شود و در این سرویس‌دهندگان اجازه ارتباطات SSLv2 حتی از طریق یک پروتکل دیگر داده شود. بسیاری از شرکت‌ها، از گواهی‌نامه‌ها و کلیدهای مشابه بر روی وب‌سایت‌ها و سرورهای پست الکترونیک، به طور مجدد استفاده می‌کنند. در این مورد، اگر سرویس‌دهنده پست الکترونیک از SSLv2 پشتیبانی کند و سرویس‌دهنده وب پشتیبانی نکند، مهاجم می‌تواند از سرویس‌دهنده پست الکترونیک استفاده کرده و ارتباطات TLS را به سرویس‌دهنده وب بشکند. هنگام استفاده مجدد از یک کلید در یک حساب کاربری، که بیش از ۱۶ درصد از سرویس‌دهنده‌های HTTPS آسیب‌پذیر هستند، ۳۳ درصد از سرویس‌دهنده‌های HTTPS را در معرض خطر قرار می‌دهد.

۴-۲-۲ چگونه می‌توان از یک سرویس‌دهنده نسبت به حمله DROWN محافظت کرد؟

برای محافظت در برابر حمله DROWN، اپراتورهای سرویس‌دهنده باید از این امر که کلید‌های خصوصی آن‌ها در هیچ کجای دیگر که دارای نرم‌افزار سرویس‌دهنده‌ای است که از ارتباطات SSLv2 پشتیبانی می‌کند، استفاده‌نشده است، اطمینان حاصل کنند. این امر شامل سرویس‌دهندگان وب، سرویس‌دهندگان SMTP، IMOP و سرویس‌دهندگان POP و هر نرم‌افزاری که از SSL/TLS پشتیبانی می‌کند، می‌شود.

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

OpenSSL: یک نوع کتابخانه رمزنگاری است که در بسیاری از محصولات سرویس‌دهنده استفاده می‌شود. برای کاربران OpenSSL، ساده‌ترین راه‌حلی که پیشنهاد می‌شود به‌روزرسانی به آخرین نسخه OpenSSL است. کاربرانی که از نسخه OpenSSL 1.0.2 استفاده می‌کنند باید OpenSSL خود را به نسخه ۱٫۰٫۲g به‌روزرسانی کنند. کاربران نسخه‌های قدیمی‌تر OpenSSL نیز باید OpenSSL خود را به یکی از این نسخه‌ها به‌روزرسانی کنند. اطلاعات تکمیلی در این مورد در وب‌سایت OpenSSL آورده شده است[۵].

مایکروسافت IIS (سرویس‌دهنده ویندوز): پشتیبانی از SSLv2 در طرف سرویس‌دهنده به صورت پیش‌فرض تنها بر روی نسخه‌های سیستم‌عاملی که مربوط به IIS 7.0 و IIS 7.5 می‌شود، مانند ویندوز ویستا، ویندوز سرور ۲۰۰۸، ویندوز ۷ و ویندوز سرور ۲۰۰۸ R2 فعال است. این پشتیبانی می‌تواند از طریق subkey مناسب SSLv2 برای ‘Server’ غیرفعال شود. این کار بر روی به‌روزرسانی KB245030 انجام شده است[۶]. حتی اگر کاربران مراحل مربوط به غیرفعال سازی SSLv2 را انجام ندهند، رمزهای export-grade و ۵۶ بیت که امکان حمله DROWN را فراهم می‌کنند به صورت پیش‌فرض پشتیبانی نمی‌شوند.

Network Security Services: NSS، یک کتابخانه رمزنگاری رایج است که برای بسیاری از محصولات سرویس‌دهنده ساخته شده است. نسخه ۳٫۱۳ از کتابخانه NSS که در سال ۲۰۱۲ منتشر شده است و نسخه‌های بعد از آن، به صورت پیش‌فرض گزینه SSLv2 آن‌ها غیرفعال است (ممکن است تعداد کمی از کاربران این گزینه را به صورت دستی فعال کرده باشند و باید مراحل مربوط به غیر فعال‌سازی آن را انجام دهند.). کاربرانی که از نسخه‌های قدیمی‌تر استفاده می‌کنند نیز باید به نسخه‌های جدیدتر به‌روزرسانی کنند. البته هنوز بررسی اینکه کلید خصوصی در جای دیگر استفاده شده است یا نه اکیداً توصیه می‌شود.

Postfix: نسخه‌های ۲٫۹٫۱۴، ۲٫۱۰٫۸، ۲٫۱۱٫۶ و ۳٫۰٫۲ که در تاریخ ۲۰ جولای ۲۰۱۵ منتشر شدند و تمامی نسخه‌های بعد از آن‌ها در تنظیمات پیش‌فرض خود نسبت به حمله DROWN آسیب‌پذیر نیستند. تنظیمات TLSپیشنهادی که در زیر برای Postfix آورده شده است به منظور جلوگیری از حمله DROWN، کافی است. با این وجود، برای اطمینان از اینکه تنظیمات Postfix شما پشتیبانی از SSLv2 و رمزهای منسوخ و ضعیف را غیرفعال کرده است، شما باید از یک OpenSSL به روز شده استفاده کنید[۷].

# Whenever the built-in defaults are sufficient, let the built-in
# defaults stand by deleting any explicit overrides.
# Disable deprecated SSL protocol versions. See:
# http://www.postfix.org/postconf.5.html#smtp_tls_protocols
# http://www.postfix.org/postconf.5.html#smtpd_tls_protocols
#
# Default in all supported stable Postfix releases since July 2015.
# Defaults for the mandatory variants never allowed SSLv2.
#
smtpd_tls_protocols = !SSLv2, !SSLv3
smtp_tls_protocols = !SSLv2, !SSLv3
lmtp_tls_protocols = !SSLv2, !SSLv3
tlsproxy_tls_protocols = $smtpd_tls_protocols
#
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3
lmtp_tls_mandatory_protocols = !SSLv2, !SSLv3
tlsproxy_tls_mandatory_protocols = $smtpd_tls_mandatory_protocols
# Disable export and low-grade ciphers. See:
# http://www.postfix.org/postconf.5.html#smtpd_tls_ciphers
# http://www.postfix.org/postconf.5.html#smtp_tls_ciphers
#
# Default in all supported stable Postfix releases since July 2015.
# smtpd_tls_ciphers = medium smtp_tls_ciphers = medium
# Enable forward-secrecy with a 2048-bit prime and the P-256 EC curve. See
# http://www.postfix.org/FORWARD_SECRECY_README.html#server_fs
# http://www.postfix.org/postconf.5.html#smtpd_tls_dh1024_param_file
# http://www.postfix.org/postconf.5.html#smtpd_tls_eecdh_grade
#
# The default DH parameters use a 2048-bit strong prime as of Postfix 3.1.0.
#
smtpd_tls_dh1024_param_file=${config_directory}/dh2048.pem
smtpd_tls_eecdh_grade = strong
# Trimmed cipherlist improves interoperability with old Exchange servers
# and reduces exposure to obsolete and rarely used crypto. See:
# http://www.postfix.org/postconf.5.html#smtp_tls_exclude_ciphers
# http://www.postfix.org/postconf.5.html#smtpd_tls_exclude_ciphers
#
smtp_tls_exclude_ciphers =
EXPORT, LOW, MD5,
aDSS, kECDHe, kECDHr, kDHd, kDHr,
SEED, IDEA, RC2 smtpd_tls_exclude_ciphers =
EXPORT, LOW, MD5, SEED, IDEA, RC2

کاربران سرورHTTP Apache: اگر شما از یک سرور Apache HTTP استفاده می‌کنید که کلیدهای مورد استفاده در آن با دیگر سرویس‌ها به اشتراک گذاشته نشده است، و سرور شما Apache https 2.4x را اجرا می‌کند، شما نسبت به حمله DROWN آسیب‌پذیر نخواهید بود. چراکه httpd 2.4 بدون هیچ قید و شرطی SSLv2 را غیرفعال کرده است. اگر که سرور شما Apache https 2.2.x را اجرا می‌کند، SSLv2 به صورت پیش‌فرض پشتیبانی می‌شود و شما احتمالاً در معرض خطر حمله DROWN قرار دارید. شما باید از اینکه در تنظیمات خود SSLv2 را غیرفعال کرده‌اید اطمینان حاصل کنید[۸ و ۹].

دیگر نرم‌افزارها و سیستم‌عامل‌های تحت تأثیر این حمله عبارت‌اند از: Ngnix، Debian و Red Hat

مرورگرها و دیگر سرویس‌گیرندگان: هیچ‌ راه‌کار عملی به منظور جلوگیری از حمله DROWN توسط مرورگرهای وب یا دیگر نرم‌افزارهای سرویس‌گیرنده وجود ندارد. تنها اپراتورهای سرورها امکان این را دارند تا از این حمله جلوگیری کنند.

مقاله کاملی که به تشریح فنی و دقیق این حمله پرداخته است در اینجا آورده شده است[۱۰].

۳-۲ آنالیز فنی حمله DROWN (CVE-2016-0800)

از لحاظ فنی، DROWN یک فرم جدید از حمله cross-protocol Bleichenbacher padding oracle است. این موضوع به مهاجمان اجازه می‌دهد تا ارتباطات TLS قطع شده را رمزگشایی کنند. این کار از طریق ارتباطات دستکاری شده خاص با یک سرویس‌دهنده SSLv2 که از کلید خصوصی مشابه استفاده می‌کند، انجام می‌شود.

مهاجم کار خود را با مشاهده چند صد ارتباط مابین قربانی و سرویس‌دهنده آغاز می‌کند. مهاجم در نهایت قادر است یکی از آن‌ها را رمزگشایی کند. جمع‌آوری این تعداد زیاد ارتباط ممکن است شامل قطع ترافیک به مدت طولانی یا گول زدن کاربر با مشاهده یک وب‌سایت که به سرعت تعداد زیادی ارتباط با یک وب‌سایت دیگر در زمینه برقرار می‌کند، صورت گیرد. این ارتباطات می‌توانند از هر نسخه‌ای از پروتکل SSL/TLS استفاده کنند که شامل TLS 1.2 نیز می‌شود؛ البته تا زمانی که آن‌ها از روش تبادل کلید RSA رایج استفاده می‌کنند. در یک تبادل کلید RSA، یک سرویس‌گیرنده یک کلید جلسه تصادفی را انتخاب کرده که توسط RSA و کلید عمومی سرویس‌دهنده رمزنگاری‌شده و به سرویس‌دهنده ارسال می‌کند.

در مرحله بعد مهاجم، به طور مداوم به سرویس‌دهنده SSLv2 متصل شده و پیام‌های handhskae به‌خصوص دست‌کاری شده را با تنظیماتی به پیام رمزی RSA از طریق ارتباطات قربانی ارسال می‌کند (این فرآیند قابل انجام است چراکه unpadded RSAقابل انعطاف است). روشی که سرویس‌دهنده به هر کدام از این‌ها پاسخ می‌دهد بستگی به این دارد که متن رمز شده تنظیم شده به یک پیام متنی به طور درستی رمزگشایی شود. از آنجاکه مهاجم اطلاعی در ارتباط با کلید خصوصی سرویس‌دهنده ندارد، او دقیقاً نمی‌داند که پیام متنی چه خواهد بود، اما روشی که سرویس‌دهنده پاسخ می‌دهد در نهایت اطلاعات مورد نیاز را در مورد کلید‌های امنیتی که به منظور ارتباطات TLS فرد قربانی استفاده می‌شود، برای مهاجم افشا می‌کند.

روشی که این اطلاعات به بیرون درز می‌کند می‌تواند یکی از این دو حالت باشد:

در اکثر انواع حملات DROWN، این حمله از یک نقطه ضعف بنیادین در پروتکل SSLv2 استفاده می‌کند که مرتبط با رمزنگاری export-grade است که معرفی شده بود تا با محدودیت‌های دولت ایالات‌متحده در دهه ۹۰ مطابقت داشته باشد. مهاجم از یک رمز استفاده می‌کند که شامل تنها ۴۰ بیت از کلید امنیتی رمزنگاری شده RSA است. مهاجم می‌تواند بگوید که آیا متن رمزی اصلاح شده آن به طور درستی تشکیل شده یا نه؛ برای این کار باید متن رمزی اصلاح شده را با پاسخ‌های سرویس‌دهنده مقایسه کند که ۲^۴۰ احتمال می‌شود (عدد نسبتاً بزرگی به منظور انجام محاسبات است). اما یک فرد می‌تواند با کمک GPU های ارزان این محاسبه را انجام دهد. درمجموع تقریباً ۴۰۰۰۰ ارتباط و ۲^۵۰ عدد محاسبه مورد نیاز است تا یکی از ۹۰۰ ارتباط TLS که متعلق به قربانی است، رمزگشایی شود. اجرای محاسبات به منظور حمله کامل با استفاده Amazon EC2 در حدود ۴۴۰ دلار هزینه دربردارد.
بیشتر سرویس‌دهندگان که به حمله DROWN آسیب‌پذیر هستند نسبت به یک اشکال در OpenSSL نیز حساس هستند که نتیجه آن اجرای یک نسخه از حمله خواهد بود که بسیار ارزان‌تر است. در این مورد خاص، یک مهاجم می‌تواند پیام‌های خود را دست‌کاری کند و درنتیجه او به سرعت خواهد فهمید که فرم درستی از پیام را انتخاب کرده است یا نه، بدون اینکه نیاز به محاسبات طولانی داشته باشد. در این مورد، مهاجم در مجموع نیاز به حدود ۱۷۰۰۰ ارتباط دارد که یک کلید از ۲۶۰ کلید مربوط به ارتباطات TLS را از قربانی به دست آورد و این محاسبات در کامپیوترهای با سرعت بالا، کمتر از ۱ دقیقه طول می‌کشد.

این مورد خاص از پیچیدگی توسط رمزنگاری export-grade معرفی شده است. این اشکال موجود در OpenSSL به مهاجم اجازه می‌دهد تا پارامترهای رمزنگاری export-grade و non-export-grade را به منظور بهره‌برداری از روش‌های غیرمنتظره در یک کد، با یکدیگر مخلوط کند.

این حالت از حمله به اندازه کافی سریع است تا به یک حالت حمله آنلاین man-in-the-middle (MitM) اجازه دهد و مهاجم می‌تواند یک سرویس‌دهنده آسیب‌پذیر را برای سرویس‌گیرنده قربانی جعل هویت کند. از مزیت‌های دیگر این اشکال برای فرد حمله‌کننده این است که یک مهاجم می‌تواند سرویس‌گیرنده و سرویس‌دهنده را مجبور کند تا از تبادل کلید RSA استفاده کنند و در مرحله بعد می‌تواند ارتباط را رمزگشایی کند، حتی اگر آن‌ها به طور طبیعی یک رمز دیگر را ترجیح دهند. این امر به مهاجم اجازه می‌دهد که ارتباطات بین مرورگرهای جدید و سرویس‌دهندگان را که روش‌های تبادل کلید perfect-forward-secret مانند DHE یا ECDH را ترجیح می‌دهند، هدف قرار داده و بشکند.

۳ سؤالات متداول در ارتباط با آسیب‌پذیری CVE-2016-0800 یا حمله DROWN

در این بخش تمامی سؤالات متداولی که در ارتباط با حمله DROWN و آسیب‌پذیری CVE-2016-800 است آورده شده است.

چه CVE هایی در ارتباط با حمله DROWN منتشر شده‌اند؟

اصل حمله DROWN به عنوان CVE-2016-0800 نام‌گذاری شده است. همچنین حمله DROWN توسط پیاده‌سازی دو آسیب‌پذیری دیگر در OpenSSL به مراتب بدتر می‌شود. آسیب‌پذیری CVE-2015-3197 که بر روی نسخه‌های OpenSSL قبل از ۱٫۰٫۲f و ۱٫۰٫۱r تأثیرگذار است [۱۱] و به یک مهاجم DROWN اجازه می‌دهد تا از طریق غیرفعال کردن دنباله‌های رمز SSLv2 به سرویس‌دهنده متصل شود درحالی‌که در سرویس‌دهنده گزینه پشتیبانی از SSLv2 فعال باشد. همچنین آسیب‌پذیری CVE-2016-0703 که بر روی نسخه‌های OpenSSL قبل از ۱٫۰٫۲a، ۱٫۰٫۱m، ۱٫۰٫۰r و ۰٫۹٫۸zf تأثیرگذار است [۱۲] و به طور قابل‌توجهی زمان و هزینه انجام حمله DROWN را کاهش می‌دهد.

میزان پیچیدگی انجام این حمله چقدر است؟ آیا این حمله عملی است؟

ما قادر خواهیم بود این حمله را علیه نسخه‌هایی از OpenSSL که دارای آسیب‌پذیری CVE-2016-0703 هستند، توسط یک کامپیوتر و در کمتر از ۱ دقیقه بهره‌برداری کنیم. همچنین برای سرویس‌دهنده‌هایی که دارای این اشکال به‌خصوص نیستند، نوع عمومی این حمله که در برابر تمامی سرویس‌دهندگان SSLv2 کار می‌کند، با پرداخت هزینه‌ ۴۴۰ دلاری در کمتر از ۸ ساعت قابل انجام است.

چه سایت‌های معروفی تحت تأثیر این آسیب‌پذیری قرار داشتند؟

در جدول زیر لیست ۱۰ سایت معروف که در رده‌بندی ۱۰۰ سایت اول بر اساس رده‌بندی Alexa قرار دارند و تحت تأثیر این آسیب‌پذیری قرار داشتند، آورده شده است:

Alexa

آیا در حال حاضر این آسیب‌پذیری توسط مهاجمان مورد بهره‌برداری قرار می‌گیرد؟

هیچ دلیلی مبنی بر اینکه بعد از افشا شدن این آسیب‎‌پذیری، حمله DROWN توسط مهاجمان در سطح اینترنت استفاده نشده باشد وجود ندارد. ازآنجاکه در حال حاضر جزئیات این آسیب‌پذیری نیز به صورت عمومی افشا شده است، مهاجمان در هر لحظه می‌توانند از آن استفاده کنند و قویاً توصیه می‌شود که کاربران اقدامات امنیتی توضیح داده شده در قبل را جهت جلوگیری از این حمله جدی بگیرند.

پروتکل SSLv2 در حدود ۲۰ سال است که ناامن شناخته شده است، چرا آسیب‌پذیری کشف شده بر روی آن دارای اهمیت زیادی است؟

در حقیقت این درست که SSLv2 برای مدت طولانی ضعیف شناخته شده بود و این برای زمانی بود که سرویس‌دهندگان و گیرندگان برای ارتباط از آن استفاده می‌کردند و در حال حاضر تقریباً تمامی سرویس‌گیرندگان جدید از پروتکل‌های جدیدتر استفاده می‌کنند. اما حمله DROWN نشان داد که صرف فعال بودن گزینه SSLv2 حتی اگر هیچ سرویس‌گیرنده‌ قانونی‌ای از آن استفاده نکند یک نوع تهدید برای سرویس‌دهندگان و گیرندگان جدید محسوب می‌شود. این امر به مهاجم اجازه می‌دهد تا ارتباطات جدید TLS را بین سرویس‌دهندگان و سرویس‌گیرندگان جدید و به روز شده نیز توسط فرستادن پیام به هر سرویس‌دهنده‌ای که از SSLv2 پشتیبانی می‌کند و از کلید خصوصی مشابه استفاده می‌کند؛ رمزگشایی کند.

آیا حمله DROWN به مهاجم اجازه می‌دهد تا کلید خصوصی سرویس‌دهنده را بدزدد؟

خیر؛ حمله DROWN به مهاجم اجازه می‌دهد که یک ارتباط را در یک زمان رمزگشایی کند. مهاجم به‌هیچ‌وجه نمی‌تواند کلید خصوصی سرور را کشف کند.

آیا می‌توان از حمله DROWN به منظور اجرای حمله MitM استفاده کرد؟

بله؛ بعضی از انواع حمله DROWN را می‌توان به منظور انجام حمله MitM در برابر TLS یا QUIC استفاده کرد. جزئیات بیشتر این حمله در مقاله فنی مربوطه در بخش‌های ۵٫۳ و ۷ آورده شده است[۱۰].

آیا Perfect Forward Secrecy از حمله DROWN جلوگیری می‌کند؟

شاید کمی عجیب باشد ولی جواب این سؤال منفی است. نوعی از این حمله که به منظور حمله MitM استفاده می‌شود می‌تواند به مهاجمان اجازه دهد تا سرویس‌دهندگان و سرویس‌گیرندگانی که روش‌های تبادل کلید non-RSA را ترجیح می‌دهند، مورد هدف قرار دهد. بخش‌های ۵٫۳ و ۷ را در مقاله فنی مربوط به حمله DROWN مطالعه کنید[۱۰].

آیا به منظور جلوگیری از حمله DROWN نیاز به گرفتن گواهی‌نامه جدید برای سرور وجود دارد؟

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

آیا باید مرورگر را به‌روزرسانی کرد؟

خیر. هیچ راه‌کار عملی برای مرورگرهای وب یا دیگر نرم‌افزارهای سرویس‌گیرنده وجود ندارد تا بتواند از حمله DROWN جلوگیری کند. تنها اپراتورهای سرور قادر به اقدامی علیه حمله DROWN هستند.

من فایروالی در اختیار دارم که قابلیت فیلتر کردن ترافیک SSLv2 را دارد، آیا باید این ترافیک را فیلتر کنم؟

بله. این راهکار یک راه‌حل معقول است. اگرچه این روش باعث جلوگیری از پیدا کردن سرورهای آسیب‌پذیر توسط پویش‌گرها می‌شود. بهتر است که در ابتدا از پویش‌گرها استفاده کرده و سرورهای آسیب‌پذیر را پیدا کنید و سپس اقدام به فیلتر کردن ترافیک SSLv2 کنید. شما همچنین باید از اقدامات پیشگیرانه که در این مقاله توضیح داده شده است استفاده کنید.

آیا امکان تشخیص اینکه حمله DROWN مورد بهره‌برداری علیه ما قرار گرفته است یا نه وجود دارد؟

احتمالاً. اگر شما یک سرور را راه‌اندازی کنید و بتوانید مطمئن باشید که هیچ‌کس تعداد زیادی از ارتباطات SSLv2 را با هیچ‌یک از سرویس‌دهندگان شما برقرار نکرده است (برای مثال از طریق بررسی IDS یا logهای سرور)؛ پس شما مورد حمله قرار نگرفته‌اید. logهای شما ممکن است تعداد کمی ارتباطات SSLv2 را از پویش‌گرهای در سطح اینترنت که توسط محققان طی چند ماه گذشته برای بررسی میزان شیوع این آسیب‌پذیری انجام شده، نشان دهند.

سرور HTTPS به صورت سازگار با PCI گواهی شده است، در نتیجه ما می‌دانیم که گزینه SSLv2 بر روی آن غیرفعال است. آیا همچنان نیاز به اقدامات پیشگیرانه وجود دارد؟

بله. حتی اگر شما مطمئن باشید که گزینه SSLv2 بر روی سرور HTTPS شما غیرفعال است؛ شما ممکن است مجدداً از کلید خصوصی خود بر روی یک سرور دیگر (مانند سرویس‌دهنده پست الکترونیک) استفاده کنید که از SSLv2 پشتیبانی می‌کند. اکیداً پیشنهاد می‌شود که به صورت دستی تمام سرورهایی که از کلید خصوصی شما استفاده می‌کنند را به طور دقیق بررسی کنید.

در صورت استفاده از یک دستگاه جاسازی شده که اجازه غیرفعال کردن SSLv2 را به ما نمی‌دهد و ما قادر به متوقف کردن آن نباشیم، چکار باید بکنیم؟

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

سایت‌هایی مانند SSLLabs یا SSLCheck می‌گویند که گزینه SSLv2 در یک سرور غیرفعال است؛ آیا برای در امان بودن از حملات، در همین حد بررسی کافی است؟

متأسفانه خیر؛ چنین سایت‌هایی فقط این گزینه را بررسی می‌کنند که سرور HTTPS شما مستقیماً SSLv2 را پشتیبانی می‌کند یا خیر. اما شما همچنان در معرض خطر هستید اگر که گواهی‌نامه شما یا کلید شما در جاهای دیگر بر روی سروری که از SSLv2 پشتیبانی می‌کند، مورد استفاده قرار گیرد. مثال رایج این امر شامل SMTP، IMAP و POP می‌شود که سرورهای پست الکترونیک هستند و همچنین سرورهای HTTPS ثانویه که برای برنامه‌های تحت وب خاص مورد استفاده قرار می‌گیرند.

شما همچنین می‌توانید از ابزارهای پویش‌گر استفاده کنید[۱۳]. اما این ابزارها تنها پشتیبانی از SSLv2 را بر روی یک پورت واحد تشخیص می‌دهند. این ابزارها قادر به شناسایی سناریوهای مشترک نیستند که برای مثال یک وب‌سرور که از SSLv2 پشتیبانی نمی‌کند همچنان آسیب‌پذیر است چراکه کلید عمومی خود را با یک سرویس‌دهنده پست الکترونیک که از SSLv2 پشتیبانی می‌کند، به اشتراک گذاشته است.

چرا بعضی از ابزارهای شناسایی، SSLv2 را بر روی سرور فعال نشان می‌دهند و بعضی دیگر نه؟

این امر به این علت است که با توجه به آسیب‌پذیری CVE-2015-3197، این امکان وجود دارد که OpenSSL همچنان ارتباطات SSLv2 را قبول کند حتی اگر تمامی رمزهای SSLv2 غیرفعال باشند.