У попередньому епізоді, Шкідливі пакети з відкритим кодом: проблема, ми обговорили, чому зловмисники були такими з ентузіазмом ставляться до публікації нових шкідливих компонентів або впровадження шкідливого програмного забезпечення в останні версії існуючих компонентів: інфраструктура з відкритим кодом дозволяє будь-кому будь-де створювати тимчасовий обліковий запис у реєстрі компонентів (наприклад, NPM, PyPI, Docker Hub або Visual Studio Marketplace) або платформі для спільної розробки (наприклад, GitHub). Нульова вартість та багато можливостей для використання надмірної довіри, яку команди розробників програмного забезпечення традиційно мають до компонентів сторонніх розробників.
Асиметрія між тим, наскільки легко зловмисникам поширювати шкідливе програмне забезпечення, використовуючи інфраструктуру, доступну для програм з відкритим кодом, і тим, наскільки важко організаціям, що розробляють програмне забезпечення (всім?), уникнути зараження шкідливим програмним забезпеченням (і постачати шкідливе програмне забезпечення в програмному забезпеченні, яке вони розповсюджують для інших), призвела до майже досягнення позначки в чверть мільйона шкідливих пакетів минулого року.
Це проблема такого масштабу, що жодна організація окремо не може її вирішити, і спільнота зараз переосмислює процес відкритого коду щодо довіри, принципів безпеки за замовчуванням та безпеки за проектуванням, а також життєвого циклу компонентів. Ми розглянемо ці ідеї в наступному епізоді. Захист від шкідливих пакетів з відкритим кодом: що (не) працює.
Пам’ятайте, що ми говоримо про програмні компоненти, які здебільшого відповідають програмні пакети: компоненти повторного використання, упаковані таким чином, щоб на них можна було посилатися як на залежність у маніфесті програмного забезпечення, та встановлені за допомогою менеджера пакетів або інструменту збірки. Зверніть увагу, що цей випадок можна розширити, включивши публічні зображення контейнерів (використовується середовищами виконання контейнерів та платформами оркестрації, такими як Kubernetes), та розширення програмних інструментів (для створення, автоматизації та розгортання).
Тут ми аналізуємо, як це тактика атаки, заснована на шкідливих компонентах працює, згідно з попередніми прикладами та тим, що ми бачили на нашій платформі для раннього попередження про шкідливе програмне забезпечення (MEW). Ми розглянемо шкідливі компоненти в різних вимірах:
(1) спосіб, обраний для розповсюдження (використаний реєстр, у новому чи існуючому компоненті, та метод, використаний для зараження опублікованої версії компонента), (2) як активується або спрацьовує шкідливе програмне забезпечення, (3) шкідлива поведінка, тобто які шкідливі дії спостерігаються та яка мотивація зловмисника, (4) які методи є поширеними для обфускації, приховування, щоб залишатися непоміченим, бокового переміщення, зв'язку з хостами командування та контролю (C2) тощо; та (5) методи завоювання достатньої популярності та довіри, щоб жертви зрештою встановили компонент.
Обраний механізм розподілу
Ми спостерігаємо «фоновий шум«недосвідчених шкідливих пакетів, що використовують опечатки, щоб обдурити необачних розробників, допустивши друкарську помилку в назві пакета для їхньої залежності. Багато популярних пакетів отримують шквал пакетів з подібними назвами та друкарськими помилками, в очікуванні, що вони обдурять якихось необачних розробників.
Вони використовують тимчасовий обліковий запис, публікують групу пакетів typosquat, створюють ще один і публікують ще одну групу… Використовуючи певну автоматизацію та винахідливість, вони можуть досягти певної складності, але зазвичай вони досить тривіальні. Ми внутрішньо називаємо їх «анчоуси«Головною метою є крадіжка облікових даних, але іноді ми виявляємо, що шпигунські програми викрадають вихідний код або конфіденційні дані, такі як особисту інформацію (PII), захоплюють буфер обміну та мають інші проблеми».
Несподівано ми бачимо більш складні шкідливі компоненти, «акули». Меншість з них націлені на певні групи чи організації, зазвичай за допомогою криптодренажів або веб-скімерів, які активуються умовно, можливо, за підходом, який спостерігається в інцидент потоку подій розшифрування корисного навантаження атаки лише тоді, коли на пакет посилається цільовий пакет.
Механізм розподілу було проаналізовано у чудовій і нині класичній статті «Колекція ножів Backstabber's Knife: Огляд атак на ланцюг поставок програмного забезпечення з відкритим кодом», яку обов’язково варто прочитати. Ви напевно вже бачили цю гарну діаграму:
Були досліджені всі шляхи, включаючи нові та існуючі пакети; вплив на вихідний код, систему збірки або сам компонент пакета; використання викрадених облікових даних або соціальної інженерії; захоплення покинутих облікових записів і репозиторіїв або отруєння тих, що вже підтримуються. Деякі атаки отримали назви (Типоскватінг, Плутанина із залежностями, Явна плутанина, Репо-джекінгтощо) та вже обговорювалися в іншому місці.
А як щодо обраних реєстрів?
NPM продовжує лідирувати за загальною кількістю шкідливих пакетів, але цього року ми спостерігаємо сплеск на PyPI. Python — популярна екосистема для обробки даних та машинного навчання. Фактично, щільність шкідливого програмного забезпечення зараз вища в PyPI, ніж у NPM.
Як спрацьовує шкідливе програмне забезпечення
Шкідливі пакети спрацьовують під час встановлення лише у 4 випадках з 10 (в останні роки цей показник був близьким до 6 з 10). Решта запускає шкідливу поведінку під час виконання, причому 1 зі 100 спрацьовує під час тестування. Зловмисники, схоже, знають, що неконтрольоване виконання скриптів встановлення було вимкнено в багатьох місцях.
Що отримують лиходії?
Ми перерахуємо категорії шкідливої поведінки, починаючи з найпопулярніших. Зверніть увагу, що вплив може бути досить різним: a склоочисник вперто руйнівний, але не поширений і спостерігався лише в кількох випадках, пов'язаних із цілеспрямованими кібервійнами або жорстоким хактивізмом. Наступні категорії досить поширені:
- InfoStealer / Credential DrainerНайчастішими, понад 90% простих атак є прості атаки, що здійснюються за допомогою крадіжки, які в основному шукають облікові дані, такі як паролі, токени доступу, ключі API та закриті ключі (для SSH тощо). Це, мабуть, найпростіше написати (разом з вайперами?). Вони перераховують відомі файли/каталоги та інші джерела (наприклад, ключі реєстру), упаковують вміст і надсилають ці дані на сервер C2. Ідея проста: «Я публікую крадіжку для фішингових облікових даних, щоб пізніше я міг використовувати ці облікові дані для запуску спрямованої атаки».
Спостережуваний мережевий зв'язок C2 зазвичай є дешевим та брудним, як-от канали Telegram або інструменти для тунелювання, подібні до ngrok (часто у вигляді зворотних проксі-серверів, що розкриваються через вихідні IP-адреси VPN). Існують сотні (!) можливостей, і багато проектів GitHub знаходяться під тема про викрадання паролівСпеціалізації, такі як кейлогери, рідко зустрічаються для шкідливих пакетів та образів контейнерів, але частіше зустрічаються в розширеннях інструментів, де очікується взаємодія з користувачем.
- Завантажувач / ЗавантажувачДругий за популярністю, зазвичай перший у багатоетапних атаках. Більше одного з трьох шкідливих компонентів мають дроппери (якщо шкідливе корисне навантаження входить до складу пакета) або завантажувачі (корисне навантаження завантажується з кінцевої точки під контролем зловмисника). Корисне навантаження часто є відомим варіантом бінарного програмного забезпечення, яке запускається, а іноді й зберігається, для встановлення бекдорів, шпигунських програм, крипто-знешкоджувачів та інших випадків використання. Завантажене або розгорнуте корисне навантаження запускає атаку другого етапу з усією потужністю, яку надають існуючі бінарні файли шкідливого програмного забезпечення. Бінарні файли можуть поширюватися всередині пакета, часто маскуючись під зображення або нібито нешкідливі типи файлів, щоб уникнути виявлення під час підключення до неочікуваних сайтів.
- Викрадачі / Майнери криптовалютФінансово мотивовані зловмисники готові використовувати ваші хмарні ресурси для запуску криптомайнерів (вони навіть виявляють, чи працюють вони у хмарній віртуальній машині). Їм байдуже... низький коефіцієнт прибутку 1 долар за кожні 53 долари, стягнуті з жертви за викрадену хмарну інфраструктуру. Жертви можуть не знати про це, доки не отримають неочікуваний рахунок. На щастя, це то з'являється, то зникає. Cryptojacking Шкідливі пакети час від часу з’являються, а потім зникають, займаючись фішингом користувачів гаманців або, зрештою, націлюючись на постачальника гаманця, як у Атака на Ledger.
Інші моделі поведінки, такі як розгортання закулісний для віддаленого виконання коду шляхом відкриття зворотної оболонки зараз трапляється рідше, ніж у минулому. Наприклад, 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 через скрипти.
А якщо вміст вашого пакета досить схожий на репозиторій, вставте пару добре продуманих змін тут і там… Ви можете впровадити своє шкідливе програмне забезпечення в новий пакет, схожий на популярний, посилаючись на репозиторій існуючого, і чекати на помилки. Якщо хтось наважиться порівняти вміст tar-архіву пакета з вмістом репозиторію GitHub, відмінності в точках впровадження шкідливого програмного забезпечення можна легко пропустити. Ми вже багато разів бачили такий підхід раніше.
Було б добре, якби компонент мав можливість створювати захищене від несанкціонованого доступу повідомлення про походження, спосіб створення пакета, джерела та ким. Але це вже інша історія.
Чи є компонент X шкідливим програмним забезпеченням?
Чи існує (повна) база даних шкідливих пакетів? Ні. Вразливостям з відкритим кодом призначається ідентифікатор CVE, але його отримують лише деякі шкідливі пакети (особливо ті, що потрапляють у заголовки газет). CWE для шкідливих пакетів... CWE-506 (вбудований шкідливий код).
Звичайні інструменти для боротьби зі шкідливими програмами (VirusTotal, MalwareBazaar, SOREL-20M…) не передбачають спеціальних заходів для шкідливих компонентів. Це було б добре!
Існують дослідницькі зразки баз даних та наборів даних для аналізу (ми використовуємо кілька з них), але записи оновлюються лише тоді, коли шкідливий пакет відомий, що часто буває занадто пізно. Якщо вам цікаво, OpenSSF Шкідливі пакети це гарний початок.
У наступній публікації ми обговоримо, як дізнатися, чи є певний пакет шкідливим. Спойлер: так, існують способи перевірки на наявність шкідливих компонентів на ранній стадії періоду зараження, до того, як реєстр видалить відомий шкідливий компонент.
Подальше читання
У наступному епізоді «Захист від шкідливих пакетів з відкритим кодом: що (не) працює" Ми обговоримо, що можна і чого не можна робити для безпеки відкритого коду. Більшість фахівців, що обізнані з безпекою, мають інтуїцію щодо того, як боротися з цією загрозою, але помилкових уявлень предостатньо.
Ми розглянемо, чому ці ідеї хибні, і як такі помилкові уявлення сприяють популярності цього механізму атаки, а також величезному ризику, з яким стикаються організації. Потім ми перейдемо до того, що працює, і які зусилля та ресурси потрібні.
Також ми збираємося опублікувати інформацію про еволюцію шкідливих пакетів з точки зору їхнього наміру, механізму впровадження та методів атаки.
Залишайтеся з нами!
