Oracle padding exploit - как он загружает web.config?

Я знаю, что на SO есть еще несколько вопросов об использовании эксплойта оракула, но ни один из них не объясняет, как он загружает web.config. Я запускаю несколько приложений ASP.NET, которые я уже тестировал с помощью рекомендованных Microsoft смягчающих факторов, но я все еще боюсь, что люди смогут получить web.config.

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

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

Ответ 1

Ребята - ответ заключается в том, что как только они получили machineKey, они могут использовать этот ключ для извлечения файлов с использованием другой функции в ASP.NET

"В ASP.NET 3.5 с пакетом обновления 1 (SP1) и ASP.NET 4.0 есть функция, которая используется для обслуживания файлов из приложения. Эта функция обычно защищена машинным ключом. Однако, если машинный ключ взломан, эта функция скомпрометирована. Это напрямую связано с ASP.NET, а не с IIS, поэтому параметры безопасности IIS не применяются. Как только эта функция скомпрометирована, злоумышленник может загружать файлы из вашего приложения, включая файл web.config, который часто содержит пароли.

Версии ASP.NET до ASP.NET 3.5 с пакетом обновления 1 (SP1) не имеют этой функции, но все еще уязвимы для основной атаки машинного ключа.

(см. сообщение внизу: http://forums.asp.net/t/1603799.aspx от команды asp.net)

Ответ 2

Скотт Гатри имеет сообщение, которое объясняет это в некоторой степени.

Ответ 4

afaik это выглядит следующим образом:

  • они попадают: webresource.axd и scriptresource.axd, оба используют зашифрованное/подписанное значение, которое asp.net пытается проверить, действительно ли его действительный
  • из-за различий в ответе, когда файлы являются или недействительными, они могут выполнять атаку дополнения.
  • После успешной атаки они могут генерировать запрос для ресурсов, как если бы они были изначально выпущены из asp.net

Теперь, насколько я знаю, оба из них должны обслуживать встроенные ресурсы, но я думаю, что это не так (Скотт Гу упомянул в своих комментариях, что те, которые используются в атаке, показали).