Ботовете за обслужване на клиенти, задвижвани от изкуствен интелект, получават все повече отговорности в бизнеса, включително достъп до профили на клиенти, данни за фактуриране, входящи пощи за поддръжка, промени в профили и инструменти за възстановяване на суми. Изследването показва, че на атакуващите може да не са им необходими традиционни сканери за уязвимости или директна експлоатация на приложения.
Вместо това те могат да манипулират данните и съобщенията, които даден ИИ агент получава, карайки го да разкрие чувствителна информация или да извърши действия от името на легитимен клиент.
Един от основните рискове е свързан с функциите за транскрипция на чатбота. Много ботове за поддръжка позволяват на потребителите да изпращат копие от разговора по имейл. Атакуващ би могъл да инжектира зловреден текст в чат сесия и да използва функцията за транскрипция, за да създаде фишинг имейл, който изглежда изпратен от доверен адрес за поддръжка.
Ако клиент получи съобщение от support@company.com, е по-вероятно да му се довери, отколкото на обикновен опит за фишинг.
Уязвимостите, свързани с подделата на имейли (email spoofing), могат да влошат проблема. Някои ИИ агенти идентифицират потребителите, като четат видимия заглавен ред From във входящия имейл. Системите за доставка и автентификация на имейли обаче могат да валидират различно поле за изпращач.
Атакуващ би могъл да изпрати имейл, който преминава автентификацията чрез контролиран от него адрес, подтиквайки ИИ системата да свърже съобщението с профила на жертвата.
ИИ ботове, подлъгани да крадат кодове за сигурност
При един от сценариите за атака ИИ агентът за обслужване на клиенти може да получи заявка, която изглежда изпратена от жертвата. След това ботът може да извлече данни за фактуриране, информация за профила или подробности за акаунта.
Ако атакуващият добави своя адрес в полето CC или в полето за отговор, ботът може непреднамерено да изпрати поверителния отговор на атакуващия.
Изследователят по сигурност Inti De Ceukelaire предупреди по време на Bug Bounty Village на DEF CON 34, че тези възможности могат да бъдат използвани за злоупотреба чрез имейл трикове, prompt injection, объркване на идентичността и слаби проверки за автентификация.
Изследването подчертава и рисковете около многофакторната автентификация. Някои ботове изискват еднократен код за достъп, преди да извършат чувствителни промени, като например актуализиране на телефонен номер.
Но слабата нормализация на имейл адреси понякога може да позволи на киберпрестъпниците да нулират лимитите за брой заявки (rate limits), като променят формата на имейл адреса, докато той все още сочи към същата пощенска кутия.
Например различните системи могат да третират коментарите, псевдонимите (алиаси) или необичайното форматиране в имейл адреса по различен начин. Един компонент може да разпознае адреса като принадлежащ на атакуващия.
В същото време друга услуга във фоновия софтуер (backend) може да обработи вградените данни по различен начин и да извлече профила на жертвата. Този тип уязвимост е особено опасен, когато необработени потребителски данни се вкарват директно в API заявки.
ИИ агентите, свързани с входящите пощи за поддръжка, могат също да разкрият кодове за потвърждение на външни акаунти. Атакуващият може първо да изпрати инструкция, предназначена да повлияе на поведението на бота.
След това той може да задейства легитимен имейл за нулиране на парола от друга услуга, като например платформа за социални мрежи, към входящата поща за поддръжка на компанията.
Ако ИИ агентът прочете входящия код и следва предишната злонамерена инструкция, той би могъл да пренасочи или изтекли кода към инфраструктура, контролирана от атакуващия.
Човешкото одобрение не винаги спира тези атаки. Човек оператор и ИИ агент могат да обработят различни версии на един и същ имейл.
Атакуващите могат да използват съобщения с множество части (multipart), скрит HTML, CSS стилове, цитирани отговори или специално форматирани прикачени файлове, за да представят безобидно съобщение пред човек, като същевременно разкриват злонамерена инструкция пред ИИ системата.
Отровяването на базата от знания (knowledge-base poisoning) е друг нарастващ проблем. Агентите за обслужване на клиенти често използват генерация с разширен достъп до информация (retrieval-augmented generation – RAG), за да отговарят на въпроси въз основа на фирмената документация.
Ако уеб ботът (crawler) индексира коментари на общността, потребителски профили или недоверени страници в домейна на компанията, атакуващите могат да поставят фалшиви инструкции или фалшиви кодове за отстъпка, които изкуственият интелект да третира като доверена вътрешна информация.
Организациите, внедряващи ИИ агенти за поддръжка, трябва строго да разделят недовереното съдържание от клиенти от системните инструкции. Те трябва да автентифицират потребителите с потвърдени механизми за контрол на идентичността, обвързани със сесията, да нормализират имейл адресите последователно, да валидират всички заявки към инструменти от страна на сървъра и да предотвратяват изпращането на конфиденциална информация от ботове към непотвърдени получатели.
ИИ агентите трябва да разполагат и с ограничени права. Чатбот, който може да чете имейли, да променя акаунти, да възстановява суми и да осъществява достъп до кодове за потвърждение от трети страни, се превръща в атрактивна цел с висока стойност. Бизнесът трябва да третира ИИ агентите като привилегировани системи за автоматизация, а не просто като интерфейси за разговор.