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

Question

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

Решение

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

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

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

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

Answer 1

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

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

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

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

ScottGu содержит ссылки для загрузки

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

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

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

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

In web.config

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

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

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

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

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

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

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

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

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

Для объяснения "Понимание атак Oracle" читайте @ sri's answer .

---

Комментарии кarticle:

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

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

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

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

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

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

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

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

Answer 2

Общие сведения об атаках Oracle с отступами

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

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

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

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

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

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

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

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

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

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

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

Answer 3

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

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

Им нужен зашифрованный 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% необходимости для этой конкретной проблемы. Например, использование ssl cookie - это решение проблемы со снифом, а не кэширование ролей в cookie - это хорошо, если вы не отправляете и не возвращаете большие куки, а также избегаете того, чтобы все взломали код, просто поместив роль администратора на печенье его.

Состояние отслеживания - это всего лишь еще одна мера для обнаружения атаки.

Answer 4

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

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

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

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

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

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

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

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

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

Как это позволяет использовать web.config?

В: Как это позволяет раскрыть 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

Answer 5

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

EDIT
Здесь - более подробная информация от scottgu.

Answer 6

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

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

Answer 7

Несколько важных ссылок:

• MS 'Советы по безопасности 2416728 (это официальная информация)
• Дополнительная информация от MS' Security Research & Defenseteam
  • «Понимание уязвимости 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: Добавлены ссылки вверх]

Answer 8

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

Answer 9

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

---

Подробнее о:

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

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

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

Answer 10

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

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