2022-06-11 19:29:59
OWASP ZAP та Burp SuiteМи з вами поговорили про nmap, про те як з його допомогою аналізувати мережеві сервіси. І знати цю інформацію це дуже круто, а ще краще, знати які дані бігають між клієнтом та сервером! Знати, які запити йдуть на API, наприклад. Бачити весь трафік між клієнтом та сервером.
В цьому допомагають локальні проксі, які ви підіймаєте на локальних портах. Такі проксі приймають трафік, який ви їм кидаєте, і відправляють далі. Це якщо говорити про звичайний проксі-сервер, типу nginx, HAProxy та інші.
Але просто проксі це не цікаво. Я б не сів писати пост, якби питання було тільки в проксі
Що за OWASP ZAP чи Burp Suite?Це інструментарій, який надає не тільки проксі, а й купу інших корисних
(для хакерів) можливостей. В нього входять fuzzing атаки
(про них я ще напишу окремий пост), можливість записувати історію запитів та показувати її в вигляді дерева, пасивне сканування на відомі вразливості та багато іншого — це комбайни у світі тестування вебаплікацій. Про це, навіть, говориться в самій назві одного з них - ZAP (Zed Attack Proxy).
Як виглядає процес на прикладі OWASP ZAP?Ви запускаєте ZAP в себе на машині, та налаштовуєте його проксі на порту 8080, наприклад. Після цього, налаштовуєте свій браузер
(чи не тільки браузер, за допомогою proxychains можна весь трафік перевести) на роботу через проксі. Для цього, в браузерних налаштуваннях вказуєте роботу через проксі 127.0.0.1:8080.
Маючи такі налаштування, ви можете починати переглядати вебаплікацію, шукати різні цікаві місця для можливих атак, а ZAP буде вести історію всіх запитів. Пізніше, ви зможете переглядати цю історію, бачити всі HTTP запити в чистому вигляді.
З історією запитів, які вам цікаві, ви можете їх редагувати. ZAP надає купу зручних інструментів для того, щоб перехоплювати запити, модифікувати їх по вашому бажанню і відсилати далі. А якщо вам треба буде кодувати зміст запиту, наприклад URL Encode-ом чи Base64, то в нього також це все передбачено і дуже зручно робиться в "пару кліків".
Як на практиці використовується ZAP?Змоделюємо ситуацію, коли Frontend розробники витратили час на валідацію та захист даних, які передаються на сервер. Тобто, через форму в браузері, передати якийсь поганий запит не вийде.
Але Backend розробники, вони ті ще ліниві дупи
(суджу по собі, впевнений що є нормальні), не захотіли робити всі валідації в себе, тому що Frontend розробники зробили ж.
В цій ситуації, ми за допомогою ZAP перехоплюємо всі запити на API. Маючи запит в історії, відкриваємо його в редакторі запитів і міняємо зміст на, наприклад, SQL ін'єкцію. Модифікований запит відправляється на сервер і ми отримуємо доступ до бази даних, завдяки цій ін'єкції. А якщо база даних криво налаштована, то і взагалі доступ до всієї машини, але це окрема історія на майбутнє.
Тобто, ZAP виконує роль посередника між клієнтом та сервером, інколи заміняючи клієнта повністю.
Сканери вразливостейВ цих інструментів також є можливість запустити сканери на відомі вразливості. Причому це робиться мишкою, сказати, щоб щось багато треба знати, то ні.
Коли у вас є історія запитів, ви просто вибираєте з неї цікавий endpoint, який має всі ознаки бути вразливим. Після чого, по натиску на "Active Scan", ви просто йдете пити каву. Якщо на цьому endpoint буде щось давно відоме та банальне, ZAP вам про це скаже і ви зможете це використати у своїх цілях.
Де про це можна детальніше почитати?На Hack The Box академії є повноцінний курс, який розбирає ці два інструменти більше детально і надає вам практичні заняття. Посилання на цей курс - https://academy.hackthebox.com/course/preview/using-web-proxies.
ЕпілогЯ зловив себе на думці, що я зараз просто розказую про інструменти, які є у світі зломів. То я оце думаю, може краще піти не з наявних інструментів, які автоматизовують атаки, а про самі атаки розповідати? Спочатку розповісти про LFI, RCE, SSTI, та інші атаки. Як вони концептуально працюють. А потім вже, розповідати про автоматизацію? Що скажете? Чи може вам легше буде йти від інструментів до атак?
1.0K views16:29
W
