По состоянию на июль прошлого года Apple продала более 800 миллионов устройств, работающих под управлением iOS. Более половины из них — различные модели iPhone. При таком количестве устройств в обращении совершенно не удивительно, что они часто становятся объектами компьютерно-технической экспертизы (forensics). На рынке представлены различные решения для автоматизации подобных экспертиз, но ценник на них зачастую делает их недоступными. Поэтому сегодня мы поговорим о том, как можно провести такую экспертизу с минимальными затратами или, проще говоря, используя бесплатные и/или open source инструменты.
Немного теории
При проведении экспертизы в большинстве случаев подразумевается физический доступ к устройству, и перед экспертом стоят две задачи: извлечь как можно больше данных и информации из устройства и оставить при этом как можно меньше следов (артефактов). Вторая задача особенно важна, если результаты экспертизы представляются в суде: слишком большое количество артефактов может помешать проведению повторной экспертизы, что, в свою очередь, может поставить результаты первоначальной экспертизы под сомнение. Во многих случаях избежать появления артефактов невозможно; эту проблему пытаются решать, подробно документируя артефакты, создаваемые на различных этапах проведения исследования.
Данные, хранящиеся на iOS-устройствах, защищены относительно хорошо, и, чтобы их извлечь, обычно нужно преодолеть следующие препятствия:
- Пасскод. Он защищает устройство от неавторизованного доступа (в том числе и от экспертизы) и криптографически защищает часть данных. Это значит, что даже если пасскод как-то обойти, то некоторые файлы и записи Keychain будут недоступны, потому что устройство не сможет получить соответствующие ключи шифрования, не зная пасскод.
- Связка ключей (Keychain). Это централизованное хранилище паролей, токенов, ключей шифрования и прочих секретов, в котором Apple рекомендует разработчикам приложений держать ценные данные. Физически представляет собой SQLite3-базу, записи в которой зашифрованы и доступ к которой осуществляется опосредованно, через запросы к сервису `securityd`.
- Шифрование файлов. В отличие от систем полнодискового шифрования (full disk encryption, FDE), iOS шифрует каждый файл отдельным ключом (чем-то это напоминает EFS в Windows). Часть файлов защищена ключом, производным от уникального ключа устройства, и может быть расшифрована без знания пасскода, часть защищена таким образом, что расшифровать их без знания пасскода невозможно.
Вместе эти три механизма образуют подсистему защиты данных (Data Protection), которая появилась в iOS 4 и своим появлением существенно усложнила проведение экспертиз. После выхода iOS 4 Data Protection изменялась не очень существенно, за одним исключением — появление Secure Enclave в iPhone 5s и более новых моделях. Secure Enclave используется в рамках Data Protection для операций с отпечатками пальцев, пасскодом, ключами шифрования и подобным, но в данной статье мы его рассматривать не будем.
Извлечение данных
Для извлечения данных из iOS-устройств на практике традиционно применяются несколько методов:
- «Физическое извлечение» позволяет получить побитовый образ диска, все ключи шифрования устройства и, в большинстве случаев, также позволяет перебирать пасскод (если он установлен). Для физического извлечения в общем случае требуется выполнение кода на устройстве в контексте пользователя с полными правами (root) и вне песочницы (sandbox). Этот метод был популярен несколько лет назад, так как уязвимость в загрузчиках старых устройств (таких как iPhone 4 или первые iPad’ы) позволяла выполнять на устройстве произвольный код. На более новых устройствах физическое извлечение возможно (да и то с оговорками) только при наличии jailbreak, поэтому сегодня мы его рассматривать не будем.
- «Логическое извлечение» использует для получения данных интерфейсы и сервисы, которые уже есть на устройстве и которые используются программами вроде iTunes или Xcode. Классическим примером здесь служит создание резервной копии iTunes: для ее создания не нужно устанавливать на устройство никаких дополнительных программ, и при этом она содержит большое количество ценной информации об устройстве (включая список контактов и вызовов, историю переписки, историю местоположений, фото/видео). Но одним только бэкапом дело не ограничивается — на iOS-устройствах присутствуют и другие службы, позволяющие получить доступ к данным.
- Извлечение из iCloud позволяет загрузить резервную копию устройства из облака. Для этого необходимо знать аутентификационные данные настроенного на устройстве Apple ID: Apple ID и пароль либо аутентификационный токен. Резервная копия в iCloud также содержит массу ценной информации.
Спаривание
Когда речь заходит о «логическом» извлечении, то одно из ключевых понятий — это спаривание (pairing) устройства и хоста. В большинстве случаев устройство будет отвечать на запросы только того хоста, с которым оно было спарено ранее (таких хостов может быть больше одного). Запись спаривания (pairing record) состоит из двух частей — одна хранится на устройстве и одна на хосте — и создается при первом подключении устройства к новому хосту. Для создания такой записи необходимо, чтобы устройство было разблокировано (то есть для спаривания в общем случае необходимо ввести пасскод) и чтобы пользователь подтвердил создание записи спаривания на устройстве (начиная с iOS 7; в более ранних версиях запись создавалась автоматически).
Запись спаривания содержит ключи шифрования для всего контента, хранящегося на устройстве, и, следовательно, может быть использована для подключения к устройству и его разблокировки. Другими словами, с точки зрения доступа к зашифрованным данным запись спаривания эквивалентна знанию пасскода: наличие любого из этих двух факторов позволяет разблокировать устройство и получить доступ ко всем данным (в криптографическом смысле).
С практической точки зрения вышесказанное значит, что для логического извлечения в общем случае необходима существующая запись спаривания с одного из доверенных компьютеров или пасскод (чтобы эту запись создать). Без этого большая часть сервисов iOS откажется работать и возвращать данные.
Практика
Для наших экспериментов понадобится виртуальная или физическая машина под управлением Linux. Linux, в принципе, может быть любым, важно чтобы под ним нормально собирались и работали `libusb` и `libimobiledevice`. Я буду использовать Santoku Linux — дистрибутив, созданный в том числе и для проведения исследования устройств под управлением Android и iOS. К сожалению, Santoku Linux содержит не все необходимое, поэтому кое-что «допиливать» все же придется.
Логическое извлечение
Для логического извлечения данных из устройства нам потребуется libimobiledevice — кросс-платформенная библиотека для общения с различными службами iOS. К сожалению, Santoku Linux 0.5 поставляется с устаревшей версией `libimobiledevice` (1.1.5), которая не полностью поддерживает iOS 8, поэтому первым делом установим самую свежую версию (1.1.7) и все ее зависимости (скачиваем архивы по указанным ссылкам, распаковываем, переходим в полученную папку и выполняем `./autogen.sh && make && sudo make install`):
- libplist-1.12;
- libusbmuxd-1.0.10;
- libimobiledevice-1.1.7 — здесь обрати внимание на ключ `--enable-dev-tools`, он включает сборку дополнительных утилит, которые мы в дальнейшем будем использовать для общения с некоторыми сервисами iOS: `./autogen.sh --enable-dev-tools`;
- usbmuxd-1.1.0 — похоже, ключ `--without-systemd` необходим на Santoku 0.5, так как без него usbmuxd не стартует: `./autogen.sh --without-systemd`;
- ideviceinstaller-1.1.0;
- ifuse-1.1.3.
Если все прошло удачно, то теперь самое время подключить какое-нибудь iOS-устройство к компьютеру (или к виртуальной машине) и проверить, что хост его видит:
santoku@santoku-vm:~$ idevice_id -l
23f88587e12c30376f8ab0b05236798fdfa4e853
santoku@santoku-vm:~$
Эта команда должна вывести идентификаторы (UUID) подключенных устройств.
Информация об устройстве
Следующий этап — получение более подробной информации об устройстве. Для этого служит утилита `ideviceinfo`. Она может использоваться в двух вариантах:
- `ideviceinfo –s` выводит общедоступную информацию об устройстве без попытки создать новое или использовать существующее спаривание между хостом и устройством;
- `ideviceinfo [-q <домен>] [-x]` выводит существенно более подробную информацию, но требует наличия спаривания между устройством и хостом. Утилита запрашивает информацию у сервиса `lockdownd`, выполняющегося на устройстве. Информация представляет собой пары ключ — значение и ключи сгруппированы в домены. С помощью параметра `-q` можно задать конкретный домен, из которого требуется получить данные.
Параметр `-x` позволяет форматировать вывод программы в виде XML (а точнее — в виде property list), так что вывод можно перенаправить в файл и в дальнейшем обрабатывать другими программами или скриптами.
Приложения
В рамках логического извлечения можно получить доступ к данным приложений. Для этого сначала необходимо получить список установленных приложений при помощи утилиты `ideviceinstaller`:
santoku@santoku-vm:~$ ideviceinstaller -l
Total: 4 apps
com.viaforensics.viaprotect-app - NowSecure 1
com.facebook.Facebook - Facebook 6017145
ph.telegra.Telegraph - Telegram 39280
com.getdropbox.Dropbox - Dropbox 3.6.2
santoku@santoku-vm:~$
В результате для каждого приложения получаем его идентификатор (так называемый bundle ID), название и версию. Зная идентификатор приложения, мы можем получить доступ к его данным. Для этого задействуются два сервиса iOS — `house_arrest` и `afc`. AFC (Apple File Conduit) — это служба доступа к файлам; с ее помощью, в частности, iTunes осуществляет доступ к музыке и прочим медиафайлам на устройстве. `house_arrest` — это менее известный сервис, который позволяет запускать сервер AFC в песочнице конкретного приложения; он, в частности, используется для реализации функции File Sharing в iTunes.
Но это все теория. На практике для получения доступа к файлам приложения достаточно воспользоваться утилитой `ifuse`:
santoku@santoku-vm:~$ ifuse --container com.getdropbox.Dropbox ~/Desktop/Applications/
santoku@santoku-vm:~$
В результате выполнения этой команды директория с данными приложения будет смонтирована в директории ~/Desktop/Applications:
santoku@santoku-vm:~$ ls ~/Desktop/Applications/
Documents Library StoreKit tmp
santoku@santoku-vm:~$
Отмонтировать данные приложения можно командой `fusermount –u ~/Desktop/Applications`.
Резервная копия iTunes
Бэкап устройства традиционно служит одним из популярных векторов извлечения данных, что неудивительно, учитывая, что бэкап по определению должен содержать массу ценной информации об устройстве и его владельце. Для создания бэкапа можно воспользоваться утилитой `idevicebackup2`:
santoku@santoku-vm:~$ idevicebackup2 backup --full ~/Desktop
Backup directory is "/home/santoku/Desktop"
Started "com.apple.mobilebackup2" service on port 50066.
Negotiated Protocol Version 2.1
Starting backup...
Enforcing full backup from device.
Backup will be unencrypted.
Requesting backup from device...
Full backup mode.
[= ] 1% Finished
Receiving files
....
Received 237 files from device.
Backup Successful.
santoku@santoku-vm:~$
В зависимости от количества контента на устройстве создание резервной копии может занять длительное время (до получаса).
Другая потенциальная проблема, связанная с бэкапами, заключается в том, что они могут быть зашифрованы. Шифрование бэкапов в iOS осуществляется на стороне устройства, поэтому если пользователь защитил бэкап паролем, то все данные, отдаваемые устройством в процессе бэкапа, будут зашифрованы. Пароль можно попытаться подобрать — для этого существуют как коммерческие, так и бесплатные инструменты. Без пароля доступ к содержимому файлов бэкапа невозможен.
По умолчанию `idevicebackup2` сохраняет резервную копию во внутреннем формате iOS, который не вполне подходит для ручного исследования, поскольку, например, вместо имени файла в нем используется значение хеш-функции SHA-1 от пути файла. Преимущество этого внутреннего формата iOS в том, что многие программы знают, как с ним работать, так что для анализа содержимого бэкапа достаточно открыть его в одной из таких программ (например, iOS Backup Analyzer, iBackupBot, или iExplorer).
Если же по каким-то причинам требуется получить бэкап в более «читаемом» формате, то можно воспользоваться командой `unback`:
santoku@santoku-vm:~$ idevicebackup2 unback ~/Desktop
Эта команда создаст на рабочем столе директорию `_unback_`, в которой будет сохранена резервная копия устройства в виде традиционного дерева файлов, а не в виде списка файлов с псевдослучайными именами, как ранее.
Файловая система
Утилита `ifuse` может быть использована и для доступа к файловой системе iOS-устройства. Сразу замечу, что стандартная служба AFC позволяет получить доступ только к содержимому директории `/var/mobile/Media`, в которой хранятся фото- и видеофайлы, фильмы, музыка и прочий медиаконтент. Эта директория может быть смонтирована при помощи команды `ifuse ~/Desktop/Media/`.
Если устройству был сделан jailbreak и установлена служба AFC2, то возможности доступа к файловой системе существенно расширяются. AFC2 — это тот же AFC, только имеющий доступ ко всей файловой системе, а не только к директории `/var/mobile/Media`. Корневая файловая система устройства может быть смонтирована следующим образом: `ifuse --root ~/Desktop/Media/`. Отмонтирование устройства осуществляется, как и в случае с доступом к данным приложений, командой `fusermount –u ~/Desktop/Media`.
FILE_RELAY
File_relay — один из менее известных сервисов iOS, позволяющий в некоторых случаях получать данные, недоступные через другие интерфейсы. Сервис присутствует во всех версиях iOS, начиная с 2.0 (тогда ОС еще называлась iPhone OS), но список доступных данных меняется от версии к версии.
Для извлечения данных через службу file_relay можно воспользоваться утилитой `filerelaytest` (она будет скомпилирована, только если указать параметр `--enable-dev-tools` при конфигурации `libimobiledevice`):
santoku@santoku-vm:~$ filerelaytest
Connecting...
Requesting AppleSupport, Network, VPN, WiFi, UserDatabases, CrashReporter, tmp, SystemConfiguration
Receiving .........................................................................................................
Total size received: 393414
santoku@santoku-vm:~$
Источники `file_relay` в iOS 8
AppleTV Baseband Bluetooth Caches CoreLocation CrashReporter CLTM demod Keyboard Lockdown MobileBackup MobileInstallation MobileMusicPlayer Network Photos SafeHarbor SystemConfiguration Ubiquity UserDatabases AppSuppor t Voicemail VPN WiFi WirelessAutomation MapsLogs NANDDebugInfo IORegUSBDevice VARFS HFSMeta tmp MobileAsset GameKitLogs Device-O-Matic MobileDelete itunesstored Accounts AddressBook FindMyiPhone DataAccess DataMigrator EmbeddedSocial MobileCal MobileNotes
Эта команда выполнит подключение к службе `file_relay` и запросит фиксированный набор «источников» (sources): AppleSupport, Network, VPN, WiFi, UserDatabases, CrashReporter, tmp, SystemConfiguration. Каждый такой источник — это один файл или более с устройства. Полный список источников для iOS 8 приведен во врезке. Для запроса определенного источника достаточно использовать его имя в качестве параметра для `filerelaytest`:
santoku@santoku-vm:~$ filerelaytest Accounts
Connecting...
Requesting Accounts
Receiving ..........
Total size received: 31217
santoku@santoku-vm:~$
Результат (то есть извлеченные данные) будет записан в файл dump.cpio.gz в текущей директории. Его можно распаковать с помощью стандартных утилит `gunzip` и `cpio`:
santoku@santoku-vm:~$ gunzip dump.cpio.gz
santoku@santoku-vm:~$ cpio -idmv < dump.cpio
.
./var
./var/mobile
./var/mobile/Library
./var/mobile/Library/Accounts
./var/mobile/Library/Accounts/Accounts3.sqlite
./var/mobile/Library/Accounts/Accounts3.sqlite-shm
./var/mobile/Library/Accounts/Accounts3.sqlite-wal
./var/mobile/Library/Preferences
./var/mobile/Library/Preferences/com.apple.accountsd.plist
6297 blocks
santoku@santoku-vm:~$
До iOS 8 этот сервис был исключительно полезным и позволял получить данные, недоступные через другие интерфейсы (например, если бэкап зашифрован). Но, начиная с iOS 8, Apple ввела дополнительную проверку: для того чтобы служба `file_relay` работала, на устройстве должен быть установлен специальный конфигурационный профиль, подписанный Apple.
При установке такого профиля в директории `/Library/Managed Preferences/mobile/` будет создан файл `com.apple.mobile_file_relay.plist` со следующим содержанием:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Enabled</key>
<true />
</dict>
</plist>
`file_relay` во время выполнения проверяет наличие этого файла и значение ключа `Enabled` в нем и возвращает данные, только если оно установлено в `true`.
Автоматизация
Один из замечательных аспектов `libimobiledevice` состоит в том, что эта библиотека, помимо готовых утилит для общения с устройством, предоставляет и API для создания своих инструментов. Она содержит, например, привязки для Python, предоставляющие такой же уровень доступа к различным сервисам устройства. Используя этот API, ты можешь достаточно быстро создать именно тот инструментарий, который тебе необходим.
iCloud
Начиная с iOS 5, устройства могут создавать собственную резервную копию в облаке iCloud, а также восстанавливаться из такой копии при первоначальной настройке. Для доступа к данным необходимо знание Apple ID и пароля. Одно из решений с открытым кодом для этого — iLoot. Утилита достаточно проста в использовании, поэтому давать какие-либо пояснения излишне: на вход подается Apple ID и пароль, на выходе — резервные копии, загруженные из iCloud’а. На момент написания статьи iLoot не работает с учетными записями, для которых включена двухэтапная аутентификация.
Заключение
В статье я постарался рассказать о доступных способах извлечения данных из iOS-устройств — способах, не требующих финансовых затрат. За кадром остался такой важный аспект исследования, как анализ извлеченных данных, — эта тема гораздо более обширна и существенно зависит от версии iOS и установленных программ, поэтому раскрыть тему анализа «в общем» представляется труднодостижимым. Тем не менее я надеюсь, что представленный материал оказался интересен и ты узнал из него что-то новое. Happy hacking!
Впервые опубликовано в журнале «Хакер» от 02/2015.
Автор: Андрей Беленко (@abelenko)
Подпишись на «Хакер»
Автор: XakepRU
