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

Я только что прочитал в сети о недавно обнаруженной уязвимости безопасности в ASP.NET. Вы можете прочитать подробности здесь.

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

Это немного расплывчато, но вот более пугающая часть:

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

В общем, я недостаточно знаком с предметом безопасности / криптографии, чтобы знать, действительно ли это так серьезно.

Итак, должны ли все разработчики ASP.NET бояться этой техники, которая может владеть любым веб-сайтом ASP.NET за считанные секунды или как?

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

Спасибо за ваши ответы!

РЕДАКТИРОВАТЬ: Позвольте мне обобщить ответы, которые я получил

Таким образом, это в основном тип атаки "оракулом-отступником". @Sri предоставил отличное объяснение того, что означает этот тип атаки. Вот шокирующее видео о проблеме!

О серьезности этой уязвимости: Да, это действительно серьезно. Это позволяет злоумышленнику узнать машинный ключ приложения. Таким образом, он может делать некоторые очень нежелательные вещи.

  • При наличии машинного ключа приложения злоумышленник может расшифровать куки-файлы аутентификации.
  • Хуже того, он может генерировать куки аутентификации с именем любого пользователя. Таким образом, он может появиться как любой на сайте. Приложение не может различить вас или хакера, который сгенерировал cookie для аутентификации с вашим именем для себя.
  • Это также позволяет ему расшифровывать (и также генерировать) сеансовые куки, хотя это не так опасно, как предыдущий.
  • Не так серьезно: он может расшифровать зашифрованный ViewState страниц. (Если вы используете ViewState для хранения конфиденциальных данных, вы все равно не должны этого делать!)
  • Совершенно неожиданно: зная ключ компьютера, злоумышленник может загрузить любой произвольный файл из вашего веб-приложения, даже тот, который обычно не может быть загружен! (Включая Web.Config и т. Д.)

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

Теперь давайте сосредоточимся на этом вопросе.

Решение

  • Включите customErrors и создайте одну страницу ошибок, на которую перенаправляются все ошибки. Да, даже 404-х годов. (ScottGu сказал, что для этой атаки важно различать 404 и 500.) Кроме того, в ваш Application_Error или же Error.aspx поставить некоторый код, который делает случайную задержку. (Сгенерируйте случайное число и используйте Thread.Sleep, чтобы спать так долго.) Это не позволит злоумышленнику решить, что именно произошло на вашем сервере.
  • Некоторые люди рекомендовали вернуться к 3DES. Теоретически, если вы не используете AES, вы не столкнетесь со слабостью безопасности в реализации AES. Оказывается, это совсем не рекомендуется.

Некоторые другие мысли

  • Кажется, что не все думают, что обходной путь достаточно хорош.

Спасибо всем, кто ответил на мой вопрос. Я многое узнал не только об этой проблеме, но и о веб-безопасности в целом. Я отметил ответ @ Микаэля как принятый, но другие ответы также очень полезны.

Источник

10 ответов

Решение

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

[Обновление 2010-09-29]

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

Статья КБ со ссылкой на исправление

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, которую вы не хотите, чтобы кто-то заполучил. Но если вы следуете передовой практике, вы используете защищенную конфигурацию для шифрования всех конфиденциальных данных в вашем файле web.config.

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

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

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

Для объяснения "Понимание атак Oracle с отступом" прочитайте ответ @sri.

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

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

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

Чтобы атака работала, должно быть верно следующее:

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

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

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

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

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

Источник

Понимание отступлений от атак Oracle

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

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

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

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

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

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

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

  1. Самое простое - что-либо чувствительное никогда не должно отправляться клиенту, зашифровано или не зашифровано. Держите это на сервере.

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

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

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

Источник

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

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

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

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

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

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

Также еще одной мерой является предотвращение хранения ролей в файлах cookie.

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

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

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

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

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

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

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

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

Обновление 2

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

очень интересное видео по этому вопросу.

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

Отслеживание состояния - это еще одна мера, чтобы найти атаку.

Источник

Вот ответ MS. Все сводится к тому, чтобы "использовать пользовательскую страницу ошибок", и вы не будете выдавать никаких подсказок.

РЕДАКТИРОВАТЬ
Вот более подробная информация от Скотту.

Источник

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

Влияет ли пользовательский IHttpModule вместо customErrors?

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

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

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

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

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

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

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

Как это позволяет подвергать web.config?

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

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

РЕДАКТИРОВАТЬ: дополнительные часто задаваемые вопросы доступны во втором блоге по адресу http://weblogs.asp.net/scottgu/archive/2010/09/20/frequently-asked-questions-about-the-asp-net-security-vulnerability.aspx

Источник

ИМО, для этого нет всеобъемлющей профилактики, ее нужно обрабатывать в каждом конкретном случае:

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

Источник

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

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

Атакуемый ключ используется для защиты как состояния просмотра, так и файлов 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 для ключей дешифрования.)

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

[Редактировать 2010-09-21: Добавлены ссылки наверх]

Источник

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

Источник

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

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

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

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

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

Еще:

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

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

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

Источник

Эта проблема также затрагивает Asp.Net MVC (как и Sharepoint, ...)

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

Источник
Другие вопросы по тегам