Архив за Сентябрь, 2020

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

Для пользователя резервная копия – удобный и простой способ перенести данные на новое устройство или восстановить уже имеющееся после сброса к заводским настройкам. Для экспертов-криминалистов резервные копии iOS — не менее удобный, универсальный и простой способ извлечь из хорошо защищённого хранилища устройства копию данных. В резервные копии попадает множество важной информации: и данные большинства приложений, и логины с паролями, которые пользователь сохранил в браузере Safari и сторонних приложениях, и пароли к Wi-Fi, и резервные копии часов Apple Watch, и данные об активности пользователя (шаги, сердцебиение в заданный момент времени). Попадают в резервные копии и многие другие вещи, жизненно необходимые для расследования преступлений. В руках злоумышленника резервная копия превращается в опасное оружие. Логины и пароли из Связки ключей позволяют получить доступ к учётным записям, переписке и финансам пользователя. Чтобы этого не произошло, Apple позволяет пользователю установить пароль на резервные копии.

Пароли к резервным копиям iOS

Если пароль установлен, вся резервная копия целиком будет зашифрована стойким ключом, который генерируется на основе пароля. Шифрование происходит внутри устройства; если пароль установлен, то незашифрованные данные просто не покидают телефон. Соответственно, какую бы программу для снятия резервной копии вы ни использовали, результат будет один: зашифрованная резервная копия.

Шифрование локальных резервных копий в iOS настолько стойкое, что даже с использованием аппаратного ускорения нам не удалось получить скорость перебора больше нескольких десятков паролей в секунду. Соответственно, лобовая атака бесполезна даже если используется несложный пароль из 7 знаков. Впрочем, даже при наличии стойкого пароля на шифрование из телефона можно извлечь фотографии и медиа-файлы, если его экран можно разблокировать.

До выхода iOS 11 длинный и сложный пароль на резервную копию был абсолютной защитой; никакой возможности удалить или поменять пароль, не введя предварительно старый, в старых версиях системы не существовало. В iOS 11 ситуация изменилась.

Первая рекурсия: сброс пароля на резервную копию

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

В iOS 11 или более поздней версии можно создать зашифрованную резервную копию устройства, сбросив пароль. Чтобы сделать это, нужно выполнить следующие действия.

  1. На устройстве iOS выберите «Настройки» > «Основные» > «Сброс».
  2. Нажмите «Сбросить все настройки» и введите пароль ОС iOS.
  3. Следуйте инструкциям по сбросу настроек. Это не затронет данные или пароли пользователей, но приведёт к сбросу таких настроек, как уровень яркости дисплея, позиции программ на экране «Домой» и обои. Пароль для шифрования резервных копий также будет удалён. (В скобках: на этом этапе устройство потребует ввести код блокировки экрана).
  4. Снова подключите устройство к iTunes и создайте новую зашифрованную резервную копию.

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

На устройстве с iOS 10 или более ранней версии сброс пароля невозможен. 

Вторая рекурсия: защита от попыток сброса пароля на резервную копию

Лёгкость, с которой злоумышленник может обойти самый сложный и длинный пароль на резервную копию, всего лишь введя код блокировки экрана, неприятно поражает. Однако от этой угрозы можно уберечься. Механизмом защиты здесь станут Ограничения родительского контроля (iOS 11) или пароль Экранного времени (iOS 12 и более поздние).

Допустим, ваш iPhone попал в руки злоумышленника. Предположим, злоумышленнику удалось подсмотреть ваш код блокировки; теперь он пытается отвязать телефон от облака, а заодно извлечь  копию данных, получив доступ к паролям из Связки ключей. Защититься от такого развития событий можно при помощи пароля Экранного времени. Подробно о возможностях контроля Экранного времени можно почитать в статье Apple Использование родительского контроля на устройствах iPhone, iPad и iPod touch ребенка. Нас же сейчас интересует другая возможность этой системы: защитить телефон от сброса пароля на резервную копию.

Как ни странно, ограничить возможность сброса пароля к локальной резервной копии iOS достаточно просто: всё, что нужно сделать, это установить пароль Экранного времени как таковой. Сложность такого пароля невелика: единственный доступный вариант – это PIN-код из 4 цифр. Тем не менее, такая защита в целом достаточно надёжна. Поскольку этот пароль используется очень редко и отличается от кода блокировки устройства, его невозможно случайно подсмотреть. Этот код понадобится в исключительно редких случаях, когда вы захотите изменить настройки или отключить ограничения. Вы можете установить случайный код, записав его на оставленной дома бумажке – и это будет вполне безопасно.

Что произойдёт, если теперь попытаться сбросить пароль на резервную копию? На первом шаге – никаких отличий: система запросит пароль блокировки устройства. А вот сразу после этого будет запрошен дополнительный 4-значный пароль Экранного времени. Эта мера безопасности вполне способна не только отвадить любопытных, но и защитить iPhone от целенаправленных попыток взлома.

Рекурсия третья: как узнать пароль Экранного времени

Пароль Экранного времени сохраняется на самом устройстве. Подобрать его за разумное время невозможно: невеликое пространство из 10,000 комбинаций защищается системой прогрессирующими задержками между попытками ввода. После нескольких неудачных попыток система ограничит скорость перебора паролей Экранного времени, вводя прогрессивные задержки в 1, 5, 15 и 60 минут. После 10 неудачных попыток каждая следующая попытка может быть предпринята не ранее, чем через час после предыдущей; перезагрузка устройства не поможет ускорить процесс. Таким образом, все 10,000 комбинаций можно перебрать за 416 дней.

Однако есть и более интересные способы. Сразу оговорюсь: первый из них работает только тогда, когда пароль на резервную копию не установлен или известен, а второй – если на iPhone можно установить джейлбрейк (включая аппаратный — checkra1n).

Способ 1: извлечь из резервной копии

В iOS 7-11 этот пароль (там он носит название Restrictions) хранится в виде хэша. Алгоритм относительно стойкий (pbkdf2-hmac-sha1, но количество итераций относительно невелико). С учётом того, что пароль этот состоит всегда и только из 4 цифр, полный перебор хэша на компьютере занимает несколько секунд. Сам хэш хранится в файле com.apple.restrictionspassword.plist, который попадает в бэкап. Соответственно, пароль Restrictions можно вскрыть, если у нас есть (одно из):

  • резервная копия iOS без пароля
  • резервная копия iOS с паролем, плюс пароль от него

В iOS 12 (здесь это пароль Экранного времени, или Screen Time) хранится в открытом виде. Нет, безопасность от этого хуже не стала: пароль переместили в Связку ключей. Тем не менее, класс защиты паролю Экранного времени назначили минимальный: он не привязан к устройству. Минимальный класс защиты назначен умышленно. Сделано это для того, чтобы при восстановлении нового iPhone из бэкапа пароль Экранного времени устанавливался автоматически (таким образом Apple закрыли потенциальную возможность снять пароль Экранного времени путём создания резервной копии, сброса устройства и последующего восстановления из резервной копии). Записи Связки ключей с более высокими классами защиты не попадают в резервные копии или попадают, но защищаются аппаратным ключом устройства (то есть, могут быть восстановлены только на то же самое устройство).

Чтобы достать пароль Экранного времени, нужно:

  • резервная копия iOS с паролем плюс пароль от него

Способ 2: через джейлбрейк

Очевидно, что первый способ сработает лишь тогда, когда пароль на резервную копию не установлен или известен. Если же пароль на резервную копию установлен, но неизвестен, то единственный оставшийся способ узнать пароль Экранного времени – получить доступ к Связке ключей (keychain). Для старых версий iOS нужна копия файловой системы.

Для iOS 7-11 нужно:

  • образ файловой системы

Для iOS 12:

  • Связка ключей

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

One more thing

Что интересно, пароль Экранного времени хранится также и в облаке iCloud, но только в том случае, если вы включили двухфакторную аутентификацию и активировали опцию Screen Time “Share across devices”. Сам ключ при этом не попадает в Облачную связку ключей, а хранится отдельно (примерно в том же виде, что и ключ восстановления доступа к зашифрованным томам FileVault 2). Извлечь его из iCloud (и просмотреть) можно посредством Elcomsoft Phone Breaker. Для этого вам понадобится всё перечисленное ниже:

  • логин и пароль от Apple ID (iCloud) пользователя
  • код блокировки экрана устройства
  • доступ ко второму фактору аутентификации (им является само устройство, если известен код блокировки; впрочем, достаточно и SIM-карты с доверенным телефонным номером)

А вот сценарий со сбросом устройства и последующим восстановлением его из «облачной» резервной копии мы не проверяли, поэтому я не могу точно сказать, активируется ли пароль Экранного времени, если создать резервную копию в iCloud, сбросить iPhone и восстановиться из облака.

Рекурсия четвёртая, последняя: как защитить доступ к паролю Экранного времени

Вот мы и подошли к последнему пункту. Если ваша цель – максимально обезопасить устройство, то в ваших интересах сделать так, чтобы пароль Экранного времени ни сбросить, ни узнать было нельзя.

Хорошая новость в том, что защитить пароль Экранного времени от обывателя и даже профессионального взломщика довольно просто: достаточно установить длинный и стойкий пароль на резервную копию, после чего просто поддерживать устройство в актуальном состоянии, устанавливая свежие версии iOS сразу после их выхода. Джейлбрейки для новых версий iOS выходят далеко не сразу. Иногда между выходом обновления iOS и появлением для неё работоспособного джейлбрейка проходят месяцы.

Опасаться можно сценария, когда украденное устройство (с известным злоумышленнику кодом блокировки) будет положено на полку в ожидании появления джейлбрейка, либо если для вашего телефона (iPhone 8, 8 Plus, iPhone X или более старое поколение) есть аппаратный джейлбрейк checkra1n. Здесь, однако, может помочь стандартная «Стереть [устройство]», выполненное в портале Find my iPhone. Дело в том, что для установки джейлбрейка требуется сначала подписать IPA-файл, а потом и подтвердить цифровую подпись непосредственно на самом iPhone. Подтверждение цифровой подписи происходит на сервере Apple; то есть, злоумышленнику придётся разрешить украденному у вас iPhone выйти в интернет. В этот момент с большой вероятностью сработает команда на стирание устройства.

Злоумышленники могут решить эту проблему, используя специальные конфигурации роутера, в которых будет запрещён доступ к узлам, ответственным за функционал Find My iPhone. Кроме того, вместо обычного сертификата для подписи джейлбрейка могут использовать сертификат разработчика, который не требует выхода iPhone в сеть для подтверждения цифровой подписи.

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

Шифрованием данных пользуются все, кто взаимодействует с современной электроникой. Будь то BitLocker, FileVault, LUKS, VeraCrypt или встроенная в смартфоны Android и Apple система шифрования, пользователь привык к определённому набору функций. Пароль от зашифрованного раздела всегда можно сменить, и это происходит практически мгновенно, а для очистки зашифрованного накопителя достаточно уничтожить ключи шифрования, после чего данные невозможно расшифровать даже с правильным паролем. Наконец, мы привыкли к тому, что системы защиты подробно документированы, а их стойкость постоянно пробуют на зуб независимые исследователи.

А что, если речь идёт не о персональном компьютере, не о смартфоне или планшете, а о специализированном устройстве, основная и единственная цель которого – надёжное и безопасное хранение больших объёмов данных? Наверное, в таких устройствах шифрование данных реализовано на высшем уровне? Производители сетевых хранилищ не стесняются открытым текстом писать о защищённости, шифровании «как у военных» и прочих приятных уху и глазу вещах. Но если копнуть чуть глубже, выясняются удивительные вещи.

Шифрование в сетевых накопителях (NAS)

Рынок сетевых хранилищ для домашних и офисных пользователей выглядит достаточно интересно. Самыми массовыми являются модели от Western Digital, одного из крупнейших производителей жёстких дисков. NAS от WD подкупают низкой ценой, часто – отрицательной: диск в накопителе обходится дешевле такого же диска отдельно. При этом шифрования данных в массовых моделях WD просто нет.

Особое место занимает компания Synology, домашние сетевые накопители которой отличаются красивым, хорошо оптимизированным софтом, качественной, хоть и не самой производительной, аппаратной платформой и длительным периодом поддержки – за соответствующие деньги. Популярностью пользуются и устройства основного конкурента – компания QNAP. В роли догоняющих выступают такие производители, как ASUS (Asustor), TerraMaster и Netgear. Не выдержав конкуренции, сошли с дистанции Thecus и малоизвестные у нас Drobo и Buffalo, которая может похвастаться вынесенной в начало статьи рекламной картинкой.

В отличие от Western Digital, большинство моделей этих производителей поддерживает шифрование, позволяющее защитить пользовательские данные. Производители поделились на два лагеря: представители одного из них (QNAP, Thecus) используют шифрование дисков на уровне тома, в то время как второй лагерь (Synology, Asustor, TerraMaster) используют шифрование отдельных сетевых папок на уровне файловой системы. У каждого способа есть свои преимущества и недостатки. В рамках данной статьи нас интересуют представители второго лагеря, использующие для шифрования криптографическую файловую систему eCryptFS.

Неоднозначное шифрование

Возможно ли представить ситуацию, в которой на обычном домашнем компьютере окажется невозможно сменить пароль к зашифрованным данным (если, конечно же, использовался именно пароль, а не аппаратный модуль с ключом)? Возможно ли шифрование, которое не позволяет моментально уничтожить информацию, потому что ключи не хранятся в одном месте, а равномерно распределены по всему диску? Или ситуацию, в которой неавторизованному пользователю доступна полная структура файловой системы, количество и размер зашифрованных файлов? Современные схемы шифрования дисков в Windows, macOS и Linux не допускают подобных сценариев.

Однако многие производители специализированных сетевых хранилищ, даже те из них, которые предлагают «безопасное шифрование AES-256» не используют шифрование тома. Вместо этого шифрованию подвергаются отдельные папки, а в них – отдельные файлы с использованием шифрующей файловой системы eCryptFS. Насколько стойким является шифрование eCryptFS в сравнении с шифрованием всего диска, какие у него есть особенности, преимущества и недостатки? Попробуем разобраться.

Шифрование средствами файловой системы: безопасность

Encrypting File System — общее название для класса криптографических файловых систем, которые шифруют данные на уровне отдельных папок и файлов. Криптографические файловые системы предоставляют возможность «прозрачного шифрования» данных. Цель криптографических файловых систем – защита данных от несанкционированного доступа при физическом доступе как к накопителям, извлечённым из компьютера, так и к самому компьютеру (в том числе и от других авторизованных пользователей компьютера, авторизованных в собственных учётных записях).

От каких именно угроз способно, а от каких – не способно защитить шифрование средствами файловой системы?

Стойкость защиты: невысокая. Да, производитель может использовать шифрование AES с 256-битным ключом, но энтропия пароля среднего пользователя (что это такое и как подсчитать) намного ниже 256 бит. При этом отозвать скомпрометированный пароль или изменить его нельзя: потребуется длительная процедура перешифровки метаданных всех файлов или даже самих файлов. В сетевых хранилищах от Synology раз установленный пароль шифрования сменить нельзя: можно лишь сначала расшифровать, а потом заново зашифровать папку. Скорость перебора паролей к eCryptFS относительно VeraCrypt или даже BitLocker высокая (65,537 итераций SHA-512 по умолчанию против 500,000 у VeraCrypt), что также не добавляет ей стойкости.

Если диск извлекут из NAS: стойкость защиты в лучшем случае соответствует стойкости пароля шифрования; в худшем (ключи шифрования хранятся на самом диске) – нулевая. При этом даже в лучшем случае (зашифрованная папка не смонтирована, пароль – неизвестен) неавторизованный пользователь:

  • Получит доступ к дереву файловой системы (структуре папок)
  • Узнает точное число файлов и объём зашифрованных данных
  • Узнает точный размер каждого зашифрованного файла, что позволит произвести профилирование по размеру (поиск совпадений по размерам файлам)
  • Сможет произвольно удалить один или несколько файлов и папок
  • Сможет скопировать метаданные и произвести атаку на пароль

Утилизация, продажа, гарантийный обмен диска: уничтожить зашифрованные данные, просто удалив ключ, невозможно. Для уничтожения данных придётся стереть метаданные каждого файла по отдельности, что может занять существенное время. Проще и надёжнее целиком отформатировать диск, что далеко не всегда возможно при возникновении гарантийной ситуации.

Защита от физического доступа к NAS: низкая. Криптографическая файловая система не защитит файл /etc/shadow от редактирования. Да, для этого может потребоваться извлечь диск из устройства – но при использовании шифрования сетевых папок в качестве единственного эшелона обороны системные файлы никак не защищены.

Удалённые атаки, зловредное ПО, вирусы-шифровальщики: если зашифрованная папка смонтирована, то влияние шифрования папок на реальную безопасность данных нулевое. Если же папка не смонтирована, то степень защиты зависит от того, хранятся ли ключи в самом NAS или же пользователь вводит пароль каждый раз при доступе к зашифрованной папке. К слову, от вирусов-шифровальщиков помогает защититься использование файловой системы BTRFS с регулярным созданием «теневых копий».

Сильные стороны eCryptFS

Во всех исследованных NAS, использующих шифрование сетевых папок, защита реализована средствами стандартной для Linux файловой системы eCryptFS, о которой можно почитать здесь или здесь. Почему такие производители, как Synology и Asustor (а в моделях с процессорами Intel — в качестве доступной опции и QNAP), выбрали шифрование на уровне сетевых папок, а не более распространённый вариант шифрования на уровне тома с использованием LUKS? Дело в том, что при всех своих недостатках eCryptFS обладает и целым рядом достоинств.

  1. Уже готовое, проверенное решение: не нужно разрабатывать самостоятельно (обычно качественно реализовать вещи, которые относятся к безопасности, у производителей NAS не получается, поэтому использование готовых компонентов – меньшее зло).
  2. Стандартная реализация шифрования позволяет просто скопировать зашифрованную папку целиком на другой накопитель или удалённое сетевое хранилище без расшифровки файлов в процессе копирования. При этом смонтировать и расшифровать такую папку получится стандартными средствами на любом компьютере с Linux. Приятный бонус: зашифрованные файлы можно скопировать и на диск, отформатированный в NTFS или FAT32/exFAT.
  3. Бесплатно: не нужно платить за лицензии, снижается себестоимость устройства.
  4. Безопасное резервное копирование: для создания и поддержания резервных копий (в том числе – инкрементных) нет необходимости расшифровывать данные и монтировать зашифрованные сетевые папки. Администратору не нужно знать пароли от каждой из зашифрованных папок – данные всё равно будут корректно скопированы или восстановлены. Изменения в незашифрованных файлах отражаются и в зашифрованных. Важный с точки зрения безопасности момент: нет необходимости хранить пароли или ключи шифрования в самом NAS, что делает процесс резервного копирования не только удобным, но и безопасным.
  5. Поскольку шифруются отдельные сетевые папки, не имеет значения, на каком из физических или логических накопителей они расположены. Главное, чтобы была поддержка на уровне файловой системы. Впрочем, шифрование сетевых папок на внешних накопителях, которые можно подключить к NAS через USB, не поддерживает ни один производитель NAS независимо от того, какая на внешнем устройстве файловая система. (В накопителях Asustor можно назначить один или несколько встроенных дисков в качестве архивных; для таких дисков шифрование доступно, но на уровне тома, а не средствами eCryptFS).
  6. Каждый пользователь может зашифровать свою папку своим собственным паролем. Таким образом, обеспечивается защита данных каждого авторизованного пользователя NAS от других авторизованных пользователей.
  7. Шифруются как сами данные, так и имена папок и файлов. Но не структура каталогов, количество и размер файлов.

Слабые стороны eCryptFS

Есть у eCryptFS и ряд недостатков, способных серьёзно повлиять на опыт использования NAS или даже сделать шифрование невозможным.

  1. Шифрование папок не является «сквозным шифрованием». Анализ зашифрованной папки позволит узнать следующую информацию:
    1. Структуру папок
    2. Количество и размер зашифрованных файлов
    3. Объём зашифрованных данных
  2. Ограничения на длину имени файла. В зашифрованной eCryptFS папке длина имени файла (или папки) не может превышать 143 символа ANSI или 47 символов иероглифической записи (почему так). Это ограничение идёт с давних времён, и связано оно в первую очередь с тем, что криптографические файловые системы – своеобразные «костыли», работающие поверх обычных файловых систем. К примеру, зашифрованное имя файла ~/.bashrc может выглядеть следующим образом:
    dWek2i3.WxXtwxzQdkM23hiYK757lNI7Ydf0xqZ1LpDovrdnruDb1-5l67.EU--
  3. (Synology DSMx) Для зашифрованных папок не поддерживается NFS.
  4. Ключ шифрования – хэш от пароля. Почему это плохо? Если данные зашифрованы непосредственно паролем или его хэшем, смена пароля приводит к необходимости перешифровки всех файлов. Именно по этой причине в сменить пароль нельзя; можно лишь расшифровать и заново зашифровать папку – развлечение на несколько дней, если речь идёт о большом объёме данных). Как делать правильно? Разделять ключи шифрования данных и ключи шифрования ключей шифрования. Собственно пароль в правильной схеме шифрования должен использоваться исключительно для шифрования ключей, которыми, в свою очередь, будут зашифрованы сами данные (так, к примеру, сделано в реализации EFS в Windows).
  5. Потенциально низкая энтропия пароля. Простая логика: если ключ шифрования не сохранять на устройстве (что является эквивалентом отсутствия шифрования), то пароль придётся вводить каждый раз для доступа к зашифрованным данным. В такой ситуации большинство пользователей использует пароль с чрезвычайно низкой энтропией, восстановить который в случае атаки будет довольно просто. И мало того, что пароль может быть с невысокой энтропией, так его ещё и сменить не получится.
  6. Метаданные шифрования хранятся в каждом файле. Это приводит к тому, что быстро и надёжно удалить зашифрованную информацию невозможно. Удаление зашифрованной папки не приводит к безвозвратному уничтожению зашифрованных данных (а вот быстрое форматирование тома BitLocker или FileVault 2 – приводит).

Чем может грозить утечка таких данных, как объём зашифрованной информации, количество файлов и размер каждого файла? Как минимум – отказом «правдоподобного отрицания». Соответственно, к зашифрованным папкам применимы такие атаки, как профилирование по размеру файлов, что позволяет узнать содержимое зашифрованной папки, если размер заданного количества файлов совпадает с размером файлов, известных атакующему.

Рекомендации: как обезопасить зашифрованные данные

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

  1. Запомните: единожды установленный пароль шифрования сменить не получится без полной расшифровки папки с последующим шифрованием файлов новым паролем. Внимательно отнеситесь к выбору пароля. Установите длинный пароль с высокой энтропией, желательно – набор случайных символов. Имейте в виду, что скорость атаки на eCryptFS высокая, и пароль с низкой энтропией может быть восстановлен очень быстро.
  2. Ни в коем случае не сохраняйте ключ шифрования в самом устройстве. Если необходимо автоматически монтировать зашифрованные папки, сохраните ключ на внешнем USB накопителе.
  3. Если ключ шифрования сохраняется на USB накопителе (например, в случае офисного NAS), обеспечьте физическую безопасность этого накопителя.
  4. Проконтролируйте процесс создания и сохранения резервного ключа (в Synology это файл с расширением .key, который будет сохранён на компьютере автоматически после создания зашифрованной папки). Этот ключ имеет смысл сохранить в зашифрованном виде (в архиве с паролем или на зашифрованном диске).
  5. Продумайте стратегию автоматического монтирования зашифрованных папок. Автоматическое монтирование зашифрованных данных при загрузке – эквивалент отсутствия безопасности.

Заключение

Выбор средств защиты – всегда компромисс между удобством и безопасностью. И если Microsoft и Apple удалось разработать безопасные и удобные решения, то у производителей сетевых хранилищ получился выбор между неудобной защитой с неровным уровнем безопасности и удобной – с нулевым уровнем защиты. В то же время даже такое шифрование позволит защитить данные от некоторых видов угроз. Главное – правильно настроить шифрование и чётко понимать, против каких угроз такая защита эффективна, а против каких – бесполезна.

 

BitLocker — одно из самых распространённых решений шифрования дисков в Windows. BitLocker используется как в организациях, так и для защиты портативных устройств — ноутбуков и устройств-трансформеров под управлением Windows. В то же время BitLocker может заблокировать доступ к зашифрованным данным, если пароль для входа в Windows утерян. Мы предлагаем решение на основе загрузочного USB-накопителя, позволяющее восстановить доступ к учётным записям Windows для систем, защищённых BitLocker. В этой статье нет ни слова о том, как взломать шифрование томов BitLocker. Мы рассказываем о том, как получить доступ к учётным записям пользователей Windows, если загрузочный диск зашифрован, но в вашем распоряжении есть депонированный ключ или один из доступных протекторов — факторов, позволяющих разблокировать том.

Методы защиты BitLocker

В предыдущей статье Механизмы защиты BitLocker: какие диски можно, а какие нельзя взломать мы подробно описали, какие типы протекторов (факторов, позволяющих разблокировать том BitLocker) существуют и какие из них можно взломать. Существуют такие типы протекторов, как TPM, TPM+PIN, TPM+USB, TPM+USB+PIN, USB и «только пароль». Методом перебора можно вскрыть лишь последний из них — «только пароль». Системные (загрузочные) диски таким способом защищают редко, а вот дополнительные разделы и внешние накопители защитить другим способом затруднительно. В результате подавляющее большинство как внешних, так и встроенных дисков в системе, за исключением загрузочного, обычно защищено именно паролем и только им.

А что насчёт остальных типов протекторов? Если отвлечься от мощной, но чрезвычайно технически сложной атаки методом холодной загрузки, то остаётся лишь вариант с использованием депонированного ключа — последовательности из 48 цифр, которая сохраняется по умолчанию либо в учётной записи пользователя Microsoft Account, либо, если речь идёт о корпоративном компьютере, в Active Directory.

И если при помощи пароля можно смонтировать или расшифровать соответствующий том даже если пароль к учётной записи пользователя утрачен (к примеру, сотрудник покинул компанию), то что-либо сделать в такой ситуации с загрузочным диском, для которого есть депонированный ключ, достаточно сложно. Microsoft не предлагает внятного способа для восстановления доступа к учётной записи пользователей Windows, если загрузочный томе зашифрован с помощью BitLocker. Восстановить или сбросить пароль к учётной записи пользователя не получится, даже если в вашем распоряжении есть депонированный ключ. По сути, единственный штатный способ восстановить доступ к системе — загрузиться с диска восстановления Windows и смонтировать зашифрованный том, введя ключ восстановления. Однако потом вам придётся либо переустановить Windows, либо скопировать данные с зашифрованного тома. Просто сбросить пароль от учётной записи вы не сможете.

Мы предлагаем более простой способ. Начиная с версии 7.05, Elcomsoft System Recovery может разблокировать тома, зашифрованные BitLocker, путём загрузки с USB накопителя. Разумеется, просто вскрыть защиту нельзя: вам в любом случае понадобится депонированный ключ или пароль к зашифрованному тому.

Какие протекторы поддерживаются

О тому, какие именно протекторы существуют, подробно рассказано в статье Механизмы защиты BitLocker: какие диски можно, а какие нельзя взломать. Сегодня перед нами не стоит задача взлома соответствующего протектора; всё, что нам требуется осуществить — это получить доступ к учётным записям системы, загрузившись с USB накопителя. В зависимости от типа протектора доступны следующие варианты.

  • TPM. Достаточно часто используется для защиты системных накопителей, особенно в портативных компьютерах. Elcomsoft System Recovery поддерживает такие тома, если у вас есть наготове депонированный ключ.
  • Только пароль. Второй по популярности тип протектора; чаще всего встречается на внешних дисках и разделах, не являющихся системными. ESR предлагает сразу два способа смонтировать такие тома: паролем тома (если он известен) либо депонированным ключом.
  • USB. В компьютерах, не оборудованных модулем TPM или платформой Intel PTT, иногда используют защиту в виде ключа USB. Для этого требуется редактирование групповых политик Windows; зашифрованный том разблокируется автоматически при наличии так называемого Startup Key. ESR может смонтировать такие тома при наличии либо самого ключа Startup Key, либо депонированного ключа.
  • TPM+PIN, TPM+USB, TPM+PIN+USB. Данные комбинации потребуют наличия всех без исключения протекторов. В рамках Elcomsoft System Recovery данные типы протекторов поддерживаются только при наличии депонированного ключа.

Для удобства мы свели данные в таблицу. В первой колонке (Supported in ESR 7.05) приводится информация о том, можно ли смонтировать том BitLocker, если в вашем распоряжении есть указанный протектор (к примеру, ключ, пароль или PIN-код). В правой колонке указано, можно ли смонтировать том, если у вас есть доступ к депонированному ключу.

Как смонтировать зашифрованный том

Для загрузки в Elcomsoft System Recovery необходимо создать загрузочный накопитель в ESR 7.05 или новее. Чтобы создать загрузочный USB накопитель, запустите программу на своём (а не на исследуемом) компьютере и следуйте указаниям мастера.

После создания загрузочного накопителя используйте его для загрузки целевого компьютера. После загрузки компьютера будет запущено приложение Elcomsoft System Recovery. Инструмент автоматически просканирует доступные жёсткие диски на предмет зашифрованных томов. Если ESR обнаружит хотя бы один том BitLocker, будет выведено предложение разблокировать диск:

Для продолжения нажмите Yes и Next.

В следующем окне ESR отобразит букву диска и тип протектора. Если будет обнаружен хотя бы один неподдерживаемый протектор, такие протекторы не будут показаны по умолчанию. Чтобы отобразить все протекторы, включая неподдерживаемые, снимите флажок «Show supported disk protectors only».

Как только флажок будет снят, вы увидите неподдерживаемые протекторы. В приведённом ниже примере загрузочный диск был защищён двумя протекторами: TPM+PIN (напрямую не поддерживается в ESR) и депонированным ключом (Recovery Key), который в ESR поддерживается.

Чтобы разблокировать диск, введите ключ восстановления (48 цифр) в поле «Numerical password», затем нажмите «Unprotect». Если ключ восстановления правильный, том будет успешно разблокирован.

Встречаются тома BitLocker, защищённые сразу несколькими протекторами, которые поддерживаются ESR. В приведённом ниже примере том был защищён паролем, а ключ восстановления был создан в качестве дополнительного (резервного) протектора. Собственно, именно так обычно и защищены все диски, кроме загрузочных. В этом случае укажите тот тип протектора, к которому у вас есть доступ. Например, если вы знаете пароль к тому BitLocker, выберите «Password».

 

BitLocker — одно из наиболее продвинутых и, наверное, самое популярное решение для шифрования дисков. BitLocker подробно документирован и отлично изучен. Время от времени в механизме обнаруживались уязвимости, но область их использования была весьма специфичной, а сами уязвимости исправлялись с очередным обновлением Windows. Тома BitLocker могут быть защищены одним или несколькими предохранителями, такими как аппаратный TPM, пароль пользователя, USB-ключ или их комбинация. Атака на пароль возможна только в одном из этих случаев, в то время как другие средства защиты требуют совсем другого набора атак. В этой статье мы подробно расскажем о механизмах защиты BitLocker и о подходах, которые можно использовать для расшифровки томов.

Как устроено шифрование диска

Для шифрования диска BitLocker последовательно использует несколько разных ключей, каждый из которых служит своей цели.

В документации Microsoft описано, что данные на диске шифруются специальным ключом, который называется полным ключом шифрования тома. Этот ключ, в свою очередь, шифруется основным ключом тома. Уже основной ключ тома будет зашифрован при помощи одного из нескольких возможных методов в зависимости от типа протектора (двоичного ключа, пароля или модуля TPM).

Полный ключ шифрования тома шифруется основным ключом тома и хранится в заголовке зашифрованного диска (так называемые «метаданные шифрования»). Основной ключ тома также хранится на зашифрованном диске; он тоже зашифрован. Для шифрования основного ключа тома используется пароль пользователя (если речь идёт о сменном носителе), двоичный ключ или сертификат либо данные модуля TPM.

Что происходит, если защита BitLocker приостанавливается или пользователь отключает защиту, решив «расшифровать» диск? В этом случае данные физически не расшифровываются и не перезаписываются; однако система сохраняет в незащищённом виде ключ, которым шифруется основной ключ тома.

С точки зрения Microsoft, такая процедура хранения гарантирует, что основной ключ тома никогда не хранится без шифрования и всегда защищён, если не отключено шифрование BitLocker. Для обеспечения избыточности система сохраняет ещё две копии ключей в разных местах на диске.

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

Где хранятся все эти ключи? Полный ключ тома, защищённый основным ключом тома, хранится в заголовке контейнера (и двух дополнительных местах на диске) в зашифрованном виде. Это хранилище мы называем метаданными шифрования, и именно эти данные извлекают продукты Elcomsoft Forensic Disk Decryptor и Elcomsoft System Recovery для последующих атак. Основной ключ тома, зашифрованный паролем или другим протектором, сохраняется в них же. А вот протектор (пароль пользователя, данные модуля TPM, двоичный ключ или сертификат) в составе контейнера не хранятся: именно эти данные будут использованы для расшифровки цепочки ключей и, соответственно, данных на диске.

Методы защиты

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

Во-первых, определим, есть ли в системе зашифрованные диски в принципе. Рекомендуем воспользоваться нашим бесплатным инструментом Elcomsoft Encrypted Disk Hunter для определения зашифрованных дисков.

Если найден зашифрованный том, то в Windows тип протектора тома можно определить, запустив следующую команду (зашифрованный том должен быть смонтирован):

manage-bde -protectors -get X:

Здесь X: — буква тома.

Если же в вашем распоряжении только диск или его образ, то используйте Elcomsoft Forensic Disk Decryptor для извлечения метаданных шифрования и Elcomsoft Distributed Password Recovery для попытки атаки.

Итак, рассмотрим возможные типы протекторов.

TPM

Аппаратные модули TPM часто используются в портативных компьютерах – ноутбуках, планшетах и устройствах 2-в-1. При использовании защиты TPM Windows загрузится до запроса входа в систему. Основной ключ тома будет расшифрован с помощью корневого ключа хранилища, который хранится в модуле TPM (или Intel PTT). Ключ будет выдан наружу в том и только в том случае, если система проходит проверку безопасной загрузки. Этот вариант совершенно прозрачен для пользователя: многие даже не подозревают, что их ноутбук или планшет зашифрован.

Векторы атаки: ввиду отсутствия пароля шифрования для доступа к тому, защищённому аппаратным модулем TPM, используйте одну из следующих стратегий.

  1. Ключ восстановления доступа BitLocker. Windows автоматически создаёт ключ восстановления при шифровании BitLocker Device Protection; такие ключи восстановления автоматически загружаются в учётную запись Microsoft Account первого пользователя компьютера, который вошёл в систему с административными привилегиями. Вы можете запросить этот ключ у Microsoft или загрузить его, войдя в учётную запись Microsoft и перейдя по следующей ссылке: https://account.microsoft.com/devices/recoverykey
  2. Дополнительные варианты. Ключ восстановления доступа может храниться в других местах – например, в Active Directory: Где найти ключ восстановления BitLocker?
  3. Атака методом холодной загрузки. BitLocker в конфигурации по умолчанию использует доверенный платформенный модуль TPM (если таковой установлен), которому для расшифровки диска не требуется ни пин-код, ни внешний ключ. Когда операционная система загружается, BitLocker извлекает ключ из TPM без какого-либо взаимодействия с пользователем. Следовательно, можно просто включить машину, подождать, пока операционная система начнёт загрузку, а затем выполнить атаку методом холодной загрузки для извлечения ключа из оперативной памяти компьютера. Обратите внимание, что эта атака недоступна, если в дополнение к TPM использовался пароль или ключ.Что такое атака методом холодной загрузки? Это технически сложный вид атаки, в процессе которого производится заморозка чипов памяти жидким азотом или сжатым воздухом, после которой питание компьютера отключается, а модули памяти физически извлекаются (или производится загрузка с USB-накопителя) с целью доступа к содержимому оперативной памяти и поиска ключей шифрования. Помимо исключительной технической сложности этого типа атаки, у него есть и ещё один недостаток: он работает только с компьютерами, модули памяти в которых не распаяны (т.е. их физически можно извлечь).
  4. Образ оперативной памяти. Если у вас есть доступ к компьютеру пользователя и вы можете войти в систему или получить дамп памяти с помощью атаки через интерфейс FireWire/Thunderbolt, то можно извлечь получить ключи шифрования непосредственно из оперативной памяти компьютера. В состав Elcomsoft Forensic Disk Decryptor входит как утилита для снятия образа оперативной памяти, так и инструмент для его анализа с целью поиска ключей шифрования.

TPM + ПИН

В этом режиме для загрузки Windows потребуется не только модуль TPM, но и дополнительный ключ (ПИН-код или пароль). Модуль TPM выдаст ключ шифрования в том и только в том случае, если на вход будет подан правильный пароль (ПИН). Как правило, длина ПИН-кода не превышает 4 цифр, но после нескольких неудачных попыток модуль TPM заблокирует доступ к ключу шифрования.

Векторы атаки: Режим TPM+ПИН – интерактивный: от пользователя требуется ввести ПИН-код, причём именно на том компьютере, на котором использовался зашифрованный диск. Сам по себе ПИН-код не используется для шифрования; он нужен для того, чтобы аппаратный модуль TPM выдал системе необходимый ключ. Перебор ПИН-кодов опасен: в зависимости от производителя и настроек модуля перебор может привести как к блокировке модуля TPM, так и к уничтожению ключа шифрования.

  1. Ключ восстановления доступа BitLocker. Windows автоматически создаёт ключ восстановления при шифровании BitLocker Device Protection; такие ключи восстановления автоматически загружаются в учётную запись Microsoft Account первого пользователя компьютера, который вошёл в систему с административными привилегиями. Вы можете запросить этот ключ у Microsoft или загрузить его, войдя в учётную запись Microsoft и перейдя по следующей ссылке: https://account.microsoft.com/devices/recoverykey
  2. Атака методом холодной загрузки сработает лишь в том случае, если вам известен ПИН-код. В противном случае система не загрузится, а ключ шифрования не попадёт в оперативную память.
  3. Образ оперативной памяти. Сработает только в том случае, если компьютер уже загружен. Используйте Elcomsoft Forensic Disk Decryptor для снятия образа оперативной памяти и его анализа с целью поиска ключей шифрования.

TPM + USB

Этот вариант для загрузки системы требует присутствия как TPM, так и USB-накопителя (или смарт-карты CCID). Это нестандартная, но возможная конфигурация.

Векторы атаки: Режим TPM+USB требует наличия файла с ключом на USB-накопителе. Соответственно, вам потребуется доступ к этому накопителю (а точнее, к ключу на нём).

  1. Ключ восстановления доступа BitLocker. Никаких различий с предыдущим протектором.
  2. Атака методом холодной загрузки сработает лишь в том случае, если в наличии есть USB накопитель с ключом. В противном случае система не загрузится, а ключ шифрования не попадёт в оперативную память.
  3. Образ оперативной памяти. Сработает только в том случае, если компьютер уже загружен. Используйте Elcomsoft Forensic Disk Decryptor для снятия образа оперативной памяти и его анализа с целью поиска ключей шифрования.

TPM + ПИН + USB

Довольно редкая реализация «параноидальной» защиты, комбинирующая два предыдущих метода. Уже из названия очевидно, что для загрузки системы потребуется и модуль TPM, и ввод ПИН-кода, и наличие USB накопителя с ключом.

Векторы атаки: Режим TPM+USB требует наличия файла с ключом на USB-накопителе и ввода ПИН-кода в дополнение к аппаратному модулю TPM. Соответственно, для доступа к данным вам потребуется всё вышеперечисленное.

  1. Ключ восстановления доступа BitLocker. Никаких различий с предыдущим протектором.
  2. Атака методом холодной загрузки сработает лишь в том случае, если в наличии есть USB накопитель с ключом, а ПИН-код вам известен. В противном случае система не загрузится, а ключ шифрования не попадёт в оперативную память.
  3. Образ оперативной памяти. Сработает только в том случае, если компьютер уже загружен. Используйте Elcomsoft Forensic Disk Decryptor для снятия образа оперативной памяти и его анализа с целью поиска ключей шифрования.

USB

Переходим от сложного – к простому. Вариант с ключом на USB накопителе гораздо проще взломать по сравнению с использованием модулей TPM. Для расшифровки диска вам понадобится только USB накопитель с ключом.

Векторы атаки: Пароля по-прежнему нет; для расшифровки диска нужен накопитель с ключом.

  1. Ключ восстановления доступа BitLocker. Никаких различий с предыдущим протектором.
  2. Атака методом холодной загрузки в данной ситуации лишена смысла. С одной стороны, атака сработает лишь в том случае, если в наличии есть USB накопитель с ключом. С другой — если в нашем распоряжении есть накопитель с ключом, то смонтировать зашифрованный раздел можно гораздо проще.
  3. Образ оперативной памяти. Сработает только в том случае, если компьютер уже загружен. Используйте Elcomsoft Forensic Disk Decryptor для снятия образа оперативной памяти и его анализа с целью поиска ключей шифрования.

Только пароль

Наконец, мы подошли к единственному протектору, который можно взломать методом полного перебора. Протектор «только пароль» защищает ключ исключительно паролем пользователя – который можно подобрать при помощи Elcomsoft Distributed Password Recovery. Более того, атаку можно проводить на другом компьютере как на сам диск, так и на его образ – модуль TPM в данной схеме не участвует, поэтому никаких ограничений на количество попыток или скорость перебора нет.

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

  1. Ключ восстановления доступа BitLocker. Никаких различий с предыдущим протектором.
  2. Атака методом холодной загрузки так же, как и в предыдущем случае, лишена смысла. С одной стороны, атака сработает лишь в том случае, если вы уже знаете пароль от зашифрованного тома. С другой — если вы знаете пароль, то и атака не нужна.
  3. Образ оперативной памяти. Сработает только в том случае, если компьютер уже загружен. Используйте Elcomsoft Forensic Disk Decryptor для снятия образа оперативной памяти и его анализа с целью поиска ключей шифрования.
  4. Перебор паролей. Используйте Elcomsoft Forensic Disk Decryptor для извлечения метаданных шифрования из самого диска или его образа. Метаданные шифрования откройте в Elcomsoft Distributed Password Recovery для настройки атаки. Вы также можете использовать Elcomsoft System Recovery для загрузки компьютера пользователя с USB накопителя с целью извлечения метаданных шифрования без разборки компьютера и извлечения самого диска.

Когда пароля нет

Если пароль не установлен или если пароль используется совместно с другим типом протектора, пытаться его подобрать – занятие бессмысленное. Даже если вы извлекли метаданные шифрования и загрузили их в Elcomsoft Distributed Password Recovery, вы не сможете запустить атаку: продукт выдаст сообщение о несовместимом типе протектора. Именно таким образом обычно и развиваются события в случаях, когда в деле фигурирует модуль аппаратной защиты TPM. Запомним: атака на пароль в случае, если том BitLocker зашифрован с протектором типа TPM, бессмысленна; расшифровать такой диск можно либо депонированным ключом (например, извлечённым из хранилища OneDrive в учётной записи пользователя Microsoft Account), либо ключом, который извлекается из оперативной памяти загруженного компьютера пользователя. Об этом – подробнее.

Что произойдёт, если мы имеем дело не с отдельным диском и не с его образом, а с уже загруженным компьютером, на котором смонтирован зашифрованный том BitLocker? В этом случае присутствует ещё один ключ, наличие которого не упоминается в документации. Этот ключ хранится в оперативной памяти компьютера и используется драйвером BitLocker для реализации «прозрачного» потокового шифрования. Подобным образом работают все утилиты шифрования диска, но если в некоторых сторонних решениях (например, VeraCrypt) пользователь может включить обфускацию этого ключа, что затрудняет его извлечение из оперативной памяти, то BitLocker не делает попыток «спрятать» ключ. Соответственно, при помощи специальных инструментов (таких как Elcomsoft Forensic Disk Decryptor) этот ключ можно извлечь из образа оперативной памяти, файла подкачки или файла гибернации (впрочем, если зашифрован системный том, то и эти файлы будут зашифрованы; остаётся лишь образ оперативной памяти). Извлечённый таким образом ключ можно использовать для мгновенного монтирования или расшифровки защищённого тома.

Ваши действия:

  • На компьютере пользователя запустите Elcomsoft Forensic Disk Decryptor.
  • Создайте образ оперативной памяти.
  • Откройте его в Elcomsoft Forensic Disk Decryptor на своём компьютере и осуществите поиск ключей BitLocker.
  • Если ключи найдены, создайте образ зашифрованного диска и используйте Elcomsoft Forensic Disk Decryptor для его монтирования или расшифровки.

Практические шаги

Опишем практические шаги по извлечению ключей и метаданных шифрования, которые упоминались выше.

Шаг 1.1: Извлечение метаданных шифрования BitLocker при помощи Elcomsoft Forensic Disk Decryptor

Используйте Elcomsoft Distributed Password Recovery для сохранения метаданных шифрования в файл.

  1. Запустите Elcomsoft Forensic Disk Decryptor.
  2. Выберите опцию «Extract/prepare data for further password recovery«.
  3. Откройте образ диска или сам диск (в примере ниже мы использовали физический жёсткий диск).
  4.  EFDD отобразит список зашифрованных томов. Выберите один из них.
  5. Нажмите Next для сохранения метаданных шифрования.

Важно: Подобрать пароль можно в том и только в том случае, если используется протектор «только пароль». Все остальные протекторы (с участием TPM, ключей или сертификатов) такой атаке не поддаются. Чтобы сэкономить ваше время, EFDD предупредит о подобных ситуациях:

Если такое произойдёт, используйте альтернативный вектор атаки.

Шаг 1.2: Извлечение метаданных шифрования BitLocker посредством Elcomsoft System Recovery

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

Elcomsoft System Recovery позволяет сэкономить время, загрузив компьютер с портативного накопителя. Программа автоматически обнаруживает шифрование диска и позволяет извлечь метаданные шифрования, необходимые для подбора исходного пароля.

  1. Установите Elcomsoft System Recovery на ваш компьютер (не на компьютер подозреваемого!)
  2. Создайте загрузочный накопитель. Обязательно укажите правильную конфигурацию целевой системы (BIOS или UEFI, 32-разрядная или 64-разрядная). Как правило, имеет смысл использовать быстрый USB-накопитель объёмом не менее 32 ГБ. Инструкция по созданию загрузочной флешки находится здесь.
  3. Загрузите с созданного накопителя компьютер, с которого нужно извлечь метаданные.
  4. Elcomsoft System Recovery запустится автоматически. Выберите пункт Disk tools.
  5. Выберите пункт Drive encryption keys.
  6. Elcomsoft System Recovery выведет список найденных разделов.
  7. Выберите зашифрованный том.
  8. Метаданные шифрования сохранятся на USB накопителе. Перенесите созданные файлы в Elcomsoft Distributed Password Recovery для настройки атаки.

Внимание: Подобрать пароль можно в том и только в том случае, если используется протектор «только пароль». Все остальные протекторы (с участием TPM, ключей или сертификатов) такой атаке не поддаются. Чтобы сэкономить ваше время, ESR предупредит о подобных ситуациях:

Шаг 2: восстановление оригинального пароля к тому в Elcomsoft Distributed Password Recovery

Чтобы восстановить пароль к тому, проделайте следующие шаги.

  1. Запустите Elcomsoft Distributed Password Recovery
  2. Откройте метаданные шифрования, сохранённые на предыдущем шаге.
  3. Настройте и запустите атаку.

Хотя эти три шага кажутся простыми, выполнение атаки методом полного перебора — один из наименее эффективных способов взломать шифрование BitLocker. Мы настоятельно рекомендуем настроить интеллектуальную атаку на основе шаблонов, которые можно определить, проанализировав существующие пароли пользователя. Эти пароли можно извлечь из учётной записи пользователя Google, Связки ключей macOS, iOS или iCloud, учётной записи Microsoft или непосредственно с компьютера пользователя. Существующие пароли пользователя подсказывают, какие группы символов могут быть использованы:

Elcomsoft Distributed Password Recovery предлагает ряд опций с использованием самых распространённых вариаций, например, Password1, password1967 или pa$$w0rd:

Если в паролях пользователя есть что-то общее, можно использовать маски:

Наконец, можно использовать методы, при помощи которых варианты паролей можно составлять с использованием до двух словарей и скриптовых правил:

Tally ERP 9 – аналог системы 1С: Предприятие, разработанный и получивший широкое распространение в Индии. Производитель описывает продукт как «программное обеспечение для управления бизнесом нового поколения для бизнеса нового поколения», которое, снова процитирую создателей, «создано для наслаждения». В сегодняшней статье мы ознакомимся с особенностями шифрования данных в Tally ERP 9 и расскажем о том, как разрабатывался способ вскрытия защиты.

О продукте Tally ERP 9

Tally ERP 9 – популярный в Индии программный продукт с более чем двумя миллионами пользователей. С учётом размера целевой аудитории программы, Tally – одно из самых популярных решений такого рода в Индии.

В марте 2020 к нам обратились представители правоохранительных органов с просьбой помочь получить доступ к защищённому хранилищу Tally ERP 9. При обработке подобных обращений мы стараемся не просто взломать конкретную базу данных, но добавить поддержку соответствующего формата в один из наших продуктов. По этому сценарию и начали развиваться события.

Каким образом обычно поступают производители программного обеспечения, в котором нужно обеспечить безопасность данных пользователя? В подавляющем большинстве случаев используется симметричное шифрование. В качестве алгоритма выбирается стандартный AES с ключом длиной 128, 192 или 256 бит. AES – отличный выбор: он проверен временем, а набор процессорных инструкций AES-NI, доступный во всех процессорах Intel, позволяет достичь совершенно избыточных скоростей шифрования.

Для шифрования данных используется ключ Media Encryption Key (MEK). Как правило, этот ключ – совершенно случайная двоичная последовательность, которая создаётся одним из стандартных алгоритмов генерации случайных чисел. Уже этот ключ будет зашифрован ключом шифрования ключа шифрования Key Encryption Key (KEK). KEK, в свою очередь, генерируется на основе комбинации пароля пользователя и соли посредством одной из стандартных хеш-функций (чаще всего это SHA-1, SHA-256 или SHA-512, но нам попадались и другие варианты). Стойкость алгоритма усиливается увеличением числа итераций хеш-функции; нам попадались варианты от 10,000 итераций (это очень быстрый перебор) до миллиона (соответственно, перебор очень медленный) включительно. Таким образом, для того, чтобы добавить поддержку нового формата защиты, нам нужно просто определить, каким именно алгоритмом шифрования воспользовался производитель и восстановить функцию преобразования ключа (определить алгоритм хеширования, число итераций и место в файле, куда сохраняется соль).

Шифрование Tally Vault

В состав Tally ERP 9 входит реализация безопасного хранилища под названием Tally Vault. Шифрование в ERP 9 – опциональное; пароль задавать пользователю не обязательно. Пароль хранилища можно задать как при создании компании, так и в любой момент после этого:

Когда пользователь задаёт пароль, система создаёт новое, защищённое хранилище. Старое, незащищённое, остаётся; впоследствии пользователь может его удалить. Эта схема чрезвычайно удобна для исследования: зашифрованную копию хранилища можно напрямую сравнить с незашифрованной. Так выглядит выбор компании, если есть и зашифрованная, и незашифрованная версия данных:

Данные в последних версиях Tally ERP 9 по умолчанию сохраняются в c:\Users\Public\Tally.ERP9\Data\(1nnnn)

Зашифрованы будут все файлы с расширением .900, размер которых превышает 512 байт. Основной файл хранилища – Company.900. В этом файле сохраняется информация о пользователях, если включена опция “Use security control”. Так выглядит этот файл в hex-редакторе до шифрования:

А так – после:

Формат файла

Файл логически разбит на секторы (страницы) по 512 байт. В начале каждой страницы записаны 4 байта контрольной суммы (CRC). При проверке блока на целостность вычисляется контрольная сумма остальных (512-4) байт и сравнивается с первыми четырьмя байтами.

Ключ шифрования

Ключ шифрования получается из пароля напрямую; никакой соли, а тем более – разделения на Media Encryption Key и Key Encryption Key, здесь нет.

Интересен и выбор алгоритма шифрования. Разработчики Tally Vault решили не полагаться на существующие криптографические преобразования и создали свой собственный вариант, настоящий кошмар криптографа. Все существующие алгоритмы хеширования без исключений гарантируют, что изменение всего одного бита в хешируемой последовательности приведёт к полному изменению всей контрольной суммы. Индийским разработчикам удалось сделать невероятное: они создали хеш-функцию, в которой при небольшом изменении пароля результат тоже меняется очень незначительно. Более того, у нас создалось впечатление, что при определённых условиях этот хеш можно обратить, получив из него оригинальный пароль (разумеется, если энтропия пароля не превышает энтропии его контрольной суммы). Вишенка на торте: преобразование применяется ровно один раз.

К примеру, вот так выглядят ключи шифрования на основе паролей, в которых попарно различается один символ:

Пароль Ключ
pwd1 0x653C68AC 0x4BA84BA8 (ac 68 3c 65 a8 4b a8 4b)
pwd2 0x653C69A7 0x4BA84BA8 (a7 69 3c 65 a8 4b a8 4b)
password1 0x74258DD3 0x57CE36D7 (d3 8d 25 74 d7 36 ce 57)
password2 0x90A78DD3 0xB34C36D7 (d3 8d a7 90 d7 36 4c b3)
password12345678 0xC6C57C3D 0xE52EC739 (3d 7c c5 c6 39 c7 2e e5)
password12345679 0xC6C51936 0xE52EA232 (36 19 c5 c6 32 a2 2e e5)
qwertyui123456789 0xD15D72DD 0x06309E8D (dd 72 5d d1 8d 9e 30 06)
qwertyuj123456789 0xD15D4D77 0x0630A127 (77 4d 5d d1 27 a1 30 06)

 

Алгоритм шифрования

Страницы шифруются алгоритмом, принцип работы которого сильно напоминает обычный DES. Для шифрования используется 64-битный ключ (который в процессе работы разворачивается в расширенный 128-битный, как и у «настоящего» DES). Шифрование блочное, размер блока – привычные для алгоритма DES 64 бита. Алгоритм используется в режиме CBC с первоначальной инициализацией IV нулями. Напомню, DES (Data Encryption Standard) — алгоритм симметричного шифрования, утверждённый правительством США в 1977 году в качестве официального стандарта. В 2001 от использования DES отказались; ему на смену пришёл привычный нам алгоритм AES. Что заставило индийских разработчиков взять за основу принципы работы именно этого давно устаревшего алгоритма – для нас загадка.

Уже на этом месте можно прекратить исследование и реализовать простейшую атаку на ключ. На современном оборудовании всё пространство ключей можно перебрать за считанные дни. При желании можно осуществить рефакторинг ключей; впрочем, принцип «неуловимого Джо» надёжно защищает Tally от подобных атак.

Проверка пароля

В коде Tally Vault проверка пароля осуществляется путём расшифровки страницы (всех 512-4 байт), вычисления её контрольной суммы (CRC) и её сравнения со значением, записанным в начале страницы. По замыслу разработчиков, для расшифровки всей страницы и полной проверки пароля потребуется расшифровать 64 блока по 8 байт (64 бита). Однако в данном случае дьявол кроется в деталях, и для проверки пароля вычислять контрольную сумму всей страницы совершенно не обязательно.

