Статьи в рубрике ‘Безопасность’

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

Зашифрованные диски

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

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

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

Как обнаружить зашифрованные диски

С точки зрения пользователя смонтированный зашифрованный диск ничем не отличается от обычного диска. Тем не менее, при выключении компьютера зашифрованный диск, как правило, размонтируется, и при следующем включении пользователю придётся или ввести пароль, или авторизоваться в системе (так работает, в частности, шифрование BitLocker с ключом, который защищается посредством аппаратного модуля TPM или Intel PTT; пароля в классическом смысле слова у таких дисков нет, поэтому и любые атаки на данные из образа диска будут совершенно бесполезны).

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

Определить наличие зашифрованных дисков поможет бесплатная утилита командной строки Elcomsoft Encrypted Disk Hunter.

Elcomsoft Encrypted Disk Hunter — это бесплатный портативный инструмент, который поможет быстро обнаружить наличие зашифрованных дисков. Для анализа системы достаточно запустить утилиту с USB накопителя; список подключённых устройств и зашифрованных дисков выводится автоматически. Инструмент может обнаруживать зашифрованные диски TrueCrypt/VeraCrypt, BitLocker, PGP WDE, FileVault2 и LUKS (только первой версии). Справедливости рады, вам вряд ли встретятся диски с шифрованием FIleVault2 и LUKS, подключённые к компьютеру с Windows (наша утилита работает только в этой ОС). Их поддержку мы включили для тех редких случаев, когда они могут вам понадобиться.

Что делать, если на компьютере пользователя запущена macOS или Linux? В этом случае вам поможет другой, загрузочный инструмент — Elcomsoft System Recovery.

Как это работает?

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

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

После этого проверяется, смонтирован ли какой-либо из зашифрованных томов. Если никаких явных признаков шифрования диска не обнаружено, Encrypted Disk Hunter проверяет цепочку системных драйверов на предмет наличия в ней драйверов TrueCrypt, VeraCrypt и PGP WDE. Если распознан драйвер шифрования диска (например, truecrypt.sys, veracrypt.sys, PGPdisk.SYS, Pgpwdefs.sys или PGPwded.sys), утилита сообщит, что в системе могло использоваться шифрование, даже если в данный момент времени ни одного зашифрованного тома не обнаружено. Кстати, такая эвристика — единственный способ обнаружить диск, зашифрованный PGP WDE, т.к. последний блокирует доступ к размонтированным зашифрованным томам.

Дальнейшие шаги

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

  1. Если никаких признаков полного шифрования диска не обнаружено: образ оперативной памяти создать желательно, но не обязательно; отключите питание и следуйте обычной схеме.
    Признаков шифрования не обнаружено
  2. При обнаружении признаков шифрования: обязательно создайте образ оперативной памяти (например, посредством Elcomsoft Forensic Disk Decryptor); возможно, вам придётся потратить дополнительное время на исследование системы перед тем, как обесточить компьютер.
    Зашифрованные тома не обнаружены, но обнаружен активный процесс шифрования диска. Требуется дальнейшее исследование.
  3. Если найдены смонтированные зашифрованные диски: создайте образ оперативной памяти; попытайтесь извлечь из него ключи восстановления / депонированные ключи. Если позволяет время, попытайтесь извлечь улики из смонтированных зашифрованных томов.

    Найден том TrueCrypt/VeraCrypt. Further analysis mandatory. Требуется дальнейшее исследование.
    Найден том BitLocker. Требуется дальнейшее исследование.

Если смонтирован хотя бы один зашифрованный диск, обратите внимание на тип шифрования. Рекомендуем ознакомиться с нашей статьёй Безопасность в опасности: как и от чего защищать информацию на компьютере, в которой рассказано об основных принципах шифрования дисков. Также рекомендуем более детальные статьи Расшифровка криптоконтейнеров VeraCrypt и Расшифровка дисков LUKS, а если вы владеете английским — то и статьи Unlocking BitLocker: Can You Break That Password? и Unlocking BitLocker Volumes by Booting from a USB Drive.

Также рекомендуем воспользоваться утилитой Elcomsoft Forensic Disk Decryptor для создания образа оперативной памяти и поиска ключей шифрования, что позволит обойтись без попыток подобрать оригинальный пароль. Извлечение ключей шифрования из образа памяти может и вовсе оказаться единственным доступным методом для разблокировки томов BitLocker, защищённых некоторыми типами протекторов (например, TPM).

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

Скачать Elcomsoft Encrypted Disk Hunter

Elcomsoft Encrypted Disk Hunter можно скачать по ссылке с нашего сайта:

Скачать Elcomsoft Encrypted Disk Hunter

Утилита доступна в виде ZIP-архива без установщика. В архиве содержится портативный исполняемый файл, подписанный цифровой подписью. Распакуйте архив, сохраните утилиту на USB-накопителе и используйте в системе с правами администратора. Настоятельно рекомендуем запускать инструмент непосредственно с USB-накопителя.

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

Возможные сценарии

Есть два типичных сценария, в которых неизвестный пароль от резервной копии iPhone может иметь значение.

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

Если же вы — пользователь iPhone, то вам может потребоваться перенести данные с одного телефона на другой или восстановить старое устройство после сброса к заводским настройкам. Трудно придумать более неприятную ситуацию, чем неизвестный или забытый пароль на уже созданной резервной копии! Если вы установили пароль и успешно его забыли, то восстановить аппарат из такой резервной копии не получится. Возможно, вам будет доступно восстановление из облачной резервной копии в iCloud, но рассмотрение этого варианта выходит за рамки данной статьи.

Рекомендуем статью, опубликованную Apple — «Зашифрованные резервные копии на iPhone, iPad или iPod touch». Мы также можем порекомендовать наш собственный текст (увы, на английском) — The Most Unusual Things about iPhone Backups. Здесь же мы расскажем о некоторых практических аспектах того, о чём две упомянутые статьи рассказывают лишь в теории.

Как извлечь оригинальный пароль

Для извлечения данных нет ничего лучше того самого пароля, который когда-то был установлен на резервную копию. У нас есть хорошая новость: если вы пользователь Mac (или в вашем распоряжении есть компьютер пользователя под управлением macOS), то вероятность, что резервный пароль хранится в связке ключей macOS, очень и очень высока. Все, что вам нужно, это пароль от Mac. Windows? К сожалению, нет.

Требуемое ПО: Keychain Acccess (бесплатно; встроено в macOS)

Взломать!

Взлом пароля — наша основная специализация. Но даже мы признаём, что попытка взлома пароля к резервной копии iPhone, работающих под хотя бы относительно свежей сборкой iOS — занятие с крайне туманными перспективами. Начиная с iOS 10.2, защита паролей такова, что скорость перебора даже с использованием дорогостоящих аппаратных ускорителей и самых мощных видеокарт не превышает нескольких десятков (в лучшем случае — сотен) паролей в секунду. С такой скоростью можно взломать лишь самые слабые пароли, которые встречаются крайне редко. Ещё один вариант — использование словаря, составленного из известных паролей того же пользователя. А вот смысла в атаке методом полного перебора, увы, мало.

Требуемое ПО: hashcat (бесплатно) или Elcomsoft Phone Breaker

Сбросить!

С выходом iOS 11 появилась возможность сброса пароля резервного копирования непосредственно с устройства iPhone (разумеется, экран телефона при этом должен быть разблокирован). Эта опция по-прежнему доступна в iOS 13 и текущих бета-версиях iOS 14, поэтому, вероятно, она останется и в будущем. Последовательность действий предельно проста (как описано в Apple HT205220, упомянутом выше):

  • На устройстве перейдите в меню «Настройки» > «Основные» > «Сбросить».
  • Нажмите «Сбросить все настройки» и введите пароль устройства.
  • Следуйте инструкциям по сбросу настроек. Это не затронет данные или пароли пользователей, но приведёт к сбросу таких настроек, как уровень яркости дисплея, позиции программ на экране «Домой» и обои. Пароль для шифрования резервных копий также будет удалён.

Как это часто бывает, дьявол кроется в деталях. Основная проблема заключается в том, что при сбросе настроек будет удалён также и код блокировки устройства, что может привести к довольно неприятным последствиям (станет недоступной некоторая часть данных — например, транзакции Apple Pay). Это особенно важно, если вы работаете не со своими данными, а расследуете инцидент в качестве судебного эксперта. Постарайтесь оставить этот способ на крайний случае, если не удастся решить проблему иначе.

Требуемое ПО: нет

Просто игнорировать

Каким бы странным ни был этот совет, в некоторых случаях пароль на резервную копию можно действительно просто проигнорировать. В каких случаях стратегия «не делать ничего» является не только самое простой, но и самой эффективной?

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

Во-вторых, для некоторых моделей iPhone и версий iOS (в настоящее время до iOS 13.5 на iPhone Xr/Xs/11 и для всех версий iOS на старых моделях) вы можете извлечь значительно больше данных, чем попадает в резервные копии, и пароль резервного копирования вам для этого не потребуется. Данные извлекаются непосредственно из файловой системы устройства, а не в формате резервной копии. Да, эти данные нельзя будет использовать для восстановления другого устройства, но и делать это вам вряд ли потребуется. В данном случае — «шашечки или ехать?»

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

Требуемое ПО: Elcomsoft iOS Forensic Toolkit

Заключение

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

Сегодня смартфон — полноценная замена множеству вещей: фотоаппарату, навигатору, шагомеру и даже кошельку. Смартфоны содержат огромное количество конфиденциальной информации, которая может оказаться полезной в расследовании или стать основой доказательной базы. Получить доступ к этим данным может оказаться непросто, что продемонстрировал спор между ФБР и Apple по поводу разблокировки телефона iPhone 5c, который был использован стрелком из Сан-Бернардино в декабре 2015 года. Несколько лет назад вопрос о разблокировке этого устройства стал причиной судебного спора двух гигантов. Сегодня благодаря последним достижениям разблокировка iPhone 5c не представляет особой проблемы.

Тот самый iPhone 5c

Apple выпустила iPhone 5 в сентябре 2012 года. Телефон поставлялся с iOS 6.0; последняя версия iOS, доступная для этого устройства — 10.3.4.

В сентябре 2013 года Apple выпустила не один, а сразу два iPhone, причём основанных на совершенно разных наборах микросхем. Флагманом компании стал инновационный (и довольно дорогой) iPhone 5s, в котором впервые появились такие вещи, как датчик отпечатка пальцев и аппаратный сопроцессор Secure Enclave. А вот iPhone 5c стал «доступной» моделью, основанной на упрощённой начинке прошлогоднего iPhone 5.

Выпустив iPhone 5c, Apple предприняла попытку выйти на рынок бюджетных телефонов, которая не нашла понимания у журналистов и обозревателей того времени. Несмотря на плохие обзоры, эта модель года стала одним из самых популярных бюджетных телефонов, продаваемых через собственным каналы продаж сотовыми операторами США.

iPhone 5c стал последним смартфоном от Apple, основанном на 32-битном процессоре. Изначально iPhone 5c вышел с iOS 7.0; последняя версия iOS, доступная для этого телефона — 10.3.3.

iPhone 5c стал знаменит после террористической атаки в Сан-Бернардино в декабре 2015 года и последующей судебной тяжбой между ФБР и Apple. В этом споре Федеральное бюро расследований потребовало, чтобы Apple создала программное обеспечение, которое позволило бы ФБР разблокировать iPhone 5C террориста. Объект спора — iPhone 5c — был найден в рабочем состоянии, но был заблокирован четырёхзначным паролем. На устройстве была настройка на стирание данных после десяти неудачных попыток. Apple отказалась создавать такое программное обеспечение (хотя технически, они могли это сделать); судебное слушание было назначено на 22 марта. Однако за день до слушания правительство потребовало отсрочки, заявив о существовании третьей стороны, способной помочь в разблокировке. 28 марта было объявлено, что ФБР удалось разблокировать аппарат. Иск был отозван.

Как именно ФБР удалось получить пароль, кто был подрядчиком и сколько именно было заплачено за услугу, официально неизвестно. Некоторые новостные агентства со ссылкой на анонимные источники назвали третьей стороной израильскую компанию Cellebrite (которая не опровергла, но и подтвердила этот факт). Однако The Washington Post сообщила, что, по словам очередных анонимных «людей, знакомых с вопросом», ФБР заплатило «профессиональным хакерам», которые использовали неопубликованную уязвимость в программном обеспечении iPhone. По словам директора ФБР Джеймса Коми, взлом данного iPhone 5c обошёлся ФБР в сумму более 1,3 миллиона долларов. До сих пор точно не известно, была ли это компания Cellebrite (которая отказывается от комментариев, но явно не подтверждает своё участие) или кто-либо ещё. С учётом того, что от комментариев воздерживается и потенциальная «третья сторона», точно установить исполнителей контракта не представляется возможным.

Сегодня же разблокировать iPhone 5c сможет любой пользователь нашего программного инструментария iOS Forensic Toolkit, цена которого почти на три порядка меньше выложенной ФБР суммы. При помощи Elcomsoft iOS Forensic Toolkit можно подобрать пароль экрана блокировки iPhone 5/5c и разблокировать устройство.

Говоря о восстановлении пароля, нельзя не упомянуть работу Сергея Скоробогатова. В своём исследовательском проекте «Анализ безопасности Apple iPhone 5c» он продемонстрировал атаку, позволяющую подобрать код блокировки экрана на iPhone 5c. У метода, предложенного Сергеем, есть два недостатка: телефон потребуется разобрать, а пауза между попытками ввода пароля достигает 5 секунд. В своей работе Сергей утверждает, что взломать 4-значный код доступа можно примерно за сутки, а восстановление 6-значного PIN-кода займёт неоправданно много времени.

Ещё одним способом разблокировки iPhone 5c в своё время стало решение IP-BOX и его многочисленные клоны. Их основной недостаток — ограничение версий iOS до iOS 8.1 включительно. Более новые версии iOS принципиально не поддерживаются, а скорость перебора аналогична решению Сергея (около 6 секунд на попытку ввода пароля или порядка 17 часов на взлом 4-значного PIN-кода).

В сравнении с этими решениями, наш продукт не требует дополнительного оборудования или разборки телефона, работая при этом примерно в 80 раз быстрее.

Как работает восстановление пароля и почему так важно восстановить именно оригинальный код блокировки экрана, а не, например, обойти его посредством эксплойта? Об этом — ниже.

Код блокировки как вершина безопасности

Код блокировки экрана — важнейшая часть модели безопасности iPhone. Начиная с iOS 8, пользовательские данные, включая пароли, хранящиеся в Связке ключей, шифруются с помощью ключа, полученного криптографическим преобразованием пароля пользователя. Без оригинального пароля невозможно получить доступ к информации на устройствах до первой разблокировки (т.е. только что включённых или сразу после перезагрузки). Обход пароля блокировки экрана для таких устройств — операция достаточно бессмысленная, поскольку основной массив данных будет надёжно зашифрованным.

Система безопасности iOS отлично документирована. Следующий отрывок из документации Apple Platform Security объясняет роль пароля в экосистеме iOS.

Установив на устройстве код-пароль, пользователь автоматически включает защиту данных. iOS и iPadOS поддерживают код-пароли из четырех или шести цифр и буквенно-цифровые код-пароли произвольной длины. Помимо разблокирования устройства, код-пароль является источником энтропии для некоторых ключей шифрования. Это означает, что злоумышленник, завладевший устройством, не сможет получить доступ к данным определенных классов защиты, не зная код-пароля.

Код-пароль привязывается к UID устройства, поэтому попытки перебора должны выполняться непосредственно на атакуемом устройстве. Для замедления каждой попытки используется большое число повторений. Число повторений настроено таким образом, что одна попытка занимает примерно 80 миллисекунд. Это означает, что для перебора всех сочетаний шестизначного код-пароля, состоящего из строчных букв и цифр, потребуется более 5,5 лет.

Чем надежнее код-пароль пользователя, тем надежнее ключ шифрования. А благодаря Touch ID и Face ID пользователь может установить гораздо более надежный код-пароль, чем это было бы возможно при отсутствии данной технологии. Это повышает эффективное количество энтропии, используемое для защиты ключей шифрования системы защиты данных, без ущерба для удобства пользователей, которым приходится по несколько раз в день разблокировать устройство iOS или iPadOS.

Чтобы дополнительно усложнить атаки методом перебора, после ввода неправильного код-пароля на экране блокировки временные задержки увеличиваются. Если параметр «Настройки» > «Touch ID и код‑пароль» > «Стирать данные» включен, все данные на устройстве будут автоматически стерты после 10 неудачных попыток ввода код-пароля подряд. При подсчете не учитываются последовательные попытки ввода одного и того же неправильного код-пароля. Эта функция также доступна при настройке политики администрирования через систему управления мобильными устройствами (MDM), которая поддерживает эту функцию, и Exchange ActiveSync. Кроме того, можно установить более низкий порог ее срабатывания.

На устройствах с Secure Enclave за применение задержек отвечает сопроцессор Secure Enclave. Если в течение заданного времени задержки устройство перезапускается, задержка применяется еще раз, а таймер запускается заново.

Источник: Apple Platform Security

В старых моделях iPhone, в частности iPhone 5 и iPhone 5c, измеренная задержка между попытками ввода пароля составила 73,5 мс, что даёт скорость перебора в 13,6 паролей в секунду. Это очень близко 80 мс, о которых пишет Apple. Поскольку в этих моделях iPhone нет сопроцессора безопасности, увеличивающиеся временные задержки устанавливаются программно операционной системой, а не сопроцессором Secure Enclave. Это, в свою очередь, означает, что задержку можно отключить программным же способом при наличии доступа к определённым системным файлам.

Наконец, iPhone 5 и iPhone 5c не оснащены датчиком отпечатков пальцев. Код блокировки — единственное средство защиты устройства. В документации Apple есть фраза: «благодаря Touch ID и Face ID пользователь может установить гораздо более надежный код-пароль, чем это было бы возможно при отсутствии данной технологии». Поскольку указанных технологий в этих моделей iPhone нет, то и пользователи, скорее всего, будут выбирать простые и короткие PIN-коды вместо более длинных буквенно-цифровых паролей, чтобы избежать (снова цитата) «ущерба для удобства пользователей, которым приходится по несколько раз в день разблокировать устройство».

Какие пароли встречаются чаще всего?

Типы паролей, которые чаще всего устанавливают пользователи, зависят от нескольких факторов. Сюда входят как настройки iOS по умолчанию, так и фактора удобства, который учитывает наличие или отсутствие Touch ID/Face ID, а также скорость и удобство ввода того или иного пароля с экранной клавиатуры.

Выбор по умолчанию

В iOS 6 был единственный вариант — простой пароль из 4 цифр, который и был включён по умолчанию. Если пользователь отключал настройку, он мог использовать буквенно-цифровой код доступа любой длины. Однако, если пользователь вводил любое количество цифр, кроме четырёх, на экране блокировки будет отображаться клавиатура только с цифрами (и текстовое поле переменного размера). Таким образом, классификация типов паролей, доступных в iOS 6, включает следующие варианты:

  • 4-значный цифровой PIN-код
  • Цифровой PIN-код произвольной длины (кроме 4-значных цифровых кодов)
  • Буквенно-цифровой код

В iOS 9 (а также iOS 10) были доступны следующие четыре варианта:

  • 4-значный цифровой PIN-код
    6-значный цифровой PIN-код
    Цифровой код произвольной длины
    Буквенно-цифровой код произвольной длины

В разных источниках приводится информация о том, что с момента выхода iOS 9 Apple перешла на шестизначные коды доступа, сделав их вариантом по умолчанию. Для двух рассматриваемых моделей iPhone (5 и 5c) это утверждение неверно. После сброса настроек на iPhone 5 и 5с мы наблюдали предложение установить 4-значный цифровой PIN-код. Ещё более интересным является то, что при попытке изменить уже установленный 6-значный PIN-код на новый, iOS все равно предложит установить 4-значный PIN-код. Скорее всего, это часть «фактора удобства», поскольку 6-значный код доступа приведёт к проблемам (ok, небольшим затруднениям), связанным с отсутствием в данных моделях датчика отпечатка пальцев.

Фактор удобства

Какие пароли чаще всего устанавливают пользователи на устройствах до Touch ID? В мае 2020 года Филипп Маркер, Даниэль В. Бейли, Максимилиан Голла, Маркус Дюрмут и Адам Дж. Авив провели исследование выбранных пользователем 4- и 6-значных PIN-кодов, собранных на смартфонах для разблокировки устройства. В своём исследовании они объединили несколько наборов данных, полученных из различных источников, и провели собственное тестирование 1220 участников. Исследование помогло определить наиболее часто используемые 4- и 6-значные PIN-коды.

Исследователи сделали следующие выводы, которые на первый взгляд могут показаться спорными. Из исследования сделан вывод, согласно которому реальная эффективность использования более длинных 6-значных PIN-кодов по сравнению с 4-значными довольно низкая. Участники исследования, вынужденные использовать 6-значный PIN, чаще всего выбирали варианты, которые легко угадать или удобно набирать на экранной клавиатуре. Существуют чёрные списки таких паролей, однако в исследовании был сделан вывод об их неэффективности и даже контрпродуктивности: оказалось, что участники эксперимента считают, что занесение выбранного ими пароля в чёрный список только усилит безопасность, не влияя на удобство использования. (источник)

Часто используемые пароли

Со своей стороны, мы можем порекомендовать ознакомиться с оригинальным исследованием. С нашей точки зрения значение имеет список наиболее часто используемых (а значит, и наименее безопасных) 6-значных PIN-кодов. В этом списке всего 2910 записей, и для их проверки требуется порядка 4 минут. В этом списке и хит всех времён — пароль 123456, и повторяющиеся цифры (000000, 999999), а также цифровые пароли, представляющие определённые комбинации, фактически из двух или трёх цифр (например, 131313 или 287287). После этого списка идут 6-значные PIN-коды, основанные на дате рождения пользователя; существует около 74 тысяч возможных комбинаций, на проверку которых уходит около 1,5 часов. Только после того, как эти возможности исчерпаны, мы начинаем полный перебор оставшихся вариантов, который длится около 21 часа.

Заключение

iPhone 5 и 5c вышли почти 7 лет назад, но на руках у пользователей и в лабораториях экспертов осталось ещё довольно много таких устройств. Для разработки первого эксплойта потребовались годы и сумма, превышающая миллион долларов. Сегодня быстрый способ разблокировки iPhone 5 и 5c доступен всем желающим с использованием чисто программного метода.

Современный смартфон — бесценный кладезь информации с одной стороны и вполне реальная угроза приватности с другой. Смартфон знает о пользователе столько, сколько не знает ни один человек — начиная с подробной истории местоположения и общения в интернете и заканчивая кругом общения в реальной жизни, который определяется распознаванием лиц встроенными технологиями искусственного интеллекта. Чем больше и чем разнообразнее становится информация, собираемая о пользователе, тем в большей степени её требуется защищать. Задача же правоохранительных органов прямо противоположна: улики требуется из устройства извлечь. Возникает конфликт интересов.

“Мы глубоко уважаем правоохранительные органы и сотрудничаем с ними во многих областях, но по этому вопросу мы не согласны. Позвольте мне выразиться предельно ясно: ослабление шифрования или его устранение вредит в первую очередь честным людям, которые используют его в легитимных целях.” (интервью Тима Кука, 2015)

Оглянемся назад и посмотрим, как эволюционировали методы защиты данных, которые использовала Apple в своих устройствах.

iPhone OS 1 — 3: нулевой уровень

В первых версиях iOS (и, соответственно, в первых трёх моделях iPhone) защита данных была чисто символической: PIN-код защищал информацию от любопытных глаз, но и только. Никакого шифрования не было; данные можно было извлечь как из самого устройства, так и из микросхемы памяти. Впрочем, в первых поколениях iPhone и не было никакой особо ценной информации — разве что фотографии. Джон Здиарски был первым, кто обнаружил способ извлечь информацию из заблокированных iPhone, см. публикацию iOS Forensic Investigative Methods.

Модели устройств:

  • iPhone OS 1.0 – iPhone
  • iPhone OS 2.0 – iPhone 3G
  • iPhone OS 3.0 – iPhone 3GS

iOS 4: шифрование файловой системы

До версии iOS 4, данные в iPhone хранились в открытом виде. Их извлечение было вопросом несложных манипуляций. Сама компания Apple активно сотрудничала с правоохранительными органами, соглашаясь извлечь данные из присланного iPhone (забегая вперёд, так продолжалось вплоть до выхода iOS 8). В iOS 4 впервые появилось шифрование. Впрочем, использование аппаратного идентификатора в качестве ключа шифрования позволило довольно быстро найти способ извлечь и расшифровать зашифрованные данные, даже если код блокировки экрана был неизвестен. Кстати, именно наша компания была первой, кто сумел  взломать устройства с iOS 4.

Модели устройств:

  • iOS 4.0 – iPhone 4
  • iOS 5.0 – iPhone 4s
  • iOS 6.0 – iPhone 5

iOS 7: запрос при установлении соединения с компьютером

Можно ли сегодня представить себе, что когда-то iPhone можно было просто подключить к компьютеру, и он сразу устанавливал соединение? Тем не менее, до 7-й версии iOS было именно так. И только в iOS 7, наконец, появился привычный всплывающий запрос, требующий разблокировать экран устройства и подтвердить установление соединения с новым компьютером (последующие подключения обходились без этого благодаря файлам pairing/lockdown).

iOS 7 стала первой версией iOS, работавшей на первом 64-разрядном iPhone, оборудованном датчиком отпечатков пальцев и аппаратной подсистемой безопасности Secure Enclave.

Модели устройств:

  • iOS 7.0 – iPhone 5s, первый 64-разрядный iPhone с Secure Enclave

Здиарски обнаружил уязвимость в устройствах iOS, см. Apple Confirms “Backdoors”; Downplays Their Severity. Некоторые из обнаруженных Здиарски служб по сей день используются в Elcomsoft iOS Forensic Toolkit.

iOS 8: шифрование на основе кода блокировки; взлом паролей перестал работать

iOS 8 стала прорывом в области безопасности мобильных операционных систем. Именно в iOS 8 был заложен фундамент той модели безопасности, которая используется в iPhone по сегодняшний день.  С точки зрения безопасности изменилось буквально всё.

Модели устройств:

  • iOS 8.0 – iPhone 6 и 6 Plus

Начнём с простого — логического анализа.

До выхода iOS 8 Apple использовали следующую практику. При установлении соединения между iPhone и другим устройством (подразумевался компьютер пользователя) создавалась запись pairing record, которая сохранялась в виде файла. В старых версиях iOS эта запись была фиксированной; она не менялась никогда, даже после сброса устройства. Раз установив соединение с одним компьютером, пользователь мог спокойно подключать iPhone к любому другому устройству — если скопировал файл с pairing record. Именно такой файл и создавался в процессе настройки iPhone на заводе. Файл сохранялся на сервере компании, что позволяло Apple добиться сразу двух целей. Во-первых, сотрудники компании могли помочь пользователю, который забыл код блокировки, извлечь из телефона важные, уникальные данные (о существовании резервного копирования большинство пользователей не слышало ни тогда, ни сейчас). Второй, не декларируемой особенностью данной схемы было сотрудничество с полицией. Если в Apple присылали iPhone с сопроводительным ордером, то компания без проблем извлекала из него информацию. Это работало, даже если код блокировки был неизвестен. Кстати, разорвать раз установленное соединение было невозможно даже сбросом телефона к заводским настройкам.

Сотрудничеству с полицией был положен конец с выходом iOS 8. Начиная с этой версии системы, для установления с компьютером требуется не один фиксированный ключ, а пара уникальных ключей, которая генерируется при установлении соединения с новым устройством. Одна половинка ключа сохраняется в самом iPhone, а вторая — передаётся на компьютер пользователя, где и сохраняется в файл pairing record. Стоит удалить любую из половинок, и соединение не установится. Сброс телефона — уничтожаются все сохранённые в нём «половинки», соединение невозможно.

Комбинация шифрования файловой системы динамическим ключом на основе кода блокировки экрана и нового подхода к установлению соединения привела к тому, что ни сотрудники Apple Genius bar, ни полиция больше не могут извлечь данные из iPhone на основе заводских записей pairing. Об этом же написано в официальной инструкции Apple для правоохранительных органов, доступной только на английском языке:

For all devices running iOS 8.0 and later versions, Apple is unable to perform an iOS device data extraction as the data typically sought by law enforcement is encrypted, and Apple does not possess the encryption key. All iPhone 6 and later device models are manufactured running iOS 8.0 or a later version of iOS. Apple’s guidelines for law enforcement requests

Для всех устройств, работающих под управлением iOS 8.0 и более поздних версий, Apple не может выполнить извлечение данных с устройства, поскольку данные, запрашиваемые правоохранительными органами, зашифрованы, а у Apple нет ключа шифрования. Все устройства iPhone 6 и более поздние модели производятся под управлением iOS 8.0 или более поздней версии iOS.

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

iOS 9: длина кода блокировки увеличена до 6 цифр

В iOS 9 появилось единственное заметное новшество: длина кода блокировки экрана, которую предлагает система при настройке телефона по умолчанию, увеличена до 6 цифр. Пользователь по-прежнему может настроить 4-значный PIN, но от версии к версии сделать это становится всё сложнее.

В iOS 9 впервые появилось ограничение на время жизни записей о сопряжении (см. следующий раздел); в этой версии системы он составляет 6 месяцев с момента последнего использования.

Модели устройств:

  • iOS 9.0.1 – iPhone 6s и 6s Plus

iOS 10: ограничен срок действия записей о сопряжении

До iOS 10 записи lockdown (pairing records) действовали в течение длительного времени. В нашей лаборатории хранились записи, которым было несколько месяцев — и они продолжали работать. После того, как полиция начала активно пользоваться записями pairing record, извлекаемыми из компьютеров пользователей, в Apple решили ограничить срок действия этих записей. iOS 10 и более новые версии аннулируют записи о сопряжении через 30 дней с момента последнего использования.

iOS 10 стала и большим шагом назад в том, что касается защиты резервных копий. Начиная с iOS 5 (или iOS 4), Apple использовала один и тот же алгоритм для проверки паролей к резервным копиям iPhone. Для вычисления ключа шифрования вычислялось 20,000 итераций хеш-функции. Это было достаточно медленно и достаточно безопасно. В iOS 10 произошла неожиданность: в защите резервных копий обнаружилась забытая уязвимость, использующая единственную итерацию хеша. На основе этой уязвимости мы создали атаку со скоростью в десятки миллионов паролей в секунду.

Модели устройств:

  • iOS 10.0.1 – iPhone 7 и 7 Plus

iOS 10.1: исправлена проблема с защитой резервных копий

Описанная выше уязвимость в защите резервных копий была исправлена в iOS 10.1; наша компания удостоилась благодарности в сопроводительной документации.

iOS 10.2: защита резервных копий в параноидальном режиме

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

iOS 10.3: переход на файловую систему APFS

В iOS 10.3 был осуществлён переход всех обновляемых устройств на новую файловую систему APFS. Сам по себе этот переход не сделал устройства более безопасными, но производителям ПО для анализа данных из iPhone пришлось в спешном порядке обновлять пакеты программ.

iOS 11: сопряжение с компьютером по паролю

В iOS 11 произошло два крупных изменения. Во-первых, установить сопряжение с новым компьютером теперь можно, если известен код блокировки: его потребуется ввести после разблокирования экрана (для самой разблокировки, кстати, можно по-прежнему использовать биометрику).

Вторым важным — и весьма сомнительным! — новшеством стала возможность сброса пароля к резервной копии. Сбросить пароль можно в настройках системы вместе с некоторыми другими настройками (в частности, при сбросе пароля на резервную копию удаляется и код блокировки экрана, что автоматически приводит к удалению таких данных, как список транзакций Apple Pay). Для сброса пароля к резервной копии потребуется ввести код блокировки экрана; таким образом, роль кода блокировки в модели безопасности iOS усилена ещё больше. С нашей точки зрения, эта возможность радикально снижает безопасность iOS. Мы написали об этом статью: iOS 11 Makes Logical Acquisition Trivial, Allows Resetting iTunes Backup Password.

Модели устройств:

  • iOS 11.0 – iPhone 8 и 8 Plus
  • iOS 11.0.1 – iPhone X

Срок действия записей о сопряжении ограничен ещё сильнее. Теперь существующие записи о сопряжении (pairing records) остаются действительными в течение 30 дней с момента последнего использования (источник: iOS Security Guide May 2019 edition, iOS 12.3).

В iOS 11 был представлен «аварийный» режим S.O.S., при активации которого отключается возможность разблокировки iPhone биометрическими датчиками. Наконец, в локальные резервные копии перестали сохраняться уведомления. Подробнее о новшествах в модели безопасности iOS 11 можно прочесть в статье New Security Measures in iOS 11 and Their Forensic Implications.

iOS 11.4.1: блокировка USB

В iOS 11.4.1 впервые появился режим ограничения (блокировки) USB, изначальным предназначением которого было противодействие инструментам для перебора кодов блокировки производства Cellerbrite и Grayshift. iOS 11.4.1 автоматически отключает передачу данных через USB (порт Lightning) через час после того, как экран устройства был заблокирован или отключен от компьютера или аксессуара USB. Кроме того, пользователь может активировать этот режим и вручную, просто запустив режим S.O.S.

iOS 12: расширен режим блокировки USB, Ограничения превратились в Экранное время

iOS 12 развивает и расширяет ограничения USB. Согласно новому руководству по безопасности iOS, опубликованному Apple после выпуска iOS 12, возможность передачи данных через порт USB блокируется сразу (а не через час, как это было раньше) после блокировки экрана устройства, если с момента последнего подключения через USB прошло более трех дней или если устройство находится в состоянии, когда для его разблокировки требуется пароль. Кроме того, порт USB блокируется, если пользователь активирует режим S.O.S. В оригинале этот момент описан так:

“In addition, on iOS 12 if it’s been more than three days since a USB connection has been established, the device will disallow new USB connections immediately after it locks. This is to increase protection for users that don’t often make use of such connections. USB connections are also disabled whenever the device is in a state where it requires a passcode to re-enable biometric authentication.”

Кроме того, в iOS 12 на смену Ограничениям пришёл новый сервис — Экранное время. Спустя время настройки и статистика Экранного времени стали доступны для синхронизации через iCloud.

Модели устройств:

  • iOS 12.0 – iPhone Xs и Xs Max
  • iOS 12.0 – iPhone Xr

iOS 13: смена пароля к резервной копии через код блокировки; режим блокировки USB снова расширен

В актуальной на сегодня ветке iOS 13, включающей в себя ответвление iPadOS, Apple отказалась от поддержки приложения iTunes на компьютерах Mac. Теперь резервные копии устройств с iOS/iPadOS создаются прямо из приложения Finder.

Модели устройств:

  • iOS 13.0 – iPhone 11 Pro и 11 Pro Max
  • iOS 13.0 – iPhone 11

При установке или изменении пароля, защищающего локальную резервную копию, пользователь должен ввести код блокировки экрана iPhone. Пароль необходимо ввести на самом iPhone. Таким образом, роль кода блокировки в iOS 13 окончательно возведена в абсолют; зная код блокировки экрана, с телефоном можно проделать практически всё, что угодно, от сброса пароля на резервную копию до смены пароля к Apple ID и отвязки устройства от iCloud.

Режим блокировки USB также был расширен. В iOS 13 появилось своеобразное «сопряжение» аксессуаров. Чтобы подсоединиться к компьютеру, пользователю нужно будет ввести PIN-код на iPhone, после чего устройства обменяются криптографическими ключами. «Сопряжение» аксессуара не использует криптографических ключей; это односторонний процесс, для которого не требуется PIN-код. Аксессуар «сопрягается» с iPhone, когда пользователь впервые подключает его к устройство в момент, когда экран телефона разблокирован (или же разблокирует iPhone уже после подключения аксессуара). iPhone сохранит информацию о «сопряжённом» аксессуаре и присвоит этому аксессуару доверенный статус.

Ограничения USB в iOS 13 различны для «доверенных» и «прочих» аксессуаров. В iOS 13 возможность коммуникации через порт USB блокируется через час после того, как телефон был заблокирован или пользователь отключил ранее использованный аксессуар. При этом подключение аксессуара, которого нет в списке доверенных устройств, вызывает мгновенное срабатывание блокировки порта USB.

Наконец, в незашифрованные резервные копии без пароля более не попадает журнал звонков и история браузера Safari.

Заключение

В заключение я хочу процитировать Дана Скалько из Digitalux. «Одна из самых больших проблем, с которыми сталкиваются компании, — это баланс конфиденциальности, безопасности и удобства потребителей. Большее удобство часто приводит к снижению уровня безопасности и, как следствие, конфиденциальности. Хорошо иллюстрирует тезис двухфакторная аутентификация в сравнении с простым паролем. Очевидно, что на прохождение двухфакторной аутентификации пользователю потребуется потратить больше времени и усилий, но с её помощью обеспечивается гораздо больший уровень безопасности и конфиденциальности, чем с одним лишь паролем. Конфиденциальность, безопасность и удобство должны быть приоритетными целями любой компании. Но в конце концов важнее всего — именно безопасность.»

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

Способы извлечения данных

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

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

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

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

Итак, рассмотрим различные варианты извлечения истории переписки для пяти распространённых приложений для обмена мгновенными сообщениями в iOS.

iMessage

iMessage — предустановленный сервис для обмена сообщениями, доступный на каждом устройстве iPhone и iPad «из коробки». Поскольку приложение предустановлено на каждом iPhone, предполагается, что большая часть пользователей iPhone так или иначе пользуется этим приложением. В какой-то мере это соответствует действительности: по умолчанию отправка сообщения через встроенное приложение «Сообщения» пошлёт SMS пользователю Android или кнопочного телефона, но отправит iMessage, если на другом конце — такой же пользователь iPhone. Компания Apple оценивает количество пользователей iMessage в 1.6 миллиарда; оценка основана на количестве активных iPhone. В 2016 году сервис пересылал порядка 200,000 сообщений iMessages в секунду.

  • Запрос от правоохранительных органов: Неоднозначно, но — нет. С одной стороны, Apple хранит сообщения на собственных серверах. С другой, по утверждениям компании, все сообщения зашифрованы сквозным шифрованием; код шифрования зависит от кода блокировки зарегистрированного устройства пользователя. Этот факт позволяет Apple утверждать, что компания не в состоянии расшифровать данные. Впрочем, Apple категорически отказывается расшифровать сообщения даже в том случае, если код блокировки известен — что фактически не представляет проблемы даже для сторонних сервисов. Так или иначе, Apple не возвращает сообщения iMessage по запросу от правоохранительных органов.
  • Собственный облачный сервис: Копии сообщений хранятся в iCloud, если пользователь включил функцию «Облачные сообщения». Данные зашифрованы, для их расшифровки необходим код блокировки экрана одного из зарегистрированных устройств пользователя. Для извлечения и расшифровки потребуется Apple ID, пароль, второй фактор аутентификации и код блокировки экрана.
  • Локальные резервные копии: История переписки iMessages всегда попадает в резервные копии, её можно извлечь и расшифровать посредством логического анализа.
  • Резервные копии в iCloud: Apple хранит сообщения iMessage в резервных копиях iCloud в том и только в том случае, если пользователь не включил функцию «Облачные сообщения». В противном случае см. предыдущие пункты.
  • iCloud Drive: нет.
  • Образ файловой системы: Сообщения iMessage хранятся в файловой системе устройства без дополнительной степени защиты. Соответственно, для их извлечения достаточно лишь образа файловой системы; расшифровка Связки ключей для этого не обязательна.

iMessage: выводы

Извлечь сообщения можно, но нужно хорошо понимать, что именно нужно делать. Сообщения доступны из нескольких источников; соответственно, получить к ним доступ можно несколькими разными способами. В целом мы оцениваем сложность извлечения iMessage как среднюю.

Необходимые программы: Elcomsoft iOS Forensic Toolkit (извлечение из образа файловой системы) или Elcomsoft Phone Breaker (извлечение из iCloud, резервных копий в iCloud, локальных резервных копий iTunes); Elcomsoft Phone Viewer (для просмотра и анализа).

Инструкции: Messages in iCloud: How to Extract Full Content Including Media Files, Locations and Documents, iMessage Security, Encryption and Attachments.

WhatsApp

Пользователей WhatsApp — более 2 миллиардов, что делает WhatsApp одним из самых популярных приложений для обмена сообщениями. Несмотря на то, что протокол обмена сообщениями WhatsApp основан на протоколе Signal, использующем сквозное шифрование, приложение WhatsApp ничуть не более безопасно в сравнении с другими мессенджерами. В приложении WhatsApp есть возможность создания резервных копий. Впрочем, история переписки WhatsApp не хранится на серверах компании за исключением недоставленных сообщений.

  • Запрос от правоохранительных органов: WhatsApp не сохраняет историю сообщений на собственных серверах. Исключение — недоставленные сообщения; только их и можно получить по запросу от правоохранительных органах.
  • Собственный облачный сервис: См. выше: доступны только недоставленные сообщения.
  • Локальные резервные копии: Как правило, резервные копии WhatsApp сохраняются как в локальных, так и в облачных резервных копиях iOS.
  • Резервные копии в iCloud: См. выше; как правило, данные WhatsApp можно извлечь из облачной резервной копии в iCloud.
  • iCloud Drive: WhatsApp предлагает пользователям возможность сохранения автономной резервной копии в облаке iCloud. Эти данные можно с лёгкостью извлечь из облака; проблема же в том, что они зашифрованы. Для расшифровки таких резервных копий необходимо зарегистрироваться в качестве нового клиента WhatsApp (например, при помощи Elcomsoft Explorer for WhatsApp).
  • Образ файловой системы: База данных WhatsApp доступна и в образе файловой системы. Никакой дополнительной защиты нет.

WhatsApp: выводы

Сложность извлечения истории переписки WhatsApp мы оцениваем как невысокую. Данные WhatsApp можно извлечь практически из любого источника (за исключением собственных серверов компании), в том числе из локальных и облачных резервных копий.

Необходимые программы: Elcomsoft iOS Forensic Toolkit и Elcomsoft Phone Viewer; либо специализированный продукт Elcomsoft Explorer for WhatsApp.

Инструкции: Extract and Decrypt WhatsApp Backups from iCloud.

Telegram

Telegram — одна из самых продвинутых программ для мгновенного обмена сообщениями. Благодаря приложениям, доступным для практически всех платформ, Telegram набрал порядка 200 миллионов пользователей (данные 2018 года). В день пересылается порядка 300 миллионов сообщений.

Telegram использует собственный облачный сервис как для доставки, так и для хранения сообщений (это и позволяет использовать несколько клиентов Telegram одновременно на разных устройствах). Доступен специальный режим «секретных чатов», в котором сообщения на сервере не хранятся.

  • Запрос от правоохранительных органов: Telegram хранит полную историю переписки пользователей на собственных серверах — за исключением секретных чатов. В зависимости от юрисдикции, историю переписки в Telegram можно получить по запросу от правоохранительных органов.
  • Собственный облачный сервис: Историю переписки в Telegram можно извлечь непосредственно из облака компании, зарегистрировавшись в качестве приложения-клиента.
  • Локальные резервные копии: Нет. Данные Telegram не попадают в локальные резервные копии.
  • Резервные копии в iCloud: Нет. Данные Telegram не сохраняются в облачных резервных копиях.
  • iCloud Drive: Нет.
  • Образ файловой системы: Telegram не использует никакой дополнительной защиты. Для доступа к данным достаточно образа файловой системы.

Telegram: выводы

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

Необходимые программы: Elcomsoft iOS Forensic Toolkit (для извлечения из файловой системы); Elcomsoft Phone Viewer (для анализа данных).

Инструкции: Извлечение секретных чатов из Telegram для iPhone

Signal

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

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

  • Запрос от правоохранительных органов: Нет. Signal не хранит сообщения на сервере; соответственно, нечего и запрашивать.
  • Собственный облачный сервис: Нет. Signal не хранит историю переписки на своих серверах.
  • Локальные резервные копии: Нет. Данные Signal не попадают в резервные копии.
  • Резервные копии в iCloud: Нет. Данные Signal не сохраняются в облачных резервных копиях.
  • iCloud Drive: Нет. Signal не создаёт резервных копий, даже автономных.
  • Образ файловой системы: Да, но сложно. Signal шифрует рабочую базу данных, а ключ шифрования хранится в Связки ключей с максимальным классом защиты. Для расшифровки базы данных вам придётся извлечь как образ файловой системы, так и Связку ключей (Elcomsoft iOS Forensic Toolkit).

Signal: выводы

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

Необходимые программы: Elcomsoft iOS Forensic Toolkit (извлечение образа файловой системы и расшифровка Связки ключей); Elcomsoft Phone Viewer (расшифровка базы данных Signal).

Инструкции: How to Extract and Decrypt Signal Conversation History from the iPhone

Skype

Skype — один из старейших мессенджеров. В настоящее время сервис принадлежит компании Microsoft. В марте 2020 года Skype использовался ста миллионами пользователей ежемесячно. Порядка 40 миллионов человек использует Skype ежедневно. Microsoft сохраняет историю общения пользователей Skype; данные доступны по запросу от правоохранительных органов.

  • Запрос от правоохранительных органов: Да; проще, чем в остальных случаях. Skype хранит полную историю переписки в облаке Microsoft; секретные чаты отсутствуют как возможность. Microsoft охотно сотрудничает с правоохранительными органами, выдавая полный набор данных по запросу от правоохранительных органов.
  • Собственный облачный сервис: Да. Microsoft хранит данные в собственном облаке, и их можно извлечь, авторизовавшись в учётной записи пользователя.
  • Локальные резервные копии: С некоторых пор Skype перестал сохранять историю переписки в локальных резервных копиях. Этот путь доступа к данным в настоящее время закрыт.
  • Резервные копии в iCloud: См. выше. В настоящее время извлечение из облачных резервных копий невозможно.
  • iCloud Drive: Нет.
  • Образ файловой системы: Skype не использует дополнительных мер по защите рабочей базы данных. Для доступа достаточно только образа файловой системы.

Skype: выводы

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

Необходимые программы: Elcomsoft Phone Breaker (для скачивания переписки из Microsoft Account); Elcomsoft Phone Viewer (для просмотра данных).

Инструкции: Extracting Skype Histories and Deleted Files Metadata from Microsoft Account

Заключение

Данная статья не претендует на полноту. Line, Viber, QQ, WeChat, Facebook Messenger и множество других приложений, в том числе от Yandex и Mail.ru, используется огромным количеством пользователей. Мы продолжаем исследования, постепенно добавляя поддержку самых распространённых мессенджеров.

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

Источники данных о местоположении

Данные о местоположении извлекаются из нескольких принципиально различных источников. Основной источник данных о местоположении – данные операторов сотовой связи, которые сообщаются в виде детализации Call Detail Record (CDR). Эти данные могут быть выданы правоохранительным органам по соответствующим образом оформленному запросу; массовая выдача подобных данных регулируется и ограничивается законодательно.

Данные о местоположении можно извлечь из смартфона пользователя; как правило, объём таких данных относительно невелик, а для извлечения информации необходим низкоуровневый доступ к файловой системе.

Наибольший интерес представляет дистанционный анализ данных о местоположении, доступ к которым осуществляется через облако. Особенно интересен «облачный» анализ устройств под управлением Android. В таких устройствах количество точек местоположения, хранящихся в самом телефоне, значительно уступает массиву информации, который собирает и систематизирует в облаке производитель Android – корпорация Google.

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

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

Огромные массивы данных о местоположении можно извлечь из таких приложений, как Google Fit или Strava. Координаты могут сохраняться даже в событиях из календаря. В наших продуктах есть возможность проанализировать данные, полученные из всех источников. За это отвечает функция агрегации данных о местоположении, которая появилась в Elcomsoft Phone Viewer 3.70 в 2018 году.

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

  • Важные геопозиции (что это такое)*
  • Кеш геопозиций (3G/LTE/Wi-Fi connections)
  • Apple Maps
  • Google Maps
  • Метаданные EXIF, включая идентификатор устройства, на котором был сделан снимок
  • События календаря и ссылка на событие
  • Приложение UBER

* Компания Apple использует именно этот термин, «геопозиция». Также используются термины «геолокация» и «геопредупреждения».

Рассмотрим способы извлечения и анализа данных о местоположении из трёх облачных провайдеров: Apple (iCloud), Google и Microsoft.

Apple

В отличие от Google, Apple не сохраняет многолетнюю подробную историю местоположения пользователя. Соответственно, возможность извлечь эти данные из облака iCloud достаточно ограниченна. В то же время в iCloud всё же есть некоторые данные, которыми можно воспользоваться для извлечения геопозиций. Эти данные включают:

Фотографии в облаке iCloud Photos

Если пользователь активирует функцию «облачных» фотографий, все снимки, сделанные на устройствах пользователя, поступают в облако iCloud в виде синхронизированных данных.  Фотографии можно скачать из облака при помощи Elcomsoft Phone Breaker, после чего извлечь метки GPS из данных EXIF (либо воспользоваться функцией Elcomsoft Phone Viewer > Aggregated Locations).

Облачные сообщения iCloud Messages

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

Здоровье — Тренировки

В рамках экосистемы Apple «тренировки» — пожалуй, единственный тип облачных данных, который стабильно содержит множество точных отметок местоположения. Данные поступают от устройств системы HealthKit, оборудованных датчиком GPS – например, от часов Apple Watch пользователя. Как только устройство обнаруживает начало тренировки, включается датчик позиционирования, и устройство начинает регистрировать такие данные, как частота сердечных сокращений и координаты пользователя. Точки местоположения, в свою очередь, поступают от датчика GPS, встроенного во все последние модели Apple Watch и доступного во множестве других совместимых с HealthKit устройств.

Данные о тренировках относятся к категории «Здоровье», которая, в свою очередь, хранится в облаке с использованием сквозного шифрования. Для доступа к зашифрованным таким образом данным с помощью Elcomsoft Phone Breaker вам понадобятся Apple ID и пароль пользователя, одноразовый код двухфакторной аутентификации, а также пароль блокировки экрана или системный пароль пользователя от одного из зарегистрированных в учётной записи устройств.

Данные можно проанализировать посредством Elcomsoft Phone Viewer.

Данные Find My

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

Резервные копии в iCloud

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

Карты Apple Maps

В данных Apple Maps содержится на удивление мало точек определения координат. Несмотря на это, разработчики Apple решили защитить данные Apple Maps в облаке сквозным шифрованием, аналогично тому, как защищается Связка ключей или данные приложения «Здоровье». Соответственно, для доступа к этим данным понадобятся как логин и пароль от Apple ID, так и одноразовый код двухфакторной аутентификации и код блокировки экрана одного из устройств в учётной записи.

Данные о местоположении можно просмотреть посредством Elcomsoft Phone Viewer.

Google

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

  • История местоположений и хронология в Google Картах. Это – основные источники данных о местоположении пользователя.
  • Google Fit. В отличие от Apple Health, Google Fit оценивает данные о физической активности пользователя на основе периодического опроса встроенного датчика-шагомера и отслеживания местоположения. Точки местоположения затем сохраняются в учётной записи Google пользователя в категории Google Fit (отдельно от основной истории местоположений).
  • Фотографии. В настоящее время Google не возвращает теги геолокации в EXIF при использовании API Google Photos. В результате криминалистический анализ фотографий из Google Photos может не вернуть данные о местоположении. Однако при извлечении Google Фото по запросу о выдаче информации от правоохранительных органов будут получены оригинальные изображения с полными метаданными EXIF, включая теги геолокации.

В чём разница между «историей местоположений» и «хронологией в Google Картах» и как одно соотносится с другим?

История местоположений – массив координатных точек и времени. Данные вычисляются на основе показаний датчика GPS, триангуляцией сигнала сотовых вышек, определяются по идентификаторам точек доступа Wi-Fi BSSID и специализированным излучателям в помещениях (такие распространены в крупных многоэтажных торговых центрах). История местоположений – это просто координаты и время. Сама по себе история местоположений ничего не говорит о том, что пользователь делал в том или ином месте или как он туда попал (пешком, на машине или на велосипеде).

Хронология Google Карт – принципиально другой источник данных. Как пишет сам Google, с помощью Хронологии «…Вы можете посмотреть места, которые посетили, и расстояние, которое преодолели, а также способ передвижения (например, пешком, на велосипеде, на машине или общественным транспортом). Расстояния указываются в милях или километрах, в зависимости от страны.»

Хронология Карт – это взгляд Google на повседневную жизнедеятельность каждого пользователя Android. Здесь отмечаются заведения, которые посещает пользователь, и регистрируются способы передвижения (Google уверенно различает поездки на автомобиле, в общественном транспорте и на велосипеде, не говоря о пеших прогулках или пробежках).

Для извлечения и анализа данных о местоположении из учётных записей Google можно воспользоваться программой Elcomsoft Cloud Explorer.

Microsoft

Microsoft использует для синхронизации данных учётные записи Microsoft Account. Данные можно просмотреть в Privacy Dashboard либо скачать при помощи Elcomsoft Phone Breaker (см. статью Fetching Call Logs, Browsing History and Location Data from Microsoft Accounts). Данные о местоположении предоставляются компанией в формате JSON. Microsoft получает данные о местоположении пользователя из нескольких источников, включая запросы Cortana, историю браузера Microsoft Edge (как на компьютерах, так и мобильных приложениях), запросам к Bing (если пользователь вошёл в учётную запись Microsoft Account).

Microsoft – Apple и Google

Ещё один неочевидный источник данных о местоположении – хранилище OneDrive. Подписчики Office 365 получают 1 ТБ облачного хранилища. В то же время, без дополнительной оплаты Apple предоставляет своим пользователем всего 5 ГБ места в хранилище iCloud, что делает его использование для синхронизации хранения фотографий практически невозможным. В результате ряд пользователей iPhone хранит фотографии в облаке OneDrive с помощью соответствующего приложения для iOS.

Google бесплатно предоставляет неограниченное хранилище фотографий в рамках сервиса Google Photos. Тем не менее, бесплатное и неограниченное хранилище для экономии места в облаке заметно сжимает фотографии, что отрицательно влияет на разрешение и качество снимков. Соответственно, и пользователи Android часто используют для хранения именно OneDrive, в котором нет таких ограничений.

Теги EXIF фотографий из OneDrive – отличный источник данных местоположения.

Почему данным местоположений нельзя доверять

Данные о местоположении могут лгать. При анализе полученной из любых источников информации ни в коем случае нельзя слепо доверять полученным результатам, а тем более – основывать на таких результатах обвинительное заключение. Одной из распространённых ошибок является безоглядное использование данных EXIF, извлечённых из всех изображений, обнаруженных на устройстве или в облачной учётной записи пользователя. Многие фотографии, найденные в источнике, могут быть получены от других пользователей или вовсе скачаны из сети. Кеш местоположений, который является ещё одним источником данных, содержит приблизительные координаты ближайшей базовой станции, которая может находиться довольно далеко от устройства пользователя. Делать какие-либо выводы на основании точек доступа Wi-Fi и вовсе не стоит: координаты таких точек доступа получают из сторонних сервисов на основе идентификатора BSSID. Наконец, Хронология Google Карт может выглядеть чрезвычайно убедительно, но нужно понимать, что это всего лишь предположения, сделанные алгоритмом искусственного интеллекта с закрытым исходным кодом.

О том, насколько сильно могут ошибаться алгоритмы, можно судить по следующей истории. Рассмотрим скриншот из учётной записи Microsoft Account.

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

 

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

LastPass

LastPass был представлен в 2008 году компанией Marvasol Inc (в настоящее время — LogMeIn). На сегодняшний день LastPass входит в четвёрку самых популярных менеджеров паролей. Как и другие подобные продукты, LastPass предназначен для хранения, управления и синхронизации паролей, что помогает пользователям избежать повторного использования паролей. Благодаря автоматическому хранению и синхронизации паролей, а также генерации паролей с высокой энтропией, пользователи получают возможность использовать сложные, уникальные пароли для разных учётных записей без необходимости запоминать их все.

В семейство продуктов LastPass входят приложения для настольных операционных систем Windows и macOS, а также мобильные приложения для iOS и Android. Особый интерес представляют так называемые расширения, позволяющие устанавливать LastPass на разных платформах в виде расширения для браузера.

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

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

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

Извлечь базу данных LastPass проще всего с компьютера пользователя. Соответственно, для её защиты LastPass использует 100,100 итераций хеш-функции мастер-пароля. Атака методом прямого перебора демонстрирует следующую скорость работы:

Скорость перебора в 15,500 паролей в секунду с использованием аппаратного ускорителя NVIDIA GeForce 2070 достаточно типична, обеспечивая адекватный уровень защиты при условии использования достаточно стойкого мастер-пароля.

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

Скорость перебора мастер-пароля LastPass для устройств с Android может достигать 309,000 комбинаций в секунду на ускорителе NVIDIA GeForce 2070. Такая скорость перебора считается высокой, позволяя восстанавливать достаточно сложные пароли в разумные сроки. Так, семизначный мастер-пароль, составленный из случайной комбинации цифр и букв в обоих регистрах, но без использования спецсимволов, может быть восстановлен в течение трёх месяцев. Шестизначный же пароль, составленный из того же набора символов, получится вскрыть в течение трёх дней.

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

Расширение для браузера Chrome и Microsoft Edge Chromium

В наборе продуктов LastPass есть расширения для нескольких популярных браузеров. Расширение, предназначенное для браузера Google Chrome, также работает и в браузере Microsoft Edge Chromium.

Расширение для браузера – пожалуй, один из самых удобных способов управления паролями. Уверенное определение полей для автозаполнения, управление паролями непосредственно из браузера предоставляют пользователю весьма удобный инструмент.

Компания-разработчик LastPass утверждает, что расширение для Chrome обеспечивает тот же уровень безопасности, что и отдельное приложение:

Only you know your master password, and only you can access your vault. Your master password is never shared with LastPass. That’s why millions of people and businesses trust LastPass to keep their information safe. We protect your data at every step.

Source

Мы выяснили, что в реальности дела обстоят иначе. В частности, если пользователь выбирает опцию «Запоминать пароль» для автоматического разблокирования защищённого хранилища, расширение LastPass для Chrome не обеспечивает должного уровня безопасности. Фактически, ни о какой безопасности в данном случае не может идти и речи.

В чём смысл использования опции «Запоминать пароль»? Так же, как и другие менеджеры паролей, LastPass автоматически блокирует доступ к защищённому хранилищу при закрытии сессии. Многие пользователи предпочитают не вводить пароль постоянно, доверяя хранение своего мастер-пароля расширению LastPass. В то же время, расширение LastPass сохраняет мастер-пароль небезопасным образом:

«Уязвимость (под названием LastPass-Vul-1) заключается в небезопасной архитектуре механизма запоминания мастер-паролей в LastPass. Как показано на рисунке 2, LastPass может запомнить мастер-пароль пользователя (с именем пользователя BCPM) в локальной базе данных SQLite [40] tableLastPassSavedLogins2, позволяя пользователю автоматически проходить аутентификацию при каждом последующем использовании LastPass».

Источник

Описанная выше уязвимость присутствует во всех известных нам версиях расширения LastPass для Chrome (на момент написания — LastPass 4.44.0 и Google Chrome 80.0.3987.146 для Windows 10 x64). Соответственно, эксперт может извлечь и расшифровать мастер-пароль пользователя и получить таким образом доступ ко всему содержимому хранилища LastPass. Способ работает при условии использования пользователем опции «Запоминать пароль».

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

Windows Data Protection API

Начнём издалека. Воспользовавшись приложением Elcomsoft Internet Password Breaker, можно моментально извлечь пароли, которые хранятся в браузере Chrome и Microsoft Edge Chromium. Казалось бы, в чём разница?

 

 

Разница в том, что извлечь пароли из Google Chrome или Edge Chromium можно лишь в том случае, если известны логин и пароль пользователя Windows или есть доступ к авторизованной сессии (разблокированному именно данным пользователем компьютеру). Если компьютер выключен, а у эксперта есть исключительно жёсткий диск или его образ (при этом пароль пользователя Windows неизвестен), то и расшифровать пароли из Chrome или Edge Chromium не удастся.

Почему не удастся?

Дело в том, как именно Chrome (и Edge Chromium; в дальнейшем это уточнение можно опускать) защищают базу данных, в которой хранятся пароли пользователя. Сама по себе база данных шифруется алгоритмом AES-256; при этом пароль шифрования (мастер-пароль) по умолчанию не используется. (Здесь, пожалуй, кроется единственное отличие механизмов защиты Chrome и Edge Chromium: если в Chrome задать пароль для синхронизации паролей пользователь сможет, то в Edge Chromium подобный функционал не предусмотрен).

Ключ шифрования базы данных с паролями хранится на том же компьютере, что и сама база данных. При этом ключ шифрования защищён при помощи Windows

Data Protection API (DPAPI), который появился ещё во времена Windows 2000. DPAPI использует AES-256 в качестве алгоритма шифрования. Для доступа к паролям из Chrome пользователь должен войти в учётную запись Windows с использованием пароля, PIN-кода или подсистемы Windows Hello. Только после этого хранилище, защищённое DPAPI, будет расшифровано.

Похожим образом дела обстоят и в системе macOS. В этой ОС используется системное защищённое хранилище, «Связка ключей». Именно в ней Chrome сохраняет ключ шифрования от базы данных с паролями пользователей. Таким образом, безопасность подсистемы хранения паролей Chrome в macOS соответствует уровню безопасности Связки ключей, который признан достаточно высоким.

Подытожим изложенное. Для доступа к паролям Google Chrome и Microsoft Edge Chromium потребуется не только образ диска или файл базы данных, но и логин и пароль пользователя системы (либо доступ к аутентифицированной сессии). «Холодная» атака, таким образом, невозможна.

Именно возможность «холодной» атаки (извлечение мастер-пароля из образа диска или просто из файла базы данных) и является отличительной чертой расширения LastPass для Chrome. Всё, что потребуется для доступа к защищённому хранилищу – это сам файл базы данных и активированная пользователем опция «Запоминать пароль».

Извлечение мастер-пароля LastPass

Для извлечения пароля воспользуемся продуктом Elcomsoft Distributed Password Recovery.

  1. Расширение LastPass для Chrome сохраняет защищённую базу данных по следующему пути (Windows 10):
     %UserProfile%\AppData\Local\Google\Chrome\User Data\Default\databases\chrome-extension_hdokiejnpimakedhajhdlcegeplioahd_0
  2. Запустите Elcomsoft Hash Extractor (входит в состав Elcomsoft Distributed Password Recovery) и откройте указанный выше файл. Важно: файл можно извлечь как из уже авторизованной сессии, так и скопировать с диска или извлечь из образа.
  3. Hash Extractor автоматически извлекает заголовок. Сохраните его в файл с и откройте в Elcomsoft Distributed Password Recovery.
  4. Выберите учётную запись.
  5. Запустите атаку.
  6. Elcomsoft Distributed Password Recovery отобразит найденный мастер-пароль в течение нескольких секунд.

День ото дня специалисты Apple работают над тем, чтобы осложнить жизнь эксперта-криминалиста. Усложняется работа с облаком iCloud, вводятся новые условия и ограничения. С выходом iOS 13.4 и macOS 10.15.4 работа экспертов станет ещё немного труднее. Посмотрим, что нового появилось в последних версиях операционных систем от Apple (и как изменилась при этом работа продуктов Элкомсофт).

iOS 13

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

Неожиданное появление синхронизации данных о звонках вызвало волнение общественности и неоднозначную реакцию специалистов по безопасности. В ответ от Apple мы получили лишь стандартную отговорку. Тем удивительнее выглядит решение Apple отказаться от синхронизации звонков (кстати, есть ещё Continuity).

Есть и другая неоднозначная новость. Пользуетесь приложением Apple Maps? Данные Карт теперь хранятся в защищённом хранилище, использующем (по терминологии Apple) «сквозное шифрование». Аналогичным образом хранятся данные Связки ключей (пароли пользователей), Облачные сообщения (SMS, iMessage), данные приложений Здоровья и Экранного времени. Теперь этот список пополнился и данными Apple Maps. Соответственно, для их извлечения нужно будет ввести код блокировки экрана от одного из устройств пользователя, зарегистрированных в учётной записи.

К слову, о приложении Экранное время. Наши пользователи обратили внимание, что в приложении Elcomsoft Phone Breaker извлекается лишь небольшая часть данных Экранного времени – пароль, информация о семейном доступе, ограничения и так далее. При этом не извлекаются статистические данные об использовании устройств. Причина в том, что эти данные, похоже, не попадают в «облако», а синхронизация происходит напрямую между устройствами. Это можно проверить самостоятельно, активировав в настройках Экранного времени функцию Share across devices и просмотрев статистику сначала на оригинальном устройстве, а потом на одном из тех, куда данные синхронизировались. Удивительно, но данные будут разительно отличаться. Более того, многие пользователи жалуются на непредсказуемое поведение этой настройки: данные временами синхронизируются, временами – нет, а иногда пропадают вовсе:

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

На днях вышла свежая бета-версия iOS 13.4.5; мы будем разбираться, какие изменения Apple внедрили в новую версию iOS.

macOS

Файлы lockdown используются для упрощения доступа к доверенным (ранее подключенным) устройствам под управлением iOS. Если такой файл был создан на компьютере, то при подключении к нему доверенного iPhone или iPad система не будет запрашивать код блокировки. В последней версии macOS доступ к файлам lockdown был ограничен.

Точнее, ограничен доступ был ещё раньше – с выходом macOS 10.12. В этой версии macOS для доступа к файлам lockdown необходимо было выполнить в терминале следующую команду:

sudo chmod 755 /private/var/db/lockdown

В последней версии macOS 10.15.4 этот способ работать перестал:

Можно ли обойти новое ограничение? Да, для этого достаточно просто отключить SIP (System Integrity Protection), загрузившись в режим Recovery (+R во время загрузки), запустить Terminal и выполнить следующую команду:

csrutil disable

После перезагрузки доступ к папке lockdown будет восстановлен, и вы сможете произвести логическое извлечение данных из iPhone посредством iOS Forensic Toolkit.

iCloud

В облаке iCloud в очередной раз изменился механизм аутентификации. Он стал работать надёжнее? Нет. Безопаснее? Нет. Просто изменился. Не буду вдаваться в детали, опишу лишь изменения в механизме работы маркеров аутентификации в Elcomsoft Phone Breaker. Для начала рекомендую ознакомиться со статьёй Accessing iCloud With and Without a Password in 2019; ниже – об актуальном положении дел.

На системах с Windows токены (маркеры аутентификации), извлекаемые из приложения iCloud  for Windows 7.0 и более новых версий, работают исключительно для учётных записей без двухфакторной аутентификации. Такие токены могут быть использованы для доступа к очень ограниченному набору данных. Доступны следующие категории: iCloud Photos и некоторые синхронизированные данные (контакты, календари, заметки, история браузера Safari и некоторые другие, за исключением данных, защищённых «сквозным шифрованием» — Связка ключей, Здоровье, Экранное время, Облачные сообщения и карты Apple Maps). Что же касается резервных копий в iCloud, они доступны лишь для старых версий iOS до 11.2.

На системах с macOS ситуация несколько лучше. На версиях macOS от 10.13 до 10.15 можно получить такой же ограниченный токен для учётных записей без 2FA. Токены для учётных записей с 2FA привязаны к устройству, на котором они были созданы. В результате использовать такой токен в Elcomsoft Phone Breaker можно только в том случае, если наш продукт запускается на том самом компьютере Mac, на котором был создан токен. Объём данных, которые можно извлечь из iCloud (независимо от типа токена и учётной записи) совпадает с тем, что можно извлечь в Windows: некоторые категории синхронизированных данных и резервные копии iCloud для устройств с iOS до 11.2. Полноценные «отвязанные» токены для учётных записей с 2FA доступны только в macOS 10.12 и более старых.

Достаточно запутанно? Изложу вкратце:

  • Токен аутентификации для учётных записей без 2FA можно получить всегда, на любой системе
  • Для учётных записей с 2FA, токены из большинства современных систем с Windows совершенно бесполезны. Аналогичные токены, извлечённые из современных систем macOS, можно использовать только на том же самом компьютере.
  • Токены позволяют доступ к ограниченному числу категорий данных в iCloud.

И последнее. Apple пытается обезопасить и учётные записи без двухфакторной аутентификации. Теперь такие учётные записи могут быть заблокированы после ввода единственного неправильного пароля.

Заключение

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

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

Какие бывают пароли?

Что важнее, безопасность или запоминаемость? Вопрос не такой однозначный, каким кажется. Ещё в 2017 году было проведено исследование, согласно которому у самого обычного пользователя было порядка 20 учётных записей. У среднего офисного работника использовалась 191 учётная запись – и это только те пароли, которые вводятся в окно браузера. К началу 2020 года среднее число паролей пользователя достигло 207, при этом в среднем каждый пароль используется без изменений в 3.9 учётных записях. Статистика не указывает, какое количество паролей пользователи используют в разных учётных записях с минимальными изменениями (например, password, Password, password1, Password2010 и т.п.) По нашим данным, количество уникальных паролей, которые невозможно угадать, подсмотрев остальные пароли пользователя, в среднем не превышает 5-7 штук на пользователя.

Какие пароли бывают? Если вы – пользователь iPhone или iPad, то, скорее всего, вам приходится иметь дела с четырьмя паролями, тесно связанными между собой. Вот они:

  1. Код блокировки экрана (это PIN-код или пароль, которым вы разблокируете iPhone)
  2. Пароль от iCloud (он же – пароль от учётной записи Apple ID)
  3. Пароль от резервной копии iTunes (с его помощью будет зашифрована резервная копия iPhone, если создать её на компьютере)
  4. Пароль Экранного времени (позволяет защитить перечисленные выше пароли от сброса, а также устанавливать ограничения на использование устройства)
  5. Одноразовый код двухфакторной аутентификации (будем считать его «половинкой» пароля; используется только в учётных записях, на которых включена двухфакторная аутентификация)

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

В этой статье описаны все известные нам взаимосвязи и взаимозависимости между паролями, актуальные для всех версий iOS 12 и 13, а также способы, посредством которых можно сбросить один пароль, если известен другой.

Код блокировки экрана

Код блокировки – самый важный пароль (а точнее, кодовая фраза), который пользователи iPhone используют чаще всех остальных вместе взятых. Этот пароль используется в процессе настройки iPhone. По умолчанию система предлагает установить код блокировки, состоящий из 6 цифр. Также можно использовать и более простой PIN-код, состоящий из 4 цифр. Можно выбрать и более сложный код блокировки, состоящий из произвольного количества цифр (как в Android) или из буквенно-цифровой последовательности произвольной длины.

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

Скачать список таких «простых» паролей можно с GitHub.

При настройке кода блокировки будет установлено соединение с iCloud; это необходимо для того, чтобы добавить устройство в доверенный круг, участники которого могут безопасно синхронизировать такие данные, как пароли (облачная Связка ключей), Здоровье, сообщения и Экранное время. Соответственно, ни одна из этих категорий не будет синхронизирована, если пользователь не настроит код блокировки. Кроме того, без кода блокировки не будет работать платёжная система Apple Pay.

В нашем блоге есть две статьи на тему кода блокировки экрана: Protecting Your Data and Apple Account If They Know Your iPhone Passcode и Passcode vs. Biometrics: Forensic Implications of Touch ID and Face ID in iOS 12.

Если код блокировки утрачен

У обычного пользователя, который забудет код блокировки, не так много возможностей. Можно сбросить устройство через режим Recovery. Для настройки сброшенного устройства потребуется ввести пароль от iCloud.

Если телефон регулярно подключали к компьютеру, то на компьютере может сохраниться файл lockdown. С его помощью можно установить соединение и сделать резервную копию телефона перед тем, как его сбросить (работает только в том случае, если телефон разблокировали хотя бы раз после последнего включения или перезагрузки). Если резервная копия защищена паролем от резервной копии iTunes, то из неё можно извлечь пароль от iCloud, посредством которого можно будет активировать сброшенный телефон. А вот если такого файла нет или срок его действия истёк, то подключить телефон к компьютеру не получится: начиная с iOS 11 для подключения к новому компьютеру нужно ввести код блокировки экрана.

У работников правоохранительных органов в некоторых странах есть возможность запустить перебор кодов блокировки (именно поэтому усиленно не рекомендуется использовать 4-значный PIN). Впрочем, шанс на успех при использовании даже шестизначного цифрового кода блокировки невысокий.

Итак, если код блокировки утрачен:

  • Можно сбросить iPhone через Recovery. Это сбросит код блокировки экрана, но для настройки устройства потребуется ввести пароль от iCloud.
  • Если вы работаете в правоохранительных органах, вам может быть доступен вариант с перебором кодов блокировки.
  • Подключить iPhone к новому компьютеру не удастся (для установления доверенного соединения требуется ввести код блокировки экрана).
  • Если есть доступ к файлу lockdown, а телефон был разблокирован хотя бы раз с момента последней перезагрузки или включения, то существует возможность извлечения локальной резервной копии. Если резервная копия защищена паролем от резервной копии iTunes, то из неё можно будет извлечь пароль от iCloud, посредством которого можно активировать сброшенный телефон.

Если код блокировки известен

Если же код блокировки известен, с телефоном можно проделать множество разных вещей:

  • Разблокировать устройство даже после холодной загрузки
  • Подключить к новому компьютеру или аксессуарам USB (обход блокировки USB)
  • Создать свежую резервную копию в формате iTunes
  • Сбросить пароль от iCloud и изменить доверенный номер телефона для получения кодов двухфакторной аутентификации (только для учётных записей с двухфакторной аутентификацией; одноразовый код для этого не нужен)
  • Сбросить пароль от резервной копии iTunes (если не установлен или известен пароль Экранного времени), создать резервную копию с новым паролем и узнать из неё пароль от iCloud
  • iOS 13: установить или изменить пароль от резервной копии iTunes
  • Обновить версию iOS
  • Сбросить устройство к заводским настройкам, отключить iCloud lock
  • Просматривать пароли из Связки ключей
  • Получить доступ к некоторым типам данных в iCloud (потребуется указать пароль от iCloud и одноразовый код двухфакторной аутентификации – оба из которых можно сбросить и настроить заново при помощи кода блокировки экрана). В список входят такие данные, как облачная связка ключей (пароли от учётных записей пользователя, заполненные формы в Safari), данные Здоровья и Экранного времени, сообщения (SMS, iMessage).
  • Сменить или удалить код блокировки экрана (при его удалении станут недоступными некоторые данные как в самом iPhone, так и в облаке iCloud)

Подводные камни

  • Установленный неизвестный пароль Экранного времени не позволит сбросить пароль от резервной копии iTunes.
  • Если пользователь установил ограничения на изменения в учётную запись Apple ID и защитил ограничение паролем Экранного времени, то сбросить пароль от iCloud не удастся.
  • При смене кода блокировки экрана iOS потребует установить соединение с iCloud. Это нужно для добавления iPhone в круг доверенных устройств, которые будут синхронизировать защищённую часть данных (пароли из облачной связки ключей, Здоровье, сообщения, Экранное время).

Выглядит достаточно запутанно? Мы только начали!

Пароль от iCloud

Так же, как и код блокировки экрана, учётная запись в iCloud не является обязательной. Впрочем, так же, как и в случае с кодом блокировки, без учётной записи в iCloud вы не сможете полноценно пользоваться устройством. Пароль от iCloud совпадает с паролем от учётной записи Apple ID, а без учётной записи Apple вы не сможете не только синхронизировать данные в и создавать резервные копии в iCloud, но и загружать приложения, даже бесплатные, из магазина App Store, слушать музыку и совершать покупки в Apple Music и так далее. Мало кто покупает iPhone исключительно для звонков и просмотра веб-страниц через встроенный браузер, поэтому большинство пользователей заводит себе учётную запись Apple ID.

В Apple контролируют минимальную сложность пароля к iCloud; слишком простой пароль установить не получится, равно как и пароль, совпадающий с одним из тех, которые использовались ранее.

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

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

Частный случай пароля от Apple ID в случаях, когда используется двухфакторная аутентификация – пароль приложений. Пароль приложения можно создать в учётной записи Apple ID; он будет сгенерирован автоматически (а не установлен пользователем). Использовать пароль приложения можно в ряде сценариев, когда то или иное приложение не поддерживает двухфакторную аутентификацию. Примеры таких приложений – некоторые сторонние почтовые клиенты или утилита Cydia Impactor для установки сторонних (не из App Store) приложений на устройство с iOS. Кроме того, пароль приложения требуется создать и в том случае, если вы используете агент-экстрактор из состава Elcomsoft iOS Forensic Toolkit с для извлечения образа файловой системы.

Можно ли обойти пароль и всё равно получить доступ к данным из облака? Да, но набор доступных таким образом данных будет ограничен; подробности – в статье Accessing iCloud With and Without a Password in 2019.

Если пароль от iCloud утрачен

Пароль от iCloud используется значительно реже кода блокировки экрана; соответственно, забывают его пользователи гораздо чаще. Для его восстановления Apple опубликовали подробную инструкцию (https://support.apple.com/ru-ru/HT201487) в статье Если вы забыли пароль учётной записи Apple ID.

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

Кроме того, пароль от iCloud можно узнать, проанализировав пароли, сохранённые в браузере на компьютере (Chrome, IE, Edge, Firefox) при помощи Internet Password Breaker (Windows), либо извлечь из связки ключей macOS при помощи Password Digger. Наконец, можно проанализировать зашифрованную резервную копию iOS при помощи Phone Breaker.

Итак, если утрачен пароль от iCloud, вы сможете:

  • Сбросить его с вашего iPhone или другого устройства из экосистемы Apple (потребуется код блокировки экрана, должна быть включена двухфакторная аутентификация, одноразовый код не потребуется)
  • Сбросить с чужого устройства из экосистемы Apple (код блокировки экрана, должна быть включена двухфакторная аутентификация, нужно ввести одноразовый код)
  • Сбросить через браузер (процесс различается для учётных записей с 2FA и без; потребуется доступ к ящику электронной почты, привязанному к данному Apple ID, одноразовый код двухфакторной аутентификации для учётных записей с 2FA; под может быть доставлен посредством SMS, отправленной на доверенный номер телефона – который, напомним, можно сменить при помощи кода блокировки экрана).

Если пароль от iCloud известен

Как ни странно, если известен пароль от iCloud и только он, сделать можно не так и много. Перечислим:

  • Заново настроить устройство, если был утрачен код блокировки экрана (сброс через Recovery, настройка с нуля, ввести пароль от iCloud для отвязки от iCloud).
  • Подтверждать покупки в App Store и iTunes Store (альтернатива – биометрическая аутентификация, для настройки которой, впрочем, всё равно потребуется ввести пароль от iCloud).
  • Подтверждать обновление приложений (пароль запрашивается не всегда; закономерности выявить не удалось).
  • Логин в App Store (если включена двухфакторная аутентификация, потребуется одноразовый код)
  • Извлекать ограниченное количество данных из iCloud (если двухфакторная аутентификация не включена).
  • Извлекать чуть больше данных из iCloud (только если двухфакторная аутентификация включена и доступен одноразовый код).
  • Извлекать ещё чуть больше данных из iCloud (пароли облачной связки ключей, пароль Экранного времени, сообщения, Здоровье; только если двухфакторная аутентификация включена, доступен одноразовый код и код блокировки экрана).
  • Отвязать iPhone от iCloud, отключить Find My iPhone, осуществить сброс к заводским настройкам.
  • Войти в учётную запись Apple из браузера (если включена двухфакторная аутентификация, потребуется одноразовый код).
  • Дистанционно стереть или заблокировать iPhone при помощи сервиса iCloud Find (одноразовый код не нужен даже для учётных записей с двухфакторной аутентификацией).
  • Сменить пароль от Apple ID/iCloud.
  • Добавление учётной записи на устройствах Apple; устройство становится доверенным (если включена двухфакторная аутентификация, потребуется одноразовый код).

Подводные камни

  • Пароль от iCloud не получится сбросить или изменить, если на устройстве настроено ограничение Экранного времени на действия с учётной записью (а пароль Экранного времени неизвестен)
  • Уже по списку «если пароль известен» видно, что сам по себе пароль от iCloud практически бесполезен, если в учётной записи включена двухфакторная аутентификация. Имея доступ ко второму фактору, можно легко сбросить пароль от iCloud. А вот добавить или изменить дополнительный фактор аутентификации, имея только пароль от iCloud, невозможно. Существующая официальная процедура восстановления учётной записи не даёт гарантированного результата (в нашей лаборатории мы смогли восстановить лишь каждую вторую учётную запись). Похоже, дополнительный фактор аутентификации в настоящий момент имеет больший вес, чем пароль от iCloud.

Пароль от резервной копии iTunes

Этот пароль такой же опциональный, как и предыдущие два. Более того, если не установить пароль на резервную копию, то для неискушённого пользователя не изменится, по большому счёту, ничего: все возможности как устройства, так и облачных сервисов будут доступны точно так же, как и с паролем. В статье The Most Unusual Things about iPhone Backups мы описали некоторые особенности паролей от резервной копии.

Для чего вообще нужен этот пароль? Очевидно, для шифрования резервной копии, которую можно создать в iTunes. Нужно ли задавать этот пароль, если вы никогда не создавали резервные копии в iTunes и не собираетесь этого делать? Да, нужно, потому что резервную копию злоумышленник может создать за вас, после чего получит доступ практически к полному содержимому телефона, включая все ваши пароли к учётным записям, которые вы использовали в браузере Safari. Помешает ли этот пароль злоумышленнику, если он получит ваш iPhone и узнает его код блокировки? Нет, не помешает, но вы сможете дополнительно (и достаточно надёжно) защитить его паролем Экранного времени.

Насколько вообще безопасен пароль от резервной копии iTunes? Если в руки злоумышленника попадут только файлы резервной копии, зашифрованные неизвестным паролем, то вам повезло: скорость перебора будет исключительно низкой. Даже на профессиональном оборудовании с использованием аппаратного ускорения и распределённых вычислительных сетей скорость перебора на одном компьютере не превышает 100 паролей в секунду. Это – очень низкая скорость; пароль из случайного набора букв и цифр длиной хотя бы в 6 символов не будет вскрыт и за сотню лет.

Ситуация меняется на свою полную противоположность, если в руки злоумышленника попадёт ваш iPhone, а код блокировки экрана подсмотрят или узнают иным способом. Используя код блокировки экрана, пароль от резервной копии iTunes можно сбросить буквально за пару шагов (вместе с ним удаляется и код блокировки телефона). Если же цель – узнать оригинальный пароль, то на телефон можно установить джейлбрейк (для ряда устройств это возможно независимо от версии iOS), после чего пароль извлекается из скрытой записи Связки ключей.

Наконец, если на iPhone запущена iOS 13, то для установки или смены пароля от резервной копии также потребуется ввести код блокировки экрана. Подытожим:

Если пароль от резервной копии iTunes утрачен

  • Если оригинальный iPhone – в вашем распоряжении, вы сможете сбросить пароль от резервной копии iTunes; для этого нужен код блокировки экрана. Если установлен пароль Экранного времени, то потребуется ввести и его.
  • Если же в вашем распоряжении – только файлы резервной копии, то единственный возможный вариант – атака по словарю или методом полного перебора.
  • Если ваша цель – анализ данных из локальной резервной копии, то заменить её может восстановление на новое устройство либо скачивание и анализ комбинации из облачной резервной копии устройства и облачной связки ключей из iCloud. Для доступа к ним нужны будут пароль от iCloud, одноразовый код двухфакторной аутентификации и (для анализа облачной связки ключей) код блокировки экрана телефона.

Если пароль от резервной копии iTunes известен

Известный пароль от резервной копии (при наличии самой резервной копии) позволит:

  • Восстановить из резервной копии как оригинальное, так и новое устройство с iOS, включая восстановление Связки ключей с паролями.
  • Проанализировать содержимое резервной копии (включая пароли из Связки ключей).
  • Узнать пароль Экранного времени (только для iOS 12) или пароль ограничений (для iOS 11). Приложений для этого существует достаточно много; отобразить пароль Экранного времени в состоянии, к примеру, Elcomsoft Phone Viewer.
  • Узнать пароль от iCloud/Apple ID (об этом подробнее – чуть ниже).

Подводные камни

  • Пароль от iCloud не всегда можно найти в резервной копии. Точную зависимость установить не удалось.
  • Пароль Экранного времени можно узнать только для старых версий iOS. В резервных копиях, созданных iOS 13 и более свежими сборками, пароль Экранного времени получил более высокий класс защиты и не может быть расшифрован из резервной копии.
  • Если вам пришлось сбросить пароль от резервной копии iTunes через настройки телефона, то код блокировки экрана также будет сброшен. Это приведёт к удалению с устройства данных обо всех транзакциях Apple Pay, писем и данных Exchange. Вы потеряете возможность сбросить пароль от iCloud; будет утрачен доступ к облачной связке ключей и другим защищённым данным в облаке. Впрочем, доступ к «облачным» данным можно восстановить, задав код блокировки заново и позволив системе добавить устройство в список доверенных.

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

com.apple.account.AppleIDAuthentication.password

apple.account.iTunesStore.password и apple.account.AppleAccount.password (устаревшие записи, в которых всё ещё может оказаться пароль)

Пароль от iCloud можно обнаружить и в следующих записях, принадлежащих браузеру Safari:

  • appleid.apple.com
  • www.icloud.com
  • idmsa.apple.com
  • id.apple.com
  • store.apple.com
  • apple.com

Пароль Экранного времени

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

Если пользователь установил пароль Экранного времени, то система будет запрашивать его при попытке изменить настройки как собственно ограничений, установленных в разделе Экранного времени, так и некоторых других системных настроек. В частности, система потребует ввести пароль Экранного времени (в дополнение к коду блокировки экрана) при попытке сбросить настройки (Reset All Settings) с целью сбросить пароль от резервной копии iTunes.

Пользователи могут установить и собственные ограничения. Например, может быть установлено ограничение на действия с учётной записью, после чего iOS не позволит сбросить пароль от iCloud посредством ввода кода блокировки. Ещё одно ограничение может запретить установку на устройство приложений, что не даст установить на устройство джейлбрейк и извлечь из него образ файловой системы. А вот защитить пароли в Связке ключей таким образом не получится: их всегда можно просмотреть, даже если установлен пароль Экранного времени.

Если пароль Экранного времени утрачен

  • Невозможно отключить или обойти установленные ограничения Экранного времени, убрать или сменить пароль
  • Невозможно включить функцию Экранного времени “Share across devices” («Учёт на всех устройствах»), благодаря которой пароль Экранного времени попадает в облако iCloud и может быть оттуда извлечён
  • Невозможно сбросить настройки для удаления пароля к резервной копии iTunes
  • В зависимости от установленных пользователем настроек, могут быть и другие ограничения: на сброс пароля от iCloud, установку приложений и другие.
  • iOS 12: пароль Экранного времени можно извлечь из локальной резервной копии с паролем (если пароль от резервной копии iTunes известен).
  • iOS 12 и 13: пароль Экранного времени можно извлечь из iCloud, если известны пароль от iCloud, есть одноразовый код двухфакторной аутентификации и известен код блокировки устройства (не обязательно данного конкретного устройства, но хотя бы одного устройства из доверенного круга); функция Экранного времени “Share across devices” («Учёт на всех устройствах») должна быть уже включена.

Если пароль Экранного времени известен

Если пароль Экранного времени известен, вы сможете:

  • Настраивать и отключать ограничения Экранного времени.
  • Сменить или удалить пароль Экранного времени.
  • Если известен код блокировки устройства, сменить пароль от резервной копии iTunes.

Подводные камни

  • iOS 12: для того, чтобы извлечь пароль Экранного времени из локальной резервной копии, необходимо, чтобы локальная копия была зашифрована паролем, а сам пароль от резервной копии iTunes – известен.
  • iOS 13: пароль Экранного времени хранится с повышенным классом защиты и не может быть извлечён из резервной копии. Вместо этого можно использовать извлечение из iCloud.
  • Из облака iCloud пароль Экранного времени можно извлечь лишь при условии, что пользователь включил функцию Экранного времени “Share across devices” («Учёт на всех устройствах»). Если эта функция включена, то в качестве кода блокировки можно использовать код блокировки экрана или системный пароль любого устройства Apple, входящего в «доверенный круг» (т.е. они зарегистрированы в том же Apple ID и на них также включена функция Экранного времени «Учёт на всех устройствах»).
  • Функция «Учёт на всех устройствах» работает исключительно в учётных записях с двухфакторной аутентификацией. Соответственно, потребуется ввести одноразовый код двухфакторной аутентификации.

Ссылки по теме:

  • How To Access Screen Time Password and Recover iOS Restrictions Password (link)
  • How to Extract Screen Time Passcodes and Voice Memos from iCloud (link)

Одноразовый код двухфакторной аутентификации

Итак, мы рассмотрели четыре пароля, которые защищают различные аспекты экосистемы Apple. Однако если в случае с iPhone даже слабого пароля может быть достаточно просто в силу того, что к телефону нужно ещё получить физический доступ, то защита онлайновой учётной записи одним лишь паролем давно показала свою несостоятельность. Яркий пример – Celebgate, событие, которое заставила Apple поторопиться и выпустить сырую версию двухфакторной аутентификации под названием Two-Step Verification.

Сегодня Apple использует гораздо более технически продвинутую и безопасную схему, которая называется просто и бесхитростно – Two-Factor Authentication, или двухфакторная аутентификация. В этой системе есть возможность настроить любое устройство Apple (и только Apple) в качестве доверенного «второго фактора». Кроме того, пользователю обязательно придётся добавить хотя бы один доверенный телефонный номер на тот случай, если единственное устройство Apple будет утеряно или украдено.

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

Нравится вам это или нет, но двухфакторную аутентификацию вам придётся включить, если вы хотите получить доступ к любому из перечисленных ниже сервисов:

Купив новое устройство с iOS 13 и зарегистрировав свежий идентификатор Apple ID, вы просто не сможете настроить его без двухфакторной аутентификации. Раз включив, отключить её уже не получится: прецеденты единичны, и каждый случай требовал персонального обращения в поддержку Apple и длительного периода ожидания.

О том значении, которое придаёт Apple двухфакторной аутентификации, говорит тот факт, что посредством второго «дополнительного» фактора легко можно сбросить пароль от Apple ID/iCloud. А вот если потерять доступ ко всем носителям «дополнительного» фактора (включая устройства Apple и доверенный телефонный номер – что на самом деле легко, если вы в заграничной поездке), то получить доступа к собственной учётной записи не получится. Точнее, это можно будет проделать, заполнив заявку, и после длительного (несколько недель) периода ожидания с пятидесятипроцентной вероятностью доступ к учётной записи может быть (а может и не быть) предоставлен.

Если доступ ко второму фактору аутентификации утрачен

Если доступа ко второму фактору аутентификации нет, наступят следующие последствия:

  • Доступ к учётной записи Apple ID и к iCloud невозможен, даже если пароль от iCloud известен. Исключения – функция Find My и отвязка сброшенного телефона от iCloud; в обоих этих случаях достаточно одного лишь пароля от iCloud.
  • Возможно, вам удастся восстановить доступ к учётной записи Apple через официальную процедуру. Процесс длительный (несколько недель), а результат не гарантирован.
  • Второй фактор аутентификации лучше не терять.

Если доступ ко второму фактору аутентификации имеется

Если же у вас есть доступ ко второму фактору аутентификации, можно проделать следующие вещи:

  • Сбросить пароль от iCloud/Apple ID с доверенного устройства (оно выступает в роли второго фактора)
  • Восстановить доступ к учётной записи Apple ID и сбросить пароль от iCloud при помощи одноразового кода двухфакторной аутентификации (с чужого устройства Apple)
  • После сброса пароля от iCloud войти в учётную запись и извлечь из неё данные (часть данных будет дополнительно защищена кодом блокировки экрана)
  • Восстановить из облачной резервной копии новое или актуальное устройство Apple
  • При восстановлении из облачной резервной копии существующего устройства (именно того, с которого была ранее создана резервная копия) будут восстановлены и пароли из Связки ключей (даже если вам неизвестен код блокировки экрана, который необходим для скачивания синхронизированной «облачной связки ключей»).

Подводные камни

  • Даже в случае утраты доступа ко второму фактору аутентификации будут доступны функция Find My и отвязка сброшенного телефона от iCloud. Для их работы достаточно одного лишь пароля от iCloud.
  • Связка ключей из облачной резервной копии может быть восстановлена исключительно на то же самое физическое устройство, с которого была создана резервная копия. Для доступа к Облачной связке ключей необходимо ввести код блокировки экрана от одного из предыдущих устройств.

Пароли и политики безопасности

Политики безопасности, ограничивающие использование слишком простых паролей, различаются для всех четырёх (с половиной) паролей.

  • Код блокировки экрана: официальной политики нет. По умолчанию система предлагает использовать код, состоящий из 6 цифр, но по желанию пользователь может выбрать и 4-значный PIN, а также цифровой пароль произвольной длины либо буквенно-цифровой пароль произвольного размера. У Apple есть база данных самых часто используемых паролей; если пользователь попытается установить именно такой пароль (например, 0000, 1111 или 1234), то система предупредит о небезопасности такого кода блокировки – но всё же позволит его установить. Просмотреть список небезопасных паролей можно по ссылке GitHub.
  • Пароль от iCloud: минимальная длина – 8 знаков. Требуется использовать по крайней мере одну строчную и одну заглавную букву, а также по крайней мере одну цифру. При смене пароля не позволяется установка ранее использованных паролей.
  • Пароль от резервной копии iTunes: ограничения отсутствуют. В iOS 13 установка или смена пароля от резервной копии требует ввода кода блокировки экрана.
  • Пароль Экранного времени: всегда ровно 4 цифры.
  • Двухфакторная аутентификация: доверенными устройствами могут стать только устройства из экосистемы Apple (iPhone, iPad, компьютер Mac). Требуется наличие хотя бы одного доверенного телефонного номера, при этом допускается наличие в одной учётной записи нескольких доверенных телефонных номеров из разных стран, что может быть удобно в поездках.Одноразовый код двухфакторной аутентификации всегда состоит из 6 цифр, а время действия ограничено 30 секундами. Получить его можно в виде push-сообщения на доверенное устройство (требуется доступ в Интернет, устройство необходимо разблокировать), а также в виде SMS или телефонного звонка на доверенный телефонный номер. Кроме того, при наличии разблокированного устройства одноразовый код можно получить и без доступа к Интернет из настроек устройства.

Реакция на попытку перебора

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

  • Код блокировки экрана: iOS будет увеличивать задержку между попытками ввода. Через определённое количество неудачных попыток устройство будет перманентно заблокировано: на экране появится сообщение “Connect to iTunes”, но подключить устройство к компьютеру не удастся из-за активированного режима защиты USB. У пользователя есть некоторая степень контроля: так, в настройках можно включить функцию “Erase after 10 attempts” setting, которая сбросит устройство к заводским настройкам после 10 неудачных попыток.
  • Пароль от iCloud: попытка подобрать пароль приведёт к временной блокировке учётной записи. Точное количество доступных попыток не разглашается. Важный момент: если вы попытаетесь подобрать код блокировки экрана устройства, посредством которого защищается доступ к Облачной связке ключей (а также паролю Экранного времени, данным Здоровья и сообщениям), то система удалит защищённые данные (ту самую Облачную связку ключей и далее по списку) после 10 неудачных попыток.
  • Пароль от резервной копии iTunes: никаких ограничений. Ломайте на здоровье!
  • Пароль Экранного времени: увеличивающаяся задержка между попытками ввода; после 10 попыток, задержка между попытками составляет ровно час.
  • Одноразовые коды двухфакторной аутентификации: у пользователя есть ограниченное число попыток для ввода кода двухфакторной аутентификации. Если код подобрать не удалось, то будут применяться правила для защиты от попытки подбора пароля к iCloud.

Заключение

В статье мы попытались разобраться в запутанных взаимоотношениях между четырьмя (с половиной) паролями Apple. Если вам кажется, что после этой статьи вы понимаете меньше, чем до неё – это совершенно нормально: о том, каким образом одни пароли влияют на другие, могут уверенно рассуждать разве что работники Apple, которое эту систему проектировали. С нашей точки зрения как экспертов по безопасности созданная Apple система кажется не до конца продуманной и местами нелогичной. Самыми нелогичными решениями Apple нам представляются возможности сброса пароля от резервной копии iTunes и пароля от iCloud посредством одного лишь кода блокировки экрана. Система безопасности, созданная Google, представляется нам гораздо более стройной и логичной (о ней мы обязательно напишем в будущем).

Создаётся ощущение, что ряд правил и возможностей вводились компанией либо под давлением пользователей («Как мне сбросить пароль от резервной копии? Что, совсем никак? Ну, вы…»), либо при попытке быстро закрыть обнаруженную дыру в безопасности. Такой подход не позволяет нам искренне похвалить созданную в Apple систему безопасности пользовательской экосистемы. В то же время, понятны и причины, по которым компании пришлось пойти на компромиссы.

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

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

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

Конкуренция среди производителей сетевых хранилищ для домашних пользователей и офисов огромна. Здесь и исключительно популярные модели Western Digital, подкупающие нулевой или отрицательной ценой (NAS со встроенным диском стоит дешевле такого же диска отдельно), и признанные гранды QNAP и Synology, которые берут мощной программной частью и длительной поддержкой, и выступающие с переменным успехом Asustor и Drobo, и даже экзотические для нас Buffalo, Terra Master и Thecus.

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

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

Шифрование в Synology

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

В некоторых NAS, в которых есть возможность зашифровать данные, используется либо защита всего накопителя целиком (аппаратное шифрование SED на уровне контроллера SATA), либо шифрование тома, расположенного как на одном диске, так и на массиве RAID. В некоторых моделях (например, QNAP), можно активировать оба способа – и это правильно, т.к. позволяет избежать некоторых очевидных атак.

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

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

В достоинства можно записать следующее:

  1. Поскольку шифруются отдельные сетевые папки, не имеет значения, на каком из внутренних физических или логических накопителей они расположены. А вот шифрование папок на внешних накопителях Synology не поддерживает.
  2. Каждый пользователь может зашифровать свою папку своим собственным паролем. Таким образом, обеспечивается защита и между отдельными пользователями.
  3. Стандартная реализация шифрования позволяет просто скопировать зашифрованную папку, к примеру, на другой накопитель – и данные останутся надёжно зашифрованными. При этом смонтировать и расшифровать такую папку получится стандартными средствами на любом компьютере с Linux.
  4. Шифруются как сами данные, так и имена папок и файлов.

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

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

Ещё один популярный сценарий – возможность моментального уничтожения данных на зашифрованном накопителе. Так, если используется зашифрованный том (BitLocker, VeraCrypt, FileVault 2 и т.п.), то пользователю достаточно удалить единственный блок данных, в котором содержатся ключ шифрования данных. После этого все данные на зашифрованном томе становятся перманентно недоступными – даже если взломщику известен пароль. В случае eCryptFS ключи шифрования данных хранятся в заголовке каждого отдельного файла, и их моментальное уничтожение невозможно.

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

Однако на этом проблемы eCryptFS не заканчиваются. Кроме ограничений, касающихся безопасности, в eCryptFS есть и чисто функциональные ограничения, основное из которых – ограничение на длину имён файлов. В имени файла в зашифрованной папке не может быть больше 143 символов ANSI или 47 символа иероглифической записи. На этом фоне невозможность использовать NFS с зашифрованными папками уже не удивляет.

Хорошо, об ограничениях eCryptFS поговорили; принципиально это те же ограничения, которые будут у любой другой компании, которая решит сэкономить на проектировании и разработке и использует в недешёвом коммерческом продукте готовое бесплатное решение с открытым исходным кодом. А что насчёт уязвимостей в конкретной реализации от Synology? Они есть, и их больше одной. Но прежде, чем говорить об уязвимостях, рассмотрим механизм управления ключами, реализованный в Synology.

Управление ключами шифрования в Synology DSM

Все сетевые хранилища Synology работают под управлением ОС под названием Disk Station Manager, DSM. Практически все модели компании (по крайней мере, те из них, которые были выпущены в последние 5-6 лет) работают под управлением унифицированной сборки DSM; обновления выходят практически одновременно для всех моделей. На сегодня актуальны сборки DSM 6.2.

Для управления ключами в DSM 6.2 используется утилита Key Manager, основная задача которой – хранение ключей и осуществление возможности автоматического монтирования зашифрованных томов после загрузки устройства.

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

Пользователь может выбрать один из трёх вариантов управления ключами.

  1. Полностью ручное управление. На устройстве Synology пароль не сохраняется (помним при этом о файле с ключом, который был автоматически сохранён на компьютер пользователя). При включении NAS или перезагрузке DSM зашифрованные тома автоматически размонтируются. Для их монтирования нужно будет зайти в администраторский веб-интерфейс, открыть раздел сетевых папок и вручную смонтировать все нужные зашифрованные папки. Для продвинутых пользователей существует неофициальный и недокументированный вариант с удалённым монтированием через SSH, но, полагаю, большинству домашних и офисных пользователей об этом неизвестно.
  2. Двоичный ключ шифрования (“machine key” в терминах DSM) сохраняется на устройстве Synology. Зачем это может понадобиться пользователю? Именно для того, чтобы избежать описанных в первом пункте шагов для монтирования зашифрованного тома! Достаточно поставить галочку в пункте “mount on boot”, и DSM автоматически смонтирует зашифрованную папку при загрузке. Удобно! О безопасности, правда, можно забыть: если и ключ шифрования, и сами данные хранятся на одном и том же устройстве, то их расшифровка тривиальна как в случае анализа устройства целиком, так и при извлечении из него только дисков.
  3. Наконец, реверанс в сторону безопасности: ключ шифрования сохраняется не на самом устройстве, а на внешнем USB накопителе. Более того, ключ шифрования MEK, сохранённый на внешнем USB накопителе можно зашифровать своим собственным паролем (KEK) – и это важный момент, позволяющий использовать сложный случайный набор символов для шифрования собственно файлов. Тем не менее, и для ключей шифрования, сохранённых на USB накопителе, опция “mount on boot” по-прежнему доступна. Это означает, что при активации этой опции пароль шифрования ключа (KEK), который вводит пользователь, сохраняется на устройстве Synology. Отметим и этот момент.Что происходит, если опция “mount on boot” включена, а USB накопитель с ключом вставлен в NAS во время загрузки DSM? Сетевые папки расшифровываются и монтируются автоматически. А если опция “mount on boot” выключена? Тогда не монтируются.Что произойдёт, если вставить USB накопитель с ключом уже после загрузки, когда зашифрованная папка не смонтирована? Автоматически не монтируется, будет предложен выбор из трёх вариантов аутентификации:

Как DSM получает двоичный ключ шифрования для алгоритма AES из пароля пользователя? Пароль шифрования, который указал пользователь, «оборачивается» очередным ключом, который называется “wrapping key”. Именно wrapping key выполняет роль ключа KEK, который должен защитить ключ шифрования данных MEK.

Примерно такую схему я ожидал увидеть при анализе защиты DSM. На самом же деле оказалось, что в DSM (уточню: в тех версиях DSM, которые работают на потребительских моделях Synology, предназначенных для дома и офиса) не используется ничего подобного. Данные, как мы выяснили, шифруются посредством пароля, который устанавливает пользователь. А вот сам пароль шифруется одной единственной жёстко прошитой в систему фразой “$1$5YN01o9y” – аналогом печально известного “default_password”, использующегося при шифровании по методу FDE в Android.

Что даёт такой подход к шифрованию? Во-первых, если пароль шифрования сетевой папки нам известен, расшифровать её содержимое мы можем на абсолютно любом компьютере с Linux, просто вытащив диск из сетевого накопителя. Сложности, связанные с монтированием RAID массива мы оставим в стороне – в конце концов, программы для этого существуют даже для Windows.

Во-вторых, если пользователь сохранил ключ во встроенной утилите Key Manager (а это делают часто, ведь монтирование зашифрованных папок в DSM – процесс небыстрый и не самый удобный), то такой сохранённый ключ тоже шифруется всё тем же wrapping key – теперь можно не только расшифровать данные, но и увидеть сам пароль, который вводил пользователь!

Если ключ шифрования сохраняется на встроенном накопителе, пароль wrapping passphrase сменить нельзя. Этот пароль один и тот же на всех накопителях Synology.

Что получается в результате? При использовании встроенной в DSM утилиты Key Manager уровень защиты данных отрицательный: и данные, и ключ шифрования MEK хранятся на жёстком диске, а ключ KEK фиксированный и нам известен. Соответственно, расшифровать можно не только данные пользователя, но и его пароль – который можно попробовать использовать для расшифровки другой информации по цепочке.

Для лучшего понимания всей глубины проблемы сравним механизм шифрования DSM с тем, что используют компьютеры с Windows. Для защиты данных в Windows используется широко известный и подробно документированный алгоритм BitLocker, которым можно зашифровать системный раздел. Ключ шифрования данных MEK сохраняется в составе контейнера; при этом ключ MEK будет зашифрован ключом KEK, который выдаёт защищённый модуль TPM2.0 (доступны разнообразные политики, позволяющие дополнительно защитить этот ключ PIN-кодом, ключом на флешке или комбинацией этих факторов). Извлечь оттуда этот ключ практически невозможно, проще провести лобовую атаку пароля учётной записи Windows. Таким образом, если мы извлечём из компьютера зашифрованный BitLocker-ом диск, то расшифровать его не удастся даже в том случае, когда используется защита самого начального уровня – BitLocker Device Protection. Для расшифровки потребуется, чтобы диск был установлен в тот самый компьютер с тем самым аппаратным модулем TPM, плюс – пароль от учётной записи пользователя. Просто TPM или просто пароля от учётной записи для расшифровки раздела недостаточно.

Если с защитой данных всё так плохо, то в чём смысл включать шифрование и использовать встроенный Key Manager? Причин несколько.

  1. Peace of mind. Чувство защищённости и спокойный сон очень важны для здоровья. О том, что чувство безопасности – ложное, можно никогда и не узнать.
  2. Безопасная продажа или утилизация работоспособного накопителя. При продаже или утилизации старых дисков потребуется уничтожить данные. Это можно сделать, полностью перезаписав содержимое накопителя, что займёт несколько часов. Но той же цели можно добиться проще и быстрее, просто удалив ключи шифрования из Key Manager. Теперь зашифрованные данные – просто цифровой шум, а диск достаточно заново инициализировать.Обратите внимание: в отличие от защиты BitLocker или VeraCrypt, в которых достаточно удалить единственный ключ шифрования данных, в Synology возможность атаки и восстановления даже удалённых зашифрованных файлов остаётся, и она заметно отлична от нуля. Сценарий «безопасной утилизации» дисков в сетевых накопителях Synology не реализован, и рассчитывать на него нельзя.
  3. Если сохранить ключ не на встроенный, а на внешний USB накопитель, то Key Manager предложит ввести свой собственный пароль для защиты ключа. Теперь для расшифровки дисков потребуется USB накопитель с ключом шифрования. Впрочем, если активирован режим автоматического монтирования томов, то пароль, которым защищён ключ шифрования, будет сохранён на внутреннем накопителе Synology.

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

  1. Пользователь добавляет ключ в Key Manager, сохраняя его на встроенном накопителе. Положение переключателя “mount on boot” в данном случае значения не имеет.
  2. Пользователь сохраняет ключ на внешнем USB накопителе, и у злоумышленника есть доступ к этому накопителю.
  3. Ключ шифрования автоматически сохраняется на компьютер пользователя при создании зашифрованной сетевой папке. Если злоумышленнику доступен этот ключ, проблемы с расшифровкой данных не будет. Имя файла по умолчанию — <name_of_encrypted_share>.key
  4. Наконец, если злоумышленнику удалось узнать пароль шифрования, то расшифровка данных тривиальна. А вот защититься от неё чрезвычайно сложно: казалось бы, простейшая и привычная смена пароля в Synology превращается в многочасовую операцию по перешифровке метаданных.

Уязвимости и их использование

Итак, подытожим описанное выше. В Synology DSM используется стандартная криптографическая файловая система eCryptFS, при этом шифрование SED (Self-Encrypting Disk) на уровне SATA домашними и офисными устройствами не используется. Ключи шифрования могут сохраняться на встроенный или внешний накопитель. В первом случае ключ шифрования защищается фиксированным паролем; во втором – пароль задаёт пользователь, но этот пароль сохраняется на встроенном накопителе (по крайней мере, если включена опция “mount on boot”).

Уязвимость 1: Отсутствие шифрования SED, а также шифрования на уровне тома, позволяет извлечь диск и изменить пароль от административной учётной записи владельца устройства, просто отредактировав файл с учётными записями.

Уязвимость 2: Если пользователь сохранил ключ шифрования в DSM Key Manager, его можно извлечь и использовать для расшифровки зашифрованных данных. Кроме того, из сохранённого ключа шифрования легко разворачивается и оригинальный пароль, который вводил пользователь при создании зашифрованной сетевой папки.

Уязвимость 3: Все устройства Synology используют фиксированный пароль для шифрования ключа шифрования.

Следующая команда отобразит оригинальный пароль, который вводил пользователь при создании зашифрованной папки:

printf "%s" "\$1\$5YN01o9y" | ecryptfs-unwrap-passphrase keyfile.key -

Здесь “$1$5YN01o9y” – тот самый фиксированный ключ wrapping passphrase, а “keyfile.key” – зашифрованный ключ шифрования данных MEK.

Узнав пароль, можно смонтировать зашифрованную папку на любом компьютере с Linux. То же самое можно сделать и одной командой посредством файла с ключом шифрования:

mount -t ecryptfs -o key=passphrase,ecryptfs_cipher=aes,ecryptfs_key_bytes=32,ecryptfs_passthrough=no,ecryptfs_enable_filename_crypto=yes,passwd=$(printf "%s" "\$1\$5YN01o9y" | ecryptfs-unwrap-passphrase /path/to/keyfile.key -) /path/to/encrypted/folder /path/to/mountpoint

Пути /path/to/keyfile.key, /path/to/encrypted/folder и /path/to/mountpoint нужно заменить на фактически используемые. Физически зашифрованное содержимое сетевых папок DSM сохраняет в следующей коннотации:

/Volume<N>/@<name_of_encrypted_share@

В примере выше путь будет таким:

/Volume1/@Encrypted_Share@

Статьи по теме:

  • How To Recover Synology encrypted folders in Linux (Robert Castle)
  • How to decrypt ecryptfs file with private key instead of passphrase (slackexchange)
  • Automatically mounting encrypted folders (на немецком) (synology-forum.de)
  • Script: Decrypt encrypted folders via keyfile (.key) (на немецком) (synology-forum.de)

Если пользователь сохранил ключ на внешнем USB накопителе, DSM запросит ввести пароль для шифрования этого ключа.

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

Наконец, если пользователь ни в каком виде не сохранил ключ шифрования в Key Manager, то данные в относительной безопасности. «Относительной» потому, что средняя энтропия пользовательских паролей значительно ниже энтропии 256-битного ключа шифрования AES. Атаки на пароли именно этого типа существуют давно, отлично оптимизированы и работают чрезвычайно быстро (в отличие, например, от атак на ключи BitLocker или документы, созданные в Microsoft Office 2016, которые при прочих равных работают значительно медленнее). Никто не отменял и человеческий фактор (1, 2, 3 и 4), который также может использоваться для взлома таких паролей.

Заключение

Данные расшифрованы, всё пропало? Реальная безопасность «непробиваемого» шифрования в Synology оказалась ниже ожидаемой в силу отсутствия каких-либо аппаратных механизмов обеспечения безопасности и сомнительного выбора базовой платформы. Для обеспечения безопасности ключей шифрования в iOS используется Secure Enclave, в Windows – TPM2.0, в устройствах с Android – TrustZone. В домашних и офисных моделях Synology не используется ничего из вышеперечисленного, хотя даже в SoC Realtek RTD1296, на которой основаны младшие модели Synology DS118, DS218Play и DS218, поддержка ARM TrustZone есть. Роль аппаратного модуля безопасности выполняет фиксированная фраза “$1$5YN01o9y” – аналог “default_password” в старых версиях Android.

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

НАШИ НОВОСТИ