Уже на протяжении многих лет программы, входящие в 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 позиций, соответствующих разным байтам гаммы. Выполнив операцию XOR каждого найденного значения с кодом пробела (0x20), мы получим 16 байт гаммы. В программах Word 97/2000 и Excel 97/2000 данные шифруются при помощи алгоритма RC4 с ключом длиной 40 бит. Такое шифрование уже не позво- ляет моментально определить пароль. Но производительность вычислительной техники за последние годы выросла настолько сильно, что единственно правильный ключ шифрования документа Word (из 24 0 возможных) может быть найден'максимум за четверо суток на компьютере с двумя процессорами 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 такова, что в большинстве случаев все зашифрованные файлы могут быть извлечены без знания пароля владельца или агента восстановления.
