W3Af скачать


Работа с W3af в Kali Linux

Это вольный перевод статьи http://pentesterconfessions.blogspot.ru/2007/10/how-to-use-w3af-to-audit-web.html по работе в w3af.

Перевод прислал Entest, спасибо ему, что поделился с нами этим материалом!

Введение

W3af (Web Application Attack and Audit Framework) — это open-source сканер веб-уязвимостей.

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

В данной статье будет описано как осуществить проверку веб-приложения на уязвимости XSS, CSRF и Sqli работая в w3af из под консоли.

Как пользоваться W3af 

Для запуска W3af в консольном виде надо открыть терминал и напечатать:

Для того чтобы посмотреть список всех опций напишем:

И получим:

|-----------------------------------------------------------------------------| | start | Запустить сканирование. | | plugins | Включение и настройка плагинов. | | exploit | Эксплуатировать уязвимость. | | profiles | Показать список и использовать профайлы сканирования. | | cleanup | Очистить перед началом нового сканирования. | |-----------------------------------------------------------------------------| | help | Показать помощь. Наберите: help [команда] , чтобы увидеть | | | больше помощи по конкретной "команде" | | version | Показать информацию о версии w3af. | | keys | Показать сочетания клавиш. | |-----------------------------------------------------------------------------| | http-settings | Задать HTTP настройки фреймворка. | | misc-settings | Изменить остальные настройки w3af. | | target | Настроить целевой URL. | |-----------------------------------------------------------------------------| | back | Вернуться в предыдущее меню. | | exit | Выход из w3af. | |-----------------------------------------------------------------------------| | kb | Просмотреть уязвимости, доступные в Базе Знаний. | |-----------------------------------------------------------------------------|

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

|-----------------------------------------------------------------------------|

| start         | Запустить сканирование.                                     |

| plugins       | Включение и настройка плагинов.                             |

| exploit       | Эксплуатировать уязвимость.                                 |

| profiles      | Показать список и использовать профайлы сканирования.       |

| cleanup       | Очистить перед началом нового сканирования.                 |

|-----------------------------------------------------------------------------|

| help          | Показать помощь. Наберите: help [команда] , чтобы увидеть   |

|               | больше помощи по конкретной "команде"                       |

| version       | Показать информацию о версии w3af.                          |

| keys          | Показать сочетания клавиш.                                  |

|-----------------------------------------------------------------------------|

| http-settings | Задать HTTP настройки фреймворка.                           |

| misc-settings | Изменить остальные настройки w3af.                          |

| target        | Настроить целевой URL.                                      |

|-----------------------------------------------------------------------------|

| back          | Вернуться в предыдущее меню.                                |

| exit          | Выход из w3af.                                              |

|-----------------------------------------------------------------------------|

| kb            | Просмотреть уязвимости, доступные в Базе Знаний.            |

|-----------------------------------------------------------------------------|

Прежде всего надо сказать как настроить w3af для работы.

Для выбора опции достаточно напечатать ее название, для того чтобы вернуться к предыдущему уровню следует напечатать "back".

Если напечатать команду "view" то на экран будет выведен список настраиваемых параметров выбранной опции.

Теперь рассмотрим опцию "target". В ней задается URL для проводимой проверки.

Настройка опций:

w3af>>> target w3af/config:target>>> help

w3af>>> target

w3af/config:target>>> help

Для данной опции доступны следующие параметры:

|-----------------------------------------------------------------------------| | view | Список доступных опций и их значения. | | set | Установить значение параметра. | | save | Сохранить новую конфигурацию. | |-----------------------------------------------------------------------------| | back | Вернуться в предыдущее меню. | | exit | Выйти из w3af. | |-----------------------------------------------------------------------------|

|-----------------------------------------------------------------------------|

| view   | Список доступных опций и их значения.                              |

| set    | Установить значение параметра.                                     |

| save   | Сохранить новую конфигурацию.                                      |

|-----------------------------------------------------------------------------|

| back   | Вернуться в предыдущее меню.                                       |

| exit   | Выйти из w3af.                                                     |

|-----------------------------------------------------------------------------|

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

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

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

w3af/config:target>>> view

Для дальнейшей работы необходимо настроить плагины.

