Xss атака что это
XSS глазами злоумышленника
Что такое XSS и как от него защитится все уже давно знают, поэтому буду краток. XSS это возможность злоумышленника определенным образом (ссылку на возможные варианты смотрите в конце статьи) интегрировать в страницу сайта-жертвы скрипт, который будет выполнен при ее посещении.
Интересно, что в большинстве случаев, где описывается данная уязвимость, нас пугают следующим кодом:
Как-то не очень страшно 🙂 Чем же действительно может быть опасной данная уязвимость?
Пассивная и активная
Существует два типа XSS уязвимостей — пассивная и активная.
Активная уязвимость более опасна, поскольку злоумышленнику нет необходимости заманивать жертву по специальной ссылке, ему достаточно внедрить код в базу или какой-нибудь файл на сервере. Таким образом, все посетители сайта автоматически становятся жертвами. Он может быть интегрирован, например, с помощью внедрения SQL-кода (SQL Injection). Поэтому, не стоит доверять данным, хранящимся в БД, даже если при вставке они были обработаны.
Пример пассивной уязвимости можно посмотреть в самом начале статьи. Тут уже нужна социальная инженерия, например, важное письмо от администрации сайта с просьбой проверить настройки своего аккаунта, после восстановления с бэкапа. Соответственно, нужно знать адрес жертвы или просто устроить спам-рассылку или разместить пост на каком-нибудь форуме, да еще и не факт что жертвы окажутся наивными и перейдут по вашей ссылке.
Причем пассивной уязвимости могут быть подвержены как POST так и GET-параметры. С POST-параметрами, понятно, придется идти на ухищрения. Например, переадресация с сайта злоумышленника.
Следовательно, GET-уязвимость чуть более опасна, т.к. жертве легче заметить неправильный домен, чем дополнительный параметр (хотя url можно вообще закодировать).
Кража Cookies
Это наиболее часто приводимый пример XSS-атаки. В Cookies сайты иногда хранят какую-нибудь ценную информацию (иногда даже логин и пароль (или его хэш) пользователя), но самой опасной является кража активной сессии, поэтому не забываем нажимать ссылку «Выход» на сайтах, даже если это домашний компьютер. К счастью, на большинстве ресурсов время жизни сессии ограничено.
xss уязвимость
Угрозы xss атак с применением javascript
Прежде чем начать, стоит оговориться, что данный материал несет исключительно информационный характер.
Что такое xss атака?
Это такой тип атак, который внедряет в веб-системы вредоносный код, заставляя её выдавать измененные данные, подменяет ссылки (видимые/скрытые) или выводит собственную рекламу на пораженном ресурсе.
Существует два направления атак:
Пассивные – которые требуют непосредственного вмешательства субъекта атаки. Суть заключается в том, чтобы заставить жертву перейти по вредоносной ссылке для выполнения «вредокода». Такой тип атак более сложный в реализации, ведь необходимо обладать не только техническими, но и психологическими знаниями.
Активные – это вид атак, когда хакер пытается найти уязвимость в фильтре сайта. Как же реализуется такая атака? Все очень просто. Нужно при помощи комбинации тегов и символов создать такой запрос, чтобы сайт его понял и выполнил команду. Как только дыра в безопасности найдена, в наш запрос можно вложить «вредокод», который, к примеру, будет воровать cookie и пересылать в удобное нам место. Приведем пример скрипта, ворующего “печеньки” с сайта:
Обычно приходится серьезно потрудиться, чтобы найти дыру в безопасности сайта, ведь большинство фильтров достаточно устойчивы. Но их пишут люди, а им свойственно ошибаться.
Правила безопасности
Откуда и почему вообще возникают подобные уязвимости, которые приводят к катастрофическим последствиям? Все дело во внимательности и знании людей. Разработчики должны писать правильный код, поэтому в этом разделе мы расскажем про минимальные правила безопасности написания сайтов.
Как применяется атака, мы уже рассказывали, но повторимся еще раз. Вся суть xss атаки — это обнаружение дыры в фильтре с целью его обхода.
1. Одно из самых первых и основных правил для разработчика – это применение любого (хотя-бы самого минимального) фильтра.
В проведенном нами исследовании сайтов почти все они были защищены, но все же находились и те, которые не использовали никакой фильтрации получаемых данных. В основном, это встречается на сайтах, написанных на языке PHP. Но, например, в фраемворках python, таких как: flask или Django уже есть встроенные минимальные фильтры, их остается только усилить.
2. Фильтрация символов и вложенных конструкций.
Минимальный фильтр защитит нас от любительских атак и неграмотных специалистов, но от серьезных хакеров нужно строить более серьезную защиту, с более детальной фильтрацией данных. Разработчики должны учитывать и понимать возможную реализацию xss атаки и строить фильтр таким образом, чтобы он распознавал вложенные конструкции. Например, хакер может создать многоуровневую конструкцию, и в самый нижний из них вложить вредоносный javascript код. Фильтр будет блокировать верхний уровень, но нижний будет выполняться.
3. Фильтр должен учитывать всевозможные комбинации символов.
Одной из наших любимых проверок на xss уязвимость является использование открытых и закрытых скобок.
Например: “/?,#”>>>><
Что такое XSS-уязвимость и как тестировщику не пропустить ее
По моему наблюдению довольно много тестировщиков когда-либо слышали такое понятие, как XSS-уязвимость. Но мало кто может просто и на пальцах рассказать на собеседовании про нее. Или эффективно проверить веб-сайт на наличие этой уязвимости. Давайте вместе разберемся со всем этим подробнее и попробуем сами найти несложную XSS-уязвимость на демо-странице, которую я специально подготовил к этой статье.
Если вы гуру тестирования безопасности и на раз-два участвуете в баунти-программах крупных IT-компаний, а количество найденных вами XSS исчисляется десятками или даже сотнями — можно смело проходить мимо этой статьи. Если же вы новичок в теме и только начинаете интересоваться поиском уязвимостей — добро пожаловать под кат.
Определение
XSS (англ. Cross-Site Scripting — «межсайтовый скриптинг») — довольно распространенная уязвимость, которую можно обнаружить на множестве веб-приложений. Ее суть довольно проста, злоумышленнику удается внедрить на страницу JavaScript-код, который не был предусмотрен разработчиками. Этот код будет выполняться каждый раз, когда жертвы (обычные пользователи) будут заходить на страницу приложения, куда этот код был добавлен. А дальше существует несколько сценариев развития.
Первый: злоумышленнику удастся заполучить авторизационные данные пользователя и войти в его аккаунт.
Второй: злоумышленник может незаметно для жертвы перенаправить его на другую страницу-клон. Эта страница может выглядеть совершенно идентично той, на которой пользователь рассчитывал оказаться. Но вот принадлежать она будет злоумышленнику. Если пользователь не заметит подмены и на этой странице введет какие-то sensitive data, то есть личные данные, они окажутся у злоумышленника.
Третий… да в общем-то много чего еще можно придумать. Почти все, что может JavaScript, становится доступным для злоумышленника. Чуть ниже мы рассмотрим подробнее один из таких примеров. А пока давайте попробуем чуть подробнее обсудить, как именно устроена уязвимость. И почему злоумышленнику удается внедрить свой код в чужое приложение без доступа к его исходникам.
Небольшое предупреждение. Вся информация далее представлена исключительно в информационных целях. Тестировщик должен уметь проверять свое веб-приложение на уязвимости. Однако, использование XSS-уязвимостей на чужих ресурсах является незаконным.
Если говорить про действующее российское законодательство, когда исследователь тестирует чужой продукт на предмет уязвимостей или проникает в чужую сеть без ведома и согласия владельца, его действия могут быть расценены как неправомерные.
Как устроена уязвимость?
Прежде всего, как именно удается внедрить на страницу JavaScript-код, которого там раньше не было? И как получается распространить этот код среди других пользователей?
Например, можно добавить JavaScript-код в поле ввода, текст из которого сохраняется и в дальнейшем отображается на странице для всех пользователей. Это может быть поле для ввода информации о себе на странице профиля социальной сети или комментарии на форуме.
Злоумышленник вводит текст (и за одно вредоносный код), который сохраняется на странице. Когда другие пользователи зайдут на эту же страницу, вместе с текстом они загрузят и JavaScript-код злоумышленника. Именно в момент загрузки этот код отработает. Конечно, уязвимость сработает, только если текст при сохранении не будет обезопасен. О том, как это сделать, и почему разработчики иногда забывают об этом, поговорим чуть позже.
Это лишь самый простой и очевидный пример того, где может быть спрятана уязвимость. Более интересный пример мы с вами чуть ниже рассмотрим на специально подготовленной демо-страничке.
А пока давайте двигаться дальше.
Почему такие ошибки часто встречаются на веб-проектах?
Суть в том, что браузер не может самостоятельно отличить обычный текст от текста, который является CSS, HTML или JavaScript-кодом. Он будет пытаться обрабатывать все, что находится между тегами
В случае, если страница является уязвимой, после ввода этого кода на странице появится вот такое окошко:
Оно и будет означать, что наш JavaScript-код исполнился и мы нашли XSS-уязвимость.
Итак, вводим код и видим следующее предупреждение:
Форма не позволяет нам осуществить поиск по такому значению, так как форма валидируется и хочет работать только с буквами и цифрами. На первый взгляд кажется, что разработчик все учел и защитил страницу от XSS, но это не совсем так.
Помните, чуть выше мы с вами заметили, что текст, который мы вводим в поле поиска, отображается в URL в так называемом GET-параметре? Имя этого параметра “q”, а значение — то, что мы вводим в поле поиска. Это сделано для того, чтобы можно было скопировать URL вместе с этой самой строкой поиска и в следующий раз открыть страницу сразу с нужными авторами.
Например, вот такой URL откроет страницу сразу только с книгами Рея Брэдбери: playground.learnqa.ru/demo/xss?q=Рей+Брэдбери
В отличие от формы, валидацию URL разработчик сделать не мог — любой пользователь в своем браузере может ввести любой URL, какой захочет, в том числе и с любым значением GET-параметра. Задача разработчика в этом случае — не забыть учесть все варианты и написать правильный обработчик значения этого GET-параметра.
Проверим, не забыл ли наш разработчик все учесть тут. Попробуем в GET-параметр “q” подставить тот самый JavaScript-код: https://playground.learnqa.ru/demo/xss?q=
Перейдя по этому URL мы видим, что на странице появилось окошко со значением 123. Но почему?
Все довольно просто. Помните, когда сайт не может найти нужные книги по заданному поисковому запросу, он текст этого поискового запроса выводит в тексте ошибке? Мол, не нашли ничего по запросу “бла-бла”. Вот вместо этого “бла-бла” у нас теперь JavaScript-код с алертом. Разработчик написал валидацию поля ввода и решил, что так он защитил сайт от того, чтобы JavaScript мог оказаться в поисковом запросе. И не стал экранировать текст ошибки. Нам же удалось обойти валидацию через URL, поменяв там значение поискового запроса.
Ради интереса теперь можем вывести значение нашей сессионной cookie, для этого вместо в URL надо подставить другой код:
С этим я уже предоставлю поиграться вам самостоятельно. 🙂
Найдя ошибку, стоит обратиться к разработчикам — они ее исправят.
Способов закрыть ошибку довольно много. Экранировать текст — не единственный из них. Еще можно запретить самому JavaScript видеть некоторые cookie. Для этого у cookie есть специальный параметр “http only”. Если он выставлен в TRUE, JavaScript никак не сможет узнать, что такая cookie вообще выставлена и не сможет ее прочитать и передать злоумышленнику даже в том случае, если ему удастся найти XSS на вашем проекте.
Все это — лишь малый, далеко не полный список манипуляций, предотвращающий XSS-уязвимости. Как писалось выше — при обнаружении XSS в ходе тестирования лучше всего пообщаться с программистами.
Если Вам интересно знать больше про тестирование безопасности, хочется лучше разобраться в устройстве клиент-серверной архитектуры, понять и отточить самые эффективные способы поиска уязвимостей на настоящем веб-приложении, приходите на мой курс “Тестирование безопасности”. Вся необходима информация есть в моем профиле.
Вас ждет только полезная и нужная теория без воды и большое количество практических примеров и заданий. Вы будете исследовать множество веб-страниц, напичканных самыми разными уязвимостями. Итоговой работой станет большое исследование либо вашего рабочего проекта, либо одного из веб-приложений таких гигантов как Google, Facebook, Twitter и так далее.
XSS атака
XSS (межсайтовый скриптинг) – одна из разновидностей атак на веб-системы, которая подразумевает внедрение вредоносного кода на определенную страницу сайта и взаимодействие этого кода с удаленным сервером злоумышленников при открытии страницы пользователем.
Термин с английского расшифровывается как Cross-Site Scripting, но при этом получил аббревиатуру XSS, чтобы не было путаницы с CSS (каскадные таблицы стилей).
Как работает межсайтовый скриптинг
Основная цель межсайтового скриптинга – кража cookies пользователей при помощи встроенного на сервере скрипта с дальнейшей выборкой необходимых данных и использованием их для последующих атак и взломов. Злоумышленник осуществляет атаку пользователей не напрямую, а с использованием уязвимостей веб-сайта, который посещают жертвы, и внедряет специальный JavaScript. В браузере у пользователей этот код отображается как единая часть сайта. При этом посещаемый ресурс по факту является соучастником XSS-атаки.
Если сравнивать с SQL-инъекциями, то XSS безопасен для сервера, но несет угрозу для пользователей зараженного ресурса или страницы. Однако, если к злоумышленнику попадут cookies администратора, можно получить доступ к панели управления сайтом и его содержимому.
Методика атаки через XSS
Запуск вредоносного кода JavaScript возможен только в браузере жертвы, поэтому сайт, на который зайдет пользователь, должен иметь уязвимость к XSS. Для совершения атаки злоумышленник изначально проверяет ресурсы на наличие уязвимостей через XSS, используя автоматизированные скрипты или ручной режим поиска. Обычно это стандартные формы, которые могут отправлять и принимать запросы (комментарии, поиск, обратная связь).
Проводится полный сбор страниц с формами ввода, и каждая сканируется на наличие уязвимостей. Например, у нас есть страница «Поиск» на сайте. Для проверки уязвимости XSS достаточно ввести запрос:
Если на экране появится уведомление, значит вы обнаружили брешь в безопасности. В противном случае система отобразит вам страницу с результатами поиска. Основные популярные CMS уже давно лишились подобных проблем, но из-за возможности расширения функционала за счет модулей и плагинов, создаваемых сторонними разработчиками, шансы на использование уязвимостей XSS возрастают в разы, особенно в Joomla, DLE, Bitrix, WordPress. Чаще всего XSS-уязвимости проверяются в браузере Internet Explorer.
Еще один возможный вариант поиска – использование страниц, которые обрабатывают GET-запросы. Допустим, у нас есть ссылка вида: http://site.ru/catalog?p=8
В адресной строке вместо идентификатора (8) добавляем скрипт – «>, в результате чего получаем ссылку такого вида: .
Если страница имеет уязвимости XSS, на экране появится уведомление такого же плана, как и в первом случае.
Для поиска «дыр» на сайте существует огромное количество готовых скриптов и запросов, и если ни один из них не подходит, значит ресурс надежно защищен от подобных атак.
Общая классификация XSS
Четкой классификации для межсайтового скриптинга не существует, но экспертами по всему миру выделено три основных типа.
Хранимые XSS (постоянные). Один из самых опасных типов уязвимостей, так как позволяет злоумышленнику получить доступ к серверу и уже с него управлять вредоносным кодом (удалять, модифицировать). Каждый раз при обращении к сайту выполняется заранее загруженный код, работающий в автоматическом режиме. В основном таким уязвимостям подвержены форумы, порталы, блоги, где присутствует возможность комментирования в HTML без ограничений. Вредоносные скрипты с легкостью могут быть встроены как в текст, так и в картинки, рисунки.
Отраженные XSS (непостоянные). В этом случае вредоносная строчка выступает в роли запроса жертвы к зараженному веб-сайту. Работает этот принцип по следующей схеме:
DOM-модели. В этом варианте возможно использование как хранимых XSS, так и отраженных. Суть заключается в следующем:
Виды XSS по способу взаимодействия
Так как основная цель злоумышленника – запустить вредоносный скрипт на компьютере жертвы, существует еще и два основных типа XSS-атак по способу взаимодействия.
Пассивные. От жертвы требуется определенное действие, чтобы вызвать обработчик событий и запустить вредоносный скрипт в установленной форме. Для этого используется социальная инженерия, например отправка электронного письма с призывом перейти по ссылке и нажать на определенную область на сайте. Как только пользователь наведет на нужный объект и кликнет по нему, запустится вредоносный скрипт. Если же жертва бездействует, код не будет активирован.
Активные. Злоумышленнику не нужно заманивать жертву по специальным ссылкам, так как код встраивается в базах данных или в каком-нибудь исполняемом файле на сервере. От пользователя не требуется никакой активности. У форм ввода, как правило, установлен специальный обработчик событий, автоматически активирующийся при попадании на эту страничку. В итоге все пользователи, перешедшие по этой ссылке, станут жертвами злоумышленника.
Как проверить сайт на наличие уязвимостей XSS и защитить его
Для быстрой проверки сайта на наличие уязвимостей XSS можно воспользоваться специализированными сервисами, которые в автоматическом режиме проведут сканирование страницы. В обязательном порядке нужно проверять все URL, где возможна отправка данных со стороны пользователя (формы комментариев, обратная связь, поиск). В качестве примера можете использовать http://xss-scanner.com, но не стоит ограничиваться лишь одним инструментом.
Например, для быстрой фильтрации и автоматической замены спецсимволов вы можете использовать следующий код на сайте:
Несколько советов по предотвращению использования XSS на вашем сайте:
Полное пособие по межсайтовому скриптингу
XSS – это тип уязвимости программного обеспечения, свойственный Web-приложениям, который позволяет атакующему внедрить клиентский сценарий в web-страницы, просматриваемые другими пользователями
Автор: Ahmed Elhady Mohamed
Перевод: www.SecurityLab.ru
Введение
В Wikipedia содержится следующее определение для XSS: «Межсайтовый скритинг (XSS) – это тип уязвимости программного обеспечения, свойственный Web-приложениям (путем обхода ограничений безопасности браузера)», который позволяет атакующему внедрить клиентский сценарий в web-страницы, просматриваемые другими пользователями. Уязвимость межсайтового скриптинга может использоваться атакующим для обхода таких механизмов безопасности как политика единства происхождения. Согласно данным Symantec за 2007 год, XSS уязвимости составили 80.5% от общего числа брешей, обнаруженных на сайтах. Рейтинг опасности таких уязвимостей может варьироваться в зависимости от важности данных, хранящихся на уязвимом сайте и существующих механизмов защиты».
Вкратце, XSS или CSS (Cross-site Scripting, аббревиатура, которая также означает Cascading Style Sheets – таблицы каскадных стилей) является довольно распространенной уязвимостью среди Web-приложений. XSS позволяет атакующему внедрить вредоносный код на страницу и отправить его обратно в браузер пользователя, где этот код будет выполнен. Причиной этому являются доверительные отношения разработчика приложения к входным данным или некорректная фильтрация входных данных.
XSS опасен
XSS действительно является уязвимостью высокой степени опасности, поскольку она может использоваться для изменения DOM-модели сайта, что в свою очередь позволит похитить учетных данных администратора сайта и получить полный контроль над уязвимым приложением.
Какие цели преследует атакующий?
Типы XSS
Существует три типа XSS уязвимостей:
Далее мы подробно обсудим каждый их этих типов.
Постоянный (хранимый) XSS
Википедия характеризует хранимый XSS как наиболее разрушительный тип атак. Хранимый XSS возможен, когда злоумышленнику удается внедрить на сервер вредоносный код, выполняющийся в браузере каждый раз при обращении к оригинальной странице. Классическим примером этой уязвимости являются форумы, на которых разрешено оставлять комментарии в HTML формате без ограничений.
Другими словами, хранимый XSS возникает, когда разработчики осуществляют некорректную фильтрацию при сохранении входных данные в БД на сервере или в при записи этих данных в файлы, а затем выводят эти данные в браузер пользователю.
Демонстрация хранимого XSS
Ниже приведен пример PHP сценария, уязвимого к хранимому XSS:
В коде не осуществляется корректная обработка параметров “message” и “name” перед сохранением данных в таблицу guestbook. Таким образом, при выводе этих данных в браузер пользователя существует возможность выполнение вредоносного JavaScript кода.
В демонстрационных целях при попробуем проэксплуатировать эту уязвимость на примере DVWA.
После отправки этой формы можем посмотреть на выполнение нашего JavaScript кода:
Непостоянный (отраженный) XSS
Согласно Wikipedia, непостоянный XSS является наиболее распространенным типом XSS. Непостоянный XSS имеет место, когда данные, предоставляемые Web-клиентов в строке запроса или HTML форме, используются для генерации ответа клиенту без обработки этих данных.
Демонстрация отраженного XSS
Ниже приведен пример кода, уязвимого к отраженному XSS:
Как видно из примера, очистка данных не осуществляется для параметра “name” перед его выводом в браузера пользователя. Таким образом, если в него внедрить JavaScript сценарий, это сценарий будет выполнен.
Мы воспользуемся приложением DVWA для демонстрации этой уязвимости:
Давайте внедрим код “” в элемент формы:
XSS в DOM-модели
Таким образом, XSS возникает непосредственно внутри JavaScript сценария. Примером к этой уязвимости может служить сценарий, который получает данные из URL через location.* DOM или посредством XMLHttpRequest запроса, и затем использует их без фильтрации для создания динамических HTML объектов.
Демонстрация XSS в DOM-модели
Для примера мы воспользуемся сценарием, который позволяет пользователю выбрать язык интерфейса. Язык по умолчанию передается посредством URL в параметре “default”. Обработка языка интерфейса осуществляется следующим образом:
Доступ к этой странице осуществляется по следующему адресу: http://www.some.site/page.html?default=French
Для эксплуатации XSS уязвимости в DOM-модели мы выполним следующий запрос:
Исходный JavaScript сценарий не ожидает, что входные данные могут содержать HTML код, поэтому просто выводит их на странице. Затем браузер обрабатывает этот код и выполняет сценарий alert(document.cookie).
Теперь давайте рассмотрим некоторые методы эксплуатации уязвимостей межсайтового скриптинга.
Методы эксплуатация XSS
Далеко не все методы фильтрации помогают защитить сайт от XSS. Ниже мы рассмотрим самые популярные варианты фильтрации данных и техники обхода таких фильтров.
Метод 1: замена «
Стоит отметить, что использование alert(“XSS”) для тестирования XSS нежелательно, поскольку большинство сайтов блокируют сценарии по ключевому слову «XSS».
Метод 2: использование magic quotes
Применяя этот метод, разработчик использует фильтрацию функции «addslashes()» языка PHP, которая добавляет символ «\» перед любым специальным символом. Таким образом, код, написанный на JavaScript, не будет выполнен.
Существует несколько способов обойти такую фильтрацию. Остановимся на двух из них.
Как злоумышленник может украсть файлы куки?
На первый взгляд, что кража файлов куки – это сложная и кропотливая работа. На самом деле для успешного хищения файлов куки необходимы лишь общие навыки программирования и понимание XSS уязвимости.
Для демонстрации мы создадим сценарий collect_cookie.php на языке PHP, который будет размещен на сервере любой компании, предоставляющей хостинг. После этого будет внедрен код на языке JavaScript, который будет похищать файлы куки и передавать их на наш сайт. Когда php-файл получит данные, он сохранит их в файл stolen_cookies.txt.
Чтобы похитить файлы куки необходимо наличие трех составляющих:
Первая составляющая: скрипт collect_cookie.php
Ниже приведен PHP-скрипт, который будет использован для сбора файлов куки и их запись в файл stolen_cookie.txt
Пожалуйста, нажмите href=»http://www.google.com/»>здесь, чтобы перейти на предыдущую страницу’;
?>
Разберемся, что делает данный скрипт:
В данной строке происходит сохранения значения переменной «cookies» из GET-запроса в переменную «collectedCookie»
$date=date(«l ds of F Y h:i:s A»);
Здесь происходит сохранение времени соединения, по нему можно определить время кражи cookies.
Сохранение user_agent жертвы для осуществления будущих атак, если они потребуются.
В этой строке происходит создание файла stolen_cookie.txt, в котором будут храниться похищенные данные.
fwrite($file,»DATE:$date || USER AGENT:$user_agent || COOKIE:$collectedCookie \n»);
Сохранение данных в следующем формате: (“ДАТА: || USER AGENT || COOKIE”)
echo ‘Извините, сайт находится в состоянии разработки. Пожалуйста, нажмите href=»http://www.google.com/»>здесь, чтобы перейти на предыдущую страницу’;
Осуществляется вывод на экран текста (“Извините, сайт находится в состоянии разработки”) и ссылки, ведущая на страницу google.com.
Первый шаг к сбору информации о cookies закончен.
Вторая составляющая: JavaScript-код
Ниже приведен JavaScript-код, который необходимо выполнить в браузере пользователя. Можно внедрить любой из нижеприведенных сценариев:
Данный скрипт требует реакции пользователя, поскольку выводит на экран ссылку на наш сайт. Если пользователь нажмет на показанную ему ссылку, то он попадет на наш сайт и его файлы куки будут украдены.
Этот скрипт не требует никаких действий со стороны пользователя. Во втором случае на сайт жертвы внедряется скрытый IFrame, невидимый для глаз пользователя.
В итоге украденные файлы куки окажутся в файле stolen_cookie.txt. По ссылке ниже доступно видео, демонстрирующие как можно украсть файлы куки: http://www.youtube.com/watch?v=ZeLyJnhz4ak
Что такое BeEF?
BeEF (сокращение от Browser Exploitation Framework) – платформа для эксплуатации браузеров. BeEF используется для разнообразных атак на компьютеры пользователей с целью их захвата. Наличие этого инструмента значительно облегчает работу, поскольку многие рутинные операции уже автоматизированы.
Поскольку операция захвата компьютера-зомби автоматизирована, с помощью приложения beef (Browser Exploitation Framework) можно захватывать множество компьютеров-зомби (так называют компьютеры, которые находятся внутри ботнета).
На официальном сайте проекта BeEF содержится следующее описание программы: «Browser Exploitation Framework (BeEF) – это мощная профессиональная утилита. В BeEF реализованы последние методы атак, которые используют специалисты в области тестов на проникновение с богатым практическим опытом атак на клиентские приложения. В отличие от остальных платформ безопасности, BeEF ориентирован на эксплуатацию уязвимостей в браузерах для получения контроля над компьютером. Данный проект разрабатывается исключительно для легальных исследований и тестов на проникновение.»
Вы можете загрузить BeEF с сайта проекта http://beefproject.com.
Как использовать BeEF?
После запуска beef-ng на экране отобразиться консоль приложения:
Теперь Вы можете открыть панель управления BeEF, перейдя по ссылке и используя «beef»/«beef» в качестве логина и пароля.
Необходимо поместить JavaScript-код на сервер или клиент жертвы, чтобы захватить компьютер-зомби. Код выглядит следующим образом:
Ниже можно увидеть список захваченных компьютеров зомби и их статус присутствия в сети.
Обратите внимание на вкладку Commands
Как можно увидеть, существует довольно много эксплоитов, которые можно использовать. Например, можно выбрать модуль misc->alert dialog. Вы можете выбрать такой модуль, какой захотите.
Ниже виден результат. Как мы и ожидали, скрипт выполнился, и появилось окошко с предупреждением.
Как вы видите, процесс полностью автоматизирован. Вам только нужно настроить и запустить модуль. Интеграция beef и metasploit заслуживает отдельного внимания. На вкладке Command Вы можете увидеть модуль metasploit. Зайдите туда и посмотрите, насколько богатый функционал предоставляет модуль metasploit. Вы увидите страницу, на которой можно будет выбрать любой эксплоит из набора metasploit и любую настраиваемую полезную нагрузку.
Дополнительная информация о beef расположена по адресу: https://github.com/beefproject/beef/wiki
Заключение
Как мы убедились, наш JavaScript-код был выполнен. Таким же образом могут выполняться и вредоносные коды, которые распространены в интернете. BeEF дает атакующему огромное количество информации, которую можно сохранять и использовать в дальнейших атаках, для получения удаленного доступа.
Мы надеемся, что приведенная информация окажется для вас полезной, в будущем мы предоставим еще много полезного материала для изучения.