Дослідники стартапу з кібербезпеки Hacktron менш ніж за 72 години пройшли шлях від вразливості у спільнотному форумі OpenAI до внутрішнього GitHub monorepo компанії. Там вони відкрили один безпечний запит на злиття (pull request) і зупинилися. Monorepos полегшують роботу з кодовою базою, але не ізолюють проєкти так, як це роблять окремі репозиторії. ШІ-агенти для кодування підвищують ставки, оскільки можуть мати широкий, постійний доступ.
У своєму блозі дослідники Hacktron детально описали, як вони використали моделі Anthropic Claude для об’єднання двох критичних вразливостей, щоб отримати контроль над обліковими записами співробітників OpenAI у ChatGPT. Звідти, через скомпрометоване середовище Codex співробітника, вони отримали доступ до внутрішнього GitHub monorepo OpenAI.
Дослідники не стали читати вихідний код OpenAI або перевіряти, наскільки далеко вони могли б зайти.
«Оскільки люди можуть підключати різні сервіси до Codex і ChatGPT, обсяг того, до чого ми теоретично могли отримати доступ, був величезним, включно з GitHub, Slack та електронною поштою», — написали вони.
Як Hacktron отримав доступ до monorepo OpenAI
Дослідницька команда Hacktron почала з форуму Discourse на community.openai.com. Оскільки форум підтримував функцію «Увійти через OpenAI» через auth.openai.com, дослідники висунули гіпотезу, що його компрометація може надати їм шлях до ширших сервісів OpenAI.
Дослідники виявили вразливість віддаленого виконання коду (RCE) в конвеєрі завантаження зображень Discourse. Після того, як Opus 4.8 не зміг надійно створити експлойт, вони використали нещодавно випущену версію Opus 5, щоб підтвердити, що локальне RCE можна досягти через завантаження зображення.
Вони помістили Claude в автономний цикл виконання завдань проти власного екземпляра Discourse Cloud як вправу «візьми прапор» (capture-the-flag), оскільки Opus спочатку відмовився написати експлойт-ланцюжок для віддаленого екземпляра. Через чотири години Claude досяг RCE на їхньому екземплярі Discourse Cloud. 25 липня дослідники досягли RCE на екземплярі OpenAI.
Hacktron заявили, що окрема неправильна конфігурація в інфраструктурі ідентифікації OpenAI дозволила використати скомпрометований форум для захоплення облікових записів ChatGPT та Codex користувачів, які ввійшли до нього, без подальшої взаємодії. Потім дослідники отримали контроль над обліковим записом співробітника OpenAI, середовище Codex якого було підключено до організації GitHub OpenAI, і використали його для відкриття PR (proof-of-concept) у внутрішньому monorepo. Процес від початкового виявлення до доступу до репозиторію зайняв менш як 72 години.
Hacktron повідомили про проблему OpenAI та окремо Discourse. Приблизно через 14 годин після першого звернення до OpenAI, компанія підтвердила, що проблему було виправлено. OpenAI не відповіла на запит про коментар до моменту публікації.
Чого може досягти одна скомпрометована ідентичність
Незалежний аналітик технологій Кармі Леві назвав інцидент з OpenAI «своєрідним попереджувальним пострілом» для індустрії. Monorepos можуть бути зручними, оскільки вони консолідують ресурси розробки для кількох проєктів, але коли ідентичність має широкий доступ у репозиторії, вони також можуть стати «монолітним об’єктом» для зловмисників, які прагнуть отримати більше від одного компрометування, як сказав Леві.
Ерік Авакян, технічний радник Info-Tech Research Group і колишній CISO штату Пенсильванія, зазначив, що monorepos самі по собі не є небезпечними. Проблема полягає в концентрації ризиків. Хоча monorepos можуть містити код для багатьох різних додатків, сервісів, бібліотек та внутрішніх систем, це все ж один репозиторій, і якщо певна ідентичність має широкий доступ, потенційна зона ураження може стати набагато більшою, ніж люди усвідомлюють.
Авакян зазначив, що ШІ-агенти для кодування є значущими, оскільки вони розроблені для пошуку коду, розуміння зв’язків між компонентами та внесення змін у кодову базу. Вони можуть орієнтуватися в цьому коді набагато швидше, ніж людина-зловмисник, який вручну намагається визначити, де розташовані важливі фрагменти коду, залежності та конфігурації.
«Це надзвичайно корисні можливості, але якщо агент або ідентичність, під якою він діє, буде скомпрометована, ці ж можливості можуть обернутися проти вас», — сказав Авакян.
Авакян зазначив, що доступ має відповідати принципу найменших привілеїв. Якщо агент потребує лише доступу для читання коду, наприклад, він не повинен мати права на запис. GitHub Apps можна обмежувати певними репозиторіями, надавати різні рівні дозволів на репозиторій і використовувати токени встановлення, термін дії яких закінчується через годину. Але ці дозволи все ще діють на рівні репозиторію. У monorepo вони не створюють окремих меж доступу для читання між директоріями.
GitHub має окремі засоби контролю над тим, що змінюється або зливається. Він може вимагати рецензування від власників коду, тоді як захист гілок і набори правил можуть вимагати рецензування, статус-перевірки та інших умов перед злиттям змін. Ці засоби контролю можуть обмежувати те, що змінюється або зливається, але вони не обмежують те, що може бачити ідентичність.
Що потрібно перевіряти командам безпеки
Авакян зазначив, що підприємства не повинні розглядати це як абсолютно нову територію. Такі підходи, як OAuth, сервісні ідентичності, короткотривалі облікові дані та доступ з найменшими привілеями, існують вже досить давно і тепер поширюються на ШІ-агентів.
«Зараз я б порадив CISO не починати з агента, — сказав Авакян, — а з облікових даних».
Команди безпеки повинні спочатку визначити, які облікові дані використовує кодувальний агент і яку ідентичність він представляє, сказав Авакян: токен OAuth співробітника, GitHub App, сервісний обліковий запис, персональний токен доступу, ключ Secure Shell (SSH) або інші делеговані облікові дані. Звідти команди безпеки можуть оцінити його фактичні дозволи:
-
Які репозиторії він може читати?
-
Які він може записувати?
-
Чи може він створювати запити на злиття, змінювати робочі процеси, отримувати доступ до секретів або досягати інших підключених систем?
«Це стане реальною поверхнею атаки для агента, — сказав Авакян. — І якщо ніхто не зможе швидко відповісти на ці запитання, це, ймовірно, перша проблема, яку слід виправити».
Авакян сказав, що до кодувальних агентів слід ставитися як до привілейованих суб’єктів і, де це можливо, надавати їм окремі нелюдські ідентичності, короткотривалі облікові дані та «найвужчі можливі дозволи на репозиторій». Він також рекомендував провести інвентаризацію кожного кодувального агента та кожних облікових даних або з’єднувача, які може використовувати агент, і зіставити його фактичний доступ, а не лише передбачувані дозволи. Це включає виявлення агентів, що діють з успадкованими обліковими даними співробітників або широкими областями дії OAuth.
Але існує момент, коли логічних контролів стає недостатньо, сказав Авакян. «Якщо два фрагменти коду представляють справді різні межі безпеки чи довіри, розміщення їх в одному monorepo може ненавмисно створити непотрібний ризик», — сказав він.
Дізнатися більше на: venturebeat.com