نرم افزار منبع باز دنیا را خورده است، اما آشفتگی آسیب پذیری Log4Shell در ماه گذشته، خطرات بالقوه زمانی را که شرکت ها با آن احترامی که شایسته آن است رفتار نمی کنند، برجسته می کند.
خطر دو جانبه است. اول، زنجیره تامین نرم افزار پر از آسیب پذیری های شناخته شده است که شرکت ها آنها را اصلاح نمی کنند. و دوم، مهاجمان همچنین شروع به سوء استفاده از عدم توجه به امنیت پروژه نرم افزاری برای افزودن عمدی درهای پشتی و سایر اجزای مخرب کرده اند.
منبع باز همه جا هست و همگی آسیب پذیر است
بر اساس گزارش 2021 امنیت منبع باز و تجزیه و تحلیل ریسک Synopsys، 98 درصد از پروژه های نرم افزاری سازمانی، داخلی و تجاری، حاوی مقداری کد منبع باز هستند.
و این فقط قطعه کد یا کتابخانه گاه به گاه نبود. در این گزارش آمده است که برای یک برنامه متوسط، 75 درصد از پایگاه کد منبع باز بود.
نیکو ون سامرن، مدیر ارشد فناوری در Absolute Software گفت: «سرعت توسعه فناوری این روزها تنها به این دلیل امکان پذیر است که ما مقادیر زیادی نرم افزار منبع باز در اختیار داریم. “این به ما امکان می دهد محصولات بزرگتر و بهتری را بسیار سریعتر از زمانی که نیاز داشتیم هر خط کد را خودمان بنویسیم بسازیم.”
گزارش مشابهی که تابستان گذشته توسط Osterman Research و GrammaTech منتشر شد، نشان داد که 100٪ از برنامه های تجاری خارج از قفسه حاوی اجزای منبع باز هستند.
همانطور که استفاده از منبع باز افزایش می یابد، خطرات نیز افزایش می یابد.
به گفته Osterman، همه آن برنامه ها – همه 100٪ آنها – دارای اجزای منبع باز با آسیب پذیری های امنیتی بودند که 85٪ آنها حیاتی بودند.
کد منبع باز را می توان چندین لایه عمیق در یک برنامه کاربردی، در وابستگی یک وابستگی یک وابستگی، مدفون کرد. هنگامی که در یک بسته نرم افزاری اختصاصی تعبیه شده است، ممکن است شناسایی و وصله آن برای یک شرکت بسیار دشوار باشد.
در واقع، طبق گزارشی که روز دوشنبه توسط Sonatype منتشر شد، کتابخانه Log4j از 10 دسامبر، زمانی که آسیب‌پذیری Log4Shell کشف شد، بیش از 10 میلیون بار دانلود شده است. از این دانلودها، 40 درصد از نسخه های قدیمی تر و آسیب پذیر کد بودند.
حتی بدتر از آن، این درصد در طول ماه گذشته تغییر چندانی نکرده است. بین 10 تا 12 دسامبر، درصد دانلودهای آسیب پذیر از 100% قبل از در دسترس بودن وصله، به 50% کاهش یافت. تا 18 دسامبر، به 40 درصد کاهش یافت – و از آن زمان تاکنون تقریباً در همان سطح باقی مانده است.
تیم مکی، استراتژیست امنیتی اصلی در Synopsys گفت که وصله نرم‌افزار منبع باز در مقایسه با نرم‌افزارهای تجاری چالش بیشتری دارد.
او گفت: «فروشندگان نرم افزارهای تجاری می دانند مشتریانشان چه کسانی هستند. اما پروژه های منبع باز به ندرت انجام می دهند زیرا دانلودهای ناشناس اجازه اعلان های فشاری را نمی دهند.
این بدان معناست که این به خود شرکت ها بستگی دارد که از به روز رسانی ها و وصله های لازم مطلع شوند.
به گفته روی ایلسلی، تحلیلگر Omdia، چالش دیگر این است که موارد زیادی وجود دارد که در آن شرکت‌ها نمی‌خواهند وصله‌ها را به طور خودکار نصب کنند، بدون اینکه ابتدا آنها را آزمایش کنند.
او گفت: تعداد بسیار کمی از افراد کاملاً خودکار هستند. “چون آنها به آن اعتماد ندارند. آنها باید آزمایش را پشت سر بگذارند.”
او گفت که سیستم های قدیمی نیز یک چالش هستند. اگر نسخه‌های جدید نرم‌افزار از سخت‌افزار قدیمی‌تر پشتیبانی نمی‌کنند، شرکت نمی‌تواند بدون انجام یک تعمیر اساسی سیستم‌ها، به‌روزرسانی کند.
در نهایت، ممکن است یک شرکت نداند که کدی وجود دارد که باید وصله شود زیرا درون ابزارهای اختصاصی دفن شده است.
او گفت که مدیران امنیت سایبری مراکز داده باید از این فرصت استفاده کنند و از همه فروشندگان خود بخواهند که صورتحساب های نرم افزاری را ارائه دهند، اگرچه آنها بیشترین اهرم را در هنگام خرید اولیه یا در زمان تمدید قرارداد خواهند داشت. با این حال، بهترین فروشندگان قرار است توجه کنند و قدم بردارند.
او گفت: «تمام نظرسنجی‌هایی که انجام می‌دهیم، داده‌هایی که برمی‌گردند، یکی از چیزهایی که مشتریان برای آن ارزش قائل هستند اعتماد به شرکای خود است.
کلی روزومالسکی، معاون رئیس شرکت Booz Allen Hamilton توضیح داد که یک لایحه مواد نرم افزاری لیستی از تمام اجزای نرم افزار در یک محصول دیجیتالی است. اگر همه فروشندگان یکی را ارائه می کردند، پاسخگویی به چالش هایی مانند Log4Shell برای شرکت ها بسیار آسان تر بود.
او گفت: «فقدان SBOM منجر به این شد که بسیاری از سازمان‌ها در تلاش برای یافتن این آسیب‌پذیری در شبکه خود باشند. دانش مرکز داده.
ممکن است به زودی شاهد این اتفاق باشیم.
در ماه مه گذشته، پرزیدنت بایدن فرمان اجرایی صادر کرد که بر اساس آن از فروشندگانی که نرم‌افزاری را در اختیار دولت فدرال قرار می‌دهند، باید صورتحساب مواد نرم‌افزاری را صادر کند.
دو روز بعد، بنیاد محاسبات بومی Cloud یک مقاله سفید با بهترین روش‌ها منتشر کرد که به همه فروشندگان توصیه می‌کرد در صورت امکان یک SBOM با پیوندهای واضح و مستقیم به وابستگی‌ها ارائه کنند.
آسیب‌پذیری Log4Shell ممکن است آخرین ضربه شلواری باشد که صنعت نرم‌افزار به آن نیاز دارد.
پروژه های منبع باز یک هدف نرم هستند
دیوید ویلر، مدیر امنیت زنجیره تامین منبع باز در بنیاد لینوکس، می گوید: “حمله کنندگان برای حمله مستقیم به بسیاری از سیستم ها سخت تر می یابند، بنابراین آنها شروع به تغییر به یک هدف نرم تر کرده اند: زنجیره های تامین نرم افزار.”
بر اساس گزارش زنجیره تامین نرم افزار سوناتایپ که در ماه سپتامبر منتشر شد، حملات به زنجیره تامین نرم افزار منبع باز در سال گذشته 650 درصد نسبت به سال 2020 افزایش یافته است.
مهاجمان پروژه های مخرب را با نام های مشابه با پروژه های قانونی، فقط در مخازن مختلف نام گذاری می کنند. یا مواردی ایجاد کنید که از رایج ترین اشتباهات تایپی آن نام ها استفاده می کنند.
مهاجمان همچنین می‌توانند اعتبار یک توسعه‌دهنده را بدزدند و کدهای مخرب را به نام آنها ارسال کنند – یا به یک پروژه منبع باز بپیوندند و خودشان کدهای مخرب ارسال کنند.
ویلر گفت، بسیاری از پروژه های منبع باز توسعه دهندگان کمی دارند و تزریق کد مخرب از دست می رود.
او پیشنهاد کرد که شرکت‌ها اقداماتی را انجام دهند تا اطمینان حاصل شود که کتابخانه‌های نرم‌افزار متن‌بازی که استفاده می‌کنند از مخازن درستی هستند و به درستی املا می‌شوند. شرکت‌ها همچنین می‌توانند از فروشندگان خود یک صورتحساب نرم‌افزاری مطالبه کنند تا فهرستی از تمام کدهای منبع باز موجود در محیط خود داشته باشند – و همچنین این فهرست‌ها را برای بسته‌های تایپی اسکوات بررسی کنند.
او گفت: “یک چالش بزرگتر تزریق کد مخرب است.” امروزه در مقایسه با برخی دیگر، این نوع حمله کمتر رایج است، اما مهم است.»
او پیشنهاد کرد که اگر قطعه خاصی از نرم افزار منبع باز برای یک شرکت مهم است، آنها به طور فعال در آن پروژه شرکت کنند – یا حداقل به دنبال پروژه هایی باشید که چندین نگهدارنده و فرآیندهای بررسی کد چند نفره دارند.
او پیشنهاد کرد: «در درازمدت، در بنیاد امنیت منبع باز مشارکت کنید. “این کنسرسیومی متشکل از بسیاری از سازمان‌ها است که روی راه‌حل‌های سیستمی کار می‌کنند. به عنوان مثال، OpenSSF پروژه‌ای را برای توزیع توکن‌های احراز هویت چند عاملی بین برخی از توسعه‌دهندگان OSS آغاز می‌کند، به طوری که رمز عبور دزدیده شده به راحتی منجر به ارسال بسته‌های مخرب مخرب در نام آنها.”
او گفت که OpenSSF همچنین اقدامات امنیتی خوبی را تشویق می کند، مانند بررسی چند نفره، و در حال بررسی راه هایی برای شناسایی مستقیم تایپوسکوت و کدهای مخرب است.
برای تأکید بر این که وقتی یک پروژه متن‌باز حیاتی توسعه‌دهنده‌های کمی دارد، چقدر خطرناک است، نگهدارنده داوطلب کتابخانه‌های محبوب colors.js و faker.js، Marak Squires، عمداً کد را به عنوان اعتراض خراب کرد و یک “حلقه بی‌نهایت” اضافه کرد. که باعث از کار افتادن هزاران پروژه نرم افزاری دیگر شد.
طبق گزارش Sonatype، color.js 3.3 میلیون بار دانلود شده و بیش از 19000 پروژه نرم افزاری دیگر به آن وابسته است و faker.js نیز 272 میلیون بار دانلود شده و در 2500 پروژه دیگر استفاده شده است.
کارشناسان می گویند زمان آن فرا رسیده است که شرکت ها گام بردارند و به جامعه منبع باز کمک کنند.
دان پترو، محقق ارشد در بیشاپ فاکس، یک شرکت تست امنیتی، گفت: “شرکت ها نباید مشارکت های منبع باز را به عنوان خیریه ببینند، زیرا اینطور نیست.” این به همان اندازه که توسعه معمولی برای امنیت است.”
او گفت که شرکت ها باید به کار منبع باز خود، مانند ممیزی های امنیتی پروژه های منبع باز، به عنوان کارهایی که از روی خیر و صلاح قلب خود انجام می دهند، فکر نکنند.
شرکت‌ها باید روی فناوری‌ای که خودشان استفاده می‌کنند سرمایه‌گذاری کنند و آن را به‌عنوان ممیزی وضعیت امنیتی خود ببینند. برای مثال، یک شرکت رسانه‌ای ممکن است برای انجام کارهای حیاتی تجاری بر روی یک کتابخانه پردازش ویدیوی منبع باز خاص تکیه کند. پیدا کردن و رفع آسیب‌پذیری‌ها در آن کتابخانه فقط حس تجاری خوبی دارد.»
کیسی الیس، موسس و مدیر ارشد فناوری در Bugcrowd، در سانفرانسیسکو، گفت: اگر تعداد کمی از افراد بخواهند نرم‌افزار متن‌باز را ممیزی و آزمایش کنند، حتی تعداد کمتری هم می‌خواهد واقعاً دست‌های خود را کثیف کند و به نگهبان‌های عمدتاً بدون دستمزد در تعمیر و آزمایش رگرسیون نرم‌افزار آسیب‌پذیر کمک کنند. شرکت امنیت سایبری جمع سپاری مستقر در کالیفرنیا.
با توجه به تمرکز Log4Shell بر روی این مشکل، حتی FTC نیز در نظر دارد وارد عمل شود.
این آژانس در بیانیه‌ای که هفته گذشته منتشر کرد، گفت: «آسیب‌پذیری Log4j بخشی از مجموعه گسترده‌تری از مسائل ساختاری است. “این یکی از هزاران سرویس منبع باز ناشناخته اما بسیار مهم است که در بسیاری از شرکت‌های اینترنتی استفاده می‌شود. این پروژه‌ها اغلب توسط داوطلبانی ایجاد و نگهداری می‌شوند که همیشه منابع و پرسنل کافی برای حوادث را ندارند. پاسخ و نگهداری پیشگیرانه حتی با وجود اینکه پروژه های آنها برای اقتصاد اینترنت حیاتی هستند. این پویایی کلی چیزی است که FTC در هنگام کار برای رسیدگی به مسائل ریشه ای که امنیت کاربر را به خطر می اندازد در نظر خواهد گرفت.”