Тестируем безопасность веб-приложения с помощью w3af

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

Что такое w3af?

Современные веб-приложения уже мало чем похожи на своих предшественников, которые были в ходу еще пять лет назад. Они становятся всё более популярными, используют намного больше технологий, что увеличивает возможный вектор атаки, обрабатывают всё больше разной информации, включая финансовые и персональные данные. Чтобы снизить риски безопасности, мы можем внедрить процесс безопасной разработки программного обеспечения (так называемый SDL), важным этапом которого является тестирование безопасности. Условно говоря, можно выделить четыре вида тестирования безопасности веб-приложения:

1. Автоматизированное сканирование на уязвимости.
2. Ручное тестирование безопасности (пентестинг).
3. Статический анализ кода.
4. Аудит кода.

Сегодня я хочу рассказать о проекте w3af. Это фреймворк для тестирования безопасности веб-приложения (Web Application Attack and Audit Framework), который может быть использован для первых двух видов тестирования. Автором этого открытого проекта является Андреас Рианчо из Аргентины. Разработкой проекта сейчас занимается в основном он вместе с группой контрибьюторов со всего мира. Фреймворк w3af написан на Python, который, как ты знаешь, является «языком с батарейками». Батарейки w3af — это его расширения, которых набралось уже больше сотни. Это, конечно, еще не Mozilla Firefox, но уже достаточно мощное средство.

Другие статьи в выпуске:

Хакер #158. Взломать Wi-Fi за 10 часов

• Содержание выпуска
• Подписка на «Хакер»-60%

Как устроен w3af?

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

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

1. Плагины для поиска возможных точек входа в приложение (или так называемые discovery-плагины) собирают формы, ссылки и вообще всё, что может сгенерировать запрос к веб-приложению. Таким образом формируется карта запросов тестируемого приложения. Хорошим примером такого плагина является классический веб-паук, реализованный в виде модуля webSpider. Discovery-плагины запускаются в цикле, благодаря чему цели, обнаруженные на предыдущем этапе, попадают на вход этих же плагинов на следующем этапе. Этот процесс продолжается до тех пор, пока не будет достигнут лимит, установленный для режима поиска целей для фаззинга.
2. Аудит-плагины используют вывод плагинов (то есть точки входа в приложение), чтобы обнаруживать цели для поиска уязвимостей, которые позволяют осуществить такие атаки, как XSS, SQL-инъекция, (R)LFI и множество других.
3. Grep-плагины просты, но в тоже время очень полезны, как и известная UNIX-утилита, в честь которой они названы. Смысл такой: через grep-плагин проходит каждая пара HTTP-запрос/ответ, в которой производится поиск интересующей нас информации (номера кредитных карт, внутренние IP-адреса, адреса электронной почты и т. п.). Эти плагины также умеют искать участки потенциально опасного JavaScript-кода, например:

   document.write
   document.location
   eval
   ...
   

   Подобные участки кода часто создают предпосылки для реализации атак вида DOM based XSS.

4. Bruteforce-плагины, как можно догадаться, производят перебор значений для механизмов аутентификации HTTP Basic и для обычной формы для логина. Например, плагин formLogin автоматически детектирует формы входа по содержанию в них двух параметров, один из которых имеет тип password. После обнаружения такой формы сразу начинается брут.
5. Attack-плагины предназначены не для поиска брешей, а для их эксплуатации. Они, как и другие аддоны, используют общую базу знаний о тестируемом приложении, в частности, они используют информацию о найденных уязвимостях и пытаются их проэксплуатировать. Да-да, именно эти плагины могут помочь добыть заветный шелл на бажном сервере. 😉
6. Mangle-плагины позволяют на лету менять что-нибудь в запросах к веб-приложению и его ответах. Если опять провести аналогию с миром UNIX, это фактически эквивалент текстового потокового редактора sed, но уже для HTTP-транзакций. Заменить во всех ответах hidden-поля на обычные текстовые? Пожалуйста!
7. Evasion-плагины используются для обхода простых правил различных IDS. Хочешь подольше остаться незамеченным при проведении очередного пентеста веб-приложения? Тогда используй что-нибудь из этого набора.
8. Output-плагины выполняют простую миссию: формируют в удобочитаемом виде отчеты о результатах работы w3af. Выбирай, что тебе больше подходит, — «православный» текстовый формат или «энтерпрайзный» PDF — или по-быстрому напиши более подходящий для твоих нужд плагин.
9. Auth-плагины берут на себя весь процесс управления пользовательской сессией: авторизируются в веб-приложении, проверяют, чтобы сессия оставалась валидной, и выполняют в конце сканирования корректный выход из веб-приложения. Это очень удобно. Ещё совсем недавно не было удобной возможности сканировать пользовательские части веб-приложений, то есть те, что находятся за авторизацией. Да, можно было указать w3af использовать предварительно полученную из браузера куку, но это не самый удобный способ. Сейчас в составе w3af всего один auth-плагин, но он подойдёт для большинства случаев. Да и не забывай, что мы имеем дело с фреймворком, и можно написать такой плагин практически для любой формы аутентификации: SMS, токены и т.п. У тебя в руках вся мощь Python!

