282 iOS-приложения с ИИ оказались дырявыми насквозь

Учёные из Университета Уэйк Форест проверили 444 iOS-приложения с большими языковыми моделями и нашли проблемы безопасности у 282 из них. Раскрытые токены, открытые API-ключи и слабая авторизация позволяют посторонним подключаться к серверной инфраструктуре разработчиков и сервисам ИИ. Под удар попали продукты с миллионами установок, а не только мелкие проекты.

К 2025 году приложения с поддержкой LLM суммарно набрали порядка 17 млрд загрузок и формируют около 13% всех установок мобильного софта в мире. Масштаб распространения превратил такие продукты в лакомую цель, а накопленные за пару лет архитектурные привычки разработчиков — в системную дыру.

Стартовая выборка составила более 38 000 программ из App Store. После технической фильтрации в финальный набор попали 444 приложения, где использование языковых моделей подтверждено анализом кода и сетевого трафика. У 282 из них нашлись изъяны, связанные с механизмами доступа к бэкенду и ИИ-провайдерам — почти две трети проверенного.

Стоит обратить внимание на то, что утечка ключей доступа к сервисам ИИ перестала быть единичной ошибкой и превратилась в системный дефект всей экосистемы iOS.

Распределение находок по типам нарушений выглядит так:

• скомпрометированные токены аутентификации у 136 приложений;
• подключение к бэкенду без полноценной проверки личности пользователя у 92 продуктов;
• открыто размещённые API-ключи к сервисам ИИ у 54 программ;
• доступ к системным промптам и инструкциям для управления поведением моделей у 28 приложений;
• комбинированные сценарии, когда у одного продукта сразу несколько типов утечек.

Около 15% уязвимых программ имели больше 1000 пользовательских оценок в App Store, а самое популярное из затронутых — свыше 2,3 млн отзывов. Долю проблемных продуктов авторы оценивают в 26% от всей изученной выборки, и встречаются они одинаково охотно и у инди-разработчиков, и у компаний с миллионами лояльных пользователей.

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

Архитектура бэкенда тоже распределилась неравномерно:

• собственные серверные решения разработчиков — 155 уязвимых приложений;
• облачные платформы Firebase, Google Cloud Run и AWS — 67 приложений;
• прямые обращения к провайдерам ИИ без промежуточного слоя — около 60 программ;
• гибридные схемы с несколькими бэкендами одновременно — десятки случаев пересечения.

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

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

После технического этапа исследователи разослали уведомления всем 282 компаниям, дали 90 дней на устранение проблем и провели повторную проверку. Около 28% разработчиков успешно закрыли дыры — отозвали скомпрометированные ключи, добавили нормальный контроль доступа, переписали клиентские части. Примерно 23% приложений остались уязвимыми и спустя три месяца, причём часть команд вообще не отреагировала на уведомления, а часть столкнулась с архитектурными ошибками, требующими переписывания значительной части продукта.

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

Скорость внедрения ИИ в мобильные продукты заметно опережает зрелость практик безопасной разработки. Команды торопятся выкатить чат-бота, генератор картинок или ассистента, забывая, что ключ к OpenAI или Anthropic в коде клиента — это открытый счёт на чужие токены и потенциальный канал для генерации произвольного контента от имени компании. Дополнительная боль — в том, что многие разработчики искренне не понимают разницы между «спрятать ключ в прокси» и «правильно построить авторизацию пользователя».

Ранее мы писали о том, что исследователи из команды Paradigm Shift обнаружили уязвимость usbliter8 в нескольких поколениях устройств Apple, которую невозможно устранить обновлением программного обеспечения. Проблема затрагивает USB-контроллеры, встроенные в процессоры Apple A12, A13 и ряд родственных чипов, используемых в носимой электронике компании. По словам исследователей, уязвимость находится на аппаратном уровне, поэтому владельцы затронутых устройств не смогут полностью защититься с помощью патчей, а единственным способом избежать риска остаётся переход на устройства с более новыми аппаратными платформами.

Эксперты редакции CISOCLUB уверены, что описанная картина не уникальна для iOS и с высокой вероятностью повторяется в Google Play, причём масштаб там может оказаться больше. Хранение секретов на стороне клиента — антипаттерн, известный десятилетиями, но эпоха генеративного ИИ вернула его в массовую практику под видом «быстрого MVP». Компаниям пора внедрять обязательный аудит ключей перед публикацией билдов, переходить на серверные обёртки с пользовательской авторизацией и ротацией токенов.

Регуляторам стоит присмотреться к категории фитнес- и health-приложений отдельно — там уязвимости пересекаются с обработкой медицинских данных. App Store Review, по нашему мнению, давно перерос рамки проверки UI и должен включать базовые автоматические тесты на наличие захардкоженных секретов в бинарниках.