حمله Dependency Confusion چیست؟

یکی از نرم‌افزارهایی که زیاد مورد استفاده برنامه‌نویسان قرار گرفته و امکانات کاملی را برای آنها جهت توسعه نرم‌افزارها ارایه می‌دهد، «محیط‌های توسعه یکپارچه» یا IDE است. این برنامه به طور معمول ویژگی‌هایی از قبیل کامپایل، راه‌اندازی و اشکال‌زدایی نرم‌افزار را در اختیار برنامه‌نویسان قرار می‌دهد.

اخیراً مهاجمان سایبری شروع به سوءاستفاده از یک نقص امنیتی جدید کرده‌اند که به آنها امکان می‌دهد با فریب محیط‌های توسعه یکپارچه (IDE) بتوانند بسته‌های مخربی را در آنها تزریق کنند. در این مطلب از فراست شما را با این روش جدید آشنا می‌کنیم.

Dependency Confusion چیست؟

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

پیچیدگی‌های زنجیره تأمین نرم‌افزار

بر اساس مطالعات صورت گرفته، بیش از 99 درصد برنامه‌های کاربردی مورد استفاده سازمان‌ها شامل کدهای منبع باز هستند و چنین کدهایی نیز در مجموع، حداقل 70 درصد از مخازن کدهای استفاده شده توسط سازمان‌ها را تشکیل می‌دهند. دلیل به وجود آمدن این شرایط، زیست بوم بزرگ بسته‌ها (پکیج) و بسته‌های شخص ثالثی است که برای زبان‌های برنامه‌نویسی مختلف ایجاد شده اند.

زبان برنامه‌نویسی جاوا بسته Central Repository، زبان جاوا اسکریپت بسته npm، زبان پایتون بسته PyPI و زبان روبی بسته RubyGems را دارد. همه این مخازن و محتویات آنها توسط جامعه طراحان و برنامه‌نویسان، نگهداری و به روزرسانی می‌شوند. زمانی که بسته‌های مورد نظر به عنوان وابستگی در ابزارهای توسعه تعریف شوند، این ابزارها آنها را از مخازن مربوطه استخراج می‌کنند.

با توجه به رابطه پیچیده‌ای که بین این بسته‌ها وجود دارد، بنابراین وارد کردن یک بخش از آنها به عنوان یک وابستگی در برنامه‌ای کاربردی، منجر به ورود ده‌ها یا حتی صدها بسته دیگر می‌شود. با توجه به اینکه نظارت درستی بر این مخازن وجود ندارد، محققان امنیت سایبری هشدار می‌دهند که مهاجمان سایبری همواره می‌توانند از این وابستگی‌ها سوءاستفاده کنند.

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

نحوه عملکرد حملات Dependency Confusion

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

Birsan متوجه شده توسعه دهندگان در هنگام ایجاد برنامه‌های کاربردی، بسته‌های کد و کتابخانه‌ها را علاوه بر مخازن عمومی، از منابع خصوصی هم که در خود سازمان‌ها طراحی شده است استخراج می‌کنند. این بسته‌ها در نهایت در مخازن خصوصی آنها نگهداشته می‌شوند. به همین دلیل معمولاً ابزارهای مدیریت این بسته‌ها مثل npm در جاوا اسکریپت، pip در پایتون، gem در روبی و سایر محیط‌های توسعه به کاربران اجازه می‌دهند منابع جانبی برای استخراج این بسته‌ها را تعریف کنند. در نتیجه سؤالی که برای Birsam به وجود آمد این بود که وقتی یک بسته هم در مخزن خصوصی و هم در مخازن عمومی وجود دارد، پس کدام یک از آنها مورد استفاده قرار می‌گیرد؟

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

Birsan در تابستان 2020 و زمانی که با یکی از دوستانش در حال تلاش برای پیدا کردن باگ در سرویس پرداخت و انتقال پول پی‌پال بود (برای طرح شکار باگ پی‌پال) به این ایده رسید. تحقیقات این دو نفر، آنها را به سمتی هدایت کرد که شروع به بررسی کدهای طراحی شده و مورد استفاده در پی‌پال کردند که در مخازن عمومی میزبانی می‌شدند.

Birsan در یک مطلب وبلاگی که حاوی جزییات کاملی از این فن است، نوشته: «کدی که برای استفاده داخلی در پی‌پال طراحی شده و در فایل package.json قرار داشت، حاوی ترکیبی از وابستگی‌های عمومی و خصوصی بود؛ بسته‌های عمومی از npm و بسته‌های خصوصی که به احتمال زیاد در خود شرکت پی‌پال میزبانی می‌شوند. این نام‌ها در آن زمان در مخزن npm عمومی قرار نداشتند».

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

این حمله با موفقیت اجرا شد و Birsan توانست جایزه 30 هزار دلاری پی‌پال را برنده شود. در نتیجه او سعی کرد این حمله را بر  سایر سازمان‌هایی که طرح شکار باگ دارند اجرا کند. در پایان نیز مشخص شد که پیدا کردن نام بسته‌های خصوصی کار سختی نیست و این کار را می‌توان با پویش فایل‌های جاوا اسکریپت یا مخازن عمومی در GitHub انجام داد.

Birsan توانست این فن را با موفقیت روی سرورهای بیش از 35 سازمان از جمله پی‌پال، اپل، شاپیفای، نت‌فلیکس، اوبر و یلپ اجرا کرده و از آنها پاداش دریافت کند. او می‌گوید: «میزان موفقیت این ایده فوق العاده بود. بین اشتباه‌های تصادفی توسعه دهنده‌ها، پیکربندی اشتباه سرورهای داخلی و مبتنی بر ابر و ابزارهای توسعه آسیب‌پذیری یک نقطه مشترک وجود داشت و آن به دست آوردن نام داخلی بسته‌های مورد استفاده در شرکت‌ها، روشی مطمئن برای نفوذ به شبکه بزرگترین شرکت‌ها، اجرای کد از راه دور و حتی نصب در پشتی در این سیستم‌ها بود».

