Bootrom уязвимость checkm8
В конце сентября 2021 г. исследователь информационной безопасности с ником axi0mX опубликовал
код эксплойта практически для всех устройств производства Apple с чипами версий A5 — A11. Особенность найденной уязвимости состоит в том, что она находится на аппаратном уровне и никакими обновлениями ПО её невозможно устранить, так как она прячется в самом механизме защиты безопасной загрузки BootROM, a. k. a. SecureROM.
Модель загрузки iOS с презентации Apple на WWDC 2021 г.
В момент холодной загрузки первым из read-only памяти запускается SecureROM, причем это самый доверенный код в Application Processor и поэтому он выполняется без каких-либо проверок. В этом кроется причина того, что патчи iOS тут бессильны. И также крайне важно, что SecureROM отвечает за переход устройства в режим восстановления (Device Firmware Update) через интерфейс USB при нажатии специальной комбинации клавиш.
Переход iOS в режим DFU.
Уязвимость Use-after-Free возникает, когда вы ссылаетесь на память после того, как она была освобождена. Это может привести к неприятным последствиям, таким как сбой программы, непредсказуемые значения, или как в данном случае — выполнение стороннего кода.
Для начала, чтобы понять механизм эксплойта, нам нужно понять, как работает системный режим восстановления. При переходе смартфона в режим DFU в момент инициализации выделяется буфер I/O и создается USB-интерфейс для обработки запросов к DFU. Когда установочный пакет 0x21, 1 поступает по USB-интерфейсу на этапе USB Control Transfer, код DFU после определения адреса и размера блока копирует данные буфера I/O в загрузочную область памяти.
Структура USB Control Transfer Setup Packet.
Соединение по USB остается активным до тех пор, пока длится загрузка образа прошивки, после чего оно завершается в штатном режиме. Однако существует и нештатный сценарий выхода из режима DFU, для этого нужно отправить сигнал DFU abort по коду bmRequestType=0x21, bRequest=4.
Checkm8 по существу эксплуатирует уязвимость Use-after-Free в процессе DFU, чтобы разрешить выполнение произвольного кода. Этот процесс состоит из нескольких этапов, но один из самых важных известен, как фэн-шуй кучи, который тасует кучу специальным образом, чтобы облегчить эксплуатацию уязвимости.
Запуск команды ./ipwndfu -p на MacOS.
В практическом плане все сводится к переводу iPhone в режим DFU и запуску простой команды ./ipwndfu -p. Результат действия Python скрипта состоит в снятии блокирования с несанкционированным доступом ко всей файловой системе смартфона. Это дает возможность устанавливать ПО для iOS из сторонних источников. Так злоумышленники и правоохранители могут получить доступ ко всему содержимому украденного или изъятого смартфона.
Хорошая новость состоит в том, что для взлома и установки стороннего ПО, требуется физический доступ к телефону от Apple и кроме того, после перезагрузки все вернется на место и iPhone будет в безопасности — это т. н. привязанный джейлбрейк. Если у вас на границе отобрали смартфон и затем вернули его, лучше лишний раз не испытывать судьбу и перезагрузиться.
Icloud и почти защищенные бэкапы
Выше уже было сказано, что в последнем противостоянии FBI с Apple из-за перестрелки в Пенсаколе, компания отдала в руки правоохранителей, резервные копии iCloud с телефонов подозреваемых. Тот факт, что в ФБР не стали воротить носом говорит о том, что эти данные, в отличие от заблокированного iPhone, были вполне пригодны для исследования.
Наивно полагать, что это единичный случай. Только за первое полугодие 2021 г. следователи 1568 раз получали доступ к почти 6000 полновесных резервных копий iCloud пользователей яблочных смартфонов. В 90% обращений из гос. структур компания предоставляла некоторые данные из iCloud, а таких обращений всего было около 18 тыс. за тот же период.
Это стало возможным после того, как Apple без лишнего шума два года назад свернула проект по обеспечению сквозного шифрования пользовательских резервных копий iCloud. Есть свидетельства в пользу того, что это было сделано после давления со стороны ФБР.
В результате компромисса с силовыми структурами и пользователями возникла мешанина, в которой не очевидно, какие данные в iCloud надежно сокрыты, а какие — так себе. По крайней мере, можно сказать, что сквозное шифрование применяется для следующих категорий.
Все же остальное, включая
Messages
, возможно, могут прочитать сотрудники Apple и компетентные органы.
Pgptools для iphone и ipad — надежное шифрование личной переписки | яблык
В последнее время проблема защиты личных данных тревожит не только IT-специалистов и продвинутых пользователей, но и всякого, кто в курсе событий последних лет, таких как массовые утечки конфиденциальной информации, взломы аккаунтов, кражи данных учетных записей и т.д.
Разработчик / Издатель: SJ Software Development Group Limited
Скачать PGPTools для iOS (App Store);
Скачать PGPTools для Android (Play Store);
Скачать PGPTools для Mac (Mac App Store);
Скачать PGPTools для для Windows (Windows Store).
Официальный сайт PGPTools.
Впрочем, защититься от постороннего вмешательства не так уж сложно — это может сделать фактически любой пользователь, не прикладывая особых усилий. В этом материале мы расскажем о простой, но довольно эффективной утилите PGPTools, которая позволит надежно зашифровать вашу личную переписку и гарантировать ее конфиденциальность.
Как и следует из названия программы, в ее основе лежит система шифрования с нескромным, но многообещающим названием PGP, что расшифровывается как Pretty Good Protect. Разработана она была почти 15 лет назад и считается одной из самых надежных в своем роде. Упрощенно, принцип работы отчетного приложения выглядит следующим образом — двое пользователей имеют PGP-ключ шифрования, при помощи которого могут как распознавать, так и создавать закодированные сообщения.
При этом PGPTools позволяет отправлять зашифрованные послания не только на электронную почту, но и через любой другой сервис, поддерживающий текстовые сообщения — Skype, ICQ, SMS, WhatsApp и т.д. Для этого нужно лишь скопировать код из приложения и вставить в сообщение, после чего получатель произведет обратную процедуру — скопирует код из мессенджера, а затем введет его в PGPTools, где он и будет расшифрован.
Важная особенность PGPTools — максимальная простота интерфейса и процесса взаимодействия с ним. Чтобы не пугать пользователей тонкими настройками и большим количеством сложных технических опций, разработчики практически упразднили их. Приложение разделено всего на два основных экрана — на одном отображается список ключей, на другом производится непосредственно шифрование и расшифровка сообщений.
Итак, нажав « » в верхнем левом углу в разделе «Список ключей» (скриншот выше), необходимо ввести его имя, электронный адрес получателя, пароль и выбрать длину ключа в битах (1024, 2048 или 4096). Имеется также возможность импорта уже созданных ранее PGP-ключей.
После чего можно переходить непосредственно к переписке, то есть, в раздел PGPTools. В основное поле нужно ввести или вставить из буфера обмена исходный текст, затем выбрать ключ из списка созданных, ввести пароль от него и нажать кнопку «Конвертировать». Полученный код можно скопировать и отправить получателю по E-mail, через мессенджеры, социальные сети и т.д. Обратный процесс не менее прост — получаем код, вставляем в основное поле, выбираем ключ, вводим пароль и видим на экране расшифрованное сообщение.
Простота, удобство и эффективность PGPTools делают данную программу весьма привлекательной для широкой массы пользователей. При этом приложение можно использовать практически на любом устройстве — под управлением iOS, Android, Windows Phone, а также десктопных платформах.
Смотрите также:
Безопасность ios (часть ii)
Как и архитектура безопасности iOS в целом, механизмы шифрования и защиты данных в полной мере используют возможности аппаратного и программного уровней.
Автор: Понуровский Иван
В прошлой статье шла речь о базовых механизмах безопасности операционной системы iOS. Базовые механизмы включают в себя цепочку доверенной загрузки, персонализацию системного ПО, подписание кода сообщений, выполнение приложений в песочнице и с правами непривилегированного пользователя, права доступа (entitlements), ASLR и ARM’s Execute Never. Но, допустим, что случилось страшное: нарушителю удалось каким-то образом обойти базовые механизмы безопасности, и конфиденциальная информация пользователя теперь находится под угрозой. Но и тогда нарушителю может помешать последний, практически нерушимый, оплот безопасности – механизмы шифрования и защиты данных.
Аппаратный уровень
Как и архитектура безопасности iOS в целом, механизмы шифрования и защиты данных в полной мере используют возможности аппаратного и программного уровней. Начнем с аппаратного уровня.
Для мобильных устройств критическую важность имеет скорость работы и энергоемкость. Криптографические операции требует большого числа ресурсов, и при неправильном проектировании могут отрицательно повлиять на заряд батареи.
Каждое устройство с iOS имеет встроенный чип, в котором реализован алгоритм AES-256. Расположение чипа на пути от флеш-памяти к оперативной памяти заметно снижает энергозатраты на шифрование/дешифрование. На аппаратном уровне также реализован алгоритм SHA-1.
При производстве в процессор зашиваются два 256-битных ключа AES: UID (уникальный идентификатор устройства) и GID (групповой идентификатор устройства). Никакое программно-аппаратное обеспечение не может напрямую прочитать ключи AES; можно только прочитать результаты шифрования/дешифрования на этих ключах. Ключ UID уникален для каждого устройства, и он неизвестен даже Apple.Не стоит путать UID и ECID; ECID – это тоже уникальный и тоже идентификатор, который имеет вид 00000XXXXXXXXXXX, где X – шестнадцатеричная цифра; а UID, как уже говорилось выше, 256-битный ключ. Ключ GID одинаков для всех процессоров одного семейства (например, у всех процессоров A5 GID одинаковый).
При загрузке ядра служба IOAESAccelerator вычисляет еще пять ключей на основе UID и GID:
Рисунок 1. Ключи, генерируемые на основе UID и GID
- Ключ 0x835 генерируется путем шифрования величины 01010101010101010101010101010101 на ключе UID;
- Ключ 0х899 генерируется путем шифрования величины D1E8FCB53937BF8DEFC74CD1D0F1D4B0 на ключе UID, назначение ключа 0x899 неизвестно;
- Ключ 0x89Aгенерируется путем шифрования величины DB1F5B33606C5F1C1934AA66589C0661 на ключе UID и используется для шифрования SHSH-сертификата;
- Ключ 0x89Bгенерируется путем шифрования величины 183E99676BB03C546FA468F51C0CBD49 на ключе UID и используется для шифрования ключа раздела данных (ключ EMF);
- Ключ 0x837 генерируется путем шифрования величины 345A2D6C5050D058780DA431F0710E15 на ключе GID, ключ использовался в ранних версиях iOS и в современных версиях не используется.
В дальнейшем нас будут интересовать только ключи 0x835, 0x89A и 0x89B.
На аппаратном уровне также реализован генератор псевдослучайной последовательности. Генератор получает энтропию на основе длительности прерываний во время загрузки, а также от внутренних датчиков.
Быстрое и безопасное удаление ключей настолько же важно, как и их генерация. Для решения подобной проблемы на устройствах под управлением iOS существует специальная область под названием Effaceable Storage. Область занимает 1 блок (~ 1Мб) во flash-памяти и содержит три ключа: зашифрованный ключ EMF, зашифрованный ключ DKey и ключ BAG1 (подробнее об этих ключах чуть ниже). Технология Effaceable Storage позволяет при необходимости быстро стереть все ключи, сделав всю информацию на устройстве пользователя недоступной.
Механизм защиты данных
Наряду с технологиями аппаратного уровня, для защиты данных пользователя во flash-памяти также используется механизм Data Protection. Механизм ориентирован на мобильные устройства и позволяет пользователю, например, отвечать на входящие звонки без расшифровки конфиденциальных данных, или в фоновом режиме скачивать информацию даже когда устройство заблокировано. Контроль доступа к каждому фалу осуществляется на основе класса защиты, то есть каждому файлу присваивается определенный класс защиты, в зависимости от того, когда может потребоваться доступ к этому файлу (например, только после разблокировки устройства, или даже если устройство заблокировано). У каждого класса защиты есть отдельный ключ, на котором шифруется ключ файла, принадлежащего конкретному классу защиты.
Рассмотрим теперь подробнее, какие действия происходят при создании файла, и как организована его защита. Все очень просто.
- Каждый раз при создании файла система генерирует новый 256-битный ключ FileKey (файловый ключ);
- Следующим шагом вычисляется вектор инициализации (IV). Сначала вычисляется так называемый IV—key. IV—keyполучается путем хеширования файлового ключа, причем хеш берется не весь, а только 16 байтов. Затем, чтобы вычислить окончательное значение IVнужно взять выход регистра сдвига с линейной обратной связью (LFSR), на вход которого подается блок из файла с определенного смещения, и зашифровать выход на ключе IV—key. Другими словами, IV= AES_ENC(SHA1(FileKey), LFSR(offset)).
- Файл зашифровывается алгоритмом AES на ключе FileKey и векторе инициализации IVв режиме CBC и записывается во flash-память.
- Файловый ключ FileKey зашифровывается соответствующим ключом класса защиты и записывается в метаданные файла.
- Метаданные файла зашифровываются ключом EMF. EMF — это специальный ключ, который генерируется при установке iOS или после того, как пользователь стер все данные с устройства. Ключ EMF шифруется ключом 0x89B и сохраняется в области Effaceable Storage, т.е. EMF! = AES_ENC(0x89B, EMF). Опция “Удалить все содержимое и настройки” (“Erase all content and settings”) позволяет в мгновение ока сделать все данные на устройстве недоступными. Действительно, если стереть ключ EMF в Effaceable Storage, никакой файл расшифровать не получится.
Чтобы расшифровать файл нужно проделать все в обратном порядке: сначала расшифровать ключ EMF, затем расшифровать метаданные необходимого файла и прочитать из них зашифрованный FileKey; расшифровать FileKey и, наконец, расшифровать весь файл.
Итак, на данный момент иерархия криптографических ключей iOS выглядит следующим образом:
Рисунок 2. Первоначальный вариант иерархии ключей
Как видно из рисунка, назначение некоторых компонентов иерархии ключей все еще остается неясным. Для полной картины необходимо описать еще несколько сущностей.
Пароль пользователя
На своем устройстве пользователь может установить пароль (Passcode). Всего возможно три вида паролей:
- четырехзначный числовой пароль;
- числовой пароль произвольной длины;
- алфавитный пароль произвольной длины.
На основе UID устройства и пароля пользователя с помощью специальной функции (PBKDF2) вычисляется парольный ключ (Passkey):
Рисунок 3. Вычисление парольного ключа
Чтобы усложнить нарушителю атаку перебором, вычисление парольного ключа намеренно замедляется и в среднем занимает около 80 миллисекунд, причем после каждой неудачной попытке ввода пароля временная задержка до следующей попытки увеличивается. Кроме того, пользователь может включить опцию, благодаря которой после определенного числа неправильных попыток ввода пароля вся информация с устройства будет стерта. Заметим еще, что благодаря тому, что в вычислении парольного ключа участвует UID, парольный ключ для разных устройств с одинаковым паролем все равно будет различаться. Вообще, парольный ключ играет одну очень важную функцию, о которой будет рассказано чуть позже. Известно также, что, начиная с iOS 5, в процессе вычисления парольного ключа участвует еще один аппаратный ключ UID , но, к сожалению, более подробной информации об этом ключе мне найти не удалось
Ключи классов защиты
Всего в iOS существует 11 классов защиты, причем 5 классов используются для защиты данных (ключи классов защиты данных), а 6 для защиты элементов связок ключей (ключи классов защиты элементов связки ключей). Сначала рассмотрим ключи классов защиты данных.
Таблица 1. Ключи классов защиты данных
Полная защита (NSFileProtectionComplete, ClassA): Если для данных установлен такой класс защиты, то спустя некоторое время после блокировки устройства расшифрованный ключ класса полной защиты стирается из оперативной памяти, делая тем самым данные класса NSFilePotectionComplete недоступными до тех пор, пока пользователь снова не разблокирует устройство и не введет пароль.
Доступ для записи при блокировке (NSFileProtectionCompleteUnlessOpen, ClassB): Для некоторых файлов требуется, чтобы информация в них могла записываться, даже когда устройство заблокировано. Подобное условие выполняется следующим образом:
- Помимо файлового ключа для файла генерируется пара открытый (pkf) закрытый ключ (skf):
- У класса защиты NSFileProtectionCompleteUnlessOpen также есть открытый (pkc) / закрытый ключи (skc):
- На основе закрытого ключа файла и открытого ключа класса защиты вычисляется разделяемый секрет:
- Файловый ключ зашифровывается на хеше разделяемого секрета и вместе с открытым ключом файла сохраняется в метаданных. Закрытый ключ файла стирается из памяти:
- После блокировки устройства файловый ключ тоже стирается из памяти
- Теперь чтобы расшифровать файл нужно снова вычислить разделяемый секрет на основе открытого ключа файла и закрытого ключа класса защиты, посчитать хеш разделяемого секрета и расшифровать файловый ключ:
Данные недоступны только до первой аутентификации пользователя (NSFileProtectionCompleteUntilFirstUserAuthentication, ClassC): В отличие от класса полной защиты ключ класса защиты NSFileProtectionCompleteUntilFirstUserAuthentication не удаляется из памяти после блокировки устройства, следовательно пользователь будет иметь доступ к данным класса С, начиная с момента первой разблокировки устройства и ввода пароля вплоть до перезагрузки устройства.
Защита отсутствует (NSFileProtectionNone, ClassD): Этот класс по умолчанию присваивается данным, если им не присваивается какой-либо другой класс. На самом деле ключ NSFileProtectionNone хранится в Effaceable Storage: это и есть тот самый ключ Dkey, зашифрованный ключом 0x835, т.е. Dkey! = AES_ENC(0x835, DKey). Таким образом, даже если файлу не присвоен какой-либо класс защиты, файл все равно шифруется.
Связка ключей
Многие приложения должны хранить собственные данные (например, пароли приложения, Wi-Fi пароли, почтовые аккаунты, сертификаты и.т.п.) в безопасности. Безопасность конфиденциальных данных приложений достигается за счет так называемой “связки ключей” (Keychain). По своей сути связка ключей – это база данных SQLite, хранящаяся в файловой системе устройства и имеющая класс защиты NoProtection. Доступ к базе осуществляется при помощи демона securityd, именно этот демон решает какое приложение или процесс к какому элементу связки ключей (записи в базе данных) может обратиться.
Хотя сама база и имеет класс защиты NoProtection, элементы связки ключей имеют собственные классы защиты, а соответственно и ключи классов защиты, в дальнейшем такие ключи будут называться ключи классов защиты элементов связки ключей. В Таблице 2 представлены все 6 возможных ключей классов защиты элементов связки ключей:
| ID ключа | Название | Назначение |
6 | kSecAttrAccessibleWhenUnlocked | Элемент связки ключей доступен только после разблокировки |
7 | kSecAttrAccessibleAfterFirstUnlock | Элемент связки ключей недоступен только до первой аутентификации |
8 | kSecAttrAccessibleAlways | Элемент связки ключей доступен, даже если устройство заблокировано |
9 | kSecAttrAccessibleWhenUnlockedThisDeviceOnly | Элемент связки ключей доступен только после разблокировки, и элемент нельзя перемещать между устройствами |
10 | kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly | Элемент связки ключей недоступен только до первой аутентификации, и элемент нельзя перемещать между устройствами |
11 | kSecAttrAccessibleAlwaysThisDeviceOnly | Элемент связки ключей доступен, даже если устройство заблокировано, и элемент нельзя перемещать между устройствами |
Таблица 2. Ключи классов защиты элементов связки ключей
Заметим, что половина ключей классов защиты связки ключей имеет постфикс “ThisDeviceOnly”. Дело в том, что в iOS 5 появилась возможность перемещать элементы связки ключей с одного устройства на другое. Элементы, которые имеют класс защиты с постфиксом “ThisDeviceOnly” дополнительно защищаются UID устройства, и поэтому на другом устройстве их просто не получится расшифровать.
Каждый элемент связки ключей имеет следующую структуру (начиная с iOS 5):
Рисунок 4. Структура элемента связки ключей
access group: группа доступа, т.е. приложения, процессы, которые могут получить доступ к элементу связки ключей;
Сумки с ключами
(Слева от абзаца 5_dollars.png) Все ключи классов защиты объединяются в еще одну сущность под названием “сумка с ключами” (Keybag). Всего существует 4 разновидности сумок с ключами: Системная сумка с ключами (System Keybag), Резервная сумка с ключами (Backup Keybag), Депонированная сумка с ключами (Escrow Keybag), Резервная сумка с ключами iCloud (iCloud Backup Keybag). Все сумки имеют одинаковую структуру, которая представлена на Рисунке 5:
Рисунок 5. Структура сумки с ключами
Теперь рассмотрим, какие функции выполняет каждая сумка в отдельности.
Системная сумка с ключами. Системная сумка хранится непосредственно на устройстве в файле /private/var/keybags/systembag.kb. Файл системной сумки зашифрован на ключе BAG1, который, как уже известно, находится в Effaceable Storage. Нужно отметить, что после каждой смены пароля меняется и ключ BAG1. После расшифровки файла мы получим системную сумку с ключами, но она будет находиться в заблокированном состоянии, то есть все ключи классов защиты в сумке по-прежнему будут зашифрованы. Каждый ключ зашифрован одним из трех способов: либо только на ключе UID, либо только на парольном ключе, либо одновременно на парольном ключи и на UID. За конкретный тип шифрования отвечает поле Wrappingtype.
Рисунок 6. Разблокировка системной сумки с ключами
В шифровании ключей классов защиты элементов связки ключей “…ThisDeviceOnly” всегда участвует ключ UID, для того чтобы на другом устройстве эти ключи расшифровать бы не получилось.
Резервная сумка с ключами. Каждый раз, когда пользователь делает резервную копию устройства в iTunes, на компьютере пользователя создается резервная сумка с ключами. Ключи классов защиты в резервной сумке отличаются от ключей классов защиты в системной сумке, поэтому все файлы бэкапа перешифровываются на новых ключах. Файлы бэкапа шифруются, конечно же, алгоритмом AES 256 в режиме CBC на уникальном ключе и нулевом IV.
Всего возможно два вида бэкапов: обычный и зашифрованный. Различия между ними следующие:
- в простых бэкапах ключи элементов связки ключей всех классов защиты зашифрованы на ключе 0x835, и, следовательно, восстановить их можно только на оригинальном устройстве;
- в зашифрованных бэкапах пользователь при резервном копировании вводит специальный пароль. Этот пароль 10 000 раз прогоняется через функцию PBKDF2 (заметим, что в отличие от вычисления обычного пароля UID здесь не используется) в результате чего получается парольный ключ резервной копии. Все ключи классов защиты перемещаемых элементов связки ключей (с идентификаторами с 6 по 8) зашифровываются только на парольном ключе резервной копии, а ключи классов защиты элементов связки ключей “…ThisDeviceOnly” (идентификаторы с 9 по 11) зашифровываются одновременно на ключе 0x835 и на парольном ключе резервной копии.
Согласно такой схеме резервного копирования элементы связки ключей “…ThisDeviceOnly” перебросить с одного устройства на другое никак не получится, а перемещаемые элементы связки ключей можно, простите за тавтологию, переместить только в зашифрованном бэкапе.
Депонированная сумка с ключами. Депонированнаясумка позволяет синхронизированному устройству (например, компьютеру, на котором установлен iTunes) разблокировать устройство с iOS, не требуя каждый раз пароля от пользователя. Когда устройство подключается к компьютеру, iTunes просит пользователя ввести пароль. После правильного ввода пароля создается депонированная сумка (ключи классов защиты в ней точно такие же, как и в системной сумке) и сохраняется на компьютере. Депонированная сумка зашифрована на 256-битном случайно сгенерированном ключе. Ключ, в свою очередь, хранится в файле на устройстве в папке /private/var/root/Library/Lockdown/escrow_records. Файл имеет класс защиты NSFileProtectionCompleteUntilFirstUserAuthentication.
Резервная сумка с ключами iCloud. Эта сумка во многом схожа с простой резервной сумкой, но в iCloud-сумке все ключи ассиметричные, благодаря чему резервное копирование в iCloud может производиться в фоновом режиме. Закрытые ключи классов защиты данных шифруются ключами облачного хранилища, а закрытые ключи классов защиты элементов связки ключей, как и в обычном бэкапе, зашифрованы на ключе 0x835.
Теперь, обладая более полной информацией, мы можем завершить схему иерархии ключей:
Рисунок 7. Иерархия ключей
Несмотря на свою кажущуюся сложность и громоздкость, иерархия ключей, реализованная Apple, позволяет гибко управлять шифрованием. Например, изменить класс защиты файла достаточно перешифровать файловый ключ, при смене пароля пользователя перешифровываются только ключи классов защиты, а чтобы сделать все данные недоступными достаточно вообще стереть только один ключ.
В заключение статьи опишем возможные атаки на механизм защиты данных
Атаки на механизм защиты данных
Допустим, нарушитель все-таки хочет извлечь конфиденциальную информацию из устройства пользователя. Нарушителю может потребоваться файл целиком (например, какой-нибудь сверхсекретный документ), или какие-либо атрибуты безопасности приложений (Wi-Fi пароль, сертификаты, закрытые ключи приложений и.т.п.). В первом случае необходимо знать ключ EMF, а также соответствующий ключ класса защиты данных. Ключ EMF зашифрован на ключе 0x89B, который, в свою очередь, вычислен на основеUID. Для шифрования ключей классов защиты данных используются ключи BAG1, UID и/или парольный ключ. Во втором случае элементы связки ключей зашифрованы на соответствующих ключах классов защиты элементов связки ключей, и для их (ключей классов защиты) расшифровки также необходимо знать ключи BAG1, UID и/или парольный ключ.
Следует сказать, что на данный момент известных способов извлечь аппаратные ключи UID и GIDне существует. Но не все так плохо. Специально для программно-технической экспертизы устройств с iOS компания Sogeti Labs выпустила пакет утилит, позволяющих извлечь практически все ключи (кроме аппаратных) из устройства. Ключи можно прочитать, благодаря пропатчиванию службы ядра IOAESAccelerator. Именно эта служба при загрузке ядра вычисляет ключи 0x835, 0x89A и 0x89B (см. Рисунок 1), а зная их, можно получить ключи Dkey, EMF и BAG1 (BAG1 вообще хранится незашифрованным). Для пропатчивания на устройстве, безусловно, должен быть сделан jailbreak. Код утилит от Sogeti Labs открыт, и при желании их легко можно найти в Интернете.
Таким образом, обычно всё упирается в знание парольного ключа, т.е. пароля. Ниже описано несколько возможных способов извлечения конфиденциальной информации. Тривиальный случай, когда нарушитель завладел устройством без пароля, рассматривать не будем.
Случай 1: Нарушитель имеет физический доступ к устройству с паролем. В таком случае, если пароль состоит из 4 цифр, то можно за разумное время перебрать все возможные пароли, разблокировать устройство и получить полный доступ к информации пользователя.
Меры противодействия:
- Установить более сложный пароль;
- Использовать опцию ”Стереть содержимое и настройки устройства после N неудачных попыток ввода пароля” (стереть ключ EMF).
Случай 2: Эксплуатация Депонированной сумки с ключами. Как известно ключи классов защиты из депонированной сумки ничем не отличаются от ключей в системной сумке. Если нарушитель будет иметь доступ к устройству и компьютеру пользователя, то он сможет извлечь из устройства ключ, на котором зашифрована депонированная сумка (подбор 256-битного ключа займет достаточно много времени), расшифровать сумку и извлечь все ключи классов защиты. В результате нарушитель получит доступ некоторым данным и атрибутам безопасности.
Меры противодействия:
- Ограничить доступ к компьютеру, на котором хранится Депонированная сумка с ключами.
Случай 3: Эксплуатация обычного бэкапа. В обычных бэкапах все ключи классов защиты элементов связки ключей зашифрованы на ключе 0x835. Следовательно, имея доступ к компьютеру с бэкапом и устройству пользователя, можно с помощью утилит Sogeti Labs извлечь ключ 0x835 и расшифровать все элементы связки ключей из бэкапа.
Меры противодействия:
- Ограничить доступ к компьютеру c бэкапами устройства;
- Использовать зашифрованные бэкапы.
Случай 4: Эксплуатация зашифрованного бэкапа. В отличие от предыдущего способа часть ключей сейчас (с 6 по 8) зашифровано на парольном ключе резервной копии, а другая часть (с 9 по 11) на парольном ключе резервной копии и ключе 0x835. Если пароль резервной копии достаточно слабый, то его можно подобрать, а дальнейшие действия ничем не отличаются от предыдущего способа.
Меры противодействия:
- Ограничить доступ к компьютеру c бэкапами устройства;
- Использовать более сложный пароль.
Но не стоит думать, что достаточно сложный пароль будет панацеей от всех атак. Даже самый стойкий пароль не устоит перед социальной инженерией или внедрением вируса в устройства (при условии, что на устройстве сделан jailbreak).
Итак, в этой статье были описаны механизмы iOS, которые на аппаратном и программном уровне защищают данные пользователя, также была показана иерархия криптографических ключей, актуальная для iOS 5. В заключении статьи приведены некоторые возможные атаки, которые позволяют получить доступ к конфиденциальной информации пользователя в обход механизма защиты данных. Надеюсь, что объяснил все более-менее понятно. Следующая, последняя, статья будет носить более информационный и ознакомительный характер, в ней речь пойдет о механизмах, обеспечивающих сетевую безопасность, а также еще о некоторых вспомогательных функциях безопасности.
Основные источники
1. http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf
2. http://theiphonewiki.com/wiki/
3.http://ensiwiki.ensimag.fr/images/4/4d/4MMSR-2021-2021-student_seminar-iPhone_data_protection_in_depth_-_Jean-Baptiste_Bedrune,_Jean_Sigwald_-_HITB_Amsterdam_2021.pdf
4. http://www.slideshare.net/andrey.belenko/ios-forensics-overcoming-iphone-data-protection
5. http://code.google.com/p/iphone-dataprotection/wiki/EncryptionKeys
6. www.exploit-db.com/download_pdf/19767/
7. http://code.google.com/p/iphone-dataprotection/wiki/iTunesBackups
Не забывайте о резервном копировании
Итак, вы обеспечили безопасность данных на вашем телефоне. Теперь стоит убедиться в том, что ваши резервные копии на iCloud или iTunes также шифруются.
В зашифрованных резервных копиях iPhone содержатся сохраненные пароли, учетные данные к Wi-Fi сетям и прочие конфиденциальные данные, которые вам понадобятся в случае утери, кражи или поломки телефона.
В iCloud резервные копии шифруются автоматически. В iTunes, нужно выбрать опцию «Шифровать резервные копии iPhone» в пункте меню «Резервное копирование» на конкретном устройстве. При этом вам понадобится выбрать новый пароль для резервных копий в iTunes.
Итак, вы обеспечили безопасность данных на вашем телефоне. Для надежности важной информации, регулярно обновляйте резервные копии с вашего телефона и проверяйте обновления к iOS и приложениям.
Даже при шифровании iPhone, дыры в ПО и программы-вымогатели представляют опасность. Предприняв некоторые шаги (в т.ч. установив мобильное защитное решение), вы обезопасите себя от потери важной информации при атаках киберпреступников и телефонных воров.
Новая уязвимость на аппаратном уровне
Китайская команда разработчиков Pangu Team неделю назад сообщила о найденной неустранимой неисправности, на этот раз в чипе SEP (Secure Enclave Processor). В зоне риска находятся все устройства iPhone процессорах А7-А11.
SEP хранит ключевую, в буквальном смысле слова, информацию. К ним относятся криптографические функции, ключи аутентификации, биометрические данные и профиль Apple Pay. Он делит часть оперативной памяти с Application Processor, но другая ее часть (известная, как TZ0) зашифрована.
Последовательность загрузки SEP.
Сам SEP представляет собой стираемое 4MB процессорное ядро AKF (вероятно, Apple Kingfisher), патент № 20210308838. Используемая технология аналогична ARM TrustZone / SecurCore, но в отличие от нее содержит проприетарный код для ядер Apple KF в целом и SEP в частности. Он также отвечает за генерацию ключей UID на А9 и более новых чипах, для защиты пользовательских данных в статике.
SEP имеет собственный загрузочный ROM и он так же, как и SecureROM / BootROM защищен от записи. То есть уязвимость в SEPROM будет иметь такие же неприятные и неустранимые последствия. Комбинируя дыру в SEPROM с эксплойтом checkm8, о котором уже выше было сказано, можно изменить регистр отображения I/O для обхода защиты изоляции памяти. В практическом плане это дает возможность злоумышленникам заблокировать телефон без возможности его разблокировать.
Хакеры Pangu продемонстрировали, что они могут использовать ошибку в контроллере памяти, управляющем содержимым регистра TZ0. Всех деталей и исходного кода они не стали раскрывать, надеясь продать свою находку компании Apple.
Известный уже нам исследователь ИБ axi0mX написал в Твиттере, что уязвимостью в SEPROM можно воспользоваться лишь при физическом доступе к смартфону, как и в случае с checkm8. Точнее сама возможность манипуляций с содержимым регистра TZ0 зависит от наличия дыры в SecureROM / BootROM, так как после штатной загрузки iPhone изменить значение регистра TZ0уже нельзя. Новые модели iPhone с SoC A12/A13 не подвержены новой уязвимости.
Определить версию ios
Процесс шифрования iPhone сменился вместе с выпуском iOS 8. В первую очередь выясните, какая версия iOS установлена на вашем телефоне – для этого необходимо запустить в телефоне приложение «Настройки», выбрав в меню «Основные» и затем «Об этом устройстве». Рядом со словом «Версия» вы увидите, какая версия iOS установлена на телефоне.
Пока вы в меню, также можно проверить наличие обновлений ПО (раздел «Обновление ПО») в меню «Основные» и провести обновления, если необходимо. Из соображений безопасности полезно следить за актуальностью установленных версий ПО.
Шифрование за несколько секунд
Личные данные на телефонах Apple шифруются по умолчанию каждый раз, когда телефон блокируется и требуется ввод кода-пароля или вход по отпечатку пальца. Опция включения этой функции находится в другом месте в меню, в зависимости от версии iOS.
В iOS 8 и более поздних версиях эта опция находится в меню «Touch ID и код-пароль» в приложении «Настройки». В iOS более ранних версий опция «код-пароль» находится в меню «Основные» в приложении «Настройки».
Если у вас не включена опция «код-пароль» или Touch ID, то приложение поможет вам шаг за шагом настроить безопасность вашего телефона.
При установке кода-пароля на iPhone предлагается несколько вариантов, от которых зависит, насколько сложно будет взломать ваш телефон.
В некоторых вариантах можно установить авторизацию через отпечаток пальца – это называется Touch ID. При этом следует отметить, что специалисты в области безопасности исследуют, как можно обмануть Touch ID при помощи формовочной глины и 3D принтеров – это может означать, что этот методы защиты не так безопасен, как считается.
Что касается числового кода-пароля, то чем он длиннее и сложнее, тем труднее его подобрать.
Вам также может понадобиться включить опцию «Сменить код-пароль» или «Произвольный код (буквы цифры)» и отключить опцию «Произвольный код (цифры)».
Если ваш код-пароль легко угадать, то утилита должна вас об этом предупредить.
В зависимости от степени важности данных, хранящиеся на вашем телефоне, вы можете настроить ваш iPhone так, чтобы информация на нем автоматически стиралась после определенного числа неудачных попыток войти.
Это может оказаться особенно полезным для рабочих телефонов и личных телефонов, на которых хранится конфиденциальные данные о здоровье или финансах.
При этом, эта функция – это крайняя мера, и ее следует использовать осторожно, особенно если вы даете ваш телефон ребенку поиграть.
Более безопасная альтернатива – это, в случае потери вашего iPhone, удаленно стереть данные с него через вашу учетную запись в iCloud.
