Хакери перетворили надійний Rust-крейт на систему доставки шкідливого програмного забезпечення

Популярний Rust-пакет став останньою жертвою зростаючої тенденції атак на ланцюги постачання програмного забезпечення. Згідно зі звітами The Register, хакери зламали обліковий запис мейнтейнера, що стоїть за arrayref — широко використовуваним Rust-крейтом, — і опублікували шкідливі оновлення, призначені для викрадення облікових даних розробників. Цей крейт, завантажений приблизно 245 мільйонів разів, є саме тим фундаментальним, легким для огляду залежним компонентом, який робить такий стиль атак настільки ефективним.

Замість того щоб атакувати окремих розробників безпосередньо, зловмисники вдарили по самому ланцюгу постачання програмного забезпечення. Отримавши контроль над обліковим записом мейнтейнера, вони змогли впровадити інфостилер у те, що виглядало як звичайне оновлення. Кожен, хто підтягував скомпрометовану версію у свою збірку, несвідомо перетворював власне середовище розробки на точку доставки коду, що викрадає облікові дані.

Чому ця атака спрацювала так добре

Екосистема Rust, як і більшість сучасних середовищ програмування, значною мірою покладається на спільні бібліотеки коду, які називаються крейтами. Розробники рідко перевіряють кожну залежність рядок за рядком. Натомість вони довіряють тому, що пакет із мільйонами завантажень і усталеним мейнтейнером уже був перевірений спільнотою. Саме цю довіру зловмисники й експлуатують.

Цей інцидент вписується в модель так званої атаки на ланцюг постачання, коли зловмисники націлюються на слабшу ланку — у цьому випадку один обліковий запис мейнтейнера, — щоб дістатися до значно більшої групи жертв нижче за течією. Оскільки arrayref вбудований у безліч інших проєктів, одне скомпрометоване оновлення могло розповсюдитися безліччю кодових баз, перш ніж хтось помітив би, що щось не так.

Що робить цей випадок помітним, так це конкретне навантаження. Замість простого впровадження бекдору чи скрипту для криптомайнінгу, шкідливе оновлення було створене для безпосереднього збору облікових даних розробників із заражених систем. Це значне загострення. Викрадені облікові дані розробників можуть бути використані для доступу до репозиторіїв вихідного коду, хмарної інфраструктури, реєстрів пакетів та інших високоцінних систем, що потенційно відкриває шлях для подальших атак, які виходять далеко за межі первинної жертви.

Ризики для приватності розробників

Більшість обговорень атак на ланцюги постачання програмного забезпечення зосереджені на технічних наслідках: зламані збірки, скомпрометовані виробничі системи, екстрені патчі. Але тут є вимір приватності, який заслуговує на більше уваги.

Розробники зберігають на своїх машинах величезну кількість чутливої інформації: ключі API, ключі SSH, токени хмарних сервісів і облікові дані для входу у внутрішні інструменти. Інфостилер, призначений для запуску під час рутинного процесу збірки, має прямий доступ саме до такого роду даних. На відміну від фішингового листа, який обережний розробник міг би помітити, шкідлива залежність виконується мовчки як частина нормальної, очікуваної поведінки. Немає підозрілого посилання, на яке треба натиснути, і немає очевидних тривожних сигналів — просто оновлення пакета, яке виглядає як будь-яке інше.

Саме тому атаки на отруєння крейтів і пакетів є особливо тривожними з точки зору приватності. Жертви часто не знають, що їхні облікові дані були розкриті, доки викрадені дані не використають деінде — чи то несанкціонований доступ до хмарного середовища компанії, чи подальша компрометація інших проєктів з відкритим кодом, які підтримує розробник.

Що це означає для вас

Якщо ви Rust-розробник або працюєте з будь-якою мовою, що покладається на екосистеми пакетів із відкритим кодом, цей інцидент — нагадування, що довіра до популярності пакета не дорівнює довірі до його поточної безпеки. Крейт, завантажений 245 мільйонів разів, усе ще може бути скомпрометований, якщо один обліковий запис мейнтейнера буде захоплений.

Практичні кроки, які варто розглянути, включають закріплення версій залежностей замість автоматичного підтягування останнього релізу, перевірку журналів змін перед оновленням критичних пакетів і використання інструментів, які сканують залежності на предмет відомої шкідливої поведінки. Увімкнення багатофакторної автентифікації на будь-яких облікових записах, пов'язаних із публікацією пакетів, а також регулярна ротація облікових даних також зменшують радіус ураження, якщо обліковий запис буде скомпрометовано.

Організаціям, які значною мірою покладаються на залежності з відкритим кодом, також варто розглянути підтримку внутрішнього реєстру використовуваних пакетів і моніторинг незвичної активності оновлень, особливо для пакетів із непропорційно великим впливом на багато проєктів.

Випереджаючи загрози ланцюгам постачання

Ця атака на arrayref навряд чи буде останнім випадком, коли хакери націлюються на екосистему відкритого коду для викрадення облікових даних розробників. Оскільки ланцюги постачання програмного забезпечення стають дедалі взаємопов'язанішими, один скомпрометований обліковий запис мейнтейнера може мати наслідки, що виходять далеко за межі одного проєкту.

Для розробників висновок не в тому, щоб відмовитися від інструментів із відкритим кодом, а в тому, щоб ставитися до управління залежностями з тією ж увагою, яку застосовують до будь-якої іншої чутливої до безпеки системи. Перевіряйте оновлення перед їх злиттям, обмежуйте дозволи, надані середовищам збірки, і припускайте, що навіть довірені пакети з великою кількістю завантажень можуть стати векторами атак. Поінформованість про такі інциденти, як цей, — один із найпростіших способів вчасно помітити попереджувальні сигнали та захистити як свої облікові дані, так і системи, які ви допомагаєте створювати.