Эксплуатируем систему регистрации и мониторинга исключений ELMAH

Одним из инструментов, применяемых для поиска и исправления ошибок в программах, являются отладчики и трассировщики — специальные утилиты, выполняющие программу по шагам, чтобы понять, что вообще происходит. Сегодня речь пойдет о взломе ELMAH — популярного средства для трассировки ASP.NET-приложений.

Другие статьи в выпуске:

Хакер #159. Подделка контрольной суммы и ЭЦП с помощью коллизий

• Содержание выпуска
• Подписка на «Хакер»-60%

Немного об отладчиках

Использование отладчика – это гарантия того, что ошибка будет как минимум обнаружена и, если повезет, исправлена. Но, к сожалению, существует множество ситуаций, когда программист не может прибегнуть к помощи этого мощного средства. Во-первых, не все ошибки можно отладить. Классический пример – тупиковые ситуации (deadlock) в многопоточном приложении: запускаешь приложение в отладчике – все работает, без него – программа «падает». Во-вторых, отладчик не всегда доступен. Например, тебе никто не разрешит устанавливать средства разработки на сервере высоконагруженного web-приложения. Или другой пример: я уверен на 99%, что ты не найдешь отладчик на компьютере бухгалтера Мариванны, которая использует твою «складскую» программу. Тут встает резонный вопрос: а что делать-то? Ответ нашли еще на заре появления компьютерной техники: трассировка – это получение информационных сообщений во время выполнения программы: какие были исключения, что ввел пользователь, чем программа занимается в данный момент и так далее. Средства трассировки приложений – это очень мощные, но в то же время и потенциально опасные инструменты, ведь они могут предоставить много полезной информации для хакеров. Такие «ошибки» особенно широко распространены в корпоративном софте, который пишется для внутренних нужд компаний. Программисты в корпорациях стараются сделать жизнь службы поддержки (да, собственно, и свою) как можно проще, поэтому чаще всего доступ к различным системным сообщениям и трассировке неограничен. Зачем усложнять систему, когда доступ извне защищают бравые парни из службы безопасности? А об инсайдерах, как обычно, забыли, хотя, если верить статистике, 80% успешных взломов корпоративных систем производится именно ими.

Что такое ELMAH?

ELMAH (расшифровывается как Error Logging Modules and Handlers) – это продукт с открытым исходным кодом, разработанный Атифом Азизом (Atif Aziz). Данная система облегчает задачу регистрации и мониторинга необработанных исключений в приложениях, разработанных на ASP.NET. Несмотря на свою молодость (ELMAH 1.1 был зарегистрирован в репозитории NuGet 11 января 2011 года), проект очень популярен в среде разработчиков сайтов под .NET. На момент написания статьи он находился на четырнадцатой строчке среди пакетов, доступных в NuGet, а библиотеку скачали 45 583 человека.

Секрет популярности ELMAH кроется в его простоте. Интеграция с любым web-приложением происходит при помощи всего нескольких щелчков мышки: добавляешь библиотеку в проект при помощи NuGet и готово! Кроме того, если ты захочешь использовать ELMAH с уже существующим кодом, то тебе не потребуется заново его компилировать! Просто скопируй необходимые сборки в проект и подправь Web.config. Все заработает на ура. Несмотря на простоту использования, ELMAH обладает богатым функционалом: здесь присутствует возможность сохранения информации об ошибках в различные базы данных, существуют сервисы уведомления разработчиков по электронной почте или через RSS и так далее.

Теперь давай перейдем от слов к делу. В качестве примера я решил использовать учебное web-приложение ASP.NET MVC Music Store, которое ты сможешь найти на нашем диске. Также оно доступно в интернете на сайте CodePlex, но уже без интеграции с ELMAH, так что в этом случае я рекомендую обратиться к официальному сайту проекта для получения дополнительной информации. Ты можешь запускать данное web-приложение непосредственно из Visual Studio или зарегистрировать его в IIS. Я буду использовать второй вариант и создам новое приложение, доступное по адресу http://localhost/MusicStore.

