Comments 31
Решение: использовать надежный пароль и не выставлять наружу сервис для отладки.
Достаточно не отлаживать ничего на проде. Напомню, что удаленный отладчик — это часть Visual Studio, и по умолчанию на серверах его нет!
ASP.NET Web Forms – новая эволюция технологии ASP, при которой происходит переход на компоненто–ориентированную модель построения приложений.
новая
2002-ой год
Заканчивающаяся 2010-ым годом статистика CVE тоже как-то не блещет актуальностью
Про Partial View написано что-то совсем непонятное. Каким образом хакер собрался добавлять туда уязвимый код, и почему считается что это сделать проще чем добавить код в основной View? Если что, эти файлы лежат в соседних папочках.
И да, приведенный пример — @Model
— это ничуть не RCE, потому что содержимое Model просто выводится в выходной поток, а не исполняется. Более того, так даже XSS не получить, потому что строки при выводе всегда экранируются...
Конечно, невнятное, вьюхи берутся только из мест, возвращённых view locator-ом, а не компиляются из произвольных откуда-то взявшихся строк. Потому и " P.S. Попытка воспроизвести не увенчается успехом. ".
По поводу PartialView и View. В этом вся и проблема. Если бы нагрузку можно было бы прокинуть в PartialView так же легко (причем не забывать, что ещё и пре-процессинг включиться, который надо обойти) — это уже было бы CVE с High уровнем. А так, этот вектор так же из реальной жизни взят, но упрощён для понимания, что не только эксплоитами возможно выполнить удаленный код. Спасибо за вопрос.
Что именно вы называете нагрузкой?
Куда ее легче прокинуть — во View или PartialView? И почему?
Какой именно пре-процессинг мешает выполнению нагрузки?
Почему RCE имеет уровень отличный от High?
2) Рассмотрим пример. Мы кладём модель во вьюху (ViewModel), полученную от контроллера, далее мы выполняем какие то действия и у нас отрисовывается PartialView, вероятность того, что туда уйдет компилируемый user-input очень мала. Поэтому во View — это просто не будет работать. А через Partial-View должен пройти input.
3) Здесь имеется ввиду штатные механизмы ASP, не дадут пробросить какую Вам захочется нагрузку. И будет ругаться фильтр.
4) Не все RCE обязательно уровнем High. Если мы вспомним CVSS 3. Там есть параметр «Сложность атаки (AC)», что заметно уменьшает оценку уязвимости.
5) И ещё от себя — это не гайд и не мануал, как взломать АСП, это описание некоторых проблем, которые могут возникнуть. Поэтому в статье нет и не предполагается точных алгоритмов развития атаки. Спасибо.
Если приходит с пользовательским вводом, то как она может выполниться? Насколько я знаю, у Razor нет никакого аналога eval.
Если второе — то откуда она там взялась?
А вот почему так происходит, это уже поле для исследований. Нагрузка попадает не в razor, а в Server-Side и вариантов может быть масса. Надеюсь, теперь вам стало понятно. Спасибо.
Про вывод @Model — в статье какой-то бред. Какой калькулятор, какая нагрузка? Это просто вывод строки, только зачем-то очень косвенный.
То же самое, что написать @ViewBag.Html в основной вьюшке. Пример из статьи просто выводит строку
@((Account.Models.User)Session[“User”].Password
в html. Как строку, не выполняя ее как код.
Возможность получить от пользователя строку и вывести ее на экран — это уязвимость? :)
Что происходит на видео, и почему там выводит admin — загадка. Было бы неплохо увидеть реальную демострацию уязвимости, а не видео + скромное "Попытка воспроизвести не увенчается успехом".
Может быть там просто во вьюшке admin написано. Или даже @((Account.Models.User)Session[“User”].Password. А разработчик после замены на @Model забыл Save нажать.
Если на серверной строне написать код для вывода содержимого — будет выведено содержимое модели, как строка. Если на серверной строне написать код для вывода свойства из View Bag — будет выведено значение свойства из View Bag.
Вы можете вывести результат выполнения @((2 + 2).ToString()) если вы — разработчик и вы прямо вписали этот код в страницу Razor, а не спустили в виде модели. Тогда этот код выполнится и отрендерит на страницу строку «4». И это не уязвимость.
В примере из поста — вы, как атакующий передаете на сервер строку "@((2 + 2).ToString())" и получаете в выходном html строку "@((2 + 2).ToString())". Что строка "@((2 + 2).ToString())", что «qqq» — без разницы, она выводится как статический контент, а не выполняется как код. И это тоже не уязвимость.
При этом на видео, якобы, возникает ситуация, когда атакующий передает на сервер строку "@((2 + 2).ToString())", и получает на странице результат выполнения ее как кода на C#, «4». И это было бы уязвимостью, если бы такая ситуация реально возникала. Но она не возникает. Ни при прямом выводе @model, ни при косвенном, через PartialView.
По сути, уязвимость на видео — или фейк, или ошибка того, кто видео записал — несохраненный файл, например. Я могу точно такое же видео записать, просто забыв нажать Ctrl+S один раз :) Но это не означает, что уязвимость есть.
Вы автор видео из статьи? Вы можете привести минимальный пример для воспроизведения уязвимости? Если вы не можете привести пример, и не можете даже теоретически обосновать механизм — указать, в каком именно месте и на каком шаге строка будет выполнена как код — то как вы можете утверждать, что уязвимость вообще имеет место?
Алгоритм:
Пользователь делает запрос в контроллер;
Контроллер отрисовывает View;
Внутри View встречается Partial View, после чего снова происходит запрос на контроллер, который отвечает за отрисовку частичного представления;
Готовый Partial View возвращается в основной, а основной – пользователю.
Не воспринимайте эту статью как мануал по зеродеям в ASP. Любой из предложенных пунктов можно обыграть, что ничего работать не будет или будет. Я говорю о том, можно ли хакнуть ASP, а не как это сделать. И основная мысль, это, что системы ломаются всегда, но намного чаще, их можно сломать через ошибки в человеческой логике.
И обратите внимание на название статьи «Можно ли «хакнуть» ASP инфраструктуру?» а не Можно ли «хакнуть» ASP.NET?
Я и не воспринимают эту статью как мануал по зеродеям. Пока я воспринимаю этот кусок статьи как "разработчику показалось".
Вот что реально происходит:
- Пользователь делает запрос в контроллер, отдает строку "@..."
- Контроллер отрисовывает View, спускает ему строку "@..."
- Внутри View встречается Partial View, после чего снова происходит запрос на контроллер, который отвечает за отрисовку частичного представления. В качестве параметра контроллеру отдается строка "@..."
- Partial View отрисовывает строку "@..."
- Готовый Partial View возвращается в основной. Основной отрисовывает результат рендера Partial — строку "@...".
- Пользователь видит на экране строку "@...".
При этом в видео видно, что пользователь получает на экране не строку "@...", а "admin". В какой момент, по вашему мнению, строка вида "@..." выполняется и превращается в "admin"?
Я же не предлагаю обсудить "обыгрывание пунктов" или "ошибки в человеческой логике". Вы(?) в статье заявили, что имеет место вот такой-то эффект. Я утверждаю, что такого эффекта нет, код не выполняется, и узявимости (не узявимости в asp.net, а узявимости в конкретном приведенном вами коде) нет.
Ответ, которого я бы ожидал для подтверждения существования уязвимости (в примере из статьи, не в asp.net) — это код, который можно было бы скопировать и запустить. Который делал бы то, что видно на видео — хоть как-то выполнял переданный пользователем код. А не мутного "невоспроизводимого" видео видео без исходников. У вас есть такой пример? Или только домыслы?
m.Headers.Add(“To", email);
Где вы вообще такое задание адресата видели? у MailMessage
есть специальное поле To
, которым все и пользуются. Собственно, вы УЖЕ выше передали нормальный адрес в конструкторе, а теперь зачем-то руками лезете в заголовки.
Что же до "XSS фильтр ByPass" — то Razor сам по себе является куда более сильной защитой от XSS чем любые фильтры основанные на поиске подозрительных общих подстрок запроса и ответа...
Еще есть путаница в понятиях «устаревшие технологии» и «уязвимые технологии». Все найденные уязвимости в .NET платформе исправляются сразу во всех фреймворках и если вы используете ASP .NET WebForms к вам это исправление прилетит с обновлениями Windows (автоматически, главное не отключить вручную). Т.е. использовать WebForms ничем не хуже ASP .NET Core c точки зрения безопасности платформы. Исключение составляют конфигурации по умолчанию, они часто исправляются в новых версиях фреймворка, чтобы поддерживать обратную совместимость (пример, XML парсеры уязвимые к XXE в дефолтных конфигурациях до FW 4.5).
Если вам интересна тема именно .NET Security, то я бы порекомендовал потратить время на чтение “Application Security in .NET Succinctly ” by Stan Drapkin и просмотр докладов по безопасности с DotNext и PDUG (VladimirKochetkov делал много хороших и там и там).
Описание: данная технология дает возможность создавать HTML-страницы со вставками на языке Jscript (очень похож на JavaScript, но помимо клиентских скриптов имеет ряд возможностей по работе с операционной системой Windows и серверными вставками на ASP)
Вы забыли упомянуть VBScript, который является в классическом ASP языком по умолчанию. По собственному опыту могу сказать, что большинство проектов на классическом ASP используют VBScript (за всю свою карьеру я работал лишь в одной компании, где использовался JScript).
Также стоит отметить, что в классическом ASP можно использовать и другие скриптовые языки (например, PerlScript), если установить соответствующие интерпретаторы.
Можно ли «хакнуть» ASP инфраструктуру?