Изследователи по киберсигурност разкриха подробности за вече коригирана критична уязвимост в сесийната изолация в Writer – корпоративна платформа за генеративен изкуствен интелект (ИИ), която може да доведе до компрометиране между различни наематели (cross-tenant compromise).

Уязвимостта, която се задейства с едно кликване, е наречена с кодовото име WriteOut от екипа за изследване на сигурността на Sand Security.

„Външно лице би могло да премине от нулев достъп до поемане на контрол над всяка организация в Writer AI в рамките на водещи в индустрията предприятия, като използва само една връзка“, споделя компанията за киберсигурност в доклад, споделен с The Hacker News.

Казано по друг начин, недостатъкът може да бъде използван за превземане на акаунта на жертвата в Writer и използването му за достъп до лични чатове, документи и други чувствителни данни, свързани с агенти, конфигурации, частни модели, конектори и идентификационни данни за големи езикови модели (LLM).

Още по-лошото е, че може да бъде използван за завземане на административен контрол в зависимост от ролята на жертвата. Важен аспект на уязвимостта е, че атакуващият и жертвата не трябва да принадлежат към една и съща организация.

Атакуващият може да създаде агент в собствения си акаунт в Writer и да сподели линк за преглед. Това е всичко, което е необходимо за задействане на уязвимостта, което на практика прави възможно отвличането на акаунта на жертва, която кликне върху линка и е вписана със собствената си сесия.

„Атакуващият може да злоупотреби с управляваната пясъчна кутия (sandbox) на Writer AI, за да събира сесии, принадлежащи на напълно отделни компании, и да действа в рамките на всяка от тях като реален потребител, без предварителен достъп където и да е“, казват от Sand Security.

WriteOut също така компрометира модела на споделена отговорност, тъй като нарушава защитите за изолация на наемателите, като се възползва от функцията за преглед на живо на Writer, която позволява на потребителите да преглеждат приложението чрез Writer Framework.

Цялата верига на атаката се развива по следния начин:

  • Атакуващият създава агент с преглед на живо и споделя публичния му линк за преглед.
  • Когато вписан потребител на Writer отвори този линк, неговият браузър прикачва сесийната бисквитка на Writer към заявката.
  • Проксито за преглед изпраща тази бисквитка в пясъчната кутия на атакуващия.
  • Кодът, съдържащ се в контролираната от атакуващия пясъчна кутия, прочита препратения сесиен токен и го ексфилтрира.
  • Атакуващият използва повторно токена и получава контрол над акаунта на жертвата в Writer.

Тъй като атакуващият може да инструктира своя предварително изграден зловреден агент да изпълнява код в контролираната, управлявана пясъчна кутия, става възможно да се прочете паметта на процеса на пясъчната кутия, да се възстанови ексфилтрираният сесиен токен на жертвата и да се предаде на сървър, който той поддържа.

След отговорно разкриване, Writer е отстранил проблема, като е предотвратил напълно препращането на сесийната бисквитка на потребителя в прегледите на пясъчната кутия и ги е преместил в изолиран произход (isolated origin).

„В Writer не са били небрежни, имало е предпазни огради. Филтрирането от страна на входа се е опитвало да блокира потребителите да четат променливи на средата или да изпращат очевидно зловреден код“, казват от Sand Security. „Проблемът е в това какво са проверявали тези проверки: инструкцията, а не поведението по време на изпълнение.“

„Заобикалянето на предпазната ограда беше доста лесно: Вместо да поставяме полезния товар директно, ние просто казахме на агента да изтегли и стартира отдалечен скрипт. Предпазната ограда видя безопасна заявка за „изтегляне и стартиране“ и реалната логика на експлойта изобщо не се появи в подканата (prompt).“