• XSS.stack #1 – первый литературный журнал от юзеров форума

Как ломать сайты один за другим?

grozdniyandy

White-Hat
Premium
Регистрация
11.08.2023
Сообщения
522
Реакции
677
Гарант сделки
2
Подпишитесь в наши курсы сейчас с промокодом "аВИнтернетеВсёБесплатно", щучу конечно.
Если у вас знания состоят только из CTF и когда дело доходит до обычных сайтов ничего не можете сделать, скажу вам секрет, проблема в вашей психике. ТК вы уже думаете что ничего не сможете, потому что не уверены в себе. Я такой же как и вы, обычные сайты в пентест беру редко, но расскажу ка я вам историю одного из моих баг баунти.

Значит баг баунти я занимаюсь макс 4 часа за 6 месяцев, не шутка, реально так. И решил я однажды чекнуть один сервис, открыл сайт, всё у меня настроено, пошёл в логин, увидел капчу, и в запросе есть параметр "капча", убрал этот параметр, эррора не было, а ответ был валиден. Подал им, получил 200$. Всё было так просто.

От сюда делаем 2 вывода, либо вы должны идти по чеклисту, либо должны основываться на своей интуиции. Чеклистов много, советую начать с одного и добавлять если чего то нет
Код:
Machine Name:
IP Add:
Machine OS:
Open Ports:
Programming Language:
Web root:
Web config files:
Web logs:
Admin interface:
Websockets:
Dirb/gobuster results:
Nikto results:
Database:

Version:
Creds:
Stacked queries:
UDF:
Copy to:
Execute shell commands:
User/password tables:
Logging:

Authentication method:

Hashing/salted or in clear:
Session cookies/tokens:
Password resets:
How are users created:
Difference between admin and non-admin:
Predictable token generation:
Type Juggling:
SQLi in login methods:
Cookies encoded or serialized:
Difference between authenticated and unauthenticated pages:
Anything interesting when accessing nonexistent page:

SQLi in code:

User controlled parameters:
Sanitization:
Escapable quotes:
Enumeration or run code:

File uploads:

Blacklists:
Mime type:
Where are files stored:

Serialization:

Anything serialized or deserialized after authentication:
Cookies:
Files:
JSON:
Pickle:
Base64 encoded:

Code injection:

User controlled parameters:
Ability to inject PHP, JS, etc:

XXE:

Is XML being used:
User controlled parameters:
Local entities:
External Entities:
Disclose known files (/etc/passwd, C:\windows\win.ini):
RCE capable:

SSTI:

Template version:
Test {{77}}, = 77
Blacklists:
Run code:

XSS:

Injectable fields:
Alert box:
Steal cookie:
CSRF:

Vulnerabilities discovered:

Type:
PoC:

Reverse Shell:

Bash:
nodeJS:
PHP:
Powershell:
Msfvenom:
 
И решил я однажды чекнуть один сервис, открыл сайт, всё у меня настроено, пошёл в логин, увидел капчу, и в запросе есть параметр "капча", убрал этот параметр, эррора не было, а ответ был валиден. Подал им, получил 200$. Всё было так просто.
От сюда делаем 2 вывода, либо вы должны идти по чеклисту, либо должны основываться на своей интуиции. Чеклистов много, советую начать с одного и добавлять если чего то нет
типа "не передал юзер ответ на капчу? ну значт и не будем проверять так пустим" - так? ахаха. прикольно!
да, CTF они как "резиновая женщина" же поэтому, IRL всё бывает куда прозаичнее и разрабы бывают редкостные рукожопы, это факт, а те кто тренировался на CTF они ждут какой-то "логики в уязвимостях" которой может не быть на реальном таргете вовсе, просто разраб тупанул или поленился.

а мне вот "мозг взломал" и "убрал психологический барьер" как ни странно один чувак, показавший что "оружием может быть ВСЁ!" жаль ролик на youtube сейчас не могу его найти, он показал что ошибки могут быть от чего угодно и через хэдеры и чего в них какие значения, и через куки, и даже через тип запроса, а не только через параметры в GET и body в POST.
это к тому что user input'ом может быть что угодно, даже то что психика не воспринимает как user input.

