Особенности шифрования и уязвимости в сетевых хранилищах Synology

21 февраля, 2020, Oleg Afonin
Рубрика: «Безопасность», «Криптография и шифрование», «Разное»
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

Соответствие нормам безопасного хранения информации защита персональных данных – то, над чем работают практически все производители средств хранения информации. И если в корпоративном сегменте представлены относительно надёжные решения, то рекламным лозунгам «безопасное шифрование 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 выбор простой: или относительно безопасно, но неудобно (сетевые папки монтировать каждый раз вручную, через веб-интерфейс, вводя каждый раз более или менее стойкий пароль шифрования), или удобно, но с нулевым уровнем безопасности. Компромиссным решением будет хранение ключа шифрования на подключаемой к устройству флешке, которую можно вставлять в процессе загрузки и физически извлекать из накопителя после её завершения.


  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
НАШИ НОВОСТИ