Привет, Codeby!
Немного о том, как были найдены пара простых уязвимостей в ходе Bug Bounty.
Я решил не соваться на
Нашел
Как это получилось и почему это заслуживает интереса.
Я просто фаззил сначала директории, потом файлы, потом параметры в URL. Обычно при таком фаззинге выполняются GET-запросы. Если бы я при фаззинге выполнял только GET-запросы, то это ничего мне не дало бы. Не знаю, что меня сподвигло, но я решил пофаззить все тоже самое POST-запросами.
В том месте, где GET-запрос возвращал мне ответ от сервера 404, метод POST возвратил мне ответ 500. То есть если я запрашивал URL -
Я стал подставлять в значение параметра
1. Если отправляем запрос на сервер с несуществующим IP, то ответ от сервера приходит через 21 секунду:
2. Если IP существует во внутренней сети, то ответ приходит значительно быстрее:
3. Можем сканировать порты, как будто бы мы находимся во внутренней сети. Если порт закрыт, то ответ приходит в течение 1.2-1.4 секунды:
4. Если порт открыт, ответ приходит быстро:
5. Можем поискать подсети:
6. Есть:
7. Можем сканировать порты в машинах, находящихся в подсетях. Тут порт закрыт:
8. Тут порт открыт:
Других возможностей эксплуатации этой уязвимости я не нашел в этом случае. Хотя, если вы немного почитаете о SSRF, то найдете, что уязвимость может привести к RCE.
Суть всей заметки выше не в самой уязвимости, а в том, как она была обнаружена. Если бы я не стал фаззить директории методом POST, то и не узнал бы о баге. Денег за это я не получил, так как уязвимость справедливо посчитали слабой, но накинули 5 баллов к рейтингу )
Затем, исследуя домены той же компании, я нашел у них такой адрес:
Запустил сканер уязвимостей в OWASP ZAP, на который особо и не расчитывал. Но он внезапно нашел там путь, по которому была уязвимость CRLF.
В тот момент я видел там только CRLF, поэтому снова полез в гугл, а заодно и во строенные инструменты браузера, чтобы понять, что происходит.
Если мы перейдем на страницу
Только к нашему
Это значит, что мы можем сами установить любые заголовки от имени сервера.
Чем может грозить, я выше приводил ссылку.
А что там внутри html?
Наш текст помещается внутрь js-скрипта. Попробуем встроить туда свой код:
Получилась XSS:
Я, конечно, написал производителю ПО, но производитель ответил, что они скоро прекратят поддержку этой версии приложения, на том я и закончил )
А прежде, чем я сообщил об уязвимости компании, в BB которой я принимал участие, компания уже закрыла уязвимость своими силами, так что ничего я за это не получил. Только опыт ))
Всем пока.
Немного о том, как были найдены пара простых уязвимостей в ходе Bug Bounty.
Я решил не соваться на
Ссылка скрыта от гостей
, а зарегистрировался на платформе попроще и поменьше, называется
Ссылка скрыта от гостей
, которая ориентирована на европейские компании. Выбрал цель и в первом же домене, который начал исследовать, нашел уязвимость.Нашел
Ссылка скрыта от гостей
, на тот момент даже не зная, что это такое.
Как это получилось и почему это заслуживает интереса.
Я просто фаззил сначала директории, потом файлы, потом параметры в URL. Обычно при таком фаззинге выполняются GET-запросы. Если бы я при фаззинге выполнял только GET-запросы, то это ничего мне не дало бы. Не знаю, что меня сподвигло, но я решил пофаззить все тоже самое POST-запросами.
В том месте, где GET-запрос возвращал мне ответ от сервера 404, метод POST возвратил мне ответ 500. То есть если я запрашивал URL -
http://domen.com/image, то приходил ответ, что такого файла или пути не существует. Если делал этот же запрос, но менял значение метода с GET на POST, то приходила ошибка Internal Server Error с кодом 500. Я начал копать в сторону поиска параметров для POST-запроса. Изфаззил кучу словарей, пробовал отправлять и XML, и JSON, и в них тоже фаззил параметры. Потратил на это несколько дней и ночей, и ничего не получил. Тогда я решил вернуться к запросу GET (вы помните, он возвращал ответ 404) и тоже стал фаззить его параметры. Я не помню (прошло уже больше года), как заметил, но таки заметил, что параметр url ведет себя не обычно. Поэтому далее я стал фаззить значения этого параметра. Оказалось, что если в значение подставить localhost, то ответ от сервера приходит значительно дольше, чем если значение параметра любое другое. При этом код ответа оставался 404(!). На этом моменте я полез в гугл и узнал от такой уязвимости, как SSRF. Тут можете посмотреть презентацию на
Ссылка скрыта от гостей
.Я стал подставлять в значение параметра
url разные ip-адреса и получил кое-какой результат (ниже скрины, которые я отправлял в репорте в программе BB. Уязвимость на сегодняшний день закрыта, поэтому не затираю адрес):1. Если отправляем запрос на сервер с несуществующим IP, то ответ от сервера приходит через 21 секунду:
2. Если IP существует во внутренней сети, то ответ приходит значительно быстрее:
3. Можем сканировать порты, как будто бы мы находимся во внутренней сети. Если порт закрыт, то ответ приходит в течение 1.2-1.4 секунды:
4. Если порт открыт, ответ приходит быстро:
5. Можем поискать подсети:
6. Есть:
7. Можем сканировать порты в машинах, находящихся в подсетях. Тут порт закрыт:
8. Тут порт открыт:
Других возможностей эксплуатации этой уязвимости я не нашел в этом случае. Хотя, если вы немного почитаете о SSRF, то найдете, что уязвимость может привести к RCE.
Суть всей заметки выше не в самой уязвимости, а в том, как она была обнаружена. Если бы я не стал фаззить директории методом POST, то и не узнал бы о баге. Денег за это я не получил, так как уязвимость справедливо посчитали слабой, но накинули 5 баллов к рейтингу )
Затем, исследуя домены той же компании, я нашел у них такой адрес:
Ссылка скрыта от гостей
.Запустил сканер уязвимостей в OWASP ZAP, на который особо и не расчитывал. Но он внезапно нашел там путь, по которому была уязвимость CRLF.
Проверил прямо сейчас этот сервис на другом домене, ZAP нашел не только CRLF, но и XSS
В тот момент я видел там только CRLF, поэтому снова полез в гугл, а заодно и во строенные инструменты браузера, чтобы понять, что происходит.
Если мы перейдем на страницу
Ссылка скрыта от гостей
, и просмотрим заголовки запроса, то увидим в Content-Disposition почти тоже самое, что и в строке запроса:
Только к нашему
xyz добавляется расширение .html. Если попробуем добавить после xyz символы переноса строки и возврата коретки - \r\n\ - то получим немного другой ответ от сервера:
\r\n в формате URL - %0D%0AЭто значит, что мы можем сами установить любые заголовки от имени сервера.
Чем может грозить, я выше приводил ссылку.
А что там внутри html?
Наш текст помещается внутрь js-скрипта. Попробуем встроить туда свой код:
Получилась XSS:
Я, конечно, написал производителю ПО, но производитель ответил, что они скоро прекратят поддержку этой версии приложения, на том я и закончил )
А прежде, чем я сообщил об уязвимости компании, в BB которой я принимал участие, компания уже закрыла уязвимость своими силами, так что ничего я за это не получил. Только опыт ))
Всем пока.
Последнее редактирование модератором:
