بسته‌های مخرب متن‌باز: رویکرد Xygeni

این چهارمین قسمت از مجموعه است سری پست ها درباره اجزای مخرب، که در آن ما ارائه می‌دهیم شیگنی رویکرد ما برای مقابله با این تهدید، به عنوان بخشی از پوشش ما برای Open Source Security

ما دیدیم که اعتماد بیش از حد به اجزای متن‌باز با منبع نامشخص، توسط انواع متخلفان مورد استفاده قرار می‌گیرد تا رفتارهای غیرمنتظره‌ای را ایجاد کنند که یا در دستگاه‌های توسعه‌دهندگان اجرا می‌شوند، CI/CD سیستم‌ها، یا در نرم‌افزار سازمان قربانی جاسازی شده است، بنابراین به مشتریان سازمان منتقل می‌شود. ما در ... تشریح کردیم. قسمت شماره ۳ حملاتی که از رجیستری‌های عمومی برای ارائه بدافزار استفاده می‌کنند و آنچه پس از مشاهده نحوه عملکرد بازیگران بد و در گذشته آموخته‌ایم قسمت شماره ۳ کنترل‌هایی که در برابر این تهدید کار می‌کنند (و آن‌هایی که شکست می‌خورند) مورد بررسی قرار گرفتند. 

حالا وقتشه که به رویکردمون در قبال این مشکل نگاهی بندازیم. در این قسمت، ما استراتژی‌ای که ما در Xygeni برای خودمون دنبال می‌کنیم رو ارائه می‌دیم. هشدار زودهنگام بدافزار سیستم (MEW). نحوه‌ی عملکرد این سیستم چند مرحله‌ای به صورت بلادرنگ هنگام انتشار نسخه‌ی جدید بسته، نحوه‌ی جمع‌آوری شواهد از منابع مختلف، نحوه‌ی اولویت‌بندی، معیارهای طبقه‌بندی مورد نظر ما و دلیل نیاز به تحلیل دستی برای تأیید ماهیت یک بسته‌ی مخرب. همچنین توضیح خواهیم داد که چگونه به NPM، GitHub، PyPI و سایر زیرساخت‌های کلیدی در اکوسیستم‌های متن‌باز کمک می‌کنیم تا زمان ماندگاری بدافزار را کاهش دهند. 

La pipeline

هشدار زودهنگام بدافزار Xygeni (MEW) به طور مداوم در حال پردازش کامپوننت‌ها، چه فایل‌های فشرده‌ی بسته برای کتابخانه‌ها و فریم‌ورک‌ها برای اکوسیستم‌های برنامه‌نویسی پشتیبانی‌شده مانند جاوااسکریپت/نود یا پایتون، چه تصاویر کانتینر Docker/OCI، یا افزونه‌ها و پلاگین‌ها برای ابزارهایی مانند IDEها یا CI/CD چنین مؤلفه‌هایی در فهرست‌های عمومی با سطوح مختلف بررسی کاربر منتشر می‌شوند.

در شکل زیر نحوه عملکرد این سیستم به صورت شماتیک نشان داده شده است:

La کاشف فرآیند، فید رویدادهای انتشار را دریافت می‌کند. یک رویداد انتشار، ایجاد نسخه جدیدی از یک مؤلفه جدید یا موجود است. از آنجایی که ثبت‌های رایج، مکانیسم انتشار-انتشار را برای مصرف‌کنندگان علاقه‌مند ارائه نمی‌دهند، این کار اغلب با نظرسنجی از ثبت برای رویدادهای اخیر انجام می‌شود. یک پروژه عالی از OSSF، بسته‌های تغذیه، حمایت کردن رجیستری‌های محبوبی مانند PyPI یا Maven Central، و یک رابط کاربری یکپارچه مبتنی بر فید ارائه می‌دهند. در MEW ما پیاده‌سازی‌های خاصی را اضافه کرده‌ایم که زمان انتظار را کاهش می‌دهد، به عنوان مثال با یک کپی از پایگاه داده CouchDB که توسط NPM استفاده می‌شود و با پایگاه داده رجیستری عمومی همگام‌سازی شده است.

در Xygeni، ما یک موجودی کالا داریم[1] از تمام اجزایی (مستقیم یا غیرمستقیم) که توسط نرم‌افزار مشتریان ما استفاده می‌شوند. مختصات اجزای مشتریان به طور منظم برای اولویت‌بندی تحلیل‌ها به MEW ارسال می‌شود: اجزایی که توسط مشتریان ما استفاده می‌شوند، زودتر پردازش می‌شوند. اولویت همچنین بر اساس اعتبار ناشر و میزان اهمیت مؤلفه است، بنابراین مؤلفه‌هایی که از ناشرانی با اعتبار پایین می‌آیند نیز در اولویت قرار می‌گیرند.

La تحلیلگرها سپس اجزای در حال انتظار در صف اولویت را مصرف می‌کند. هنگامی که یک نسخه از یک جزء برای تجزیه و تحلیل انتخاب می‌شود، فایل فشرده (tarball) آن از رجیستری دانلود می‌شود. توجه داشته باشید که جزء باینری بسته‌بندی شده تجزیه و تحلیل می‌شود: اکثر اجزای منبع باز معمولاً از یک مخزن منبع باز، اغلب در github.com، می‌آیند که فقط برای زمینه استفاده می‌شود و بدافزار همیشه در فایل فشرده جزء جستجو می‌شود زیرا عاملان تهدید به طور سیستماتیک در مورد منابعی که ادعا می‌کنند برای ساخت فایل فشرده جزء که منتشر می‌کنند استفاده کرده‌اند، دروغ می‌گویند. 

از دیدگاه کاربر

می‌شنوم که فکر می‌کنید: چطور می‌توانم از اطلاع زودهنگام از نسخه یک بسته مخرب بهره‌مند شوم؟ در این قسمت «آناتومی بسته‌های مخرب: روندها چیستند؟» دیدیم که کل زمان ماندگاری در محدوده روز است، در حالی که اولین اعلان از MEW به مشتریانی که از مؤلفه آسیب‌دیده استفاده می‌کنند در محدوده دقیقه است. با یک محافظ ساده[2] شما می‌توانید ساخت را مسدود کنید (دو سطح هشدار وجود دارد، یکی کاملاً خودکار، زمانی که موتور نتیجه می‌گیرد که بدافزار بالقوه‌ای وجود دارد و یک اعلان بعدی زمانی که تیم امنیتی ما با بازرسی دستی وجود بدافزار را تأیید می‌کند). انتظار تا زمانی که رجیستری، بدافزار را تأیید و آن را از رجیستری حذف کند، معمولاً به دلیل بازه زمانی طولانیِ در معرض قرار گرفتن، خیلی دیر است.

سازمان می‌تواند از یک محافظ استفاده کند که بررسی می‌کند آیا مؤلفه‌ای با بدافزار بالقوه (در هر یک از دو سطح هشدار) وجود دارد یا خیر، یا از طریق API، به سرعت متوجه شود که آیا هر یک از وابستگی‌های مستقیم یا غیرمستقیم در یک پروژه نرم‌افزاری از یک مؤلفه مخرب استفاده می‌کند یا خیر.

نحوه کار MEW: جزئیات داخلی

هسته: موتور تشخیص بدافزار

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

در Xygeni، ما یک تیم مهندسی با تجربه طولانی در تحلیل استاتیک داریم و این تفاوت اصلی با سایر راه‌حل‌های ضد بدافزار است. توجه داشته باشید که برای برخی از اکوسیستم‌ها، فایل فشرده بسته‌بندی شده شامل کد منبع (مثلاً کد جاوا اسکریپت یا TypeScript برای بسته‌های NPM، منابع پایتون برای بسته‌های PyPI) یا کد کامپایل شده‌ای است که به اندازه کافی به کد منبع برای تحلیل استاتیک نزدیک است (مثلاً بایت‌کد در فایل‌های JAR برای Maven). برای برخی دیگر، مانند تصاویر کانتینر، فایل‌های اجرایی باینری رایج هستند، بنابراین استنتاج قابلیت‌ها تکنیکی است که همراه با تشخیص بدافزار مرسوم بر اساس قوانین YARA و امضاهای بدافزار استفاده می‌شود. 

لطفاً توجه داشته باشید که فناوری‌های ساده‌ای مانند عبارات منظم یا امضاها برای تشخیص رفتار مخرب مناسب نیستند. تصور کنید که یک دراپر یا دانلودکننده را شناسایی می‌کنید: مقداری کد یا فایل باینری در بسته قرار دارد یا از یک دامنه خارجی دانلود شده است، که به مؤلفه مربوط نمی‌شود (می‌تواند یکی از ... باشد) فهرست بزرگی از دامنه‌های خریداری شده توسط عامل تهدید[4]، و یا یک دامنه قانونی برای جلوگیری از شناسایی). سپس آن کد با استفاده از یکی از توابع مربوط به آن اجرا می‌شود. کد می‌تواند طوری تغییر شکل یابد که URL دانلود یا تابعی که برای اجرای کد دانلود شده استفاده می‌شود را پنهان کند. برای تشخیص آن، تجزیه و تحلیل کامل جریان داده مورد نیاز است، با استفاده از تمام ابزارهای تجزیه و تحلیل ایستا، یا اجرای در محیط سندباکس (در صورت فراهم بودن شرایط لازم برای اجرای رفتار مخرب) که در حالت کلی می‌تواند این را تشخیص دهد.

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

افزودن زمینه

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

A امتیاز بدخواهی (MS) از یافته‌های آشکارسازهای اجرا شده، بر اساس قدرت شواهد به دست آمده محاسبه می‌شود. همه یافته‌ها یکسان نیستند و ترتیب اجرا نیز مرتبط است. 

اعتبار کاربر و مؤلفه

همه توسعه‌دهندگان متن‌باز یکسان خلق نشده‌اند! 

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

در MEW، ما یک سیستم جامع مدیریت اعتبار را پیاده‌سازی کرده‌ایم تا به رفتارهای مثبت پاداش دهیم و فعالیت‌های مشکوک را جریمه کنیم. این سیستم با کاربران جدید در یک موضع خنثی شروع می‌شود و اعتبار آنها را بر اساس فعالیت‌های مداومشان تنظیم می‌کند.

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

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

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

شواهدی مبنی بر رفتار مخرب پیدا شد. خب که چی؟ فرآیند بررسی دستی

طبقه‌بندی‌کننده‌ی فعلی، نسخه‌ی مؤلفه‌ی تحلیل‌شده را بر اساس آستانه‌هایی روی امتیازها که یافته‌ها و اعتبار کاربر/مؤلفه را خلاصه می‌کند، در یکی از دسته‌بندی‌های «تأییدشده‌ی مخرب»، «احتمالاً مخرب»، «پرخطر»، «کم‌خطر» یا «غیرمخرب» قرار می‌دهد. طبقه‌بندی به دسته‌بندی‌های «پرخطر» یا «احتمالاً مخرب» باعث بررسی دستی و اولین اعلان می‌شود. دسته‌بندی «تأییدشده‌ی مخرب» پس از بررسی دستی یا زمانی که شواهد با شواهد مشابه برای نسخه‌ی قبلی که مخرب بودن آن تأیید شده بود، مطابقت داشته باشد، تعیین می‌شود. 

وقتی شواهد کافی برای رفتار مخرب احتمالی وجود داشته باشد، یک هشدار اولیه (هشدار قرنطینه) به سازمان‌های آسیب‌دیده ارسال می‌شود. همانطور که قبلاً ذکر شد، این ممکن است نصب یا ساخت نرم‌افزاری را که به مؤلفه قرنطینه‌شده بستگی دارد، مسدود کند. 

این موضوع باعث ایجاد مشکل در بخش داخلی وزارت انرژی و آب می‌شود. dashboard بنابراین تحلیلگران امنیتی ممکن است فرآیند بررسی دستی را برای این مؤلفه آغاز کنند. این تیم ابزارهای تخصصی (جعبه شنی، ابزارهای رفع ابهام، توزیع برای تحقیقات بدافزار، ابزارهای گزارش بدافزار) را برای ارزیابی سریع ماهیت نسخه مؤلفه تحت بررسی در اختیار دارد. بیشتر بدافزارها ("آنچوی‌ها" یا مؤلفه‌های مخرب ساده) بررسی می‌شوند.  

نتیجه بررسی به این صورت است که یا امن، بنابراین موتور تحلیل خودکار یک مثبت کاذب پیدا کرده است که به عنوان بازخورد به طبقه‌بندی‌کننده یادگیری ماشین برای یادگیری الگو استفاده می‌شود؛ یا مخرب تأیید شدبنابراین، پس از فرآیند گزارش، مؤلفه با مسئولیت‌پذیری به عنوان مخرب در رجیستری عمومی افشا می‌شود. اعلان دوم به سازمان‌های آسیب‌دیده ارسال می‌شود که به نوبه خود ممکن است کامپوننت را از قرنطینه خارج کنید، یا قطعاً آن را از فرآیند ارتقاء نسخه یا فایروال کامپوننت مورد استفاده در رجیستری داخلی خود مسدود کنید.

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

گزارش به اداره ثبت

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

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

کار آینده

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

یکی دیگر از پیشرفت‌های مداوم، بهبود یافته است طبقه‌بندی‌کننده یادگیری ماشین. MEW از طبقه‌بندی‌های گذشته درس خواهد گرفت. بردار یافته‌ها از آشکارسازهای موتور، به علاوه امتیاز مخرب بودن و امتیاز شهرت مشتق شده برای هر دو مؤلفه و ناشر ("شواهد یافت شده") به عنوان ورودی به یک سیستم یادگیری ماشینی استفاده می‌شود که مدل طبقه‌بندی کننده را به‌روزرسانی می‌کند. متغیر خروجی به سادگی این است که آیا رجیستری تأیید کرده است که مؤلفه مخرب بوده است یا خیر. این با نام رمز "اوراکل" شناخته می‌شود و به پیش‌بینی بیشتر کمک خواهد کرد.cisتوصیف‌کننده‌ی e، طوری طراحی شده که سالم باشد (یادآوری بالا، یعنی اجزای مخرب را از دست ندهد) اما با مثبت کاذب کمتر (اجزای ایمن را به عنوان مخرب گزارش نکند). 

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

