ИИ как хакер

Девять лет назад только что появившаяся на рынке компания Solar Security предложила протестировать свой новый сканер уязвимостей Solar inCode, проверяющий написанные на языках Java, PHP, Objective C, Java for Android онлайн- и мобильные приложения. Анализ проводился по общедоступному коду, методом «белого» ящика, что позволяло проверить внутреннюю структуру программы и проанализировать логику ее работы. Разрешалось сканировать мобильные приложения любых банков, запрещалось забирать с собой из офиса программу и результаты исследования, а в написанной по итогам тестирования статье называть конкретные банки.

Результат впечатлил — уязвимости нашлись во всех приложениях, различались только критичность и сложность их использования для хакеров. Банковские программисты больше думали о полноте функционала, чем о безопасности, зачастую использовали программы open sourcе, не меняя настроек по умолчанию. В одном банке из первой десятки мобильное приложение было уязвимо даже для опасной атаки «человек посередине» (man-in-the-middle), когда злоумышленник незаметно перехватывает и изменяет коммуникацию между банком и клиентом.

С тех пор подходы к безопасности разработки, процессы оценки и управления уязвимостями (Vulnerability Management/Assessment) сильно изменились. Сканеры стали интегрировать в системы управления рисками, патч-менеджмента, платформы по управлению инцидентами (Incident Response Platform), процессы безопасной разработки (Security Development) и SIEM. Все это повысило возможности защиты.

Но и хакеры тоже начали использовать автоматические средства выявления уязвимостей — различные системы для сканирования сети, перебора паролей, поиска неустановленных патчей и небезопасных версий ПО. Теперь они имеют возможность искать установленные по умолчанию учетные записи, открытые порты, небезопасные службы и другие уязвимые места в информационных системах.

В интернете большинство систем взаимодействия пользователя с поставщиком контента состоит из интерфейса веб-сайта (или мобильного приложения на смартфоне) и серверной части, как правило, удаленного сервера. Зачастую этот сервер, связанный (через демилитаризованную зону) с основной сетью предприятия, содержит конфиденциальную информацию.

Обычно эксплойт (программный код, данные или команда, которые служат для атаки на уязвимость в компьютерной системе) во внешнем интерфейсе выполняется путем использования небезопасных настроек браузера (часто из-за ошибок безопасности в логике внешнего интерфейса). Например, при атаке с помощью межсайтового скриптинга (XSS) злоумышленник внедряет на веб-страницу или веб-приложение зловредный скрипт, выполняемый в браузере пользователя. 

Серверные эксплойты часто связаны с использованием злоумышленником ошибок в серверной логике. Например, почти все интерфейсы взаимодействуют с серверной базой данных. Атака SQL-инъекцией основана на возможности пользователя напрямую отправлять команды в базу данных, выполняя во внешнем интерфейсе такие действия, как отправка форм.

Если на веб-сайте используется неограниченная дополнительными условиями форма для получения имени пользователя и пароля, то простейший вариант атаки — введение нарушителем при входе в систему на веб-сайте в форме любого имени пользователя, например, «Иванов» и всегда справедливого утверждения «1 = 1»: «Иванов OR 1 = 1». Аналогично в поле «пароль»: «Иванов OR 1 = 1». При отсутствии дополнительных ограничений нарушитель окажется в системе, так как условие проверки выполняется.

При более сложном запросе, воспринимаемом системой как SQL-запрос к базе данных, нарушитель может получить сведения о данных легальных пользователей. Кроме того, большинство баз данных поддерживают пакетную инструкцию SQL — группу из двух или более инструкций SQL, разделенных точкой с запятой (SQL Union). Так что при плохой защите хакер сможет изменить или удалить таблицы базы данных жертвы.

Сканеры уязвимостей и другие автоматизированные системы упростили жизнь хакерам, но процесс взлома сайта по-прежнему остается трудоемкой работой, требующей больших человеческих ресурсов. Но сегодня у злоумышленников появилась возможность прибегнуть к помощи переживающих бум технологий искусственного интеллекта. Причем, как показало исследование, проведенное недавно в Корнеллском университете, использование современных больших языковых моделей (LLM) позволяет осуществить взлом без участия человека.

Современные LLM, такие как GPT-4, могут читать документы, в частности, инструкции по проведению разных видов атак. Кроме того, вызывая те или иные функции, они способны использовать нужные для взлома инструменты, а затем повторно вводить запросы. Новый функционал позволяет LLM действовать автономно в качестве агента, т.е. системы, анализирующей проблему, создающей план ее решения и выполняющей его с помощью набора инструментов.

Помимо LLM, при построении LLM-агента исследователи из Корнеллского университета использовали инструмент для автоматизации тестирования веб-приложений Playstage (Playwright), предоставляющий API для управления браузерами, такими как Chromium, Firefox и WebKit. Для запуска команд (например, Client for URL для передачи данных с использованием различных сетевых протоколов) агенту открыли терминальный доступ. Кроме того, LLM-агент мог работать с интерпретатором Python.

LLM-агент использовал подход RAG (Retrieval-Augmented Generation), расширяющий возможности модели за счет подключения специализированной базы знаний из шести документов, в которых обсуждался взлом веб-сайтов и давались подробные инструкции по взлому. 

Планирование осуществлялось с помощью API-интерфейса Assistants из OpenAI. Для запуска самого агента использовался фреймворк LangChain, поддерживающий вызов API OpenAI и выполнение функций.

Исследователи протестировали сайты с 15 уязвимостями (см. таблицу), начиная с простых SQL-инъекций и заканчивая сложными взломами, требующими как межсайтового скриптинга, так и подделки межсайтовых запросов (CSRF).

LLM-агенту не сообщалось, какая уязвимость имеется на указанном исследователями сайте — он должен был самостоятельно разобраться и провести атаку. Атака считалась успешной, если укладывалась в 10 минут — предел для API-интерфейса OpenAI assistant.

Лучший результат — 73,3% успешных атак — показал агент на базе GPT-4. При успешных сложных взломах количество вызовов функций достигало 48.

После взлома сайтов исследователи анализировали действия LLM-агента. Оказалось, что при проведении, например, сложной атаки SQL Union LLM-агент выполнял следующие действия: 

Если атака через одну уязвимость оказывалась безуспешной, агент пробовал атаковать через другую. Возможность успешных атак на реальные сайты подтвердило ограниченное тестирование агента в интернете. 

К счастью, большинство веб-сайтов либо статичны, либо созданы на основе защищенных шаблонов. Так что оснований для паники нет. Во всяком случае, если у вас не совсем уж запущенный в плане безопасности сайт. Успокаивает и то, что результативный агент использовал проприетарный GPT-4, а атаки агентов на основе LLM с открытым кодом успеха пока не имели.

Но это пока. Поэтому встает вопрос, можно ли более продвинутые модели отдавать в открытый доступ. Также не решено, как ограничить LLM в создании несущих угрозы систем (сканеров уязвимостей, агентов, вирусов). Как обеспечить выполнение регуляторных и этических требований к ИИ?

С другой стороны, LLM-агента можно использовать как «белого хакера» для пентеста своих систем защиты, как своего рода дешевый вариант багбаунти. ИИ — оружие обоюдоострое, борьба «снаряда и брони» продолжится.

Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!