15.2. Секретность в реализации Microsoft

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

15.2.1. Microsoft Word и Excel

Шифрование файлов было реализовано уже в Microsoft Word 2.0. Из пароля с помощью легко обратимого алгоритма получалась 16-байтовая гамма, которая накладывалась на содержимое документа. Но вычисление гаммы без пароля не составляло никакого труда, т. к. гамма накладывалась и на служебные области, которые имели фиксированное значение во всех документах.

В Word 6.0/95 и Excel 5.0/95 алгоритм шифрования не претерпел значительных изменений, но изменился формат файлов — он стал основываться на хранилище OLE Structured Storage. Для восстановления пароля документа все также требовалось найти 16-байтовую гамму, использованную для шифрования данных.

Один из методов, позволяющих отыскать гамму, например, для документов Word, основывается на простейшем статистическом анализе. Самый часто встречающийся символ в тексте на любом языке — пробел. Таким образом, достаточно определить код наиболее используемого символа  в каждой из 16 позиций, соответствующих разным байтам гаммы. Выполнив операцию ХОК каждого найденного значения с кодом пробела (0x20), мы получим 16 байт гаммы.

В программах Word 97/2000 и Excel 97/2000 данные шифруются при помощи алгоритма RC4 с ключом длиной 40 бит. Такое шифрование уже не позволяет моментально определить пароль. Но производительность вычислительной техники за последние годы выросла настолько сильно, что единственно правильный ключ шифрования документа Word (из 2" возможных) может быть найден -максимум за четверо суток на компьютере с двумя процессорами AMD Athlon 2600+.

Начиная с Office XP, наконец появилась поддержка шифрования документов ключами длиной более 40 бит. Но, похоже, большинство пользователей до сих пор продолжает использовать 40-битовое шифрование, т. к. оно позволяет открывать защищенные документы в предыдущих версиях офисных программ. Да и изменение настроек шифрования требует дополнительных действий со стороны пользователя (открытия диалога настроек и выбора нужного крипто-провайдера), а по умолчанию применяются 40-битовые ключи.

15.2.2. Microsoft Access

Базы данных Microsoft Access могут иметь два типа паролей: пароли на открытие и пароли для разграничения доступа на уровне пользователя.

Пароль на открытие, похоже, никогда не представлял серьезной защиты, т. к., начиная с Access версии 2.0, он хранился в заголовке базы данных. Правда, сам заголовок был зашифрован алгоритмом RC4, но это не сильно увеличивало стойкость, т. к. в рамках одной версии формата всегда использовался один и тот же 32-битовый ключ шифрования, жестко прошитый в динамически загружаемую библиотеку, отвечающую за работу с файлом базы данных.

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

Так для Access 97 необходимо было выполнить XOR 13 байт, расположенных по смещению 0x42 от начала файла базы данных, со следующей последовательностью:

0x86, OxFB, ОхЕС, 0x37, 0x5D, 0x44, 0х9С, OxFA, ОхСб, 0х5Е, 0x28, ОхЕб, 0x13.

Альтернативный способ снятия пароля заключался в исправлении заголовка и установке значения байта, соответствующего первому символу, в такое состояние, чтобы после расшифровки заголовка там оказывался нулевой байт. Тогда Access, интерпретирующий пароль как строку, заканчивающуюся нулевым символом, увидев ноль в первом байте, решит, что пароль вообще не установлен. Для снятия пароля в Access 97 необходимо установить байт по смещению 0x42 от начала файла в значение 0x86.

Кстати, разработчики одной коммерческой программы, позволяющей восстановить забытые пароли к базам Microsoft Access, в описании новшеств очередной версии указали, что время, затрачиваемое на отыскание пароля, уменьшилось в 1,5 раза. Вероятно, для этого им пришлось уменьшить задержку перед выводом найденного пароля на экран, т. к. значительно сложнее придумать очень медленный способ выполнения XOR, а потом ускорить его в 1,5 раза.

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

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

Другой тип паролей, поддерживаемых Microsoft Access, используется не для обеспечения секретности, а для разграничения доступа. Но при проектировании, похоже, было допущено несколько ошибок, связанных и с этими паролями.

Правильно было бы хранить не пароли, а их хэши. Но, по непонятным причинам, в системной базе данных, содержащей имена, пароли и прочие атрибуты всех пользователей, можно найти сами пароли, зашифрованные трехкратным DES с двумя ключами в режиме EDE (Encrypt-Decrypt-Encrypt), когда первый ключ применяется дважды, на первом и третьем шаге. Ключи, как обычно, являются константами и хранятся в динамически загружаемой библиотеке. Такая защита позволяет быстро определить пароль любого пользователя, хотя Microsoft утверждает, что утерянные пароли пользователей Access не могут быть восстановлены.

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

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

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

15.2.3. Microsoft Money

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

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

Но и тут не обошлось без "оригинальных" технических решений. Дело в том, что зашифровывается не весь файл, а только 15 первых блоков (в новых версиях каждый блок занимает 4 Кбайта). Такой подход, скорее всего, выбран с целью обеспечения возможности создания компактных архивных копий баз Money.

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

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

15.2.4. Encrypted File System

Начиная с Windows 2000 операционные системы, основанные на ядре NT, поддерживают Encrypted File System (EFS) — расширение файловой системы NTFS (New Technology File System), позволяющее хранить файлы пользователей в зашифрованном виде. При этом шифрование выполняется совершенно прозрачно и не требует от пользователя никаких дополнительных усилий, кроме однократного указания, что файл должен быть зашифрован.

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

Симметричный ключ, которым зашифровывается файл (File Encryption Key, FEK), сам зашифрован на открытом ключе, принадлежащем пользователю, имеющему права на доступ к файлу. FEK хранится вместе с зашифрованным файлом, и для его расшифровки используется секретный ключ пользователя.

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

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