چگونه آسیب پذیری Log4j را در برنامه های خود شناسایی کنیم

یک اشکال در کتابخانه همه جا حاضر Log4j می تواند به مهاجم اجازه دهد تا کد دلخواه را در هر سیستمی که از Log4j برای نوشتن گزارش استفاده می کند، اجرا کند. آیا مال شما؟

دیروز بنیاد آپاچی یک به‌روزرسانی اضطراری را برای صفر بحرانی منتشر کرد. آسیب‌پذیری روز در Log4j، یک ابزار ورود به سیستم همه‌جانبه که تقریباً در هر برنامه جاوا وجود دارد. این مشکل Log4Shell نام دارد و شناسه CVE-2021-44228 را دریافت کرده است. .

مشکل حول یک اشکال در کتابخانه Log4j است که می تواند به مهاجم اجازه دهد تا کد دلخواه را روی سیستمی که از Log4j برای نوشتن پیام های گزارش استفاده می کند، اجرا کند. این آسیب‌پذیری امنیتی تأثیر گسترده‌ای دارد و هر کسی با برنامه‌ای حاوی Log4j باید فوراً به آن توجه کند.

چرا آدرس دادن Log4Shell یک چالش بزرگ است

Log4j یک کتابخانه است که توسط بسیاری از برنامه های جاوا استفاده می شود. این یکی از فراگیرترین کتابخانه های جاوا تا به امروز است. اکثر برنامه‌های جاوا داده‌ها را ثبت می‌کنند، و هیچ چیز این را آسان‌تر از Log4j نمی‌کند.

چالش اینجا یافتن Log4j به دلیل نحوه کار بسته بندی جاوا است. این امکان وجود دارد که Log4j را در جایی از برنامه خود پنهان کرده باشید و حتی آن را ندانید.

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

اساساً، در دنیای جاوا، می‌توانید یک JAR تودرتو در یک JAR تو در تو در یک JAR داشته باشید. این لایه های زیادی را ایجاد می کند که همه باید بررسی شوند. فقط نگاه کردن به JARهایی که پروژه شما مستقیماً وارد می کند ممکن است کافی نباشد، زیرا Log4j ممکن است در داخل یک فایل JAR دیگر پنهان شود!

Log4j را با ابزارهای منبع باز اسکن کنید

دو ابزار منبع باز به رهبری Anchore وجود دارد که توانایی اسکن تعداد زیادی از قالب‌های وابستگی بسته‌بندی شده را دارند. ، وجود آنها را شناسایی کنید و در صورت وجود آسیب پذیری گزارش دهید. در این مورد، توانایی اسکن فایل‌های JAR، به ویژه لایه‌های تودرتوی فایل‌های JAR، چیزی است که می‌خواهیم. Syft یک صورتحساب نرم افزاری مواد (SBOM) و Grype یک اسکنر آسیب پذیری است. هر دوی این ابزارها می‌توانند چندین لایه تودرتو از آرشیوهای JAR را برای کشف و شناسایی نسخه‌های Log4j بازرسی کنند.

Syft همچنین قادر است تشخیص دهد که یک برنامه جاوا دارای کدام نسخه از Log4j است. Log4j JAR می‌تواند مستقیماً در پروژه ما گنجانده شود، یا می‌تواند در یکی از وابستگی‌های ما پنهان شود. به عنوان مثال، استفاده از Syft برای اسکن این پروژه نمونه جاوا نشان می دهد که شامل Log4j نسخه ۲.۱۴.۱ است که در برابر Log4Shell آسیب پذیر است.

صرف نظر از نسخه Log4j که گنجانده شده است، تولید و ذخیره یک SBOM برای نگه داشتن سابقه همه چیزهایی که در هر جزء نرم افزاری یا برنامه ای که ارائه می کنید دارای ارزش است. هنگامی که آسیب‌پذیری جدیدی پیدا می‌شود، مانند Log4Shell، جستجو در یک مخزن SBOM بسیار سریع‌تر از یافتن و اسکن همه برنامه‌های جاوا است.

Grype اسکنر است که این توانایی را دارد که به ما بگوید نرم افزار ما دارای کدام آسیب پذیری های خاص است. هنگامی که یک وابستگی را در برنامه خود قرار می دهید، همچنین می توانید آسیب پذیری هایی را که این وابستگی شامل می شود و غیره را از طریق چندین سطوح تودرتو شناسایی کنید. Grype می تواند نرم افزار را مستقیماً اسکن کند یا SBOM تولید شده توسط Syft را اسکن کند. این به شما امکان می دهد حتی پس از استقرار یا تحویل نرم افزار به مشتریان، SBOM را برای آسیب پذیری های جدید دوباره اسکن کنید.

اسکن کردن همان پروژه نمونه جاوا با Grype آسیب‌پذیری Log4j را پیدا می‌کند و آن را به عنوان یک شدت بحرانی شناسایی می‌کند.

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

Syft و Grype را در دسترس داشته باشید

هر زمان که آسیب‌پذیری روز صفر جدیدی کشف شود، رفع سریع مشکل برای سازمان‌های متاثر می‌تواند دشوار و چالش برانگیز باشد. اولین و مهمترین قدم این است که بفهمید آیا یک آسیب پذیری خاص حتی بر شما تأثیر می گذارد یا خیر، و در مورد فایل های JAR، درک این موضوع بدون ابزارسازی می تواند چالش برانگیز باشد. ابزارهای Grype و Syft منبع باز Anchore تا انتهای درخت وابستگی شما حفاری می‌کنند تا تشخیص دهند آیا نسخه‌ای از Log4j در جایی پنهان شده است یا خیر.

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

جاش برسرز معاون امنیت در Anchore است.

—

New Tech Forum مکانی برای کاوش و بحث در مورد فناوری سازمانی نوظهور در عمق و وسعت بی سابقه ای فراهم می کند. انتخاب ذهنی است، بر اساس انتخاب ما از فناوری هایی که معتقدیم مهم هستند و برای خوانندگان InfoWorld بیشترین علاقه را دارند. InfoWorld وثیقه بازاریابی را برای انتشار نمی پذیرد و حق ویرایش تمام محتوای ارائه شده را برای خود محفوظ می دارد. همه سوالات را به newtechforum@infoworld.com ارسال کنید.