В предишния епизод, Злонамерени пакети с отворен код: Проблемът, обсъдихме защо заплашителните участници бяха толкова ентусиазирани от публикуването на нови злонамерени компоненти или инжектирането на зловреден софтуер в най-новите версии на съществуващи компоненти: Инфраструктурата с отворен код позволява на всеки, където и да е, да създаде ефимерен акаунт в регистър на компоненти (като NPM, PyPI, Docker Hub или Visual Studio Marketplace) или платформа за съвместна разработка (като GitHub). Нулева цена и много възможности за използване на излишното доверие, което софтуерните екипи традиционно имат към компонентите на трети страни.
Асиметрията между това колко лесно е за атакуващите да разпространяват зловреден софтуер, използвайки инфраструктурата, достъпна за отворен код, и колко е трудно за организациите, разработващи софтуер (всички ли?), да избегнат заразяване със зловреден софтуер (и да доставят зловреден софтуер в софтуера, който разпространяват за други), доведе до почти достигане на четвърт милион злонамерени пакети миналата година.
Това е проблем от такъв мащаб, че никоя организация не може да го реши сама, а общността е в процес на преосмисляне на процеса на отворен код по отношение на доверието, принципите за сигурност по подразбиране и сигурност по дизайн, както и жизнения цикъл на компонентите. Ще разгледаме тези идеи в следващия епизод. Защита срещу злонамерени пакети с отворен код: Какво (не) работи.
Не забравяйте, че говорим за софтуерни компоненти, които в повечето случаи съответстват на софтуерни пакети: компоненти за многократна употреба, опаковани така, че да могат да бъдат използвани като зависимост в софтуерен манифест и инсталирани с мениджър на пакети или инструмент за изграждане. Моля, обърнете внимание, че този случай може да бъде разширен, за да включва публични изображения на контейнери (използван от среди за изпълнение на контейнери и платформи за оркестрация като Kubernetes) и разширения на софтуерни инструменти (за изграждане, автоматизация и внедряване).
Тук анализираме как това тактика на атака, базирана на злонамерени компоненти работи, според минали примери и това, което сме виждали в нашата платформа за ранно предупреждение за злонамерен софтуер (MEW). Ще анализираме злонамерените компоненти в различни измерения:
(1) избраният начин за разпространение (използван регистър, в нов или съществуващ компонент и техниката, използвана за заразяване на публикуваната версия на компонента), (2) как се активира или задейства зловредният софтуер, (3) злонамереното поведение, т.е. какви вредни действия се наблюдават и каква е мотивацията на нападателя, (4) кои техники са често срещани за обфускация, скриване, за да остане незабелязан, странично движение, комуникация с хостове за командване и контрол (C2) и др.; и (5) техниките за спечелване на достатъчна популярност и доверие, така че жертвите в крайна сметка да инсталират компонента.
Избраният механизъм за разпределение
Наблюдаваме едно „фонов шум„на несложни злонамерени пакети, използващи типосквотинг, за да фишират невнимателни разработчици с печатна грешка в името на пакета за тяхната зависимост. Много популярни пакети получават порой от пакети с подобни имена и печатни грешки, с очакването, че ще фишират някои невнимателни разработчици.
Те използват ефимерен акаунт, публикуват група от typosquat пакети, създават друг и публикуват още една група... Използвайки известна автоматизация и изобретателност, те могат да постигнат известна сложност, но обикновено са доста тривиални. Вътрешно ги наричаме „аншоа„Кражбата на идентификационни данни е основната цел, но понякога откриваме шпионски софтуер, който извлича изходен код или чувствителни данни, като лична информация (PII), заснемане на клипборда и други опасения.“
Изневиделица виждаме по-сложни злонамерени компоненти, „акулите“. Малцинство от тях са насочени към конкретни групи или организации, обикновено с крипто дрейнери или уеб скимъри, които се активират условно, вероятно следвайки подхода, наблюдаван в инцидент със поток от събития на декриптиране на полезния товар на атаката само когато пакетът е препратен от целеви пакет.
Механизмът на разпределение беше анализиран в отличната и вече класическа статия „Колекция от ножове на Backstabber: Преглед на атаките срещу веригата за доставки на софтуер с отворен код„, което е задължително четиво. Със сигурност сте виждали тази хубава диаграма преди:
Бяха проучени всички възможности, включително нови и съществуващи пакети; засягане на изходния код, системата за изграждане или самия пакетиран компонент; използване на откраднати идентификационни данни или социално инженерство; отвличане на изоставени акаунти и хранилища или отравяне на поддържани такива. Някои атаки получиха имена (Типоскват, Объркване в зависимостта, Явно объркване, Кражба на репо-сделки... и т.н.) и вече бяха обсъдени другаде.
А какво ще кажете за избраните регистри?
NPM продължава да води по общ брой злонамерени пакети, но тази година наблюдаваме скок в PyPI. Python е популярна екосистема за наука за данни и машинно обучение. Всъщност, плътността на злонамерения софтуер вече е по-висока в PyPI, отколкото в NPM.
Как се задейства зловредният софтуер
Злонамерени пакети се задействат по време на инсталиране само в 4 от 10 случая (през последните години това беше близо 6 от 10). Останалите изпълняват злонамерено поведение по време на изпълнение, като 1 от 100 се задейства по време на тестове. Изглежда, че злонамерените пакети знаят, че неконтролираното изпълнение на инсталационни скриптове е било деактивирано на много места.
Какво получават лошите?
Ще изброим категориите злонамерено поведение, като най-популярните са на първо място. Моля, обърнете внимание, че въздействието може да бъде доста различно: a ексцентрик е упорито разрушително, но не е често срещано и е наблюдавано само в няколко случая, свързани с целенасочени кибервойнствени кампании или брутален хактивизъм. Следните категории са доста често срещани:
- InfoStealer / Източване на идентификационни данниНай-честите, над 90% от несложните атаки, са прости атаки, търсещи главно идентификационни данни като пароли, токени за достъп, API ключове и частни ключове (за SSH и други подобни). Вероятно е най-лесният за писане (заедно с wiper-ите?). Те изброяват известни файлове/директории и други източници (напр. ключове в системния регистър), пакетират съдържанието и изпращат тези данни до C2 сървър. Идеята е проста: „Публикувам атака за кражба на фишинг идентификационни данни, за да мога по-късно да използвам тези данни за стартиране на насочена атака“.
Наблюдаваната C2 мрежа обикновено е евтина и мръсна, като например Telegram каналите или инструменти за тунелиране, подобни на ngrok (често под формата на обратни прокси сървъри, изложени чрез изходящи VPN IP адреси). Има стотици (!) възможности, като много GitHub проекти са под тема за кражба на паролиСпециализации като кейлогъри са рядкост за злонамерени пакети и изображения на контейнери, но са по-чести в разширения на инструменти, където се очаква взаимодействие с потребителя.
- Дропър / ИзтеглятелВторият по популярност, обикновено на първо място при многоетапни атаки. Повече от един на всеки трима злонамерени компоненти имат дропери (ако злонамереният полезен товар е включен в пакета) или програми за изтегляне (полезният товар се изтегля от крайна точка под контрола на атакуващия). Полезният товар често е известен двоичен вариант на зловреден софтуер и се изпълнява, а понякога и съхранява, за инсталиране на задни врати, шпионски софтуер, програми за източване на криптовалути и други случаи на употреба. Изтегленият или разположен полезен товар започва атака от втора фаза с цялата мощ, предоставена от съществуващите двоични файлове на зловреден софтуер. Двоичните файлове могат да бъдат разпространявани в рамките на пакета, често маскирани като изображения или уж безобидни файлови типове, за да се избегне откриване при свързване с неочаквани сайтове.
- Крадци / Миньори на криптовалутиФинансово мотивираните противници са склонни да използват вашите облачни активи за стартиране на крипто майнери (те дори откриват дали те работят в облачна виртуална машина). Те не се интересуват от... ниско съотношение на печалба от $1 за всеки $53, начислени на жертвата за открадната облачна инфраструктура. Жертвите може да не са наясно с това, докато не получат неочаквана сметка. За щастие, това идва и си отива. Cryptojacking Кампании в злонамерени пакети понякога се появяват и след това изчезват, фишинг за потребители на портфейли или в крайна сметка насочени към доставчика на портфейла, както в Атака върху Леджър.
Други поведения, като например внедряване на задна врата за дистанционно изпълнение на код чрез отваряне на обратна обвивка е по-рядко срещано сега, отколкото в миналото. Например, 123rf_contributor_web пакетът (вече премахнат от системния регистър) се отваря без никакво обфускация, като обратна обвивка, копирана и поставена от Шпаргалка за обратна черупка:
В допълнение към легитимните и злонамерените компоненти, наблюдавахме няколко злоупотреби, включително:
Спам пакети
Има хиляди малки пакети, предимно в NPM, без зловреден софтуер, но обещаващи лесни печалби, „змийско масло“, връзки към предложения за Виагра и всичко останало. Няколко потребители публикуват такъв спам и отнемат много трафик от регистъра. Друг(и) участник(и), вероятно от Индонезия, се е опитал(и) да извлече полза чрез злоупотреба с чаяРанг предназначено за компенсиране на разработчици с отворен код, чрез създаване на десетки хиляди взаимосвързани NPM пакети със свързани фиктивни хранилища на GitHub. Това е явно нарушение на условията за ползване.
Измами с награди за грешки и изследвания за сигурност
Когато даден пакет се описва като извличащ данни за добри цели, като например откриване на пропуски в сигурността за програми за откриване на грешки или изследване на определени аспекти на екосистемата. Виждали сме хиляди пакети в тази категория, които извличат идентификационни, но не твърде чувствителни данни, към адрес на Burp Collaborator от PortSwigger (напр. хост в домейна oastify.com). Често наблюдавахме имитации на... Объркване в зависимостта доказателство за концепцията от Алекс Бирсан, подобно на aurora-webmail-pro пакет (премахнат от системния регистър), който просто изпълнява този гаден код в скрипта за предварителна инсталация:
И също така включваше „Това е проста атака за объркване на зависимости, доказателство за концепция„описание на отказ от отговорност в package.jsonТова е явно нарушение на условията за ползване, дори без злонамерено намерение.
Добри новини? Все още не сме виждали рансъмуер атаки, извършвани чрез злонамерени компоненти. По неизвестни причини киберпрестъпниците изглежда предпочитат по-традиционните механизми за фишинг на имейли, базирани на RDP и drive-by механизми за изтегляне.
Допълнителни наблюдавани техники
Много техники бяха използвани за упорство, избягване на защитата, събиране на информация, комуникация с командни и контролни хостове и ексфилтрация.
Постоянство в злонамерени компоненти се постига с помощта на функциите за постоянство в двоичен зловреден софтуер от втори етап, но понякога поведението се локализира в кода на пакета, като най-често срещаните са планирани задачи и промени в системния регистър на Windows.
еквилибристика е често срещано, но несложно. Повечето пакети с типосквотинг (помнете „аншоа„?) изобщо не използват обфускация; много от тях използват или тривиални (base64/hex кодиране или заместващи шифри като rot13), или използват налични обфускатори на код и минификация, което лесно се обръща с правилните инструменти. Само „акулите“ правят истинска, хардкор обфускация, трудна за обратно инженерство.
Обфускацията може да скрие атаката, но защо кодът в компонент с отворен код трябва да бъде обфускиран? Има ли доказателства, че нещо трябва да бъде скрито от обикновения поглед? Открихме много случаи на незлонамерени пакети, които използват обфускация, за да защитят интелектуалната собственост, което противоречи на „отворения код“. Обфускацията може да се използва като доказателство за злонамерен софтуер, но не е убедителна. Също така е трудно да се де-обфускира.
Избягване от защитните контроли използва прости техники. Злонамереният код често е защитен в опитай ... хвани блокове, които игнорират всякакви изключения, така че необичайна активност не се показва в лог файловете. Проверката на средата (работеща във виртуална машина или контейнер) е рядкост, освен за злонамерен софтуер, насочен към определена организация или среда.
Маскирането на двоични файлове в изображения и PDF файлове (вид стеганография) беше друга техника, използвана за избягване на откриване.
Тъй като най-често срещаните злонамерени компоненти са крадците на информация, събиране на данни е от съществено значение. Тайните данни (пароли, токени за достъп, API ключове, криптографски ключове) рутинно се сканират в лог файлове, променливи на средата и дори в клипборда (наблюдавано при банкови троянци и крипто крадци). Изтичането на изходен код също е често срещано, тъй като инсталирането на пакета често се извършва в развойна среда, където вътрешни git хранилища могат да бъдат клонирани. Виждали сме пакети, които изброяват директории в търсене на git хранилища. Търсенето на местоположения като .env, private.pem, settings.py, app.js или application.properties е доста често срещано.
Извличането на данни е друго широко разпространено действие. Само малка част от злонамерените пакети дори се опитват да скрият местоназначението на извлечените данни. Telegram канали и тунели, подобни на нгрок често се използват. И има много обикновено домейни в белия списък, използвани за ексфилтрация.
Други техники, като ескалация на привилегиите или странично движение, бяха по-рядко срещани.
Придобиване на популярност и доверие
Представете си технологичен мошеник с готово злонамерено нещо, който се чуди: „Как да направя това лайно достоверно за тези нищо неподозиращи идиоти?“.
Това се превежда в това как да се направи записът за злонамерения компонент, който да показва много звезди / разклонения (за популярност), плюс версии / проблеми и pull requests (за активност). Идеята е да се спечели фиктивна популярност (звезди) и зависими лица, както и убедителен вид по отношение на релевантност и поддръжка.
Регистърът не проверява дали съдържанието в проект в GitHub и съдържанието на пакета съвпадатТова е добре познат проблем във веригата за доставки на софтуер. Публичните регистри са гигантски провали, които поглъщат всичко, което им бъде хвърлено. Можете да свържете всяко хранилище.
Ако злонамереният пакет е с печатна грешка, това е лесно: просто посочете съществуващото хранилище на GitHub в манифеста на зависимостите, използван за създаването на пакета и публикуването му в системния регистър. За нови пакети във фалшиво хранилище на GitHub може да ви е необходима повече изобретателност, може би създаване на фалшиви... наблюдение на звезди/разклоняване GitHub акаунти чрез скриптове.
И ако съдържанието на вашия пакет е сравнително подобно на хранилището, добавете няколко добре проектирани промени тук-там… Можете да инжектирате вашия зловреден софтуер в нов пакет, наподобяващ популярен, като препращате към хранилището на съществуващия пакет, и да изчакате печатните грешки. Ако някой се осмели да сравни съдържанието на tarball-а на пакета със съдържанието от хранилището на GitHub, разликите в точките на инжектиране на зловреден софтуер биха могли лесно да бъдат пропуснати. Виждали сме този подход много пъти преди.
Механизъм, чрез който компонент да прави защитено от неправилно използване твърдение относно произхода, как е изграден пакетът, от какви източници и от кого, би бил добре дошъл. Но това е друга история.
Злонамерен ли е компонент X?
Има ли (изчерпателна) база данни за злонамерени пакети? Не. Уязвимостите с отворен код имат присвоен CVE ID, но само няколко злонамерени пакета (особено тези, които попадат в заглавията на новините) получават такъв. CWE за злонамерени пакети е CWE-506 (вграден зловреден код).
Обичайните инструменти за борба със зловредния софтуер (VirusTotal, MalwareBazaar, SOREL-20M…) не предвиждат специфични мерки за злонамерени компоненти. Това би било добре дошло!
Има примерни бази данни и набори от данни за анализ (ние използваме няколко от тях), но записите се актуализират само когато злонамереният пакет е известен, което често е твърде късно. Ако се интересувате, OpenSSF Злонамерени пакети е хубаво начало.
В следващата публикация ще обсъдим как да разберем дали даден пакет е злонамерен. Спойлер: да, има начини за проверка за злонамерени компоненти в началото на периода на експозиция, преди системният регистър да премахне известен злонамерен компонент.
Допълнителна информация
В следващия епизод „Защита срещу злонамерени пакети с отворен код: Какво (не) работи" Ще обсъдим какво трябва и какво не трябва да се прави по отношение на сигурността на отворения код. Повечето професионалисти, запознати със сигурността, имат интуиция как да се справят с тази заплаха, но изобилстват и погрешни схващания.
Ще разгледаме защо тези идеи са погрешни и как подобни погрешни схващания допринасят за популярността на този механизъм за атака и за огромния риск, пред който са изправени организациите. След това ще продължим с това, което работи и какви усилия и ресурси са необходими за това.
Също така ще публикуваме за еволюцията на злонамерените пакети по отношение на тяхното намерение, механизма на инжектиране и техниките за атака.
Остани настроен!
