Разработчики мобильных приложений зачастую сталкиваются с необходимостью хранить конфиденциальные данные пользователя на пользовательском устройстве. Это могут быть, например, номер кредитной карточки или аутентификационные данные. В этой статье мы поговорим о типичных ошибках реализации хранения конфиденциальных данных с точки зрения информационной безопасности на примере мобильной платформы iOS.
Обычно настройки приложения хранятся в конфигурационных файлах. Библиотека Cocoa Touch, используемая при разработке приложений для мобильной платформы iOS, предоставляет слой абстракции для хранения настроек приложения в классе NSUserDefaults. Класс NSUserDefaults реализует нелюбимый многими шаблон проектирования «Одиночка» (более известный как Singleton), предоставляя доступ к интерфейсу над стандартным конфигурационным файлом приложения.
Стандартный файл конфигурации приложения располагается в его домашней директории по относительному адресу Library/Preferences/<your.company.name>.<app.name>.plist. Как и другие файлы, расположенные в «песочнице», он не доступен на чтение для других приложений пользовательского уровня. Исключения составляют устройства, подвергнутые модификациям политики безопасности системы (jailbroken-устройства).
Многие разработчики по достоинству оценили удобство работы с классом NSUserDefaults. Подавляющее число приложений используют его для хранения внутренних настроек и/или настроек пользователя. К сожалению, удобство использования редко коррелирует с безопасностью. Хранение конфиденциальных данных пользователя в стандартном файле настроек является типичной ошибкой разработчиков, приводящей к утечке пользовательской информации.
В результате исследования исходного кода Приложения А на наличие ошибок в контексте информационной безопасности было выявлено, что приложение сохраняет данные аутентификации пользователя в конфигурационном файле настроек. Загрузив Приложение А на iPad под управление оригинальной операционной системы iOS версии 6.1.3, мы прошли стадию аутентификации и принялись за исследование файла настроек приложения.
Рис. 1. Загрузка приложения на iPad
Для демонстрации уязвимости мы использовали приложение iExplorer, доступное для операционных систем семейств Windows NT и Mac OS X. Приложение iExplorer представляет собой графический файловый менеджер для устройств под управлением iOS. Находим Приложение А в списке установленных приложений и открываем Library/Preferences/<settings-name>.plist на чтение.
Рис. 2. Внешний вид приложения iExplorer c доступом к нужному файлу
Рис. 3. Конфигурационный файл с конфиденциальной информацией
Вполне очевидным представляется факт, что те же самые действия может осуществить злоумышленник с целью несанкционированного доступа к конфиденциальной информации. Более того, процесс извлечения файла настроек приложения может быть автоматизирован во вредоносных приложениях, исполняющихся на компьютере пользователя или на jailbroken-устройствах.
Рассмотрим другой пример неправильного использования стандартного файла настроек приложения. В результате исследования исходных кодов другого приложения, скажем, Приложения Б, было выявлено, что данные аутентификации пользователя хранятся в конфигурационном файле в зашифрованном виде. Для шифрования данных используется композиция алгоритма симметричного шифрования AES256 с постоянным ключом алгоритма кодирования Base64.
На первый взгляд, такой подход может показаться вполне разумным. Кажется, что перехват злоумышленником шифрованной информации мало что даст. Однако на самом деле у злоумышленника существуют, как минимум, два способа использовать полученные данные.
1. Подмена конфигурационного файла. Осуществив подмену конфигурационного файла, злоумышленник получает частичный либо полный доступ к конфиденциальным данным пользователя.
2. Распознавание алгоритма шифрования и извлечение ключа.
Если в первом случае недостаток используемого алгоритма очевиден, то во втором случае требуется оценить сложность такого взлома. Установим Приложение Б на устройство под управлением операционной системы iOS и выгрузим образ приложения. Поскольку образ приложения обычно частично или полностью зашифрован, его предварительно необходимо расшифровать. Используя отладчик, выгружаем образ приложения из памяти и правим бинарный образ приложения, заменяя дешифрованные сегменты. Подробное описание этого процесса выходит за рамки статьи, упомянем лишь, что существуют средства автоматической дешифровки бинарных образов приложений в формате Mach-O.
Следующим шагом станет дизассемблирование бинарного образа приложения. Для этого воспользуемся интерактивным дизассемблером IDA Pro. Попробуем поискать строчку password в секции __cfstring и попросим дизассемблер показать перекрестные ссылки.
Рис. 4. Работа с дизассемблером IDA Pro
Перейдем в подпрограмму -[Preferences setPassword:]. IDA Pro и тут не подвела: сделала за нас всю работу.
Рис. 5. Ассемблер бинарного образа
Не нужно быть гуру архитектуры ARM, чтобы понять, что здесь происходит. По смещению 0x0000DDCC пароль пользователя кодируется Base64, а по смещению 0x0000DDE6 шифруется AES256 с ключом TheSuperSecretKey (в реальном приложении применялся другой ключ шифрования).
Итак, алгоритм шифрования вместе с ключом могут быть скомпрометированы злоумышленником даже не очень высокого уровня квалификации менее чем за 10 минут. При наличии этих знаний злоумышленник может получить несанкционированный доступ к конфиденциальной информации пользователя и автоматизировать процесс сбора данных пользователя.
Рекомендации по устранению таких уязвимостей могут быть следующие:
- Используйте связки ключей (Key Chains) для хранения конфиденциальных данных. К элементам связки ключей могут быть применены различные уровни доступа, и они могут быть защищены от переноса на другое устройство.
- Применяйте шифрование к элементам связки ключей. На устройствах, к которым был получен несанкционированный привилегированный доступ, злоумышленник может просмотреть все элементы связки ключей. Для этого достаточно создать приложение с доступом ко всем группам доступа к связке ключей или к группе com.apple.keystore.access-keychain-keys.
- Используйте алгоритмы динамической генерации ключа шифрования, уникального для каждого пользователя.
- Пишите средства защиты на чистом языке C. Рассмотрите использование встраиваемых функций или воспользуйтесь макросами.
- Не храните конфиденциальные данные на пользовательском устройстве.
Автор: Daniil_Chernov
