Структуризация знаний и поиск уязвимостей

[users_h8]

Приветствую всех читателей. У меня возник такой вопрос -> как лучше всего структуризировать полученные знания? У меня на данный момент не слишком обширные познания в области веб пентеста. Есть за спиной несколько пройденных CTF и всегда меня преследует одна и та же проблема. Нумерация и сканы у меня проходят без проблем, однако при столкновении с поиском XSS уязвимостей или SQL инъекций, я начинаю перебирать свои записи и понимаю, что они хоть и разбиты по разным папкам, но ориентироваться в них не всегда удобно.

Второй момент -> сам процесс поиска уязвимостей. Быть может кто-то посоветуетопределённую методологию? Или же поможет лишь практический опыт? Аналогичного совета с методологией хранения записей хотелось бы попросить.

Насчёт XSS, RCE и их поиска. Ранее у меня был только опыт системного администрирования и около месяцев двух назад начал интересоваться кодом. Читал код питона по Exploit DB для различных уязвимостей. Мне эта тема очень сильно приглянулась и стало интересно, как научиться самому находить XSS или RCE и писать под них скрипты.

С удовольствием почитаю ваши ответы.

 

[dot]

Привет)
Все на опыте, та же самая ореинтация в записях - в терминале сначала тоже неорентируешься, но со временем руки все запоминают и уже попроще.
Я записываю все подряд что цепляет мое внимание, иногда так сильно увлекаюсь, что перестаю это делать и на следующий день стараюсь основные моменты выделить как минимум.
Потому что сейчас времена тяжеленькие и неизвестно что тебе пригодиться, чтобы в панике не бегать по гуглу, лучше быстро воостановить информацию через свои заметки)
Чтобы заметки не оказались мусором со временем, информацию обновляешь и структурируешь уже со временем на опыте, что-то отваливается, что-то слишком очевидное запоминается, а где-то тратишь время чтобы капнуть глубже.

 

[dunkel]

Насчёт XSS и их поиска. Ранее у меня был опыт системного администрирования и около месяцев двух назад начал интересоваться кодом. Читал код питона по Exploit DB для различных уязвимостей. Мне эта тема очень сильно приглянулась и стало интересно, как научиться самому находить XSS и писать под них скрипты.

