Как взламывают iCloud. Разбираемся в системах резервного копирования iPhone и iPad

Содержание статьи

• Apple iOS
• Облачные бэкапы — это безопасно?
• Безопасность — это удобно?
• А если без облака?
• Резервные копии в iTunes: с паролем или без?
• Наши рекомендации
• Исследуем iCloud: как это устроено
• Можно ли извлечь данные, защищенные securityd?
• Заключение

О резервном копировании не говорит только ленивый, но мало кто следует рекомендациям специалистов. С резервным копированием данных с компьютера все более-менее понятно. А как с этим обстоят дела на мобильном фронте? Как с этой задачей справляются смартфоны, планшеты и прочие, более экзотические устройства под управлением Apple iOS, Google (и не Google) Android, мобильных и стационарных сборок Microsoft Windows и BlackBerry 10? В новом цикле публикаций мы расскажем, как вытащить данные, куда сохранить, как восстановить, как обеспечить безопасность и как взломать.

Сегодняшняя «серия» будет посвящена резервным копиям iOS, в следующей мы посмотрим, как работает и как ломается система бэкапов Android, а на закуску оставим Windows Phone и BlackBerry 10. Сразу предупредим, что статья разбита на две части: в первой мы попробуем выяснить, так ли безопасны бэкапы iOS и стоит ли им доверять, вторая же посвящена изучению внутреннего устройства бэкапа iCloud и извлечению данных из него, что называется, голыми руками, без помощи специальных инструментов.

Apple iOS

Начиная с iOS 5 пользователи яблочных устройств получили возможность автоматического сохранения данных устройства в облако. В старых версиях iOS эту возможность нужно было активировать вручную, но в последних она стала предлагаться в качестве опции по умолчанию. В iOS 9 облачные копии хранятся уже не в iCloud, а в более универсальном iCloud Drive.

К слову, бесплатно в iCloud доступно всего 5 Гбайт, которых, однако, хватает для хранения данных приложений и настроек даже устройств с 64 Гбайт на борту. Для тех пользователей, которые хотят сохранять в облаке много фотографий и видеороликов, Apple предлагает варианты платной подписки. Включить облачное резервное копирование можно при активации аппарата или в любое время в настройках устройства (Settings -> iCloud -> Backup).

После активации настройки резервного копирования в облако происходит следующее. Ты возвращаешься домой (или в любое другое место, где есть известная телефону сеть Wi-Fi) и ставишь устройство на зарядку. В это время телефон (или планшет, или iPad) автоматически соединяется с облаком и сливает в него накопленные за день инкрементные изменения. Разумеется, если копирование делается впервые, то в облако закачиваются все данные — процесс небыстрый и потребляющий заметное количество трафика. Резервное копирование запускается не чаще, чем раз в сутки. При необходимости его можно выполнить и вручную (командой Back Up Now).

А как обстоят дела с восстановлением данных? Это тоже просто. Непосредственно при активации нового (или старого, после сброса настроек) устройства можно выбрать, из какой резервной копии восстанавливать данные. Причем ни модель, ни версия операционной системы большой роли не играют: на новый iPad можно восстановить данные из старого iPhone, и наоборот. Работает это все действительно очень удобно. Поехал ты, скажем, в отпуск и потерял телефон. Завернул в ближайший Apple Store, активировал новый iPhone, и все настройки, приложения, контакты, журналы звонков, фотографии и даже обои и расположение иконок — все восстановится само по себе «по воздуху».

Облачные бэкапы — это безопасно?

Обрати внимание на знак в конце заголовка. Безопасность облачных резервных копий iOS под большим вопросом, ответ на который, впрочем, хорошо известен.

Итак, первое и главное: облачные резервные копии шифруются. Второе и не менее главное: ключ шифрования хранится рядом с зашифрованными данными, и достать его не составляет никакого труда. Шифрование, таким образом, защищает данные только в момент их передачи между устройством и сервером, а вот дальше… дальше ни у Apple, ни у спецслужб не возникает ни малейших проблем с доступом к твоим данным.

