در 25 اکتبر تیم OpenSSL یه هشدار امنیتی در خصوص یه آسیب پذیری حیاتی در OPENSSL نسخه های 3.0.0 تا 3.0.6 منتشر کرد و اعلام کرد که نسخه اصلاح شده (3.0.7) در تاریخ 1 نوامبر بین ساعات 13 تا 17 UTC (برابر با 10 آبان و ساعت بین 16:30 تا 22:30 تو ایران میشه)، منتشر میکنه.
نکته : پست براساس محتوای منتشر شده ، بروزرسانی خواهد شد.
[بروزرسانی 21:20 – 10 آبان] : نسخه 3.0.7 بهمراه توضیحات منتشر شد و به انتهای مقاله اضافه شد.
[بروزرسانی 21:58 – 10 آبان] : جزییات آسیب پذیری CVE-2022-3602 بهمراه POC اضافه شد.
این هشدار سروصدای زیادی تو جامعه امنیت ایجاد کرد.دلیلش هم اینکه تیم OPENSSL کمتر هشدار در سطح حیاتی میده .
در کل آسیب پذیری برای تیم OPENSSL حیاتی طبقه بندی میشه که ، روی نسخه های رایج تاثیر بزاره و قابل اکسپلویت شدن هم باشه.برای مثال آسیب پذیری هایی که مقدار قابل توجهی از محتوای حافظه سرور بخصوص اطلاعات کاربر رو افشا کنه ، اکسپلویت اون باعث اجرای کد یا منجر به خطر افتادن کلیدهای خصوصی سرور از راه دور و به سادگی بشه، تو این طبقه بندی هستن.
آخرین باری که تیم OPENSSL هشدار حیاتی داده به سال 2014 برمیگرده و آسیب پذیری معروف Heartbleed که ، منجر به افشای اطلاعات حافظه از سرور به کلاینت یا برعکس میشد.
آسیب پذیری CVE-2014-0160 یا Heartbleed یه آسیب پذیری حیاتی بود که باعث شد مهاجمین امکان استراق سمع شبکه ، سرقت داده های کاربران و جعل هویت رو داشته باشن. این آسیب پذیری روی محصولات مختلفی مانند Nginx و Apache و IIS و سازمانها و شرکتهای بزرگی مانند Google و Akamai و CloudFlare و Facebook و Cisco و ارائه دهندگان VPN تاثیر گذاشته بود.
این نگرانی به دلیل استفاده گسترده از کتابخونه OPENSSL هستش اما نکته ای که وجود داره اینکه نسخه خیلی رایج این کتابخونه ، نسخه 1.x.x هستش و آسیب پذیری در نسخه های 3.0.0 تا 3.0.6 هستش.
ابزار OpenSSL چیه؟
یه جعبه ابزار نرم افزاری منبع باز هستش و در پروژه ها و نرم افزارهای مختلف به روش های مختلف بارگذاری و استفاده میشه. بر همین اساس هستش که وجود آسیب پذیری در اون میتونه خطرناک باشه.
سه جزء این ابزار شامل :
- کتابخونه libcrypto : یه کتابخونه رمزنگاری هستش که پروتکل های مختلفی مانند AES و RSA و … توش پیاده سازی شدن.
- کتابخونه libssl : این کتابخونه نسخه های مختلف TLS رو تا TLSv1.3 پیاده سازی کرده.
- اجرایی openssl : یه ابزار کامندلاینی برای انجام عملیات مختلف مثلا تولید گواهینامه
اقدامات کاهشی برای آسیب پذیری OPENSSL :
برنامه ها برای انجام کارهای مختلف اغلب کتابخونه های libcrypto و libssl رو لوود و اجرا میکنن. بنابراین برخلاف سایر برنامه ها که شناسایی نسخه آسیب پذیر اونها ساده هست. در مورد OPENSSL با یه چالش شناسایی هم روبرو هستیم. در اصل اولین گام برای کاهش آسیب پذیری در OPENSSL شناسایی دارایی های آسیب پذیر هستش. برای همین منظور تیم OPENSSL اولش یه هشدار داده تا ادمین ها فرصت کافی برای شناسایی دارایی هایی که از OPENSSL استفاده میکنن رو داشته باشن.
نکته مهم دیگه اینه که اگه وصله منتشر بشه ، برای همه برنامه هایی که از OPENSSL استفاده میکنن جوابگو نیست. چون برخی از برنامه ها باید توسط خود سازنده بروزرسانی بشن. یعنی ما باید بجای بروزرسانی OPENSSL باید خود نرم افزار X رو بروزرسانی کنیم و بنابراین نیاز زمان داریم تا شرکت سازنده نرم افزار ،نسخه اصلاح شده رو منتشر کنه.برای همین 2 تا توصیه شده:
- محدودیت های سخت تری رو در قالب DMZ به دارایی هایی که در مواجه با اینترنت قرار دارن ، اعمال کنید.
- از segmentation یا بخش بندی در دامنه استفاده کنید تا اگر سیستمی دچار نقض شد، این نقض در کل دامنه گسترش پیدا نکنه.
همچنین ایجاد یه لیست از دارایی ها ، قبل از اعمال بروزرسانی و بعدش ، میتونه کمک کنه تا شبکه و داراییهامون بطور کامل از دید این آسیب پذیری ، امن بکنیم.
در ادامه برای اینکه بتونیم دارایی هایی که از OPENSSL استفاده میکنن رو تشخیص بدیم ، دو تا رویکرد رو داریم:
- برنامه هایی که میدونیم از OPENSSL3 استفاده میکنن، رو لیست کنیم.مثلا براساس کاتالوگ و …
- روشی داشته باشیم که باینری ها رو چک کنه تا در صورتیکه از OPENSSL3 استفاده میکنن رو مشخص کنه.
چه برنامه های شناخته شده ای آسیب پذیر هستن؟
کتابخونه های LibreSSL و BoringSSL (که در مرورگر کروم استفاده میشه) ، براساس کد های OpenSSL توسعه داده شدن، اما تحت تاثیر آسیب پذیری نیستن.
توزیعهای لینوکسی زیر با توجه به اینکه همراه با کتابخونه OpenSSL ارائه میشن ، میتونن آسیب پذیر باشن:
Redhat Enterprise Linux 9
Ubuntu 22.04+
CentOS Stream9
Kali 2022.3
Debian 12
Fedora 36
البته اگه از نسخه ای استفاده میکنید که در لیست بالا نیست، تضمین کننده آسیب پذیر نبودنتون نیست. چرا ؟ چون ممکنه شما توزیع رو نصب و در حال استفاده باشید اما به مرور زمان کتابخونه رو بروزرسانی کرده باشید و به نسخه آسیب پذیر ارتقاء داده باشید. راه حل؟ بررسی نسخه OPENSSL با دستور زیر :
|
1 |
openssl version |
برای داکر هم میتونید از این لینک استفاده کنید.اما بطور کلی تخمین زده شده که 1000 image در مخازن مختلف Docker Official و Docker Verified Publisher تحت تاثیر این آسیب پذیری هستن که imageهایی هستن که براساس توزیعهایی که در بالا اشاره شد، منتشر شدن.
فریمورکNode.js v18.x و v19.x از Openssl 3 استفاده میکنن و بنابراین تحت تاثیر این آسیب پذیری هستن. اگه از این فریمورکها استفاده میکنید، جزییات اینجا بروزرسانی میشه. مثلا گفته شده که نسخه های Node.js 14.x و v16.x تحت تاثیر این آسیب پذیری نیستن.
همچنین وقتی آسیب پذیری OPENSSL منتشر شده ، یه بروزرسانی امنیتی در GOLANG هم منتشر شده ، که خیلیا فک میکنن این دو تا به هم مرتبط هستن که اینجوری نیست.
[بروزرسانی 21:20 – 10 آبان] : لیست برنامه هایی که تحت تاثیر این آسیب پذیری هستند رو میتونید از اینجا بدست بیارید.
روش کلی برای شناسایی برنامه هایی که از OPENSSL 3 استفاده می کنن
کتابخونه OPENSSL رو هم میشه بصورت استاتیک و هم داینامیک در برنامه ها استفاده کرد. فرقشونم اینکه تو استاتیک کدهای OPENSSL بعنوان بخشی از کدهای برنامه گنجونده شده و هر دو تو یه فایل اجرایی کامپایل شدن. تو روش داینامیک بصورت جداگانه و بصورت کتابخونه که در ویندوزیها libssl.dll و libcrypto.dll و در لینوکسی ها libssl.so و libcrypto.so ، هستش و هر وقت نیازه توسط سیستم عامل لوود و اجرا میشه.
برای اینکه بتونیم هر دو رو تشخیص بدیم ، فقط نیاز هستش که باینری هایی که بصورت استاتیک کامپایل شدن رو بدست بیاریم. چرا ؟ چون اگه یه باینری بصورت داینامیک OPENSSL رو لوود کنه یا حتی یه کتابخونه دیگه ای رو لوود کنه که این کتابخونه بصورت داینامیک کتابخونه OPENSSL رو لوود کنه ، در نهایت کتابخونه های OPENSSL که بصورت استاتیک کامپایل شدن لوود میشن. بنابراین با توجه به اینکه همه بارگذاری های داینامیک داخل یه پروسس اتفاق می افته ، پس با بدست آوردن لیست کتابخونه های لوود شده در پروسس و بررسی کتابخونه ایستا OPENSSL تو این لیست، قابل شناسایی هستش.
نکته باقی مونده اینکه ما چطوری کتابخونه استاتیک OPENSSL رو تشخیص بدیم؟ همه نسخه های استاتیک یه رشته دارن که توش ،نسخه اشون رو نوشته. مانند :
|
1 |
OpenSSL 3.0.6 11 Oct 2022 |
خب تو این رشته ،3.0.6، نشون دهنده نسخه هستش و تشخیص اون با Regex یا YARAخیلی ساده هستش.
نکته ای که در خصوص این رشته وجود داره اینکه چون OPENSSL منبع باز هستش، هر کی میتونه با توجه به نیازهای خودش تغییراتی رو ایجاد کنه. مثلا سیسکو این رشته رو به رشته زیر تغییر داده :
|
1 |
CiscoSSL 1.1.1k.7.2.225 |
شناسایی با رولهای Yara :
با فرض اینکه روی نسخه های خود OPENSSL تمرکز کنیم میتونیم از رول YARA زیر برای شناسایی استفاده کنیم :
|
1 2 3 4 5 6 |
rule openssl_version { strings: $re1 = /OpenSSL\s3\.[0-6]{1}\.[0-9]{1}[a-z]{,1}/ condition: $re1 } |
این رول تو فایلها میگیرده و اگه داخلشون رشته مدنظر ما باشه اونو نشون میده.
روش بعدی هم اینکه فایلهای اجرایی رو اسکن کنیم و اگه توش کتابخونه ای بود که OPENSSL توش بود اونو برامون نشون بده. این رول هم بدین شکله :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
import "elf" import "pe" rule elf_import_openssl { condition: (elf.type == elf.ET_EXEC or elf.type == elf.ET_DYN) and ( for any i in (0..elf.symtab_entries): ( elf.symtab[i].name contains "@OPENSSL_3" ) ) } rule pe_import_openssl { condition: pe.is_pe and ( for any i in (0..pe.number_of_imports): ( pe.import_details[i].library_name contains "libcrypto-3" or pe.import_details[i].library_name contains "libssl-3" ) ) } |
برای دوستانی که نمیدونن چطوری رول های YARA رو اجرا کنن : (داکیومنتش رو میتونید از اینجا بخونید یا این ویدیو رو ببینید)
- ابتدا باید باینریش رو دانلود کنید.
- رولهای بالا رو تو یه فایل قرار بدید، با فرمت yara. مثلا rul1.yara
- بعد دانلود اونو از حالت فشرده خارج کنید.
- یه cmd باز کنید و دستور زیر توش وارد کنید:
|
1 2 3 4 5 6 7 8 9 10 11 |
yara64 -r rul1.yara c:\desktop\salam.exe فقط فایل سلام رو چک میکنه yara64 -r rul1.yara --scan-list c:\desktop\salam.txt فایلهای داخل فایل سلام رو اسکن میکنه yara64 -r rul1.yara c:\desktop\ فایلهای داخل فولدر دسکتاپ رو میگرده yara64 -r rul1.yara -r c:\desktop\ فایلها و فولدرهای داخل فولدر دسکتاپ رو میگرده |
- اگه آسیب پذیر باشه جلو اسم فایل ، اسم رول مینویسه. یعنی openssl_version رو برای رول اولی.
شناسایی با OSQuery :
تو OSQuery هم با رولهایی که بالا اشاره شد میتونید این فرایند رو انجام بدید،تو قسمت YARA table میتونید این رولها رو اجرا کنید :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
WITH FIRST_QUERY AS (SELECT DISTINCT proc.pid, proc.path, proc.cmdline, proc.cwd, mmap.path AS mmap_path FROM process_memory_map AS mmap LEFT JOIN processes AS proc USING(pid) SELECT * FROM FIRST_QUERY JOIN yara ON yara.path = FIRST_QUERY.mmap_path WHERE sigrule = 'rule openssl_3 { strings: $re1 = /OpenSSL\s3\.[0-6]{1}\.[0-9]{1}[a-z]{,1}/ condition: $re1 } ' AND yara.count > 0 |
شناسایی با پاورشل و BASH :
[بروزرسانی 21:20 – 10 آبان] با این ابزارها هم میتونید اسکن کنید. نسخه لینوکسی | نسخه ویندوزی
[بروزرسانی 21:20 – 10 آبان]
آسیب پذیری با شناسه CVE-2022-3786 :
آسیب پذیری از نوع Stack Buffer overflow هستش و در بررسی گواهینامه X.509 و بررسی قسمت name constraint رخ میده. نکته ای که وجود داره ، برای اکسپلویت نیاز هستش که یه CA این گواهی مخرب رو امضا کرده باشه یا کاربر هشدار رو جدی نگیره و ادامه بده. مهاجم میتونه ایمیل مخرب رو با تعداد زیادی . (نقطه – دسیمال 46) پر کنه تا سرریز بافر رخ بده. این سرریزبافر میتونه منجر به کرش یا DoS بشه تو کلاینت های TLS با اتصال به سرور مخرب میتونه فعال بشه. در سرور های TLS ، اگه سرور از کلاینت مخرب درخواست احراز هویت کنه ، میتونه فعال بشه. آسیب پذیری توسط Viktor Dukhovni گزارش شده.
آسیب پذیری با شناسه CVE-2022-3602 :
آسیب پذیری از نوع Stack Buffer overflow هستش و در بررسی گواهینامه X.509 و بررسی قسمت name constraint رخ میده. نکته ای که وجود داره برای اکسپلویت نیاز هستش که یه CA این گواهی مخرب رو امضا کرده باشه یا کاربر هشدار رو جدی نگیره و ادامه بده.مهاجم میتونه یه ایمیل مخرب ایجاد کنه که منجر به سرریز بافر و کنترل برنامه در پشته بشه. سرریز میتونه منجر به اجرای کد یا کرش بشه. با توجه به اینکه بسیاری از پلتفرم ها حفاظت از سرریز پشته رو اجرا میکنن، امکان اجرای کد کاهش پیدا میکنه.این آسیب پذیری قبلا حیاتی معرفی شده بود اما با توجه به تجزیه و تحلیل و نیازمندی های بالا برای اجرای موفق اکسپلویت به طبقه بندی “بالا” تنزل پیدا کرده. تو کلاینت های TLS با اتصال به سرور مخرب میتونه فعال بشه. در سرور های TLS ، اگه سرور از کلاینت مخرب درخواست احراز هویت کنه ، میتونه فعال بشه. آسیب پذیری توسط Polar Bear گزارش شده.
[بروزرسانی 21:58 – 10 آبان]
جزییات این آسیب پذیری :
این آسیب پذیری تو تابع ossl_punycode_decode رخ میده. این تابع کارش دیکد کردن دامنه های Punycode هستش. برای اطلاعات بیشتر در خصوص این دامنه ها میتونید به RFC3492 مراجعه کنید اما بطور کلی برای تبدیل دامنه های بین المللی از یونیکد به اسکی استفاده میشه. مثلا حرف یونانی آلفا (Unicode 0251).
اگه دامنه ما بصورت dɑtadog.com (a اولی آلفا) باشه، دامنه تبدیل به International Domain Name in Applications (IDNA) میشه. حالا کامپیوترها دامنه های IDNA رو به دامنه punycode تبدیل میکنن. در مثال ما dɑtadog.com تبدیل به xn--dtadog-bxc.com میشه. در حقیقت xn– مشخص کننده دامنه punycode هستش.
تو تابع ossl_punycode_decode یه بافر رشته ای از دامنه punycode میگیره و تبدیل به یونیکد میکنه. این تابع زمانی فراخوانی میشه که یه کلاینت یا سرور برای تأیید اعتبار گواهی X.509 پیکربندی شده باشن. یه مهاجم میتونه با ایجاد یک گواهی خاص که حاوی punycode در فیلد email address هستش، این آسیب‌پذیری رو اکسپلویت کنه.
سناریوی کلی :
برای تست آسیب پذیری میتونید از این PoC استفاده کنید .
تحلیل تکنیکالی اکسپلویت رو هم میتونید از اینجا دریافت کنید.