Comments 32
>При помощи этой уязвимости злоумышленник может запрашивать и загружать с сервера файлы входящие в приложение ASP.NET такие как web.config
Уязвимость web.config только для версий ASP.NET выше 3.5SP1, где есть магическая фича обходящая защиту IIS чтоб выдавать любые файлы по запросу.
Уязвимость web.config только для версий ASP.NET выше 3.5SP1, где есть магическая фича обходящая защиту IIS чтоб выдавать любые файлы по запросу.
ого, это что за фича?
In ASP.NET 3.5 Service Pack 1 and ASP.NET 4.0 there is a feature that is used to serve files from the application. This feature is normally protected by the machine key. However, if the machine key is compromised then this feature is compromised. This goes directly to ASP.NET and not IIS so IIS's security settings do not apply. Once this feature is compromised then the attacker can download files from your application — including web.config file, which often contains passwords.
Versions of ASP.NET prior to ASP.NET 3.5 SP1 do not have this feature, but are still vulnerable to the main machine key attack.
forums.asp.net/t/1603799.aspx
Подробнее к сожалению не сказано
Versions of ASP.NET prior to ASP.NET 3.5 SP1 do not have this feature, but are still vulnerable to the main machine key attack.
forums.asp.net/t/1603799.aspx
Подробнее к сожалению не сказано
Есть хорошее видео, демонстрирующее уязвимость www.youtube.com/watch?v=yghiC_U2RaM
Вот и подтвердилось о чем я писал в habrahabr.ru/blogs/infosecurity/104157/
Похоже, часть проблемы описывалось в новости Питера Фогеля, которую я переводил — habrahabr.ru/blogs/net/104258/
Ниодно из предложеных решений не решает гарантированно проблему. Гарантированное решение, это сделать так чтобы авторизационная кука енкриптилась другим ключем.
Почему не решает? Каким другим ключем?
Насколько я понимаю все что тут написано, если вы определите кастомную страницу которая показывается при ошибке — злоумышленник теряет возможность с помощью стандартной страницы различать коды ошибок и соответственно не сможет получить private key asp.net приложения.
Насколько я понимаю все что тут написано, если вы определите кастомную страницу которая показывается при ошибке — злоумышленник теряет возможность с помощью стандартной страницы различать коды ошибок и соответственно не сможет получить private key asp.net приложения.
Есть косвенные улики. Например время которое тратится на неправильную куку отличается от вермени на правильную куку но с левыми данными. Почитайте — www.gdssecurity.com/l/b/2010/09/14/automated-padding-oracle-attacks-with-padbuster/
Вообще то это «временное решение» на всех серьезных сайтах и так должно быть включено — иначе при ошибке все будут получать желтенькую страницу ASP.NET, что не очень красиво.
Там временное решение заключается не в редиректе на другую страницу. А в рандомной задержке. Она позволяет запутать атку при помощи Padding Oracle. Я вам выше дал ссылку почитайте.
Даже с временной задержкой нет гарантии решения проблемы?
Мне кажется, использовать решение, предложенное в статье (выделенная страница для сообщения об ошибке), крайне желательно в любом случае. Даже если бы никакой уязвимости не было.
1. Пользователю абсолютно ничего не говорят сообщения об ошибках, которые он увидит.
2. Мало того, у него появляется ощущение, что сайт ненадежный. Общая фраза «На сайте произошел сбой, дайте нам немного времени, чтобы мы могли его устранить» создает впечатление хоть какого-то контроля над ситуацией.
3. Злоумышленник может получить полезную информацию о внутренностях вашего сайта, чтобы использовать ее для других методов взлома. Я периодически наталкиваюсь на сайты, которые выводят дампы SQL запроса в случае сбоя — выглядит «несколько непрофессионально», как вежливо говорит один наш заказчик :)
Как вариант, можно поставить обработчик Application_Error и гарантированно логировать там все необработанные ошибки + перенаправлять на страницу «Сбой на сайте». Только нужно учитывать, что для ASP.NET 404 ошибка — это то же исключение. Такие ошибки нужно выделять и перебрасывать на другую страницу, которая вернет 404 код (для поисковых серверов), но будет содержать нормальный html код «Страница не найдена» для посетителей.
1. Пользователю абсолютно ничего не говорят сообщения об ошибках, которые он увидит.
2. Мало того, у него появляется ощущение, что сайт ненадежный. Общая фраза «На сайте произошел сбой, дайте нам немного времени, чтобы мы могли его устранить» создает впечатление хоть какого-то контроля над ситуацией.
3. Злоумышленник может получить полезную информацию о внутренностях вашего сайта, чтобы использовать ее для других методов взлома. Я периодически наталкиваюсь на сайты, которые выводят дампы SQL запроса в случае сбоя — выглядит «несколько непрофессионально», как вежливо говорит один наш заказчик :)
Как вариант, можно поставить обработчик Application_Error и гарантированно логировать там все необработанные ошибки + перенаправлять на страницу «Сбой на сайте». Только нужно учитывать, что для ASP.NET 404 ошибка — это то же исключение. Такие ошибки нужно выделять и перебрасывать на другую страницу, которая вернет 404 код (для поисковых серверов), но будет содержать нормальный html код «Страница не найдена» для посетителей.
Мда… Если бы речь шла о php, то тут бы забурлило, конечно.
Как я понял из слайдов доклада, была продемонстрирована уязвимость к некой модификации атаки Воденэ, описаной еще в 2002 году и которая очень широко известна. И если это действительно так, то мне непонятно почему в Microsoft 8 лет(!) игнорировали существование этой атаки, а опомнились только когда петух клюнул в одно место.
Атака Padding Oracle была известна давно. Небыло експолита. Вот появился.
И все равно мне непонятно почему сразу нельзя было реализовать временную задержку при ответе на криптованный запрос(пусть даже включающуюся опционально). Неужели понадеялись что и так сойдет, никто не заметит.
Я не думаю что в 2002м кто-то свзяывал эту атаку именно с этим експолитом. Ведь атака сама по себе достаточно распространненная. Тот же SQL/XML Injection активно использует разницу в таймингах. Я например видел атаки на файловую систему, когда оличали ошибку отсувия доступа и отсутвия самого пути. Короче. Везде рандомные тайминги не поставиш.
ИМХО проблема не в возможности при помощи Padding Oracle облегчить брутфорс машинного ключа, а то что все юзают один и тот же ключ. Если бы ASP.NET не енкрптил и вьюстейт и куку одинм ключем, то проблем было бы меньше. Вот подумайте, зачем енкриптить вьюстейт? А зачем енкриптить названия ресурсов?
ИМХО проблема не в возможности при помощи Padding Oracle облегчить брутфорс машинного ключа, а то что все юзают один и тот же ключ. Если бы ASP.NET не енкрптил и вьюстейт и куку одинм ключем, то проблем было бы меньше. Вот подумайте, зачем енкриптить вьюстейт? А зачем енкриптить названия ресурсов?
Где-то видел предложение вместо AES использовать алгоритм 3DES. То ли он не подвержен такой атаке, то ли атака не на него направлена. Поскольку изменить AES на 3DES слегка проще, чем делать кастомную ошибку с рандомной задержкой, мне интересно, действительно ли это вылечит, не подскажете?
Не поможет, какой бы вы блочный алгоритм шифрования не выбрали, т.к. все они используют дополнение данных до размера блока, а именно это и позволяет реализовать атаку.
Ок, понял, спасибо. Просто в посте деталей атаки нет, и как работает в данном случае оракул не ясно.
Если очень схемотично то все происходит примерно так. Во-первых уязвимы не сами криптосистемы AES или DES, а режим шифрования CBC.
Во-воторых сама атака: атакующий производит следующие действия:
1. Получает криптованный текст С.
2. Генеритует случайный набор бит равный по размеру блоку данных R.
3. Отправляет единным блоком серверу пару R||C.
4. Сервер получив данное сообщение пытается его расшифровать. И вот тут, собственно уязвимое место. Видители сервер во время дешифровки должен произвести, в силу специфики CBC, следующие действия D(С) xor R. Получившуюся белеберду(напомню, что R-совершенно случайный набор бит сгенерированный атакующим) сервер проверяет на предмет правильности заполнения и возвращает атакующему ответ в виде «заполнение правильно/направильно».
5. Вероятность того что заполнение окажется верным составляет 1/256. Т.е. отправив всего 256 запросов атакующий вполне вероятно сможет получить верно заполненное сообщение.
6. Это даст ему возможность расшифровать последний байт криптованного блока.
7. И так расшифровывая байт за батом можно взломать весь криптотекст.
Ну это в общих чертах. Надеюсь принцип вы поняли. Т.е. тут уж вы как не пытайтесь но смена криптоалгоритма не поможет. Нужно именно устранять возможность для атакующено узнавать правильно ли заполненым вышло сообщение D(С) xor R или нет.
Во-воторых сама атака: атакующий производит следующие действия:
1. Получает криптованный текст С.
2. Генеритует случайный набор бит равный по размеру блоку данных R.
3. Отправляет единным блоком серверу пару R||C.
4. Сервер получив данное сообщение пытается его расшифровать. И вот тут, собственно уязвимое место. Видители сервер во время дешифровки должен произвести, в силу специфики CBC, следующие действия D(С) xor R. Получившуюся белеберду(напомню, что R-совершенно случайный набор бит сгенерированный атакующим) сервер проверяет на предмет правильности заполнения и возвращает атакующему ответ в виде «заполнение правильно/направильно».
5. Вероятность того что заполнение окажется верным составляет 1/256. Т.е. отправив всего 256 запросов атакующий вполне вероятно сможет получить верно заполненное сообщение.
6. Это даст ему возможность расшифровать последний байт криптованного блока.
7. И так расшифровывая байт за батом можно взломать весь криптотекст.
Ну это в общих чертах. Надеюсь принцип вы поняли. Т.е. тут уж вы как не пытайтесь но смена криптоалгоритма не поможет. Нужно именно устранять возможность для атакующено узнавать правильно ли заполненым вышло сообщение D(С) xor R или нет.
Дело в том, что этой атаке вообще без разницы, какой алгоритм шифрования применяется. Поэтому не поможет.
Спасибо за перевод! Рекомендую всем .NET разработчикам фолловить автора @scottgu в твиттере — очень много интересного.
Sign up to leave a comment.
Важно: Уязвимость безопасности ASP.NET