Как связанны системное администрирование, код питона, exploit db и xss?
Xss используется чтобы угнать куки сессию, или подгрузить со своего хоста большой скрипт (не работает если на сайте есть http заголовки SOP, CSP) который нарисует фейк форму логина и 2fa
Сканируешь сайт всеми xss scanner и найденные xss тестируешь ручками (могут быть ложноположительными). Нет смысла искать xss на каких то бомжатских сайтах/форумах выбора подгузников для мамочек(зачем тебе это говно?). Искать xss надо на денежных сайтах, онлайн банках, криптобиржах, бк, платежках и т.д.
Reflected xss - js код в url запросе(допустим нашел на сайте reflected xss и спамишь этой ссылкой в тематических чатах/дискордах/форумах, если человек перейдет и залогинен на том сайте - js код выполнится и его куки улетят тебе на сервер, ставишь себе юзер агент жертвы + подбираешь прокси того же города + вставляешь себе его куки, заходишь => монетизируешь (выводишь деньги с баланса, спамишь, меняешь креды если возможно, перепродаешь)
Stored xss - js код на самой странице(допустим на уязвимом форуме пишешь комменты/посты с xss, какой то чел зашел на такую страницу - его куки улетели тебе(хз зачем тебе это, нужны только для спама по форуму наверно).

 

[users_h8]

Как связанны системное администрирование, код питона, exploit db и xss?
Xss используется чтобы угнать куки сессию, или подгрузить со своего хоста большой скрипт (не работает если на сайте есть http заголовки SOP, CSP) который нарисует фейк форму логина и 2fa
Сканируешь сайт всеми xss scanner и найденные xss тестируешь ручками (могут быть ложноположительными). Нет смысла искать xss на каких то бомжатских сайтах/форумах выбора подгузников для мамочек(зачем тебе это говно?). Искать xss надо на денежных сайтах, онлайн банках, криптобиржах, бк, платежках и т.д.
Reflected xss - js код в url запросе(допустим нашел на сайте reflected xss и спамишь этой ссылкой в тематических чатах/дискордах/форумах, если человек перейдет и залогинен на том сайте - js код выполнится и его куки улетят тебе на сервер, ставишь себе юзер агент жертвы + подбираешь прокси того же города + вставляешь себе его куки, заходишь => монетизируешь (выводишь деньги с баланса, спамишь, меняешь креды если возможно, перепродаешь)
Stored xss - js код на самой странице(допустим на уязвимом форуме пишешь комменты/посты с xss, какой то чел зашел на такую страницу - его куки улетели тебе(хз зачем тебе это, нужны только для спама по форуму наверно).

Спасибо за ответ. Об опыте работы сис админом упоминал в контексте моего общего прошлого опыта в IT сфере.

На exploit db я смотрел примеры уязвимостей XSS, в том числе там находил скрипты на питоне в котором немного разбираюсь. Изначально сложилось впечатление, что большая часть подобных эксплоитов пишутся на питоне.

 

[dunkel]

Спасибо за ответ. Об опыте работы сис админом упоминал в контексте моего общего прошлого опыта в IT сфере.

На exploit db я смотрел примеры уязвимостей XSS, в том числе там находил скрипты на питоне в котором немного разбираюсь. Изначально сложилось впечатление, что большая часть подобных эксплоитов пишутся на питоне.

Для начала хотя бы прочитай все статьи из поисковой выдачи. Никакого отношения к питону и эксплоитам xss не имеет. Эксплоит - скрипт который воспроизводит баг. Xss - выполнение Js кода обычно в браузере посетителя сайта

xss - Recherche Google

 

[users_h8]

Для начала хотя бы прочитай все статьи из поисковой выдачи.

Я понял в чём, ошибся -> перепутал XSS и RCE уязвимости. Потому и писал про скрипты питона которые нашел на db. Извиняюсь на путаницу.

 

[weaver]

У меня возник такой вопрос -> как лучше всего структуризировать полученные знания?

Я бы посоветовал установить программу CherryTree чтобы структурировать свои знания, вести заметки чит-шиты, другим же нравится программа Obsidian. Ты наверно уже не раз видел на гитхабе где выкладываются различные чит-шиты, по использованию инструментов, где например описаны различные техники эксплуатации, в том числе чит-шиты в виде пайлоадов. Да и так же взять хотя бы этот сайт и вот этот на что это похоже? правильно это похоже на заметки где структурируется информация. Ты же можешь установить любую себе программу для ведения заметок, можешь начать даже с блокнота. Ну и собственно записывай максимально кратко инфу, так, чтобы ты это понял, понял в случае того, когда ты забудешь какой-то момент. А заметка поможет освежит тебе эти знания и ты сразу же сможешь эти знания применить. И постепенно у тебя будет это всё откладываться в голове. Какие-то заметки со временем даже станут не актуальными.

Второй момент -> сам процесс поиска уязвимостей. Быть может кто-то посоветуетопределённую методологию? Или же поможет лишь практический опыт? Аналогичного совета с методологией хранения записей хотелось бы попросить.

Когда ты нибиваешь руку на одной уязвимости, то у тебя появляется опредленная методология. Взять хотя бы sql-injection ты пихаешь ковычку и ждешь результат. Соответственно когда ты расширяешь свой арсенал другими уязвимостями то и методология у тебя будет шире включая больший скоуп по разным уязвимостям... Поэтому прежде чем искать ты должен как быть сделать разведку посмотреть на чем сделан сайт? может быть это самописная CMS или это Wordpress или это какое-то веб-приложения на Python. Отсюда и вывод, что определенного пути нет, а ты подстраивешься под таргет. Т.е. ты изначально определяешь поверхность атаки, и пробуешь нащупать в каждых местах уязвимость, ну а для выявления определенной баги используешь определенные методы.

 

[users_h8]

Я бы посоветовал установить программу CherryTree чтобы структурировать свои знания, вести заметки чит-шиты, другим же нравится программа Obsidian. Ты наверно уже не раз видел на гитхабе где выкладываются различные чит-шиты, по использованию инструментов, где например описаны различные техники эксплуатации, в том числе чит-шиты в виде пайлоадов. Да и так же взять хотя бы этот сайт и вот этот на что это похоже? правильно это похоже на заметки где структурируется информация. Ты же можешь установить любую себе программу для ведения заметок, можешь начать даже с блокнота. Ну и собственно записывай максимально кратко инфу, так, чтобы ты это понял, понял в случае того, когда ты забудешь какой-то момент. А заметка поможет освежит тебе эти знания и ты сразу же сможешь эти знания применить. И постепенно у тебя будет это всё откладываться в голове. Какие-то заметки со временем даже станут не актуальными.



Когда ты нибиваешь руку на одной уязвимости, то у тебя появляется опредленная методология. Взять хотя бы sql-injection ты пихаешь ковычку и ждешь результат. Соответственно когда ты расширяешь свой арсенал другими уязвимостями то и методология у тебя будет шире включая больший скоуп по разным уязвимостям... Поэтому прежде чем искать ты должен как быть сделать разведку посмотреть на чем сделан сайт? может быть это самописная CMS или это Wordpress или это какое-то веб-приложения на Python. Отсюда и вывод, что определенного пути нет, а ты подстраивешься под скоуп. Т.е.ты изначально определяешь поверхность атаки, и пробуешь нащупать в каждых местах уязвимость.

Спасибо! Ранее не слышал о CherryTree, обязательно ознакомлюсь.

 

[zdestuta]

Надо понимать на чём и как примерно работает таргет, ну чтобы хотя бы не искать уязвимости апача в IIS и наоборот

Как пример тут недавно толковая статья была про Google dorks, однако автор всё свёл к SQLi по итогу, тогда как на практике ну прям как здрасьте там часто LFI и в случае PHP ешё и RCE через LFI (см. от меня комменты там), а это уже совсем другой вектор. И если не думая искать там SQLi , то LFI, а уж тем более RCE не найти таким образом разумеется никак. Не зря говорят "вектор атаки" - есть "пространство" куда атаковать (ещё "площадь атаки" это называют - чем больше тем вероятнее успех обычно) и если упорото идти одним вектором, но в другие места где уязвомость можно просто не попасть вообще.

Поэтому правильно тут пишут что пэйлоад зависит от таргета, а не от "волшебного чеклиста, которым со мной никто не делится, вот жадные какие!"

Также надо отчётливо понимать, что "структура" например HTTP запросов - она только в RFC и головах разработчиков, а хакер не мыслит шаблонами, для него HTTP запрос весь это по сути plain text и даже binary и даже не "запрос" а stream, то есть пэйлоад это "набор байт который прилетит в сервер и парсер на сервере жуя это слетит с катушек", и по сути надо найти такой "набор данных" для юзеринпута, чтобы парсер на той стороне от полученного малость прифигел и сработал неправильно ;-)
И такая же фигня не только с HTTP (помню-помню в 2003 как я на MDaemon через POP3 делал "DELE -1" ну и клал его - он ну никак не ожидал просьбу "удали минус первое письмо плиз" соответственно в массиве он попадал куда-то не туда в памяти, ибо писан на C++) но и с другими протоколами разумеется. Вон недавно в IPv6 виндовом дырень какую знатную нашли, см. новости, а оно ведь вертелось много лет никто и не подозревал.

Для начала рекомендую "просто ошибки" повызывать своим юзер инпутом на сайтах, что прям очень легко сделать практически на любом сайте, и хоть баги это не уязвимости, но если повезёт и ответ verbose будет от сервера, то можно примерно догадаться где и на чём там "логика ломается" и придумать уже более удачный payload - это если black box.

Ну а с white box ещё приятнее работать - ставишь локально такой же энвайрнмент как на таргете, но локально тыж ещё и debug можешь проводить, смотреть куда по CFG (comtrol flow graph) прога пошла и чего со структурами данных стало в RAM от твоего пэйлоада.

Это если серьёзно к вопросу подходить как к исследованию. Ну а иначе - готовые сплоиты, hack tricks, без понимания чего на таргете происходит - это путь "мамкин хакер" называется Тоже наверное весело, да и ломать можно, но без понимания... вот лично мне не особо интересно так.

По kill chain, векторам атак и т.д. рекомендую ознакомиться с доками от MITRE
Для тестирования Web Apps ("сайтов") рекомендую глянуть на "методичку" от OWASP

 

[users_h8]

Надо понимать на чём и как примерно работает таргет, ну чтобы хотя бы не искать уязвимости апача в IIS и наоборот

Как пример тут недавно толковая статья была про Google dorks, однако автор всё свёл к SQLi по итогу, тогда как на практике ну прям как здрасьте там часто LFI и в случае PHP ешё и RCE через LFI (см. от меня комменты там), а это уже совсем другой вектор. И если не думая искать там SQLi , то LFI, а уж тем более RCE не найти таким образом разумеется никак. Не зря говорят "вектор атаки" - есть "пространство" куда атаковать (ещё "площадь атаки" это называют - чем больше тем вероятнее успех обычно) и если упорото идти одним вектором, но в другие места где уязвомость можно просто не попасть вообще.

Поэтому правильно тут пишут что пэйлоад зависит от таргета, а не от "волшебного чеклиста, которым со мной никто не делится, вот жадные какие!"

Также надо отчётливо понимать, что "структура" например HTTP запросов - она только в RFC и головах разработчиков, а хакер не мыслит шаблонами, для него HTTP запрос весь это по сути plain text и даже binary и даже не "запрос" а stream, то есть пэйлоад это "набор байт который прилетит в сервер и парсер на сервере жуя это слетит с катушек", и по сути надо найти такой "набор данных" для юзеринпута, чтобы парсер на той стороне от полученного малость прифигел и сработал неправильно ;-)
И такая же фигня не только с HTTP (помню-помню в 2003 как я на MDaemon через POP3 делал "DELE -1" ну и клал его - он ну никак не ожидал просьбу "удали минус первое письмо плиз" соответственно в массиве он попадал куда-то не туда в памяти, ибо писан на C++) но и с другими протоколами разумеется. Вон недавно в IPv6 виндовом дырень какую знатную нашли, см. новости, а оно ведь вертелось много лет никто и не подозревал.

Для начала рекомендую "просто ошибки" повызывать своим юзер инпутом на сайтах, что прям очень легко сделать практически на любом сайте, и хоть баги это не уязвимости, но если повезёт и ответ verbose будет от сервера, то можно примерно догадаться где и на чём там "логика ломается" и придумать уже более удачный payload - это если black box.

Ну а с white box ещё приятнее работать - ставишь локально такой же энвайрнмент как на таргете, но локально тыж ещё и debug можешь проводить, смотреть куда по CFG (comtrol flow graph) прога пошла и чего со структурами данных стало в RAM от твоего пэйлоада.

Это если серьёзно к вопросу подходить как к исследованию. Ну а иначе - готовые сплоиты, hack tricks, без понимания чего на таргете происходит - это путь "мамкин хакер" называется Тоже наверное весело, да и ломать можно, но без понимания... вот лично мне не особо интересно так.

По kill chain, векторам атак и т.д. рекомендую ознакомиться с доками от MITRE
Для тестирования Web Apps ("сайтов") рекомендую глянуть на "методичку" от OWASP

Спасибо за ответ. Касательно понимания происходящего "под капотом" полностью согласен, в разы интереснее понимать процессы, которые происходят во время проверки. Про Google dorks тоже обязательно почитаю.