بازگشت تهدید اوراکلِ Bleichenbacher

چکیده

بسیاری از میزبان‌های وب همچنان به یکی از قدیمی‌ترین حملات علیه RSA در TLS آسیب‌پذیر هستند. ما نشان دادیم که آسیب‌پذیری RSA از نوع Bleichenbacher که از سال ۱۹۹۸ به وجود آمده است هنوز در اینترنت بسیار رایج بوده و بر روی یک سوم از ۱۰۰ دامنه برتر در لیست ۱ میلیون سایت برترِ Alexa تأثیرگذار است که در میان آن‌ها سایت‌های فیس‌بوک و Paypal نیز قرار دارند. ما محصولات آسیب‌پذیر را از حداقل ۸ تولیدکننده مختلف و پروژه منبع باز کشف کردیم که در میان آن‌ها می‌توان به F5 ،Critix ،Radware، سیسکو، Erlang ،Bounty Castle و WolfSSL اشاره کرد. علاوه بر این ما با امضای یک پیام با کلید خصوصی گواهی‌نامه HTTPS دامنه facebook.com، بهره‌برداری عملی از این حمله را ثابت کردیم. درنهایت، ما در مورد اقدامات پیشگیرانه علیه حملات Bleichenbacher در TLS بحث می‌کنیم و توصیه می‌کنیم تبادل کلید^(۱) رمزگذاری RSA در TLS و PKCS # 1 v1.5 استاندارد را منسوخ کنید.

مقدمه

در سال ۱۹۹۸ Daniel Bleichenbacher یک حمله‌ی متنِ رمز شده انتخابیِ تطبیقی^(۲) بر روی رمزنگاری RSA PKCS #1 v1.5 که در SSL استفاده می‌شود را منتشر کرد[۱۱]. در این حمله مهاجم از یک سرور آسیب‌پذیر به‌عنوان اوراکل استفاده می‌‌کند و از آن به‌صورت پی‌درپی با متون رمزنگاری‌شده سؤال می‌پرسد. اوراکل به هر سؤال^(۳) با توجه به صحت متن رمز شده پاسخ درست یا غلط می‌دهد. این امر به مهاجم اجازه می‌دهد تا متن رمز شده اختیاری را بدون داشتن کلید خصوصی و با استفاده از الگوریتم Bleichenbacher برای بهره‌برداری از قالب v1.5 PKCS #1 رمزگشایی کند.

به‌جای به‌روزرسانی به  [۲۷]RSA-OAEP، طراحان TLS تصمیم گرفتند تا در نسخه‌های بعدی TLS از RSA PKCS # 1 v1.5 استفاده کنند و اقدامات پیشگیرانه خاصی را اعمال کردند[۲، ۱۷ و ۳۱]. این اقدامات پیشگیرانه نشان می‌دهند که سرورها همیشه باید به پیام‌های هشدار عمومی پاسخ دهند. هدف این است که توسط غیرممکن ساختن تشخیص متون رمزنگاری‌شده معتبر از نامعتبر مانع از این حمله شد.

پیاده‌سازی نادرست اقدامات پیشگیرانه حمله Bleichenbacher می‌تواند عواقب جبران‌ناپذیری به دنبال داشته باشد و می‌تواند پروتکل‌های دیگر را نیز در معرض خطر قرار دهد. برای مثال Jager ،Schwenk و Somorovsky نشان دادند که صرف وجود یک پیاده‌سازی آسیب‌پذیر، می‌توان از پروتکل‌های متداول برای حمله به پروتکل‌های مدرن مانند QUIC و TLS 1.3 که از تبادل کلید بر پایه رمزنگاری RSA پشتیبانی نمی‌کنند نیز استفاده کرد[۲۲]. Aviram و همکاران نیز حمله DROWN را منتشر کردند که یک نوع حمله‌ی Bleichenbacher بر روی SSLv2 است^(۴).

با توجه به اهمیت بالای این حمله، ارزیابی اعمال اقدامات پیشگیرانه در کتابخانه‌های TLS از اهمیت بالایی برخوردار است. محققان متعددی بر روی ارزیابی حملات Bleichenbacher در زمینه TLS تمرکز داشتند. بااین‌حال، این ارزیابی‌ها عمدتاً بر روی ارزیابی این حملات در پیاده‌سازی‌های منبع باز TLS متمرکز بودند.

Meyer و همکاران نشان دادند که برخی از پشته‌های^(۵) TLS جدید به انواع حمله Bleichenbacher آسیب‌پذیر هستند[۲۶].

به‌عنوان‌مثال، پیاده‌سازی Java TLS به دلیل اداره خطاهای کدگذاری^(۶) آسیب‌پذیر بود و دیگر پیاده‌سازی‌ها از طریق اوراکل‌های مبتنی بر زمان آسیب‌پذیر بودند. در سال ۲۰۱۵، Somorovsky کشف کرد که MatrixSSL نیز آسیب‌پذیر است[۳۳].

درحالی‌که حملات Bleichenbacher در موارد متعدد و در انواع گوناگون یافت شده‌اند، ما از تحقیقات اخیر در تلاش برای شناسایی پیاده‌سازی‌های TLS آسیب‌پذیر در سطح اینترنت، آگاه نیستیم. با توجه به این حقیقت که بیشتر پیاده‌سازی‌های منبع باز مطابق ارزیابی‌های اخیر ایمن هستند[۲۶ و ۳۳]، امکان دارد این تصور به وجود آید که یک ارزیابی، بسیاری از پیاده‌سازی‌های آسیب‌پذیرِ جدید را آشکار نخواهد کرد. اما موضوع این نیست. ما یک ابزار جستجوی سیستماتیک را تولید کردیم که به ما امکان شناسایی چندین میزبان آسیب‌پذیر TLS را می‌دهد. بسیاری از یافته‌ها از دیدگاه تحقیقاتی جالب هستند، زیرا رفتارهای مختلف سرور را آشکار می‌کنند یا کانال‌های جانبی^(۷) جدید را نشان می‌دهند که به‌طور خاص به‌وسیله تغییر جریان پروتکل TLS به وجود می‌آیند.

ما یافته‌های خود را با تأمین‌کننده‌های آلوده‌شده به اشتراک گذاشتیم و تا جایی که امکان داشت سرورهای آسیب‌پذیر را شناسایی کردیم. این آسیب‌پذیری‌ها در فایروال‌ها و سرورهای معروف مانند F5 ،Citrix، سیسکو و Radware حضور داشتند. یکی از معروف‌ترین وب سرورهای آلوده‌شده فیس‌بوک بود. ما یک حمله را به همراه اثبات ادعای آن پیاده‌سازی کردیم که به ما اجازه داد که یک پیام را با کلید خصوصی گواهی‌نامه صفحه وب فیس‌بوک امضا کنیم. درنهایت، ما در مورد اقدامات پیشگیرانه پیشنهاد شده در TLS 1.2  بحث کردیم[۳۱] و این امکان وجود دارد که تبادل کلید مبتنی بر رمزنگاری RSA را از رده خارج‌شده بدانیم.

۱ تبادل کلید TLS-RSA

حمله Bleichenbacher بر روی تبادل کلید TLS-RSA قابل اجرا است. این تبادل کلید در تمام دنباله‌های رمز^(۸) که نام آن‌ها با TLS RSA شروع می‌شود وجود دارد (به‌عنوان‌مثال TLS RSA WITH AES 128 CBC SHA). جریانِ پیامِ یک تبادل کلید RSA که در TLS پیاده‌سازی شده است، در شکل ۱ نشان داده شده است[۳۱].

شکل ۱: دست‌تکانی TLS-RSA

دست تکانی^(۹) TLS توسط یک مشتری TLS با یک پیام ClientHello آغاز می‌شود. این پیام حاوی اطلاعاتی درباره نسخه TLS و یک لیست از دنباله‌های رمز پشتیبانی شده است. اگر سرور، رمز و پروتکلی را که توسط مشتری پشتیبانی می‌شود به اشتراک بگذارد، پیام ارسال‌شده با یک پیام ServerHello پاسخ داده می‌شود و دنباله رمز انتخاب‌شده و دیگر پارامترهای ارتباطی را نشان می‌دهد. سرور با ارسال گواهی‌نامه خود در غالب پیام Certificate ادامه می‎دهد و پایان پیام خود را با پیام ServerHelloDone اعلام می‌کند. سپس مشتری یک پیام ClientKeyExchange را که حاوی یک premaster مخفی است و با استفاده از کلید موجود در گواهی‌نامه سرور به‌صورت RSA رمزگذاری شده است را ارسال می‌کند. تمامی کلیدهای ارتباطی بعدی از این premaster مخفی مشتق می‌شوند. دست‌تکانی با ارسال پیام‌های ChangeCipherSpec و Finished به هر دو طرف، به آن‌ها خاتمه می‌دهد. ChangeCipherSpec نشان می‌دهد که همکار^(۱۰)، پیام‌های بیشتری را که با کلیدها و الگوریتم‌های رمزنگاریِ مذاکره شده^(۱۱) محافظت می‌شوند، ارسال خواهد کرد. پیام Finished پیام‌های پروتکل‌های تبادل شده را اعتبارسنجی می‌کند.

۲ حمله Bleichenbacher

حمله Bleichenbacher بر روی SSL بر پایه ۲ رکن اصلی است. اولی قابلیت انعطاف RSA است که به هر کسی با یک کلید عمومی RSA اجازه می‌دهد تا متون واضح^(۱۲) رمزنگاری‌شده را ضرب^(۱۳) کند. دومی ماهیت تحمل^(۱۴) قالب پوده‌گذاری شده RSA PKCS # 1 v1.5 است که اجازه می‌دهد یک مهاجم پیام‌های معتبر با احتمال بالا بسازد.

ما فرض می‌کنیم (N,e) یک کلید عمومی RSA باشد که N دارای طول بایت l باشد که (N|=l|) و با کلید رمز مربوطه d=1⁄(e) modϕ(N) باشد. || نشان‌دهنده پیوند بایت^(۱۶) است.

۱-۲ استاندارد RSA PKCS #1 v1.5

RSA PKCS # 1 v1.5 شرح می‌دهد که چگونه یک رشته پوده‌گذاری شده تصادفیِ PS برای یک پیام k قبل از رمزنگاری با RSA تولید می‌شود[۲۳]:

1. رمز کننده یک رشته پوده‌گذاری شده‌ی PS را به‌صورت تصادفی تولید می‌کند که PS|>8| و |PS|=l – 3 – |k| و ۰x00∉{PS₁,…,PS_|PS|}
2. بلاک پیام^(۱۷) را به این صورت محاسبه می‌کند: m=00||02||PS||00||k
3. درنهایت، متن رمز شده^(۱۸) را به این صورت محاسبه می‌کند: c=m^e mod N

فرایند رمزگشایی این مراحل را به نحوی آشکار بازمی‌گرداند. رمزگشا^(۱۹) از کلید خصوصی خود برای انجام رمزگشایی RSA استفاده می‌کند، PKCS # 1 v1.5 پوده‌گذاری شده را بررسی می‌کند و پیام k را استخراج می‌کند.

۲-۲ شهود حمله

حمله Bleichenbacher به مهاجم اجازه می‌دهد تا متن واضح رمزنگاری‌شده m را از متن رمز شده c بازیابی کند. برای اجرای حمله، مهاجم از یک اوراکل استفاده می‌کند که c را رمزگشایی کرده و اگر متن واضح با  آغاز شود با ۱ پاسخ می‌دهد، و در غیر این صورت با ۰:

ο(c)=1 if m=c^d mod N starts with 0x0002 and 0 othertwise

چنین اوراکلی می‌تواند از یک سرور رمزگشایی متون رمز RSA PKCS # 1 v1.5 ساخته شود.

الگوریتم Bleichenbacher بر پایه قابلیت انعطاف^(۲۰) طرح رمزنگاری RSA است. به‌طورکلی، این ویژگی به مهاجم اجازه می‌دهد تا از یک مقدار صحیح s استفاده کند و ضرب‌های متن واضح را اجرا کند:

C’=(c.s^e) mod N=(ms)^e mod N

حالا یک PKCS # 1 v1.5 را مطابق با پیام c=m^e mod N در نظر بگیرید. مهاجم با یک مقدار کوچک s شروع می‌کند. او مرتباً s را افزایش می‌دهد، ‘c را محاسبه می‌کند و اوراکل را جستجو می‌کند. هنگامی‌که اوراکل با ۱ پاسخ دهد، او می‌فهمد که:

۲B≤ms-rN<3B