Немного теории

Для начала давай посмотрим, что же интересного можно найти в отчете об обычном исключении в ELMAH. Открой Music Store и войди в магазин как администратор, воспользовавшись ссылкой Admin в правом верхнем углу страницы. Имя пользователя и пароль по умолчанию admin и p@ssw0rd соответственно. Теперь давай сгенерируем какое-нибудь исключение. Наш сайт основан на ASP.NET MVC, так что проще всего запросить несуществующую страницу, так как ошибка 404, конечно же, сгенерирует исключение. Получилось? Отлично. Теперь можно посмотреть, какую же информацию мы сможем вытянуть. Для этого открывай web-интерфейс ELMAH, который доступен по адресу http://localhost/MusicStore/elmah.axd. Как видишь, последняя исключительная ситуация, зарегистрированная ELMAH, это ошибка 404, которую мы сами только что воспроизвели. Дальше давай посмотрим, что же именно записал ELMAH. Нажми на ссылку Details и внимательно посмотри на логи. Во-первых, ELMAH сохраняет как можно больше информации об исключении: его тип, сообщение об ошибке и стек вызовов. Что все это может дать злоумышленнику? Многое. Очень часто сообщение об ошибке содержит не предназначенную для посторонних глаз системную информацию, например информацию о соединении с базой данных (включая имя пользователя и пароль), информацию о состоянии объекта, в котором произошла ошибка, и многое другое. Если ошибка произошла в коде интернет-магазина, то там могут оказаться и данные кредитной карты пользователя! На мой взгляд, стек вызовов не может принести столько вреда, сколько текст сообщения об ошибке, но я не думаю, что ты захочешь раскрывать злоумышленнику какую-либо информацию об устройстве твоего приложения. Также стоит отметить, что сообщения об ошибках в логах ELMAH никак не связаны с параметром customErrors в ASP.NET, который используется для сокрытия чувствительной информации от пользователя web-приложения. Ты можешь скрыть от пользователя информацию о необработанном исключении, установив customError в режим on (включен), но это не поможет тебе скрыть эту информацию от ELMAH, в журнале ты найдешь полное описание ошибки.

Идем дальше. ELMAH не ограничивается регистрацией исключения. Он также записывает информацию и о запросе, повлекшем за собой некорректную работу сайта, сохраняя, например, такие серверные переменные, как HTTP_COOKIE, HTTP_HOST, HTTP_USER_AGENT и тому подобные. Наибольший интерес для нас представляют серверные переменные HTTP_COOKIE и AUTH_USER. Переменная AUTH_USER содержит имя пользователя, который выполнил запрос. В твоем случае значение этой переменной будет равно admin. Переменная HTTP_COOKIE содержит куки пользователя. Если он был авторизован на сайте, то в переменной должно быть значение куки .ASPXAUTH. Этот кукис используется для проверки подлинности запроса от определенного пользователя. Таким образом, если пользователь находится на сайте, ты можешь создать похожие куки в своем браузере и угнать сессию данного пользователя. Кроме того, я рекомендую обратить внимание на кукис с именем ASP.NET_SessionId. В нем хранится идентификатор сессии атакуемого пользователя. Его стоит похитить на случай, если в сессии приложения хранится что-нибудь важное. Теперь у тебя есть достаточно информации для проведения атаки на пользователя системы. Она довольно проста: ты должен найти активную сессию авторизованного пользователя и скопировать куки .ASPXAUTH и ASP.NET_SessionId в свой браузер.

Угоняем сессии пользователей