w3af/config:target>>> back w3af>>> plugins w3af/plugins>>> help

w3af/config:target>>> back

w3af>>> plugins

w3af/plugins>>> help

|---------------------------------------------------------------------------------------------------| | list | Список доступных плагинов. | |---------------------------------------------------------------------------------------------------| | back | Перейти к предыдущему меню. | | exit | Выйти из w3af. | |---------------------------------------------------------------------------------------------------| | grep | Просмотр, настройка и включение плагинов grep | | audit | Просмотр, настройка и включение плагинов аудита | | evasion | Просмотр, настройка и включение плагинов уклонения | | crawl | Просмотр, настройка и включение плагинов обхода контента | | auth | Просмотр, настройка и включение плагинов аутентификации | | mangle | Просмотр, настройка и включение плагинов искажения | | output | Просмотр, настройка и включение плагинов вывода | | bruteforce | Просмотр, настройка и включение плагинов брутфорса | | infrastructure | Просмотр, настройка и включение плагинов инфраструктуры | |---------------------------------------------------------------------------------------------------|

|---------------------------------------------------------------------------------------------------|

| list                  | Список доступных плагинов.                                                |

|---------------------------------------------------------------------------------------------------|

| back                  | Перейти к предыдущему меню.                                               |

| exit                  | Выйти из w3af.                                                            |

|---------------------------------------------------------------------------------------------------|

| grep                  | Просмотр, настройка и включение плагинов grep                             |

| audit                 | Просмотр, настройка и включение плагинов аудита                           |

| evasion               | Просмотр, настройка и включение плагинов уклонения                        |

| crawl                 | Просмотр, настройка и включение плагинов обхода контента                  |

| auth                  | Просмотр, настройка и включение плагинов аутентификации                   |

| mangle                | Просмотр, настройка и включение плагинов искажения                        |

| output                | Просмотр, настройка и включение плагинов вывода                           |

| bruteforce            | Просмотр, настройка и включение плагинов брутфорса                        |

| infrastructure        | Просмотр, настройка и включение плагинов инфраструктуры                   |

|---------------------------------------------------------------------------------------------------|

Для аудита веб-приложения нам потребуется настроить как минимум четыре плагина. Audit, crawl, infrastructure и output.

Если мы напечатаем audit, то увидим все доступные настройки для этого плагина, такие как xss, csrf, sql и ldap инъекции и т.д. Кроме этого там также указано какие из настроек в данный момент включены.

Для включения определенных настроек следует напечатать:

w3af/plugins>>> audit xss,csrf,sqli

w3af/plugins>>> audit xss,csrf,sqli

Для выбора всех настроек:

w3af/plugins>>> audit all

w3af/plugins>>> audit all

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

Для этого включим необходимые плагины crawl и output.

w3af/plugins>>> crawl web_spider,pykto w3af/plugins>>> infrastructure hmap w3af/plugins>>> output console,html_file

w3af/plugins>>> crawl web_spider,pykto

w3af/plugins>>> infrastructure hmap

w3af/plugins>>> output console,html_file

Немного информации об используемых плагинах:

Web_spider  — Плагин представляет из себя классического web-паука. Он бродит по сайту и извлекает все ссылки и адреса форм.

Pykto — Плагин представляет из себя сканнер nikto, портированный на python. Он использует базу данных из nikto (scan_database) для поиска уязвимых ссылок.

Hmap — Плагин опознаёт удалённый веб-сервер, его тип, версию и установленные исправления.

