Приветствую! Нашел себе цель под защитой cloudflare. Сам по себе сайт написан на старом php, имеет дыру XSS reflected. Но XSS мне тут мало чем помог, так как моя цель получить доступ к серверу (initial access). Какие есть техники по нахождению реального IP за cloudflare? Каким образом вообще cloudflare может мешать мне достигнуть моей цели в данном случае? Быть может я в силу малого опыта о чём-то вообще могу не знать? Также есть dev. субдомен, на нём basic auth стоит.
-
XSS.stack #1 – первый литературный журнал от юзеров форума
Помощь с обходом cloudflare
- Автор темы users_h8
- Дата начала
Можешь попробовать посмотреть историю IP адресов у домена, возможно там засветился реальный IP до того как сайт залез под CloudFlare.
Либо поискать суб. домены по сертификату основного, и там посмотреть IP - возможно есть не защищенные.
Либо поискать суб. домены по сертификату основного, и там посмотреть IP - возможно есть не защищенные.
crt.sh | Certificate Search
Free CT Log Certificate Search Tool from Sectigo (formerly Comodo CA)
crt.sh
IP History - ViewDNS.info
Shows a historical list of IP addresses a given domain name has been hosted on as well as where that IP address is geographically located, and the owner of that IP address.
viewdns.info
А админа через XSS поиметь, например, это не доступ к серверу? вдруг админка даёт что-то заливать туда чего рядовому не даёт?
от истории домена на viewdns.info или в архивах, до masscan+httpx по ASN провов, можно просто httpx даже, но c masscan отсечёшь "не вебки" сразу, что сэкономит время.
лучше всех c0d3x написал про эту тему вот тут /threads/82843/page-2#post-583305
иногда вообще никаким если ты "из снайперки", но чаще всего всем мешает WAF и rate limit
это у всех такое же примерно чувство, даже у опытных, открою тайну: матёрые APT группировки и мамкины хакеры используют плюс-минус одни и те же инструменты , просто одни это делают системно и осознанно продвигаясь к цели, а другие бессистемно и хаотично, оттого и разный результат теми же сканерами, Burp и т.д.
мне вон на работе говорили раньше иногда "у тебя что - другой поисковик не как у всех что-ли?!" (нет, я просто "дорки" юзать начал когда слова такого не знали, примерно тогда когда запросы к рамблеру делать начал в 95-98 году вроде, там даже инструкция была "как лучше искать?" - и я не поленился и про язык запросов прочитал, а кто-то поленился просто) , а сейчас говорят "у тебя какая-то крутая нейронка чтоли?!" (кстати юзаю анонимно в приватном окне chatgpt бесплатный ессно через прокси и впн всякие)
это о чём говорит? а лишь о том, что качество ответов людей и систем - напрямую зависит от качества твоих вопросов , а не от "волшебности" какой-то "уникальных" систем и людей.
ну так пробруть basic auth то хотя бы rockou.txt для приличия может, а?
- Автор темы
- Добавить закладку
- #8
Пробовал, но полный перехват куков через document.cookie не получается сделать, httponly на куках стоит
- Автор темы
- Добавить закладку
- #9
Делал брут, пока результатов не дало
зачем перехват куков обязательно? что все на это упираются при XSS?
думай ширше. XSS это на самом деле очень-очень опасная атака, просто "узкая" в пределах клиента (при stored XSS впрочем массовый эффект будет).
ведь у тебя по сути при успехе - полный контроль твоим скриптом над окном браузера жертвы! что угодно любую дичь можно творить!
окна "ваш аккаунт взломан! напишите пароль в техподдержку!" показывать можно, можно BinB (browser-in-browser) атаку производить, любые fetch() и соответственно CSRF - попробовать скрафтить и выполнить от имени админа или юзера запросы к сайту, или к сайтам (вот тут CSRF) где ещё клиент зареган по твоей гипотезе, а ответы себе переслать - у тебя то origin любой будет на твоём серваке, ты эту инфу сможешь принять.
например кейз: XSS на внешнем сайте, пользак ещё до кучи и на внутреннем корпоративном интранет сайте залогинен (браузер хранит креды), причём тебе похер что httpOnly даже - ты можешь fetch() запросы например к корпоративному сайту слать своим скриптом и если там "origin *" условно то они прокатят, а полученный ответ себе fetch() переслать как прокси, у тебя то "origin *" ты точно сможешь сделать на "командном серваке", ну вот и данные клиентов конторы например за ночь и скачаны...
Если с сервера можно запросить письмо на почту(восстановить пароль например), то в теле реальный IP "Возможно" засветится. Раньше работало до 80% доменов так можно было IP узнать.
Да, это сработает иногда с почтой.
Как и любой "отстук" сервера наружу если вдруг можно как-то задать куда ему "отстукивать" он это будет делать с реального IP, ну типа SSRF если там вдруг.
Но с почтой вроде как поумнел народ уже и не палит так IP как правило, либо почтовик вынесен на другой сервак отдельный либо вообще на мэйлган и подобные сервисы.
- Автор темы
- Добавить закладку
- #13
Я вообще не так сильно прошарен в XSS, но идея с CSRF у меня была. Думаю стоит мне глубже погрузиться в этот вопрос. У меня есть только reflected XSS на сайте, по сути в моём случае я могу заставить админа выполнить у себя js только в случае если он откроет ссылку с кодом, вообще думал над письмом с гиперссылкой, насколько вообще на твой взгляд рабочий вариант? Есть какие-то способы обфускации скрипта в ссылке, чтобы JS был вообще нечитаем?зачем перехват куков обязательно? что все на это упираются при XSS?
думай ширше. XSS это на самом деле очень-очень опасная атака, просто "узкая" в пределах клиента (при stored XSS впрочем массовый эффект будет).
ведь у тебя по сути при успехе - полный контроль твоим скриптом над окном браузера жертвы! что угодно любую дичь можно творить!
окна "ваш аккаунт взломан! напишите пароль в техподдержку!" показывать можно, можно BinB (browser-in-browser) атаку производить, любые fetch() и соответственно CSRF - попробовать скрафтить и выполнить от имени админа или юзера запросы к сайту, или к сайтам (вот тут CSRF) где ещё клиент зареган по твоей гипотезе, а ответы себе переслать - у тебя то origin любой будет на твоём серваке, ты эту инфу сможешь принять.
например кейз: XSS на внешнем сайте, пользак ещё до кучи и на внутреннем корпоративном интранет сайте залогинен (браузер хранит креды), причём тебе похер что httpOnly даже - ты можешь fetch() запросы например к корпоративному сайту слать своим скриптом и если там "origin *" условно то они прокатят, а полученный ответ себе fetch() переслать как прокси, у тебя то "origin *" ты точно сможешь сделать на "командном серваке", ну вот и данные клиентов конторы например за ночь и скачаны...
вариант настолько рабоч насколько админ глуп
кстати, а ты не задумывался, что произойдёт если эта твоя ссылка с reflected XSS будет на каком-то другом сайте в теге
<img src="туттвояссылкасXSS" width="0" height="0" /> или в <iframe> или ещё как-то в невидимом (max прозрачность) элементе и админ вдруг ненароком посетит тот другой сайт? ;-)ну конечно варианты есть что anti-csrf токены юзаются сайтом который админит админ, а может быть и нет, так что тут всё "it depends ..." как говорится.
Последнее редактирование:
https://securitytrails.com/ is a very powerful tool to find old domains/ip's. Maybe youll find the origin IP of the domain