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

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

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

Ответы

Ответ 1

Отличное резюме изменений происходит от http://musingmarc.blogspot.com/2010/09/ms10-070-post-mortem-analysis-of-patch.html

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

Ответ 2

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

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

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

Ответ 3

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