برای بعضی از r های محاسبه‌شده در جایی که B=2 ^(8(l-2)). این به مهاجم اجازه می‌دهد تا مجموعه راه‌حل‌های ممکن را کاهش دهد. با انتخاب s جدید به‌طور مرتب، جستجوی اوراکل و محاسبه مقادیر r جدید، مهاجم راه‌حل‌های ممکن m را کاهش می‌دهد تا جایی که فقط ۱ راه‌حل باقی بماند یا زمان تکرار^(۲۱) به‌قدری کوچک شود تا بتوان یک جستجوی brute force را انجام داد. برای جزئیات بیشتر می‌توانید به مقاله اصلی مراجعه کنید [۱۱].

۳-۲ عملکرد حمله و انواع اوراکل

Bleichenbacher در مقاله اصلی خود تخمین زده است که حدود یک‌میلیون درخواست برای رمزگشایی یک متن رمز شده دلخواه مورد نیاز است. بنابراین، این حمله با عنوان «حمله ۱ میلیون پیام» نیز نام‌گذاری شده است. بااین‌حال، با توجه به قدرت اوراکل ارائه‌شده، عملکرد حمله تغییر می‌کند. به‌طورکلی، الگوریتم حمله یک زمان تکرار جدید با هر پاسخ معتبرِ جدید اوراکل پیدا می‌کند. این موضوع اگر که متن رمز شده رمزگشایی‌شده با  آغاز شود، اتفاق می‌افتد. اوراکل اگر با یک پاسخ منفی برای برخی از متون رمز شده‌ی رمزگشایی‌شده که با  آغاز می‌شوند، پاسخ داده شود؛ ضعیف‌تر در نظر گرفته می‌شود. در این سناریو، زمان تکرار جدید پیدا نمی‌شود و مهاجم نیاز دارد تا درخواست‌های بیشتری را ارسال کند. برای مثال این موضوع زمانی اتفاق می‌افتد که پیاده‌سازی مؤکدا قالب PKCS # 1 v1.5 را بررسی کند که نشان می‌دهد ۸ بایت اولِ بعد از ، غیر صفر هستند یا پیاده‌سازی مؤکدا طول کلید پوده‌گذاری نشده^(۲۲) را بررسی کند.

Bardou و همکاران حمله اصلی را بهبود بخشیدند و تأثیر پیاده‌سازی‌های مختلف را بر عملکرد حمله تحلیل کردند[۷]. برای مثال، الگوریتم حمله‌ی بهبودیافته‌ی Bleichenbacher وقتی از قوی‌ترین اوراکل استفاده می‌کند به‌صورت میانگین به ۱۰٫۰۰۰ درخواست نیاز دارد. از سوی دیگر، هنگام استفاده از ضعیف‌ترین اوراکل این الگوریتم به حدود ۱۸٫۰۰۰٫۰۰۰ درخواست نیاز دارد.

برای ساده‌سازی، در این مقاله ما فقط ۲ نوع اوراکل را در نظر گرفتیم: ضعیف و قوی. اوراکل قوی اجازه می‌دهد که یک متن رمز شده دلخواه با کمتر از ۱ میلیون درخواست به‌طور میانگین رمزگشایی شود. چنین اوراکلی می‌تواند توسط یک پیاده‌سازی تأمین شده باشد که اگر متن رمز شده با  شروع شود و شامل یک  در هر موقعیتی باشد، true را بازمی‌گرداند. اوراکل ضعیف منجر به یک حمله با چندین میلیون درخواست می‌شود و می‌تواند توسط یک پیاده‌سازی فراهم شود که بررسی می‌کند آیا بایت  در موقعیت صحیح قرار دارد یا نه. ما از الگوریتم Bleichenbacher اصلی استفاده کردیم [۱۱].

۴-۲ ساختن یک امضا توسط حمله Bleichenbacher

در بیشتر تحقیقات، حمله Bleichenbacher به‌عنوان یک حمله رمزگشایی در نظر گرفته می‌شود. نکته‌ای که کمتر بدان اشاره شده این است که این حمله اجازه می‌دهد تا عملیات کلید خصوصی RSA دلخواه انجام شود. با توجه به دسترسی به یک اوراکل، مهاجم نه‌تنها قادر به رمزگشایی متن‌های رمز شده است، بلکه همچنین می‌تواند پیام‌های دلخواه را با کلید RSA خصوصیِ سرور امضا کند.

برای ایجاد یک امضا با کلید خصوصی سرور، مهاجم ابتدا از یک تابع هش و رمزگذاری مناسب برای پردازش پیام استفاده می‌کند. برای مثال، هنگام ایجاد یک امضای PKCS # 1 v1.5 برای پیام M، نتیجه رمز شده دارای قالب زیر خواهد بود[۲۷]:

EM=0x0001||0xFF…FF∥۰x00||ASN.1(hash(M))

در قالب بالا ()hash یک تابع هشِ رمزنگاری را نشان می‌دهد. خروجیِ تابع هش باید با استفاده از ASN.1 رمزگذاری شود. مهاجم سپس EM را به‌عنوان ورودی الگوریتم Bleichenbacher تعیین می‌کند. به یک معنا، او از پیام امضاشده استفاده می‌کند، مثل ‌اینکه یک متن رمز شده استراق سمع شده^(۲۳) است. نتیجه نهایی این عملیات یک امضای معتبر برای M است.

همچنین لازم به ذکر است که برای ایجاد یک امضا معمولاً وقت بیشتری نسبت به رمزگشایی یک متن رمز شده PKCS # 1 v 1.5 نیاز است. دلیل آن این است که یک مهاجم با یک متن رمز شده PKCS # 1 v1.5 می‌تواند در ابتدا فرض کند که اولین پیام دارای تصدیق امضا^(۲۴) PKCS # 1 v1.5 است. این امر به او اجازه می‌دهد اولین گام را از الگوریتم اصلی حذف کند [۱۱]. از سوی دیگر، با رمزگشایی یک متن رمز شده تصادفی یا ایجاد یک امضا، مهاجم نمی‌تواند فرض کند که اولین درخواست تصدیق امضای PKCS # 1 v1.5 است. برای تصدیق امضای اولین پیامِ PKCS # 1 V1.5، مهاجم باید یک مرحله blinding را اجرا کند [۱۱]. ازآنجاکه این مرحله نیازمند درخواست‌های اوراکل زیادی است، ساختن یک امضا بسیار وقت‌گیر است و فقط زمانی عملی خواهد بود که یک اوراکل قوی در دسترس باشد.

۳ روش اسکن کردن

چالش تحقیق ما این است که یک اسکن مؤثر با استفاده از کمترین درخواست ممکن انجام شود، اما به ما اجازه دهد تا همه آسیب‌پذیری‌های شناخته‌شده را شناسایی کرده و به‌طور بالقوه آسیب‌پذیری‌های جدید را نیز پیدا کنیم. برای این منظور، ما اولین اسکنر را پس از تکنیک‌های مقاله اصلی Bleichenbacher و نتایج تحقیقات زیر [۷، ۲۴ و ۲۶] مدل کردیم. این اسکنر، یک دست‌تکانی TLS-RSA پایه‌ای را اجرا می‌کند (شکل ۱) که شامل قالب‌های مختلف پیام‌های PKCS #1 v1.5 است که در ClientKeyExchange واقع شده‌اند. با این روش، ما قادر خواهیم بود اولین پیاده‌سازی‌های TLS آسیب‌پذیر را شناسایی کنیم. تجزیه‌وتحلیل بیشتر برای شناسایی false positives ممکن، قبل از گزارش این رفتار به فروشندگان و اپراتورهای سایت انجام شد. این تجزیه‌وتحلیل دستی به ما اجازه داد تا مسائل جدید را بیابیم و اسکن‌های TLS بعدی را گسترش دهیم.

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

۱-۳ پیام‌های PKCS # 1 v1.5 در قالب‌های مختلف

برای راه‌اندازی رفتارهای مختلف سرور، پیام‌های ClientKeyExchange ما، حاوی پیام‌های PKCS # 1 v1.5 با قالب‌بندی متفاوت هستند. برای توصیف آن‌ها، نماد زیر را در نظر بگیرید.  نشان‌دهنده پیوند بایت است. version نشان‌دهنده دو بایت نسخه TLS است.  یک رشته تصادفی غیر صفر با طول x را نشان می‌دهد.  یک تابع را نشان می‌دهد که یک رشته پوده‌گذاری شده غیر صفر را تولید می‌کند که در آن ورودی‌ پیام را برای دستیابی به طول کلید RSA پر می‌کند.

با توجه به پیش‌نیازهای عملکرد برای اسکن ما، پنج بردار PKCS # 1 v1.5 را با توجه به تحقیقات قبلی در مورد حملات Bleichenbacher انتخاب کردیم[۱۱، ۷، ۲۶ و ۳۳]. هر پیام باید یک آسیب‌پذیری متفاوت را ایجاد کند:

1. پیام TLSکه به‌درستی قالب‌بندی شده است. این پیام شامل یک PKCS # 1 v1.5 به‌درستی قالب‌بندی شده و پوده‌گذاری شده با ۰x00 در موقعیت صحیح و نسخه TLS صحیح واقع در secret premaster است:

M1=0x0002||pad( )||0x00||version||rnd[46]

M1 باید یک مهاجم را شبیه‌سازی کند که به‌درستی پوده‌گذاری PKCS # 1 v1.5 و نسخه TLS را حدس بزند. گرچه این مورد به‌سختی اتفاق می‌افتد (زیرا احتمال ساختن چنین پیامی کم است)، اما لازم است ارزیابی صحت سرور انجام شود.

2. پوده‌گذاری غلط PKCS # 1 v1.5. این پیام با بایت‌های پوده‌گذاری PKCS # 1 v1.5 نادرست آغاز می‌شود:

M2=0x4117||pad( )

بایت اول نامعتبر در پوده‌گذاری PKCS # 1 v1.5 باید یک رفتار سرور نادرست را همان‌طور که در مقاله اصلی توضیح داده شده است [۱۱]، راه‌اندازی کند.

3. ۰x00 در موقعیت نادرست. این پیام شامل یک قالب PKCS # 1 v1.5 صحیح است اما ۰x00 در یک موقعیت غلط قرار دارد بنابراین secret premaster پوده‌گذاری نشده داری طول نامعتبری خواهد بود:

M3=0x0002||pad( )∥۰x0011

بسیاری از پیاده‌سازی‌ها فرض می‌کنند که مقدار پوده‌گذاری نشده دارای طول صحیح است. اگر مقدار پوده‌گذاری نشده کوتاه‌تر یا طولانی‌تر باشد، می‌تواند موجب راه‌اندازی یک سرریز بافر یا استثنائات داخلی خاص شود و منجر به یک رفتار سرور متفاوت شود. به‌عنوان‌مثال،Meyer  و همکاران چنین پیامی را در هشدارهای مختلف TLS در JSSE (افزونه سوکت ایمن جاوا^(۲۵)) نشان دادند[۲۶].

4. فاقد ۰x00 این پیام با ۰x0002 آغاز می‌شود اما فاقد بایت ۰x00 است:

M4=0x0002||pad( )

استاندارد PKCS # 1 v1.5 نشان می‌دهد که پیام رمزگشایی‌شده همیشه شامل یک بایت ۰x00 است. اگر این بایت ازدست‌رفته باشد، پیاده‌سازی PKCS # 1 v1.5 نمی‌تواند مقدار رمزگذاری شده را unpad کند، که این امر دوباره می‌تواند منجر به یک رفتار سرور متفاوت شود.

5. نسخه TLS نادرست. این پیام شامل یک نسخه TLS نادرست در secret premaster است:

M5=0x0002||pad( )||0x00||0x0002||rnd[46]

M5 باید یک رفتار نامناسب را راه‌اندازی کند که توسط Klima ،Pokorny و Rosa شرح داده شده است[۲۴]. یک نمونه عملی از چنین رفتاری اخیراً در MatrixSSL یافت شد[۳۳]. نسخه آسیب‌پذیر MatrixSSL، این نوع از پیام‌ها را با یک هشدار پارامتر غیرقانونی پاسخ داد. پیام‌های دیگر با یک خطای رمزگشایی پاسخ داده شدند.

۲-۳ جریان‌های پروتکل TLSمختلف

ما مشاهده کردیم چندین پیاده‌سازی که بر اساس جریان پروتکل TLSساخته شده‌اند، به‌طور متفاوت پاسخ داده شدند. به‌طور خاص، هنگام پردازش یک پیام ClientKeyExchange که توسط خودش ارسال شده در مقایسه با زمانی که در ارتباط^(۲۶) با ChangeCipherSpec و Finished فرستاده شده، تفاوت‌هایی در برخی از سرورها مشاهده کردیم.

مثال اولیه این موضوع F5 BIG-IP است. تحت تنظیمات خاص، هنگامی‌که این دستگاه یک ClientKeyExchange نامعتبر بدون پیام‌های دیگر دریافت می‌کند، بلافاصله دست‌تکانی را لغو و ارتباط را قطع می‌کند. در غیر این صورت، در هنگام پردازش ClientKeyExchange به‌درستی فرمت شده، دستگاه منتظر پیام‌های متعاقب ChangeCipherSpec و Finished خواهد بود.

اسکن‌های ما نیز تأیید کرده است که تنها در نظر گرفتن تعدادِ هشدارهای TLS یا زمان‌بندی^(۲۷) به‌عنوان یک کانال جانبی مناسب، کافی نیست. همچنین لازم است مسائل مربوط به وضعیت ارتباط و وقفه‌های زمانی^(۲۸) را بررسی کنید.

۳-۳ دنباله‌های رمز

پیاده‌سازی ابزار اولیه ما در تلاش بود تا با یک دنباله رمز AES-CBC واحد ارتباط برقرار کند. در طول اسکن‌های ما برخی از سرورها را با مجموعه محدودی از دنباله‌های رمز مشاهده کردیم، که برای مثال، تنها از دنباله‌های رمز AES-GCM پشتیبانی می‌کرد. بنابراین ما ابزار خود را تغییر دادیم تا به‌طور پیش‌فرض مجموعه‌ای از دنباله‌های رمز اضافی را ارائه دهیم. این کار تعداد سرورهای آسیب‌پذیرِ شناسایی‌شده را افزایش داد.

علاوه بر سرورهای آسیب‌پذیر جدید، دنباله‌های رمز اضافی سایبری به ما اجازه می‌دادند که رفتار جالبی را مشاهده کنیم. در بعضی موارد، پاسخ به پیام‌های مختلف ClientKeyExchange بسته به دنباله‌های متقارن استفاده شده متفاوت است. به‌عنوان‌مثال، یکی از سرورهای هدف ما پس از پذیرش یک پیام فرمت شده PKCS # 1 v1.5 معتبر هنگام استفاده از دنباله‌های رمز AES-CBC، اتصالات TCP را دوباره تنظیم می‌کند.

هنگام استفاده از دنباله‌های رمز AES-GCM، سرور با یک هشدار TLS 51(خطای رمزگشایی) پاسخ داد. پیام‌های PKCS # 1 v1.5 نامعتبر همیشه و مستقل از دنباله رمز استفاده‌شده منجر به یک وقفه زمانی در ارتباط می‌شود.

۴-۳ نظارت بر پاسخ‌های مختلف سرور

مطابق با استاندارد TLS، سرورهایی که پیام‌های نامعتبر ClientKeyExchange را دریافت می‌کنند[۳۱]، باید دست‌تکانی TLS را ادامه دهند و همیشه با یک هشدار TLS یکسان پاسخ دهند. در تجزیه‌وتحلیل انجام‌شده، ما چندین سرور را مشاهده کردیم که همیشه با هشدارهای TLS مشابه پاسخ داده می‌شوند. اگرچه بعضی‌ها یک پیام هشدار اضافی TLS را در هنگام پردازش یک ClientKeyExchange نامعتبر بازگشت دادند.

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

۵-۳ انجام یک اسکن بر روی سرور

به‌طور خلاصه، ارزیابی سرور ما عمدتاً با سایر تکنیک‌های انتشاریافته[۱۱، ۲۶ و ۳۳] که ما با آن‌‌ها آشنایی داریم، متفاوت است، چراکه ما حالت اتصال را به‌عنوان یک سیگنال کانال جانبی در نظر گرفتیم و با یک جریان پیام غیراستاندارد مورد آزمایش قرار می‌دهیم.

تشخیص اوراکل اسکنر ما در ابتدا با دانلود یک گواهیِ سرورِ هدف کار می‌کند و از آن برای رمزگذاری پنج پیام ClientKeyExchange شامل M1 تا M5 استفاده می‌کند. هر مقدار سپس به‌عنوان بخشی از یک دست‌تکانی استاندارد با یک مقدار Finished که hardcode شده ارسال می‌شود. اگر پاسخ برای هر مورد آزمون یکسان نبود، فرض می‌شود که هدف موردنظر آسیب‌پذیر است. اگر پاسخ‌ها یکسان باشند، سرور با استفاده از همان ClientKeyExchange مجدداً آزمایش می‌شود، اما با یک جریان پیام مختصر شده که ChangeCipherSpec و Finished را حذف می‌کند. پاسخ‌ها دوباره مقایسه می‌شوند و اگر اختلافی مشاهده شد، فرض می‌شود که هدف موردنظر آسیب‌پذیر است. به‌منظور به حداقل رساندن نتایج مثبت کاذب^(۲۹) به علت شرایط شبکه یا سرورهای غیرقابل‌اعتماد، تمام سرورهایی که احتمالاً آسیب‌پذیر هستند، مجدداً مورد آزمایش قرار می‌گیرند تا اوراکل را قبل از گزارش کردن هدف به‌عنوان آسیب‌پذیر، تأیید کنند. این موضوع هنگام شناسایی اوراکل‌های بر پایه وقفه زمانی، مهم است.

هنگام آزمایش با جریان پیام کوتاه شده، ما دریافتیم که تنظیم کردن یک ‌زمان وقفه‌ی سوکتِ مناسب برای مسیر شبکه بین اسکنر و هدف، ضروری است. تست‌ها می‌توانند سریع‌تر و با زمان‌های وقفه کوتاه‌تر انجام شوند، اما این کار می‌تواند در هنگام برخورد با میزبان‌های کندتر یا برخورد با تأخیر شبکه^(۳۰) منجر به بروز رفتار ناسازگار شود. در آزمایش‌های ما، ثابت شد که ۵ ثانیه، زمان وقفه‌ی سوکت قابل‌اعتمادی برای اسکن کردن اینترنت بدون زمان‌های وقفه‌ی دست‌تکانیِ اضافی است. در بعضی از محیط‌ها، ممکن است تمایل به افزایش مدت‌زمان وقفه‌ی سوکت باشد، اما افزایش بیش‌ازحد آن، به نتایج غیرقابل اطمینانی منجر خواهد شد.

۶-۳ تغییرات بیشتر

در طول تحقیقات ما کشف کردیم که با تغییراتی جزئی مانند تغییر دنباله رمز یا استفاده از جریان پیام TLS کوتاه شده، می‌توان سرورهای آسیب‌پذیر بیشتری را کشف کرد. یک اسکن جامع‌تر می‌تواند پیاده‌سازی‌های آسیب‌پذیرِ بیشتری را نشان دهد. بااین‌حال، تعداد بسیار زیادی از تغییرات بالقوه برای آزمایش وجود دارد. به‌عنوان‌مثال، یک نفر می‌تواند سعی کند با دنباله‌های رمز بیگانه^(۳۱) (مانند Camelia)، پسوند‌ها یا انواع جدیدی از جریان‌های پیام، ارتباط برقرار کند.

با ابزار اسکن، ما تلاش کردیم تمام آسیب‌پذیری‌هایی که از آن آگاه هستیم را پیدا کنیم و درعین‌حال از انجام اسکن‌های بیش‌ازحد اجتناب کنیم.

۴ پیاده‌سازی‌های آسیب‌پذیر

۱-۴ فیس‌بوک

در طول جستجوهای اولیه، ما کشف کردیم که میزبان اصلی فیس‌بوک یعنی www.facebook.com آسیب‌پذیر است. این سرور با یک TLS alert 20 یا bad record mac به یک خطا در secret premaster پوده‌گذاری شده^(۳۲) پاسخ داد.  یک خطا در پیشوند PKCS # 1 v1.5 یا در پوده‌گذاری فورا منجر به راه‌اندازی مجدد TCPخواهد شد. ما توانستیم یک رفتار مشابه را بر روی چندین میزبان دیگر که متعلق به فیس‌بوک بودند مانند intagram.com و fbcdn.com نیز مشاهده کنیم.

ما با استفاده از این اوراکل، یک امضای اثبات ادعا تولید کردیم و به همراه توضیح مشکل برای فیس‌بوک ارسال کردیم. فیس‌بوک در عرض یک هفته وصله‌های موردنیاز را برای بستن اوراکل نصب کرد. امضای ساخته‌شده در پیوست A آورده شده است. بااین‌حال، پس از آزمایش بیشتر با جریان‌های پیام‌های مختلف، متوجه شدیم که وصله منتشرشده در جلوگیریِ ما از تمایز بین انواع خطا به‌طور کامل مؤثر نبود. اگر ChangeCipherSpec و Finished به‌طور کامل متوقف شوند، سرور تنها درصورتی‌که ClientKeyExchange به‌درستی رمزگشایی شود، برای این پیام‌ها منتظر می‌ماند. از طرف دیگر خطاهای پوده‌گذاری خاص، منجر به راه‌اندازی یک TCP FIN از سرور می‌شوند. فیس‌بوک همچنین این رفتار را ۱ هفته پس از مطلع شدن از آن، اصلاح کرد. ما ابزار اسکن خود را گسترش دادیم تا این استراتژی تغییر داده‌شده را در نظر بگیریم که در ادامه این مقاله به‌عنوان جریان پیام کوتاه شده به آن اشاره شده است.

فیس‌بوک به ما اطلاع داد که از یک نسخه وصله شده از OpenSSL برای میزبان‌های آسیب‌دیده استفاده می‌کنند و این اشکال در یکی از وصله‌های سفارشی آن‌هاست. بنابراین ما معتقدیم این نوع خاص از آسیب‌پذیری بر روی میزبان‌هایی که متعلق به فیس‌بوک نیستند اثر نمی‌گذارد.

علاوه بر این ما میزبان‌های دیگر آسیب‌پذیر که متعلق به فیس‌بوک بودند را کشف کردیم که به شیوه‌ای متفاوت عمل می‌کردند. این میزبان‌ها پشته‌های TLS را با F5 و Erlang اجرا می‌کردند. تا آنجا که ما اطلاع داریم تمام میزبان‌های آسیب‌پذیر که متعلق به فیس‌بوک بودند، وصله شده‌اند.

۲-۴ F5

بر اساس پاسخ‌های دلگرم‌کننده فیس‌بوک به اولین گزارش‌ها، ما همچنان به اسکن زیرساخت‌های آن‌ها ادامه دادیم و یکی دیگر از رفتار‌های آسیب‌پذیر را کشف کردیم. این بار، رفتار آسیب‌پذیر بر روی یک سرور مربوط به پست الکترونیکی شرکت مشاهده شد که با یک بنر سرور که نشان‌دهنده BIG-IP بود، شناسایی شد. اسکن‌های بیشتر رفتار مشابهی را بر روی دامنه‌های دیگر فاش کردند که مالکان آن‌ها تأیید کردند که دستگاه‌ها از F5 هستند. در طی این تحقیق ما متوجه شدیم که محصولات F5 می‌توانند انواع مختلفی از اوراکل را بر اساس محصول و پیکربندی خاص نمایش دهند. به‌طورمعمول، محصولات F5 به ClientKeyExchange ناقص با یک هشدار TLS 40یا handshake failure پاسخ می‌دهند؛ اما اگر رمزگشایی موفقیت‌آمیز باشد، به ارتباطات اجازه وقفه زمانی می‌دهند. تجزیه‌وتحلیل دقیق پشته‌های F5 TLS همچنین نشان داد که برخی از تنظیمات محصول یک هشدار اضافی TLS را بسته به نوع خطا ارسال می‌کنند.

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

ما به F5 اطلاع دادیم و آن‌ها در ۱۷ نوامبر ۲۰۱۷ یک گزارش امنیتی منتشر کردند[۱۸]. آن‌ها وصله‌هایی را برای همه محصولات پشتیبانی شده‌ی تحت تأثیر منتشر کردند. کد CVE-2017-6168 به این آسیب‌پذیری اختصاص داده شد.

۳-۴ Critix

با تماس با صاحبان صفحات وب متوجه شدیم که بسیاری از پیاده‌سازی‌هایی که ما به‌عنوان آسیب‌پذیر شناسایی کرده‌ایم، توسط دستگاه‌های Citrix Netscaler اجرا می‌شوند. آسیب‌پذیری Netscaler بسته به اینکه آیا اتصال از یک دنباله رمز CBC یا GCM استفاده می‌کند، کمی متفاوت رفتار می‌کند.

برای این آسیب‌پذیری، سیگنال برای یک بلوک رمزگشایی ناقص، یک وقفه زمانی است. این امر حملات عملی را چالش‌برانگیزتر می‌کند، زیرا نیاز به ارسال پیام‌های زیاد و شناسایی وقفه‌های زمانی دارد. این کار احتمالاً نیازمند موازی کردن^(۳۳) حمله است.

کد CVE-2017-17382 به این آسیب‌پذیری اختصاص داده شد. Citrix یک گزارش و به‌روزرسانی‌های موردنیاز را برای دستگاه‌های آلوده‌شده منتشر کرد[۱۵].

۴-۴ Radware

