Пентестинг приложений iPhone – часть 4

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

Хранилище Sqlite

Sqlite – кроссплатформенная библиотека языка C, в которой реализован самостоятельный, встраиваемый, не требующий предварительной установки движок реляционной БД. База данных Sqlite не нуждается в отдельном серверном процессе – вся база данных с множеством таблиц, триггеров и представлений сосредоточена в одном единственном файле. Sqlite позволяет выполнять все стандартные операции языка SQL, включая Select, Insert, Update, Delete. Будучи переносимой, надежной и легковесной, Sqlite является замечательным решением для долгосрочного хранения данных на iOS-устройствах.

Библиотека Sqlite, поставляющаяся с iOS, реализует легковесный и мощный движок реляционной БД, который легко встраивается в приложение и обеспечивает быстрый доступ к записям базы данных. Поскольку вся БД находится в одном плоском файле, приложения могут с легкостью создавать локальные файлы своих БД и оперировать таблицами и их содержимым. Как правило, приложения iOS хранят в БД Sqlite большие объемы данных со сложной структурой, чтобы оптимизировать скорость их обработки и использование памяти. Движок БД Sqlite, поставляемый с iOS, не имеет встроенного шифрования. Поэтому большинство приложений iOS хранят большое количество конфиденциальных данных внутри файлов Sqlite в открытом виде. Например, приложение Gmail, чтобы обеспечить оффлайновый доступ к почте, хранит все электронные письма в открытом виде внутри БД Sqlite.

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

Файлы Sqlite могут создаваться с произвольным, в том числе пустым, расширением. Чаще всего они имеют расширение .sqlitedb или .db. Далее мы рассмотрим, как можно просматривать эти файлы и восстанавливать удаленные данные на iPhone. Для этой цели я создал демонстрационное приложение под названием CardInfo. CardInfo – самоподписанное приложение, так что оно может быть установлено только на устройстве, подвергшемся джейлбрейку. Приложение спрашивает имя пользователя и пароль, принимая любой ответ, а затем собирает данные о кредитной карте пользователя, сохраняя их в БД Sqlite. Записи базы данных удаляются при выходе из приложения.

Шаги для установки приложения CardInfo:

1. Выполните Jailbreak устройства.
2. Загрузите файл CardInfoDemo.ipa - Ссылка.
3. На Windows-машине загрузите утилиту для настройки iPhone – Ссылка.
4. Откройте утилиту настройки и перетащите в ее окно файл CardInfoDemo.ipa.



5. Подключите iPhone к Windows-машине через USB-кабель. Убедитесь, что подключенное устройство появилось в списке утилиты настройки. Выберите устройство и перейдите на вкладку Applications. В открывшемся списке наряду с уже установленными приложениями должно появиться приложение CardInfo.



6. Щелкните по кнопке Install, соответствующей приложению CardInfo. В результате приложение будет установлено на iPhone.

Шаги для просмотра файлов Sqlite, принадлежащих приложению CardInfo:

1. На подвергшемся джейлбрейку iPhone установите OpenSSH и Sqlite3 из Cydia.
2. На windows-машине загрузите Putty.
3. Подключите iPhone и рабочую станцию к одной сети Wi-Fi. Замечание: Wi-Fi необходим, чтобы подключиться к iPhone по SSH. Если сеть Wi-Fi недоступна, подключитесь к iPhone по SSHчерез USB-кабель.
4. Запустите Putty и подключитесь к iPhone по SSH, введя IP-адрес устройства, логин root и пароль alpine.
5. Перейдите в папку /var/mobile/Applications/ и найдите директорию приложения CardInfo с помощью команды "find . –name CardInfo". На моем iPhone приложение CardInfo установилось в директорию /var/mobile/Application/B02A125C-B97E-4207-911B-C136B1A08687/.



6. Перейдите в поддиректорию CardInfo.app найденной директории (в моем случае – в /var/mobile/Application/B02A125C-B97E-4207-911B-C136B1A08687/CardInfo.app) и найдите файл базы данных CARDDATABASE.sqlite3.



7. Используя команду sqlite3, откройте файл CARDDATABASE.sqlite3. Отметим, что таблица CARDINFO пуста.



Замечание: также можно скопировать файлы Sqlite с iPhone на рабочую станцию по SSH и просмотреть их с помощью утилит Sqlite data browser и Sqlite spy.