А что насчет злоумышленников? Тут несколько сложнее, ведь для доступа к облачной копии потребуется как минимум узнать Apple ID и пароль пользователя. Впрочем, небольшой фишинг или социальный инжиниринг — и пароль от Apple ID у нас в кармане. Дальше дело техники: ставим Elcomsoft Phone Breaker, вводим ID и пароль — и вуаля! Данные пользователя у нас в кармане.

Именно этот способ был использован для воровства фотографий знаменитостей. Нет, так не годится!

И действительно, никуда не годится. В результате в Apple в спешном порядке разработали механизм двухфакторной аутентификации (на тот момент — two-step verification), который существенно затруднял дело злоумышленникам, получившим пароль от учетной записи Apple ID. При активации этого механизма для доступа к резервной копии iCloud требовалось ввести не только логин и пароль, но и одноразовый код, который можно было получить на доверенное устройство через push или в виде СМС на доверенный телефонный номер.

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

Если же злоумышленник получал доступ к компьютеру пользователя, то у него появлялся шанс и вовсе пройти мимо всей и всякой защиты — логинов, паролей и кодов. Достаточно было всего лишь извлечь двоичный маркер аутентификации с компьютера, на котором была установлена (и активирована) программа iCloud for Windows. Дальнейшее — дело техники: маркер вводится в Elcomsoft Phone Breaker, резервные копии скачиваются, а логин, пароль и одноразовый код не нужны.

Как на это отреагировали в Apple? Довольно оперативно: срок жизни маркера аутентификации iCloud уменьшили с нескольких месяцев до считаных часов. Правда, есть тонкость: в iOS 9, как мы уже писали, резервные копии сохраняются не в iCloud, а в iCloud Drive, для которого маркеры аутентификации и поныне действуют очень и очень долго.

А как обстоят дела с паролями сайтов, социальных сетей и учетных записей? Тут все не так однозначно. Если восстанавливаешься из облачной копии на то же самое устройство, то все будет в порядке: устройство восстановится и заработает как ни в чем не бывало. Если же восстанавливается другое устройство, то ситуация будет в точности такая, как с локальным бэкапом без пароля: все пароли из keychain (включая пароли от Wi-Fi, почты, социальных сетей) восстановлены не будут. И не только они. Многие приложения хранят данные в keychain с опцией this device only — «только на этом устройстве». В первую очередь это относится к утилитам хранения паролей, различным программам для хранения документов и подобным.

Как ФБР могло бы получить данные с iPhone стрелка из Сан-Бернардино

Изначально извлечение данных из iPhone 5c стрелка из Сан-Бернардино осложнялось тремя факторами:

1. Смартфон был зашифрован с использованием неизвестного пароля,
2. Последний iCloud-бэкап сделан более месяца назад,
3. Работодатель подозреваемого (департамент здравоохранения), владеющий смартфоном, зачем-то сбросил пароль iCloud.

А что, если бы последний пункт не был выполнен? На этот случай есть стандартная полицейская процедура. Телефон подозреваемого изолируется от радиочастот — помещается в специальный защитный пакет Faraday bag, после чего подключается к зарядному устройству. Поднимается точка доступа с такими же SSID и паролем, как у подозреваемого. Антенна вводится внутрь изолированного пакета, в котором лежит устройство, и готово: телефон самостоятельно создает свежую копию данных, которая без проблем извлекается с серверов Apple. Обрати внимание, разблокировать аппарат при этом нет никакой необходимости — не нужен ни пин-код, ни отпечаток пальца. (В скобках еще раз заметим, что для того, чтобы данная схема сработала, телефон должен быть разблокирован хотя бы один раз после «холодного» старта, иначе пароль от Wi-Fi останется зашифрованным и телефон не сделает попытки соединиться с сетью.)

Естественно, такой способ мог быть успешным только в том случае, если облачный бэкап включен. ФБР настаивает, что бэкап не был активирован, однако верить им нет никаких оснований.

Безопасность — это удобно?