ما کشف کردیم که سرور مورداستفاده در صفحه وبِRadware یعنی radware.com آسیب‌پذیر است. پیام‌هایی که با ۰x0002 شروع نمی‌شوند با یک تنظیم مجدد TCP پاسخ داده شدند. سایر پیام‌ها با یک هشدار TLS 51 (خطای رمزگشایی) پاسخ داده شدند. ما همین مسئله را در یک میزبان کشف کردیم که با توجه به تحقیقات انجام‌شده در گذشته می‌دانستیم توسط یک دستگاه Radware Alteon خدمات‌دهی می‌شود.

ما Radware را در مورد این مسئله آگاه کردیم و آن‌ها این آسیب‌پذیری را با انتشار نسخه‌های ۳۰٫۲٫۹٫۰، ۳۰٫۵٫۷٫۰ و ۳۱٫۰٫۴٫۰ اصلاح کردند[۲۹]. به این آسیب‌پذیری کد CVE-2017-17427 اختصاص داده شده است.

۵-۴ Cisco ACE

ما متوجه شدیم که متعادل‌کننده‌های بار Cisco ACE آسیب‌پذیر هستند. انواع خطاهای مختلف با TLS alert 20 (bad record mac) یا ۴۷ (پارامتر غیرقانونی) پاسخ داده شدند.

سیسکو در سال ۲۰۱۳ فروش و پشتیبانی از دستگاه‌های ACE را متوقف کرد[۱۳]. آن‌ها به ما خبر دادند که برای اصلاح این نقص وصله‌ای منتشر نخواهند کرد. به این آسیب‌پذیری کد CVE-2017-17428 اختصاص داده شده است. بر اساس اسکن‌ها، ما متوجه شدیم که علیرغم عدم پشتیبانی چندین ساله از دستگاه‌های ACE، این دستگاه‌ها هنوز به‌طور گسترده مورداستفاده قرار می‌گیرند.

ما همچنین مشاهده کردیم که میزبان cisco.com و چندین زیر دامنه آن به حملات Bleichenbacher آسیب‌پذیر هستند دقیقاً همان‌طوری که دستگاه‌های ACE آسیب‌پذیر هستند. اگرچه سیسکو برای ما آشکار نساخت که چه محصولاتی برای این دامنه‌ها مورداستفاده قرار می‌گیرند، اما باور ما این است که احتمالاً آن‌ها از دستگاه‌های ACE که خارج از پشتیبانی هستند در زیرساخت‌های شبکه خود استفاده می‌کنند. تمام دنباله‌های رمزی که توسط این دستگاه‌ها پشتیبانی می‌شوند از تبادل کلید رمزنگاری RSA استفاده می‌کنند[۱۴] و با غیرفعال کردن آن، جلوگیری از این آسیب‌پذیری غیرممکن خواهد بود. بنابراین کاربران دستگاه‌های ACE سیسکو که به TLS نیاز دارند، نمی‌توانند این دستگاه‌ها را با یک پیکربندی TLS امن اجرا کنند.

۶-۴ Erlang

ما چند پشته TLS را در نرم‌افزار‌های منبع باز و رایگان بازرسی کردیم. ما کشف کردیم که پیاده‌سازی TLS در زبان برنامه‌نویسی Erlang به خطاهای رمزگشایی مختلف RSA با هشدارهای TLS متفاوت پاسخ می‌دهد. پیام‌هایی که با  شروع نمی‌شوند با یک هشدار TLS 51 (خطای رمزگشایی) و خطاهای دیگر با هشدار TLS 10 (پیام غیرمنتظره) پاسخ داده شدند.

مستقل از آن، ما چند میزبان مورداستفاده توسط واتزاپ (متعلق به فیس‌بوک) را کشف کردیم که با روش مشابهی آسیب‌پذیر بودند، به‌جز اینکه آن‌ها در پاسخ به خطاهای پوده‌گذاری خاص با هشدار TLS 20 (bad  record mac) پاسخ داده می‌شوند، نه ۵۱٫ ما بعداً توسط فیس‌بوک متوجه شدیم که این میزبان‌ها نیز با استفاده از Erlang اداره می‌شوند. ارزیابی ما که این تفاوت‌ها به دلیل نسخه‌های مختلف Erlang به وجود آمده است بعدها توسط توسعه‌دهندگان Erlang تأیید شد. آزمایش‌های آن‌ها نشان داد که نسخه‌های ۱۹ و ۲۰ با هشدار TLS 51/10 درحالی‌که نسخه ۱۸ با هشدار TLS 51/20 پاسخ داده شدند همان‌طور که در دامنه واتزاپ مشاهده شد.

توسعه‌دهندگان Erlang وصله‌های موردنظر را با انتشار نسخه‌های ۱۸٫۳٫۴٫۷ [۳]، ۱۹٫۳٫۶٫۴ [۴] و ۲۰٫۱٫۷ [۵] ارائه کردند. به این آسیب‌پذیری کد CVE-2017-1000385 اختصاص داده شده است.

۷-۴ Bounty Castle

ما ابزار تست خود را با CERT/CC به اشتراک گذاشتیم و آن‌ها آن را با توسعه‌دهندگان پیاده‌سازی‌های TLS مختلف به اشتراک گذاشتند. ما متوجه شدیم که اجرای TLS Java از Bounty Castle به یک نوع از ROBOT آسیب‌پذیر است. ارسال یک ClientKeyExchange که در آن فسخ کننده^(۳۴) صفر پوده‌گذاری در موقعیت درستی نبود، منجر به یک هشدار TLS 80 (خطای داخلی) می‌شد. خطاهای دیگر باعث شد که سرور پیام ChangeChipSpec را ارسال کند.

این آسیب‌پذیری فقط هنگامی ظاهر می‌شود که Bounty Castle از JCE API در جاوا برای عملیات رمزنگاری استفاده کند. Bounty Castle یک API قدیمی (org.bouncycastle.crypto.tls) و یک API جدید (org.bouncycastle.tls) پیشنهاد می‌دهد. این آسیب‌پذیری فقط هنگامی ظاهر می‌شود که API جدید در ترکیب با JCE API استفاده شود. API قدیمی از JCE API پشتیبانی نمی‌کند.

Bounty Castle این آسیب‌پذیری را با انتشار نسخه ۱٫۵۹ برطرف کرده است. به این آسیب‌پذیری کد CVE-2017-13098 اختصاص داده شده است.

۸-۴ WolfSSL