Сканируем веб-приложение

Теперь, когда мы немного разобрались с архитектурой w3af, настало время увидеть его в действии. Специально для демонстрации я написал простое, но очень «вебдванольное» приложение социальной направленности под названием Itter. Да, это сервис для ведения микроблогов, и, я надеюсь, он станет таким же популярным, как его ограниченный 140 символами на одно сообщение старший брат. 🙂 Тестовое веб-приложение обладает следующими свойствами:

• основано на LAMP (Linux-Apache-MySQL-PHP);
• имеет функцию поиска и сервис приватных сообщений;
• полноценный доступ к функционалу приложения предоставляется только зарегистрированным и авторизованным пользователям;
• активно использует AJAX;
• имеет, черт побери, уязвимости!

Холодный запуск

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

• gtkUi — графический, основанный на тулките GTK;
• consoleUi — хакерский UI для консольных старожилов (конечно же, с удобным автозавершением команд).

Будем использовать первый из них. Для запуска GUI-версии набираем в консоли «./w3af_gui» и видим что-то похожее на изображенное на скриншоте 1. Главное окно разделено на несколько секций: профиль, цель, плагины и тулбар. Немного расскажу о профилях.

Как можно догадаться, это именованные наборы настроек, которые можно загружать в w3af. По сути, это ini-файлы, в которых ты можешь сохранять полюбившуюся тебе конфигурацию w3af, в том числе тестируемый URL, выбранные и настроенные плагины, core-настройки и многое другое. Например, для сканирования Itter я создал простой профиль под названием My Profile, далее подключил в нем discovery-плагины webSpider и pykto (порт знаменитого Nikto на Python), пару grep-плагинов для поиска DOM XSS и несколько плагинов для поиска XSS- и SQL-инъекций. Чтобы начать сканирование, нажимаем Start и ждем несколько минут, пока не появятся первые результаты. Кстати, мы всегда можем наблюдать за действиями w3af на вкладке Log, куда в реальном времени выводятся информационные сообщения от ядра и плагинов. Ход процесса отображается через прогресс-бар и другие идентификаторы.

Примерно через 20 минут сканирование завершается. Посмотрим, что удалось найти w3af. Помимо ошибок конфигурации Апача и кучи подозрений на DOM XSS, сканер обнаружил несколько XSS! Одна из них, в /index.php, представляет для нас особый интерес, остальные мы пока отложим. Плагин Pykto, в свою очередь, обнаружил доступную страницу статуса Apache и phpinfo-скрипт /test.php. Другие плагины установили название и версию используемого веб-сервера и веб-фреймворка. В нашем случае это Apache/2.2.16 на Debian GNU/Linux и язык программировани PHP. Другая полезная фишка, которая позволяет нам лучше понять структуру веб-приложения, — это вкладка URLs с древовидной картой веб-приложения и ее графическим представлением. Здесь же можно просмотреть все HTTP-транзакции, сгенерированные в рамках сканирования.

Пентестинг веб 2.0

Сейчас уже никого не удивишь играми, графическим редактором или видеозвонками через веб-браузер. Неотъемлемой частью интернета стали веб-приложения, в которых логика выполнения запрограммирована на стороне клиента с активным использованием JavaScript, AJAX, JSON, HTML5 и других названий и аббревиатур. 🙂 Такой насыщенный комплекс технологий всё сильнее затрудняет автоматизированное тестирование безопасности веб-приложений. Прошли былые времена. Это история уже не о тестировании обычного веб-сайта с множеством страниц вида /article.php?id=68, на которых, в свою очередь, есть множество ссылок, форм и тому подобного «мяса» для веб-паука. Нажав, как обычно, Ctrl-U, чтобы посмотреть HTML-код, ты увидишь месиво из огромного куска JavaScript и немного традиционного HTML. Подобный «сайт» очень часто не по зубам веб-пауку, построенному по классической модели. Это вообще очень интересное направление для развития средств тестирования безопасности веб-приложений. Ведь непонятно, как в такой ситуации автоматизированно обойти весь сайт — встраивать полноценные JS и рендеринг-движки? Использовать подход, подобный Selenium/WebDriver?

Для тестирования подобных приложений не обойтись без специализированных прокси, таких как OWASP WebScarab и Burp Suite, или даже популярного аддона к Firefox — Tamper Data. Такие «пользовательские прокси» позволяют в реальном времени отслеживать (и даже изменять) HTTP-трафик между веб-браузером и веб-сервером. Конечно, подобный инструмент есть и в комплекте w3af. Вернее, таких прокси в нем целых две:

• discovery-плагин spiderMan;
• интерактивный инструмент Intercepting Proxy для ручного тестирования.