Представим ситуацию. Ты активировал двухфакторную аутентификацию. Поехал в отпуск. Старый iPhone (он же доверенное устройство, он же носитель SIM-карты с доверенным телефонным номером, на который можно получить СМС c кодом) пропал. Ты приходишь в Apple Store, покупаешь новый iPhone и пытаешься его активировать. Вводишь Apple ID, потом пароль… а потом с тебя требуют одноразовый код, получить который тебе некуда и не на что.

Дальнейшее будет зависеть от того, какой именно вид двухфакторной аутентификации был использован: старый two-step verification (2SV) или новый two-factor authentication (2FA). В первом случае тебе придется использовать код восстановления доступа (Recovery Key), который ты, конечно же, сохранил в безопасном месте. Во втором — пройти процедуру восстановления доступа через автоматизированный сервис Apple, причем процедура может занять до нескольких дней. Или можно подождать, пока ты вернешься домой и восстановишь SIM-карту с заветным доверенным номером для получения кода через СМС. В целом же складывается так, что безопасность требует жертв.Впрочем, пресловутым кинозвездам подобная ситуация вряд ли доставит затруднения, ведь новую SIM-карту с собственным телефонным номером в США можно получить и активировать за минуты буквально на каждом углу. Таким образом, с точки зрения Apple проблема решена.

А если без облака?

Как мы выяснили, облачные резервные копии, несомненно, удобны, но не обязательно безопасны. И если вопрос безопасности перевешивает удобство использования, но резервную копию данных иметь все-таки хочется, то можно воспользоваться альтернативным методом резервного копирования непосредственно на компьютер через iTunes. Можно сделать так, чтобы резервная копия создавалась автоматически каждый раз, когда iPhone или iPad подключается к компьютеру. Да, это не так удобно, как облачное копирование, зато гораздо более безопасно. Или нет? Давай посмотрим.

 Резервные копии в iTunes: с паролем или без?

Обрати внимание на скриншот выше. Видишь настройку Encrypt iPhone backup? Если активировать эту настройку и указать пароль (кстати, он никак не связан с кодом блокировки устройства и паролем от Apple ID), то все вновь создаваемые резервные копии будут шифроваться с использованием этого пароля. Более того, если ты его забудешь, то сбросить или изменить его будет невозможно без полного сброса устройства (при этом восстановить его из зашифрованной резервной копии ты не сможешь, не указав правильный пароль).

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

Что ж, получается, с шифрованием все хорошо? Можно установить пароль и забыть о проблемах с безопасностью? Есть два момента, которые мешают расслабиться и получать удовольствие. Первый: пароль можно попробовать взломать.

Второй момент, вступающий в некоторое противоречие со здравым смыслом: если резервная копия зашифрована паролем, то почти все данные из keychain (а это твои пароли от учетных записей и веб-сайтов, данные утилит Health, HomeKit и многие другие) будут также зашифрованы тем же паролем. С одной стороны, это позволяет восстановить резервную копию на новое устройство и автоматически получить доступ ко всем сохраненным паролям и учетным записям. С другой — если пароль от резервной копии удастся взломать, то все эти данные станут доступны злоумышленнику.

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

«Штатными средствами»? Что, опять?! Действительно, и на этот замок есть свой ключ, однако достать его очень и очень трудно и далеко не всегда возможно. Скажем только, что ключ этот (назовем его securityd) можно извлечь только из устройств, не оснащенных системой безопасности Secure Enclave, и только в том случае, если на устройство установлен джейлбрейк. Короче говоря, извлечь securityd для расшифровки keychain из не защищенной паролем резервной копии можно на iPhone 5c и более старых, iPad mini (но даже не mini 2) и оригинальных iPad 1–4, основанных на 32-битных процессорах.

Наши рекомендации

Теперь ты знаешь, какие варианты резервного копирования существуют, и в курсе потенциальных проблем, в том числе с безопасностью. Значит ли это, что от резервных копий стоит отказаться? С нашей точки зрения — нет. Сэкономленное время и удобство перевешивают; бэкапам — быть! Оптимальной стратегией, с нашей точки зрения, будет активировать облачные резервные копии и позволить системе регулярно сохранять данные. А чтобы не оказаться в один момент у разбитого корыта, стоит время от времени (хотя бы раз в месяц) создавать и локальные копии данных через iTunes, причем с достаточно длинным, но легко запоминаемым (и трудно угадываемым) паролем.

