Впервые об этом фреймворке я узнал из темы iv. (http://forum.antichat.ru/thread119108.html). После знакомства с w3af я решил перевести официальную документацию для того что бы пользоваться им, хотя бы на базовом уровне, смог каждый вне зависимости от знаний языка. Возможно этот перевод будет опубликован на официальном сайте как русскоязычная версия (на данный момент имеются только английская и французская). Некоторые возможности форматирования не релизованы в редакторе форума, поэтому советую скачать PDF-версию документа: http://kuzya.name/files/w3af_final.pdf (27 страниц, шрифт Arial 12pt) P.S. Мой перевод меньше официального документа на 10 страниц. Это из-за того что автор испольует объёмные вырезки из консоли в качестве примеров, а я небольшие скриншоты (конечно, без изменения смысла) Перевод официальной документации в w3af. Переводчик: Кузьмин Антон (Kuzya) http://kuzya.name Версия w3af на момент перевода: 1.0-rc2 Официальные сайты: w3af.sourceforge.net / w3af.sf.net Введение Этот документ является пользовательским руководством к фреймворку для атак и аудита веб-приложений w3af. Здесь будет дана базовая информация о фреймворке, о принципах его работы и возможностях. Загрузка Фреймворк может быть скачен с главной страницы нашего проекта: http://w3af.sf.net/#download У w3af есть 2 варианта установки : из релиз-пакета (установочный файл w3af для Windows и tgz-пакет для *nix-систем) или из SVN. Неопытные пользователи могут скачивать новые версии фреймворка с сайта, тогда как более продвинутые могут обновлять его с помощью SVN. Установка Фреймворк должен работать на любой платформе которая поддерживает Python. Работоспособность w3af была протестирована на Linux, Windows XP, Windows Vista и OpenBSD. Это руководство содержит пример установки на Linux-платформу который применим к остальным *nix-системам. Установить w3af на Windows-системы Вы можете с помощью готового установочного файла (находится на нашем сайте). Системные требования Для запуска w3af требуются следующие пакеты, которые можно условно поделить на 2 группы: Пакеты, которые необходимы для функционирования ядра: Python 2.5 fpconst-0.7.2 pygoogle nltk SOAPpy pyPdf Beautiful Soup Python OpenSSL json.py scapy Пакеты, необходымые для работы с графическим интерфейсом: python sqlite3 graphviz pygtk 2.0 gtk 2.12 Как Вы наверное уже догадались, библиотеки из первой категории нужны для запуска w3af, вне зависимости от выбранного интерфейса, а требования второй группы обязательны только если Вы собрались использовать графический интерфейс. Некоторые библиотеки поставляются сразу с дистрибутивом для того чтобы упростить установку. Их Вы можете найти в директории extlib. Большинство библиотек могут быть установлены прямо отсюда, но возможен вариант когда в процессе установки Вас попросят установить какие-то дополнительные пакеты. Вот пошаговое описание установки библиотек (она должна производиться под пользователем root) Фазы работы w3af Перед запуском w3af пользователь должен знать какие фазы работы существуют в приложении и как работают плагины. Пагины, имеющиеся в w3af, делятся на 3 типа - для исследований, для аудита и для проведения атак. Исследовательские плагины ответственны за поиск новых ссылок, форм и других мест через которые могут быть проведены инъекционные атаки. Классический пример исследовательского плагина это webSpider. Он находит ссылки в теле страниц, и показывает какие места в них могут быть использованы для инъекционных атак. Когда пользователь активирует один или более плагинов такого типа, то они работают по кругу: если плагин А находит новый URL то ядро w3af посылает этот адрес плагину Б. Если плагин Б находит новый URL то он посылается плагину А. Этот процесс будет происходить пока каждая ссылка не будет обработана всеми плагинами. Плагины для аудита берут места возможных инъекций в ссылках полученных исследовательскими плагинами, и производят запросы по ним со специально сформированными данными пытаясь выявить возможные уязвимости. Классическим примером является плагин для поиска SQL-инъекций. Плагины проведения атак берут на себя задачу эксплуатации уязвимости. Они обычно возвращают командную строку на удалённом сервере или дамп таблиц. Запуск w3af w3af имеет 2 интерфейса - консольный пользовательский интерфейс (в официальных документах он обозначается как consoleUI - п.п.) и графический (в официальных документах он обозначается как gtkUi - п.п.). Это руководство описывает работу с консольной версией интерфейса потому что она больше тестировалась и отлаживалась чем графическая. Для вызова консольного интерфейса нужно запустить соответствующий бинарный файл w3af без параметров: Из этой строки Вы можете конфигурировать фреймворк, запускать сканирование и эксплойты для уязвимостей. Для этого имеется специальный набор команд. Первая команда, которую Вам нужно запомнить - "help" (так же после неё может быть указана конкретная команда или параметр): Для каждой команды имеется подробное описание. Команда "help" может принимать в качестве единственного параметра другую команду, как это показано на скриншоте. Интересной вещью является самодописывание команд в консоли (например наберите "plu" и нажмите TAB) и история команд (после написания Вами разных команд Вы можете перемещаться по ним с помощью стрелок вверх и вниз). Для того чтобы зайти в управление какой-либо конфигурации Вы должны набрать её имя и нажать Enter. После этого командная строка изменится соответствующим образом: Управление каждой настройкой осуществляется следующими командами: help view set back Вот пример их использования с опцией http-settings: Вообщем, команда "view" служит для просмотра списка всех конфигурационных параметров с их описанием и значением. Команда "set" используется для изменения значений параметров. Так же Вы можете использовать команды "back", "." (у меня эта команда не срабатывала - п.п.) и комбинацию клавиш CTRL+C для того чтобы вернуться в предыдущее меню. Детальное описание для каждого из конфигурационных параметров может быть получено с использованием команды "help", как показано в примере: Меню "http-settings" и "misc-settings" используются для указания фреймворку глобальных настроек. Каждый параметр имеет значение по умолчанию, и в большинстве случаев Вы можете оставить всё без изменений. w3af был спроектирован так чтобы позволить новичкам пользоваться данным инструментом вне зависимости от знаний его внутреннего устройства. Зато настройки могут достаточно гибко изменятся экспертами которые знают что они хотят и могут поменять параметры чётко под свои задачи. Запуск w3af с GTK-интерфейсом Фреймворк помимо консольного интерфейса имеет ещё и графический. Открыть его Вы можете запустив соответствующий исполняемый файл: Графический интерфейс позволяет управлять действиями (например сканированием) и настройками фреймворка очень легко и быстро. Вот как он выглядит.
Плагины Плагины ищут ссылки, обнаружают уязвимости и т.д - вообщем выполняют всю основную работу. Сейчас мы научимся их настраивать. Вопервых, нужно сказать что w3af имеет 3 основных типа плагинов: для исследований, аудита и эксплуатации уязвимостей. Вот полный лист категорий (включая и 3 основные): discovery audit grep exploit output mangle bruteforce evasion Первый вид плагинов находит места для возможного проведения инъекционных атак. Они позже передаются audit-плагинам для поиска уязвимостей. Grep-плагины анализируют содержимое всех страниц и ищут в нём что-либо подозрительное. Например grep-плагин ищет комментарии со словом "password" в коде страниц. Плагины для эксплуатации уязвимостей (exploit) запускаются при работе audit-плагинов и пытаются дать пользователю что ни будь полезное (удалённый шелл, SQL-дамп и т.д.). Output-плагины осуществляют связь между фреймворком и пользователем. Они сохраняют полученные данные в виде отчётов в текстовый или html-файл. Отладочная информация так же передаётся этим плагинам и может быть в будущем использована для анализа. Mangle-плагины позволяют модифицировать запросы к серверу и ответы от него с помощью регулярных выражений. Bruteforce-плагины занимаются подбором паролей. Они запускаются на фазе исследования (работы discovery-плагинов) Ну и наконец evasion-плагины. Они нужны для избежания обнаружения сканирования (скрытие от IDS и т.д.). Настройка плагинов Плагины можно настроить в соответствующем разделе. Используйте для этого команду "plugins" в главном меню. Все плагины могут быть настроены здесь, за исключением оных их exploit-группы. Вот примеры того как можно узнать синтаксис для любого из них: Нижеприведённый пример демонстрирует использование команды для того чтобы увидеть доступные audit-плагины и их статус. Для активации плагинов "xss" и "sqli", и проверки того что фреймворк правильно понял нас, можно использовать следующий набор команд В появившемся списке Вы можете увидеть то что нужные нам плагины теперь активны. А если пользователю интересно что делает тот или иной плагин то он может использовать команду "desc". Теперь мы можем узнать что делает плагин, но давайте проверим его настройки: Конфигурационное меню у плагинов всегда имеет команду "set" для изменения значений и команду "view" выводящую список существующих опций. В предыдущем примере мы отключили одну из проверок в xss-плагине и посмотрели список опций sqli-плагина который на данный момент не имеет параметров. Начало сканирования После настройки всех необходимых плагинов пользователь должен указать целевой URL и начать сканирование. Указание цели происходит следующим путём: В конце нужно выполнить команду "start". Время от времени Вы можете нажимать Enter для того чтобы видеть текущую информацию о ходе сканирования. Полная сессия работы Рассмотрим пример работы с w3af от начала и до конца. Обратите внимание на вставленные коментарии так как они содержат дополнительную информацию. Все предыдущие команды активировали два output-плагина - "console" и "textFile", и настроили их. В этом случае мы будем запускать только discovery-плагины. А именно - "allowedMethods" и "webSpider". После фазы исследования пользователь получил следующие данные: Список полученных URL: А в секции отчёта будет информация о местах с возможными инъекционными уязвимостями, которые будут использованы audit-плагинами: По окончании работы приложения пользователь возвращается в командную строку. Предупреждение об исследовании Фаза исследований это палка о двух концах: если использовать её с умом то можно получить много информации о веб-приложении, а пользоваться этим безрассудно то можно прождать несколько часов и получить небольшой результат. Скажу более понятно - безрассудный вариант это например активация всех discovery-плагинов ( "discovery all" ) без чёткого понимания того что они делают. Вот несколько примеров исследования сайтов и рекомендаций по ним: "Вы тестируйте веб-приложение во внутренней сети. Оно имеет большую структуру и не использует Flash или JS-код. Рекомендация : Вам нужна команда "discovery all,!spiderMan, !fingerGoogle, !fingerMSN, !fingerPKS, !MSNSpider, !googleSpider, !phishtank, !googleSafeBrowsing". Причина: Плагин Spiderman должен быть использован только тогда когда webSpider не может найти ссылок. Плагины FingerGoogle, FingerMSN и FingerPKS ищут почтовые адреса в поисковиках. Если веб-приложение находится во внутренней сети то адреса, находящиеся на его страницах, никогда не попадут к ним. Плагины MSNSpider и googleSpider ищут ссылки с помощью соответствующих поисковых систем. Их не нужно использовать по той же причине. Плагины phishtank и googleSafeBrowsing сделаны для поиска фишинговых сайтов, но так как сайт с приложением находится во внутренней сети то он не может быть проверен поисковиком. "Вы тестируйте веб-приложение в интернете. Оно имеет большую структуру и не содержит элементов Flash и JS-кода Рекомендация : Вам нужна команда "discovery all,!spiderMan, !wordnet , !googleSets". Причина: Плагин Spiderman должен быть задействован только тогда когда плагин webSpider не может сам обнаружить ссылок на главной странице. Wordnet и googleSets работают очень долго при работе в интернете, поэтому их отключение является хорошей идеей. "Вы тестируйте веб-приложение в интернете. Оно большое и содержит элементы Flash или JS-кода. Так же Вы знаете что приложение не реализует какой-либо веб-сервис. Рекомендация :Вам нужна команда "discovery all, !wordnet , !googleSets, !wsdlFinder". Причина: Плагины wordnet и googleSets отнимают много времени на выполнение в интернете, поэтому их отключение является хорошей идеей. А wsdlFinder не нужно включать если мы итак знаем что веб-сервисов на сайте нет. "Вы проверяете приложение в интернет. Вам требуется узнать досконально всё о его функционале и Вы не ограничены временем. Рекомендация : Используйте команду "discovery all" . Причина: Вы хотите узнать о сайте как можно больше и не боитесь потратить на это пару дней.
Когда ничего не получается... Итак. Вы активировали рекомендуемые плагины, запустили сканирование час назад, но до сих пор ничего не найдено. Когда Вы окажитесь в такой ситуации у Вас будет 2 выхода - ждать пока w3af закончит сканирование или нажать CTRL+C сбросив текущие задачи исследования и запустить фазу аудита. Так же Вы должны помнить что если Вы сохраняете отладочную информацию в текстовом файле то можете открыть новое окно терминала и набрать "tail -f w3af-output-file.txt". После запуска этой команды Вы увидите что на самом деле происходит с w3af и возможно выявите причину его неработоспособности. Скрипты в w3af При разработке w3af я понял что программе нужен способ выполнять какие-либо часто повторяющиеся действия. Поэтому я включил в функционал фреймворка поддержку скриптов. w3af может запустить скрипт с использованием параметра "-s". Файл скрипта должен представлять из себя текстовый файл с набором команд. Пример содержимого такого файла: Для запуска этого скрипта Вы должны выполнить команду "./w3af_console s scripts/scriptosCommanding.w3af". Результат будет тот же самый как если бы Вы вводили все эти команды вручную: Вывод информации Вся выводимая приложением информация управляется output-плагинами. Каждый такой плагин может записывать информацию в различных форматах (txt, html и т.д). Для примера - плагин "textFile" по умолчанию пишет всю исходящую информацию в файл output-w3af.txt. Конфигурация таких плагинов происходит так же как и остальных, рассматриваемых нами выше. Такие настройки укажут плагину "textFile" что нужно выводить все сообщения включая отладочную информацию в файл "outputw3af.txt". А вот пример того что в этот файл будет помещаться: Output-плагины так же могут записывать и содержимое HTTP-запросов и ответов. Каждый плагин работает с этой информацией по разному. Например, плагин textFile пишет все запросы и ответы в файл, тогда как htmlFile-плагин равнодушен к этой информации и просто ничего с ней не делает. Рассмотрим пример лог-файла плагина textFile: Все сообщения выводимые плагинами или фреймворком попадают ко ВСЕМ активированным output-плагинам. Так что если Вы активируйте одновременно плагины textFile и htmlFile то они оба будут записывать одну и ту же информацию.
Сложноструктурные сайты. Некоторые сайты содержат в себе специфические объекты типа Flash-элементов или Java-апплетов. Это не позволяет получать фреймворку информацию о ссылках стандартным способом. Специально для этого создан скрипт spiderMan. Он запускает http-прокси-сервер через который пользователь должен бродить по сайту. В это время скрипт будет извлекать из запросов и ответов сервера нужную ему информацию. Как пример рассмотрим следующую ситуацию. Допустим что w3af проверил сайт и не нашёл ни одной ссылки на главной странице. После более подробного рассмотрения оказывается что на главной странице находится навигационное меню, представляющее из себя Java-аплет. Пользователь запускает w3af снова и активирует плагин spiderMan, после чего бродит по сайту самостоятельно через прокси-сервер созданный этим плагином. Когда он заканчивает w3af запускает audit-плагины, передавая им ссылки найденные при помощи пользователя. Вот простой пример работы с этим плагином: Теперь пользователь настраивает браузер на использование прокси-сервера по адресу 127.0.0.1:44444 и начинает бродить по сайту, после чего он проходит по ссылке "http://127.7.7.7/spiderMan?terminate", чем завершает работу spiderMan. Вот результат: Эксплуатация найденных уязвимостей Существует два пути использования уязвимостей. Первый заключается в том чтобы дождаться фазы аудита, а второй в том чтобы вызывать exploit-плагин напрямую, указывая нужные ему параметры. Давайте посмотрим на пример первого пути - эксплуатации уязвимостей автоматическими механизмами w3af: Второй путь заключается в том чтобы вручную запустить exploit-плагин. Данный метод может пригодится когда пользователь самостоятельно нашёл уязвимость, но её эксплуатацию по каким-то причинам хочет провести с помощью фреймворка. Продвинутая техника эксплуатации уязвимостей В фреймворке реализует две продвинутые техники использования уязвимостей. Они основаны на возможности фреймворка выполнять удалённо команды системы с помощью плагинов "remoteFileIncludeShell" и "davShell". Эти техники основаны на: Виртуальном демоне позволяющем выполнять код, сгенерированный Metasploit`ом, на удалённом сервере. w3afAgent, позволяющем создать SOCKS-прокси на удалённом сервере. Обе из них просты в использовании и настройке. Но они пока что плохо проработаны и не факт что у Вас будут работать стабильно. В случае их использования Вы действуйте на свой страх и риск.
Виртуальный демон Как было сказано выше, эта техника позволяет Вам выполнять код сгенерированный Metasploit`ом для компрометации атакуемого сервера. Чтобы её использовать требуется иметь на машине установленным Metasploit Framework версии 3.0 и выше. Вы можете скачать его бесплатно на сайте www.metasploit.com. Установка и настройка MSF выходят за пределы этого документа. Для активации использования виртуального демона Вам нужно запустить следующую команду, скопировав прежде metasploit-модуль w3af в директорию MSF: Где "/home/jdoe/tools/msf/" это директория куда пользователь "jdoe" установил Metasploit. Далее скопируйте модуль для работы с MSF в его специальную директорию. Как только это сделано, атакующий может начинать пользоваться виртуальным демоном. Для того чтобы Вы поняли как это делается рассмотрим следующий пример: 1. w3af нашёл уязвимость которая позволяет удалённо выполнять команды ОС на атакуемом сервере 2. Взломщик, через использование этой уязвимости, запускает виртуальный демон. 3. Запускает MSF 4. Настраивает модуль w3af, находящийся внутри MSF и выполняет его 5. w3af-модуль внутри MSF соединяется с виртуальным демоном который прослушивает определённый порт на localhost`е. 6. MSF посылает код, выбранный пользователем, виртуальному демону. 7. Демон создаёт PE или ELF — файл, в зависимости от удалённой операционной системы, и с использованием уязвимости этот код загружается на атакованный сервер и выполняется. 8. Процесс загрузки файла на сервер зависит от удалённой операционной системы, привилегий пользователя запустившего w3af и локальной ОС. Далее происходит следующее: 1. w3af посылает небольшой исполняемый файл удалённому серверу. 2. Затем фреймворк получает имя сетевого интерфейса ( misc-settings -> interface ) и отсылает на определённые порты несколько пакетов. Так он определяет разрешены ли такие соединения файрволом удалённой сети. 3. Если какой-либо TCP-порт оказывается разрешённым, w3af пытается запустить сервер на этом порту и осуществляет back-connect с удалённого хоста для загрузки сгенерированного PE/ELF — файла. Если такого порта нет то w3af записывает PE/ELF – файл используя команду «echo». Этот способ самый медленный, но он всегда работает. 9. Загруженный код выполняется на удалённом сервере и соединяется с MSF. Теперь, когда мы знаем этот процесс в теории, давайте рассмотрим иллюстрацию практического примера. Ничего особенного. Только добавилась новая команда «start daemon». Этот пример отражает пункты 1 и 2 из теоретической части. Следующая часть — конфигурация MSF-модуля и его запуск. Я больше предпочитаю веб-интерфейс «msfweb». Первым делом нужно выбрать пункт «Exploit» в главном меню. Появится маленькое окошко в котором Вы должны произвести поиск по выражению «w3af» и выбрать эксплоит с именем “w3af virtual daemon exploit”. Несколько важных особенностей которые Вы должны знать при настройке «w3af agent virtual daemon module» в MSF: 1. В качестве цели должна быть указана именно та система с которой Вы работаете. 2. Не работать с VNC (скорее всего это переведено неверно, вот исходное выражение «VNC payloads don't seem to work») 3. RHOST - параметр должен содержать IP атакуемого хоста 4. LHOST - это Ваш внешний IP-адрес 5. LPORT — это порт на Вашей машине, куда удалённый веб-сервер может подключится. Или куда можете обращатся Вы. 6. w3af-модуль внутри MSF соединится с адресом localhost:9091 и произведёт передачу данных. Этот параметр не может быть изменён и не должен совпадать с LHOST и LPORT. Когда всё это будет настроено мы можем кликнуть по кнопке «Launch Exploit». Вот что мы при этом увидим в консоли w3af: Последнее сообщение выведется только если Вы запускали w3af как обычный пользователь. Причина проста — не хватает прав на то чтобы произвести сканирование. Удачная попытка сканирования выглядит вот так: И если мы теперь посмотрим на веб-интерфейс MSF то увидим там что ни будь интересное типа : Теперь пользователь имеет интерактивный шелл с привилегиями веб-сервера без всяческих ограничений. На этом этапе можно закрыть w3af и продолжить работу только с MSF.
w3afAgent Как уже было сказано, w3afAgent позволяет создать SOCKS-прокси (в оригинальном тексте он именуется как "туннель для проведения TCP-соединений через атакованный сервер", но ниже пишется прямо - SOCKS-proxy - п.п.). В отличие от виртуального демона w3afAgent не требует установки стороннего софта. Перед тем как рассмотреть пример использования этой технологии, мы теоретический алгоритм работы с ним. 1. w3af находит уязвимость удалённого выполнения команд 2. Пользователь запускает w3afAgent 3. w3af посылает небольшой исполняемый файл на удалённый сервер. После выполнения он соединяется с w3af и позволяет фреймворку проверить правила файрвола для исходящих соединений. 4. w3afAgent Manager загружает w3afAgentClient на удалённый сервер. Процесс загрузки файла на удалённый сервер зависит от типа удалённой ОС, привилегий под которыми запущен w3af и типа локальной ОС. Затем происходит следующее 1. w3af берёт информацию из первого сканирования, которое про ходило в шаге 3 для того чтобы узнать какой порт можно использовать для соединения с атакованным сервером. 2. Если TCP-порт найден, w3af попытается запустить сервер на нём и сделать обратное соединение для скачивания PE/ELF файла. Если ни один ТСР-порт недоступен, w3af загружает PE/ELF-файл на удалённый сервер с помощью команды "echo". Этот способ самый медленный, но всегда срабатывает. 5. w3afAgent Manager запускает w3afAgentServer на локальном хосте, порт 1080. И на интерфейсе указанном в misc-settings->interface, на порту который был найден в 3 шаге. 6. The w3afAgentClient осуществляет обратное соединение к w3afAgentServer и создаёт туннель 7. Пользователь настраивает нужные программы на работу с SOCKS-прокси по адресу localhost:1080 8. Когда программы будут соединятся с прокси-сервером весь трафик будет идти через атакованный сервер. Вот пример практической реализации: Ничего нового. Мы настроили фреймворк, запустили сканирование и нашли уязвимость. Последнее сообщение показано потому что w3af запущен под правами обычного пользователя и сканирование не может быть произведено. Отчёт об удачном сканировании выглядит примерно так: Дальше, в обоих случаях (при запуске с правами обычного пользователя и супер- пользователя), Вы должны увидеть описание следующих шагов: И теперь из другой консоли мы можем использовать socksClient для проведения соединений через атакованный сервер: Дополнительная информация Дополнительная информация о фреймворке типа HOWTO, продвинутое использование, ошибки, TODO-list и новости, могут быть найдены на домашней странице проекта: http://w3af.sf.net/ Проект w3af имеет 2 листа рассылок - один для пользователей, второй для разработчиков. Если у Вас есть какие-то вопросы или комментарии по фреймворку то обращайтесь в эти рассылки: http://sourceforge.net/mail/?group_id=170274 Ошибки и недоработки Фреймворк находится в стадии развития и имеет множество ошибок и недоработок. Если Вы скачали последнюю его версию и нашли в ней какую-то ошибку, то сообщите пожалуйста нам с описанием всех деталей. Для этого обратитесь сюда: http://sourceforge.net/tracker/?group_id=170274&atid=853652 Помощники Мною всегда приветствуется помощь сторонних разработчиков. В ближайшее время будет написано руководство разработчиков по написанию плагинов. Для того чтобы узнать список ошибок и TODO-лист смотрите пожалуйста следующую ссылку: http://sourceforge.net/pm/?group_id=170274 Последнее слово Этот документ лишь простое введение во фреймворк. Полные знания по нему могут быть получены только при непосредственной работе с ним. Делайте ошибки, учитесь на них и с каждым шагом становитесь всё умнее.