پشتیبانی از اکوسیستم‌های دیگر در دست توسعه است. فناوری‌ها و ابزارهای گسترده‌ای مانند PHP یا افزونه‌های Jenkins در نقشه راه قرار دارند.

ما همچنین در حال بررسی این موضوع هستیم که آیا می‌توان با استفاده از هوش مصنوعی به فرآیند بررسی دستی کمک کرد تا تجزیه و تحلیل چند مؤلفه مخرب پیچیده‌تر ساده‌تر شود. 

در قسمت بعدی و پایانی این مجموعه، «سوءاستفاده از متن‌باز: چه انتظاری از افراد شرور می‌توان داشت«ما بر جدیدترین روش‌هایی که دشمنان برای مخفیانه‌تر، دشوارتر کردن شناسایی، هدفمندتر کردن حملات برای صنایع خاص و سودآورتر کردن آنها به کار می‌برند، تمرکز خواهیم کرد. آیا حملات باج‌افزاری با استفاده از این ابزار انجام خواهد شد؟ افراد شرور چگونه از ابزارهای هوش مصنوعی برای ارائه بدافزارهای پیچیده‌تر استفاده می‌کنند؟ آیا پروژه‌های محبوب برتر در معرض خطر هستند؟ این مطلب برای این است که خوانندگان درکی از این مسابقه تسلیحاتی و آنچه در کوتاه‌مدت (نیمه دوم سال 2024) و میان‌مدت (2025) انتظار می‌رود، داشته باشند. 

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

بدافزارهای موجود در اجزای متن‌باز نباید مزایای عظیمی را که جامعه متن‌باز برای جامعه ما به ارمغان آورده است، مختل کنند.  

  • [1] اسکنر ما اجزای متن‌بازی را که توسط پروژه‌های نرم‌افزاری مورد تجزیه و تحلیل ارجاع داده شده‌اند، شناسایی می‌کند، بنابراین نمودار وابستگی کامل و به‌روز، حداقل برای پروژه‌هایی که به‌طور منظم اسکن می‌شوند، مشخص است. Xygeni OSS یک API را در معرض نمایش قرار می‌دهد که مشتریان ممکن است هنگام قرار دادن یک جزء مورد علاقه در لیست سفید، از جمله اطلاعات مربوط به آسیب‌پذیری‌ها و شواهد مخرب، از آن استفاده کنند.
  • [2]  اگر شرایطی مطابق با مسائل امنیتی شناسایی شود، ممکن است یک گاردریل (نرده محافظ) ساخت را مختل کند. یافته‌های امنیتی مانند یک آسیب‌پذیری بحرانی و قابل دسترسی یا استفاده از یک جزء قرنطینه شده می‌تواند به اندازه کافی جدی تلقی شود که ساخت نرم‌افزار آسیب‌دیده را مختل کند.
  • [3]تحلیلگران امنیتی ما در صورت لزوم، کامپوننت یا اسکریپت‌های نصب آن را در یک محیط سندباکس اجرا می‌کنند. با این حال، MEW تجزیه و تحلیل پویا انجام نمی‌دهد، در درجه اول به این دلیل که رفتار مخرب همیشه در حملات هدفمند انجام نمی‌شود و به دلیل منطق گریزی که عاملان تهدید برای فرار از تجزیه و تحلیل پویا استفاده می‌کنند. 
  • [4]  به این تکنیک، الگوریتم‌های تولید دامنه ثبت‌شده یا RDGA، نام داده شد و عوامل تهدید جدیدی مانند ... خرگوش رولور تا سقف ۱ میلیون دلار در ۵۰۰ هزار دامنه سرمایه‌گذاری کرد که نشان می‌دهد صنعت جرایم سایبری چقدر سودآور است. 

آناتومی بسته‌های مخرب: روندها چیستند؟

محافظت در برابر بسته‌های مخرب OSS: چه چیزهایی کار می‌کنند (چه چیزهایی کار نمی‌کنند)

ابزارهای-نرم‌افزاری-ترکیب-تحلیل-ترکیب-ابزارها
ریسک‌های نرم‌افزاری خود را اولویت‌بندی، اصلاح و ایمن‌سازی کنید
حساب کاربری رایگان خود را دریافت کنید.
بدون کارت اعتباری مورد نیاز است.

توسعه و تحویل نرم‌افزار خود را ایمن کنید

با مجموعه محصولات Xygeni