Соответствие нормам безопасного хранения информации защита персональных данных – то, над чем работают практически все производители средств хранения информации. И если в корпоративном сегменте представлены относительно надёжные решения, то рекламным лозунгам «безопасное шифрование AES-256» в накопителях, ориентированных на домашний сегмент, безусловно верить не стоит. Неоднозначная реализация средств защиты, небезопасное хранение ключей, использование псевдослучайных чисел, выбранных из 255 вариантов – лишь немногое из того, с чем нам довелось столкнуться в процессе исследования. В этой статье мы расскажем о том, как и от чего защищает пользовательские данные производитель самых популярных среди домашних и офисных пользователей сетевых хранилищ Synology.
Конкуренция среди производителей сетевых хранилищ для домашних пользователей и офисов огромна. Здесь и исключительно популярные модели Western Digital, подкупающие нулевой или отрицательной ценой (NAS со встроенным диском стоит дешевле такого же диска отдельно), и признанные гранды QNAP и Synology, которые берут мощной программной частью и длительной поддержкой, и выступающие с переменным успехом Asustor и Drobo, и даже экзотические для нас Buffalo, Terra Master и Thecus.
В большинстве моделей этих производителей в том или ином виде присутствует шифрование, позволяющее защитить пользовательские данные. Некоторые производители довольно забавно рекламируют возможность шифрования:
От каких угроз способны защитить зашифрованные данные сетевые накопители, насколько серьёзные атаки способны выдержать и как всё-таки добраться до зашифрованных файлов? Попробуем разобраться.
Все сетевые накопители используют один и тот же алгоритм шифрования AES, как правило, с длиной ключа 256 бит (нам встречались варианты и со 192-битными ключами). Выбор алгоритма вполне логичен: большинство современных наборов микросхем в том или ином виде поддерживает аппаратное ускорение AES или хотя бы набор инструкций, использующихся именно в этом алгоритме. Тем не менее, реальная безопасность зашифрованных таким образом данных разительно отличается в зависимости от реализации.
В некоторых NAS, в которых есть возможность зашифровать данные, используется либо защита всего накопителя целиком (аппаратное шифрование SED на уровне контроллера SATA), либо шифрование тома, расположенного как на одном диске, так и на массиве RAID. В некоторых моделях (например, QNAP), можно активировать оба способа – и это правильно, т.к. позволяет избежать некоторых очевидных атак.
В моделях Synology, предназначенных для серверных стоек, также можно активировать аппаратное шифрование SED. Однако большинство домашних и офисных моделей такой возможности лишены. Вместо этого Synology предлагает использовать шифрование файлов на уровне отдельных сетевых папок.
Шифрование реализовано средствами стандартной для Linux файловой системы eCryptFS, о которой можно почитать здесь или здесь. В сравнении с методами шифрования, основанными на защите целых томов, у такого способа шифрования есть как достоинства, так и недостатки.
В достоинства можно записать следующее:
Если у пофайлового шифрования столько достоинств, почему производители корпоративных устройств предпочитают шифровать целые тома? К сожалению, у eCryptFS есть и ряд недостатков, способных серьёзно испортить опыт использования или даже сделать шифрование невозможным.
Шифрование, применяемое к отдельным файлам, не обеспечивает приемлемого уровня безопасности в ряде сценариев. В eCryptFS каждый файл хранится на диске отдельно; соответственно, даже без ключа шифрования легко определить такие вещи, как объём зашифрованных данных, количество файлов и размер каждого файла. Соответственно, к зашифрованным папкам применимы такие атаки, как профилирование по размеру файлов, что позволяет узнать содержимое зашифрованной папки, если размер заданного количества файлов совпадает с размером известных атакующему файлов.
Ещё один популярный сценарий – возможность моментального уничтожения данных на зашифрованном накопителе. Так, если используется зашифрованный том (BitLocker, VeraCrypt, FileVault 2 и т.п.), то пользователю достаточно удалить единственный блок данных, в котором содержатся ключ шифрования данных. После этого все данные на зашифрованном томе становятся перманентно недоступными – даже если взломщику известен пароль. В случае eCryptFS ключи шифрования данных хранятся в заголовке каждого отдельного файла, и их моментальное уничтожение невозможно.
Добавим сюда невозможность сменить пароль шифрования без длительной перешифровки метаданных, и получим классическую странную, непродуманную и небезопасную, зато – бесплатную и не требующую лицензионных отчислений реализацию шифрования.
Однако на этом проблемы eCryptFS не заканчиваются. Кроме ограничений, касающихся безопасности, в eCryptFS есть и чисто функциональные ограничения, основное из которых – ограничение на длину имён файлов. В имени файла в зашифрованной папке не может быть больше 143 символов ANSI или 47 символа иероглифической записи. На этом фоне невозможность использовать NFS с зашифрованными папками уже не удивляет.
Хорошо, об ограничениях eCryptFS поговорили; принципиально это те же ограничения, которые будут у любой другой компании, которая решит сэкономить на проектировании и разработке и использует в недешёвом коммерческом продукте готовое бесплатное решение с открытым исходным кодом. А что насчёт уязвимостей в конкретной реализации от Synology? Они есть, и их больше одной. Но прежде, чем говорить об уязвимостях, рассмотрим механизм управления ключами, реализованный в Synology.
Все сетевые хранилища Synology работают под управлением ОС под названием Disk Station Manager, DSM. Практически все модели компании (по крайней мере, те из них, которые были выпущены в последние 5-6 лет) работают под управлением унифицированной сборки DSM; обновления выходят практически одновременно для всех моделей. На сегодня актуальны сборки DSM 6.2.
Для управления ключами в DSM 6.2 используется утилита Key Manager, основная задача которой – хранение ключей и осуществление возможности автоматического монтирования зашифрованных томов после загрузки устройства.
После создания зашифрованной сетевой папки ключ (файл с расширением .key, представляющий из себя пароль в «обёртке» — практически обфускация) автоматически сохраняется на компьютер пользователя. Этот ключ можно сохранить (например, в зашифрованном архиве), а можно удалить – если пользователь уверен, что никогда не забудет пароль шифрования.
Пользователь может выбрать один из трёх вариантов управления ключами.
Как 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? Причин несколько.
Выполнение любого из перечисленных ниже условий делает зашифрованные данные уязвимыми:
Итак, подытожим описанное выше. В 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@
Статьи по теме:
Если пользователь сохранил ключ на внешнем 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 выбор простой: или относительно безопасно, но неудобно (сетевые папки монтировать каждый раз вручную, через веб-интерфейс, вводя каждый раз более или менее стойкий пароль шифрования), или удобно, но с нулевым уровнем безопасности. Компромиссным решением будет хранение ключа шифрования на подключаемой к устройству флешке, которую можно вставлять в процессе загрузки и физически извлекать из накопителя после её завершения.