Исследователи из команды Sand Security обнаружили брешь в платформе Writer — генеративном ИИ-сервисе для корпоративных клиентов, — которая позволяла постороннему человеку без каких-либо предварительных прав захватить контроль над организацией внутри системы. Уязвимость получила название WriteOut. Для атаки хватало одной ссылки и одного клика жертвы.
Самое неприятное в этой истории — полное отсутствие требований к атакующему. Ему не нужно было состоять в той же организации, что и жертва, не нужен был доступ к внутренним ресурсам компании, не требовалось вообще ничего, кроме умения создать агента в собственном аккаунте Writer и заставить кого-то перейти по ссылке. После этого злоумышленник получал шанс на полный захват учётной записи жертвы — с доступом к приватным чатам, документам, конфигурациям агентов, закрытым моделям, коннекторам, учётным данным для LLM и, в зависимости от роли пострадавшего сотрудника, даже к административным функциям.
Механика атаки строилась вокруг функции живого превью, которая работает на базе Writer Framework. Атакующий создавал агента в собственном аккаунте, а затем публиковал ссылку на предпросмотр — обычную вещь для платформы, предназначенную для демонстрации работы агентов коллегам или клиентам. Жертва, будучи уже авторизованным пользователем Writer, кликала по этой ссылке в своём браузере. И вот тут начиналась проблема: браузер автоматически прикреплял к запросу сессионную куки жертвы, а прокси-сервер превью пересылал эту куку прямо в песочницу атакующего.
Дальше всё было делом техники. Код, запущенный внутри контролируемой злоумышленником песочницы, считывал переданный токен сессии и отправлял его на сервер атакующего. Получив токен, оставалось просто воспроизвести его в собственных запросах — и учётная запись жертвы переходила под контроль постороннего человека, причём совершенно из другой компании.
Корень проблемы кроется в самой архитектуре управляемой ИИ-песочницы Writer. Она позволяла собирать сессии, принадлежащие абсолютно разным организациям, и действовать внутри каждой из них от имени реального авторизованного пользователя — без какой-либо изначальной зацепки в целевой среде. По сути, это ломало саму модель разделённой ответственности между провайдером сервиса и клиентом, а заодно и защиту изоляции между разными арендаторами платформы (tenant isolation), на которой держится доверие корпоративных клиентов к облачным сервисам.
В Sand Security подчеркнули: «Посторонний мог перейти от полного отсутствия доступа к захвату любой организации Writer AI внутри ведущих предприятий отрасли, имея на руках лишь ссылку». И добавили формулировку жёстче: «Атакующий может злоупотребить управляемой ИИ-песочницей Writer, чтобы собирать сессии, принадлежащие совершенно разным компаниям, и действовать внутри каждой из них как реальный пользователь — без какой-либо предварительной точки опоры где бы то ни было».
Что любопытно — у Writer действительно были защитные механизмы против подобных атак, и компанию сложно упрекнуть в халатности. Существовала фильтрация на входе, которая должна была блокировать попытки пользователей читать переменные окружения или отправлять явно вредоносный код. Проблема была в том, на что именно смотрели эти проверки. Guardrail анализировал инструкцию, текст запроса, а не то, что код делает во время выполнения.
Именно это и позволило исследователям обойти защиту почти тривиальным способом. Вместо того чтобы вставлять вредоносную нагрузку прямо в запрос — что неминуемо было бы замечено фильтром, — команда просто попросила агента скачать и запустить удалённый скрипт. С точки зрения guardrail-а это выглядело как безобидная просьба «скачай и выполни», ничем не отличающаяся от десятков легитимных сценариев использования агентов. Сама вредоносная логика при этом никогда не появлялась в тексте промпта и потому оставалась полностью невидимой для системы фильтрации.
В Sand Security описали это так: «Writer не был беспечен, защитные механизмы там были. Фильтрация на входе пыталась блокировать попытки пользователей читать переменные окружения или отправлять очевидно вредоносный код. Проблема в том, на что смотрели эти проверки: на инструкцию, а не на поведение во время выполнения». И далее: «Обойти guardrail оказалось довольно просто: вместо того чтобы вставлять полезную нагрузку прямо в запрос, мы просто сказали агенту скачать и выполнить удалённый скрипт. Guardrail увидел безобидный запрос вида «скачай и запусти», а сама логика эксплойта вообще не появлялась в промпте».
На момент публикации отчёта уязвимость уже была устранена. Подробности исследования были предоставлены изданию The Hacker News на эксклюзивной основе, что типично для практики ответственного раскрытия информации о критических брешах в корпоративных ИИ-платформах.
Эта история показывает довольно неприятную закономерность для всей индустрии генеративного ИИ: фильтры, ориентированные на анализ текста запросов, слепы к тому, что код агентов реально делает после запуска. Пока проверки строятся вокруг слов в промпте, а не вокруг реального поведения выполняемого кода, подобные обходы остаются вопросом изобретательности, а не технической сложности.
Самое неприятное в этой истории — полное отсутствие требований к атакующему. Ему не нужно было состоять в той же организации, что и жертва, не нужен был доступ к внутренним ресурсам компании, не требовалось вообще ничего, кроме умения создать агента в собственном аккаунте Writer и заставить кого-то перейти по ссылке. После этого злоумышленник получал шанс на полный захват учётной записи жертвы — с доступом к приватным чатам, документам, конфигурациям агентов, закрытым моделям, коннекторам, учётным данным для LLM и, в зависимости от роли пострадавшего сотрудника, даже к административным функциям.
Механика атаки строилась вокруг функции живого превью, которая работает на базе Writer Framework. Атакующий создавал агента в собственном аккаунте, а затем публиковал ссылку на предпросмотр — обычную вещь для платформы, предназначенную для демонстрации работы агентов коллегам или клиентам. Жертва, будучи уже авторизованным пользователем Writer, кликала по этой ссылке в своём браузере. И вот тут начиналась проблема: браузер автоматически прикреплял к запросу сессионную куки жертвы, а прокси-сервер превью пересылал эту куку прямо в песочницу атакующего.
Дальше всё было делом техники. Код, запущенный внутри контролируемой злоумышленником песочницы, считывал переданный токен сессии и отправлял его на сервер атакующего. Получив токен, оставалось просто воспроизвести его в собственных запросах — и учётная запись жертвы переходила под контроль постороннего человека, причём совершенно из другой компании.
Корень проблемы кроется в самой архитектуре управляемой ИИ-песочницы Writer. Она позволяла собирать сессии, принадлежащие абсолютно разным организациям, и действовать внутри каждой из них от имени реального авторизованного пользователя — без какой-либо изначальной зацепки в целевой среде. По сути, это ломало саму модель разделённой ответственности между провайдером сервиса и клиентом, а заодно и защиту изоляции между разными арендаторами платформы (tenant isolation), на которой держится доверие корпоративных клиентов к облачным сервисам.
В Sand Security подчеркнули: «Посторонний мог перейти от полного отсутствия доступа к захвату любой организации Writer AI внутри ведущих предприятий отрасли, имея на руках лишь ссылку». И добавили формулировку жёстче: «Атакующий может злоупотребить управляемой ИИ-песочницей Writer, чтобы собирать сессии, принадлежащие совершенно разным компаниям, и действовать внутри каждой из них как реальный пользователь — без какой-либо предварительной точки опоры где бы то ни было».
Что любопытно — у Writer действительно были защитные механизмы против подобных атак, и компанию сложно упрекнуть в халатности. Существовала фильтрация на входе, которая должна была блокировать попытки пользователей читать переменные окружения или отправлять явно вредоносный код. Проблема была в том, на что именно смотрели эти проверки. Guardrail анализировал инструкцию, текст запроса, а не то, что код делает во время выполнения.
Именно это и позволило исследователям обойти защиту почти тривиальным способом. Вместо того чтобы вставлять вредоносную нагрузку прямо в запрос — что неминуемо было бы замечено фильтром, — команда просто попросила агента скачать и запустить удалённый скрипт. С точки зрения guardrail-а это выглядело как безобидная просьба «скачай и выполни», ничем не отличающаяся от десятков легитимных сценариев использования агентов. Сама вредоносная логика при этом никогда не появлялась в тексте промпта и потому оставалась полностью невидимой для системы фильтрации.
В Sand Security описали это так: «Writer не был беспечен, защитные механизмы там были. Фильтрация на входе пыталась блокировать попытки пользователей читать переменные окружения или отправлять очевидно вредоносный код. Проблема в том, на что смотрели эти проверки: на инструкцию, а не на поведение во время выполнения». И далее: «Обойти guardrail оказалось довольно просто: вместо того чтобы вставлять полезную нагрузку прямо в запрос, мы просто сказали агенту скачать и выполнить удалённый скрипт. Guardrail увидел безобидный запрос вида «скачай и запусти», а сама логика эксплойта вообще не появлялась в промпте».
На момент публикации отчёта уязвимость уже была устранена. Подробности исследования были предоставлены изданию The Hacker News на эксклюзивной основе, что типично для практики ответственного раскрытия информации о критических брешах в корпоративных ИИ-платформах.
Эта история показывает довольно неприятную закономерность для всей индустрии генеративного ИИ: фильтры, ориентированные на анализ текста запросов, слепы к тому, что код агентов реально делает после запуска. Пока проверки строятся вокруг слов в промпте, а не вокруг реального поведения выполняемого кода, подобные обходы остаются вопросом изобретательности, а не технической сложности.