Во претходната епизода, Злонамерни пакети со отворен код: Проблемот, дискутиравме зошто актерите на заканата беа толку ентузијастички расположени за објавување нови малициозни компоненти или инјектирање на малициозен софтвер во најновите верзии на постоечките компоненти: Инфраструктурата со отворен код му овозможува на секого, насекаде, да креира ефемерна сметка во регистар на компоненти (како NPM, PyPI, Docker Hub или Visual Studio Marketplace) или платформа за колаборативен развој (како GitHub). Нула трошоци и многу можности за искористување на вишокот доверба што софтверските тимови традиционално ја имаат врз компонентите од трети страни.
Асиметријата помеѓу тоа колку лесно е напаѓачите да дистрибуираат малициозен софтвер користејќи ја инфраструктурата достапна за отворен код и колку е тешко за организациите што развиваат софтвер (сите?) да избегнат инфицирање со малициозен софтвер (и да испорачаат малициозен софтвер во софтверот што го дистрибуираат за други), доведе до речиси достигната граница од четврт милион малициозни пакети минатата година.
Ова е проблем од таков обем што ниедна организација не може да го реши, а заедницата е во процес на преосмислување на процесот на отворен код во однос на довербата, принципите „безбедно по дифолт“ и „безбедно по дизајн“ и животниот циклус на компонентите. Ќе ги разгледаме ваквите идеи во следната епизода. Заштита од малициозни пакети со отворен код: Што (не) функционира.
Запомнете дека зборуваме за софтверски компоненти кои најчесто одговараат на софтверски пакети: компоненти за повеќекратна употреба спакувани за да можат да се референцираат како зависност во софтверски манифест и инсталирани со менаџер на пакети или алатка за градење. Забележете дека овој случај може да се прошири за да вклучи јавни слики од контејнери (се користи од страна на извршување на контејнери и платформи за оркестрација како Kubernetes), и проширувања на софтверски алатки (за градење, автоматизација и распоредување).
Тука анализираме како ова тактика на напад базирана на малициозни компоненти функционира, според минатите примери и она што го видовме во нашата платформа за рано предупредување за малициозен софтвер (MEW). Ќе ги анализираме малициозните компоненти во различни димензии:
(1) избраниот начин за дистрибуција (регистар што се користи, во нова или постоечка компонента и техниката што се користи за инфицирање на објавената верзија на компонентата), (2) како се активира или активира малициозниот софтвер, (3) злонамерното однесување, т.е. какви штетни дејства се забележани и која е мотивацијата на напаѓачот, (4) кои техники се вообичаени за замаглување, криење за да не се забележи, странично движење, комуникација со хостови за команда и контрола (C2) итн.; и (5) техниките за стекнување доволно популарност и доверба за жртвите да ја инсталираат компонентата.
Избраниот механизам за дистрибуција
Забележуваме едно „бучава во позадина„од несофистицирани злонамерни пакети кои користат typosquatting за да ги измамат невнимателните програмери со печатна грешка во името на пакетот за нивната зависност. Многу популарни пакети добиваат бараж од слично именувани пакети со печатни грешки, со очекување дека ќе измамат некои невнимателни програмери.“
Тие користат ефемерна сметка, објавуваат група пакети typosquat, креираат друга и објавуваат друга група… Користејќи одредена автоматизација и генијалност, тие можат да добијат одредена софистицираност, но обично се прилично тривијални. Ние внатрешно ги нарекуваме „аншопови„Крадењето на акредитиви е главната цел, но повремено наоѓаме шпионски софтвер кој го краде изворниот код или чувствителните податоци како што се лични информации (PII), снимање на таблата со исечоци и други сомнежи.“
Одеднаш, гледаме пософистицирани малициозни компоненти, „ајкулите“. Малцинство се насочени кон одредени групи или организации, обично со крипто дрејнери или веб-скимери кои се активираат условно, можеби следејќи го пристапот што се гледа во инцидент на настан-тек за дешифрирање на товарот на нападот само кога пакетот е референциран од целниот пакет.
Механизмот на дистрибуција беше анализиран во одличниот, а сега класичен труд, „Колекција ножеви „Backstabber’s Knife“: Преглед на нападите врз синџирот на снабдување со софтвер со отворен код„, што е задолжително читање. Сигурно сте ја виделе оваа убава табела и претходно:
Беа истражени сите можности, вклучувајќи нови и постоечки пакети; влијание врз изворниот код, системот за градење или самата спакувана компонента; користење украдени акредитиви или социјален инженеринг; киднапирање на напуштени сметки и складишта или труење на одржувани. Некои напади добија имиња (Тајкуирање, Конфузија од зависност, Манифестна конфузија, Репо-џекинг. итн.) и веќе беа дискутирани на друго место.
А што е со избраните регистри?
NPM продолжува да води во вкупниот број на малициозни пакети, но видовме скок почнувајќи од оваа година на PyPI. Python е популарен екосистем за наука за податоци и машинско учење. Всушност, густината на малициозен софтвер сега е поголема во PyPI отколку во NPM.
Како се активира малициозниот софтвер
Малициозните пакети се активираат за време на инсталацијата само во 4 од 10 случаи (во последниве години беше близу 6 од 10). Останатите извршуваат малициозно однесување за време на извршување, при што 1 од 100 се активира за време на извршување тестови. Се чини дека противниците знаат дека неконтролираното извршување на инсталациските скрипти било оневозможено на многу места.
Што добиваат лошите момци?
Ќе ги наведеме категориите на злонамерно однесување, при што најпопуларните се прво. Ве молиме имајте предвид дека влијанието може да биде доста различно: а бришач е тврдоглаво деструктивно, но не е вообичаено и се забележува само во неколку случаи, поврзани со целни кампањи за кибер војна или брутален хактивизам. Следните категории се доста чести:
- InfoStealer / Одводник за акредитивиНајчестите, над 90% од несофистицираните напади се едноставни крадци кои главно бараат акредитиви како лозинки, токени за пристап, API клучеви и приватни клучеви (за SSH и слично). Веројатно е наједноставно да се запише (заедно со бришачите?). Тие ги набројуваат познатите датотеки/директориуми и други извори (на пр. клучеви во регистарот), ја пакуваат содржината и ги испраќаат тие податоци до C2 сервер. Идејата е едноставна: „Објавувам крадец за фишинг акредитиви, за подоцна да можам да ги користам акредитивите за започнување насочен напад“.
Забележаното C2 мрежно поврзување е типично евтино и нечисто, како каналите на Telegram или алатки за тунелирање слични на нгрок (често во форма на обратни прокси-сервери изложени преку VPN излезни IP-адреси). Постојат стотици (!) можности, со многу GitHub проекти под тема за крадење лозинкиСпецијализации како што се keyloggers се ретки за малициозни пакети и слики од контејнери, но почести кај додатоците на алатки, каде што се очекува интеракција со корисниците.
- Dropper / DownloaderВтор по популарност, обично прв кај повеќестепените напади. Повеќе од една од три малициозни компоненти имаат dropper-и (ако малициозниот товар е вклучен во пакетот) или download-и (товарот се презема од крајна точка под контрола на напаѓачот). Товарот е често позната варијанта на бинарен малициозен софтвер и се извршува, а понекогаш и се одржува, за инсталирање на задни врати, шпионски софтвер, крипто дрејнери и други случаи на употреба. Товарот што се презема или распоредува започнува напад од втора фаза со целата моќ што ја обезбедуваат постојните бинарни датотеки на малициозен софтвер. Бинарните датотеки можат да се дистрибуираат во пакетот, честопати маскирани како слики или наводно безопасни типови датотеки, за да се избегне откривање при поврзување со неочекувани страници.
- Крадци на криптовалути / РудариФинансиски мотивираните противници се подготвени да ги користат вашите cloud средства за работа со крипто-рудари (тие дури откриваат дали работат во cloud виртуелна машина). Не им е грижа за низок коефициент на профит од 1 долар за секои 53 долари наплатени од жртвата за украдената облачна инфраструктура. Жртвите можеби нема да бидат свесни за ова сè додека не добијат неочекувана сметка. За среќа, ова доаѓа и си оди. Cryptojacking кампањите во малициозни пакети повремено се појавуваат, а потоа исчезнуваат, фишинг за корисниците на паричници или на крајот таргетирање на давателот на паричници, како во Напад на Леџер.
Други однесувања, како што е распоредување на задна врата за далечинско извршување на код со отворање на обратна обвивка е поретко сега отколку во минатото. На пример, 123rf_contributor_web пакетот (сега отстранет од регистарот) се отвора без никакво замаглување, обратна обвивка е копирана и залепена од Лист за измамници со обратна школка:
Покрај легитимните и злонамерните компоненти, забележавме неколку злоупотреби, вклучувајќи:
Спам пакети
Постојат илјадници мали пакети, претежно во NPM, без малициозен софтвер, но ветувајќи лесна заработка, „змиско масло“, линкови до понуди за Виагра и сè тоа. Неколку корисници објавуваат таков спам и земаат многу пропусен опсег од регистарот. Друг актер(и), веројатно од Индонезија, се обидел(а) да извлече корист од злоупотреба на teaRank наменето за компензација на програмерите со отворен код, преку создавање десетици илјади меѓусебно поврзани NPM пакети со поврзани репозиториуми-лажни GitHub. Ова е јасно кршење на условите за користење.
Награда за грешки и измами за истражување на безбедноста
Кога пакетот се опишува себеси како ексфилтрира податоци за добри цели, како што е откривање на безбедносни пропусти за програми за откривање на грешки или истражување на одредени аспекти на екосистемот. Видовме илјадници пакети во оваа категорија, кои внесуваат идентификациски, но не премногу чувствителни податоци на адреса на Burp Collaborator од PortSwigger (на пр. домаќин во доменот oastify.com). Честопати забележуваме имитатори на Конфузија од зависност доказ за концепт од Алекс Бирсан, како што е aurora-webmail-pro пакет (отстранет од регистарот), кој едноставно го извршува овој гаден код во скриптата за пред-инсталација:
И исто така вклучуваше „Ова е едноставен напад на конфузија на зависности - доказ за концепт„Опис на изјавата за одрекување од одговорност во пакет.jsonОва е јасно прекршување на условите за користење, дури и без злонамерна намера.
Добри вести? (Сè уште) не сме виделе напади со ransomware извршени преку малициозни компоненти. Од непознати причини, сајбер-криминалците се чини дека претпочитаат по традиционални механизми за фишинг преку е-пошта, RDP-базирани и механизми за испорака на преземања од „drive-by“.
Дополнителни техники забележани
Беа користени многу техники за упорност, избегнување на одбрана, собирање информации, комуникација со командни и контролни домаќини и ексфилтрација.
Упорност кај малициозните компоненти се добива со користење на карактеристиките на перзистентност кај бинарен малициозен софтвер од втора фаза, но понекогаш однесувањето се наоѓа во кодот на пакетот, а најчести се закажаните задачи и промените во регистарот на Windows.
Обфускација е вообичаено, но несофистицирано. Повеќето пакети за пишување грешки (запомнете го „аншопови"?) воопшто не користат заматување; многумина користат или тривијални (base64/hex кодирање или шифри за замена како rot13) или користат достапни заматувачи на код и минимизирање, што лесно се поништува со соодветни алатки. Само „ајкулите“ прават вистинска, тешка за обратно инженерство за заматување.
Замаглувањето може да го скрие нападот, но зошто би требало кодот во компонента со отворен код да биде замаглен? Дали постојат докази дека нешто треба да се скрие од обичниот поглед? Пронајдовме многу примери на незлонамерни пакети кои користат замаглување за заштита на интелектуалната сопственост, што е спротивно на „отворениот код“. Замаглувањето може да се користи како доказ за малициозен софтвер, но не е убедливо. Исто така е тешко да се отстрани замаглувањето.
затајување од одбранбените контроли усвојува едноставни техники. Злонамерниот код често е заштитен во пробај… фати блокови што ги игнорираат сите исклучоци, така што абнормалната активност не се прикажува во логовите. Верификацијата на околината (што работи во виртуелна машина или контејнер) е ретка, освен ако не станува збор за малициозен софтвер насочен кон одредена организација или околина.
Маскирањето на бинарни датотеки во слики и PDF-датотеки (вид стеганографија) беше друга техника за избегнување на откривање.
Бидејќи најчестите злонамерни компоненти се крадците на информации, собирање на податоци е од суштинско значење. Тајните (лозинки, токени за пристап, API клучеви, криптографски клучеви) рутински се скенираат во лог датотеки, променливи на околината, па дури и во таблата со исечоци (што се гледа кај банкарски тројанци и крадци на крипто). Ексфилтрацијата на изворниот код е исто така честа појава, бидејќи инсталацијата на пакетот често се врши во развоен јазол каде што може да се клонираат внатрешни git репозиториуми. Видовме пакети што набројуваат директориуми во потрага по git репозиториуми. Барањето локации како .env, private.pem, settings.py, app.js или application.properties е доста честа појава.
Ексфилтрацијата е уште една широко распространета акција. Само мал број злонамерни пакети дури се обидуваат да ја сокријат дестинацијата на извлечените податоци. Каналите на Телеграм и тунели слични на нгрок често се користат. И има многу обично домени на белата листа што се користат за ексфилтрација.
Други техники, како што се ескалација на привилегии или странично движење, беа поретки.
Стекнување популарност и доверба
Замислете технолошки измамник со готова злонамерна работа како се прашува: „Како да го направам ова срање! доверливо за тие наивни кретени?“.
Тоа се преведува во тоа како да се направи записот за малициозната компонента да прикажува многу ѕвездички / разгранувања (за популарност), плус верзии / проблеми и pull requests (за активност). Идејата е да се добие фиктивна популарност (ѕвезди) и издржувани лица, како и убедлив поглед во однос на релевантноста и одржувањето.
Регистарот не проверува дали содржината во проектот GitHub и содржината на пакетот се совпаѓаатОва е добро познат проблем во синџирот на снабдување со софтвер. Јавните регистри се огромни дупки што голтаат сè што им се фрла. Можете да поврзете кое било складиште.
Ако злонамерниот пакет со печатна грешка се најде во некоја популарна, тоа е лесно: само повикајте се на постоечкото GitHub репозиториум во манифестот на зависности што се користи за креирање на пакетот и негово објавување во регистарот. За нови пакети на лажно GitHub репозиториум, можеби ќе ви треба повеќе генијалност, можеби креирање лажни набљудување на ѕвезди/разгранување GitHub сметки преку скриптирање.
И ако содржината на вашиот пакет е релативно слична со складиштето, внесете неколку добро дизајнирани промени тука и таму… Можете да го инјектирате вашиот малициозен софтвер во нов пакет што личи на популарен пакет што се повикува на складиштето на постоечкиот и да почекате за печатни грешки. Ако некој се осмели да ја спореди содржината на tarball-от на пакетот со содржината од складиштето на GitHub, разликите на точките на инјектирање на малициозен софтвер лесно би можеле да се пропуштат. Овој пристап го видовме многу пати претходно.
Механизам преку кој компонентата ќе даде изјава за неовластено отварање во врска со потеклото, како е изграден пакетот, од кои извори и од кого, би бил добредојден. Но, тоа е друга приказна.
Дали компонентата X е малициозен софтвер?
Дали постои (сеопфатна) база на податоци за малициозни пакети? Не. Ранливостите со отворен код имаат доделен CVE ID, но само на неколку малициозни пакети (особено на оние што се појавуваат во насловите) им е доделен еден. CWE за малициозни пакети е CWE-506 (вграден малициозен код).
Вообичаените алатки за малициозен софтвер (VirusTotal, MalwareBazaar, SOREL-20M…) не предвидуваат посебни одредби за малициозни компоненти. Тоа би било добредојдено!
Постојат примероци од истражувачки бази на податоци и збирки на податоци за анализа (ние користиме неколку од нив), но записите се ажурираат само кога е познат малициозниот пакет, што често е предоцна. Ако сте заинтересирани, OpenSSF Злонамерни пакети е убав почеток.
Во следниот пост, ќе разговараме за тоа како да знаете дали даден пакет е злонамерен. Спојлер: да, постојат начини за проверка на злонамерни компоненти рано за време на прозорецот за изложеност, пред регистарот да отстрани позната злонамерна компонента.
Понатамошно читање
Во следната епизода „Заштита од малициозни пакети со отворен код: Што (не) функционира" Ќе разговараме за тоа што треба и што не треба да се прави за безбедноста со отворен код. Повеќето професионалци кои се свесни за безбедноста имаат интуиција за тоа како да се справат со оваа закана, но има изобилство од заблуди.
Ќе разгледаме зошто овие идеи се погрешни и како таквите заблуди придонесуваат за популарноста на овој механизам за напад и за огромниот ризик што го доживуваат организациите. Потоа ќе продолжиме со тоа што функционира и кои се напорите и ресурсите што се вклучени.
Исто така, ќе објавиме за еволуцијата на малициозните пакети во однос на нивната намера, механизам за инјектирање и техники на напад.
Останете со нас!
