Pull to refresh

Comments 31

Решение: использовать надежный пароль и не выставлять наружу сервис для отладки.

Достаточно не отлаживать ничего на проде. Напомню, что удаленный отладчик — это часть Visual Studio, и по умолчанию на серверах его нет!

ASP.NET Web Forms – новая эволюция технологии ASP, при которой происходит переход на компоненто–ориентированную модель построения приложений.
новая
2002-ой год

Заканчивающаяся 2010-ым годом статистика CVE тоже как-то не блещет актуальностью

Спасибо за уточнение. Здесь логический я имел ввиду новое по сравнению с предыдущим.
тоже не поняла, зачем автор так глубоко закопался в прошлое. выходит, статья частично неактуальна и частично нерелевантна. заходя в статью про варианты хаков технологии, как-то не ожидаешь увидеть историческую сводку по развитию от царя гороха.
В целом Вы Правы. Но ASP это не PHP. Многие вещи, написанные на нем живут годы, а некоторые и десятилетия. Например в моей карьере разработчика я часто встречался с ASP.NET WebForms, когда во всю уже был MVC, а сейчас активно занимает позиции Core. Но и Web Forms живет до сих пор.

Про Partial View написано что-то совсем непонятное. Каким образом хакер собрался добавлять туда уязвимый код, и почему считается что это сделать проще чем добавить код в основной View? Если что, эти файлы лежат в соседних папочках.


И да, приведенный пример — @Model — это ничуть не RCE, потому что содержимое Model просто выводится в выходной поток, а не исполняется. Более того, так даже XSS не получить, потому что строки при выводе всегда экранируются...

Конечно, невнятное, вьюхи берутся только из мест, возвращённых view locator-ом, а не компиляются из произвольных откуда-то взявшихся строк. Потому и " P.S. Попытка воспроизвести не увенчается успехом. ".

Начну с обратного… Разумеется вывод @Model — это опять же просто игровой сценарий, но нельзя вывести содержимое свойства любого объекта просто на клиентской стороне. Так или иначе должен быть Server-Side. Поэтому, вместо этой нагрузки, можно было бы и тот же калькулятор запускать.
По поводу PartialView и View. В этом вся и проблема. Если бы нагрузку можно было бы прокинуть в PartialView так же легко (причем не забывать, что ещё и пре-процессинг включиться, который надо обойти) — это уже было бы CVE с High уровнем. А так, этот вектор так же из реальной жизни взят, но упрощён для понимания, что не только эксплоитами возможно выполнить удаленный код. Спасибо за вопрос.
Я вас не понимаю.

Что именно вы называете нагрузкой?
Куда ее легче прокинуть — во View или PartialView? И почему?
Какой именно пре-процессинг мешает выполнению нагрузки?
Почему RCE имеет уровень отличный от High?
Нагрузка (Payload) — Это тот сценарий (код), который мы хотим выполнить в контексте RCE.
2) Рассмотрим пример. Мы кладём модель во вьюху (ViewModel), полученную от контроллера, далее мы выполняем какие то действия и у нас отрисовывается PartialView, вероятность того, что туда уйдет компилируемый user-input очень мала. Поэтому во View — это просто не будет работать. А через Partial-View должен пройти input.
3) Здесь имеется ввиду штатные механизмы ASP, не дадут пробросить какую Вам захочется нагрузку. И будет ругаться фильтр.
4) Не все RCE обязательно уровнем High. Если мы вспомним CVSS 3. Там есть параметр «Сложность атаки (AC)», что заметно уменьшает оценку уязвимости.
5) И ещё от себя — это не гайд и не мануал, как взломать АСП, это описание некоторых проблем, которые могут возникнуть. Поэтому в статье нет и не предполагается точных алгоритмов развития атаки. Спасибо.
Откуда берется нагрузка? Она приходит с пользовательским вводом или уже лежит в cshtml-файле?

Если приходит с пользовательским вводом, то как она может выполниться? Насколько я знаю, у Razor нет никакого аналога eval.