План действий понятен. Переходим к его непосредственной реализации. Первым делом открой лог ELMAH и посмотри информацию о последних исключениях. Есть шанс, что среди них обнаружится информация об активной в данный момент сессии. В этом случае ты можешь смело переходить к следующему шагу. Если тебе не повезло, то остаются два возможных варианта действий. Во-первых, ELMAH распространяет информацию об ошибках через RSS. Добавь канал http://localhost/MusicStore/elmah.axd/rss в читалку RSS и спокойно жди, пока появится возможность для угона сессии :). Нет времени ждать? Тогда тебе на помощь придет социальная инженерия. Предположим, что ты решил взломать какое-нибудь внутрикорпоративное приложение (именно там чаще всего можно встретить незащищенный ELMAH). Попробуй отправить в службу поддержки следующее сообщение: «Здравствуйте. Сегодня у меня перестало открываться приложение Music Store, постоянно выводится ошибка 404. Пример ссылки, которую я пытаюсь открыть: http://localhost/MusicStore/Store/Browse>aspx". Особенность ссылки в том, что страница сгенерирует ошибку 400 «Плохой запрос», которая будет записана в журнал ошибок ELMAH. Теперь осталось ждать, пока сотрудник службы поддержки перейдет по ссылке. Скорее всего, он уже авторизован на сайте, поэтому ты сможешь угнать его сессию. Наша операция переходит в активную фазу. Открывай web-страницу ELMAH и ищи информацию о куках сотрудника службы поддержки. Скорее всего у тебя в руках окажется что-то аналогичное:

ASP.NET_SessionId=3dljmclkhjpat52quopccijj;
.ASPXAUTH=CDB45013DD38AD7D2759BA6FAA7D98F07
...
B84C6CB5BCC76E7AE899690CC2016B5F1BCE9CDCBAA

Осталось создать подобные куки в твоем браузере. Для этой цели я использую браузер Firefox с плагинами Firebug и Firecookie. Кукис ASP.NET_SessionId скорее всего уже существует, поэтому просто обнови его значение. После этого создай кукис .ASPXAUTH. Вот и все! Далее перезагрузи страницу и открой раздел администрирования сайта, щелкнув по ссылке Admin в правом верхнем углу главной страницы. Если все верно, и сессия пользователя еще активна, то ты войдешь в админку, не зная при этом пароль администратора сайта.

И это еще не все

ELMAH не только позволяет подключаться к активным сессиям пользователей, но и существенно облегчает поиск уязвимостей на сайте. Давай в качестве примера проведем атаку типа SQL Injection на наш Music Store. Я специально добавил такую уязвимость в учебный пример — в оригинальной версии Music Store от Microsoft данная проблема отсутствует. Давай посмотрим, как устроена страница поиска альбома. Открывай http://localhost/MusicStore/Search. Как видишь, здесь есть только поле для поиска и кнопка сабмита. Теперь необходимо удостовериться, возможно ли выполнить SQL-запрос, да и вообще, есть ли доступ к базе данных на этой странице. У тебя есть доступ к ELMAH, значит, можно упростить себе жизнь и попробовать сгенерировать исключение. Введи что-либо наподобие "' or select 1 from abcdef". Скорее всего, в базе данных не будет таблицы с именем abcdef (я бы за такую таблицу руки разработчику оторвал). Как и ожидалось, поиск вызвал исключительную ситуацию в коде. Теперь необходимо удостовериться, действительно ли на странице возможна SQL-инъекция. Открывай лог ELMAH и смотри последнее исключение:

System.Data.SqlClient.SqlException (0x80131904):
Incorrect syntax near the keyword 'select'.
Incorrect syntax near '%'.
Unclosed quotation mark after the character string ''.

О чем говорит эта ошибка? Во-первых, сайт построен на базе СУБД SQL Server. Во-вторых, поле ввода ключевого слова не фильтруется. Теперь у тебя должно быть достаточно информации для проведения атаки.

