Сообщает Peter Vogel
Два исследователя безопасности, Тай Донг (Thai Duong) и Джулиано Риццо( Juliano Rizzo), обнаружили баг в используемом по умолчанию механизме шифрования, который задействован в защите куки, обычно применяемых для реализации аутентификации формами (Forms Authentication) в ASP.NET. С помощью разработанного исследователями инструмента (Padding Oracle Exploit Tool или POET), можно многократно модифицировать куки, зашифрованные с помощью механизма шифрования AES и, исследуя возвращаемые ошибки, вычислить машинный ключ (Machine Key), используемый для шифрования куки. По утверждениям исследователей, процесс надёжен на 100% и занимает от 30 до 50 минут для любого сайта.
Как только машинный ключ был определён, атакующий может создавать фиктивные аутентификационные куки. И если разработчики сайта выбрали вариант встраивания информации о роли данного пользователя в куки, то атакующий может присвоить себе роль администратора. Эта дыра в безопасности может оказать влияние и на другие функции провайдера членства в ролях, защиту от спуфинга ViewState, других зашифрованных данных, которые могут храниться в куки или каким-то другим образом могут быть доступны на стороне клиента.
Плохая новость в том, что проблема обширна и требует немедленного решения. Хорошая же в том, что решение её достаточно просто. Данный хак эксплуатирует баг в .NET-реализации шифрования с использованием AES. Выход прост – необходимо переключиться на использование другого механизма шифрования – например, 3DES. А поскольку шифрование членства и провайдеров ролей обрабатывается ASP.NET, то никакой модификации существующего кода, использующего аутентификацию формами, не понадобится.
Метод шифрования можно изменить в файле web.config для сайта, в IIS 7 для веб-сервера или в конфигурационном файле .NET на сервере в каталоге %SYSTEMROOT%\Microsoft.NET\Framework\version\CONFIG\. На 64-битных системах так же необходимо изменить конфигурационный файл в каталоге %SYSTEMROOT%\Microsoft.NET\Framework64\version\CONFIG\. Типичная запись будет выглядеть таким образом:
На веб-ферме этот параметр должен быть изменен на всех серверах фермы.
Эти параметры также используются для предотвращения спуфинга ViewState (данные ViewState кодируются, но не шифруются). Поэтому если вы внесёте эти изменения, это также приведёт к шифрованию ViewState с использованием 3DES.
Разработчики, которые используют AES для шифрования информации, доступной на клиенте, должны рассмотреть возможность изменения кода, с целью использования другого механизма шифрования.
Донг и Риццо намерены предоставить более подробную информацию об этой проблеме на конференции по безопасности, которая пройдёт в пятницу, 17 сентября в Буэнос-Айресе.
Два исследователя безопасности, Тай Донг (Thai Duong) и Джулиано Риццо( Juliano Rizzo), обнаружили баг в используемом по умолчанию механизме шифрования, который задействован в защите куки, обычно применяемых для реализации аутентификации формами (Forms Authentication) в ASP.NET. С помощью разработанного исследователями инструмента (Padding Oracle Exploit Tool или POET), можно многократно модифицировать куки, зашифрованные с помощью механизма шифрования AES и, исследуя возвращаемые ошибки, вычислить машинный ключ (Machine Key), используемый для шифрования куки. По утверждениям исследователей, процесс надёжен на 100% и занимает от 30 до 50 минут для любого сайта.
Как только машинный ключ был определён, атакующий может создавать фиктивные аутентификационные куки. И если разработчики сайта выбрали вариант встраивания информации о роли данного пользователя в куки, то атакующий может присвоить себе роль администратора. Эта дыра в безопасности может оказать влияние и на другие функции провайдера членства в ролях, защиту от спуфинга ViewState, других зашифрованных данных, которые могут храниться в куки или каким-то другим образом могут быть доступны на стороне клиента.
Плохая новость в том, что проблема обширна и требует немедленного решения. Хорошая же в том, что решение её достаточно просто. Данный хак эксплуатирует баг в .NET-реализации шифрования с использованием AES. Выход прост – необходимо переключиться на использование другого механизма шифрования – например, 3DES. А поскольку шифрование членства и провайдеров ролей обрабатывается ASP.NET, то никакой модификации существующего кода, использующего аутентификацию формами, не понадобится.
Метод шифрования можно изменить в файле web.config для сайта, в IIS 7 для веб-сервера или в конфигурационном файле .NET на сервере в каталоге %SYSTEMROOT%\Microsoft.NET\Framework\version\CONFIG\. На 64-битных системах так же необходимо изменить конфигурационный файл в каталоге %SYSTEMROOT%\Microsoft.NET\Framework64\version\CONFIG\. Типичная запись будет выглядеть таким образом:
<machineKey validationKey="AutoGenerate,IsolateApps"
validation="3DES"
decryptionKey="AutoGenerate,IsolateApps"
decryption="3DES" /> На веб-ферме этот параметр должен быть изменен на всех серверах фермы.
Эти параметры также используются для предотвращения спуфинга ViewState (данные ViewState кодируются, но не шифруются). Поэтому если вы внесёте эти изменения, это также приведёт к шифрованию ViewState с использованием 3DES.
Разработчики, которые используют AES для шифрования информации, доступной на клиенте, должны рассмотреть возможность изменения кода, с целью использования другого механизма шифрования.
Донг и Риццо намерены предоставить более подробную информацию об этой проблеме на конференции по безопасности, которая пройдёт в пятницу, 17 сентября в Буэнос-Айресе.
