Розробників дедалі частіше атакують через інструменти, які вони використовують для співпраці та створення коду, такі як Docker, Kubernetes і Slack, оскільки кіберзлочинці та представники національних держав прагнуть отримати доступ до цінного програмного забезпечення, над яким розробники працюють щодня.
Наприклад, 18 вересня зловмисник заявив, що використав викрадені облікові дані Slack для доступу та копіювання понад 90 відео, які представляють рання розробка Grand Theft Auto 6, популярна гра від Rockstar Games від Take-Two Interactive. А тижнем раніше компанія з безпеки Trend Micro виявила, що зловмисники систематично шукали та намагалися скомпрометувати неправильно налаштовані контейнери Docker.
Жодна атака не пов’язана з уразливими місцями програмного забезпечення, але помилки безпеки або неправильна конфігурація не є рідкістю з боку розробників, які часто не вживають заходів, необхідних для захисту своєї поверхні атаки, каже Марк Лавлесс, штатний інженер безпеки GitLab, a Постачальник платформи DevOps.
«Багато розробників не вважають себе цілями, тому що вони думають, що зловмисники прагнуть отримати готовий код, кінцевий результат», — каже він. «Розробники часто ризикують безпекою — наприклад, встановлюють тестове середовище вдома або знімають усі елементи керування безпекою — щоб вони могли випробувати нові речі з наміром додати захист пізніше».
Він додає: «На жаль, ці звички тиражуються і стають культурою».
Атаки на ланцюг постачання програмного забезпечення — і розробників, які виробляють і розгортають програмне забезпечення — швидко зросли за останні два роки. Наприклад, у 2021 році кількість атак, спрямованих на компрометацію програмного забезпечення розробників — і компонентів з відкритим кодом, які широко використовуються розробниками — зросла на 650%, згідно з “2021 Стан «Ланцюжка поставок програмного забезпечення», опублікований компанією з безпеки програмного забезпечення Sonatype.
Конвеєри розробників і співпраця в пам’ятках
Загалом експерти з безпеки стверджують, що швидкі темпи безперервної інтеграції та середовищ безперервного розгортання (CI/CD), які є основою підходів у стилі DevOps, створюють значні ризики, оскільки їх часто не помічають коли йдеться про впровадження посиленої безпеки.
Це впливає на різноманітні інструменти, що використовуються розробниками для створення більш ефективних конвеєрів. Slack, наприклад, є найпопулярнішим інструментом для синхронної співпраці серед професійних розробників, а Microsoft Teams і Zoom займають друге і третє місця, згідно з даними Опитування розробників StackOverflow 2022. Крім того, опитування показало, що понад дві третини розробників використовують Docker, а ще чверть — Kubernetes під час розробки.
Зломи таких інструментів, як Slack, можуть бути «неприємними», оскільки такі інструменти часто виконують критичні функції та зазвичай мають лише захист периметра, сказав Метью Ходжсон, генеральний директор і співзасновник платформи обміну повідомленнями Element, у заяві, надісланій Dark Reading.
«Slack не має наскрізного шифрування, тому зловмисник має доступ до всього обсягу знань компанії», — сказав він. «Справжня ситуація з лисицею в курнику».
Крім помилок конфігурації: інші проблеми безпеки для розробників
Варто зазначити, що кібератакники шукають не лише неправильну конфігурацію чи слабкий захист, коли справа доходить до розробників. У 2021 році, наприклад, доступ групи загроз до Slack через придбання маркера входу на сірому ринку призвело до злому ігрового гіганта Electronic Arts, що дозволило кіберзлочинцям скопіювати майже 800 ГБ вихідного коду та даних фірми. І розслідування зображень Docker у 2020 році виявило це більше половини останніх збірок мають критичні вразливості, які піддають ризику будь-яку програму чи службу, засновану на контейнерах.
Фішинг і соціальна інженерія також є чумою в цьому секторі. Тільки цього тижня розробники, які використовують два сервіси DevOps — CircleCI та GitHub — були націлені на фішингові атаки.
Крім того, немає жодних доказів того, що зловмисники, націлені на Rockstar Games, використовували вразливість у Slack — лише твердження ймовірного зловмисника. Натомість соціальна інженерія, ймовірно, була способом обійти заходи безпеки, йдеться в заяві представника Slack.
«Безпека корпоративного рівня в управлінні ідентифікацією та пристроями, захисті даних і управлінні інформацією вбудована в кожен аспект того, як користувачі співпрацюють і виконують роботу в Slack», — сказав речник, додавши: «Ці тактики [соціальної інженерії] стають все більш популярними. поширені та складні, і Slack рекомендує всім клієнтам застосовувати суворі заходи безпеки, щоб захистити свої мережі від атак соціальної інженерії, включаючи навчання з питань безпеки».
Повільні покращення безпеки, більше роботи
Проте розробники лише повільно прийняли безпеку, оскільки спеціалісти з безпеки програм вимагають кращого контролю. Багато розробників продовжує розкривати «секрети» — включаючи паролі та ключі API — у коді, що надсилається до репозиторіїв. Таким чином, команди розробників повинні зосередитися не лише на захисті свого коду та запобіганні імпорту ненадійних компонентів, але й на забезпеченні того, щоб критичні можливості їхніх конвеєрів не були скомпрометовані, каже Лавлесс із GitLab.
«Вся частина нульової довіри, яка зазвичай пов’язана з ідентифікацією людей і подібними речами, також повинна мати ті самі принципи, які мають застосовуватися до вашого коду», — каже він. «Тож не довіряйте коду; це треба перевірити. Наявність людей або процесів, які передбачають найгірше — я не збираюся довіряти цьому автоматично — особливо коли код виконує щось критичне, наприклад, створює проект».
Крім того, багато розробників досі не використовують базові заходи для посилення автентифікації, такі як використання багатофакторної автентифікації (MFA). Однак зміни відбуваються. Усе частіше починаються різні екосистеми пакетів програмного забезпечення з відкритим кодом вимагаючи, щоб великі проекти використовували багатофакторну автентифікацію.
Що стосується інструментів, на яких слід зосередитися, Slack привернув увагу через останні серйозні порушення, але розробники повинні прагнути до базового рівня контролю безпеки для всіх своїх інструментів, говорить Лавлесс.
«Є припливи та відпливи, але це те, що працює для зловмисників», — каже він. «Говорачи з мого досвіду носіння різного роду капелюхів різних кольорів, як нападник, ви шукаєте найпростіший шлях, тож якщо інший шлях стає легшим, тоді ви говорите: «Я спробую це спочатку».»
Лавлесс зазначає, що GitLab бачив таку поведінку слідування за лідером у своїх власних програмах винагород за помилки.
«Ми бачимо, коли люди надсилають повідомлення про помилки, раптом щось — нова техніка — стає популярною, і з’являється ціла низка повідомлень, які є результатом цієї техніки», — каже він. «Вони точно приходять хвилями».