Вернёмся к первому скриншоту:

В начале каждой страницы есть некая служебная информация, содержимое которой фиксировано или может быть известно заранее. Например, сразу после CRC, по смещению 4, находится 32-битная фиксированная последовательность DWORD 0x00000001. Назначение этой последовательности нам неизвестно; предположительно, это флаг страницы данных. Соответственно, для ускорения проверки правильности пароля в процессе перебора можно прервать расшифровку страницы сразу после первого блока, если содержимое этих 32-бит байтах не 0x00000001. Разумеется, 32 бита данных гарантированно дадут некоторое число коллизий, которые потенциально приведут к ложным срабатываниям. Поэтому в случаях, когда значение расшифрованных очередным ключом 32 бита данных совпало со значением 0x00000001, мы проведём расшифровку блока до конца, вычислим CRC и сравним контрольную сумму со значением, записанным в первых 4 байтах страницы. Однако количество таких коллизий будет порядка 1 к 4 миллиардам, что практически не влияет на скорость перебора паролей.

Кстати, если после прочтения этой статьи разработчики изменят или вовсе уберут фиксированное значение по смещению 4, можно использовать и другие константы. Например, по смещению 12 записывается последовательный номер страницы, если страница – не последняя.

Результат

Вооружившись знанием об использованных алгоритмах хеширования и шифрования, мы разработали две версии плагина для Elcomsoft Distributed Password Recovery. В первой версии плагина реализована «лобовая» атака, в которой правильность пароля проверяется именно так, как задумали индийские разработчики. Во второй – для проверки используется константа в первом зашифрованном блоке. Как и ожидалось, разница в скорости впечатляет.

Сравнение скорости на двух CPU:

Скорость (п/с) При полной расшифровке страницы При проверке константы в первом блоке

(используется в EDPR)

Intel Core i7 6700 170 000 5 400 000
Intel Core i7 9700K 345 000 11 400 000

 

11 миллионов паролей в секунду на одном процессоре, без использования GPU – много это или мало? Для сравнения, скорость атаки на CPU для документов в формате .docx, созданных в Microsoft Office 2016, составляет порядка 40 паролей в секунду, OpenOffice — 9000. Скорость атаки на контейнеры VeraCrypt – чуть больше 1 пароля в секунду. Атака на резервные копии iTunes – порядка 1 пароля в 10 секунд. Архивы RAR – порядка 64 паролей в секунду, 7zip – около 25.

Взлом

Для взлома паролей Tally Vault воспользуемся Elcomsoft Distributed Password Recovery с соответствующим плагином. Для проведения атаки откроем файл Company.900:

Далее настроим атаку по словарю. Можно использовать как обыкновенный словарь русского или английского языка, так и один из специфических словарей, в котором содержатся самые распространённые пароли или пароли, которые были извлечены из браузера пользователя. В данном случае мы воспользовались паролями, которые извлекли из браузера Chrome, установленного на компьютере пользователя:

Пароль обнаружился менее, чем за секунду:

Усложнив задачу, запустили полный перебор, чтобы посмотреть скорость атаки, которая стабилизировалась на 11.1 миллионах паролей в секунду.

Как было бы правильно

Как можно было бы реализовать шифрование правильным образом? В данном случае достаточно было бы сделать «как все», а именно:

  1. В качестве алгоритма шифрования использовать стандартный AES с длиной ключа 256 бит.
  2. Для шифрования данных использовать ключ Media Encryption Key (MEK), созданный криптографически стойким генератором случайных чисел.
  3. MEK сохранять в зашифрованном виде. Шифрование этого ключа осуществлять при помощи дополнительного ключа Key Encryption Key (KEK).
  4. Key Encryption Key вычислять посредством одной из готовых KDF (Key Derivation Function), использующих многочисленные (порядка сотен тысяч) итерации хеш-функции SHA-256 или SHA-512 на основе пароля пользователя и соли.

Кроме того, если есть возможность изменить формат файла, то стоит тщательно проанализировать страницы на предмет наличия констант или данных, которые легко вычислить (например, номеров страниц или внутренних идентификаторов). От таких данных нужно избавиться.

Заключение

Tally ERP 9 полностью оправдал заявку маркетологов «создано для наслаждения». Мы получили редкое удовольствие, создавая атаку на данные Tally Vault, словно вернувшись на 20 лет назад во времена слабой, зарегулированной экспортными ограничениями защиты.

Что же касается самого Tally Vault, то разработчики совершили все возможные и невозможные ошибки. Мы не смогли найти ни одного аспекта защиты, который был бы реализован на уровне хотя бы школьника-энтузиаста. Беспросветно плохо здесь абсолютно всё. Здесь и прямое преобразование пароля в ключ шифрования, и пренебрежение солью, и единственная итерация доморощенного (и безграмотно реализованного) алгоритма хеширования. Использование алгоритма на основе DES более чем 40-летней давности в комбинации с коротким ключом шифрования делают возможной атаку на ключ (а не на пароль), и только отсутствие спроса защищает продукт от полного рефакторинга. Исправить эти алгоритмы принципиально невозможно, можно лишь сделать заново.

Впрочем, здесь тот случай, когда и «сделать заново», вероятно, не поможет. Фиксированные данные, находящиеся в самом начале страницы данных, позволяют ограничиться расшифровкой единственного 64-битного блока, что более чем в 30 раз ускоряет проверку. Нам же остаётся порадоваться очередному установленному рекорду: более 11 миллионов паролей в секунду на единственном CPU, без использования даже аппаратного ускорения – наш абсолютный рекорд за всё время работы.

В прошлом году мы разработали новый способ извлечения данных из iPhone, не требующий взлома устройства через джейлбрейк. Обладающий массой достоинств метод не обошёлся без недостатка: для его работы требовалось зарегистрировать учётную запись Apple ID в платной программе Apple для разработчиков. Очередное обновление iOS Forensic Toolkit для Mac снимает это ограничение, позволяя использовать обычные учётные записи для установки агента-экстрактора и извлечения данных из iPhone.

Доступ к файловой системе и Связке ключей на iPhone невозможен без эскалации привилегий. В ранних версиях iOS Forensic Toolkit требовалось взломать телефон, установив на него джейлбрейк. Наша новая разработка, агент-экстрактор, стала отличной альтернативой: благодаря его использованию у экспертов появилась возможность извлекать данные из iPhone без джейлбрейка. Агент-экстрактор демонстрирует высокую скорость, надёжность и совместимость. В бочке мёда не обошлось и без ложки дёгтя: для установки агента эксперт должен был зарегистрировать Apple ID в платной программе Apple для разработчиков.

В обновлённой версии iOS Forensic Toolkit для Mac используется новый способ, позволяющий устанавливать агента-экстрактора на устройства под управлением iOS без обязательной регистрации в программе для разработчиков. Новый способ работает только с компьютеров под управлением macOS, и поддерживается исключительно в версии iOS Forensic Toolkit для Mac. Пользователям редакции для Windows по-прежнему доступна только работа с учётной записью для разработчиков; в качестве опции этот режим остался доступен и для пользователей редакции для Mac.

Учётная запись Apple ID для установки сторонних приложений

Компания Apple отличается цепким контролем над всей экосистемой iOS. Вся экосистема построена таким образом, что платить Apple должны все. Пользователи — покупкой устройств Apple и подписок. Разработчики — покупкой техники Apple, без которой невозможно запустить инструменты для разработки; оплатой самих инструментов для разработки, ежегодной оплатой участия в программе Apple для разработчиков и отдельно — оплатой подписки на право подавать заявки на публикацию приложений в App Store (отдельно отметим, что обязательства опубликовать поданное на рассмотрение приложение Apple на себя не берёт).

Идиллию нарушало сообщество пользователей джейлбрейков. Взлом iPhone и использование стороннего магазина приложений позволяло устанавливать программы, не одобренные модераторами Apple. Для тех, кто не хотел взламывать свой iPhone, существовала альтернатива: при помощи Cydia Impactor и подобных программ было возможно установить на телефон приложение и пользоваться им в течение семи дней. Необходимая для установки и запуска приложения цифровая подпись легитимно запрашивалась с сервера Apple; для запроса было достаточно использовать самую обычную учётную запись Apple ID.

С точки зрения Apple неделя без плотной опеки — это слишком много. В ноябре 2019 компания изменила политику одобрения цифровых подписей, в результате чего установка сторонних приложений при помощи Cydia Impactor стала невозможной. Saurik, разработчик Cydia Impactor, писал об этом в Twitter. С тех пор установка сторонних приложений стала возможна только при условии оплаты подписки на участие в программе Apple для разработчиков. Однако не всё так просто. Одновременно с блокировкой цифровых подписей «обычных» учётных записей у частных лиц начались проблемы и с регистрацией в программе для разработчиков. Установка сторонних приложений на iPhone без джейлбрейка стала сложным процессом, результат которого не гарантирован.

Извлечение данных и учётные записи для разработчиков

Подписка на участие в программе для разработчиков стоит недорого. Откровенно говоря, её стоимость — единицы процентов от стоимости программного обеспечения для анализа iPhone. Использование учётной записи разработчика для загрузки агента-экстрактора имеет ощутимые преимущества по сравнению с использованием обычного или анонимного (одноразового) идентификатора Apple ID. О преимуществах таких учётных записей говорится и в нашей статье. Только такие учётные записи позволяют обходить проверку сертификата цифровой подписи на iPhone, которая в противном случае потребовала бы выхода в глобальную сеть для связи с сервером Apple со всеми вытекающими из этого факта рисками и последствиями.