Если второе — то откуда она там взялась?
Нагрузка передается от View -> в PartialView. Во View как и обычно.
А вот почему так происходит, это уже поле для исследований. Нагрузка попадает не в razor, а в Server-Side и вариантов может быть масса. Надеюсь, теперь вам стало понятно. Спасибо.
Нет, мне ничего не ясно. Что такое Server-Side и почему Razor ему противопоставляется?

Каким образом Razor исполняет нагрузку? Насколько я знаю, из коробки у него нет никаких аналогов eval.

Про вывод @Model — в статье какой-то бред. Какой калькулятор, какая нагрузка? Это просто вывод строки, только зачем-то очень косвенный.


То же самое, что написать @ViewBag.Html в основной вьюшке. Пример из статьи просто выводит строку


@((Account.Models.User)Session[“User”].Password 

в html. Как строку, не выполняя ее как код.


Возможность получить от пользователя строку и вывести ее на экран — это уязвимость? :)


Что происходит на видео, и почему там выводит admin — загадка. Было бы неплохо увидеть реальную демострацию уязвимости, а не видео + скромное "Попытка воспроизвести не увенчается успехом".


Может быть там просто во вьюшке admin написано. Или даже @((Account.Models.User)Session[“User”].Password. А разработчик после замены на @Model забыл Save нажать.

Очень странный комментарий. Какая разница что сделать на серверной стороне? Вывести содержимое модели или вывести содержимое ViewBag? Я могу вывести @((2 + 2).ToString()).
В каком смысле «какая разница что сделать на серверной стороне?».

Если на серверной строне написать код для вывода содержимого — будет выведено содержимое модели, как строка. Если на серверной строне написать код для вывода свойства из 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 попадали в контроллер(а точнее в Action), который собирал Partial View и возвращал назад, это хорошо видно из картинки. Обратите внимание на алгоритм:
Алгоритм:

Пользователь делает запрос в контроллер;
Контроллер отрисовывает View;
Внутри View встречается Partial View, после чего снова происходит запрос на контроллер, который отвечает за отрисовку частичного представления;
Готовый Partial View возвращается в основной, а основной – пользователю.


Не воспринимайте эту статью как мануал по зеродеям в ASP. Любой из предложенных пунктов можно обыграть, что ничего работать не будет или будет. Я говорю о том, можно ли хакнуть ASP, а не как это сделать. И основная мысль, это, что системы ломаются всегда, но намного чаще, их можно сломать через ошибки в человеческой логике.

И обратите внимание на название статьи «Можно ли «хакнуть» ASP инфраструктуру?» а не Можно ли «хакнуть» ASP.NET?
А по самому кейсу. Разметку Razor ренедрили специально и отдавали во вьюху. Делали это чуваки для кастомизации стилей, но получился такой кейс.

А, ну это многое объясняет. Если написать на сервере код, который выполняет user input как код на C# — то, внезапно, user input можно будет выполнить как код на C#. Так и стоило бы написать прямо в статье, а упоминания Partial — выбросить как не имеющие отношения к уязвимости.

Я и не воспринимают эту статью как мануал по зеродеям. Пока я воспринимаю этот кусок статьи как "разработчику показалось".


Вот что реально происходит:


  1. Пользователь делает запрос в контроллер, отдает строку "@..."
  2. Контроллер отрисовывает View, спускает ему строку "@..."
  3. Внутри View встречается Partial View, после чего снова происходит запрос на контроллер, который отвечает за отрисовку частичного представления. В качестве параметра контроллеру отдается строка "@..."
  4. Partial View отрисовывает строку "@..."
  5. Готовый Partial View возвращается в основной. Основной отрисовывает результат рендера Partial — строку "@...".
  6. Пользователь видит на экране строку "@...".

При этом в видео видно, что пользователь получает на экране не строку "@...", а "admin". В какой момент, по вашему мнению, строка вида "@..." выполняется и превращается в "admin"?


Я же не предлагаю обсудить "обыгрывание пунктов" или "ошибки в человеческой логике". Вы(?) в статье заявили, что имеет место вот такой-то эффект. Я утверждаю, что такого эффекта нет, код не выполняется, и узявимости (не узявимости в asp.net, а узявимости в конкретном приведенном вами коде) нет.


Ответ, которого я бы ожидал для подтверждения существования уязвимости (в примере из статьи, не в asp.net) — это код, который можно было бы скопировать и запустить. Который делал бы то, что видно на видео — хоть как-то выполнял переданный пользователем код. А не мутного "невоспроизводимого" видео видео без исходников. У вас есть такой пример? Или только домыслы?

Так причем тут ASP.Net? Эта уязвимость из разряда «сам себе яму выкапал», а уже чем, лопатой или экскаватором неважно.
А причем тут ASP.NET?! Я не говорил о том, как взломать ASP.NET, я говорил о том, какие могут быть (и были) проблемы с использованием ASP.NET. Основная мысль, развеять миф, что если снаружи выглядит достаточно секьюрно и безопасно, всегда найдется слабое место. И если рассматривать статью с этой позиции, то все становится ясно и понятно. Я не собирался писать мануалы по взлому, с которыми можно идти в интернет и крушить проекты. С конкретными ресёрчами я бы пришел не на хабру а hackerone. Поэтому я не вижу претензий публики на тему: «А если сделать идеально, то уязвимости — нет» — разумеется это так. Это не security мануал по безопасной разработке, это выборка интересных, на мой взгляд, кейсов, встречающихся на практике и упрощенных для понимания, которые до бесконечности можно обыгрывать. Я согласен, что и XXE и SMTP Header Injection и т.д., это целые вектора уязвимостей разных технологий, а не только ASP. В том числе по OWASP'у.
m.Headers.Add(“To", email);

Где вы вообще такое задание адресата видели? у MailMessage есть специальное поле To, которым все и пользуются. Собственно, вы УЖЕ выше передали нормальный адрес в конструкторе, а теперь зачем-то руками лезете в заголовки.

Разумеется, Вы правы. Это сценарий притянутый «за уши» — как можно манипулировать SMTP заголовками в контексте приложения — это не проблема Майкрософта или бага в продукте ASP — это ошибка разработчиков и логики (кейс взят из реальной жизни).

Что же до "XSS фильтр ByPass" — то Razor сам по себе является куда более сильной защитой от XSS чем любые фильтры основанные на поиске подозрительных общих подстрок запроса и ответа...

Простите за прямоту, но большей дичи про .NET Security я еще не читал, начиная от школолольной терминологии («хакнуть ASP инфраструктуру», «с точки зрения взлома», я вообще думал безопасники в Рамблере оперируют понятиями модели угроз), упоминания Active Server Pages (это как в статье про JavaScript рассказывать про Java), простигосподи сравнение с PHP тут каким-то боком вылезло, какой-то безнадежно устаревшей и неполной(!) статистики CVE в платформе. И с этого мы резко перескакиваем к SMTP Header Injection, CSS Injection, XXE в docx, Redis, SMB Hijacking, которые к .NET имеют ровно столько же отношения, что и к другой платформе.

Еще есть путаница в понятиях «устаревшие технологии» и «уязвимые технологии». Все найденные уязвимости в .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 делал много хороших и там и там).
Небольшая поправка: все-таки у WebForms есть «родовая» уязвимость которой нет в WebPages (Razor) — отсутствие экранирования у Literal по умолчанию.
Да, и если правильно помню Label, Checkbox, RadioButton и подобное тоже не санитизируют отображаемые значения. Об этом приходится помнить, но формально это не уязвимость, а особенность реализации:) Исправление этого может сломать существующие проекты после автообновления, поэтому это поведение не меняют, так же как и дефолтные значения/дефолтное поведение других классов.
Спасибо за ссылку на Application Security in .NET Succinctly!
Описание: данная технология дает возможность создавать HTML-страницы со вставками на языке Jscript (очень похож на JavaScript, но помимо клиентских скриптов имеет ряд возможностей по работе с операционной системой Windows и серверными вставками на ASP)

Вы забыли упомянуть VBScript, который является в классическом ASP языком по умолчанию. По собственному опыту могу сказать, что большинство проектов на классическом ASP используют VBScript (за всю свою карьеру я работал лишь в одной компании, где использовался JScript).

Также стоит отметить, что в классическом ASP можно использовать и другие скриптовые языки (например, PerlScript), если установить соответствующие интерпретаторы.
Sign up to leave a comment.