WolfSSL یک پشته TLS برای دستگاه‌های جاسازی شده است. با جریان پیام کوتاه شده، ما یک وقفه زمانی برای یک پیام به‌درستی فرمت شده دریافت کردیم و همچنین خطاهایی برای تمامی پیام‌هایی که دارای نقصی در ساختارشان هستند (پیشوند PKCS #1 v1.5 غلط، وجود صفر در پوده‌گذاری‌های غیر صفر، فسخ کننده صفر پوده‌گذاری ازدست‌رفته^(۳۵)).

این نقص فقط یک اوراکل ضعیف را ارائه می‌دهد و حملات بسیار زمان‌بر است. بااین‌حال، این آسیب‌پذیری هنوز باید یک نقص امنیتی محسوب شود. سازندگان WolfSSL این مشکل را در کد Git برطرف کردند[۲۰]. در زمان انتشار این مقاله نسخه جدیدی از طرف سازندگان ارائه نشده بود و نسخه ۳٫۱۲٫۲ همچنان آسیب‌پذیر بود. به این آسیب‌پذیری کد CVE-2017-13099 اختصاص داده شده است.

 ۹-۴ آسیب‌پذیری‌های قدیمی در MatrixSSL و JSSE

ما از دو آسیب‌پذیری در پشته‌های TLS که قبلاً شناخته شده بودند آگاهیم که در سال‌های اخیر کشف شده‌اند. Meyer و همکاران یک آسیب‌پذیری را در Java/JSSE یا CVE-2012-5081 شناسایی کردند که بر روی Oracle Java SE 7 Update 7 ،۶ Update 35، ۵٫۰ Update 36، نسخه ۱٫۴٫۲٫۳۸ و نسخه‌های قدیمی‌تر تأثیرگذار است (CVE-2012-5081). Somorovsky یک آسیب‌پذیری را در MatrixSSL نسخه ۳٫۸٫۳ و قدیمی‌تر کشف کرده است (CVE-2016-6883).

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

۱۰-۴ آسیب‌پذیری‌های دیگر

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

علاوه بر این، ما سرورهای آسیب‌پذیری را شناسایی کرده‌ایم که نمی‌توانیم آن‌ها را به یک پیاده‌سازی خاص نسبت دهیم. اغلب پیدا کردن نوع محصولاتی که در میزبان‌ها و بر روی اینترنت مورداستفاده قرار می‌گیرند، موضوعی چالش‌برانگیز است. تلاش برای پرسیدن از اپراتورها، معمولاً بدون پاسخ می‌ماند و بسیاری از محصولات معمولاً اطلاعات مربوط به محصول یا نسخه آن را از طریق هدر‌های HTTP مناسب نمایش نمی‌دهند. هدرِ سرور نیز غیرقابل‌اعتماد است، زیرا در بسیاری از موارد، بالانس کننده‌های بار یا ابزارهای امنیتی اتصالات TLS را هنگامی‌که اطلاعاتِ هدر توسط سرور HTTP تولید شده باشد را خاتمه می‌دهند. هدر X-Forwarded-For که قرار است توسط چنین محصولاتی مورد استفاده قرار گیرد، به‌ندرت استفاده می‌شود، زیرا بسیاری از توسعه‌دهندگانِ تجهیزات امنیتی فکر می‌‌کنند که این اطلاعات باید پنهان شوند.

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

۱۱-۴ آمار مربوط به میزبان‌های آسیب‌دیده

ما چندین اسکن را در فهرست ۱ میلیون سایت برترِ Alexa برای میزبان‌های آسیب‌پذیر انجام دادیم. ما به‌تدریج استراتژی اسکن خود را بهبود بخشیدیم و هم‌زمان به صفحات وب و سازندگان آسیب‌پذیر نیز اطلاع‌رسانی کردیم. بنابراین یک نقطه زمانی خاص وجود نداشت که ما بتوانیم تمام آسیب‌پذیری‌های موجود را شناسایی کنیم. ما در اینجا می‌خواهیم تأکید کنیم که همه اعداد ما که در ادامه می‌آیند باید به‌صورت برآوردهای تقریبی در نظر گرفته شوند.

ما معتقدیم که دو اسکن که در تاریخ‌های ۱۱ و ۱۲ نوامبر ۲۰۱۷ انجام دادیم، نزدیک‌ترین برآورد را برای تعداد سرورهای آسیب‌پذیر پیش از تحقیق به ما ارائه دادند. ما اسکن‌های خود را بر روی تمامی دامنه‌های موجود بر روی لیست ۱ میلیون سایت برترِ Alexa با و بدون پیشوند www بر روی HTTPS/port 43 انجام دادیم. این یک موضوع کاملاً رایج بود که میزبان‌ها با و بدون پیشوند www توسط پشته‌های TLS مختلف خدمات‌رسانی می‌شدند.

ما در حال حاضر به جریان پیام کوتاه رسیده‌ایم و یک false positive را در ترکیب با SNI (نشان‌دهنده نام سرور) در اسکن‌های قبلی خود حذف کرده‌ایم. به‌غیراز فیس‌بوک، هیچ‌یک از فروشندگان آسیب‌دیده در این مرحله، اصلاحات shipping را آغاز نکرده است. این موضوع دارای اهمیت است که اسکن‌های ما قبل از در دسترس بودن به‌روزرسانی‌های مربوط به دستگاه‌های F5 بود.

بااین‌حال این اسکن‌ها با استفاده از دنباله‌های رمز متنوع تست نشدند و ازاین‌رو برخی از میزبان‌های آسیب‌پذیر را که هنگام مذاکره با یک رمز CBC از خود رفتار آسیب‌پذیر نشان می‌دهند را شناسایی نکردند. این اسکن‌ها نیز پس‌ازاینکه فیس‌بوک شروع به انجام اصلاحات در زیرساخت‌های خود کرد، شروع شدند. علاوه بر این، ابزار اسکن ما هنوز شامل آزمونی برای شناسایی مشکل JSSE یا CVE-2012-5081 نیست.

درحالی‌که ابزار اسکن ما تلاش می‌کند تا با تصدیق پاسخ‌های آسیب‌پذیر اشتباهات را کاهش دهد، ما مشاهده کردیم که برخی رفتارهای غیرقطعی^(۳۶) همچنان می‌تواند به‌طور اشتباه به‌عنوان آسیب‌پذیر شناخته شوند.

بر طبق این اسکن‌ها ۸۵۴،۲۲ میزبان (۲٫۳ درصد) در میان میزبان‌های www آسیب‌پذیر بودند. ۴۶۳،۱۷ میزبان (۱٫۷ درصد) در میان میزبان‌های غیر www آسیب‌پذیر بودند. اگر ما نتایج را با هم ترکیب کنیم، ۹۶۵،۲۷ میزبان (۲٫۸ درصد) هم بر روی www و هم بر روی غیر www آسیب‌پذیر بودند.

در میان ۱۰۰ دامنه برترِ Alexa، اگر ما بهترین نتیجه اسکن خود را با اسکن‌های قبلی از میزبان‌ها که در آن زمان وصله شده بودند، ترکیب کنیم؛ تعداد ۲۷ عدد (درنتیجه ۲۷ درصد) آسیب‌پذیر بودند. این نشان می‌دهد که در میان میزبان‌های پربیننده، تعداد سیستم‌های آسیب‌پذیر بالاتر است.

بر اساس آسیب‌پذیری دقیق، ما همچنین می‌توانیم فروشندگان تحت تأثیر را تخمین بزنیم. ما می‌خواهیم تأکید کنیم که پتانسیل بیشتری برای اشتباه در اینجا وجود دارد، زیرا ممکن است فروشندگان مختلف آسیب‌پذیری مشابهی داشته باشند که این موضوع این امر را سخت می‌کند که به‌طور دقیق بین محصولات آسیب‌پذیر فرق گذاشت. اگر ما این دو اسکن را ترکیب کنیم ۲۱۱۹۴ میزبان به یکی از انواع F5 که ما مشاهده کردیم، آسیب‌پذیر بودند. ۵۸۵۶ میزبان به انواع Citrix شامل ۵۲۱ عدد  Cisco ACE، ۳۳۶ عدد Radware، ۱۱۸ عدد Vendor X،۶ عدد MatrixSSL و ۵ عدد Erlang آسیب‌پذیر بودند. VENDOR X تا زمان انتشار این مقاله وصله‌ای را منتشر نکرده و بعداً منتشر خواهد شد. ما همچنین سه پروفایل رفتار اضافی را شناسایی کردیم که نمی‌توانستند به هیچ‌یک از فروشنده‌های خاص نسبت داده شوند. این رفتارها به ترتیب بر روی ۹۲۳، ۷۹۳ و ۷۶۳ عدد میزبان کشف شدند.

۵ اثبات ادعای حمله

ما یک حمله اثبات ادعا ایجاد کردیم که امکان رمزگشایی و امضای یک پیام را با کلید یک سرور آسیب‌پذیر فراهم می‌کند. این حمله در پایتون ۳ پیاده‌سازی شده است. اثبات ادعای ما بر پایه پیاده‌سازی Tibor Jager از الگوریتم Bleichenbacher است.

این پیاده‌سازی از یک الگوریتم ساده استفاده می‌کند، همان‌طور که توسط کار اصلی Bleichenbacher شرح داده شده است [۱۱]. بنابراین حمله ما از الگوریتم‌های بهینه‌سازی شده‌ای که در طول سال‌ها توسعه یافته‌اند، استفاده نمی‌کند [۷]. ما همچنین این حمله را به‌صورت موازی انجام ندادیم و همه اتصالات و درخواست‌های اوراکل به‌طور پیوسته (سری) رخ دادند. باوجوداین محدودیت‌ها، هنوز هم می‌توانستیم به‌طور عملی این حمله را بر روی اینترنت و هم برای رمزگشایی و هم برای امضا انجام دهیم.

کد ما ابتدا میزبان‌ها را برای آسیب‌پذیری‌های Bleichenbacher اسکن می‌کند. ما سعی می‌کنیم سیگنال‌های مختلفی را که توسط سرور ارائه می‌شود شناسایی کنیم و به‌طور خودکار اوراکل را با آن سازگار کنیم.

برای یک حمله موفقیت‌آمیز، ما نیاز به اتصالات پیوسته و‌ زیاد به یک سرور داریم. کد حمله ما پرچم TCP NODELAY و TCP Fast Open که در دسترس هستند را به کار می‌گیرد تا این ارتباطات را سریع‌تر کند. این تأخیر و اتصال بالاسری^(۳۷) را کاهش می‌دهد و اجازه می‌دهد درخواست‌های اوراکل بیشتری در ثانیه ارسال شوند.

ما قصد داریم حمله اثبات ادعای خود را تحت مجوز رایگان (CC0) منتشر کنیم. بااین‌وجود، این انتشار را تا پس از اعلام اولیه آسیب‌پذیری‌ها به تأخیر می‌اندازیم تا کاربران زمان کافی برای اعمال اصلاحات را داشته باشند. بااین‌وجود ما بخش اسکن ابزار خود را در این مقاله منتشر خواهیم کرد.

۶ تجزیه‌وتحلیل اثرات

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

TLS از انواع مختلف تبادلات کلید با RSA پشتیبانی می‌کند: تبادلات کلید RSA استاتیک که یک مقدار مخفی، توسط مشتری رمزگذاری شده است و forward-secrecy با استفاده از Diffie Hellman یا منحنی بیضوی^(۳۸) Diffie Hellman، تبادلات کلید را فعال کرده است که RSA فقط برای امضا استفاده می‌شود. پیکربندی‌های مدرن، تمایل به منحنی بیضوی Diffie Hellman دارند. در یک پیاده‌سازی TLS صحیح، نباید برای یک مهاجم این امکان وجود داشته باشد که یک مکانیزم تبادل کلید خاص را بشکند، بااین‌حال دیگر اشکالات ممکن است اجازه این کار را بدهند.

اگر یک تبادل کلید RSA استاتیک استفاده شود، این حمله عواقب ویرانگری دارد. یک مهاجم می‌تواند به‌طور غیرمستقیم ترافیک را ضبط کند و بعداً آن را با اوراکل Bleichenbacher رمزگشایی کند. درنتیجه سرورهایی که تنها از تبادلات کلیدی RSA استاتیک پشتیبانی می‌کنند، در معرض بیشترین خطر قرار دارند. ما دستگاه‌ها و پیکربندی‌هایی که در این مورد وجود دارند را مشاهده کردیم، به‌ویژه متعادل‌کننده‌های بار Cisco ACE و میزبان paypal.com

 ۱-۶ حملاتی که سرور و سرویس‌گیرنده از رمزنگاری RSA استفاده نمی‌کنند.

برای حمله یک تبادل کلید که RSA فقط برای امضاها مورداستفاده قرار می‌گیرد، مهاجم با یک مشکل مواجه می‌شود: او می‌تواند یک سرور را به‌عنوان یک سرویس‌گیرنده جا بزند، اما برای انجام این کار او باید قادر به انجام یک عملیات امضای RSA در هنگام دست‌تکانی باشد. یک دست‌تکانی TLS معمولاً کمتر از یک ثانیه طول می‌کشد. یک مهاجم می‌تواند این زمان را به مدت چند ثانیه به تأخیر بیندازد، اما نه بیشتر. بنابراین حمله باید خیلی سریع صورت گیرد. ساختن یک امضا با یک حمله Bleichenbacher از رمزگشایی یک متن رمز شده بیشتر طول می‌کشد، درنتیجه این موضوع حقیقتاً چالش‌برانگیز است.

بااین‌حال، اگر مشتری هنوز از رمزگذاری RSA پشتیبانی می‌کند، مهاجم دارای گزینه دیگری است: او می‌تواند ارتباط را به یک مبادله کلید RSA کاهش دهد. این حالت قبلاً توسط Aviram و همکاران توصیف شده است [۶]. ما معتقدیم که در سناریوهای واقع‌بینانه امکان بهینه کردن حمله به‌اندازه کافی وجود دارد تا بتوان این کار را انجام داد، به‌ویژه برای اهداف بزرگ که تعداد زیادی سرور دارند. یک مهاجم می‌تواند حمله را موازی کرده بین چند سرور توزیع کند و به چندین سرورِ هدف حمله کند. بااین‌حال، ما عملاً سعی نکردیم چنین حمله‌ای را انجام دهیم.

۲-۶ حمله به QUIC قدیمی

پروتکل QUIC یک سناریوی حمله خاص را امکان‌پذیر می‌سازد. نسخه‌های قدیمی‌تر QUIC امکان امضای یک کلید static X25519 با RSA را داشتند. سپس این کلید می‌تواند برای اجرای یک سرور بدون نیاز به استفاده از کلید خصوصی RSA در هنگام دست‌تکانی استفاده شود. این سناریو قبلاً توسط Jager و همکاران[۲۲] و در زمینه حمله DROWN توسط Aviram و همکاران[۶] موردبحث قرار گرفته است. در پاسخ به حمله DROWN، گوگل در ابتدا QUIC  را برای میزبان‌های غیر گوگل غیرفعال کرده است و بعدازآن دست‌تکانی  QUIC را برای جلوگیری از این حمله تغییر داد[۱۲].

۳-۶ حملات cross-protocol  و  cross-server

لازم به ذکر است که با حمله Bleichenbacher هدف موردحمله می‌تواند تا زمانی که یک کلید RSA مشابه را به اشتراک می‌گذارد، از سرور آسیب‌پذیر مستقل باشد. همان‌طور که توسط Aviram و همکارانش نشان داده شده است [۶] این چندین پیامد عملی دارد. بیایید فرض کنیم یک سرویس وب تحتِ www.example.com توسط یک پشته TLS امن خدمات‌رسانی می‌شود که آسیب‌پذیر نیست. این سرور همچنان می‌تواند موردحمله واقع شود اگر کلیدهای RSA مشابه در جای دیگر توسط یک پشته آسیب‌پذیر مورداستفاده قرار گیرند. این امکان وجود دارد زیرا یک مهاجم می‌تواند از اوراکلِ سرورِ آسیب‌پذیر برای امضای پیام‌ها یا رمزگشایی تبادلات کلید RSA استاتیک با www.example.com استفاده کند. حملات جعل هویت نیز ممکن است در برابر www.example.com صورت پذیرد، زیرا سرویس‌های آسیب‌پذیر که از یک گواهی HTTPS معتبر برای www.example.com استفاده می‌کنند، وجود دارد و مهاجم به‌اندازه کافی سریع است. شایع‌ترین سناریو برای این موضوع این خواهد بود که گواهی *.example.com بر روی هدف آسیب‌پذیر استفاده شود. ما درواقع چنین نمونه‌ای را بر روی اینترنت مشاهده کردیم. صفحه‌ی وب اصلی واتزاپ یعنی www.whatsapp.com آسیب‌پذیر نبود. هرچند چندین زیر دامنه از whatsapp.com آسیب‌پذیر بود و از یک گواهی wildcard استفاده می‌کرد که برای *.whatsapp.com نیز معتبر بود. این سرورها عملکرد بسیار خوبی را ارائه می‌دهند، بنابراین ما اعتقاد داریم که یک حمله موازی اجازه جعل هویت www.whatsapp.com را می‌دهد.

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

این سناریوها خطر اشتراک‌گذاری کلید، میان سرویس‌های مختلف و یا استفاده از گواهی‌ها را با دامنه بی‌حدوحصر بزرگ نشان می‌دهد. ما بر این باوریم که یک شیوه رمزنگاری خوب برای جلوگیری از این سناریوها وجود دارد. هر سرویس باید گواهی‌نامه‌های مخصوص به خود را داشته باشد و از گواهی‌نامه‌هایی که برای تعداد زیادی از میزبان‌ها (مخصوصاً گواهی‌نامه‌های wildcard) معتبر هستند، باید اجتناب شود. همچنین کلیدهای خصوصی نباید بین گواهینامه‌های مختلف به اشتراک گذاشته شوند.

۴-۶ حمله بر روی لغو^(۳۹) ACME

به‌غیراز حملات علیه TLS، یک حمله ممکن است امکان‌پذیر شود اگر کلید خصوصی یک سرور TLS در زمینه‌های مختلف نیز استفاده شود.

یک مثال برای این، پروتکل ACME برای صدور گواهی است[۸] که توسط  Let’s Encrypt استفاده می‌شود. این پروتکل اجازه می‌دهد تا گواهی‌نامه‌ها لغو شوند، درصورتی‌که یکی بتواند یک پیام لغو خاص^(۴۰) را با یک کلید خصوصیِ متعلق به یک گواهی امضا کند.

درحالی‌که این موضوع امنیت ارتباطات TLS را تحت تأثیر قرار نمی‌دهد، این امر باعث ایجاد مشکلات برای اپراتورهای صفحه وب می‌شود که ممکن است خطاهای تأییدِ اعتبارِ گواهیِ ناخواسته را ببینند.

۷ بحث

 ۱-۷ اقدامات متقابل در TLS نسخه‌های ۱٫۰، ۱٫۱ و ۱٫۲

حمله اصلی Bleichenbacher در سال ۱۹۹۸ رخ داد. در آن زمان SSL نسخه ۳ بر روی پروتکل SSL استفاده می‌شد. SSL نسخه ۳ در سال ۱۹۹۹ با TLS نسخه ۱ جایگزین شد و بنابراین این اولین استانداردی بود که شامل اقدامات متقابل علیه حمله Bleichenbacher بود.

TLS نسخه ۱٫۰ پیشنهاد داد که هنگام دریافت یک بلوک RSA که نادرست فرمت شده است، یک پیاده‌سازی باید یک مقدار تصادفی را تولید کند و با استفاده از این مقدار تصادفی به‌عنوان یک premaster مخفی اقدام کند. پس‌ازآن این موضوع منجر به یک شکست در پیام Finished می‌شود که باید از یک بلوکِ RSA درست فرمت شده برای یک مهاجم، غیرقابل تشخیص باشد.

اگر نسخه ClientHello در premaster مخفی نادرست باشد، TLS نسخه ۱٫۰ به‌وضوح مشخص نکرده است که سرور چه کاری باید انجام دهد. این موضوع به Klıma ،Pokorny و Rosa اجازه داد تا یک اوراکل نسخه بد را ایجاد کنند[۲۴]. همچنین اقدامات متقابل، یک نوع زمان‌بندیِ اوراکلِ Bleichenbacher را باز می‌کند. با توجه به اینکه مقدار تصادفی فقط در صورت پیام نادرست فرمت شده ایجاد می‌شود، مهاجم ممکن است قادر به ‌اندازه‌گیری زمان لازم برای فراخوانی تولیدکننده عدد تصادفی باشد. در TLS نسخه ۱٫۱ [۱۷] تلاش شد تا این حملات را در نظر بگیریم و اقدامات متقابل را تطبیق دهیم.

در TLS نسخه ۱٫۲ [۳۱] دو الگوریتم بالقوه ارائه شده است که مجریان باید دنبال کنند تا از حملات Bleichenbacher جلوگیری کنند. این دو نوع تغییرات شامل زیرتغییراتی^(۴۱) نیز می‌شوند که پیشنهاد‌هایی برای چگونگی حفظ سازگاری با پیاده‌سازی‌های شکسته شده قدیمی می‌دهند. بااین‌وجود این تغییرات فقط در مواقعی باید اعمال شوند که بررسی عدد نسخه به‌صراحت غیرفعال شده باشد. علاوه بر اینTLS  نسخه ۱٫۲ بیان می‌کند که اولین الگوریتم توصیه می‌شود، زیرا مزایای نظری دارد، دوباره به کار Klima ،Pokorny و Rosa رجوع کنید[۲۴]. روشن نیست که چرا طراحان TLS تصمیم به ارائه دو الگوریتم مختلف گرفتند و همچنین ادعا کردند که یکی از آن‌ها ترجیح داده می‌شود. این کار به‌طور غیرضروری پیچیدگی را هر چه بیشتر افزایش می‌دهد.

تفاوت بین دو الگوریتم درTLS  نسخه ۱٫۲ در نحوه به کار بردن نسخه‌های ClientHello نادرست است. اولین الگوریتم پیشنهاد ‌می‌کند که سرور، خطاهای نسخه ClientHello را در premaster مخفی اصلاح کند و پیام Finished را با آن محاسبه کند. الگوریتم دوم پیشنهاد می‌کند همیشه با یک عددِ نسخه اشتباه در  premaster مخفی به‌عنوان یک خطا رفتار شود.

استانداردهای TLS اشاره می‌کنند که پروتکل OAEP امنیت بیشتری نسبت به حملات Bleichenbacher فراهم می‌کند. اگرچه همیشه تصمیم گرفتیم تا استاندارد PKCS # v1.5 قدیمی را به دلایل سازگاری حفظ کنیم.

به‌طورخلاصه، می‌توان دید که طراحان پروتکل TLS تصمیم به مقابله با حملات Bleichenbacher با ارائه اقدامات متقابل پیچیده گرفتند. با هر نسخه جدید TLS، فصل مقابله با اقدامات Bleichenbacher بزرگ‌تر و پیچیده‌تر شده است. همان‌طور که تحقیقات ما نشان می‌دهد، این اقدامات متضاد اغلب در عمل به کار نمی‌آیند و بسیاری از پیاده‌سازی‌ها همچنان آسیب‌پذیر باقی می‌مانند. به نظر ما این نشان می‌دهد که این یک استراتژی نادرست برای مقابله با حملات رمزنگاری با راه‌حل‌هاست^(۴۲). کدگذاری PKCS # 1 v1.5 پس از کشف حمله Bleichenbacher باید منسوخ شود.

ما می‌خواهیم اشاره کنیم که چیزی بسیار مشابه در TLS ازلحاظ رمزنگاری متقارن اتفاق افتاده است. در سال ۲۰۰۲، Sergey Vaudenay یک حمله اوراکل پوده‌گذاری شده را در برابر CBC در TLS نشان داد[۳۴]. به‌جای حذف این حالت‌های گیج‌کننده و یا طراحی مجدد آن‌ها برای انعطاف‌پذیری در برابر حملات اوراکل پوده‌گذاری شده، طراحان TLS تصمیم به ارائه اقدامات متقابل گرفتند. TLS نسخه ۱٫۲ به‌صراحت ذکر می‌کند که این اقدامات متقابل هنوز یک کانال جانبی زمان‌بندی را باقی می‌گذارند. پس ‌از آن AlFardan و Paterson توانستند نشان دهند که این کانال جانبی زمان‌بندی می‌تواند مورد بهره‌برداری قرار گیرد[۱].

۲-۷ حملات زمان‌بندی‌شده

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

Meyer و همکاران برخی از آسیب‌پذیری‌های Bleichenbacher مبتنی بر زمان را توصیف کرده‌اند [۲۶]. با توجه به پیچیدگی اقدامات متقابل در استاندارد TLS، احتمالاً هنوز انواع مختلف زمان‌بندی‌های ناشناخته از آسیب‌پذیری‌های Bleichenbacher در بسیاری از پشته‌های TLS وجود داشته باشد.

ما از Adam Langley یاد گرفتیم که پیاده‌سازی‌های مختلف TLS ممکن است به دلیل استفاده از پیاده‌سازی‌های bignum با اندازه‌های مختلف، به حملات زمان‌بندی آسیب‌پذیر باشند. در OpenSSL نتیجه رمزگشایی RSA با توابع داخلی BN یا bignum مدیریت می‌شود. اگر مقدار رمزگشایی یک یا چند صفر پیشرو^(۴۳) داشته باشد، عملیات کمی سریع‌تر خواهد شد. اگر یک مهاجم قادر به ‌اندازه‌گیری سیگنال زمان‌بندی باشد، ممکن است بتواند از این به‌عنوان یک اوراکل استفاده کند و یک حمله بسیار شبیه به یک حمله Bleichenbacher را انجام دهد. سایر کتابخانه‌های TLS نیز مسائل مشابهی دارند.

سیگنال زمان‌بندی بسیار کوچک است و مشخص نیست که آیا در عمل قابل بهره‌برداری است یا نه. بااین‌حال، AlFardan و Paterson در حمله Lucky Thirteen  نشان داده‌اند [۱] که حتی کانال‌های جانبیِ زمان‌بندیِ بسیار کوچک نیز می‌توانند مورد بهره‌برداری قرار گیرند.

۳-۷ منسوخ شدن PKCS # v1.5 در TLS

طراحان پروتکل TLS به تحقیقات Bleichenbacher با راه‌حل‌های پیچیده، واکنش نشان دادند. تحقیقات ما نشان می‌دهد که این استراتژی جواب نداده است. همچنین راه‌حل‌های ارائه‌شده به‌درستی در تعداد زیادی از میزبان‌ها اجرا نمی‌شود.

برای نسخه TLS 1.3 که در آینده منتشر می‌شود، مبادله کلید رمزگذاری RSA در مراحل اولیه طراحی منسوخ شده است[۳۰]. بااین‌حال، همان‌طور که توسط Jager و همکاران نشان داده شده است، این کافی نیست، زیرا این حملات می‌تواند در نسخه‌های مختلف این پروتکل اجرا شود [۲۲]. اگر فرض کنیم که اقدامات پیشگیرانه در همه جا به‌درستی اجرا شده است، تنها گزینه ایمن این است که پشتیبانی کامل از تبادلات کلید رمزگذاری RSA را غیرفعال کنیم.

این موضوع با برخی از چالش‌ها همراه است. جایگزینی برای مبادله کلید RSA، مبادلات کلیدِ فیلد محدودِ^(۴۴) Diffie Hellman و منحنی بیضوی Diffie Hellman هستند. همچنین تلاش شده است تا فیلد محدودِ Diffie Hellman منسوخ شود، زیرا مشتریان عملاً نمی‌توانند پارامترهای ایمن را از یک سرور دریافت کنند. توسعه‌دهندگان مرورگر Chrome تصمیم گرفتند پشتیبانی از فیلد محدودِ Diffie Hellman را غیرفعال کنند [۱۰]. این کار، منحنی بیضوی Diffie Hellman را تنها گزینه باقی‌مانده قرار می‌دهد، بااین‌حال، پیاده‌سازی این دنباله‌ها به دلایل نگرانی‌های ثبت اختراع به تأخیر افتاده است. بنابراین مبادلات کلید مبتنی بر رمزگذاری RSA به‌عنوان یک جایگزین سازگار برای حمایت از مشتریان قدیمی موردتوجه قرار گرفته است.

منسوخ شدن فیلد محدودِ Diffie Hellman لزوماً یک مشکل در اینجا نیست. آسیب‌پذیری‌های Bleichenbacher در سمت سرور TLS تأثیر می‌گذارند. اگر مشتری هنوز از مبادلات کلیدی مبتنی بر رمزگذاری RSA پشتیبانی می‌کند، هیچ خطری اضافه نمی‌شود. بنابراین اپراتورهای سرور می‌توانند مبادلات کلیدی مبتنی بر رمزگذاری RSA را غیرفعال کنند و از مبادلات منحنی بیضوی Diffie Hellman برای مشتریان جدید و فیلد محدودِ Diffie Hellmanبرای مشتریان قدیمی پشتیبانی کنند.

Cloudflare به ما اطلاع داد که در میان میزبان‌های خود تنها یک درصد از ارتباطات مشتری از یک تبادل کلید رمزگذاری RSA استفاده می‌کند. یکی از نویسندگان این مقاله سرورهای HTTPS را اداره می‌کند و قادر به غیرفعال کردن رمزگذاری RSA بدون هیچ‌گونه مشکل قابل‌توجهی بود.

نشانه‌هایی وجود دارد که غیرفعال کردن رمزگذاری RSA در سرورهای پست الکترونیک مشکل‌ساز است. ما شناسایی کردیم که شمار قابل‌توجهی از ارتباطات قانونی به سرورهای IMAP و POP3 با یک تبادل کلید RSA اتفاق می‌افتد. با پرسیدن از کاربران آسیب‌دیده متوجه شدیم که همه آن‌ها از برنامه Mail استفاده می‌کردند. برنامه Mail، یک برنامه از پیش نصب‌شده در گوشی‌های قدیمی دارای اندروید نسخه ۴ یا در یک مورد حتی اندروید نسخه ۲ است.

انتخاب‌های الگوریتم بر روی اندروید به برنامه بستگی دارد. بر روی گوشی‌های دارای اندروید نسخه ۴٫۳ ما توانستیم متوجه شویم که برنامه Mail از طریق TLS RSA WITH AES 128 CBC SHA متصل است. بااین‌حال با استفاده از برنامه رایگان K9Mail، یک ارتباط با یک کلید تبادل منحنی بیضوی  Diffie Hellmanمورداستفاده قرار گرفت. بنابراین برای کاهش نیاز به پشتیبانی از تبادلات کلید مبتنی بر رمزگذاری RSA کاربران می‌توانند از برنامه‌های جایگزین که از الگوریتم‌های رمزنگاری مدرن‌تری پشتیبانی می‌کنند، استفاده کنند.

علی‌رغم این چالش‌ها ما اعتقاد داریم که خطر پیاده‌سازی نادرست راه‌حل‌های مقابله با حملات Bleichenbacher بسیار بالا است و تبادلات کلید مبتنی بر رمزنگاری RSA باید منسوخ شود. با توجه به مسائل مربوط به سازگاری و خطرات احتمالی ما توصیه می‌کنیم که در ابتدا پشتیبانی در سمت سرور باید غیرفعال شود. برای سرورهای HTTPS ما بر این باوریم که در حال حاضر می‌توان این کار را انجام داد و تنها باعث ایجاد مشکلات سازگاری جزئی خواهد شد.

۴-۷ OAEP و  PKCS # 1 v1.5 برای امضاها و PSS

RSA-OAEP یک جایگزین برای پوده‌گذاری ارائه‌شده توسط PKCS # 1 v1.5 است و امنیت بیشتری را برای RSA رمزگذاری شده فراهم می‌کند. این موضوع در استانداردهای PKCS # 1 جدیدتر، استاندارد شده است، که آخرین نسخه ۲٫۲ [۲۷] است. بااین‌حال برای TLS هرگز استفاده نشده و بعید است که در این روند تغییری رخ دهد.

مستقل از حالت پوده‌گذاری، رمزگذاری RSA در حقیقت forward secrecy را تأمین نمی‌کند. با در نظر داشتن مزیت شفاف دنباله‌هایی که دارای forward secrecy فعال هستند، ما معتقدیم راه پیش رو استفاده نکردن از رمزگذاری PKCS # 1 v1.5 و RSA-OAEP در TLS است. این تصمیم برای TLS نسخه ۱٫۳ نیز قابل اجراست [۳۰]. اگرچه RSA-OAEP ممکن است جایگزین بهتری برای پروتکل‌های دیگر باشد. ما می‌خواهیم اشاره کنیم که OAEP به‌طور کامل در برابر حملات پوده‌گذاری مقاوم نیست، برای جزئیات بیشتر به Manger [25] و Meyer و همکاران [۲۶] مراجعه کنید.

هنگام استفاده ازforward secrecy  در حقیقت RSA می‌تواند به‌عنوان یک الگوریتم امضا، مورداستفاده قرار گیرد. این هنوز هم شایع‌ترین تنظیمات در TLS است؛ ازآنجاکه جایگزین‌هایی مانند ECDSA هنوز به‌طور گسترده موردقبول واقع نشدند. پیاده‌سازی‌های امضای RSA از حمله Bleichenbacher از سال ۱۹۹۸ رنج نمی‌برند، اما پوده‌گذاریPKCS # 1 v1.5  مشکل دیگری دارد. در سال ۲۰۰۶، Daniel Bleichenbacher یک نقص پیاده‌سازی مشترک را در تجزیه این امضاها کشف کرد[۱۹]. انواع دیگر این حمله، به نام BERserk، به‌طور مستقل توسط Antoine Delignat-Lavaud و اینتل کشف شده است که بر روی کتابخانه NSS موزیلا در سال ۲۰۱۴ تأثیر گذاشت[۳۲]. درحالی‌که این حملات کاملاً مستقل از حمله رمزنگاری RSA از سال ۱۹۹۸ هستند، آن‌ها دلایل خوبی برای منسوخ کردن PKCS # 1 v1.5 هم برای رمزگذاری و هم برای امضا هستند.

RSA-PSS مقاومت در برابر این حمله را فراهم می‌کند و همچنین در استاندارد PKCS # 1 v2.2 استاندارد شده است [۲۷]. TLS  نسخه ۱٫۳ از RSA-PSS برای امضا استفاده خواهد کرد [۳۰].

۵-۷ حملات Bleichenbacher در دیگر پروتکل‌ها

در این تحقیق ما روی حملات Bleichenbacher در برابر TLS تمرکز کردیم. بااین‌حال این حملات محدود به TLS نیستند. Jager و همکاران[۲۱] آسیب‌پذیری‌های Bleichenbacher را در رمزنگاری XML نشان داده‌اند، Detering و همکاران آسیب‌پذیری‌هایی را در JSON/JOSE نشان داده‌اند[۱۶] و Ivan Nestlerode آسیب‌پذیری‌هایی را در کد Cystocol Message Sintax یا CMS در OpenSSL کشف کرده است[۲۸].

تمام پروتکل‌هایی که از رمزگذاری PKCS # 1 v1.5  استفاده می‌کنند و به‌طور بالقوه به مهاجم اجازه می‌دهند پیام‌های خطا را ببیند، اهداف بالقوه حملات Bleichenbacher هستند. بنابراین توصیه ما برای منسوخ کردن PKCS # 1 v1.5  به TLS محدود نمی‌شود و باید در پروتکل‌های دیگر نیز از آن اجتناب شود.

۶-۷ مسئولیت فروشنده

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

هشدارهای متعددی مبنی بر این مشکلات وجود داشت. کار Meyer و همکاران در سال ۲۰۱۴ برخی از پیاده‌سازی‌های امروزی آسیب‌پذیر را نشان داده است [۲۶]. Jager و همکاران در مورد خطر حملات Bleichenbacher برای TLS نسخه ۱٫۳ هشدار داده‌اند [۲۲] و در کارگاه TLS 1.3 Ready Or Not یا TRON جایزه بهترین مقاله به آن‌ها اهدا شد[۹]. Aviram و همکاران از ایده حمله Bleichenbacher برای ساخت حمله DROWN خود استفاده کرده‌اند [۶]. این نکته قابل‌توجه است که هیچ‌کدام از این مقالات باعث نشده که فروشندگان آسیب‌دیده محصولات خود را برای چنین آسیب‌پذیری‌هایی تست کنند.

۷-۷ ابزارهای تشخیص آسیب‌پذیری

بسیاری از ابزارهای تست آسیب‌پذیری TLS موجود، درگذشته برای آسیب‌پذیری‌های Bleichenbacher مورد آزمایش قرار نگرفته‌اند. این احتمالاً یکی از دلایلی است که چرا چنین آسیب‌پذیری قدیمی هنوز شایع است. مطابق اطلاعات ما ^(۴۵)TLS-Attacker و ^(۴۶)tlsfuzzer قبل از شروع شدن تحقیق ما برای آسیب‌پذیری‌های Bleichenbacher تست شده‌اند. بااین‌حال، هر دو ابزار هنوز برای قابلیت استفاده بهینه‌سازی نشدند و احتمالاً تنها توسط تعداد کمی از مخاطبان استفاده می‌شوند. هیچ‌یک از ابزارهای موجودی که ما می‌شناسیم، آزمایش‌هایی برای حملات جریان پیام کوتاه شده^(۴۷) نداشتند.

ما قبل از انتشار این مقاله، با توسعه‌دهندگان بعضی از ابزارهای تست TLS ارتباط برقرار کردیم. توسعه‌دهندگان testssl.sh یک آزمایش را انجام دادند که شبیه به ابزار آزمایشی ما است. Hubert Kario در tlsfuzzer، بررسی‌‌های اضافی را پیاده‌سازی کرد. تست در tlsfuzzer با آزمون ما متفاوت است، چراکه برای نقض‌های^(۴۸) پروتکل‌هایی که آسیب‌پذیر نیستند نیز بررسی می‌شود. یک تفسیر دقیق از استاندارد TLS خواستار آن شده است که تمام خطاهای رمزگشایی RSA با یک هشدار TLS 20 (bad record mac) پس از پیام Finished پاسخ داده شود.

Tripwire IP360، تشخیص^(۴۹) برای دستگاه‌های آسیب‌پذیر F5 در ASPL-753 را اضافه کرد که همراه با گزارش عمومی F5 منتشر شد. تشخیص عمومی اوراکل‌های Bleichenbacher در هماهنگی با این نشریه منتشر خواهد شد. SSLLabs تشخیص اوراکل‌های Blaichenbacher را در نسخه توسعه‌یافته خود با یک تست مشابه با ما اضافه کرد^(۵۰).

قبل از تحقیق ما، TLS-Attacker یک ارزیابی حمله Bleichenbacher پایه‌ای را با جریان‌های پروتکل TLS کامل پیاده‌سازی کرد. ما این ارزیابی را با جریان‌های پروتکل کوتاه شده با پیام‌های ChangeCipherSpec و Finished گسترش دادیم و یک تشخیص اوراکل بر اساس وقفه‌های زمانی TCP و هشدارهای TLS تکراری پیاده‌سازی کردیم. این ویژگی‌های جدید در TLS-Attacker نسخه ۲٫۲ در دسترس هستند.

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

ما در حال ارائه‌ی کدِ ابزارِ اسکنِ خودمان تحت مجوز CC0 (مالکیت عمومی) هستیم^(۵۱). این به توسعه‌دهندگان دیگر ابزارها (هم رایگان و هم اختصاصی) اجازه می‌دهد تا از کد ما بدون هیچ محدودیتی استفاده کنند.

۸ خلاصه و نتیجه‌گیری

ما قادر به شناسایی هشت فروشنده و پروژه منبع باز و شمار قابل‌توجهی از میزبانانی شدیم که به تغییرات جزئی از حمله متنِ رمز شده انتخابیِ تطبیقی Bleichenbacher مربوط به سال ۱۹۹۸ آسیب‌پذیر بودند. قابل‌توجه‌ترین واقعیت این است که ما تلاش کمی برای بهره‌برداری از این آسیب‌پذیری انجام دادیم. بنابراین می‌توان نتیجه گرفت که تست‌های کافی برای پیاده‌سازی‌های TLS جدید در ارتباط با آسیب‌پذیری‌های قدیمی وجود ندارد.

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

طراحان TLS  نسخه ۱٫۳ قبلاً تصمیم گرفته‌اند تبادل کلید رمزگذاری RSA را منسوخ کنند. بااین‌حال، تا زمانی که سازگاری با دنباله‌های رمزِ رمزگذاری RSA در نسخه‌های قدیمی‌تر TLS ادامه یابد، این حملات همچنان یک مشکل هستند. برای اطمینان از اینکه حملات Bleichenbacher درنهایت حل شده‌اند، ما توصیه می‌کنیم تبادلات کلیدی مبتنی بر رمزگذاری RSA در TLS به‌طور کامل منسوخ شود. برای HTTPS ما معتقدیم که هم‌اکنون می‌توان این کار را انجام داد.

ما امیدواریم که تحقیقات ما به پایان دادن به استفاده از PKCS # 1 v1.5 کمک کند.

سپاسگزاری

نویسندگان از Tibor Jager برای ارائه کردن یک پیاده‌سازی Python از حمله Bleichenbacher،Adam Langley برای بازخورد در مورد QUIC و مشکلات زمان‌بندی در Go TLS، Eric Mill  از GSA برای کمک به ما برای شناسایی سیستم‌های آسیب‌پذیر، Nick Sullivan برای به اشتراک گذاشتن تعدادِ استفاده از تبادلات کلید RSA از Cloudflare، Dirk Wetter و David Cooper برای پیاده‌سازی یک بررسی ROBOT در testssl.sh و برای پیدا کردن اشکالات در کدِ تست ما، Hubert Kario برای پیدا کردن اشکالات در کدِ تست ما، Graham Steel ،Vladislav Mladenov ،Christopher Meyer، ErnstGunter Giessmann و Tanja Lange برای دادن بازخورد در مورد این مقاله، Ange Albertini برای طراحی یک لوگوی عالی، Garret Wasserman از CERT/CC برای کمک به تماس گرفتن با فروشندگان و فیس‌بوک برای مسابقات کشف باگ سخاوتمندانه، تشکر می‌کنند.

منابع

[۱] Nadhem J. AlFardan and Kenneth G. Paterson. Lucky Thirteen: Breaking the TLS and DTLS Record Protocols. In 2013 IEEE Symposium on Security and Privacy, pages 526-540, May 2013. doi: 10.1109/SP.2013.42. URL http://www.isg.rhul.ac.uk/tls/TLStiming.pdf.

[۲] Christopher Allen and Tim Dierks. The TLS Protocol Version 1.0. RFC 2246, January 1999. URL https://rfc-editor.org/rfc/rfc2246.txt.

[۳] Ingela Anderton Andin. Patch Package: OTP 18.3.4.7. erlang-questions mailing list, November 2017. URL http://erlang.org/pipermail/erlang-questions/2017-November/094257.html.

[۴] Ingela Anderton Andin. Patch Package: OTP 19.3.6.4. erlang-questions mailing list, November 2017. URL http://erlang.org/pipermail/erlang-questions/2017-November/094256.html.

[۵] Ingela Anderton Andin. Patch Package: OTP 20.1.7. erlang-questions mailing list, November 2017. URL http://erlang.org/pipermail/erlang-questions/2017-November/094255.html.

[۶] Nimrod Aviram, Sebastian Schinzel, Juraj Somorovsky, Nadia Heninger, Maik Dankel, Jens Steube, Luke Valenta, David Adrian, J. Alex Halderman, Viktor Dukhovni, Emilia K¨asper, Shaanan Cohney, Susanne Engels, Christof Paar, and Yuval Shavitt. DROWN: Breaking TLS Using SSLv2. In 25th USENIX Security Symposium (USENIX Security 16), pages 689- 706, Austin, TX, August 2016. USENIX Association. ISBN 978-1-931971- 32-4. URL https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/aviram.

[۷] Romain Bardou, Riccardo Focardi, Yusuke Kawamoto, Lorenzo Simionato, Graham Steel, and Joe-Kai Tsay. Efficient padding oracle attacks on cryptographic hardware. In Reihaneh Safavi-Naini and Ran Canetti, editors, Advances in Cryptology – CRYPTO 2012: 32nd Annual Cryptology Conference, Santa Barbara, CA, USA, August 19-23, 2012. Proceedings, pages 608-625, Berlin, Heidelberg, August 2012. Springer Berlin Heidelberg. ISBN 978-3-642-32009-5. doi: 10.1007/978-3-642-32009-5 36. URL https://eprint.iacr.org/2012/417.

[۸] Richard Barnes, Jacob Hoffman-Andrews, and James Kasten. Automatic Certificate Management Environment (ACME). Internet Draft draft-ietf-acme-acme-08, Internet Engineering Task Force, October 2017. URL https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-08. Work in Progress.

[۹] Dominik Baumgarten. IETF-Award f¨ur Beitrag zu TLS 1.3, February 2016. URL https://www.hgi.ruhr-uni-bochum.de/hgi/news/articles/ietfpreis/.

[۱۰] David Benjamin. Intent to Deprecate: DHE-based cipher suites. Chromium net-dev mailing list, March 2016. URL https://groups.google.com/a/chromium.org/forum/#!topic/net-dev/AAdv838-koo.

[۱۱] Daniel Bleichenbacher. Chosen Ciphertext Attacks Against Protocols Based on the RSA Encryption Standard PKCS1. In Advances in Cryptology – CRYPTO ’۹۸, pages 1-12. Springer-Verlag, August 1998. URL http://archiv.infsec.ethz.ch/education/fs08/secsem/bleichenbacher98.pdf.

[۱۲] Chromium. Add QUIC 31 in which the server’s proof covers both the static server config as well as a hash of the client hello. Chromium Code Reviews, March 2016. URL https://codereview.chromium.org/1765603002/.

[۱۳] Cisco. End-of-Sale and End-of-Life Announcement for the Cisco ACE Application Control Engine ACE30 Module, September 2013. URL https://www.cisco.com/c/en/us/products/collateral/interfaces-modules/services-modules/eol_C51-728979.html.

[۱۴] Cisco. Release Note vA5(3.x), Cisco ACE Application Control Engine Module, August 2014. URL https://www.cisco.com/c/en/us/td/docs/interfaces_modules/services_modules/ace/vA5_3_x/release/note/ACE_mod_rn_A53x.html.

[۱۵] Citrix. TLS Padding Oracle Vulnerability in Citrix NetScaler Application Delivery Controller (ADC) and NetScaler Gateway, December 2017. URL https://support.citrix.com/article/CTX230238.

[۱۶] Dennis Detering, Juraj Somorovsky, Christian Mainka, Vladislav Mladenov, and J¨org Schwenk. On The (In-)Security Of JavaScript Object Signing And Encryption. In Reversing and Offensive-oriented Trends Symposium (ROOTS), Vienna, Austria, November 2017. URL https://www.nds.rub.de/media/ei/veroeffentlichungen/2017/10/17/main.pdf.

[۱۷] Tim Dierks and Eric Rescorla. The Transport Layer Security (TLS) Protocol Version 1.1. RFC 4346, April 2006. URL https://rfc-editor.org/rfc/rfc4346.txt.

[۱۸] F5. K21905460: BIG-IP SSL vulnerability CVE-2017-6168, November 2017. URL https://support.f5.com/csp/article/K21905460.

[۱۹] Hal Finney. Bleichenbacher’s RSA signature forgery based on implementation error. IETF OpenPGP mailing list, August 2006. URL https://www.ietf.org/mail-archive/web/openpgp/current/msg00999.html.

[۲۰] David Garske. Fix for handling of static RSA padding failures. Github pull request, November 2017. URL https://github.com/wolfSSL/wolfssl/pull/1229.

[۲۱] Tibor Jager, Sebastian Schinzel, and Juraj Somorovsky. Bleichenbacher’s Attack Strikes again: Breaking PKCS#1 v1.5 in XML Encryption. In European Symposium on Research in Computer Security (ESORICS), pages 752-769, 2012. URL https://www.nds.rub.de/research/publications/breaking-xml-encryption-pkcs15.

[۲۲] Tibor Jager, Jorg Schwenk, and Juraj Somorovsky. On the Security of TLS V1.5 Encryption. 1.3 and QUIC Against Weaknesses in PKCS#1 In 22Nd ACM SIGSAC Conference on Computer and Communications Security, CCS ’۱۵, pages 1185-1196, New York, NY, USA, 2015. ACM. ISBN 978-1-4503-3832-5. doi: 10.1145/2810103.2813657. URL https://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21/Tls13QuicAttacks.pdf.

[۲۳] B. Kaliski. PKCS #1: RSA Encryption Version 1.5. RFC 2313 (Informational), March 1998. URL http://www.ietf.org/rfc/rfc2313.txt. Obsoleted by RFC 2437.

[۲۴] Vlastimil Klima, Ondrej Pokorny, and Tomas Rosa. Attacking RSA-Based Sessions in SSL/TLS. In Colin D. Walter, C¸ etin K. Ko¸c, and Christof Paar, editors, Cryptographic Hardware and Embedded Systems – CHES 2003: 5^th International Workshop, Cologne, Germany, September 8-10, 2003. Proceedings, pages 426-440, Berlin, Heidelberg, 2003. Springer Berlin Heidelberg. ISBN 978-3-540-45238-6. doi: 10.1007/978-3-540-45238-6 33. URL https://eprint.iacr.org/2003/052.

[۲۵] James Manger. A Chosen Ciphertext Attack on RSA Optimal Asym metric Encryption Padding (OAEP) as Standardized in PKCS #1 v2.0. In Advances in Cryptology CRYPTO 2001: 21st Annual Inter national Cryptology Conference, Santa Barbara, California, USA, August 19-23, 2001 Proceedings, pages 230-238, Berlin, Heidelberg, 2001. Springer Berlin Heidelberg. ISBN 978-3-540-44647-7. doi: 10.1007/3-540-44647-8 14. URL https://link.springer.com/content/pdf/10.1007%2F3-540-44647-8_14.pdf.

[۲۶] Christopher Meyer, Juraj Somorovsky, Eugen Weiss, Jorg Schwenk, Sebastian Schinzel, and Erik Tews. Revisiting SSL/TLS Implementations: New Bleichenbacher Side Channels and Attacks. In 23rd USENIX Security Symposium (USENIX Security 14), pages 733-748, San Diego, CA, August 2014. USENIX Association. ISBN 978-1-931971-15-7. URL https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/meyer.

[۲۷] Kathleen Moriarty, Burt Kaliski, Jakob Jonsson, and Andreas Rusch. PKCS #1: RSA Cryptography Specifications Version 2.2. RFC 8017, November 2016. URL https://rfc-editor.org/rfc/rfc8017.txt.

[۲۸] OpenSSL. OpennSSL Security Advisory: CMS and S/MIME Bleichenbacher attack (CVE-2012-0884), March 2012. URL https://www.openssl.org/news/secadv/20120312.txt.

[۲۹] Radware. CVE-2017-17427 Adaptive chosen-ciphertext attack vulnerability, December 2017. URL https://support.radware.com/app/answers/answer_view/a_id/1010361.

[۳۰] Eric Rescorla. The Transport Layer Security (TLS) Protocol Version 1.3. Internet-Draft draft-ietf-tls-tls13-22, Internet Engineering Task Force, November 2017. URL https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-22. Work in Progress.

[۳۱] Eric Rescorla and Tim Dierks. The Transport Layer Security (TLS) Protocol Version 1.2. RFC 5246, August 2008. URL https://rfc-editor.org/rfc/rfc5246.txt.

[۳۲] Intel Security: September 2014. Advanced Threat Research. BERserk Vulnerability, URL http://www.intelsecurity.com/resources/wp-berserk-analysis-part-1.pdf.

[۳۳] Juraj Somorovsky. Systematic Fuzzing and Testing of TLS Li braries. In ACM SIGSAC Conference on Computer and Communications Security, CCS ’۱۶, pages 1492-1504, New York, NY, USA, October 2016. ACM. ISBN 978-1-4503-4139-4. doi: 10.1145/2976749. 2978411. URL https://www.nds.rub.de/research/publications/systematic-fuzzing-and-testing-tls-libraries/.

[۳۴] Serge Vaudenay. Security Flaws Induced by CBC Padding – Applicationsto SSL, IPSEC, WTLS. In Advances in Cryptology – EUROCRYPT 2002, International Conference on the Theory and Applications of Cryptographic Techniques, Amsterdam, The Netherlands, April 28 – May 2, 2002, Proceedings, volume 2332 of Lecture Notes in Computer Science, pages 534-546. Springer, May 2002. doi: 10.1007/3-540-46035-7 35. URL https://www.iacr.org/cryptodb/archive/2002/EUROCRYPT/2850/2850.pdf.

---

(۱) Key Exchange
(۲) adaptive chosen-ciphertext attack
(۳) query
(۴) stacks
(۵) social engineering
(۶) encoding
(۷) side-channels
(۸) cipher suites
(۹) handshake
(۱۰) peer
(۱۱) negotiated
(۱۲) plaintexts
(۱۳) multiply
(۱۴) tolerant
(۱۵) padding
(۱۶) byte concatenation
(۱۷) message block
(۱۸) ciphertext
(۱۹) decryptor
(۲۰) malleability
(۲۱) interval
(۲۲) unpadded
(۲۳) eavesdropped
(۲۴) conform
(۲۵) Java Secure Socket Extension
(۲۶) conjunction
(۲۷) timing
(۲۸) timeout
(۲۹) false positive
(۳۰) network latency
(۳۱) exotic
(۳۲) padded
(۳۳) parallelizing
(۳۴) terminator
(۳۵) missing padding zero terminator
(۳۶) non-deterministic
(۳۷) overhead
(۳۸) elliptic curve
(۳۹) non-deterministic
(۴۰) revocation
(۴۱) sub-variations
(۴۲) workarounds
(۴۳) leading
(۴۴) finite field
(۴۵) https://github.com/RUB-NDS/TLS-Attacker
(۴۶) https://github.com/tomato42/tlsfuzzer
(۴۷) shortened message flow
(۴۸) violation
(۴۹) https://www.tripwire.com/state-of-security/vert/return-bleichenbachers-oracle-threat-robot
(۵۰) https://dev.ssllabs.com
(۵۱) https://github.com/robotattackorg/robot-detect

ضمیمه A

ما یک امضا تولید کردیم که متن زیر را امضا می‌کند:

We hacked Facebook with a Bleichenbacher Oracle (JS/HB).

این متن به‌صورت PKCS # 1 v1.5 کد شده است و با گواهی‌نامه‌ای که بر روی www.facebook.com در زمان انجام این تحقیق مورداستفاده قرار گرفته است، امضا شده است.

ما دستوراتی را برای نمونه با استفاده از curl، xxd و openssl ارائه می‌کنیم که این امضا را تأیید می‌کنند. ما این گواهی را از موتور جستجوی Crt.sh دانلود می‌کنیم تا یک URL پایدار داشته باشیم. ما به‌عنوان یک راه‌حل جایگزین می‌توانیم آن را از سرورهای فیس‌بوک از طریق TLS دریافت کنیم اما بعدازاینکه گواهی منقضی ‌شود و فیس‌بوک آن را تغییر دهد، از کار می‌افتد.

این امضا از فرمت دستور OpenSSL’s rsautl استفاده می‌کند. این دستور پیام خام ورودی را امضا می‌کند و از هش کردن که بخشی از PKCS # 1 v1.5 است، استفاده نمی‌کند.

echo 799e43535a4da70980fada33d0fbf51ae60d32c1115c87ab29b716b49ab0

 ۶۳۷۷۳۳f92fc985f280fa569e41e2847b09e8d028c0c2a42ce5beeb640c101

d5cf486cdffc5be116a2d5ba36e52f4195498a78427982d50bb7d9d938ab9

۰۵۴۰۷۵۶۵۳۵۸b1637d46fbb60a9f4f093fe58dbd2512cca70ce842e74da078

۵۵۰d84e6abc83ef2d7e72ec79d7cb2014e7bd8debbd1e313188b63a2a6aec

۵۵de6f56ad49d32a1201f18082afe3b4edf02ad2a1bce2f57104f387f3b84

۰۱c5a7a8336c80525b0b83ec96589c367685205623d2dcdbe1466701dffc6

e768fb8af1afdbe0a1a62654f3fd08175069b7b198c47195b630839c66332

۱dc5ca39abfb45216db7ef837 | xxd -r -p > sig

curl https://crt.sh/?d=F709E83727385F514321D9B2A64E26B1A195751BBC

  AB16BE2F2F34EBB084F6A9|openssl x509 -noout -pubkey > pubkey.k

 ey

openssl rsautl -verify -pubin -inkey pubkey.key -in sig