Старые недоработки в MS Office на новый лад

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

Рассмотрим обобщенный процесс верификации пароля в MS Office,  который был придуман еще в ранних версиях Office и принципиально не поменялся до сих пор.

Схема проверки пароля в MS Office

Схема проверки пароля в MS Office

  • Шаг 1. Из пароля и случайной привязки (salt) через одно- или многократное хэширование получается строка бит.
  • Шаг 2. Из этой строки берется ровно столько бит, сколько нужно для генерации ключа (в разных версиях от 40 до 256).
  • Шаг 3. Еще одна случайная строка (Verifier) длиной 128 бит зашифровывается на полученном ключе и результат EncryptedVerifier сохраняется в файле Office.
  • Шаг 4. Тот же самый Verifier однократно хэшируется.
  • Шаг 5. Результат хеширования зашифровается на полученном на шаге 2 ключе и сохраняется в файле как EncryptedVerifierHash.

Тогда, по замыслу разработчиков, для проверки пароля надо было сгенерировать ключ, расшифровать EncryptedVerifier, найдя исходный Verifier, получить его хэш, зашифровать по шагу 5 и сравнить полученный результат с EncryptedVerifierHash. Когда алгоритмом хэширования в Office XP был MD5, а шифрования - RC4, все работало именно так. Но в Office 2007 разработчики заменили MD5 на SHA1, а RC4 на AES.

Казалось бы, все стало только лучше - SHA1 явно более стойкий, чем MD5, а AES - современный стандарт шифрования. Но,

  1. MD5 генерировал хэш длиной 128 бит, а SHA1 - 160. AES же работает блоками по 128 бит.
  2. RC4 был потоковый шифр, а AES - блочный.

Первое привело к тому, что VerifierHash на шаге 5 перестал быть кратен длине блока AES, поэтому для его зашифрования пришлось использовать два 128-битных блока. Лишние 96 бит, недолго думая, заполнили нулями. А это уже разрушило всю преполагаемую схему аутентификации. Действительно, теперь шаг 5 можно пройти в обратном порядке, расшифровав EncryptedVerifierHash, и если мы получим в результате последние 96 бит нулей, то пароль верный! Больше нет необходимости делать шаги 3 и 4!

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

Да, это нельзя назвать серьезной уязвимостью, и на скорость подбора пароля Office это тоже не влияет, так как основной по трудоемкости является шаг 2, где выполняется 50.000 (Office 2007) или 100.000 (Office 2010) преобразований SHA1. Интересно то, что в модификации Office 2010 разработчики предложили несколько новых улучшений, но описанную проблему проигнорировали. Забавно также, что похожая проблема была в старой версии MS Office 97, когда процесс верификации пароля в MS Word удалось убыстрить примерно с помощью такого же трюка (не нужно было выполнять несколько шагов, предложенных Microsoft). Именно поэтому восстановление паролей Word 97 происходит быстрее, чем Excel 97.

Нет комментариев

Еще нет комментариев.

RSS лента комментариев к этой записи.

Оставить комментарий

You must be logged in to post a comment.

WordPress Themes