А если включать двухфакторную аутентификацию 2SV или 2FA, то в первом случае бережно хранить (хоть с паспортом вместе) Recovery Key, во втором — как минимум привязать к учетной записи кредитку (что делают далеко не все). Еще желательно добавить дополнительный номер для СМС-верификации, что позволит «в случае чего» получить одноразовый код на другую SIM-карту.

Исследуем iCloud: как это устроено

Для пользователя iCloud — это просто и удобно. А как он устроен изнутри и как можно добраться до облачных данных? Ты можешь установить iCloud for Windows или зайти в облако с iPhone или iPad. Можешь просмотреть список резервных копий и увидеть их размер. На том всё. Скачать резервную копию ты не сможешь, для этого просто нет готового механизма. Чтобы скачать собственный бэкап, придется хорошо поработать и разобраться, как организованы хранение и защита данных.

iCloud — интересная динамическая система распределенного хранения данных, завязанная на Apple ID пользователя и работающая на основе Google Protocol Buffers. Сами файлы разбиты на отдельные блоки (chunks), которые распределены между двумя независимыми облачными провайдерами — Amazon S3 и Microsoft Azure. Что интересно, в последнее время мы наблюдаем эпизодическое использование и третьего облачного провайдера, которым стал… Google. Да-да, Apple использует сервисы Amazon, Google и Microsoft для хранения облачных бэкапов iCloud! А вот российские облачные провайдеры, такие как… ну… какие-нибудь российские, Apple для хранения облачных бэкапов не использует. Злостные нарушители, однако!

На серверах Apple формируются запросы в облачные хранилища Amazon и Microsoft для каждого блока. Ключи шифрования при этом генерируются для каждого блока (chunk) по отдельности.

Извлечь и расшифровать резервную копию данных из iCloud можно и вручную. Приведем последовательность действий.

Аутентификация в облако выполняется в следующем формате. Запрос:

https://setup.icloud.com/setup/authenticate/$APPLE_ID$
Authorization:Basic <authentication_data>

Данные аутентификации для вычисляются как mime64 (AppleID:password).

Результат: mmeAuthToken, dsPrsID.

Пример такого запроса:

