Ложная уверенность в самодельной защите

На протяжении последних месяцев я активно использую агентов для написания кода на своем основном ПК и других рабочих станциях. В моем арсенале было использование Claude для координации агентов Codex, успешный опыт очистки «мусора» в моей системе Windows 11 с помощью ИИ, а также неделя экспериментов по определению границ доверия к локальным LLM при работе с моим исходным кодом. Я чувствовал себя в относительной безопасности, полагаясь на самостоятельно написанный защитный барьер (guardrail), призванный предотвращать исполнение любых деструктивных команд. Мне казалось, что система надежна, однако когда я попытался проверить ее на прочность с помощью пятнадцати «грязных» команд, специально разработанных для обхода логики фильтрации, система провалилась почти в половине случаев. Тогда я привлек модель Opus для исправления её собственных уязвимостей, что позволило мне значительно глубже понять природу этих механизмов. Атаки, которые я придумал, вскрыли реальные дыры, хотя и совсем не те, на которые я изначально рассчитывал.

Проблема «черных списков» и ограничения Bash

Все мои первоначальные тесты базировались на ошибочном предположении, что Claude Code всегда будет использовать Bash. Моя первая версия системы защиты представляла собой «черный список» — стандартная процедура для тех, кто действует в спешке. Принцип был прост: разбить каждую команду на фрагменты, сверить их с очевидными угрозами и заблокировать любые совпадения. Это решение, которое быстро пишешь, когда времени в обрез, а создание «белого списка» кажется непосильной задачей. Такой фильтр легко проходит код-ревью, выглядит полезным инструментом и создает у вас фальшивое чувство защищенности. В реальности он не справился почти с половиной моих тестов, став практически бесполезным. Регулярные выражения (Regex) оказались чудовищно сложными для корректной реализации, и такие мелочи, как использование полной версии флага вместо сокращенной, были достаточны, чтобы обмануть блокировку.

Решением стала правильная архитектура: переход на «белый список» инструментов и команд оболочки, которым я доверял, с принудительной блокировкой всего остального. Кроме того, я запретил использование любого инструмента или кода, содержимое которого система не могла прочитать. Это позволило пройти все 15 тестов, но доказало лишь то, что я составил тесты именно под тот результат, который хотел увидеть. Я написал второй набор тестов, который выявил новые проблемы, а при тестировании в тестовой папке я наткнулся на нечто, чего не предсказал ни один из моих сценариев.

Неожиданности среды Windows и PowerShell

Каждый тест исходил из того, что агент будет использовать Bash, поскольку это инструмент, применяемый Claude. Но все тесты ошибались относительно того, какой инструмент выберет агент при работе в терминале Windows. Двенадцать строк логов раскрыли больше, чем целые пакеты атак, и я в очередной раз убедился, что неработающий защитный барьер выглядит точно так же, как и работающий. Я должен был понимать, что нельзя просто доверять средствам защиты: я проверяю свои системные резервные копии ровно по той же причине — они не существуют, пока их не протестируешь. Потребовалось несколько запусков тестового пакета, чтобы осознать необходимость логирования действий защиты. Как только логи появились, я увидел реальную картину: Claude Code в Windows предпочитает PowerShell, а не Bash. Угадайте, какой инструмент мои правила не блокировали? Второй момент: я блокировал безобидную команду — обычную идиому оболочки для перенаправления вывода ошибок: одиночный амперсанд.

В логах было заметно нечто еще более странное. Я наблюдал, как агент отказывался от выполнения деструктивной команды, и ошибочно принял это за доказательство работы своей защиты. Это было не так: агент просто решил не использовать эту команду до обращения к оболочке, поэтому мой хук-перехватчик даже не был вызван. Хуже того, в тот момент сама защита была установлена некорректно. В этом и заключается коварство защитных слоев: когда они работают как задумано, это ничего не показывает, но так же ведет себя и сломанная система. Я снова атаковал исправленную версию, и она сломалась уже по-новому.

Инструменты как лазейки и творческий подход агентов

Худший обход защиты произошел из-за правила, которое я сам же и внедрил. После фиксации оболочки я попросил агента проверить отклик сайта. Команда сработала, и показалось, что защита не сработала. На самом деле она сработала корректно, просто затронула инструмент, который я явно разрешил — встроенный утилитарный инструмент fetch. Когда я писал защиту, я разделил функции на два типа: команды оболочки с сетевым доступом и инструменты с доступом к диску. Fetch классифицировался как инструмент, не меняющий файлы, поэтому его не спрашивали о сетевом доступе. Я установил сложную систему сигнализации, но оставил заднюю дверь открытой. Агенту достаточно было просто проявить находчивость, чтобы использовать весь пакет инструментов и получить доступ к сети. Claude обошел мои барьеры, создав файлы PowerShell. Я не учел этот сценарий в модели угроз, ожидая, что Claude Code будет пробовать выполнить команды напрямую. Я исправил утилиту fetch, запустил тест снова, и агент совершил невероятно хитрый маневр: он не смог запустить команды инлайново, поэтому просто записал ту же команду в файл скрипта и запустил его. У меня есть давнее правило в файле CLAUDE.md, гласящее, что все длинные команды следует сохранять в файлы-скрипты, так как они лучше читаются и пригодны для повторного использования. Это отличное правило, я не собираюсь его удалять, но буду относиться к нему осторожнее. Это стало обходом моего защитного хука, так как он блокирует только команды, но не читает содержимое файлов. Как только скрипт оказался в файле, он стал невидимым для защиты. Большая часть разработки выглядит именно так: код живет в файлах, от сборок и пакетных скриптов до CI-конфигураций. Любая инженерная практика — это кодификация скриптов в файлы, и ни одна из моих атак не нашла бы эту уязвимость.

Итоги: проверка важнее доверия

Я не считаю свой эксперимент провалом: он выявил одиннадцать реальных уязвимостей в двух версиях Claude Code и научил меня важным вещам о скоупинге. Теперь этот тестовый набор будет запускаться каждый раз при добавлении новых инструментов в «белый список», потому что я уверен — они снова найдут способ обойти защиту. Тестовый пакет хорош лишь тем, что находит то, до чего я додумался, а все, что он пропустил, было тем, что я упустил в своих исследованиях: системная утилита, о которой я забыл, стандартный редирект, встроенная функция и даже то, что я сам написал для удобства. Тестируйте, верифицируйте и постоянно итерируйте свои протоколы безопасности.

Источник: xda-developers.com