8. На iPhone откройте приложение CardInfo и осуществите вход (приложение принимает любую пару логин/пароль).



9. Введите данные кредитной карты и щелкните по кнопке Save. В результате данные кредитной карты попадут в БД Sqlite.





10. Откройте файл CARDDATABASE.sqlite3. Теперь таблица CARDINFO содержит данные кредитной карты.



11. Выйдите из приложения. В результате данные из БД приложения будут удалены.



12. Теперь можно снова открыть файл CARDDATABASE.sqlite3 и убедиться, что таблица CARDINFO опять пуста.

Порядок восстановления данных, удаленных из БД Sqlite программы CardInfo:

Прежде чем записать данные в файл БД, движок Sqlite сохраняет их в журнале, чтобы обеспечить возможность восстановления после системных сбоев. При каждом коммите или прохождении контрольной точки данные из журнала записываются в файл БД. Так что, если после удаления записи из БД не последовало коммита, мы можем легко восстановить удаленные данные из журнала. В iOS для вывода удаленных из БД Sqlite данных можно воспользоваться командой strings. В нашем случае команда "strings CARDDATABASE.sqlite3" выведет удаленные данные о кредитной карте.

Если приложение iOS использует БД Sqlite для хранения временных данных, всегда существует возможность восстановить его удаленные временные данные.

Для повышения безопасности хранимых в БД Sqlite конфиденциальных данных их необходимо явно шифровать. Кроме того, перед удалением записи БД нужно затирать ее содержимое случайными данными. В этом случае, даже если кто-то попытается восстановить удаленные данные из файла БД, он не сможет получить желаемый результат. Наконец, при создании файлов Sqlite следует указывать подходящий уровень доступности.

Cookies.binarycookies

Большинство приложений iOS не спрашивают учетные данные у пользователя при каждом входе. Они создают и хранят куки в файле cookies.binarycookies, расположенном в домашней директории приложения. В ходе тестирования на проникновение исследуйте данный файл на предмет наличия конфиденциальной информации и недостатков управления сессиями. Файл cookies.binarycookies имеет двоичный формат, и его содержимое нельзя прочитать напрямую. Поэтому я написал на Питоне скрипт BinaryCookieReader.py, который может отображать содержимое этого файла в читаемом виде.

Чтение файла Cookies.binarycookies:

1. На Windows-машине загрузите WinScp, Python и BinaryCookieReader.py.
2. Подключите iPhone и рабочую станцию к одной сети Wi-Fi.
3. Запустите WinScp и войдите в iPhone по SSH, введя IP-адрес iPhone, логин root и пароль alpine.
4. Перейдите в папку Library/Cookies внутри домашней директории приложения.
5. Скопируйте файл Cookies.binarycookies на Windows-машину, перетащив его на соответствующую панель.



6. На Windows-машине откройте командную строку и запустите следующую команду для просмотра содержимого файла cookies.binarycookies.
   Python BinaryCookieReader.py [путь к файлу Cookies.binarycookies]

Вот как выглядят куки, созданные iOS-приложением Facebook.

Клавиатурный кэш

Для того, чтобы научиться предугадывать печатаемое пользователем слово, устройства iOS создают локальный клавиатурный кэш, используя функцию Автокоррекции. Данный клавиатурный кэш разработан для автодополнения предсказумых слов. Проблема этой функции в том, что в кэш заносится вся без исключения вводимая пользователем информация. Размер кэша составляет около 600 слов. Кэш расположен в файле Library/Keyboard/en_GB-dynamic-text.dat. Чтобы просмотреть его содержимое, скопируйте по SSH файл en_GB-dynamic-text.dat на компьютер и откройте его в HEX-редакторе. Вот как может выглядеть содержимое этого файла:

Клавиатурный кэш не хранит информацию, введенную в поля, которые были помечены как безопасные (Secure). По умолчанию такую метку имеют пароли и строки, состоящие из одних цифр (ПИН-коды и номера кредитных карт). Таким образом, данные, вводимые в эти поля, не хранятся в клавиатурном кэше. Однако в нем могут храниться данные, вводимые в поля вроде логина или ответа на секретный вопрос. В ходе тестирования на проникновение очистите текущий клавиатурный кэш, выбрав пункт меню iPhone Settings -> General -> Reset -> Reset Keyboard Dictionary (показан на картинке ниже), затем введите данные в текстовые поля и проанализируйте, попадают ли они в клавиатурный кэш или нет.

