Пользователь
0,0
рейтинг
19 сентября 2010 в 15:05

Разработка → Важно: Уязвимость безопасности ASP.NET перевод

Несколько часов назад мы выпустили рекомендации по безопасности в ASP.NET (Microsoft Security Advisory). Эта уязвимость существует во всех версиях ASP.NET.

Эта уязвимость была публично раскрыта вечером в пятницу на конференции по безопасности. Мы рекомендуем все клиентам использующим ASP.NET немедленно применить временное решение (описанное ниже) для предотвращения атак с ее использованием.

Чем опасна уязвимость?

При помощи этой уязвимости злоумышленник может запрашивать и загружать с сервера файлы входящие в приложение ASP.NET такие как web.config (который часто содержит секретные данные).

Злоумышленник при помощи эксплуатации этой уязвимости может также расшифровать данные посланные клиенту в зашифрованном состоянии (такие как данные ViewState на странице).

Как работает уязвимость

Чтобы понять как работает уязвимость, вы должны иметь представление о криптографических оракулах. Оракул в контексте криптографии это система которая предоставляет подсказки в ответ на вопросы которые вы ей задаете. В данном случае уязвимость которая присутствует в ASP.NET и действует как оракул. Это позволяет атакующему посылать шифрованный текст веб-серверу и выяснять, правильно ли он расшифрован путем исследования кодов ошибок возвращаемых сервером. Выполнив много подобных запросов (и наблюдая какие ошибки возвращаются) злоумышленник может получить достаточно информации для того чтобы расшифровать остальной зашифрованный текст.

Как закрыть уязвимость

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

Важно: Недостаточно просто включить опцию CustomErrors и установить ее атрибут RemoteOnly в значение true. Вам также нужно убедится что все ошибки сконфигурированы возвращать одну и туже страницу. Вам нужно явно установить атрибут «defaultRedirect» секции <customErrors> и убедиться что не установлены постатусные коды.

Временное решение на ASP.NET с V1.0 по V3.5

Если вы используете ASP.NET 1.0, ASP.NET 1.1, ASP.NET 2.0 или ASP.NET 3.5 тогда вы должны выполнить следующие шаги для включения и адресации всех ошибок на одну и туже страницу ошибки:

1) Отредактируйте файл Web.Config в корневом каталоге вашего приложения ASP.NET. Если файл не существует, создайте его в корневом каталоге приложения.

2) Создайте или отредактируйте в файле web.config секцию чтобы ее установки были такими как указано ниже:

<configuration>
  <system.web>
     <customErrors mode="On" defaultRedirect="~/error.html" />
  </system.web>
</configuration>


* This source code was highlighted with Source Code Highlighter.


3) Затем вы можете добавить в ваше приложение файл error.html который содержит страницу ошибки соответствующего внешнего вида. Этот файл будет отображаться каждый раз когда происходит ошибка в веб-приложении.

Замечания: Вот, что нужно отметить в примере приведенном выше, что customErrors установлено в значение «on», а все ошибки обрабатываются страницей ошибок указанной в атрибуте «defaultRedirect». Что также не определено постатусных страниц ошибок — это можно проверить убедившись в отсутствии элементов <error> внутри секции <code><customErrors></code>. Выполнение этих условий не позволит злоумышленнику различать ошибки когда они происходят на сервере и предотвратит раскрытие информации.

Временное решение на ASP.NET V3.5 SP1 и ASP.NET 4.0

Если вы используете ASP.NET 3.5 SP1 или ASP.NET 4.0 тогда тогда вам нужно выполнить шаги указанные ниже, чтобы включить опцию <customErrors> и адресовать все ошибки на одну страницу ошибки:

1) Отредактируйте файл Web.Config вашего приложения ASP.NET. Если его не существует, создайте его в корневом каталоге приложения.

2) Создайте или измените секцию <customErrors> файла web.config file так, чтобы в итоге у вас было следующее содержимое. Обратите внимание на использование redirectMode=«ResponseRewrite» в .NET 3.5 SP1 и .NET 4.0:

<configuration>
  <system.web>
     <customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="~/error.aspx" />
  </system.web>
</configuration>


* This source code was highlighted with Source Code Highlighter.


3) Вы можете вы можете добавить в ваше приложение Error.aspx который содержит страницу ошибки соответствующего внешнего вида. Этот файл будет отображаться каждый раз когда происходит ошибка в веб-приложении.

4) Мы рекомендуем добавить следующий код в обработчик северного события Page_Load() в файле Error.aspx, чтобы добавить небольшую случайную маленькую задержку. Это поможет в дальнейшей обфускации ошибок.

Версия для VB

Ниже представлена версия файла Error.aspx для VB, которую вы можете использовать и которая имеет небольшую случайную задержку. Вам не нужно компилировать этот код в приложении, опционально вы можете просто сохранить файл Error.aspx в директории приложения на веб-сервере:

<%@ Page Language="VB" AutoEventWireup="true" %>
<%@ Import Namespace="System.Security.Cryptography" %>
<%@ Import Namespace="System.Threading" %>

<script runat="server">
    Sub Page_Load()
        Dim delay As Byte() = New Byte(0) {}
        Dim prng As RandomNumberGenerator = New RNGCryptoServiceProvider()
        
        prng.GetBytes(delay)
        Thread.Sleep(CType(delay(0), Integer))
        
        Dim disposable As IDisposable = TryCast(prng, IDisposable)
        If Not disposable Is Nothing Then
            disposable.Dispose()
        End If
    End Sub
</script>

<html>
<head runat="server">
    <title>Error</title>
</head>
<body>
    <div>
        Sorry - an error occured
    </div>
</body>
</html>


* This source code was highlighted with Source Code Highlighter.


Версия для C#

Ниже приведена версия файла Error.aspx для C# которую вы можете использовать и которая имеет небольшую случайную задержку. Вам не нужно компилировать этот код в приложении, опционально вы можете просто сохранить файл Error.aspx в директории приложения на веб-сервере:

<%@ Page Language="C#" AutoEventWireup="true" %>
<%@ Import Namespace="System.Security.Cryptography" %>
<%@ Import Namespace="System.Threading" %>

<script runat="server">
  void Page_Load() {
     byte[] delay = new byte[1];
     RandomNumberGenerator prng = new RNGCryptoServiceProvider();

     prng.GetBytes(delay);
     Thread.Sleep((int)delay[0]);
        
     IDisposable disposable = prng as IDisposable;
     if (disposable != null) { disposable.Dispose(); }
    }
</script>

<html>
<head runat="server">
    <title>Error</title>
</head>
<body>
    <div>
        An error occurred while processing your request.
    </div>
</body>
</html>


* This source code was highlighted with Source Code Highlighter.


Как проверить, что временное решение работает

После того как вы применили указанное выше временное решение вы можете проверить что секция <customErrors> корректно сконфигурирован запросив URL подобный этому с вашего сайта: mysite.com/pagethatdoesnotexist.aspx

If you see the custom error page appear (because the file you requested doesn’t exist) then your configuration should be setup correctly. If you see a standard ASP.NET error then it is likely that you missed one of the steps above. To see more information about what might be the cause of the problem, you can try setting <customErrors mode=”remoteOnly”/> – which will enable you to see the error message if you are connecting to the site from a local browser.

Как найти уязвимые приложения ASP.NET на сервевре

Мы опубликовали сценарий .vbs, который вы можете сохранить и запустить на вашем веб-сервере чтобы определить есть ли установленные приложения ASP.NET у которых отключена секция или которые различают сообщения об ошибке по коду статуса.

Вы можете загрузить сценарий .vbs отсюда. Просто скопируйте/вставьте сценарий в текстовый файл с именем «DetectCustomErrors.vbs» и сохраните его на диск. Затем откройте окно с командной строкой которое выполняется с правами администратора и выполните «cscript DetectCustomErrors.vbs», чтобы выполнить этот сценарий на локальном веб-сервере. Он просмотрит все приложения на веб-сервере и проверит указана ли корректная конфигурация <customErrors>.

image

Сценарий отметит каждое приложение, у которого будет найдено, что файл web.config не имеет секции <customErrors> (в таком случае вам нужно добавить ее) или она не настроена правильно, чтобы предлагать временное решение для выключения уязвимости (в таком случае вам нужно обновить ее). Сценарий будет выводить «ok» для файла web.config каждого приложения который будет определен как правильно настроенный. Надеемся, что это облегчить поиск источников ошибок.

Замечание: Мы разработали этот определяющий сценарий в течении нескольких последних часов и будем улучшать его дальше в будущем. Я буду обновлять этот раздел каждый раз, когда мы будем вносить в него изменения.

Как найти больше информации об этой уязвимости

Вы можете узнать больше об этой уязвимости из следующих источников:



Форум для вопросов

Мы настроили отдельный форум на сайте www.asp.net, для того чтобы помочь ответить на вопросы об этой уязвимости.

Публикуйте вопросы здесь, чтобы их задать и получить помощь по уязвимости.

Выводы

Мы будем публиковать больше деталей как будем узнавать больше, и также выпустим заплатку которую можно будет использовать для исправления самой причины проблемы (и больше не использовать указанное выше временное решение).

До этого момента, пожалуйста применяйте временное решение указанное выше ко всем вашим приложениям ASP.NET, чтобы избежать эксплуатации уязвимости злоумышленниками.

Спасибо,

Скотт
Перевод: Scott Guthrie
Павел Крупин @Easter
карма
15,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (32)

  • 0
    >При помощи этой уязвимости злоумышленник может запрашивать и загружать с сервера файлы входящие в приложение ASP.NET такие как web.config

    Уязвимость web.config только для версий ASP.NET выше 3.5SP1, где есть магическая фича обходящая защиту IIS чтоб выдавать любые файлы по запросу.
    • 0
      ого, это что за фича?
      • 0
        In ASP.NET 3.5 Service Pack 1 and ASP.NET 4.0 there is a feature that is used to serve files from the application. This feature is normally protected by the machine key. However, if the machine key is compromised then this feature is compromised. This goes directly to ASP.NET and not IIS so IIS's security settings do not apply. Once this feature is compromised then the attacker can download files from your application — including web.config file, which often contains passwords.

        Versions of ASP.NET prior to ASP.NET 3.5 SP1 do not have this feature, but are still vulnerable to the main machine key attack.

        forums.asp.net/t/1603799.aspx

        Подробнее к сожалению не сказано
  • +12
    Есть хорошее видео, демонстрирующее уязвимость www.youtube.com/watch?v=yghiC_U2RaM
  • +3
    Вот и подтвердилось о чем я писал в habrahabr.ru/blogs/infosecurity/104157/
    • +4
      Тогда всерьез это никто не воспринял…
  • 0
    Похоже, часть проблемы описывалось в новости Питера Фогеля, которую я переводил — habrahabr.ru/blogs/net/104258/
    • +1
      Да, и это та же новость, на которую я приводил ссылку чуть ранее
  • +1
    Ниодно из предложеных решений не решает гарантированно проблему. Гарантированное решение, это сделать так чтобы авторизационная кука енкриптилась другим ключем.
    • 0
      Почему не решает? Каким другим ключем?

      Насколько я понимаю все что тут написано, если вы определите кастомную страницу которая показывается при ошибке — злоумышленник теряет возможность с помощью стандартной страницы различать коды ошибок и соответственно не сможет получить private key asp.net приложения.
      • +1
        Есть косвенные улики. Например время которое тратится на неправильную куку отличается от вермени на правильную куку но с левыми данными. Почитайте — www.gdssecurity.com/l/b/2010/09/14/automated-padding-oracle-attacks-with-padbuster/
        • 0
          Интересно. Решение — добавить в Error.aspx рандомную паузу :) С рандомом тоже нужно быть осторожным…
          • 0
            Только не говорите что еще потребление электричества в датацентре будет отличаться в зависимости от куки…
          • 0
            Там собсно крутой рандом. По идее его должно временно хватить ;). Я еще прелдагал в глобальном зенделере ловить обе шибки и делать так чтобы они занимали одинаковое время ;).
  • 0
    Вообще то это «временное решение» на всех серьезных сайтах и так должно быть включено — иначе при ошибке все будут получать желтенькую страницу ASP.NET, что не очень красиво.
    • 0
      Там временное решение заключается не в редиректе на другую страницу. А в рандомной задержке. Она позволяет запутать атку при помощи Padding Oracle. Я вам выше дал ссылку почитайте.
      • 0
        Даже с временной задержкой нет гарантии решения проблемы?
        • +1
          Рандомная задержка защищает от проявления Padding Oracle в том как ASP.NET обрабатывает ошибки. Вполне возможно что существуют другие пути оверюза. Ведь машинным ключем кроме авторизационной куки еще много чего енкриптится: названия ембдед скриптов, вьюстейт, реквест валидация.
  • +1
    Мне кажется, использовать решение, предложенное в статье (выделенная страница для сообщения об ошибке), крайне желательно в любом случае. Даже если бы никакой уязвимости не было.

    1. Пользователю абсолютно ничего не говорят сообщения об ошибках, которые он увидит.

    2. Мало того, у него появляется ощущение, что сайт ненадежный. Общая фраза «На сайте произошел сбой, дайте нам немного времени, чтобы мы могли его устранить» создает впечатление хоть какого-то контроля над ситуацией.

    3. Злоумышленник может получить полезную информацию о внутренностях вашего сайта, чтобы использовать ее для других методов взлома. Я периодически наталкиваюсь на сайты, которые выводят дампы SQL запроса в случае сбоя — выглядит «несколько непрофессионально», как вежливо говорит один наш заказчик :)

    Как вариант, можно поставить обработчик Application_Error и гарантированно логировать там все необработанные ошибки + перенаправлять на страницу «Сбой на сайте». Только нужно учитывать, что для ASP.NET 404 ошибка — это то же исключение. Такие ошибки нужно выделять и перебрасывать на другую страницу, которая вернет 404 код (для поисковых серверов), но будет содержать нормальный html код «Страница не найдена» для посетителей.
  • +5
    Мда… Если бы речь шла о php, то тут бы забурлило, конечно.
  • +1
    Как я понял из слайдов доклада, была продемонстрирована уязвимость к некой модификации атаки Воденэ, описаной еще в 2002 году и которая очень широко известна. И если это действительно так, то мне непонятно почему в Microsoft 8 лет(!) игнорировали существование этой атаки, а опомнились только когда петух клюнул в одно место.
    • 0
      Атака Padding Oracle была известна давно. Небыло експолита. Вот появился.
      • 0
        И все равно мне непонятно почему сразу нельзя было реализовать временную задержку при ответе на криптованный запрос(пусть даже включающуюся опционально). Неужели понадеялись что и так сойдет, никто не заметит.
        • +2
          Я не думаю что в 2002м кто-то свзяывал эту атаку именно с этим експолитом. Ведь атака сама по себе достаточно распространненная. Тот же SQL/XML Injection активно использует разницу в таймингах. Я например видел атаки на файловую систему, когда оличали ошибку отсувия доступа и отсутвия самого пути. Короче. Везде рандомные тайминги не поставиш.

          ИМХО проблема не в возможности при помощи Padding Oracle облегчить брутфорс машинного ключа, а то что все юзают один и тот же ключ. Если бы ASP.NET не енкрптил и вьюстейт и куку одинм ключем, то проблем было бы меньше. Вот подумайте, зачем енкриптить вьюстейт? А зачем енкриптить названия ресурсов?
          • 0
            Согласен. Пермудрили конечно. Хотели как лучше, а получилось то что получилось.
  • –1
    Где-то видел предложение вместо AES использовать алгоритм 3DES. То ли он не подвержен такой атаке, то ли атака не на него направлена. Поскольку изменить AES на 3DES слегка проще, чем делать кастомную ошибку с рандомной задержкой, мне интересно, действительно ли это вылечит, не подскажете?
    • 0
      Не поможет, какой бы вы блочный алгоритм шифрования не выбрали, т.к. все они используют дополнение данных до размера блока, а именно это и позволяет реализовать атаку.
      • 0
        Ок, понял, спасибо. Просто в посте деталей атаки нет, и как работает в данном случае оракул не ясно.
        • +2
          Если очень схемотично то все происходит примерно так. Во-первых уязвимы не сами криптосистемы AES или DES, а режим шифрования CBC.
          Во-воторых сама атака: атакующий производит следующие действия:
          1. Получает криптованный текст С.
          2. Генеритует случайный набор бит равный по размеру блоку данных R.
          3. Отправляет единным блоком серверу пару R||C.
          4. Сервер получив данное сообщение пытается его расшифровать. И вот тут, собственно уязвимое место. Видители сервер во время дешифровки должен произвести, в силу специфики CBC, следующие действия D(С) xor R. Получившуюся белеберду(напомню, что R-совершенно случайный набор бит сгенерированный атакующим) сервер проверяет на предмет правильности заполнения и возвращает атакующему ответ в виде «заполнение правильно/направильно».
          5. Вероятность того что заполнение окажется верным составляет 1/256. Т.е. отправив всего 256 запросов атакующий вполне вероятно сможет получить верно заполненное сообщение.
          6. Это даст ему возможность расшифровать последний байт криптованного блока.
          7. И так расшифровывая байт за батом можно взломать весь криптотекст.

          Ну это в общих чертах. Надеюсь принцип вы поняли. Т.е. тут уж вы как не пытайтесь но смена криптоалгоритма не поможет. Нужно именно устранять возможность для атакующено узнавать правильно ли заполненым вышло сообщение D(С) xor R или нет.
          • 0
            Спасибо, теперь хоть понял в чём именно проблема, и какой конкретный смысл в защите от всего этого. Но всё-таки для разнообразия надо будет глянуть возможность подмены шифрования, возможно в своей реализации там можно будет сменить режим.
    • 0
      Дело в том, что этой атаке вообще без разницы, какой алгоритм шифрования применяется. Поэтому не поможет.
  • 0
    Спасибо за перевод! Рекомендую всем .NET разработчикам фолловить автора @scottgu в твиттере — очень много интересного.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.