1. Зміст статті Проект w3af сильно виділяється серед багатьох інших інструментів для дослідження безпеки...
2. Що таке w3af?
3. Як влаштований w3af?
4. Скануємо веб-додаток
5. холодний запуск
6. Пентестінг веб 2.0
7. ручне тестування
8. Outro

Зміст статті

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

WARNING

Інформація представлена ​​виключно для ознайомлення. Редакція не несе відповідальності за її використання в протизаконних цілях. Подібні дії тягнуть за собою кримінальне переслідування.

Що таке w3af?

Сучасні веб-додатки вже мало чим схожі на своїх попередників, які були в ходу ще п'ять років тому. Вони стають все більш популярними, використовують набагато більше технологій, що збільшує можливий вектор атаки, обробляють все більше різної інформації, включаючи фінансові та персональні дані. Щоб знизити ризики безпеки, ми можемо впровадити процес безпечної розробки програмного забезпечення (так званий SDL), важливим етапом якого є тестування безпеки. Умовно кажучи, можна виділити чотири види тестування безпеки веб-додатки:

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

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

Головне вікно w3af

Як влаштований 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

Скануємо веб-додаток

Тепер, коли ми трохи розібралися з архітектурою 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?

Результати сканування w3af

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

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

Використання проксі-утиліти в w3af

Для наших цілей будемо використовувати 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-ін'єкція. 🙂 Як ти вже здогадався, це запускаються все ті ж плагіни, які ти вибираєш при звичайному скануванні.

Отримуємо шелл через 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.

Утиліта зі складу w3af для порівняння HTTP-транзакцій