Несмотря на все преимущества, заметное число экспертов предпочитает не пользоваться учётными записями разработчика. Более того, регистрация в программе для разработчиков стала неоправданно сложной: Apple часто отказывает в регистрации без объяснения причин. В конце концов нам пришлось разработать решение, позволяющее использовать обычные или одноразовые Apple ID для подписи агента-экстрактора. К сожалению, наше решение работает только на компьютерах Mac. Обойти это ограничение на данном этапе технически невозможно.

Совместимость и ограничения метода

Для того, чтобы воспользоваться новым методом загрузки агента-экстрактора, вам необходима обычная (или одноразовая) учётная запись Apple ID с активированной двухфакторной аутентификацией (на данный момент все новые учётные записи создаются уже с ней). Вам также потребуется доступ к компьютеру под управлением macOS. Разумеется, нужен iPhone, из которого будут извлекаться данные, и кабель Lightning, посредством которого телефон будет подключён к компьютеру.

В список совместимых моделей входят iPhone iPhone 5s … 11 Pro Max под управлением iOS 9.0 … 13.5.

Вам также понадобится компьютер под управлением macOS 10.12 (Sierra) … 10.15 (Catalina). Необходима версия iOS Forensic Toolkit для Mac 6.50 или более новая.

В сравнении с использованием учётной записи для разработчика извлечение с обычным Apple ID имеет ряд ограничений.

  1. Полученная цифровая подпись действительна в течение 7 дней. Постарайтесь завершить извлечение до того, как она истечёт.
  2. Обычные Apple ID можно использовать для подписи ограниченного числа устройств (на данный момент — трёх). Использование одноразовых Apple ID поможет решить проблему.
  3. Вам потребуется пройти двухфакторную аутентификацию. Код двухфакторной аутентификации будет отправлен непосредственно на доверенное устройство (получить код через SMS не представляется возможным), поэтому вам нужно будет иметь такое устройство под рукой. Впрочем, код не потребуется, если Mac уже является доверенным (привязанным к Apple ID, который вы собираетесь использовать).
  4. Необходимо пройти проверку (верификацию) сертификата цифровой подписи на iPhone, из которого вы собираетесь извлечь данные. Для этого телефон придётся подключить к интернет. Ознакомьтесь с инструкцией, которая позволит уменьшить связанные с этим риски.

Последовательность шагов

Обратите внимание: при анализе iPhone с использованием обычного Apple ID настройте ограничения на доступ в сеть согласно инструкции Извлечение данных из iPhone: ограничение сетевых подключений.

  • Скачайте последнюю сборку Elcomsoft iOS Forensic Toolkit.
  • Установите инструментарий согласно инструкции How to Install and Run iOS Forensic Toolkit on a Mac.
  • Запустите iOS Forensic Toolkit.
  • Введите команду 1 для установки агента-экстрактора на телефон. Введите логин и пароль используемого Apple ID, после чего введите одноразовый код двухфакторной аутентификации (код доставляется на доверенное устройство — iPhone, iPad или Mac).
  • Верифицируйте сертификат цифровой подписи на iPhone. Для этого устройству понадобится доступ к сети. После подтверждения сертификата запустите приложение-агента, коснувшись его иконки.
  • Введите команду 2 для извлечения и расшифровки Связки ключей
  • Введите команду 3 для извлечения образа файловой системы
  • Введите команду 4 для удаления агента-экстрактора с телефона

Настоятельно рекомендуем извлечь как Связку ключей, так и файловую систему, так как содержимое Связки ключей может использоваться для расшифровки данных некоторых приложений (например, облачных резервных копий WhatsApp, данных Signal и т.д.). Образ файловой системы можно проанализировать в программе Elcomsoft Phone Viewer или аналогичном продукте.

Заключение

В ноябре 2019 года произошли изменения, введённые Apple для более плотного контроля за установкой приложений из сторонних источников. В результате этих изменений перестал работать вариант установки сторонних приложений на устройства под управлением iOS, в котором для подписи исполняемого файла использовался обычный, чаще всего – одноразовый идентификатор Apple ID. Единственным доступным способом установки агента-экстрактора стала регистрация в программе Apple для разработчиков, участие в которой не бесплатно, процесс регистрации – сложен, а результат – не гарантирован. Нам удалось обойти введённые компанией ограничения, но только в версии для компьютеров Mac. Пользователям редакции для Windows по-прежнему необходима регистрация в программе Apple для разработчиков.

В обновлённом инструментарии iOS Forensic Toolkit для извлечения данных из iPhone и других устройств под управлением iOS можно использовать обычный или одноразовый идентификатор Apple ID. Использование Apple ID, не зарегистрированного в программе Apple для разработчиков, сопряжено с некоторыми рисками и ограничениями. В частности, необходимо верифицировать сертификат, которым подписан агент-экстрактор, для чего на исследуемом iPhone потребуется открыть подключение к интернет. В данной статье мы расскажем, как позволить устройству верифицировать цифровую подпись, минимизировав риски удалённой блокировки или сброса устройства.

В Elcomsoft iOS Forensic Toolkit используется метод извлечения файловой системы и дешифрования Связки ключей с устройств iOS без установки джейлбрейка. Для доступа к данным используется собственное приложение, которое служит агентом-посредником между телефоном и компьютером эксперта. Использование агента обладает рядом преимуществ перед методами, использующими джейлбрейк. При этом, однако, требуется использование идентификатора Apple ID для подписи агента извлечения. Использование обычного Apple ID (не зарегистрированного в программе для разработчиков) требует обязательной верификации цифровой подписи, которая должна быть проведена на самом устройстве. Это, в свою очередь, требует подключения к удалённому серверу Apple — иными словами, выхода в интернет.

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

Управление рисками

Самый простой способ избежать рисков — избавить iPhone от необходимости проверять сертификат цифровой подписи в принципе. Если агент-экстрактор подписан с Apple ID, зарегистрированным в программе Apple для разработчиков, то проверка сертификата проводится автоматически, без выхода iPhone в сеть.

Проблемы возникают тогда, когда для подписи агента-экстрактора используется обычный или одноразовый идентификатор Apple ID. В этой ситуации для проверки сертификата iPhone придётся «выпустить» в сеть, позволив ему подключиться к удалённому серверу для валидации цифровой подписи. Адрес этого сервера — ppq.apple.com (17.173.66.213), порт 443.

Наша цель — ограничить сетевое подключение доступом исключительно к единственному указанному выше серверу. Для этого необходимо ограничить список узлов, к которым разрешено подключаться исследуемому устройству, оставив в «белом списке» единственный адрес сервера проверки сертификатов Apple (упомянутый выше ppq.apple.com).

Добиться этого можно несколькими способами. Проще всего настроить сеть Wi-Fi на роутере таким образом, чтобы в «белом списке» был единственный нужный узел. Если же радиомодули устройства требуется держать отключёнными, то можно воспользоваться заранее настроенным проводным соединением (например, при помощи адаптера Lightning на Ethernet или более дешёвой альтернативой,  либо комбинацией адаптера Lightning на USB и адаптера USB Ethernet).

 

 

Если же вы пользуетесь компьютером Mac, то никакого дополнительного аппаратного обеспечения не нужно. Достаточно настроить соединение на самом компьютере.

Шаг 1. Подключите к компьютеру Mac любой iPhone кроме того, который вы анализируете. Откройте [Settings] | [Shared] и убедитесь, что в меню Internet Sharing в «To computers using:» содержится пункт «iPhone USB».

Если такого пункта нет, временно включите на телефоне Personal Hotspot (выберите опцию «USB only»). Пункт меню должен появиться. После этого iPhone можно отключить от компьютера, а раздачу интернета с него — выключить.

Шаг 2. Убедитесь, что к компьютеру Mac не подключено ни одного iPhone, и активируйте файрвол (только для интерфейса iPhone USB), разрешив доступ только к узлу ppq.apple.com. Это можно сделать при помощи нашего скрипта, запущенного из-под пользователя root:

sudo ./install_firewall.sh

Содержимое скрипта очень простое:

#!/bin/bash
cp /etc/pf.conf /etc/pf.conf.backup
echo "table <allowed-hosts> { ppq.apple.com, 192.168.2.0/24 }" >> /etc/pf.conf
echo "block drop in quick on bridge100 proto tcp from any to !<allowed-hosts>" >> /etc/pf.conf
pfctl -f /etc/pf.conf

Шаг 3. Подключите iPhone, из которого нужно извлечь данные. Агент-экстрактор должен быть уже установлен. Если это не так — установите агент-экстрактор через Elcomsoft iOS Forensic Toolkit. Теперь включите Internet Sharing на iPhone USB.

Шаг 4. Пройдите верификацию сертификата, выданного на тот Apple ID, посредством которого был установлен агент-экстрактор.

Шаг 5. Проведите извлечение файловой системы и Связки ключей в EIFT.

Step 6. Теперь файрвол можно отключить, восстановив оригинальную конфигурацию из резервной копии. Проще всего это сделать, запустив второй скрипт (от имени пользователя root):

sudo ./uninstall_firewall.sh

Этот скрипт даже проще предыдущего:

#!/bin/bash
cp /etc/pf.conf.backup /etc/pf.conf
pfctl -f /etc/pf.conf

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

НАШИ НОВОСТИ