Проблема с безопасностью при использовании аутентификации формами в ASP.NET

    Сообщает 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\. Типичная запись будет выглядеть таким образом:

    <machineKey validationKey="AutoGenerate,IsolateApps"
    validation="3DES"
    decryptionKey="AutoGenerate,IsolateApps"
    decryption="3DES" />


    На веб-ферме этот параметр должен быть изменен на всех серверах фермы.

    Эти параметры также используются для предотвращения спуфинга ViewState (данные ViewState кодируются, но не шифруются). Поэтому если вы внесёте эти изменения, это также приведёт к шифрованию ViewState с использованием 3DES.

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

    Донг и Риццо намерены предоставить более подробную информацию об этой проблеме на конференции по безопасности, которая пройдёт в пятницу, 17 сентября в Буэнос-Айресе.
    • +15
    • 1.6k
    • 7
    Share post

    Similar posts

    Comments 7

      +2
      Во всех проектах стараюсь хранить в куках только идентификатор сессии, а все данные, относящиеся к сессии — в хранилище на сервере.
        +2
        А собственно кто-то читал статью по ссылке? Там вообще то описан метод расшифровки и шифрования данных, не имея ключа, а ориентируясь исключительно по ответам сервера. Каким образом из этого можно получить ключ — для меня неясно.
        Кроме того для расшифровки/шифрования одного блока нужно выполнить 128*(размер блока) запросов к серверу. Это первое.
        Второе: метод не зависит от выбранного алгоритма шифрования. Зато зависит от режима шифрования (потому что все используют CBC и надеются таким образом обеспечить не только шифрование но и подлинность данных). Если бы использовали CBC совместно с MAC подписью — таких проблем не было бы.
        Учитывая, что и AES и 3DES — блочные шифры, нет разницы, какой из них использовать. .NET всё равно будет использовать режим шифрования CBC для подтверждения подлинности кук.

        В общем, проблема действительно есть, но не та, которая описана в статье.
          +1
          Я так и не понял, эти «Два исследователя безопасности» взломали Advanced Encryption Standard (AES)? За 50 минут??? Что за бред? :-)
            +1
            Сломали некорректную реализацию CBC. Всего-то.
              +1
              Точнее, даже не реализацию, а некорректное использование. Да ещё и с сигнализацией ошибки паддинга (согласно PKCS#5). Т.е. если ваш сервер будет прямо говорить, что в зашифрованных данных ошибка паддинга — то да, его взломают.
            +3
            Вообще-то заголовок немного не соответствует действительности.

            Прочитайте оригинальную презентацию: netifera.com/research/poet/PaddingOracleBHEU10.pdf

            чуваки нашли уязвимость в использовании блочного шифра + CBC (тут 3DES не поможет, он тоже блочный, а Peter Vogel — фантастический идиот).

            в их презентации есть примеры не только для ASP.NET, но и для RoR и JSF, так что ребята сеят панику прямо ковровым бомбометанием.

            Но, оказывается, что для успешной атаки им надо знать, произошла ли ошибка из-за неверного паддинга(!), или по другой внутренней причине (например такой user id не существует или ip не тот).
            Но вы же, как все здравомылящие люди, не оставляете в продакшене вывод ошибок в бразер, не так ли?
              0
              Теперь понятно, спасибо за ссылку на оригинальную презентацию.

              Вообще-то идея сообщать о том, что паддинг неверный зря пришла в голову разработчикам, в любом случае. Это как в ответ на попытку расшифровать данные говорить о том, что столько-то бит ключа из 128 (например) неверные :-)

            Only users with full accounts can post comments. Log in, please.