Для наших целей будем использовать spiderMan, который, как мы уже разобрались, представляет собой discovery-плагин. Попробуем его в деле. Подключаем плагин в главном окне и запускаем сканирование. В веб-браузере в качестве прокси прописываем 127.0.0.1:44444 (я использую для этого аддон для Firefox, позволяющий легко управлять проксями и переключаться между ними). SpiderMan будет запущен до webSpider, так что последний сможет использовать его результаты. Переключившись на spiderMan в нашем браузере, немного полазаем по тестируемому веб-приложению. В Log-табе видим:

[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.

Как видно из лога, чтобы остановить работу spiderMan, необходимо перейти на специальный адрес, после чего webSpider и другие плагины примутся за дело. Так, аудит-плагины обнаружили SQL- и XSS-инъекцию! Первая дыра, оказавшаяся как раз в AJAX-запросе, была упущена во время первого сканирования.

Добавлю немного про эксплуатацию найденных багов. W3af умеет эксплуатировать некоторые виды уязвимостей и, к примеру, может предоставить тебе заветный шелл на целевой машине. Для эксплуатации обнаруженной уязвимости надо просто перетащить соответствующий эксплоит на вкладке Exploit на уязвимость. Для эксплуатации SQL-инъекций используется наверняка знакомый тебе sqlmap, встроенный в w3af.

Ручное тестирование

Отправить HTTP-запрос в нормальной операционной системе можно с помощью множества способов: Telnet, cURL, Wget, Python + urllib, в конце концов, 🙂 — выбирай, что больше по душе. В w3af для этого предусмотрены специальные удобные инструменты. Послать пачку однотипных HTTP-запросов с разными значениями одного из параметров? Пожалуйста! Генерировать соответствующие токены можно на том же Python. С помощью редактора HTTP-запросов, в котором есть даже простая подсветка HTTP-синтаксиса, можно отправлять одиночные запросы. Часто возникает необходимость выполнить кодирование какой-нибудь строки в URL или просто посчитать MD5-сумму. Конечно, можно быстро набрать «echo -n "admin" | md5sum» в консоли, но использовать для этого встроенный кодировщик немного удобнее. При раскрутке очередной слепой SQL-инъекции важно различать между собой ответы веб-сервера, для чего тебе наверняка пригодится встроенный diff. Ну и наконец, если ты «вайтхат» или просто аудитор безопасности, то заказчику пентеста надо показать, как «работает» уязвимость, используя возможность экспорта запросов в форматы HTML, AJAX и Python. Иными словами, можно сказать: «Откройте вот эту форму, нажмите „Сабмит“ и смотрите, как появляется JS-сообщение…»

Рассмотрим типичный сценарий использования этих инструментов. Запускаем прокси и шаримся по исследуемому веб-приложению (не забываем включить проксирование трафика в браузере). На вкладке History видим отображаемый в реальном времени HTTP-трафик между браузером и сервером. В случае с более мощным приложением, например чатом, транзакций будет значительно больше. В такой ситуации как нельзя кстати будет хороший фильтр: с его помощью можно, к примеру, выводить только транзакции с такими запросами, которые содержат параметры в строке «Запросы» и на которые был получен 2xx-й ответ.

Вернемся к нашему приложению. Во время навигации по нему замечаем, что при наведении на аватар пользователя появляется всплывающее «окно» с информацией об этом пользователе. Эта информация выдается в результате обычного AJAX-запроса к /user-info.php?id=1, что видно в истории запросов. Давай протестируем этот скрипт на уязвимости. Для нашего запроса в меню выбираем «Audit request with...» — нас интересует, есть ли там SQL-инъекция. Бинго! Обнаружена классическая SQL-инъекция. 🙂 Как ты уже догадался, это запускаются всё те же плагины, которые ты выбираешь при обычном сканировании.

Для поиска «слепых» скулей тоже есть специальные плагины. Выключим вывод ошибок в настройках PHP и попробуем задетектить тот же баг, но уже вслепую. С помощью HTTP-редактора посылаем пару запросов к нашему веб-приложению: /user-info.php?id=1 и /user-info.php?id=1%2b1, а затем передаем результаты средству для сравнения транзакций. В результате при выполнении SQL-запроса срабатывает простейшее алгебраическое выражение, и мы получаем два разных ответа (информация для разных пользователей). Дальнейшим шагом может стать всё та же эксплуатация скули.

Outro

W3af — это действительно мощный фреймворк для тестирования безопасности веб-приложений. Рассказывать о нем можно долго, поэтому я ставил перед собой задачу показать его в действии. Важно, что это не просто очередной сканер безопасности, а именно фреймворк, большое количество дополнений тому доказательство. К тому же для человека, на базовом уровне знающего веб и Python, не составит труда добавить недостающий функционал или проверку. Кстати, как и любому свободному проекту, w3af нужны новые разработчики, тестировщики и просто активные пользователи. Кого это заинтересовало, добро пожаловать в соответствующий список рассылки (w3af.sourceforge.net) либо на IRC-канал #w3af в сети Freenode.