Кстати, ELMAH позволяет не только убедиться, что на странице есть SQL-инъекция, но и автоматизировать поиск подобных уязвимостей на других страницах. Поэтому первым делом при анализе логов обрати внимание на ошибки с типом Sql. Ты также можешь скачать список ошибок в формате CSV, воспользовавшись ссылкой http://localhost/MusicStore/elmah.axd/download, и затем произвести дальнейший анализ в Microsoft Excel или при помощи скриптов. Для начала давай попробуем получить список всех альбомов. Возвращайся на страницу поиска и вводи следующий текст: "' or 1 = 1 --". Получил? Отлично. Теперь давай попробуем сделать что-нибудь более серьезное, например получим список пользователей и хеши паролей.

Music Store, разработанный при помощи ASP.NET MVC и SQL Server, использует авторизацию через web-формы (это следует из того, что при авторизации создается кукис .ASPXAUTH). Можно предположить, что разработчики решили воспользоваться системой авторизации, которая идет в поставке ASP.NET, начиная с версии 2.0. Если все сходится, то информация о пользователях хранится в таблицах aspnet_Users и aspnet_Membership. Чтобы знать наверняка, выполни следующий запрос: "Hits' and exists(select 1 from sys.tables where name = 'aspnet_Users') --". Запрос вернул результат – ты на верном пути. Теперь осталось получить список пользователей. Предположим (если интересно, то можешь посмотреть исходный код страницы), что скрипт запрашивает из базы данных два поля: идентификатор альбома и название. Тогда попробуем выполнить следующий запрос:

select 1, u.UserName + ':' + m.Password + ':' + m.PasswordSalt 
from dbo.aspnet_Users as u
inner join dbo.aspnet_Membership as m on u.UserId = m.UserId

И теперь еще один запрос, только в виде эксплойта для формы поиска:

"' and 1 <> 1 union all select 1, u.UserName + ':' + m.Password + ':'
+ m.PasswordSalt from dbo.aspnet_Users as u inner join
dbo.aspnet_Membership as m on u.UserId = m.UserId --"

Как себя обезопасить?

Как видишь, средства, облегчающие жизнь разработчикам и службе поддержки, могут быть очень опасны, если использовать их по принципу «поставил и забыл». Сразу хочу отметить, что описанные выше проблемы с безопасностью – это не ошибка в ELMAH, а ошибка в конфигурации web-приложения. Более того, защититься от подобных проблем можно довольно просто. Я сам повсеместно использую ELMAH и отключать его в обозримом будущем не планирую, тем более, что в моем случае это зачастую единственное доступное средство отладки. Поэтому я всегда использую стандартные средства безопасности ASP.NET, причем изменения вносятся только в Web.config и не требуют перекомпиляции приложения. Если твое приложение использует авторизацию пользователей через web-формы, то тебе помогут следующие рекомендации:

1. Сначала удали регистрацию ELMAH из разделов configuration/system.web/httpHandlers и configuration/system.webServer/handlers файла Web.config;
2. После этого добавь в раздел configuration следующий XML:

   <location path="elmah.axd">
     <system.web>
   <httpHandlers>
     <add verb="POST,GET,HEAD" path="elmah.axd" 
   type="Elmah.ErrorLogPageFactory, Elmah" />
   </httpHandlers>
   <authorization>
     <allow roles="Administrator" />
     <deny users="*" />
   </authorization>
     </system.web>
     <system.webServer>
   <handlers>
     <add name="Elmah" path="elmah.axd" verb="POST,GET,HEAD"
   type="Elmah.ErrorLogPageFactory, Elmah"
   preCondition="integratedMode" />
   </handlers>
     </system.webServer>
   </location>
   

Готово! Теперь только пользователь c ролью Administrator сможет просматривать логи ELMAH, а это именно то, что нам нужно.

Напоследок

Надеюсь, я смог показать тебе, как безопасные на первый взгляд средства для разработчиков и сотрудников службы поддержки могут нанести непоправимый вред компании при условии, что безопасность приложения неправильно сконфигурирована. Всегда думай о последствиях и никогда не полагайся на принцип «поставил, работает, не трогай».