Как была исправлена ​​атака с использованием оракула на ASP.NET?

Question

Microsoft выпустила свой внеполосный выпуск, чтобы исправить ошибку безопасности в ASP.NET вчера.

Какие методы использовала Microsoft, чтобы покончить с жизнеспособностью этого вектора?

Answer 1

Великолепное резюме изменений пришло от http://musingmarc.blogspot.com/2010/09/ms10-070-post-mortem-analysis-of-patch.html

• Не пропускайте информацию об исключениях - это предотвращает эксплойты, чтобы увидеть, что сломано.
• Не короткосхема проверки заполнения (отнимите столько же времени для заполнения правильных стихов, если заполнение прервано) - Это не позволит эксплойтам увидеть разницу во времени при неправильном заполнении.
• Не будьте слишком разборчивы в отлове исключений в IHttpHandler.ProcessRequestЭто предотвращает обнаружение эксплойтами того, что вы поймали один тип исключения (CryptographicException) вместо всех исключений.
• Переключение с векторов инициализации на основе хеш-функции на случайные IV - это предотвращает использование эксплойтами отношения между данными и хешемрасшифровать быстрее.
• Разрешить обратную совместимость - в случае, если это что-то нарушает, разрешите частичное возвращение нового поведения.
• При выполнении прохода проверки кода измените его, чтобы сделать его понятнымВы рассмотрели новые варианты.

Answer 2

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

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

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

Answer 3

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