Насколько серьезной является эта новая уязвимость безопасности ASP.NET и как ее можно обойти?

Ответ 1

Что мне делать, чтобы защитить себя?

[Обновить 2010-09-29]

Бюллетень по безопасности Microsoft

KB Article со ссылкой на исправление

ScottGu содержит ссылки для скачивания

[Обновить 2010-09-25]

Пока мы ждем исправления, вчера ScottGu опубликовать обновление о том, как добавить дополнительный шаг для защиты ваших сайтов с помощью настраиваемого Правило URLScan.

<ч/" > В основном убедитесь, что вы предоставили настраиваемую страницу ошибок, чтобы злоумышленник не подвергался внутренним ошибкам .Net, которые вы всегда должны в любом случае в режиме выпуска/производства.

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

В web.config

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

Это приведет к перенаправлению любой ошибки на пользовательскую страницу, возвращенную с кодом состояния 200. Таким образом, злоумышленник не может просматривать код ошибки или информацию об ошибках для информации, необходимой для дальнейших атак.

Также безопасно установить customErrors mode="RemoteOnly", поскольку это перенаправит "настоящих" клиентов. Только просмотр с localhost будет показывать внутренние ошибки .Net.

Важная часть состоит в том, чтобы убедиться, что все ошибки настроены на возврат той же страницы ошибок. Для этого требуется явно указать атрибут defaultRedirect в разделе <customErrors> и убедиться, что не установлены коды для каждого состояния.

Что поставлено на карту?

Если злоумышленнику удастся использовать указанный эксплойт, он может загружать внутренние файлы из вашего веб-приложения. Обычно web.config является целевой и может содержать конфиденциальную информацию, такую ​​как информация для входа в строку подключения к базе данных, или даже ссылку на автоматизированную базу данных sql-express, которую вы не хотите, чтобы кто-то завладел. Но если вы следуете лучшей практике, вы используете Protected Configuration для шифрования всех конфиденциальных данных в вашем web.config.

Ссылки на ссылки

Ознакомьтесь с официальными комментариями Microsoft об уязвимости в http://www.microsoft.com/technet/security/advisory/2416728.mspx. В частности, часть "Обходное решение" для реализации детализирует эту проблему.

Также есть информация о в блоге ScottGu, включая script, чтобы найти уязвимые приложения ASP.Net на вашем веб-сервере.

Для объяснения в разделе "Understanding Padding Oracle Attacks" прочитайте @sri answer.

Комментарии к статье:

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

Если заполнение недействительно, сообщение об ошибке, которое получает отправитель, даст ему некоторую информацию о том, как работает процесс расшифровки сайта.

Для того, чтобы атака работала, должно быть выполнено следующее:

• В вашем приложении должно быть указано сообщение об ошибке.
• Кто-то должен вмешиваться в ваши зашифрованные файлы cookie или viewstate.

Итак, если вы возвращаете сообщения, читаемые человеком, в вашем приложении, например: "Что-то пошло не так, попробуйте еще раз", тогда вы должны быть в безопасности. Чтение немного комментариев к статье также дает ценную информацию.

• Сохранять идентификатор сеанса в зашифрованном файле cookie
• Сохранение реальных данных в состоянии сеанса (сохраняется в db)
• Добавить случайное ожидание, когда информация пользователя неверна, прежде чем возвращать ошибку, поэтому вы не можете время

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

Будет интересно посмотреть, что на самом деле представлено на конференции Ekoparty, но сейчас я не слишком беспокоюсь об этой уязвимости.

Ответ 2

Общие сведения о запасах Oracle Attacks

Предположим, что ваше приложение принимает зашифрованную строку в качестве параметра - является ли параметр cookie, параметром url или чем-то еще несущественным. Когда приложение пытается его декодировать, есть 3 возможных результата -

• Результат 1. Зашифрованная строка дешифрована правильно, и приложение смогло разобраться в ней. Значение, если зашифрованная строка была десятизначным номером учетной записи, после дешифрования приложение обнаружило что-то вроде "1234567890", а не "abcd1213ef"

• Результат 2: заполнение было правильным, но после расшифровки полученная строка была тарабарщиной, которую приложение не могло понять. Например, строка расшифровывается до "abcd1213ef", но приложение ожидает только числа. В большинстве приложений появится сообщение типа "Недопустимый номер учетной записи".

• Результат 3: заполнение было неправильным, и приложение бросило какое-то сообщение об ошибке. В большинстве приложений появится общее сообщение типа "Некоторая ошибка".

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

Если эти два условия соблюдены, злоумышленник может в конечном итоге расшифровать сообщение, а затем повторно зашифровать его любым желанием. Это просто вопрос времени.

Что можно сделать, чтобы предотвратить его?

• Простейшая вещь - ничего чувствительного никогда не следует отправлять клиенту, зашифровать или не зашифровать. Храните его на сервере.

• Убедитесь, что результат 2 и результат 3 в приведенном выше списке точно совпадают с атакующим. Не должно быть никакого способа разобраться друг с другом. Однако это не так просто - злоумышленник может различать использование какой-то временной атаки.

• Как последняя линия защиты, у вас есть брандмауэр веб-приложений. Атака прокрутки оракула должна сделать несколько запросов, которые выглядят почти одинаковыми (сменяя один бит за раз), поэтому WAF должен быть способен поймать и заблокировать такие запросы.

P.S. Хорошее объяснение Padding Oracle Attacks можно найти в этом сообщении в блоге. Отказ от ответственности: его НЕ мой блог.

Ответ 3

Из того, что я читал до сих пор...

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

Им нужен зашифрованный файл cookie пользователя, который уже был зарегистрирован в любой учетной записи. Им также нужно найти данные в файлах cookie - я надеюсь, что разработчики не хранят важные данные в файлах cookie:). И есть способ, которым я располагаю ниже, чтобы не допустить данные хранилища asp.net в файле cookie для входа.

Как кто-то может получить файл cookie пользователя, который находится в сети, если он не получает данные браузера? Или обнюхайте IP-пакет?

Один из способов предотвратить использование файлов cookie без ssl-шифрования.

<httpCookies httpOnlyCookies="true" requireSSL="true" />

Также еще одна мера состоит в том, чтобы предотвратить сохранение ролей в файлах cookie.

<roleManager enabled="true" cacheRolesInCookie="false">

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

Справка:
Может ли какой-нибудь хакер украсть файл cookie у пользователя и войти с этим именем на веб-сайт?

Как проверить, откуда приходят атаки, и не возвращать информацию. Я написал здесь простой способ предотвратить заполнение недействительным и протоколирование в то же время для отслеживания злоумышленников: CryptographicException: Заполнение недопустимо и не может быть удалено и не удалось выполнить проверку MAC-адреса viewstate

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

Обновление 1.

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

Если кто-то попытается использовать этот инструмент или этот метод, приведенный выше код может отследить их, и вы можете заблокировать их из своей страницы простым кодом, подобным этому "Предотвратить отказ в обслуживании (DOS)" или как этот код для предотвращения отказа в обслуживании.

Обновление 2

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

очень интересное видео по этой проблеме.

Таким образом, все вышеперечисленное более важно для большей защиты, но не для 100% необходимых для этой конкретной проблемы. Например, для использования ssl cookie является решение проблемы с snif, а не кешировать роли в куки файлах, чтобы не отправлять и получать большие куки файлы, а чтобы избежать того, что все готово к взлому кода, просто установите роль администратора на его печенье.

В режиме просмотра отслеживается его еще одна мера, чтобы найти атаку.

Ответ 4

Здесь - ответ MS. Все это сводится к "использованию специальной страницы ошибок", и вы не будете раздавать какие-либо подсказки.

ИЗМЕНИТЬ
Здесь есть более подробная информация от scottgu.

Ответ 5

Добавление ответов ScottGu, взятых из обсуждения, на http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx

Является ли пользовательский IHttpModule вместо пользовательских ошибок, вызванных ошибкой?

В: У меня нет элемента, объявленного в моем web.config, вместо этого у меня есть модуль IHttpModule. Этот модуль регистрирует ошибку и перенаправляет на страницу поиска (для 404) или на страницу с ошибкой (для 500). Я уязвим?

A: Я бы рекомендовал временно обновлять модуль, чтобы всегда перенаправлять на страницу поиска. Одним из способов этой атаки является поиск дифференциации между 404 и 500 ошибками. Всегда возвращать один и тот же HTTP-код и отправлять их в одно и то же место - это один из способов помочь ему заблокировать его.

Обратите внимание, что, когда исправление исходит, чтобы исправить это, вам не нужно это делать (и может вернуться к старому поведению). Но прямо сейчас я бы рекомендовал не дифференцировать между 404 и 500 для клиентов.

Могу ли я продолжать использовать разные ошибки для ошибок 404 и 500?

Q: Я полагаю, что мы можем по-прежнему иметь настраиваемую 404 страницу, определенную в дополнение к перенаправлению по умолчанию при ошибке, не нарушая принципов, описанных выше?

A: Нет - пока мы не выпустим патч для реального исправления, мы рекомендуем использовать описанное выше решение, которое гомогенизирует все ошибки. Одним из способов этой атаки является поиск дифференциации между 404 и 500 ошибками. Всегда возвращать один и тот же HTTP-код и отправлять их в одно и то же место - это один из способов помочь ему заблокировать его.

Обратите внимание, что, когда исправление исходит, чтобы исправить это, вам не нужно это делать (и может вернуться к старому поведению). Но сейчас вы не должны различать между 404 и 500 для клиентов.

Как это разрешает экспозицию web.config?

Q: Как это разрешает доступ к web.config? Это, похоже, позволяет дешифровать только ViewState, есть ли другая связанная с этим уязвимость, которая также позволяет раскрывать информацию? Есть ли документ, в котором подробно описывается атака, для лучшего объяснения того, что происходит?

A: Атака, которая была показана публике, зависит от функции ASP.NET, которая позволяет загружать файлы (как правило, javascript и css) и защищена ключом, который отправляется как часть запроса. К сожалению, если вы можете создать ключ, вы можете использовать эту функцию для загрузки файла web.config приложения (но не файлов вне приложения). Мы, очевидно, выпустим патч для этого - до тех пор вышеупомянутое обходное решение закрывает вектор атаки.

EDIT: дополнительные FAQ доступны во втором блоге на http://weblogs.asp.net/scottgu/archive/2010/09/20/frequently-asked-questions-about-the-asp-net-security-vulnerability.aspx

Ответ 6

IMO, для этого нет сквозной профилактики, его необходимо обрабатывать в каждом конкретном случае:

http://www.onpreinit.com/2010/09/aspnet-vulnerability-workaround-flawed.html

Ответ 7

Несколько значимых ссылок:

• MS 'Security Advisory 2416728 (это официальная информация)
• Дополнительная информация от MS 'Security Research and Defence team
  • "Понимание уязвимости ASP.NET" (2010-09-17)
  • "Дополнительная информация об уязвимости ASP.NET" (2010-09-20)
• Скотт Гу: "Важно: уязвимость безопасности ASP.NET" (2010-09-18)

[Чтобы ответить на серьезность этого аспекта (то, что было опубликовано, и обходные пути охватываются другими ответами).]

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

Еще более серьезно, если вы хотите, чтобы сеансы могли охватывать продолжительность жизни рабочего процесса или разрешать веб-фермы (т.е. все экземпляры фермы могут обрабатывать любой пользовательский сеанс), ключ должен быть жестко закодирован, это делается в web.config:

[...]
  <system.web>
    <machineKey
        decryption="AES"
        validation="SHA1"
        decryptionKey="57726C59BA73E8A4E95E47F4BC9FB2DD"
        validationKey="158B6D89EE90A814874F1B3129ED00FB8FD34DD3"
      />

Это, конечно, вновь созданные ключи, я использую следующий PowerShell для доступа к генератору криптографических случайных чисел Windows:

$rng = New-Object "System.Security.Cryptography.RNGCryptoServiceProvider"
$bytes = [Array]::CreateInstance([byte], 20)
$rng.GetBytes($bytes)
$bytes | ForEach-Object -begin { $s = "" } -process { $s = $s + ("{0:X2}" -f $_) } -end { $s}

(Использование длины массива 20 для проверки и 16 для ключей дешифрования.)

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

[Edit 2010-09-21: Добавлены ссылки в начало страницы]

Ответ 8

Я только что опубликовал свой полный отчет об этом в своем блоге после дополнительных исследований по этой проблеме. Я думаю, что его важно понять, почему они доходят до куки файла cookie.

Просто хочу получить некоторые факты прямо:

• Атака
• не позволяет напрямую получить машинный ключ. Тем не менее, это в значительной степени похоже на то, что оно имело, поскольку оно позволяет расшифровывать сообщения и изменять повторно/шифровать новые.
• способ получить фактические ключи, используя их способность изменять re/encrypt как в 1 и получить web.config. К сожалению, есть причины, по которым некоторые кладут эти ключи в web.config на уровне сайта (разные обсуждения), а в образце видео они получают выгоду от того, что по умолчанию DotnetNuke.
• чтобы получить web.config, все указывает на то, что они используют webresources.axd и/или scriptresources.axd. Я думал, что они работают только со встроенными ресурсами, но, похоже, это просто не так.
• Если приложение является asp.net MVC, нам действительно не нужны webresources.axd и/или scriptresources.axd, поэтому их можно отключить. Мы также не используем viewstate. Тем не менее, его непонятно для меня, если какая-либо из других функций asp.net предоставляет различную информацию с обходным решением на месте, т.е. я не знаю, добавляет ли заполнение недопустимые результаты при ошибке, дополняя действительные результаты игнорированием аутентификационного билета (не знаю если это или нет)... тот же анализ должен применяться к файлу сеанса.
• роли поставщика кэширования asp.net в файлах cookie, отключите это.

Около 1, afaik зашифрованные сообщения не могут быть на 100% произвольными, должны терпеть крошечный кусок мусора где-то в сообщении, так как в сообщении есть 1 блок, который расшифровывает значение, которое невозможно контролировать.

Наконец, я хотел бы сказать, что эта проблема является результатом того, что ms не выполняет свои собственные указания в этом случае: функция полагается на что-то, отправленное клиенту, в качестве доказательства несанкционированного доступа.

Подробнее:

Я не знаю, добавляет ли заполнение недопустимые результаты при ошибке при заполнении допустимых результатов в игнорированном билете проверки подлинности (не знаю, является ли это его или нет)... тот же анализ должен применяться к файлу cookie сеанса.

Файл cookie auth подписан, и из информации в документе они не должны иметь возможность создавать подписанный файл cookie, если они не попадают в фактические ключи (как это было в видео до подделки файла cookie auth).

Как упоминал Аристос, для идентификатора сеанса в cookie, который является случайным для пользовательского сеанса, поэтому его нужно будет обнюхать от пользователя с целевым уровнем безопасности и взломать, пока этот сеанс активен. Даже тогда, если вы полагаетесь на аутентификацию для назначения/авторизации пользовательских операций, тогда влияние будет минимальным/это будет сильно зависеть от того, в каком сеансе используется в этом приложении.

Ответ 9

Патч для этой ошибки был выпущен в Центре обновления Windows: http://weblogs.asp.net/scottgu/archive/2010/09/30/asp-net-security-fix-now-on-windows-update.aspx

Ответ 10

Asp.Net MVC также подвержен этой проблеме (как и Sharepoint,...)

Я рассмотрел исправление для MVC здесь: Является ли ASP.NET MVC уязвимым для атаки дополнения оракула?