روش‌های مقابله با حملات Dependency Confusion

بدیهی‌ترین روش برای مقابله با این مشکل، عدم استفاده از پیکربندی‌های ترکیبی هنگام استفاده از مخازن عمومی و خصوصی است. ابزارهای مدیریت بسته باید به‌ گونه‌ای پیکربندی شوند که همیشه از مخازن خصوصی تحت نظارت و کنترل سازمان که همه بسته‌های آن همواره بررسی و موشکافی می‌شوند، استفاده کنند. بعضی از ابزارهای مدیریت بسته مثل pip پایتون، گزینه‌هایی از جمله index-url برای انجام این کار دارند. این ابزار، گزینه‌هایی مثل extra-index-url هم دارد که فقط یک اندیس به مخزن پیش فرض عمومی اضافه می‌کنند و نباید از آنها استفاده نمود.

مشکلی که وجود دارد این است که ابزارهای دیگری مثل JFrog Artifactory وجود دارد که از آنها برای مدیریت بسته ها استفاده می‌شود و امکان ترکیب مخازن خصوصی و عمومی در یک مخزن مجازی را فراهم کرده که همگی آنها تحت تأثیر رفتارهای مشابه قرار دارند. مایکروسافت که یک سرویس میزبانی بسته به نام “Azure Artifacts” دارد هم در واکنش به گزارش Birsan یک مقاله که مشتمل بر توصیه‌هایی برای مقابله با این مشکل است، منتشر کرد.

مایکروسافت در این گزارش نوشته که: «حتی با وجود این پیکربندی، اگر مخزن شما امکان رونویسی بسته‌های عمومی روی بسته‌های خصوصی را داشته باشد، کماکان احتمال وقوع حمله وجود دارد. شما یا باید مطمئن شوید که مخزنتان به‌ گونه‌ای پیکربندی شده که امکان انجام این کار وجود نداشته باشد و در فهرست‌های عمومی، نام بسته‌های خصوصی تان را ثبت کنید یا اینکه از یک روش مقابله ای دیگر استفاده نمایید».

روش بعدی، استفاده از فضای نام یا ویژگی محدوده (Scope) است که بعضی ابزارهای مدیریت بسته در اختیار شما قرار می‌دهند و در واقع پیشوندهایی هستند که متعلق به یک کاربر یا سازمان بوده و به همه بسته‌های آنها که در مخازن عمومی منتشر شده‌اند، اعمال می‌شوند.

در مستندات عمومی npm آمده است که: «محدوده‌ها راهی برای گروه‌بندی بسته‌های مرتبط به هم هستند که چند تأثیر در رفتار npm نسبت به بسته‌ها دارد. هر کاربر یا سازمانی در npm، محدوده خاص خودش را داشته و فقط می‌تواند به این محدوده بسته اضافه کند. پس دیگر نیازی نیست که نگران استفاده از یک نام بسته توسط شخص دیگری قبل از خودتان باشید. این روش برای مشخص کردن بسته‌های رسمی سازمان‌ها نیز مفید است».

در واقع اگر مثلاً پی‌پال، محدوده @paypal را در npm در اختیار داشته باشد و در تعریف همه وابستگی‌ها، علاوه بر نام بسته از نام محدوده هم استفاده کند بنابراین هیچ فردی قادر به درج بسته در فهرست npm عمومی پی‌پال نیست. شاید سازمان‌ها در محیط داخلی از چنین حوزه‌هایی استفاده کنند اما این روش برای ثبت بسته‌ها در مخازن کد منبع باز هم بسیار مفید است. مثلاً Birsan چندین بسته در npm متعلق به شرکت Atlassian نصب کرد چون این شرکت این محدوده را برای خودش ثبت نکرده بود.

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

از آنجا که این مشکل گسترده است و مقابله با آن نیاز به ایجاد تغییرات قابل توجه در پیکربندی ابزارهای توسعه، ابزارهای مدیریت بسته و جریان‌های کاری دارد، ممکن است مطلع شدن سازمان‌ها از این موضوع و پیاده سازی سازوکارهای دفاعی توسط آنها کاری زمان بر باشد. در طول 48 ساعت پس از انتشار گزارش Birsan، شرکت Sonatype که در زمینه خودکارسازی DevOps و حاکمیت کد منبع باز فعالیت دارد، بیش از 275 بسته جعل شده را پیدا کرد که توسط افراد مختلفی نوشته شده بودند و به نوعی حمله Birsan را اجرا کرده بودند.

زیست بوم بزرگ اجزای نرم‌افزاری کد منبع باز و وابستگی‌های پیچیده بین آنها باعث شده که توسعه دهندگان نرم‌افزار، یکی از اهداف هکرها باشند. بر اساس گزارش منتشر شده توسط GitHub در سال 2020، برنامه‌های کاربردی جاوا اسکریپت به طور میانگین، 10 وابستگی مستقیم دارند ولی از آنجا که این وابستگی‌ها هم خودشان وابستگی‌های دیگری داشته و این زنجیره کماکان ادامه دارد، این رقم در واقع به 683 عدد می‌رسد. همزمان، Sonatype در یک سال اخیر متوجه افزایش 430 درصدی حملات زنجیره تأمین با استفاده از فنون مختلف شده است.

منبع: csoonline