но увы у меня теперь другая проблема: нет "чуйки" точнее недостаточно, а кол-во вариантов через что ломать пытаться - оно просто огромное (не на fuzz'ишься как говорится), чеклист конечно это хорошо но годами ломать что-то по нему можно, всё таки надо как-то "чуйку" тренировать - вот как?

обычно я пытаюсь "просто вызвать ошибку" для начала сломав параметры (и не только параметры, см. выше), и это обычно очень-очень просто увы, и если есть ошибка то смотрю уже можно ли 4xx или 500 ошибку обратить себе на пользу, если verbose output с дебагом - это особенно помогает понять чего там бахнуло на сервер сайд.
 
типа "не передал юзер ответ на капчу? ну значт и не будем проверять так пустим" - так? ахаха. прикольно!
да, CTF они как "резиновая женщина" же поэтому, IRL всё бывает куда прозаичнее и разрабы бывают редкостные рукожопы, это факт, а те кто тренировался на CTF они ждут какой-то "логики в уязвимостях" которой может не быть на реальном таргете вовсе, просто разраб тупанул или поленился.

а мне вот "мозг взломал" и "убрал психологический барьер" как ни странно один чувак, показавший что "оружием может быть ВСЁ!" жаль ролик на youtube сейчас не могу его найти, он показал что ошибки могут быть от чего угодно и через хэдеры и чего в них какие значения, и через куки, и даже через тип запроса, а не только через параметры в GET и body в POST.
это к тому что user input'ом может быть что угодно, даже то что психика не воспринимает как user input.

но увы у меня теперь другая проблема: нет "чуйки" точнее недостаточно, а кол-во вариантов через что ломать пытаться - оно просто огромное (не на fuzz'ишься как говорится), чеклист конечно это хорошо но годами ломать что-то по нему можно, всё таки надо как-то "чуйку" тренировать - вот как?

обычно я пытаюсь "просто вызвать ошибку" для начала сломав параметры (и не только параметры, см. выше), и это обычно очень-очень просто увы, и если есть ошибка то смотрю уже можно ли 4xx или 500 ошибку обратить себе на пользу, если verbose output с дебагом - это особенно помогает понять чего там бахнуло на сервер сайд.
сходи к бабке, она тебе третий глаз откроет😁
 
сходи к бабке, она тебе третий глаз откроет😁
Не надо третьего глаза, чтобы на PHP сайте не сканить на предмет ASPX ну и наоборот, например. Я вот о такой "чуйке".

Плюс я разработчик что делает процесс проще например с помощью Burp Suite вручную - потому что везде одно и то же: раутинг в Web App который можно байпасить он на регулярках обычно, фильтрация параметров которую тоже можно байпасить, и потом обращение к БД как правило там могут быть SQLi если там SQL разумеется и нет фильтрации ввода, ну и и выдача результата.

Ну с байпасом более-менее понятно, ну например (один из тысяч вариантов, "детсадовский"), выкусывают "<script>" регуляркой, а ты суёшь "<sc<script>ript>" после выкуса 1 раз то есть не рекурсивно получится искомый "<script>".

Псеводокод ведь примерно везде таков:
Код:
// модуль router для ендпоинтов
if(request.url = "/huemoe1") {
  huemoe1_processor(request);
} else if (request.url = "/huemoe2") {
  huemoe2_processor(request);
} else {
  default_huita();
}

//модуль обработчика huemoe1
function huemoe1_processor(request) {
  if(regexp_not_match(request.body.login, '.*@.*\./*')) { // проверяем регуляркой на email, регулярка может быть кривая или напрочь отсутствовать
    response.respond('wrong email!');
  }

  result = db.query('SELECT * FROM users WHERE email={request.body.login}'); // тут SQLi если регулярку выше обошёл
 
  if(result.password != hash(request.body.password)) {
     response.respond('wrong password!');
  }
 
  response.setCookie('blablabla={result.user_id}'); // если куки не httpOnly то XSS их потырит
  response.respond('welcome!');
}

Но вариаций просто дофига и "дьявол кроется в деталях".
Как правило разрабы не особо церемонятся и копипастят паттерны ендпоинтов при создании новых, например доступ к БД, поэтому SQLi если набрёл они "не ходят по одной", а косяками прут.
 
Последнее редактирование:
типа "не передал юзер ответ на капчу? ну значт и не будем проверять так пустим" - так? ахаха. прикольно!
да, CTF они как "резиновая женщина" же поэтому, IRL всё бывает куда прозаичнее и разрабы бывают редкостные рукожопы, это факт, а те кто тренировался на CTF они ждут какой-то "логики в уязвимостях" которой может не быть на реальном таргете вовсе, просто разраб тупанул или поленился.

а мне вот "мозг взломал" и "убрал психологический барьер" как ни странно один чувак, показавший что "оружием может быть ВСЁ!" жаль ролик на youtube сейчас не могу его найти, он показал что ошибки могут быть от чего угодно и через хэдеры и чего в них какие значения, и через куки, и даже через тип запроса, а не только через параметры в GET и body в POST.
это к тому что user input'ом может быть что угодно, даже то что психика не воспринимает как user input.

но увы у меня теперь другая проблема: нет "чуйки" точнее недостаточно, а кол-во вариантов через что ломать пытаться - оно просто огромное (не на fuzz'ишься как говорится), чеклист конечно это хорошо но годами ломать что-то по нему можно, всё таки надо как-то "чуйку" тренировать - вот как?

обычно я пытаюсь "просто вызвать ошибку" для начала сломав параметры (и не только параметры, см. выше), и это обычно очень-очень просто увы, и если есть ошибка то смотрю уже можно ли 4xx или 500 ошибку обратить себе на пользу, если verbose output с дебагом - это особенно помогает понять чего там бахнуло на сервер сайд.
А детали не подскажешь? На русском/английском, насколько длинное? Может что то в нике автора запомнилось, или слова какие то точно в названии есть? Заранее благодарю!
 
А детали не подскажешь? На русском/английском, насколько длинное? Может что то в нике автора запомнилось, или слова какие то точно в названии есть? Заранее благодарю!
Да название не важно, видео просто "одно из", то же самое написано даже в OWASP Testing Guide V4 причём куда более подробно.
Суть простая: например, не надо воспринимать "протокол HTTP" как некоторые жёсткие рамки, надо начать воспринимать его как текст, а лучше как "набор байтов" в запросе к серверу, ну и покопавшись в коде серверов разных (которые люди писали, такие же как и ты) тоже начинаешь понимать что оно там внутри не "волшебные эльфы", а вполне такой корявый код с регулярными выражениями, фильтрующими далеко не всё, с ошибками засовывания "распарсенного не так" (неожиданный юзеринпут) в переменные и т.д.
Ну простой пример: есть в URL переменная /?param=value - кто сказал что нельзя её передать дважды или трижды? кто сказал что в её нельзя передать что-то нестандартное и не обязательно всеми любимую кавычку для SQLi, вариантов же море просто. И самое веселье когда сервер начинает отвечать подробно, не "500 какая-то ошибка", а 500 и стек прям вываливать - тогда считай повезло и можно "дебажить" эту ошибку до нужного тебе результата, и даже если нет - всегда в VM локально можно поднять аналогичный сетап и "дрючить" его беспалевно и локально, а когда найдёшь как эскплуатировать - тогда и выходить на таргет (так меньше шума в логах кстати).
 
Если говорить про баг-баунти, то нужно убрать мышление еще что нужно его "вскрыть". Порой это может быть или невозможно, или быть аут-оф-скоуп, или еще какие ограничения. Но баг-баунти на то и баг-баунти, что сдавать можно все что вам кажется так или иначе имеет хоть какой то сесурити импакт.
 
Если говорить про баг-баунти, то нужно убрать мышление еще что нужно его "вскрыть". Порой это может быть или невозможно, или быть аут-оф-скоуп, или еще какие ограничения. Но баг-баунти на то и баг-баунти, что сдавать можно все что вам кажется так или иначе имеет хоть какой то сесурити импакт.
не понимаю баг-баунти и "белых хакеров", которых кидают ещё к тому же (см. тему про багбаунти от Timeweb) и они сюда жаловаться приходят.
"белый хакер" для меня это как "werewolf-веган" звучит 😆

а так да, ничего "вскрывать" не надо, хак - это надо системе что-то "скормить" (userinput, он же payload) что она неправильно прожуёт и выдаст "неожиданный (автором) результат" полезный тебе. это может быть и не сразу прям вот RCE но какая-то sensitive инфа которая поможет "сёрфить" дальше вглубь сетки таргета с целью разжиться более ценной инфой или "доступами".

так вот кто-то пэйлоады ищет в виде готовых сплоитов (script-kiddie) ваще не понимая как он добивается "неправильной сработки" системы на том конце, а кто-то опенсорцное хакает whitebox, глядя исходный код и находя там 0-day от которых "нет спасения" пока патч не выйдет.
 
Да не. почему, вайтхеты вполне себе хакеры, если ковырять уж совсем в терминологию.
Используют ограниченные ресурсы системы для получения неожиданного поведения, дающего преимущество. Разница лишь в конечном результате и $$$.
История про таймвеб очень субьективна, тут две стороны.
 


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх