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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Вы можете зашифровать конфиденциальные данные с помощью защищенной конфигурации
• Использовать только куки HTTP
• Предотвратить DoS-атаки

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

• Скотт Гатри опубликовал запись об этом в своем блоге
• Сообщение в блоге ScottGu об уязвимости
• Обновление ScottGu об уязвимости
• У Microsoft есть совет по безопасности об этом
• Понимание уязвимости
• Дополнительная информация об уязвимости

Решение

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

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

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

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

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

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

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

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

ScottGu имеет ссылки для скачивания

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

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

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

В 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-файл пользователя, который уже вошел в систему на любом аккаунте. Им также необходимо найти данные в файлах cookie - я надеюсь, что разработчики не хранят важные данные в файлах cookie :). И есть способ, который у меня есть ниже, чтобы не позволить asp.net хранить данные в файле cookie для входа.

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

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

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

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

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

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

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

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

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

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

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

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

Обновление 2

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

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

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

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

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

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

Добавление ответов 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

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

• MS 'Security Advisory 2416728 (это официальная информация)
• Дополнительная информация от команды MS 'Security Research & Defense
  • «Понимание уязвимости 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 для ключей дешифрования.)

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

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

Я только что опубликовал свое полное мнение об этом в своем блоге , после дополнительного исследования по этой проблеме. Я думаю, что важно выяснить, почему они зашли так далеко, как подделка аутентичного 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 в этом приложении.

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

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

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