Чтобы отключить автодополнение для текстового поля в ходе разработки приложения, либо пометьте его как безопасное (пример: mytextField.secureTextEntry = YES), либо отключите автодополнение (mytextField.autocorrectionType = UITextAutocorrectionTypeNo;).

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

Хранилище снимков экрана

При нажатии на кнопку home окно приложения iPhone сжимается и приложение перемещается в фон. Для создания визуального эффекта сжатия iOS делает снимок окна приложения и сохраняет его в папке Library/Caches/Snapshots внутри домашней директории приложения. В результате конфиденциальная информация пользователя может храниться на устройстве без его ведома. Сделанные снимки автоматически удаляются после перезагрузки устройства.

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

При разработке приложения данную проблему можно решить двумя способами.

1. Стирать конфиденциальные данные или выставлять черный фон перед возвратом из функции applicationDidEnterBackground().
2. Вместо скрытия или удаления конфиденциальных данных можно запретить перевод приложения в фоновый режим, выставив свойство "Application does not run in background" в списке свойств приложения Info.plist.

Файловый кэш

Помимо списков свойств, файлов Sqlite, двоичных куки и снимков экрана, приложения iOS могут хранить файлы других форматов вроде pdf, xls, txt и т. д. при просмотре некоторой информации. Например, при просмотре пользователем вложений письма приложение Yandex.Mail сохраняет вложения на устройство до тех пор, пока пользователь не выйдет из приложения. Приложения, которые хранят на устройстве временные файлы, должны очищать их при выходе/закрытии. На данном снимке экрана показана директория attachment приложения Yandex.Mail.

Журналы ошибок

Приложения iOS обычно заносят данные в журнал в целях диагностики проблем или отладки. Кроме того, разработчики нередко используют для отладки функцию NSLog. Данные журналы могут включать в себя запросы, ответы, куки, маркеры аутентификации и другие конфиденциальные данные. Данные, передающиеся в функцию NSLog, записываются в системный журнал Apple (ASL), в котором они сохраняются до перезагрузки. Также журналы ошибок не ограничены песочницей приложения, то есть, записи журнала, сгенерированные одним приложением, могут быть прочтены другим. Поэтому, если приложение заносит в журнал конфиденциальные данные, вредоносное приложение может подхватывать эти данные и отправлять их на удаленный сервер.

Журналы ошибок iPhone можно просматривать напрямую с помощью приложения Console. Данное приложение доступно для скачивания в AppStore. Журналы ошибок также легко просмотреть через утилиту настройки iPhone или в папке CrashReporter при синхронизации устройства через iTunes.

Вернемся к демонстрационному приложению CardInfo. Как уже было сказано, это самоподписанное приложение, поэтому его можно установить только на устройство, подвергшееся джейлбрейку. Приложение принимает любой логин/пароль, а затем запрашивает у пользователя данные о кредитной карте и записывает полученную информацию в журнал.

Действия, необходимые для просмотра журнала ошибок:

1. Установите приложение CardInfo на iPhone.
2. На Windows-машине установите и откройте утилиту конфигурации iPhone.
3. Подключите iPhone к Windows-машине через USB-кабель. Убедитесь, что подключенное устройство перечислено в списке утилиты конфигурации. Выберите его и перейдите на вкладку Console.
4. На iPhone откройте приложение CardInfo и войдите с любым логином и паролем.
5. Введите данные кредитной карты и нажмите на кнопку Save. При этом данные занесутся в журнал ошибок.



6. Теперь данные карты, занесенные в журнал приложением CardInfo, можно увидеть на вкладке Console утилиты конфигурации.

В целях повышения безопасности не заносите в журнал конфиденциальные данные. Также удаляйте отладочные журналы перед публикацией приложения.

Это четвертая часть серии статей о пентестинге приложений iPhone. В пятой части будет рассмотрен анализ приложений iOS во время выполнения.

Ссылки:

1. Debunking NSLog Misconceptions
   http://blog.gdssecurity.com/labs/2012/3/28/debunking-nslog-misconceptions.html
2. What’s in your iOS Image Cache ?
   http://software-security.sans.org/blog/2011/01/14/whats-in-your-ios-image-cache-backgrounding-snapshot
3. Hacking and Securing iOS Applications by Jonathan Zdziarski