О резервном копировании не говорит только ленивый, но мало кто следует рекомендациям специалистов.
С резервным копированием данных с компьютера всё более-менее понятно. А как с этим обстоят дела на мобильном фронте? Как с этой задачей справляются смартфоны, планшеты и прочие, более экзотические устройства под управлением Apple iOS, Google (и не-Google) Android, мобильных и стационарных сборок Microsoft Windows и BlackBerry 10? Как вытащить данные, куда сохранить, как восстановить, как обеспечить безопасность и как взломать – об этом мы расскажем в новом цикле публикаций.
Сегодняшняя «серия» будет посвящена резервным копиям iOS, в следующей мы расскажем, как работает и как ломается система бэкапов Android, а на закуску оставим Windows Phone и Blackberry 10. Сразу предупредим, что статья разбита на две части: в первой мы попробуем выяснить так ли безопасны бэкапы iOS и стоит ли им доверять, вторая же — посвящена изучению внутреннего устройств бэкапа iCloud и извлечению данных из него, что называется, голыми руками, без привлечения специальных инструментов.
Начиная с iOS 5, пользователи «яблочных» устройств получили возможность автоматического сохранения данных устройства в «облако». В старых версиях iOS эту возможность нужно было активировать вручную, но в последних версиях iOS она стала предлагаться в качестве опции «по умолчанию». В iOS 9 «облачные» копии хранятся уже не в iCloud, а в более универсальном iCloud Drive.
К слову, бесплатно в iCloud доступно всего 5 ГБ, которых, тем не менее, хватает для хранения настроек устройств и данных приложений даже устройств с 64 Гб на борту. Для тех пользователей, которые хотят сохранять в «облаке» много фотографий и видеороликов, Apple предлагает варианты платной подписки. Включить «облачное» резервное копирование можно во время активации аппарата или в любое время в настройках устройства (Settings iCloud Backup).
После активации настройки резервного копирования в «облако»происходит следующее. Ты приходишь домой (или в любое другое место, в котором есть известная телефону сеть Wi-Fi) и ставишь устройство на зарядку. В это время телефон (планшет или iPod) автоматически соединяется с «облаком» и сливает в него накопленные за день инкрементные изменения. Разумеется, если копирование происходит впервые, то в «облако» закачиваются все данные – процесс небыстрый и потребляющий заметное количество трафика. Процесс резервного копирования происходит не чаще, чем раз в сутки. При необходимости его можно осуществить и вручную, выполнив команду «Back Up Now».
[ad name=»Responbl»]
А как обстоят дела с восстановлением данных? Это тоже просто. Непосредственно в процессе активации нового (или старого, после сброса настроек) устройства можно выбрать, из какой резервной копии восстанавливать данные. Причём ни модель, ни версия операционной системы большой роли не играют: на новый iPad можно восстановить данные из старого iPhone и наоборот. Работает это всё действительно очень удобно. Поехал ты, скажем, в отпуск и потерял телефон. Завернул в ближайший Apple Store, активировал новый iPhone – и все настройки, приложения, контакты, журналы звонков, фотографии и даже обои и расположение иконок – всё восстановится само по себе «по воздуху».
Обрати внимание на вопросительный знак в заголовке. Безопасность «облачных» резервных копий iOS – под большим вопросом, ответ на который, впрочем, хорошо известен.
Итак, первое и главное: «облачные» резервные копии шифруются. Второе и не менее главное: ключ шифрования хранится рядом с зашифрованными данными, и достать его не составляет никакой проблемы. Шифрование, таким образом, защищает данные только в момент их передачи между устройством и сервером, а вот дальше… дальше ни у Apple, ни у спецслужб не возникает ни малейших проблем с доступом к твоим данным.
А что насчёт злоумышленников? Тут несколько сложнее, ведь для доступа к «облачной» копии потребуется как минимум узнать Apple ID и пароль пользователя. Впрочем, небольшой фишинг или социальный инжиниринг – и пароль от Apple ID у нас в кармане. Далее – дело техники: ставим Elcomsoft Phone Breaker, вводим ID и пароль – и вуаля! Данные пользователя у нас в кармане.
И действительно, именно этот способ был использован для воровства фотографий знаменитостей. Нет, так не годится!
И действительно, никуда не годится. В результате в Apple в спешном порядке разработали механизм двухфакторной аутентификации (на тот момент – two-step verification), который существенно осложнял доступ злоумышленникам, получившим доступ к паролю от учётной записи Apple ID. При активации этого механизма для доступа к резервной копии iCloud требовалось ввести не только логин и пароль, но и одноразовый код, который можно было получить на доверенное устройство через push или в виде SMS на доверенный телефонный номер.
[ad name=»Responbl»]
Введение дополнительного шага аутентификации существенно осложнило жизнь злоумышленников. Социальный инжиниринг усложнился: теперь требовалось не только узнать у жертвы собственно пароль, но и каким-то образом заставить её сообщить одноразовый код. Впрочем, злоумышленники справились и с этим, в качестве инструмента использовав взломанную версию 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-карты с доверенным телефонным номером, на который можно получить SMS c кодом) пропал. Ты приходишь в Apple Store, покупаешь новый iPhone и пытаешься его активировать. Вводишь Apple ID, потом пароль… а потом с тебя требуют одноразовый код, получить который тебе некуда и не на что.
Дальнейшее будет зависеть от того, какой именно вид двухфакторной аутентификации был использован: старый Two-Step Verification (2SV) или новый Two-Factor Authentication (2FA). В первом случае тебе придётся использовать код восстановления доступа (Recovery Key), который ты, конечно же, сохранил в безопасном месте. Во втором – пройти процедуру восстановления доступа через автоматизированный сервис Apple, причём процедура может занять до нескольких дней в зависимости от ситуации. Или можно подождать, пока ты вернёшься домой и восстановишь SIM-карту с заветным доверенным номером для получения кода через SMS. В целом же ситуация такова, что безопасность требует жертв.
[ad name=»Responbl»]
Впрочем, для пресловутых кинозвёзд такая ситуация вряд ли составит проблему, ведь новую SIM-карту с собственным телефонным номером в США можно получить и активировать за минуты буквально на каждом углу. Таким образом, с точки зрения Apple проблема – решена.
Как мы выяснили, «облачные» резервные копии, несомненно, удобны, но не обязательно безопасны. И если вопрос безопасности перевешивает удобство использования, но резервную копию данных иметь всё-таки хочется, то можно воспользоваться альтернативным методом резервного копирования непосредственно на компьютер через iTunes. Можно сделать так, чтобы резервная копия создавалась автоматически каждый раз, когда iPhone или iPad подключается к компьютеру. Да, это не так удобно, как «облачное» копирование, зато гораздо более безопасно. Или нет? Давай посмотрим.
Обрати внимание на скриншот выше. Видишь настройку «Encrypt iPhone backup»? Если активировать эту настройку и указать пароль (кстати, он никак не связан с кодом блокировки устройства и паролем от Apple ID), то все вновь создаваемые резервные копии будут шифроваться с использованием этого пароля. Более того, если ты забудешь пароль, то сбросить или изменить его будет невозможно без полного сброса устройства (при этом восстановить его из зашифрованной резервной копии ты не сможешь, не указав правильный пароль).
С технической точки зрения шифрование в iOS реализовано образцово-показательно. Вся информация шифруется непосредственно в самом устройстве, а наружу выдаётся уже зашифрованный поток данных. iTunes в данном случае всего лишь выдаёт команду на создание резервной копии, принимает зашифрованный поток данных и сохраняет его в файл. На месте iTunes могла бы быть любая другая программа, при этом данные всё равно остались бы зашифрованными (в одной из следующих статей мы рассмотрим этот момент подробнее).
Что ж, получается, с шифрованием всё хорошо? Можно установить пароль и забыть о проблемах с безопасностью? Есть два момента, которые мешают расслабиться и получить удовольствие. Момент первый: пароль можно попробовать взломать.
Есть и второй момент, который вступает в некоторое противоречие со здравым смыслом. Если резервная копия зашифрована паролем, то почти все данные из keychain (а это твои пароли от учётных записей и веб-сайтов, данные утилит Health, HomeKit и многие другие) будут также зашифрованы тем же паролем. С одной стороны, это позволяет восстановить резервную копию на новое устройство и автоматически получить доступ ко всем сохранённым паролям и учётным записям. С другой – если пароль от резервной копии удастся взломать, то все эти данные станут доступны злоумышленнику.
А если пароль не указывать? Тогда данные приложений, фотографии и прочая информация зашифрованы не будут. А вот данные из keychain – наоборот, будут зашифрованы стойким аппаратным ключом, взломать который на данном этапе развития технологий не представляется возможным. Правда, штатными средствами восстановить данные из keychain можно будет только на то же самое устройство, с которого они были скопированы.
«Штатными средствами»? Что, опять?! Действительно, и на этот замок есть свой ключ, однако достать его – очень и очень трудно и далеко не всегда возможно. Скажем только, что ключ этот (назовём его «securityd») можно извлечь только из устройств, не оснащённых системой безопасности Secure Enclave, и только в том случае, если на устройство установлен jailbreak. Короче говоря, извлечь securityd для расшифровки keychain из незащищённой паролем резервной копии можно из iPhone 5c и более старых, iPad mini (но даже не mini 2) и оригинальных iPad 1-4, основанных на 32-битных процессорах.
Теперь ты знаешь, какие варианты резервного копирования существуют и в курсе потенциальных проблем, в том числе проблем с безопасностью. Значит ли это, что от резервных копий стоит отказаться? С нашей точки зрения – нет. Сэкономленное время и удобство перевешивают; бэкапам – быть! Оптимальной стратегией с нашей точки зрения будет активировать «облачные» резервные копии и позволить системе регулярно сохранять данные. А чтобы не оказаться в один момент «у разбитого корыта», стоит время от времени (хотя бы раз в месяц) создавать и локальные копии данных через iTunes, причём с достаточно длинным, но легко запоминаемым (и трудно угадываемым) паролем.
[ad name=»Responbl»]
А если включать двухфакторную аутентификацию 2SV или 2FA, то в первом случае бережно хранить (хоть с паспортом вместе) Recovery Key, во втором – как минимум привязать к учётной записи кредитку (что делают далеко не все). Ещё желательно добавить дополнительный номер для SMS-верификации, что позволит «в случае чего» получить одноразовый код на другую SIM-карту.
Для пользователя 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>
Данные аутентификации для <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/g6YMJKQBPxQruxQAr30
C?sp=r&sr=b&byterange=154-31457433&se=2013-06-07T10:14Z&st=2013
-06-07T09:19Z&sig=0EdHy75gGHCee%2BjKePZBqz8xbWxpTxaYyASwFXVx2%2
Fg%3D
Здесь ‘se’ – время авторизации в iCloud (маркеры действительны в течение часа). А вот пример для блока из Amazon AWS:
http://us-std-00001.s3-external-1.amazonaws.com/I9rh20QBPX4jizMAr3v
Y?x-clientrequest-id=739A222D-0FF5-44DD-A8FF-2A0EB6F49816&Expir
es=1371208272&byterange=25556011-25556262&AWSAccessKeyId=AKIAIW
WR33ECHKPC2LUA&Signature=PxAdegw0PLyBn7GWZCnu0bhi3Xo%3D
В «облаке» обычно хранится три последних бэкапа. Когда создаётся новый, какое-то время в «облаке» висит четыре последних версии (а иногда и больше), но потом их число снова сокращается до заветной цифры «три». Хранятся резервные копии инкрементально. Самый первый бэкап обычно полный, следующий существенно меньше, самый новый еще меньше. Извлечь самую старую копию легче всего; следующий – чуть сложнее, т.к. нужно скачать и вторую часть тоже, а потом «применить» изменения. Для получения самого свежего бэкапа процедуру приходится проделывать дважды.
Скачать данные из «облака» — полдела. Теперь нужно их ещё и расшифровать. Даже с учётом того, что ключи шифрования для большей части данных нам доступны (они хранятся параллельно с самими данными), задача не самая простая.
Что значит «для большей части»? Дело в том, что далеко не все данные из «облачной» резервной копии могут быть расшифрованы. Часть данных шифруется с помощью ключей из OTA (over-the-air) backup keybag, большинство из которых может быть расшифровано только на том самом устройстве, с которого была сделана резервная копия (с помощью ключа 0x835 «securityd», который вычисляется ядром системы в момент загрузки устройства).
Да, это было возможно сделать на 32-разрядных платформах с iOS 5-7. Начиная с iOS 8 и устройств, оборудованных Secure Enclave (а это – все 64-разрядные iPhone и iPad) извлечь этот ключ из устройства не представляется возможным даже при наличии jailbreak, в том числе – если верить заявлениям компании – даже для самой Apple.
Впервые извлечь все данные из чужого iCloud удалось в 2012 году, ещё во времена iOS 5 с помощью атаки «man in the middle» с подменой сертификата. Для взлома использовался iPhone 4S. Последовательность действий была такой (всё описанное относится только к iOS 5-7; в более свежих версиях возможность подмены сертификата прикрыли):
1. Смартфон взламывается (jailbreak);
2. Из репозитария Cydia устанавливается OpenSSH, с помощью которого извлекается keychain (файл keychain-2.db);
3. Смартфон сбрасывается к к заводским настройкам, а сервис Find My iPhone– деактивируется;
4. Аппарат перезагружается.
В результате имеется «чистое» устройство, сброшенное к заводским установкам. Далее была выполняется следующая последовательность действий:
Ключ 0x835 и есть «securityd». Извлечь его можно только из загруженного устройства с установленным jailbreak, и только из устройств, не оборудованных Secure Enclave. Фактически он формируется из ключа UID (уникальный ключ устройства) с помощью следующей функции:
key835 = AES(UID, bytes("01010101010101010101010101010101"))
Сегодня мы ознакомились с образцово-показательной (без малейшей иронии) системой резервного копирования, спроектированной и реализованной на самом высоком уровне. В Apple серьёзно подошли к вопросу и попытались нащупать баланс между удобством и безопасностью. С нашей точки зрения им это скорее удалось, особенно если сравнить с решениями конкурентов. А как обстоят дела в самой распространённой мобильной ОС Android? Об этом мынапишем в следующем выпуске.
Чтобы взломать сеть Wi-Fi с помощью Kali Linux, вам нужна беспроводная карта, поддерживающая режим мониторинга…
Работа с консолью считается более эффективной, чем работа с графическим интерфейсом по нескольким причинам.Во-первых, ввод…
Конечно, вы также можете приобрести подписку на соответствующую услугу, но наличие SSH-доступа к компьютеру с…
С тех пор как ChatGPT вышел на арену, возросла потребность в поддержке чата на базе…
Если вы когда-нибудь окажетесь в ситуации, когда вам нужно взглянуть на спектр беспроводной связи, будь…
Elastic Security стремится превзойти противников в инновациях и обеспечить защиту от новейших технологий злоумышленников. В…
View Comments
Как с вами связаться
Если вы не в состоянии найти наши контакты на нашем сайте. не стоит связываться.
How do I perform authentication to 2 factor account? (I get 409 Conflict Error as followed:
HTTP/1.1 409 Conflict
Server: AppleHttpServer/2f080fc0
Date: Mon, 25 Dec 2017 07:29:23 GMT
Content-Type: application/xml; charset=UTF-8
Content-Length: 538
Connection: keep-alive
X-Apple-Jingle-Correlation-Key: CEOP775HJFE6RKSXGRCEYBJUY4
apple-seq: 0
apple-tk: false
Apple-Originating-System: UnknownOriginatingSystem
X-Responding-Instance: setupservice:21800103:nk11p18ic-setupsvc001:8003:17H249:a07b3b3c2
Cache-Control: no-cache, no-store, private
Set-Cookie: X-iCloud-HSA-Login=MTI2NjExMTkzODpBUUFBQUFCYVFLalRab0E2eG9sbUhGemt3bnFTb0dVazVkUHJNZTB+;Max-Age=100;Path=/;Domain=.icloud.com;Secure;HttpOnly;Version=1
Set-Cookie: repairSteps=gv;Path=/setup/iosbuddy/;HttpOnly
Strict-Transport-Security: max-age=31536000; includeSubDomains
via: icloudedge:br30p00ic-zteu01133101:7401:17RC198:Berlin
X-Apple-Request-UUID: 111cffff-a749-49e8-aa57-34444c0534c7
access-control-expose-headers: X-Apple-Request-UUID
access-control-expose-headers: Via
protocolVersion
2
title
Verification Required
localizedError
MOBILEME_TERMS_OF_SERVICE_UPDATE
message
This Apple ID is protected with two-step verification. To sign in, you must verify your identity.