Давайте посмотрим правде в глаза: Vibe-кодирование или использование искусственного интеллекта для помощи в написании кода уже стало реальностью для многих разработчиков. Особенно когда он используется опытным разработчиком в качестве инструмента повышения производительности, он эффективен и может значительно ускорить выполнение определенных задач. Однако делается недостаточно для снижения рисков, связанных со скоростью и дополнительной абстракцией, возникающей при получении инструмента для написания кода за вас.
При просмотре чужой работы (агента ИИ) получить четкое представление о безопасности кода сложнее, чем при проверке собственного кода. Мы видели это на собственном опыте, и это привело к реальным уязвимостям, которые были непосредственно привнесены ИИ. А поскольку это происходит в компании по управлению уязвимостями, в которой работают высококвалифицированные специалисты по безопасности, вы можете гарантировать, что это происходит повсюду.
Vibe: кодирование Honeypot
Чтобы предоставить услугу быстрого реагирования Intrumer, мы начали использовать наши собственные ловушки для обнаружения новых эксплойтов и использования их для написания автоматических проверок, которые защищают наших клиентов.
Публичные отчеты об уязвимостях редко содержат подробную информацию о том, как работает эксплойт, и на ранних стадиях жизненного цикла уязвимости, когда такая информация известна только небольшой группе злоумышленников, наличие реального примера того, как кто-то использует уязвимость, может предоставить ключевые детали, которые мы можем использовать для написания надежных обнаружений, которые не полагаются на то, что система раскрывает номер своей версии.
Чтобы помочь в достижении этой цели, мы решили создать приманку с низким уровнем взаимодействия, которую можно было бы быстро развернуть и имитировать любое веб-приложение, регистрируя запросы, соответствующие определенным шаблонам, для анализа. Мы не смогли найти проект с открытым исходным кодом, который полностью отвечал бы нашим потребностям, поэтому, естественно, вместо того, чтобы начинать трехмесячный спринт, мы написали тестовый код Honeypot с использованием искусственного интеллекта.
Наши приманки с кодом Vibe были развернуты как «уязвимая инфраструктура» в средах, где предполагается компрометация (не связанные с какой-либо конфиденциальной технологией злоумышленника), но мы все же кратко проверили код на предмет безопасности, прежде чем он был запущен.
После тестирования в течение нескольких недель мы заметили кое-что странное: некоторые журналы, которые должны были быть сохранены в каталоге, названном в честь IP-адреса злоумышленника, сохранялись с именем, которое определенно не было IP-адресом:
Уязвимости, созданные искусственным интеллектом
Видение такого рода полезной нагрузки в имени файла, очевидно, вызвало тревогу, поскольку это было признаком использования пользовательского ввода там, где мы ожидали достоверных данных. Еще раз взглянув на код, сгенерированный ИИ, мы обнаружили следующее:
Проницательный пентестер или разработчик должен сразу заметить проблему. Проблема заключалась даже не в плохо документированном поведении Go API или чем-то в этом роде, а в явном поведении (и даже хорошо прокомментированном!). Как мы это пропустили?
Код берет заголовки X-Forwarded-For и X-Real-IP из запроса посетителя и использует их в качестве IP-адреса, если они присутствуют. Эти заголовки предназначены для использования там, где у вас есть внешний прокси-сервер между вашим пользователем и вашим веб-сервером, поэтому вы используете реальный IP-адрес посетителя, а не IP-адрес вашего прокси-сервера, но при их использовании вы должны убедиться, что доверяете им только в том случае, если они отправлены с вашего доверенного прокси-сервера!
Эти заголовки представляют собой данные, контролируемые клиентом, и поэтому являются легкой точкой внедрения для злоумышленников. Посетитель сайта может легко подделать свой IP-адрес или воспользоваться слабостью внедрения, используя эти заголовки в качестве вектора атаки. Это распространенная уязвимость, которую мы часто обнаруживаем при тестировании на проникновение.
В этом случае полезная нагрузка, которую использовал злоумышленник, была вставлена в этот заголовок, отсюда и наше необычное имя каталога. Хотя в нашем случае серьезного воздействия не было и не было никаких признаков полной цепочки эксплойтов, злоумышленник все же получил некоторый контроль над выполнением программы, и ситуация была не за горами. Если бы мы использовали IP-адрес другим способом, это могло бы легко привести к таким уязвимостям, как раскрытие локальных файлов или подделка запросов на стороне сервера (SSRF).
А как насчет статического тестирования безопасности приложений и проверки кода?
Могут ли здесь помочь инструменты статического анализа кода? Мы запустили код Semgrep OSS и Gosec, и ни один из них не сообщил об этой проблеме, хотя Semgrep обнаружил в коде другие потенциальные проблемы. Обнаружить эту уязвимость статическим сканером непросто, поскольку это контекстная проблема. Правило проверки на наличие вредоносных данных может (и некоторые сканеры, вероятно, так и делают) обнаружить использование заголовков в имени файла, но автоматическое принятие решения о том, является ли файл безопасным с помощью списка разрешенных, является сложной проблемой.
Так почему же опытный тестер на проникновение не заметил этого на этапе проверки кода? Мы считаем, что ответ – самоуспокоенность в области автоматизации ИИ.
Самоуспокоенность в области автоматизации ИИ
В авиационной отрасли давно известна концепция, известная как «самоуспокоенность» в автоматизации, снижающая бдительность пилотов. Другими словами, нам гораздо труднее следить за автоматизированным процессом, не допуская ошибок, чем самим избегать ошибок при активном выполнении задачи.
Именно это произошло здесь на этапе проверки кода при проверке кода, написанного ИИ. Человеческий разум по своей природе хочет быть максимально эффективным, и когда кажется, что автоматизация «просто работает», гораздо легче впасть в ложное чувство безопасности и слишком расслабиться.
Однако есть одно ключевое отличие между кодированием Vibe и авиационной отраслью: отсутствие строгих испытаний на безопасность. Там, где пилоты могут слишком расслабиться и позволить автопилоту взять на себя управление, у них есть много лет испытаний и улучшений безопасности, к которым можно прибегнуть. В нынешних условиях это не относится к коду, написанному ИИ, поскольку эта отрасль все еще очень незрела. Уязвимости безопасности находятся всего в одном быстром слиянии с рабочей версией, и на этом пути стоит только внимательный анализ кода.
Не единичный инцидент
Для тех читателей, которые думают, что это, возможно, случайность и случается нечасто, к сожалению, мы наблюдаем такое не впервые. Мы использовали модель рассуждения Gemini, чтобы помочь создать специальные роли управления идентификацией и доступом для облачной среды AWS, которая была уязвима для повышения привилегий. Даже на соответствующий запрос модель ИИ отвечает классическим «Вы абсолютно правы…», а затем снова публикует еще одну уязвимую роль.
Когда у руля стоит инженер по безопасности, готовый тщательно изучить модель, эти проблемы будут обнаружены. Но кодирование Vibe открывает эти задачи для тех, у кого гораздо меньше знаний в области безопасности, поэтому это только вопрос времени, когда мы начнем видеть распространение кода, сгенерированного ИИ. В конце концов, чтобы говорить о своих уязвимостях, нужна прозрачная организация, и еще меньше людей собираются признать, что источником слабости было использование ими ИИ. Это будет не последний раз, когда вы об этом услышите, в этом мы уверены!
ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Дэн Эндрю — руководитель службы безопасности в Intrumer и руководит группами тестирования на проникновение и инженерной безопасности. Его опыт работы в качестве .NET-инженера, тестера на проникновение и консультанта по безопасности. Узнайте больше от Дэна Эндрю