Идентификация происходит не только через заголовок "Server". По сути плагин представляет из себя обёртку для hmap Dustin`a Lee.

Console — Этот плагин пишет отчёт о работе фреймворка в консоль.

Html_file — Плагин пишет отчёт о работе фреймворка в HTML-файл.

Для начала аудита выполняем следующие команды:

w3af/plugins>>> back w3af>>> start

w3af/plugins>>> back

w3af>>> start

Сканер работает довольно долго, так что придется запастись терпением. В итоге получим примерно такой отчет:

w3af>>> start Auto-enabling plugin: discovery.allowedMethods Auto-enabling plugin: discovery.error404page Auto-enabling plugin: discovery.serverHeader The Server header for this HTTP server is: Apache/2.2.3 (Ubuntu) PHP/5.2.1 Hmap plugin is starting. Fingerprinting may take a while. The most accurate fingerprint for this HTTP server is: Apache/2.0.55 (Ubuntu) PHP/5.1.2 pykto plugin is using "Apache/2.0.55 (Ubuntu) PHP/5.1.2" as the remote server type. This information was obtained by hmap plugin. pykto plugin found a vulnerability at URL: http://localhost/icons/ . Vulnerability description: Directory indexing is enabled, it should only be enabled for specific directories (if required). If indexing is not used, the /icons directory should be removed. The vulnerability was found in the request with id 128. pykto plugin found a vulnerability at URL: http://localhost/doc/ . Vulnerability description: The /doc directory is browsable. This may be /usr/doc. The vulnerability was found in the request with id 1865. pykto plugin found a vulnerability at URL: http://localhost/> . Vulnerability description: The IBM Web Traffic Express Caching Proxy is vulnerable to Cross Site Scripting (XSS). CA-2000-02. The vulnerability was found in the request with id 3385. New URL found by discovery: http://localhost/ New URL found by discovery: http://localhost/test2.html New URL found by discovery: http://localhost/xst2.html New URL found by discovery: http://localhost/xst.html New URL found by discovery: http://localhost/test.html

w3af>>> start

Auto-enabling plugin: discovery.allowedMethods

Auto-enabling plugin: discovery.error404page

Auto-enabling plugin: discovery.serverHeader

The Server header for this HTTP server is: Apache/2.2.3 (Ubuntu) PHP/5.2.1

Hmap plugin is starting. Fingerprinting may take a while.

The most accurate fingerprint for this HTTP server is: Apache/2.0.55 (Ubuntu) PHP/5.1.2

pykto plugin is using "Apache/2.0.55 (Ubuntu) PHP/5.1.2" as the remote server type. This information was obtained by hmap plugin.

pykto plugin found a vulnerability at URL: http://localhost/icons/ . Vulnerability description: Directory indexing is enabled, it should only be enabled for specific directories (if required). If indexing is not used, the /icons directory should be removed. The vulnerability was found in the request with id 128.

pykto plugin found a vulnerability at URL: http://localhost/doc/ . Vulnerability description: The /doc directory is browsable. This may be /usr/doc. The vulnerability was found in the request with id 1865.

pykto plugin found a vulnerability at URL: http://localhost/> . Vulnerability description: The IBM Web Traffic Express Caching Proxy is vulnerable to Cross Site Scripting (XSS). CA-2000-02. The vulnerability was found in the request with id 3385.

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

New URL found by discovery: http://localhost/test2.html

New URL found by discovery: http://localhost/xst2.html

New URL found by discovery: http://localhost/xst.html

New URL found by discovery: http://localhost/test.html

И результат, сохраненный в results.html:

Спонсор публикаций Cyber-512

Готовим специалиста в области ИБ  - Воспитаем специалиста в области ИБ с нуля до начального уровня. После обучения сможете оказывать услуги по проведению тестирования на проникновение ( легальный хакинг )

codeby.net

Authenticated scans | w3af - Open Source Web Application Security Scanner

w3af supports these types of authentication credentials that a user can provide in order for the scanner to keep a session open to scan the target web application:

  • HTTP Basic authentication
  • NTLM authentication
  • Form authentication
  • Setting an HTTP cookie

HTTP Basic and NTLM authentication are two types of HTTP level authentication usually provided by the web server, while the form and cookie authentication methods are provided by the application itself. It’s up to the user to identify which authentication method is required to keep a session with the application, but usually a quick inspection of the HTTP traffic will define what’s required.

First you’ll have to start w3af’s GUI, from the command line run “w3af_gui” and you should see the main window:

To configure basic or NTLM credentials you need to open the HTTP settings menu. The configuration set in this section will affect all plugins and other core libraries. In the top menu choose “Configuration” and then “HTTP Settings” and a window like this will appear:

Please note the two tabs called “Basic HTTP Authentication” and “NTLM Authentication”. Enter your preferred settings and click save. The scanner is now ready to start an authenticated scan, the next step would be to enable specific plugins and start the scan, for example, you could follow the Find Cross-Site Scriptings and SQL injections howto to finish the scan configuration.

Form authentication has changed significantly in the latest w3af versions. Starting with version 2.0 the form authentication is configured using “auth” plugins. There are two authentication plugins available in the framework:

Authentication plugins are a special type of plugin which is responsible to keep a session alive during the whole scan. These plugins are called before starting the scan (in order to get a fresh session) and once every 5 seconds while the scan is running (to verify if the current session is still alive and create a new one if needed).

This tutorial will explain how to configure the generic authentication plugin which has the following options:

  • username: Web application’s username
  • password: Web application’s password
  • username_field: The name of the username form input that can be found in the login HTML source.
  • password_field: The name of the password form input that can be found in the login HTML source.
  • auth_url: The URL where the username and password are POST’ed to.
  • check_url: The URL that will be used to check if the session is still active, usually this is set to the web application user’s settings page.
  • check_string: A string that if found in the check_url’s HTTP response body proves that the session is still active, usually this is set to a string that can only be found in the user’s settings page, for example his last name.

Once all these settings have been configured, it is recommended to start a test scan only with crawl.web_spider and auth.generic in order to verify that all the post-authentication forms and links are identified. Also, keep an eye on w3af’s log since the authentication plugins will create log entries if there is any issue with the authentication process. Log entries like:

Login success for admin/password User "admin" is currently logged into the application

Are what you would expect to see if the configuration was successful and messages like:

Can't login into web application as admin/password

Show that either the plugin configuration is incorrect, or the application requires more parameters to be sent to the auth_url which in some cases is solved by using the detailed plugin.

Creating new authentication plugins is easy! Custom authentication types can be added by cloning the detailed auth plugin.

For the cases in which the form authentication doesn’t work, which might be related with login forms with anti-CSRF tokens, w3af provides users with a method to set an HTTP cookie to use during the scan. This method will set an HTTP request header which will be added to each HTTP request that’s sent by the framework, note that no verification of the session’s state is made when using this method, if the session is invalidated the scan will continue using the old cookie.

The recommendations for form authentication about blacklisting the application’s logout link apply to this method too, since we want to keep the session alive for the duration of the scan.

In order to use this method you’ll first have to create a text file using your favorite text editor with the following contents: “Cookie: <insert-cookie-here>”, without the quotes and inserting the desired session cookie. Then, in w3af’s main menu open the “Configuration” and “HTTP Settings” and a window like this should appear:

In the headers_file configuration parameter enter the path to the file you just created and click save. The w3af scanner is now configured to use the HTTP session cookie for all HTTP requests.

w3af.org

How-to test web applications with w3af

Intro

Today web applications become more and more popular and process a huge amount of critical information: financial, private and sometimes even military kinds. To mitigate risks in it we can implement secure software development circle and security testing as part of it. There are 4 basic techniques for analyzing the security of a web application:

  • Automated scanning
  • Manual penetration testing
  • Static analysis
  • Manual code review

w3af is an Web Application Attack and Audit Framework and it can be used in the first two activities. It is an open source project (GPLv2) created by Andres Riancho and developed by him and a group of contributors from around the world. w3af is written in Python which as you know very powerful language "with batteries". Batteries of w3af are plugins - it has at least 143 ones!

w3af is divided in two main parts: the core and the plugins. The core coordinates the process and provides features that plugins consume. Plugins find the vulnerabilities and in some cases are able to exploit them! Plugins share information with each other using a knowledge base.

In w3af we have 8 different types of plugins each for various purpose. Discovery plugins finds new URLs, forms, etc. and creates a complete sitemap. webSpider is one of them and is classic example of web spider engine which parses HTTP response and extract links, forms, image sources and so on. Discovery plugins runs in loop - the output of one discovery plugin is sent as input to the next plugin. This process continues until all plugins fail to find a new resource.

Audit plugins takes the output of discovery plugins and find all kinds of vulnerabilities like SQL injection, XSS and others. As I think audit plugins are main in w3af plugins hierarchy.

Grep plugins usually simple but useful, they grep (like the UNIX utility) every HTTP request and response in order to find interesting information. It can be, for example, credit card numbers, private IPs, emails or risky JavaScript code.

Bruteforce plugins bruteforces the HTTP Basic and Form Login authentications that are found during the discovery phase. For example, formLogin plugin automatically detects login forms by finding forms with two parameters, one of them of type text and the other one of type password. Once the username and password fields are identified, the bruteforce starts automatically.

Attack plugins reads the vulnerability objects from the KB and try to exploit them. Yes, these ones can give you the shell ;)

Mangle plugins allows modification of requests and responses based on regular expressions like sed stream editor. Evasion plugins tries to evade simple intrusion detection rules.

Output plugins writes framework messages to different locations (different format files) and usually are used for generating of reports.

Scanning a web application

Well, we have reviewed the architecture of w3af. Now it is time to see w3af in action. Let's scan some web applications! For demonstration purposes I have made a simple but very sociable web application called Itter. Yes, it is micro-blogging service and hope that it will become as popular as twi..OK, it is joke :) This testing web application has following characteristics:

  • LAMP (Linux-Apache-MySQL-PHP) stack
  • search, private messages
  • authentication protected user area
  • usage of AJAX capabilities
  • has vulnerabilities!

Cold Start

For the first we will test our web application without logging-in like "cold start". w3af has 2 user interfaces: one based on GTK toolkit and console UI with auto-complete feature for console hackers. For GUI version simply type in the console ./w3af_gui and you will see something like on the picture:

There are Profile, Plugins, Target sections and Toolbox. Profile is a file where the scan configuration (including target, misc and HTTP settings, enabled plugins) is saved. For testing Itter I have made "My Profile" configuration with webSpider and pykto (python port of famous Nikto tool) to find target URLs, some grep plugins to find anything strange and interesting in HTTP transactions like DOM-based XSS and some audit plugins like XSS and SQLi to find appropriate security holes. Pressing Start button and waiting for the first results. We can monitor scan progress on Log tab - console with application messages, progress bar and time diagram will help us. Scan finished in about 20 minutes and we have the results. Oh, besides server configuration flaws like Apache web server status page and suspicion on DOM-based XSS w3af has found XSS vulnerabilities! Let's discover it. For the first of course XSS flaw - w3af has found it in /index.php and some other scripts.

Pykto plugin has found Apache web server status page and phpinfo() /test.php script. From other plugins we has determined web server name, version and web platform - in our case it are Apache/2.2.16 on Debian GNU/Linux system and PHP as programming language with enabled session mechanism.

Another cool feature which helps us to better understand web application structure is URLs tab with graphical representation of testing web application map and traditional tree-list. By clicking on target point on the map you can zoom it in/out.

Testing web 2.0 applications

Reader, as you knows, everybody now uses a lot of web 2.0 applications with heavy usage of client-side logic, e.g. AJAX: social networks, email web interfaces and so on. Heavy usage of client side scripts (in most cases JavaScript) means big problems for most of the scanners because they need to be more and more like modern web browser with JavaScript engine. One of ways to test such applications is using an intercepting proxy to collect http requests for further testing. w3af has 2 proxies for such purposes. One is Intercepting Proxy tool for manual testing. Another one is spiderMan plugin SpiderMan which collects URLs and can be used in automated scans. Lets try it. I have enabled in case of used profile spiderMan plugin and tune web browser to use 127.0.0.1:44444 as proxy address. FoxyProxy is great proxy management addon for Mozilla Firefox especially when you need to quickly switch between proxies. spiderMan will be run before webSpider so then last one will use its results. After starting navigating web application through spiderMan we will see such messages in Log section:

[Mon 30 May 2011 12:08:22 AM MST] 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 . [Mon 30 May 2011 12:15:29 AM MST] The user is navigating through the spiderMan proxy. [Mon 30 May 2011 12:15:29 AM MST] Trapped fuzzable requests: [Mon 30 May 2011 12:15:29 AM MST] http://localhost/index.php | Method: GET [Mon 30 May 2011 12:15:32 AM MST] http://localhost/user-info.php | Method: GET [Mon 30 May 2011 12:22:36 AM MST] SQL injection in a MySQL database was found at: "http://localhost/user-info.php", using HTTP method GET. The sent data was: "id=d'z"0". This vulnerability was found in the request with id 3911. [Mon 30 May 2011 12:27:10 AM MST] Cross Site Scripting was found at: "http://localhost/index.php", using HTTP method GET. The sent data was: "limit=15&u=<ScRIPT>a=/UzmE/%0Aalert(a.source)</SCRiPT>". The modified parameter was "u". This vulnerability affects ALL browsers. This vulnerability was found in the request with id 4042.

As you can see after stopping usage of spiderMan by navigating to special URL webSpider have found some new targets and audit plugins have found SQL injection and XSS vulnerabilities. The first one in AJAX request.

w3af also has capabilities to exploit some types of vulnerabilities, e.g. even can give you the desired shell on the target system! To exploit the vulnerability, you need to drag the exploit and drop it on the vulnerability you want to exploit. For our example with SQL injection it can be built-in version of famous sqlmap.

Manual testing

w3af has a number of GUI tools for manual work with HTTP transactions. Among them:

  • Sending automated HTTP requests e.g. for explore SQL injection point
  • Manual request editor can be used to send HTTP requests to the remote web server
  • Encode and decode strings: URL encoding, base64, MD5 hash and so on
  • Compare HTTP responses may be useful when you finds blind SQL injection and need to know differences between HTTP responses
  • Intercepting Proxy
  • Export requests

Launching proxy tool starts local proxy server (don't forget, you need to tune you web browser to use it). Navigating through our testing social service. History tab shows us all HTTP transactions between web browser and server. In case of really big applications there will be a lot of items but we can filter it in various ways. For example show only transactions with parametrized request and 2xx response. When mouse pointer hovers over user avatar we see that in background web application sends AJAX request /user-info.php?id=1 to the web server to get user information for pop-up area. It is very interesting! Lets test this page against some vulnerabilities by pressing "Audit request with..." button and selecting sqli. Bingo! We have found a SQL injection! It is classic error based SQL injection. In case of blind SQL injections we can use special blindSQli plugin but lets assume switched off error displaying and try to find it manually. Using Manual request editor sending 2 requests with different ID values: /user-info.php?id=1 and /user-info.php?id=1%2b1, then sending it to Compare tool.

As you can see our algebraic expression works correctly inside SQL interpreter and we get user information for user with ID 2. Further steps can be of course exploitation with w3af's attack plugins or manually.

Outro

Now we have seen w3af in action and it is really powerful tool for security testing of web applications. But framework is not buzzword in the definition of w3af - number of plugins is striking demonstration for it. It is really easy to extend its functionality, you can write your own plugin for various purposes. But it is a good reason for writing the next article.

oxdef.info

Installation — w3af - Web application attack and audit framework 1.7.6 documentation

Prerequisites

Make sure you have the following software ready before starting the installation:

  • Git client: sudo apt-get install git
  • Python 2.7, which is installed by default in most systems
  • Pip version 1.1: sudo apt-get install python-pip

Installation

git clone https://github.com/andresriancho/w3af.git cd w3af/ ./w3af_console . /tmp/w3af_dependency_install.sh

Let me explain what’s going on there:

  • First we use git to download w3af‘s source code
  • Then we try to run the w3af_console command, which will most likely fail because of missing dependencies. This command will generate a helper script at /tmp/w3af_dependency_install.sh that when run will install all the required dependencies.
  • Dependencies are installed by running /tmp/w3af_dependency_install.sh

The framework dependencies don’t change too often, but don’t be alarmed if after updating your installation w3af requires you to install new dependencies.

Supported platforms

The framework should work on all Python supported platforms and has been tested in various Linux distributions, Mac OSX, FreeBSD and OpenBSD.

Note

The platform used for development is Ubuntu 14.04 and running our continuous integration tests is Ubuntu 12.04 LTS.

Warning

While in theory you can install w3af in Microsoft Windows, we don’t recommend nor support that installation process.

One of the ugly details users can find is that w3af needs to detect the Operating System / Linux distribution, and then have support for creating the /tmp/w3af_dependency_install.sh for that specific combination. In other words, for Ubuntu we use apt-get install and for Suse we use yum install.

The list of distributions w3af knows how to generate the installation script for is extensive . If we don’t support your distribution, we’ll default to Ubuntu.

Installation in Kali

The easiest way to install w3af in Kali is:

apt-get update apt-get install -y w3af

This will install the latest packaged version, which might not be the latest available from our repositories. If the latest version is needed these steps are recommended:

cd ~ apt-get update apt-get install -y python-pip w3af pip install --upgrade pip git clone https://github.com/andresriancho/w3af.git cd w3af ./w3af_console . /tmp/w3af_dependency_install.sh

This will install the latest w3af at ~/w3af/w3af_console and leave the packaged version un-touched.

Note

There are two versions in your OS now:
  • cd ~/w3af/ ; ./w3af_console will run the latest version
  • w3af_console will run the one packaged in Kali

Installing using Docker

Docker is awesome, it allows users to run w3af without installing any of it’s dependencies. The only pre-requisite is to install docker , which is widely supported.

Once the docker installation is running these steps will yield a running w3af console:

$ git clone https://github.com/andresriancho/w3af.git $ cd w3af/extras/docker/scripts/ $ sudo ./w3af_console_docker w3af>>>

For advanced usage of w3af‘s docker container please read the documentation at the docker registry hub

Installation in Mac OSX

In order to start the process, you need XCode and MacPorts installed.

sudo xcode-select --install sudo port selfupdate sudo port upgrade outdated sudo port install python27 sudo port select python python27 ./w3af_console . /tmp/w3af_dependency_install.sh

Those commands should allow you to run ./w3af_console again without any issues, in order to run the GUI a new dependency set is required:

./w3af_gui . /tmp/w3af_dependency_install.sh

Troubleshooting

After running the helper script w3af still says I have missing python dependencies, what should I do?

You will recognize this when this message appears: “Your python installation needs the following modules to run w3af”.

First you’ll want to check that all the dependencies are installed. To do that just follow these steps:

$ cd w3af $ ./w3af_console ... Your python installation needs the following modules to run w3af: futures ... $ pip freeze | grep futures futures==2.1.5 $

Replace futures with the library that is missing in your system. If the pip freeze | grep futures command returns an empty result, you’ll need to install the dependency using the /tmp/w3af_dependency_install.sh command. Pay special attention to the output of that command, if installation fails you won’t be able to run w3af.

It is important to notice that w3af requires specific versions of the third-party libraries. The specific versions required at /tmp/w3af_dependency_install.sh need to match the ones you see in the output of pip freeze. If the versions don’t match you can always install a specific version using pip install --upgrade futures==2.1.5.

w3af still says I have missing operating system dependencies, what should I do?

You will recognize this when this message appears: “please install the following operating system packages”.

Most likely you’re using a Linux distribution that w3af doesn’t know how to detect. This doesn’t mean that w3af won’t work with your distribution! It just means that our helper tool doesn’t know how to create the /tmp/w3af_dependency_install.sh script for you.

What you need to do is:

  • Find a match between the Ubuntu package name given in the list and the one

for your distribution * Install it * Run ./w3af_console again. Repeat until fixed

Please create a ticket explaining the packages you installed, your distribution, etc. and we’ll add the code necessary for others to be able to install w3af without going through any manual steps.

How do I ask for support on installation issues?

You can create a ticket containing the following information:

  • Your linux distribution (usually the contents of /etc/lsb-release will be enough)
  • The contents of the /tmp/w3af_dependency_install.sh file
  • The output of pip freeze
  • The output of python --version

docs.w3af.org

описание и статистика / Блог компании Pentestit / Хабрахабр

Пришло время подвести результаты автоматического сканирования, которое было анонсировано 3 недели назад. Было прислано несколько заявок на автоматический аудит, большинство сайтов представляли коммерческий сектор — интернет-магазины и корпоративные сайты.

Выбор инструмента

Для автоматического тестирования был выбран один из самых популярных opensource сканеров уязвимостей — w3af.

w3af или Web Application Attack and Audit Framework — это гибкая платформа для поиска и эксплуатации уязвимостей в веб-приложениях, работает на большинстве современных систем, написан на Python. Этот фреймворк иногда называют «Metasploit для веб».

Для упрощения процесса автоматизированного тестирования была взята консольная версия w3af_console. Как и в GUI версии, где всем управляют профили (состоящие из плагинов), в консольной версии все управление и настройки тоже зависит от подключенных плагинов в так называемом script файле.

Как это работает

Формат запуска настроенного скрипт-файла довольно прост: ./w3af_console ­-s MyScript.w3af Скрипт файл состоит из последовательности подключаемых видов плагинов и их параметров:plugins output console,text_file output output config text_file set output_file report.txt set verbose True back output config console set verbose False back crawl all crawl grep all grep audit all audit bruteforce all bruteforce back target set target http://targethost back start В представленном примере будут собраны все ссылки с сайта targethost, проанализированы запросы и ответы, комментарии, вывод ошибок, проверятся по базе знаний/признаков на наличие распространенных веб-уязвимостей, обнаруженные формы ввода будут подвергнуты bruteforce-атаке (подбор паролей) и результат будет сохранен в файл report.txt с полным выводом работы плагинов.

вывод подключаемых плагинов в ручном режиме в консоли w3af_console

Из чего состоит

В зависимости от типа воздействия существует несколько видов подключаемых плагинов:
  • attack — для реализации атаки, эксплойтинг. В автоматическом аудите не использовались.
  • audit — выявление уязвимостей веб-приложения, содержит плагины для поиска XSS, SQLi, CSRF, LFI, RFI, open redirects и многие другие. Часть плагинов использовалось в автоматическом аудите.
  • auth — плагины для задания параметров авторизации на исследуемом ресурсе. В автоматическом аудите не использовались.
  • bruteforce — плагины для проведения атаки «подбор по словарю» (bruteforce). В автоматическом аудите не использовались.
  • crawl — плагины для поиска и сбора информации, перебора имен файлов и директорий, использования поисковых систем, определения типа CMS, анализа форм для передачи в отделы audit/bruteforce/attack. Часть плагинов использовалось в автоматическом аудите.
  • evasion — плагины для обхода IDS, политик безопасности и WAF. В автоматическом аудите не использовались.
  • grep — плагины для анализа запросов/ответов веб-сервера, поиска критичной информации, вывода ошибок, комментариев в исходном коде и т.д. Часть плагинов использовалось в автоматическом аудите.
  • infrastructure — плагины для анализа настроек сервера, мисконфигураций, виртуальных хостов и т.д. Часть плагинов использовалось в автоматическом аудите.
  • mangle плагины для модификации запросов «на лету». В автоматическом аудите не использовались.
  • output — плагины для вывода и сохранения результатов работы. Часть плагинов использовалось в автоматическом аудите.
Готовые примеры скрипт-файлов под разные вектора атаки и тип воздействия вы можете найти здесь. Их работоспособность можно протестировать в специализированной уязвимой среде moth.

Статистика

Для проведения автоматического аудита был скомпонован script файл для поиска и выявления полной карты сайта, типа CMS, веб-сервера и поиск уязвимостей OWASP TOP-10, настроена система проверки легитимности и компоновки отчетности (резюмирующие рекомендации по найденным уязвимостям добавлялись сотрудниками нашей компании вручную, машина не может проанализировать вектора атаки и составить точный сценарий атаки).

скриншот системы добавления задания на автоскан

Из общего количества сайтов топ-5 по общему объему выявленных уязвимостей выглядит так:

  1. Утечка чувствительных данных — OWASP A6 (sensitive data exposure) — неверные конфигурации сертификатов, сюда же отнесены неправильно настроенные политики HSTS.
  2. Небезопасная конфигурация — OWASP A5 (security misconfiguration) — листинг директорий, настройки по-умолчанию, устаревшие версии ПО.
  3. Использование компонентов с известными уязвимостями — OWASP A9 (using components with known vulnerabilities) — было найдено несколько незакрытых уязвимостей, с доступными публичными эксплоитами.
  4. Межсайтовый скриптинг — OWASP A3 XSS (cross-site scripting) — было найдено несколько пассивных XSS.
  5. Внедрение кода — OWASP A1 (injection) — уязвимости типа SQL-injection все еще достаточно распространены.
Время сканирования ресурсов занимало от 10 минут до 2 суток. Несколько сайтов не выдержали нагрузки и автоматическое тестирование было остановлено до восстановления работоспособности. По всем выявленным уязвимостям были составлены отчеты, содержащие перечисление выявленных уязвимостей, вероятность компрометации веб-приложения и возможный сценарий атаки.

habrahabr.ru


Смотрите также