Атака №5: Supply Chain Attack

Когато доверието към партньори се превръща във входна точка

Обобщение – Supply Chain Attack

Как работи атаката

Supply chain атаките рядко таргетират крайната жертва директно.

Вместо това атакуващите компрометират доверена трета страна. Софтуерен доставчик, managed service provider, IT партньор или инфраструктура за обновления. Чрез този доверен канал се въвежда зловреден код, достъп или команди в downstream среди.

Тъй като източникът изглежда легитимен, атаката заобикаля много традиционни предположения за сигурност.

Софтуерни обновления, интеграционни креденшъли или инструменти за отдалечено управление се превръщат в механизъм за доставка.

Доверието в supply chain се превръща в атакуващ вектор.

Реални случаи

Supply chain атаките компрометират доверен доставчик, софтуерен компонент или процес за разработка. Така злонамерен код може да достигне до множество организации чрез легитимен продукт или актуализация.

3CX (2023)

Сектор: Бизнес комуникации и софтуер

Как е започнал инцидентът?
Служител на 3CX инсталира компрометираното приложение X_TRADER на личния си компютър. Нападателите открадват корпоративните му идентификационни данни и ги използват за достъп до средата на 3CX. Така една supply chain атака води до втора.

Какво е било компрометирано?

• средата за разработка на 3CX;
• легитимни и цифрово подписани версии на 3CX Desktop App;
• устройства, инсталирали засегнатите версии за Windows и macOS.

Как се е развила атаката?
Компрометираният софтуер е разпространен през официалните канали на 3CX. Злонамерените компоненти са позволявали многоетапна атака и изтегляне на допълнителен код към избрани системи.

Какво би могло да ограничи щетите?

• изолирани и наблюдавани среди за разработка;
• защита на привилегированите акаунти;
• контрол върху личните устройства и външния софтуер;
• проверка на компилациите преди разпространение.

XZ Utils (2024)

Сектор: Софтуер с отворен код и Linux инфраструктура

Как е започнал инцидентът?
Злонамерен код е прикрит в release пакетите на XZ Utils версии 5.6.0 и 5.6.1. Основната част от backdoor механизма е добавена чрез файлове в разпространяваните tarball пакети, което затруднява откриването му само чрез преглед на публичния изходен код.

Какво е било компрометирано?

• процесът за публикуване на широко използвана Linux библиотека;
• определени DEB и RPM пакети за x86-64 системи;
• потенциално sshd, при специфични компилации и конфигурации.

Как се е развила атаката?
Backdoor-ът е открит, преди засегнатите версии да навлязат широко в стабилните Linux дистрибуции. Fedora, Red Hat и други проекти спират разпространението им и препоръчват връщане към безопасни версии.

Какво би могло да ограничи щетите?

• проверка на произхода и целостта на пакетите;
• възпроизводими компилации;
• независимо одобрение на критичните промени;
• точна инвентаризация на софтуерните зависимости.

Какво показват тези случаи?

При 3CX компрометиран продукт от един доставчик позволява проникване в друг доставчик и заразяване на неговото приложение. При XZ Utils нападателят се насочва към самия процес за поддръжка и публикуване на широко използван компонент.

И двата случая показват, че цифровият подпис и довереният източник не са достатъчни сами по себе си. Организациите трябва да проверяват произхода на софтуера, да наблюдават поведението му след актуализация и да поддържат видимост върху използваните зависимости.

Кого таргетира най-често

Supply chain атаките търсят мащаб и обхват.

Роли

• IT администратори, управляващи интеграции

• DevOps и софтуерни екипи

• доставчици на услуги и партньори

• managed service providers (MSP)

Сектори

• технологични компании и SaaS

• производствени екосистеми

• финансови услуги

• здравеопазване

• публична инфраструктура

Тип организации

• предприятия с голяма мрежа от доставчици

• cloud-базирани среди

• организации, силно зависими от външни платформи

• компании с автоматизирани интеграционни процеси

Колкото по-взаимосвързана е екосистемата, толкова по-голям е потенциалният обхват на атаката.

На какво разчита атаката

Компрометирането на supply chain успява, когато доверието се приема за даденост, вместо да бъде проверявано.

Човешки фактор

• автоматично доверие към доставчици

• ограничена осведоменост за рисковете на партньори

• недостатъчен контрол върху трети страни

Технически пропуски

• споделени креденшъли или токени

• слаба API сигурност

• непроверени софтуерни обновления

• прекомерни права на интеграции

Процесни слабости

• ограничени проверки на сигурността на доставчици

• липса на проверка на софтуерната цялост

• липса на мониторинг на външни интеграции

• слабо управление на supply chain риска

Supply chain атаките експлоатират най-слабата връзка в доверената мрежа.

Как се хваща

Откриването е трудно, защото източникът често изглежда легитимен.

Какво може да забележи потребителят

• необичайно поведение след софтуерно обновление

• неочаквани промени в системи

• спад в производителността

Какво вижда IT екипът

• аномалии в процесите на обновление

• подозрително поведение на интеграции

• необичайна API активност

Какво вижда SOC

• корелирани аномалии в множество среди

• подозрителен трафик от партньорска инфраструктура

• нетипични модели на разпространение на обновления

Supply chain инцидентите често започват като малки аномалии.

Как се ограничава въздействието

Когато има съмнение за supply chain компрометиране, реакцията трябва да е координирана.

Основните действия включват:

• изолиране на засегнатите системи и интеграции

• временно спиране на достъп на компрометирани доставчици

• проверка на софтуерната цялост

• ротация на интеграционни ключове и токени

• комуникация с партньори и засегнати страни

Пренебрегването на ранните сигнали може да позволи компрометирането да се разпространи в множество организации.

Какво реално помага

Управлението на риска във supply chain изисква както технологични, така и управленски мерки.

Хора

• осведоменост за риска от доставчици

• сътрудничество по сигурността с партньори

• ясни канали за ескалация

Процеси

• формални проверки на сигурността на доставчици

• рамки за управление на supply chain риска

• политики за проверка на софтуер

• координация при инциденти с партньори

Технологии

• проверка на сигурността на софтуерни обновления

• мониторинг на API и интеграции

• управление на идентичности и достъп за партньори

• SOC мониторинг на връзките с доставчици

Доверието трябва да бъде непрекъснато проверявано, а не автоматично приемано.

Чести митове

„Доверените доставчици не могат да бъдат източник на атаки“
„Широко използваният софтуер е сигурен“
„Периметърната защита ни защитава“

В реалността supply chain атаките заобикалят традиционните защити, защото действат чрез доверени взаимоотношения.

Атака №1: Фишинг и социално инженерство

Атака №2: Злоупотреба с акаунти и превземане на достъп

Атака №3: Компрометиране на бизнес имейли

Атака №4: Ransomware

Следва: Атака №6 – Insider Threat