Чему нас научила приманка, созданная искусственным интеллектом
«Вибрационное кодирование» — использование моделей искусственного интеллекта для написания кода — стало частью повседневной разработки для многих команд. Это может значительно сэкономить время, но также может привести к чрезмерному доверию к коду, сгенерированному ИИ, что создает уязвимости в системе безопасности.
Опыт злоумышленника служит примером того, как код, сгенерированный ИИ, может повлиять на безопасность. Вот что произошло и на что следует обратить внимание другим организациям.
Когда мы позволили ИИ помочь в создании приманки
Чтобы предоставлять услугу быстрого реагирования, мы создали приманки, предназначенные для сбора данных о попытках взлома на ранних стадиях. Для одного из них мы не смогли найти вариант с открытым исходным кодом, который делал бы именно то, что нам нужно, поэтому мы сделали то, что в наши дни делают многие команды: использовали ИИ для разработки прототипа.
Он был развернут как намеренно уязвимая инфраструктура в изолированной среде, но мы все равно провели быструю проверку кода, прежде чем внедрять его.
Несколько недель спустя в журналах начали появляться странные записи. Файлы, которые должны были храниться под IP-адресами злоумышленников, вместо этого содержали строки с полезной нагрузкой, что указывало на то, что вводимые пользователем данные попадали не туда, куда нужно.
Уязвимость, о которой мы не подозревали
При более тщательном изучении кода стало понятно, что происходит: ИИ добавил логику для извлечения IP-заголовков, предоставленных клиентом, и использования их в качестве IP-адреса посетителя.
Это безопасно только в том случае, если заголовки поступают с контролируемого вами прокси-сервера; в противном случае они фактически находятся под контролем клиента.
Это означает, что посетитель сайта может легко подменить свой IP-адрес или использовать заголовок для внедрения полезных данных. Эту уязвимость мы часто обнаруживаем при тестировании на проникновение.
В нашем случае злоумышленник просто поместил полезную нагрузку в заголовок, что объясняет необычные имена каталогов. Последствия были незначительными, и не было никаких признаков полной цепочки эксплойтов, но злоумышленник получил возможность влиять на поведение программы.
Всё могло быть гораздо хуже: если бы мы использовали IP-адрес другим способом, та же ошибка могла бы легко привести к раскрытию локальных файлов или подделке запросов на стороне сервера.
Почему SAST не заметил этого
Мы запустили Semgrep OSS и Gosec в коде. Ни один из них не обнаружил уязвимость, хотя Semgrep сообщил о нескольких не связанных с ней улучшениях. Это не ошибка инструментов, а ограничение статического анализа.
Для обнаружения этой конкретной уязвимости требуется понимание контекста: IP-заголовки, предоставленные клиентом, использовались без проверки, и не было установлено никаких границ доверия.
Этот нюанс очевиден для пентестера-человека, но его легко упустить, если рецензенты слишком доверяют коду, сгенерированному ИИ.
Самоуверенность в автоматизации с помощью ИИ
В авиации хорошо известна идея о том, что контроль за автоматизацией требует больше когнитивных усилий, чем выполнение задачи вручную. Похоже, что здесь наблюдается тот же эффект.
Поскольку код не был нашим в прямом смысле этого слова — мы не писали эти строки сами, — наше представление о том, как он работает, было не таким чётким, и проверка была затруднена.
Однако на этом сходство с авиацией заканчивается. Системы автопилота разрабатывались десятилетиями с учётом требований безопасности, в отличие от кода, сгенерированного ИИ. Пока не существует установленного запаса прочности, на который можно было бы положиться.
Это был не единичный случай
Это был не единственный случай, когда ИИ уверенно выдавал небезопасные результаты. Мы использовали модель рассуждений Gemini для создания пользовательских ролей IAM для AWS, которые оказались уязвимыми для повышения привилегий. Даже после того, как мы указали на проблему, модель вежливо согласилась и выдала ещё одну уязвимую роль.
Чтобы прийти к безопасной конфигурации, потребовалось четыре итерации. Модель ни разу самостоятельно не распознала проблему безопасности — на протяжении всего процесса требовалось вмешательство человека.
Опытные инженеры обычно выявляют такие проблемы. Но инструменты разработки с использованием ИИ упрощают процесс написания кода для людей, не имеющих опыта в сфере безопасности, и недавнее исследование уже выявило тысячи уязвимостей, возникающих из-за таких платформ.
Но, как мы показали, даже опытные разработчики и специалисты по безопасности могут не заметить ошибок, если код создан с помощью модели ИИ, которая на первый взгляд выглядит надёжной и работает правильно. А конечные пользователи никак не могут определить, содержит ли программное обеспечение, на которое они полагаются, код, сгенерированный ИИ, что возлагает всю ответственность на организации, распространяющие этот код.
Выводы для команд, использующих ИИ
Как минимум, мы не рекомендуем поручать написание кода с помощью ИИ тем, кто не является разработчиком или специалистом по безопасности.
И если ваша организация разрешает экспертам использовать эти инструменты, стоит пересмотреть процесс проверки кода и возможности CI/CD-обнаружения, чтобы убедиться, что этот новый класс проблем не останется незамеченным.
Мы ожидаем, что со временем уязвимости, связанные с искусственным интеллектом, будут возникать всё чаще.
Лишь немногие организации открыто признают, что проблема возникла из-за использования ими ИИ, поэтому масштаб проблемы, вероятно, больше, чем сообщается. Это не последний подобный случай, и мы сомневаемся, что он единичный.
Редактор: AndreyEx
