Това е първият епизод от поредица статии за най-разпространения вид атаки срещу веригата за доставки на софтуер: тези, които (злоупотребяват) с публичен регистър на софтуерни компоненти, предназначени за... проекти с отворен код да качват артефакти, които биха могли да бъдат споделяни с други потребители. Когато злонамерените лица публикуват злонамерен софтуер там, използвайки системния регистър като средство за разпространение на зловреден софтуер, имаме атака по веригата за доставки, когато организациите-жертви инсталират или стартират заразения софтуерен компонент.
За да опростим дискусията, ще говорим за софтуерни пакети:, компоненти в пакетна форма, произведени от трети страни. Това включва не само компоненти, използвани от мениджъри на пакети като NPM или Poetry, но и компоненти на операционната система включително библиотеки и изпълними двоични файлове, изображения на контейнери, и виртуални машини, или удължения на инструмента за инструменти за разработка, изграждане и внедряване. Виждали сме злонамерени пакети навсякъде. Киберпрестъпниците нямат нищо против: те са възхитени от алтернативите, предоставяни от съвременните софтуерни инфраструктури, и използват системния регистър и инструмента, който най-добре отговаря на техните намерения. Затова, моля, не забравяйте, че софтуерните пакети са съкращения за изображения на контейнери, двоични пакети, хранилища с отворен код и разширения или плъгини от всякакъв вид (IDE, CI/CD системи, инструменти за изграждане). Всички те редовно са подложени на атаки.
Сериалът ще има 5 епизода:
- Какъв е проблемът с пакетите с отворен код? Това е темата на тази публикация. Защо престъпници от всякакъв вид публикуват злонамерени пакети? Защо трябва да се притеснявам?
- Анатомия на злонамерените пакети: Какви са тенденциите? В този епизод се фокусираме върху заплахата, която наблюдаваме с нашата MEW система, ден след ден. С голям фонов шум, дължащ се на голям брой злонамерени пакети, използващи типосквотинг или объркване на зависимости, по-малък процент атаки са много по-коварни и представляват по-голям риск. Как се промени поведението на злонамерените лица по отношение на операционните системи в близкото минало? Какви са числата? Какви са използваните тактики, техники и процедури, както и наблюдаваните вредни действия?
- Защита срещу злонамерени пакети с отворен код: Какво (не) работиПовечето професионалисти, запознати със сигурността, имат идеи как да се справят с тази заплаха. Чували сме мениджъри по сигурността да казват без колебание, че SCA Инструментите вече ви казват кога дадена версия на пакета е злонамерен софтуер. Или че зависят от добре познати, високо оценени софтуерни компоненти, където всеки злонамерен софтуер би бил незабавно открит и премахнат. Те казват, че използват отворени второстепенни/корекции на версии за автоматично получаване на корекции на уязвимости и това е правилният, препоръчителен начин за намаляване на риска от зависимости с отворен код, следвайки принципа „корекция рано, корекция често“. В този епизод ще разгледаме защо тези идеи са погрешни и как подобни погрешни схващания допринасят за популярността на този механизъм за атака и за огромния риск, който организациите изпитват. Ще завършим с това, което работи и какви са усилията и ресурсите, които са необходими.
- Злонамерени пакети с отворен код: Подходът на XygeniВ този епизод представяме каква е стратегията, която следваме в Xygeni за нашата система за ранно предупреждение за зловреден софтуер (MEW). Как работи тази многоетапна система в реално време, когато се публикува нова версия на пакета, как се събират доказателства от различни източници, как се извършва триаж, какви критерии за класификация следваме и защо все още е необходим ръчен анализ, за да се потвърди естеството на кандидат-злонамерен пакет? Как обратната връзка от нашите вътрешни екипи и екипите по регистрация помага на системата да се учи от събраните минали доказателства, за да намали до минимум фалшивите положителни резултати. Ще обясним и как помагаме на NPM, GitHub, PyPI и други ключови инфраструктури в екосистемите с отворен код да намалят времето на задържане..
- Експлоатация с отворен код: Какво да очаквате от лошите момчетаСерията завършва с фокус върху най-новите действия, които противниците предприемат, за да направят атаките по-скрити, по-трудни за откриване, по-целенасочени срещу специфични индустрии и да извлекат повече полза от този клас атаки. Ще бъдат ли извършвани атаки с ransomware с помощта на това средство? Как злодеите използват инструменти с изкуствен интелект, за да доставят по-сложни злонамерени пакети? Застрашени ли са най-популярните проекти? Това е, за да даде на читателите представа за тази надпревара във въоръжаването и какво да очакват в краткосрочен (втората половина на 2024 г.) и средносрочен план (2025 г.). Ще научим как атаки като скорошната... XZ-Utils Задна вратичкаили атаката за препитание от земята срещу електрон-строител през март 2024 г. показват, че трябва да сме бдителни и да следим как се развиват противниците.
Нека започнем с първия епизод: Какво се случва със злонамерените пакети с отворен код?
Какъв е проблемът с пакетите с отворен код?
През последните години, нарушители от всякакъв вид използваха регистри за софтуер с отворен код, за да разпространяват злонамерено поведение. Тези дейности са толкова стари, колкото и отвореният код, но честотата им се увеличи драстично през последните три години.
Публикуване на злонамерени компоненти в публични регистри (атаки, базирани на зависимости) е асиметрична партизанска война, която злонамерените лица използват за разпространение на зловреден софтуер, възползвайки се от доверието, което организациите влагат в компоненти с отворен код, идващи от неизвестни разработчици (помнете зависимост xkcd комикс?). Тъй като се доверявате на пакетите и нямате нищо против да преглеждате ръчно съдържанието на пакета и неговите зависимости, тези атаки са изключително ефективни. А асиметрията идва, защото те могат да бъдат до голяма степен автоматизирани и злонамерените играчи не е необходимо да взаимодействат директно с жертвата. Те просто качват пакета в публичния регистър и го пускат.
Злонамерени пакети скочи 6 пъти през 2022 г.и продължи да расте с 2.5 пъти повече през 2023 г. Миналата година бяха наблюдавани колосалните 245 000 злонамерени пакета, цифра, която повече от два пъти надвишава общия брой от предишни години взети заедно. Това е експоненциален растеж! От премахването на пакети като потвърден зловреден софтуер в стотици през 2021 г. и в хиляди през 2022 г., видяхме много повече фонов „шум“ през 2023 г., с подобен темп и за тази година. И скрит в този фон, причинен от неопитни киберпрестъпници, следващи „пътя на най-малкото съпротивление“, малка част от нашумелите атаки достигнаха до заглавията дори в общите медии.
Защо това е проблем от такъв мащаб? Съществува излишък на доверие по цялата верига. Софтуерът с отворен код се разпространява заедно с изходния си код и се пуска под даден лиценз. Да, всеки може да провери изходния код; но кой го прави като цяло? Кой, след като провери дали софтуерът няма зловреден софтуер, го изгражда от изходните кодове? Кой, преди да предаде пакетирания компонент (известен също като пакет) надолу по веригата към мениджъра на пакети или инструмента за изграждане, гарантира, че пакетът не е заразен със зловреден софтуер и съответства на предполагаемия изходен код, от който би трябвало да произлиза?
Защо инфраструктурата позволява толкова лесни атаки?
Регистри на пакети са отворени, често изискващи минимална проверка на самоличността на издателя. „Всеки е добре дошъл да публикува своя софтуер тук!“ Летвата за нападателите е поставена ниско: те използват имейл адреси за еднократна употреба и акаунти в GitHubgithub за еднократна употреба, за да създадат стотици злонамерени пакети в кратки, подобни на фишинг, кампании. Само за целенасочените е необходима по-висока сложност: Видяхме дори създаването на надеждно хранилище за изходен код на GitHub с много звезди и commitот множество фалшиви сътрудници и други показатели за популярност и поддръжка. Получаване звездобройци и репутация от фалшиви приноси не е трудно за автоматизиране. Видяхме злоупотреби с отворени софтуерни инфраструктури от всякакъв вид, не само със зловреден софтуер, като например инцидент с протокола за чай.
Мениджърите на пакети са проектирани за лесна употреба, а не за сигурност.Те могат да изпълняват скриптове преди и след инсталиране (понякога е необходимо компилиране на оригинален код за библиотека). Също така, Мениджъри на пакети инсталират пакети от множество източници, а понякога по подразбиране се използва публична регистрация. Те не са проверявали за несъответствие между метаданните в заявката за публикуване и метаданните в самия пакет.
Зависимостите са вложени и образуват граф. В определени екосистеми като Node (JavaScript), дребнозърнестите зависимости се натрупват в стотици или хиляди. Едно е да имам строг контрол върху директните зависимости, декларирани от моите софтуерни проекти, но транзитивни зависимости са по-трудни за контролиране. Отвореният код следваше принципа „приятелите на моите приятели са мои приятели“. Братството е норма в дивия Далечен Изток! Заплашителните лица знаят това и дълбоко крият злонамереното поведение в неясни зависимости, които често са неизвестни. Такъв беше случаят с поток от събития инцидент, насочен към Портфейл за доплащане.
Ето как работеше софтуерът с отворен код от самото му създаване. Няма да се промени много. Някои регистри на пакети изискват в най-добрия случай двуфакторно удостоверяване и често само за най-популярните пакети. Някои регистри предоставят scopes, пространство от имена, собственост на проверена организация, но трагично други не го поддържат (PyPI) или го правят по избор (NPM). Интересно е да се отбележи, че дори един проста схема за скрининг (базирано на контрола на DNS или хранилището/организацията на GitHub, съответстващи на идентификатора на групата) и създаване Задължителни PGP подписи за всички артефакти с изключение на контролните суми премахва по-голямата част от „шума“, злонамерените пакети, подобни на типосквотинг, и ограничава голяма част от объркване в зависимосттаСложните атаки са възможни, но много по-трудни, като само няколко са подобни на com.github.codingandcoding:плъгин за компилиране на maven известен с Maven Central. И не всички регистри на Maven следват едни и същи практики!
Контролите за сигурност на мениджърите на пакети могат да натоварят, но не възпрепятстват атаките, базирани на зависимости. Проблемът с многофакторното удостоверяване е, че за автоматизация се генерират производни идентификационни данни, като например токени за достъп или APIapi ключове, за акаунти, които да се използват в APIapi извиквания, направени от автоматизирани скриптове, без да е необходим интерактивен потребител, предоставящ втори фактор. Многофакторното удостоверяване е добро за защита на потребителските акаунти от изтичане на пароли, но генерираните токени за достъп или APIapi ключове трябва да бъдат защитени, докато са активни, или техният собственик ще бъде представян от злонамерените лица. Голяма част от кампаниите за верига за доставки, базирани на пакети, започват с изтичане на ключ/токен. Само не забравяйте инциденти като... надгробна плоча, 3CX, и много други, където неинтерактивни идентификационни данни са били откраднати за първи път при предварително проникване за стартиране на атака срещу веригата за доставки.
Отговорът, даден на тази заплаха, не беше достатъчно силен. В третия епизод ще се съсредоточим върху това, което проработи и какво се провали с гръм и трясък. Индустрията трябва да работи колективно по standardпроцеси, обучение и инструменти за смекчаване на рисковете за глобалните вериги за доставки. Това не е проблем, който една организация може да реши сама.
За да завършим този раздел, ключовото недоразумение: говорим за злонамерен пакети, не уязвим такива. Уязвимостите идват от грешки в дизайна или кодирането, въведени случайно, без лоши намерения. Уязвимостите могат да бъдат използвани, но много от тях не са. Злонамерените пакети винаги са умишлени и има 100% възможност за употреба, ако бъдат изпълнени. Няма сравним риск! Следователно Парадоксално е да се види колко усилия се полагат за откриване и смекчаване на уязвимости, както и липсата на еквивалентни мерки за злонамерени компоненти..
„Ние приемаме сигурността сериозно“
Нека си представим обичайното Acme CorporationAcme, основен доставчик на WileCoyote.com, разполага с по-голямата част от софтуера си, идващ от трети страни, като над 80% е от проекти с отворен код. Те произвеждат софтуер за вътрешна употреба, но също така предоставят софтуер за своите партньори, доставчици и клиенти/крайни потребители. Acme има софтуер, написан на Go, JavaScript, Java, C# и Python, и изпълнява по-голямата част от софтуера си в облака, под Kuberneteskubernetes клъстери. Acme изгражда своите персонализирани образи от базови образи, взети от Docker Hub и други регистри. Те също така споделят няколко библиотеки, пакети и образи на контейнери в публични регистри.
Acme приема сигурността сериозно. Те са доста наясно с проблема... open source securityи риска, който това носи. Всички разработчици, системни мениджъри и DevOpsdevops инженери използват тези сладки малки крипто ключове като второфакторно удостоверяване. Всички commitподписването на хранилищата с код, защитата на клоновете е активирана със задължителни прегледи на кода, CI/CD заключени, тайни, съхранявани в секретно хранилище, и с вътрешен регистър, частично отразяващ външни регистри, където се съхраняват само разрешените компоненти от белия списък. Изисква се софтуерът, създаден от Acme, да приема зависимости от трети страни от този регистър.
Вероятно повечето организации се вписват в този профил. Скъпи читателю, вашата със сигурност се вписва, ако все още сте тук, нали?
Тогава един злополучен ден, важен frontend разработчик в Acme бягаше npm инсталиране на acme-cute-lib, забравяйки, че @acme/cute-lib беше правилната зависимост с определен обхват. Точната грешка не е важна, много неща могат да се объркат, дори когато човек поеме пълен контрол върху жизнения цикъл на софтуера. Нашият разработчик не знаеше, че APT група е насочена към Acme и публикува злонамерен компонент под това име, по хитър начин, така че злонамереното поведение се активира само когато софтуерът е инсталиран на Acme компютри. Пакетът не беше открит седмици след публикуването му.
Изпълнява се инсталационен скрипт, който търси идентификационни данни (в лаптопа на нашия разработчик имаше много juicy access tokens), позволяващи достъп до вътрешни софтуерни хранилища и гореспоменатото вътрешно хранилище, което, разбира се, е достъпно само чрез VPN. Злонамереният код успява да използва съществуващата VPN връзка и да публикува злонамерен компонент от втори етап във вътрешния регистър, засягайки обща библиотека с помощни програми, споделяна от по-голямата част от софтуера, доставян от Acme.
Седмици по-късно други организации, използващи публикуваните инструменти на Acme, започнаха да виждат странен трафик в мрежите си, използващ протокола на Acme, но насочен към хостове, наподобяващи домейна Acme. Трафикът беше криптиран, но инструментите за системно наблюдение откриха достъп до неочаквани файлове и изпълнение на процеси, които изглеждаха като системни команди, но в крайна сметка изпълняваха изтеглени изпълними файлове.
Останалото е история: Acme първоначално отрече, че подобно поведение е тяхно и че са взети всички мерки за сигурност. Едва след като медиите за киберсигурност започнаха да питат защо източникът на откритото поведение произхожда от компонентите на Acme, а анализът на сигурността показа колко са били залети от тези компоненти със скрит зловреден софтуер, Acme трябваше да разпознае инцидента и да се обади на фирма за реагиране при инциденти. Негативна маркетингова кампания, която подкопа трудно спечеленото доверие за секунда.Acme беше на една npm инсталация разстояние от disaster„“ беше често срещано заглавие. След това последваха съдебни дела и анулирани договори.
Виждате ли прилики с известни инциденти в миналото? Acme се сблъска с инцидент във веригата за доставки на два етапа, използвайки комбинация от... объркване/печатна грешка в зависимостта атаки, които използваха работна станция на разработчик като плацдарм за заразяване на компоненти, които се озоваха в софтуер, използван от трети страни. Как би могло това да бъде предотвратено или смекчено?
Защо отровните пакети са толкова популярни
Този хипотетичен инцидент показва, че дори с разумен подход към сигурността на отворения код, организациите се нуждаят от специфични мерки, за да избегнат да станат жертва на зловреден софтуер в компоненти с отворен код. Схематично, злонамереният субект може:
- Създайте нов пакет (следвайки добре познатите пътища за типосквотинг или объркване със зависимости, това е най-често използваният път от злонамерените);
- Опитайте се да заразите съществуващ такъв, като го инжектирате в изходния код, опитвайки се да го прикриете като сътрудник чрез pull requestили използване на социално инженерство, за да се превърне в поддържащ (както направи „Джао Тан“ в XZ Backdoor или дясно9Ctrl Потребителят на GitHub го направи в поток от събития инцидент през есента на 2018 г.) или чрез получаване на идентификационни данни за хранилище с отворен код и представяне за поддържащия го;
- Инжектирайте зловреден софтуер по време на компилирането на пакета, или чрез изпълнение на зловреден скрипт за компилиранеили намеса в изтеглянията на пакети чрез прихващания от типа „човек по средата“ (за щастие, TLS вече винаги се изисква в повечето регистри).
- Инжектирайте пакетирания компонент директно в системния регистър, обикновено чрез заснемане на идентификационните данни за регистъра (предпочитаната алтернатива за много сложни атаки като тази на Acme, където компрометираната работна станция на първия етап е имала вътрешен токен за достъп до системния регистър, например в обичайния .env or ~/.m2/settings.xml: злонамерените лица знаят къде да търсят тайни). Уязвимости в регистрите също бяха използвани.
Отравянето на регистри със зловреден софтуер е основата за атаки, основани на зависимости. Нищо ново под слънцето: разпространението му се увеличи драстично, но същите техники работят сега, както преди пет години.
Източник: Колекция от ножове на Backstabber.
Зловредният пакет може да работи по време на инсталиране, по време на изграждане на софтуер или по време на изпълнение. Поведението варира от извличане на информация, например извличане на секретни данни за втора фаза на опит, до извличане на изходен код, пускане на допълнителен зловреден софтуер. В следващия епизод ще анализираме злонамерените пакети и как се публикуват.
Допълнителна информация
Следващият епизод Анатомия на злонамерените пакети: Какви са тенденциите? Ще се съсредоточим върху реални случаи, които наблюдаваме с нашата система за ранно предупреждение за зловреден софтуер, ден след ден. Ще прегледаме кои видове зловреден софтуер са били наблюдавани и кои тактики, техники и процедури са предпочитани. Ще разгледаме обфускацията и как те се опитват да се скрият от потенциални проверяващи, техниките за избягване на откриване и как те се развиват с телеметрията и страничното движение. Моля, следете ни!
Източници
- Колекция от ножове на Backstabber: Преглед на атаките срещу веригата за доставки на софтуер с отворен кодМ. Ом и др., май 2020 г.
- Защита от злонамерен софтуер с отворен кодБяла книга от Xygeni.
- Software Supply Chain Security Ретроспекция: Оформяне на по-безопасна 2024 г.Доклад от Xygeni.
