Вы когда-нибудь задумывались о персональном ИИ-помощнике, который делает всё, что вы пожелаете? Как в фильме Her. Сейчас такая фантазия как будто почти реальна: LLM-агент OpenClaw быстро набирает популярность.
Но как мы предсказывали ещё в прошлом году, LLM-агенты становятся популярным вектором атак. И к уже известным проблемам безопасности OpenClaw недавно добавилась ещё одна, о которой расскажем сегодня.
Когда работаешь с LLM-агентами, легко попасть в ловушку неправильных ожиданий. Кажется, что даёшь агенту простую задачу: посмотри страницу, собери данные, проанализируй. Но на практике вы делегируете не только цель, но и способ её достижения. В этом и проблема.
LLM-агенты принимают решения на основе языковой модели, а действуют с помощью кода, вызовов API или утилит ОС. При слабых ограничениях на действия и доступ к данным агент может повести себя слишком самостоятельно. Такова природа больших языковых моделей: они выдают статистически уместные ответы на основе текущего контекста. Здесь ключевое слово - статистически.
Можно возразить, что существуют тщательно прописанные prompt’ы. Но LLM обучены быть полезными, и если не получается достичь результата описанным способом, они могут искать альтернативные пути решения задачи.
Иногда эти альтернативы разумные. А иногда - выходящие далеко за рамки того, что предполагал пользователь. В частности, действия агента могут приводить к компрометации узла, на котором работает LLM-агент.
Так получилось и в нашем случае: мы проанализировали агента OpenClaw и нашли способ добиться RCE. При посещении специально подготовленной веб-страницы агент OpenClaw выполняет команды оболочки в контексте пользователя, под которым запущен процесс.
В ответ на наш репорт вендор сообщил, что рассматривает описанное поведение как prompt injection, а не дефект агента, и потому не квалифицирует его как уязвимость.
Мы понимаем их позицию, но считаем риск классовым и заслуживающим огласки. Поэтому публикуем минимально необходимые практические меры снижения риска обнаруженной нами атаки:
1. Запускайте OpenClaw в Docker-контейнере, изолировав его от чувствительных данных и инфраструктуры.
2. Ограничивайте инструменты, например, установив подтверждение всех системных команд exec.ask=always.
3. По возможности отключите использование exec.
4. В средах с высокими требованиями к безопасности лучше вообще воздержаться от использования OpenClaw.
Общий вывод: с агентами на базе LLM мы делегируем не только «что сделать», но и «как именно». Без строгих ограничений это чревато неожиданными и опасными последствиями.
Большой технический разбор нашей находки выпустим позже, не переключайтесь.
Но как мы предсказывали ещё в прошлом году, LLM-агенты становятся популярным вектором атак. И к уже известным проблемам безопасности OpenClaw недавно добавилась ещё одна, о которой расскажем сегодня.
Когда работаешь с LLM-агентами, легко попасть в ловушку неправильных ожиданий. Кажется, что даёшь агенту простую задачу: посмотри страницу, собери данные, проанализируй. Но на практике вы делегируете не только цель, но и способ её достижения. В этом и проблема.
LLM-агенты принимают решения на основе языковой модели, а действуют с помощью кода, вызовов API или утилит ОС. При слабых ограничениях на действия и доступ к данным агент может повести себя слишком самостоятельно. Такова природа больших языковых моделей: они выдают статистически уместные ответы на основе текущего контекста. Здесь ключевое слово - статистически.
Можно возразить, что существуют тщательно прописанные prompt’ы. Но LLM обучены быть полезными, и если не получается достичь результата описанным способом, они могут искать альтернативные пути решения задачи.
Иногда эти альтернативы разумные. А иногда - выходящие далеко за рамки того, что предполагал пользователь. В частности, действия агента могут приводить к компрометации узла, на котором работает LLM-агент.
Так получилось и в нашем случае: мы проанализировали агента OpenClaw и нашли способ добиться RCE. При посещении специально подготовленной веб-страницы агент OpenClaw выполняет команды оболочки в контексте пользователя, под которым запущен процесс.
В ответ на наш репорт вендор сообщил, что рассматривает описанное поведение как prompt injection, а не дефект агента, и потому не квалифицирует его как уязвимость.
Мы понимаем их позицию, но считаем риск классовым и заслуживающим огласки. Поэтому публикуем минимально необходимые практические меры снижения риска обнаруженной нами атаки:
1. Запускайте OpenClaw в Docker-контейнере, изолировав его от чувствительных данных и инфраструктуры.
2. Ограничивайте инструменты, например, установив подтверждение всех системных команд exec.ask=always.
3. По возможности отключите использование exec.
4. В средах с высокими требованиями к безопасности лучше вообще воздержаться от использования OpenClaw.
Общий вывод: с агентами на базе LLM мы делегируем не только «что сделать», но и «как именно». Без строгих ограничений это чревато неожиданными и опасными последствиями.
Большой технический разбор нашей находки выпустим позже, не переключайтесь.