GET /setup/authenticate/$APPLE_ID$ HTTP/1.1
Host: setup.icloud.com
Accept: */*
User-Agent: iCloud.exe (unknown version) CFNetwork/520.2.6
X-Mme-Client-Info: <PC> <Windows; 6.1.7601/SP1.0; W> <com.apple.AOSKit/88>
Accept-Language: en-US
Authorization: Basic cXR0LnRld3RAaWNtb3VkLmNvbTqRd2VydHkxMjM0NQ==

Для получения маркера аутентификации для дальнейшей работы используем такой запрос:

https://setup.icloud.com/setup/get_account_settings
Authorization:Basic <authentication data>
authentication data = mime64 (dsPrsID:mmeAuthToken)

Результат: mmeAuthToken (обрати внимание, это уже второй маркер аутентификации!).

Получим список бэкапов, доступных на сервере для данной учетной записи:

https://p11-mobilebackup.icloud.com/mbs/(dsPrsID)
Authorization: <authentication data>
authentication data = mime64 (dsPrsID:mmeAuthToken)

Результат: список идентификаторов резервных копий (backupudid).

Для каждой резервной копии запрашиваем ключи шифрования:

https://p11-mobilebackup.icloud.com/mbs/2005111682/(backupudid)/getKeys

Далее нам потребуется еще три запроса. Первый запрос возвращает список версий (для каждой резервной копии в облаке сохраняется целых три последние версии):

https://p11-mobilebackup.icloud.com/mbs/(dsPrsID)/(backupudid)/(snapshotid)/listFiles?offset=(offset)&limit=(limit)

Далее получаем маркеры аутентификации для каждого файла:

https://p11-mobilebackup.icloud.com/mbs/(dsPrsID)/(backupudid)/(snapshotid)/getFiles

После чего смотрим список ссылок (URL), по которым будут доступны для скачивания отдельные блоки:

https://p11-content.icloud.com/(dsPrsID)/authorizeGet

Дальше нам нужно извлечь данные, скачав все блоки. Пример запроса для блока данных, сохраненных в Windows Azure:

http://msbnx000004.blob.core.windows.net:80/cnt/g6YMJKQBPxQruxQAr30C?sp=r&sr=b&byterange=154-31457433&se=2013-06-07T10:14Z&st=2013-06-07T09:19Z&sig=0EdHy75gGHCee%2BjKePZBqz8xbWxpTxaYyASwFXVx2%2Fg%3D

Здесь se — время авторизации в iCloud (маркеры действительны в течение часа). А вот пример для блока из Amazon AWS:

http://us-std-00001.s3-external-1.amazonaws.com/I9rh20QBPX4jizMAr3vY?x-clientrequest-id=739A222D-0FF5-44DD-A8FF-2A0EB6F49816&Expires=1371208272&byterange=25556011-25556262&AWSAccessKeyId=AKIAIWWR33ECHKPC2LUA&Signature=PxAdegw0PLyBn7GWZCnu0bhi3Xo%3D

В облаке обычно хранятся три последних бэкапа. Когда создается новый, какое-то время там висят четыре последние версии (а иногда и больше), но потом их число снова сокращается до заветной цифры три. Хранятся резервные копии инкрементально. Первый бэкап обычно полный, второй существенно меньше, последний — еще меньше. Извлечь самую старую копию легче всего; следующую — чуть сложнее, так как нужно скачать и вторую часть тоже, а потом «применить» изменения. Для получения самого свежего бэкапа процедуру приходится проделывать дважды.

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

Что значит «для большей части»? Дело в том, что далеко не все данные из облачной резервной копии могут быть расшифрованы. Часть данных шифруется с помощью ключей из OTA (over-the-air) backup keybag, а большинство из них может быть расшифровано только на том самом устройстве, с которого была сделана резервная копия (с помощью ключа 0x835 «securityd», который вычисляется ядром системы в момент загрузки устройства).

Можно ли извлечь данные, защищенные securityd?

Да, это было возможно сделать на 32-разрядных платформах с iOS 5–7. Начиная с iOS 8 и устройств, оборудованных Secure Enclave (а это все 64-разрядные iPhone и iPad), извлечь этот ключ из устройства не представляется возможным даже при наличии джейлбрейка, в том числе — если верить заявлениям компании — для самой Apple.

Впервые получить все данные из чужого iCloud удалось в 2012 году, еще во времена iOS 5, с помощью атаки «man in the middle» с подменой сертификата. Для взлома использовался iPhone 4s. Последовательность действий была такой (все описанное относится только к iOS 5–7; в более свежих версиях возможность подмены сертификата прикрыли):

1. Смартфон взламывается (джейлбрейк).
2. Из репозитория Cydia устанавливается OpenSSH, с помощью которого извлекается keychain (файл keychain-2.db).
3. Смартфон сбрасывается к заводским настройкам, а сервис Find My iPhone деактивируется.
4. Аппарат перезагружается.

В результате имеется «чистое» устройство, сброшенное к заводским установкам. Далее выполняется такая последовательность действий:

1. Устройство активируется через сеть Wi-Fi с предустановленным снифером.
2. В файле keychain корневой сертификат заменяется на наш собственный (для этого потребуется ключ 0x835 и собственно файл keychain, который мы извлекли ранее).
3. Теперь все коммуникации между телефоном и серверами Apple шифруются с помощью подмененного сертификата; становится возможным снифинг трафика.

Ключ 0x835 — это и есть «securityd». Извлечь его можно только из загруженного устройства с установленным джейлбрейком и только из устройств, не оборудованных Secure Enclave. Фактически он формируется из ключа UID (уникальный ключ устройства) с помощью следующей функции:

key835 = AES(UID, bytes("01010101010101010101010101010101"))

Заключение

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

https://xakep.ru/2016/05/18/hack-ios-backup/

https://t.me/PhoenixTrading