چرا آسیب پذیری log4shell خطرناک است؟ و چگونه باید آن را رفع کرد؟
آن‌چه می‌خوانید، نوشته‌ی رامین فرج‌پور، از اعضای تیم راورو، در تحلیل آسیب پذیری روزصفر (ZeroDay) کشف‌شده از کتابخانه‌ی مشهور log4j جاوا است؛ این آسیب‌پذیری همه‌گیر در آخرین روزهای سال ۲۰۲۱، مهمان ناخوانده‌ی کریسمس سامانه‌های با پشتیبانی جاوا شده که از کتابخانه‌ی log4j برای گزارش‌گیری استفاده می‌کنند.
آن‌چه در این بلاگ‌پست خواهید خواند:
• احتمالا شما هم شنیده‌اید...
• آسیب پذیری log4shell از کجا پیدا شد؟
• شدت خطر آسیب پذیری log4shell چگونه است؟
• تحلیل و بررسی آسیب پذیری log4shell
• بررسی فنی آسیب پذیری log4shell
• جدول زمانی – Timeline
• نحوه‌ی جلوگیری از آسیب پذیری log4shell
• ابزار بررسی وجود این آسیب‌پذیری؛ Log4Shell Looker
• چگونه می‌توانیم بفهمیم که آیا از طریق این آسیب پذیری موردحمله قرار گرفته‌ایم؟ یا نه؟ (فارنزیک)
احتمالا شما هم شنیده‌اید...
همین چند روز پیش، در ۹ دسامبر ، محققان کد سوءاستفاده‌ی اثبات مفهوم (PoC) را برای یک آسیب‌پذیری مهم در Apache Log4j 2 منتشر کردند. این آسیب پذیری مربوط به کتابخانه‌ی گزارش‌گیری (Logging) جاوا بود.از آن‌جا که این کتابخانه بر پایه‌ی جاوا است، این احتمال وجود دارد که ۳ میلیارد دستگاهی که از جاوا استفاده می‌کنند نیز در خطر باشند! این کتابخانه توسط بسیاری از برنامه‌ها و سرویس‌ها مورداستفاده قرار می‌گیرد، سرویس‌ها و برنامه‌هایی نظیر:
• Apache Druid
• Apache Flink
• Apache Solr
• Apache Spark
• Apache Struts2
• Apache Tomcat
• و...
همهی این سرویس‌ها توسط تیم Apache و به صورت اوپن سورس ارائه شده است. (البته محدود به سرویس‌های زیر نیست)
آسیب پذیری log4shell از کجا پیدا شد؟
ماجرای کشف این آسیب‌پذیری با گزارش‌هایی آغاز شد که نشان می‌دادند که چندین نسخه از بازی ویدیویی محبوب sandbox، بازی Minecraft، تحت‌تأثیر این آسیب پذیری قرار گرفته‌اند.
این آسیب پذیری در ادامه هم بسیار خبرساز شد! حتی شرکت‌های بزرگی مانند Apple، VMware، Twitter و ... آسیب پذیر بودن خود نسبت به این آسیب پذیری را تایید کردند.
https://thehackernews.com/2021/12/extremely-critical-log4j-vulnerability.html
شدت خطر آسیب پذیری log4shell چگونه است؟
این آسیب پذیری در محاسبه‌ی شدت خطر و حساسیت طبق فرمول CVSS، مقدار 10 از 10 (حداکثر مقدار ممکن) را کسب کرده است! این میزان حساسیت و خطر باعث شد که مدیرعامل شرکت ارائه‌دهنده‌ی خدمات ابری CloudFlare در توییتی برای مخاطبان و مشتریان خود، درصدد ارائه‌ی راهکار برای جلوگیری از سوءاستفاده‌های ممکن از این آسیب پذیری برآید.
تحلیل و بررسی آسیب پذیری log4shell
بگذارید به سراغ توضیح تحلیل و بررسی این آسیب پذیری که از سوی محققان log4shell نامیده شده است، برویم. شناسه‌ی آسیب پذیری CVE-2021-44228 مربوط به یک آسیب‌پذیری اجرای کد از راه دور (RCE) در Apache Log4j 2 است. یک مهاجم از راه دور می‌تواند با سوءاستفاده از این آسیب پذیری، یک درخواست جعلی خاص به سروری که نسخه‌ی آسیب‌پذیر log4j را اجرا می‌کند، ارسال کند. درخواستی که از تزریق نام‌گذاری جاوا و رابط دایرکتوری (JNDI) از طریق انواع خدمات دست‌کاری شده، خدماتی از جمله:
• Lightweight Directory Access Protocol (LDAP)
• Secure LDAP (LDAPS)
• Remote Method Invocation (RMI)
• Domain Name Service (DNS)
در سرویس‌هایی که از کتابخانه‌ی log4j برای گزارش‌گیری درخواست‌های خود استفاده می‌کنند، این کد مخرب ( exploit ) باعث می‌شود که کد JNDI که توسط مهاجم به سمت سرور ارسال می‌شود، کنترل نشود و درخواست ارسالی از سمت مهاجم با موفقیت به اجرا درآید.
معماری کلی از نحوه‌ی اکسپلویت این آسیب پذیری:
منبع :
https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j
در حال حاضر این نحوه‌ی اکسپلویت از این آسیب پذیری به صورت عمومی افشا شده است.
لینک منبع :
https://github.com/search?q=CVE-2021-44228&ref=simplesearch
بررسی فنی آسیب پذیری log4shell
کتابخانه‌ي Java Naming and Directory Interface (JNDI) یک API جاوا برای یک سرویس دایرکتوری است که به مهاجم این امکان را می‌دهد، که برای جستجوی داده‌ها و منابع با LDAP یا DNS ارتباط برقرار کند. متأسفانه، یک نوع از داده‌هایی که می‌توان برگرداند، یک URI است که به یک کلاس جاوا اشاره می‌کند – و اگر یک کلاس جاوا نامعتبر بارگیری شود، ناخواسته کد شخص دیگری اجرا می‌شود...
حالا بیایید این مورد را در نسخه‌ی2.14.1 log4j امتحان کنیم تا ببینیم به چه شکل رخ می‌دهد. همان‌طور که می‌بینید با اجرای کد، درخواست به URL مورد نظر ارسال می‌شود.
ادامه بررسی از این آسیب پذیری و اجرای دستورات سیستم عامل :
خروجی این دستور :
همچنین :
خروجی این دستور :
جدول زمانی Timeline
در ۲۴ نوامبر ۲۰۲۱، شرکت نرم‌افزاری Apache نیز، توسط تیم Alibaba Cloud Security از این آسیب پذیری اجرای کد از راه دور Log4j مطلع شد. PoC این آسیب پذیری نیز در ساعت ۱۵:۳۲ به وقت گرینویچ در ۹ دسامبر ۲۰۲۱ در Github منتشر شد و بعد از مدت کوتاهی حذف شد.
این آسیب پذیری مانند هر آسیب پذیری یا باگ گستردهی دیگری که حساسیت بالایی دارد، مورد توجه و استقبال هکرهای کلاه سیاه قرار گرفته است. هکرهای کلاه‌سیاه و نفوذگران غیرقانونی نیز تمام تلاش خود را به کار می‌گیرند تا حداکثر فایده‌ی ممکن را ببرند. از موقعیت موجود و آسیب پذیر بودن اکثر سرورها نسبت به این آسیب پذیری، سوءاستفاده کنند. با بررسی‌هایی که با استفاده از سامانه‌ی Shodan انجام شده تعداد زیادی از سرویس‌های مختلف در اینترنت وجود دارد که از این سرویس گزارش‌گیری استفاده می‌کنند. لیستی از محصولات شرکت‌هایی که در خطر این آسیب پذیری هستند:
در همهی سرویس‌های موجود در لیست اگر log4j به‌روزرسانی نشود، آسیب پذیر هستند.
لینک :
https://www.shodan.io/search?query=product%3Akafka%2Celastic%2Ctomcat%2Cminecraft%2Credis
نحوه‌ی جلوگیری از آسیب پذیری log4shell
در حال حاضر تیم Apache نسخه‌ی جدیدی را برای وصله‌ی این آسیب پذیری ارائه داده‌اند که با نصب آن می‌توانید خطر را خنثی کنید.
https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc1
• کتابخانه‌ی log4j را به آخرین نسخه‌ی log4j ارائه‌شده به‌روز کنید.
• برای نسخه‌های قبلی می‌توانید در بخش تنظیمات، ویژگی سیستم log4j2.formatMsgNoLookups را روی true بگذارید و با افزودن پارامتر جاوا زیر خطر را کاهش دهید: Dlog4j2.formatMsgNoLookups=true-
• از سرویس‌های ابری مانند CloudFlare و Arvancloud استفاده کنید.
داخل پرانتز: نسخه‌ی JDK بزرگ‌تر از 6u211، 7u201، 8u191 و 11.0.1 تحت تأثیر این حمله‌ی LDAP قرار نمی‌گیرند. ( در تست‌های انجام شده بر روی نسخه‌ی 11.0.2 و 17.0.1، آسیب پذیری مشاهده نشد.)
ابزار بررسی وجود این آسیب‌پذیری؛ Log4Shell Looker
با بررسی ویژگی‌های این آسیب‌پذیری روزصفر، ابزاری را به زبان GO ایجاد کردم تا بتوانید به‌سادگی و با اجرای یک دستور در خط فرمان از آسیب‌پذیر بودن سامانه‌ی خود نسبت به این آسیب‌پذیری اطلاع پیدا کنید: «Log4Shell Looker»
لینک دسترسی به این اسکنر در گیت‌هاب راورو: https://github.com/ravro-ir/log4shell-looker
ابزار Log4Shell Looker برای بررسی وجود آسیب‌پذیری Log4Shell، پنج روش متفاوت را در اختیارتان قرار می‌دهد؛
دستور لازم برای استفاده از روش header:
1$ go run main.go -mode=header -url=http://127.0.0.1:8080/ 2
دستور لازم برای استفاده از روش useragent:
1$ go run main.go -mode=useragent -url=http://127.0.0.1:8080/ 2
دستور لازم برای استفاده از روش cookie:
1$ go run main.go -mode=cookie -url=http://127.0.0.1:8080/ 2
دستور لازم برای استفاده از روش urlpath:
1$ go run main.go -mode=urlpath -url=http://127.0.0.1:8080/ 2
دستور لازم برای استفاده از روش contents:
1$ go run main.go -mode=contents -url=http://127.0.0.1:8080/ 2
با بررسی از طریق هر پنج روش، می‌توانید از وجود یا عدم وجود آسیب‌پذیری اطمینان پیدا کنید.
چگونه می‌توانیم بفهمیم که آیا از طریق این آسیب پذیری موردحمله قرار گرفته‌ایم؟ یا نه؟ (فارنزیک)
با این حجم گستردهی سامانه‌های درگیر با این آسیب پذیری و خطراتی که این آسیب پذیری دربر دارد، بهتر است تنها به به‌روزرسانی اتکا نکنید. چراکه ممکن است در بازه‌ی زمانی گذشته سامانه‌ی شما هم از طریق این آسیب پذیری مورد سو استفاده قرار گرفته باشد. برای این که بررسی کنید که « کسب‌وکار شما مورد این حمله در این بازه زمانی مشخص قرار گرفته یا نگرفته است؟» می‌توانید با این دستورات لینوکسی ساده، به راحتی لاگ فایل‌های وب سرور خود را بررسی کنید.
1$ sudo cat /var/log/nginx/access.log | grep jndi 2 3$ grep -r “jndi” /var/log 4
منبع :
https://www.fastly.com/blog/digging-deeper-into-log4shell-0day-rce-exploit-found-in-log4j