Я решил вести этот канал, потому что стали накапливаться мысли разного характера, которыми хочется поделиться с теми, кому это может быть интересно.

Я уже давно занимаюсь баг-хантингом, зарегистрировался на HackerOne аж в 2014 году (самому страшно), а три года назад я уволился с неплохой программистской должности с весьма высоким, даже для Москвы, окладом, и баг-хантинг стал моей основной работой. Почему так произошло, доволен ли я, и собираюсь ли что-то менять – буду рассказывать здесь.

За это время у меня накопился немалый опыт, появились собственные наработки и техники, подходы к поиску уязвимостей, сформировался список сервисов и софта, который помогает мне в работе. Соответственно, будет здесь и инфа технического характера.

Хоть я и не фрилансер в общепринятом смысле, родные и друзья воспринимают меня именно так. И мне знакомы многие вещи, с которыми сталкиваются все фрилансеры. Выгорание, трудности работы из дома, организация рабочего процесса и распорядка – на этом я съел ни одну собаку. Про это тоже буду писать.

Резюмируя, должен получиться наполовину технический, а наполовину личный блог про инфобез, баг баунти, программирование, фриланс и все в таком духе. Если что-то из этого вам интересно – милости прошу :)

Немножко расскажу о себе.

Меня зовут Антон (skavans), я из Москвы. Вот мой профиль на h1: https://hackerone.com/skavans

Выше писал, что имею достаточно большой опыт в баг-хантинге. Чем могу в результате похвастаться?

На данный момент у меня около 6500 репутации на h1, в общем рейтинге занимаю сейчас 170 место.

Я топ-1 исследователь в NewRelic, а также топ-5 в двух крупных приватных программах, с которыми я работаю последние два года.

Полагаю также, что я где-то в самом начале топа h1 по России, по крайней мере по сумме вознаграждений :)

Я нашел более 300 багов и получил за них более 175 вознаграждений.

🇺🇸 English version – @BugBountyPLZen

Привет! Меня зовут Антон (skavans).

Уже три года баг-хантинг – моя основная работа.
И у меня неплохо получается.

Делюсь здесь опытом и своими наработками. Рассказываю про то, как я организую свою работу, как я учился, и как можно научиться вам.

А ещё иногда пишу просто истории из жизни, связанные с баг баунти.

---------------------------------

Если хотите поддержать мой канал – выбирайте:

💳 https://boosty.to/skavans

🪙 ETH, BNB, MATIC 0x1a90F6ABDD2D29bD7A9b8FE099ff8c7dd0961519

🪙 BTC bc1q9uq96lfekq7ec6slhw72k6kvxntzfk9a4un3vs
🪙 TRX THeRubKK1cNzVRD9JTTQYR7ApK8wCao8Fm
🪙 LTC ltc1q9k2lhuzfg7k482qkcswgqmn0vwsp32suf7yvr3
🪙 BCH bitcoincash:qqypg65vd2cmy54kevdu0ae4jp0229xddycx3xgsg5

Что такое Bug Bounty?

Вообще-то я не собираюсь постить прописные истины. Но у меня есть надежда, что сюда будут подписываться не только опытные люди, но и новички. А может и те, кто вообще не понимает ни заголовок этого поста, ни название канала. Этот пост для вас.

Bug Bounty – это легальный взлом, за который вам платят компании. Многие компании хотят, чтобы хакеры искали уязвимости в их сервисах или приложениях, и готовы выплачивать за них вознаграждение.

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

Почему? Я думаю, все дело в мотивации. Штатные специалисты, в подавляющем большинстве, получают зарплату, которая не зависит от их успехов, старания и тщательности.

Мы же, сторонние исследователи, мотивированы исключительно на результат. Если не найти уязвимость – ничего не заработаешь. В этом разница.

В результате, компания получает «бесплатное» исследование безопасности от тысяч человек, а оплачивать ей нужно только лишь найденные валидные уязвимости.

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

Вин-вин.

Моя первая пятизначная выплата

#истории #разборы #техническое #деньги

Первую пятизначную выплату ($10000) я получил от Gitlab.

Это произошло спустя месяц с тех пор, как я уволился и стал искать баги фулл-тайм. До этого я занимался баг-хантингом лишь изредка, по утрам перед работой, или по ночам после.

Сразу после увольнения я осознал, что все серьезно, и мне нужно как минимум обеспечить себе прежний уровень дохода. Я решил выбрать программу, продукт которой мне нравится (так как хотелось не только заработать денег, но и улучшить любимый продукт). Но и такую, чтобы хорошо платили. В общем, остановился на гитлабе.

И все пошло не по плану. Я работал очень много – на адреналине, ну и из-за страха остаться без денег, конечно. Работал по 10 часов в день с небольшим количеством выходных. В результате к концу месяца я нашёл пару мелких багов: Content Spoofing и очень лайтовый Information Disclosure. Надеяться на нормальный заработок не приходилось, в общем. И помню как сейчас: вечером должен был ехать с другом попить пивка, оставалось немного время до выхода из дома, а я сидел и как всегда ковырял приложение.

Ниже техника 👨‍💻

Сидел под админом и наткнулся на функцию имперсонализации. Это когда админ может выбрать любого пользователя, и залогиниться под ним просто нажатием одной кнопки. Видимо, для отладки багов или помощи с настройками. Ковырял эту функцию и так, и сяк, но ничего не находилось.

Работала она так. Когда админ нажимает impersonate, ему выдаётся новая сессионная кука (на имя имперсонируемого юзера). Затем у него появляется кнопка stop impersonating, после нажатия на которую, его админская сессионная кука возвращается обратно.

Пока изучал, как это работает, заходил также и под самим имперсонируемым пользователем. И обратил внимание, что в момент, когда админ прикидывается им, в личном кабинете пользователя, в списке активных сессий (ну там, где ещё часто можно нажать «завершить все другие сессии»), появляется эта самая сессия, под которой сидит админ.

Стал смотреть, какая инфа про эту сессию доступна пользователю. Оказалось, что почти ничего кроме некоторого айдишника, который виден при попытке прервать эту сессию. До меня доходит, что формат этого айдишника какой-то сильно знакомый. И тут я понимаю, что это ни что иное, как прям само значение сессионной куки.

То есть, условно, при логине пользователю ставится сессионная кука
sess=12345
а если он захочет эту сессию прервать в списке открытых сессий – отправляется запрос
/stop_session?id=12345

И то же самое работало для сессии, под которой сидит админ. Стало быть, я знаю эту его куку и могу войти под именно этой сессией.

Помните, я говорил, что у админа под такой сессией есть кнопка «выйти обратно в админа»? Вот мне было очень интересно, появится ли она у меня в таком случае :) Ну и заработанное баунти намекает, что да, появилась.

Соответственно, когда админ имперсонирует любого юзера, этот юзер может сам войти под этой хитрой админской сессией, и потом выйти обратно в админа. Такая вот эскалация привилегий.

Я оценил баг в Critical при отправке и думал:
«Ого, это мне наверное тысяч 5 заплатят, в 2 раза больше, чем когда-либо». До сих пор помню своё чувство, когда в почте увидел свою первую пятизначную выплату :)

Отчёт открыт:
https://hackerone.com/reports/493324

#черный_список

Недоволен пока что программой Яндекса. Отправили с другом пару репортов ещё месяц назад – ноль реакции. На повторные письма также ответа нет.

Если вдруг что-то изменится – напишу, а пока в ЧС. Не тратьте время.

Onmouse* XSS PoC

#техническое #советы #PoC

Про то, как я делаю PoC, буду еще писать в дальнейшем. Но с особой тщательностью я прорабатываю сценарии для уязвимостей, которым нужно user interaction.

Например, если я нашел XSS через событие onmousemove или onmouseclick, я всегда стараюсь добавить к уязвимому элементу такие стили, чтобы растянуть этот элемент на максимально возможную площадь страницы.

Обычно я использую что-то вроде
{
position: fixed;
top: 0;
left: 0;
width: 100%;
height: 100%;
background-color: red;
opacity: 0.5;
}

Тогда в отчете вместо "пользователь заходит на страницу, скроллит ее вниз, находит такую-то картинку и наводит на нее указатель" можно написать "пользователь заходит на страницу, и проводит мышкой в любом месте страницы".

Это показывает, что атаку можно реализовать в реальной жизни, а не только если думать как атакующий.

Mindmaps

#советы #организация

Обычно я работаю с одной программой очень подолгу. Может доходить до года. Это просто выгоднее, ведь хорошие баги всегда лежат где-то в глубине, и чтобы до них добраться – нужно хорошо изучить цель, понять, как работают разные компоненты и какие есть между ними взаимосвязи.

Раньше у меня были проблемы с тем, чтобы не путаться, какие функции я уже исследовал, а какие только предстоит. Особенно когда в голову пришла очередная идея и ты бежишь пробовать ее на старых, уже исследованных компонентах. Тут всегда можно подумать: "Так, а на CSRF я эту функцию уже проверял?".

Чтобы избегать выполнения одной и той же работы несколько раз, я стал использовать mindmaps. Мне показалось, что они куда лучше подходят для этого, чем, например, просто текстовые файлы. Потому что в них удобно хранить древовидные данные, а когда ты исследуешь сайт – ты по факту обходишь дерево всех его возможностей.

Структура получается примерно такая:

домен ➡️ раздел ➡️ функция ➡️ подфункция ➡️ определенная уязвимость

Если эту уязвимость я уже проверил – крашу узел с ней в другой цвет. Так я даже через год легко могу понять, что я-таки проверял эту функцию на CSRF 🙂

Таким же образом я отмечаю разделы или функции, которые я нашел, но хочу вернуться к ним позже – отдельным цветом. Удобно, что к каждому узлу можно также написать комментарий, чтобы напомнить себе в будущем, что я хотел попробовать сделать.

https://o1.su/tg_images/1.png

CSS-гаджеты

#техническое #советы

Пару постов назад я писал про мой способ увеличить импакт от XSS, завязанных на событиях мыши – через растягивание уязвимого элемента на максимальную площадь страницы с использованием стилей. Но что если атрибут style блокируется WAF, а уязвимый элемент находится в таком неочевидным месте, что есть шанс получить informative?

Например, какая-нибудь крошечная ссылка в подвале страницы вида
<a href=“INJECTION”>
оказалась уязвима и мы смогли превратить ее в
<a href=“” onclick=alert() a=“”>
но не можем сделать красивый PoC через атрибут style.

В данном случае, я использую так называемые (мной) CSS-гаджеты. Может кто-то ещё их и применяет, но я не слышал.

Суть такая, что можно «набрать» нужный стиль с использованием нативных стилей приложения. Например, неплохо бы добавить уязвимому элементу свойства width: 100% и top: 0.

Открываем инструменты разработчика на уязвимой странице и прочесываем все стили. Это удобно делать в Firefox, там они все собраны в одной вкладке.

Находим, например
.test {
display: block;
color: blue;
width: 100%;
}
и
#someid {
top: 0;
font-family: Tahoma;
}

Теперь можно модифицировать нашу ссылку и привести ее к виду
<a href=“” id=someid class=test onclick=alert() a=“”>

Таким образом, мы без использования запрещённого атрибута style придадим ей свойства, нужные для нормальной выплаты.

И даже если WAF совсем злой, и не получилось совсем выполнить JS, но инъекция в элемент все же есть, можно попробовать провернуть таким образом что-то типа дефейса. Если этот элемент важен для функционирования приложения – можно спрятать его, применив к нему класс со свойством display: none или вроде того.

Не бог весть что, но есть шанс на как минимум Availability Impact: Low.

​​Как все начиналось?

#истории

Со школы ещё я читал Хакер, когда была возможность его купить (он тогда ещё был бумажный, с диском, и стоит космических денег – чуть ли не 1000 рублей). Читал в основном ресерчи по взлому веба, понимал какие-то крохи.

Помню была статья, где на каком-то магазине, достаточно крупном, нашли SQLi прямо в форме логина. Я тогда сел за бабушкин компьютер и попытался воспроизвести все по шагам прямо на этом сайте. Я тогда не знал ничего про responsible disclosure, конечно.

Что самое смешное – бага так и не была закрыта, видимо про это не знал и автор статьи :)

Прошло несколько лет, и нам с коллегами на работе предложили сходить на PhDays за счёт компании. Мы на тот момент уже учились в МИФИ, как раз на факультете Информационной Безопасности. Но оффенсива у нас там практически не было, за каким-то очень маленьким исключением, а работали мы программистами.

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

Доклады я особо не запомнил, вроде было несколько интересных. А вот что я запомнил навсегда – это как парни из Qiwi рассказывали, что запустили баг баунти на H1. На тот момент это для меня было просто каким-то откровением. Что можно взламывать сайты легально и ещё и зарабатывать на этом.

Я шёл домой с твёрдой уверенностью заняться этим. Результаты можете видеть на скрине ниже :)

Прошло ещё прилично времени, прежде чем я получил первую выплату. Но об этом как-нибудь в другой раз расскажу.

Low-hanging fruit

У меня тут спросили, могу ли я поделиться скриптами для поиска low-hanging fruit. Конечно, таких комментов будет много – поэтому пишу этот пост.

Low-hanging fruit (дословно – низко-висящие фрукты). Так принято называть баги, которые очень легко обнаружить. Я бы их разделил ещё на 2 типа:

1. Баги, которые не имеют толкового импакта. Например: отсутствие какого-нибудь заголовка безопасности, открытый редирект, content spoofing. Такие баги я не ищу и вам не советую.

Во-первых, вам за них никто не заплатит в 99% случаев. Во-вторых – поиск таких «багов» никак вас не развивает. Куда лучше потратить время на изучение хотя бы одной более серьёзной уязвимости и вы уже будете лучше многих других, кто умеет только шаблонно просматривать заголовки без понимания происходящего.

Иногда я все же ищу их, но только прицельно, если у меня есть какой-то баг, но для эксплуатации мне нужен, например, открытый редирект. Это называется chaining – связывание нескольких багов (иногда простых, с низким импактом), чтобы в результате получить высокий импакт. Расскажу позже с примерами.

2. Нормальные баги с импактом, но которые находятся на супер-видном месте. Например: XSS в форме поиска на главной странице или IDOR в запросе смены пароля.

Тут сложнее. Однозначно не стоит пытаться найти что-то подобное в старых публичных программах. Уже тысячи таких как вы давно прочесали главную страницу. Вы потратите кучу времени, ничего не найдёте, и просто перегорите. Если же вас пригласили в свежую приватку – можно попробовать.

Сам я периодически нахожу что-то подобное, но они составляют мизерный процент, как по количеству, так и по заработку.

Чем глубже запрятана функция, чем она сложнее (и может даже скучнее) – тем меньше людей ее исследовало. Такие функции – ваш шанс найти уязвимость.

Так что нет, таких скриптов у меня нет. И советую развиваться в другом направлении.

Рутина

#fulltime #минусы

Рутина – достаточно большая проблема bug bounty на фуллтайме (для меня).

Ну какая-то ее часть воспринимается нормально. Это написание отчётов, общение с компаниями, даже проверка фиксов. Это просто есть, это часть работы, без этого не получить денег. Иногда это даже бывает весело, особенно делать какие-нибудь хитрые PoC.

Но есть другая рутина, которая высасывает все соки. Вот мне сейчас надо ещё 2 часа отработать, чтобы быть в графике, а я сел писать пост, потому что невозможно :)

Это рутина двух видов. Либо когда сидишь ковыряешь приложение, и ничего не находится часами. Не за что даже зацепиться. Но это ещё не самое страшное, потому что я так размышляю: чем дольше я ничего не нахожу – тем ближе я к новому багу. Ведь я уже давно этим занимаюсь и всегда что-то да находится новое. Значит и сейчас найдётся (хотя все равно бывает иногда страшновато).

А вот второй вид такой мерзкой рутины – это наоборот, когда есть потенциальная уязвимость и ее надо раскручивать. А она никак не даётся. Ну, например, нужно обойти фильтр или WAF. И ты сидишь часами над ним, и думаешь: может надо остановиться, может его просто не обойти? Но останавливаться не хочется, ведь можно упустить баг (особенно если он потенциально дорогой).

И каждый час, наоборот, усиливает ощущение, что время тратится впустую. И прям замкнутый круг – уже столько времени просидел, не бросать же?! Вот тут надо уметь понять свой предел, оценить возможности, принять поражение, и вовремя остановиться.

Неочевидное об XSS и HTML-энкодинге

#техническое #xss

Многие знают о том, что перед тем, как получить значение атрибута тега, браузер декодирует HTML-сущности внутри. Скажем, если попытаться прочитать свойство test у такого тега:
<tag test="&amp;">
то мы получим декодированное значение: "&".

На этом построены некоторые обходы простых XSS-фильтров.

Допустим, если нужно внедрить javanoscript-ссылку, а javanoscript: блокируется WAF, то можно попробовать сделать так:
<a href="javanoscript&colon;alert()">
Когда браузер будет читать href этой ссылки, он декодирует значение, и получится как раз javanoscript:alert(). Такая ссылка обойдет фильтр (если он никудышный), но будет рабочей.

Работают не только именованные сущности, но и числовые в разных видах. То есть можно делать атрибуты вида javanoscript:
61 – это "a" в шестнадцатеричной форме, 97 – в десятичной. Их можно комбинировать и ссылка все равно будет рабочей.

Есть еще всякие дополнительные штуки типа "a", или что можно обходиться без точки с запятой, если после HTML-сущности идет не буква. Это знают многие, кто гуглил на тему XSS и обхода фильтров.

А вот что для меня оказалось неочевидным.

Часто для предотвращения XSS приложение кодирует инпут в HTML-сущности. Ну, скажем, заменяет вашу кавычку на ". Вы все это видели.

Представим, что на странице есть тег с ивент-хендлером, а внутри него отражается параметр INJ:
<button onclick="someFunction('test', 'INJ')">
и если мы пробуем вставить кавычку в этот параметр – она также кодируется в HTML-сущность, и получается
<button onclick="someFunction('test', '&amp;')">

Выглядит безопасно, не так ли?

Вот только вернитесь назад и прочитайте пару абзацев повыше. Браузер декодирует эти сущности. И на самом деле тут написано:
<button onclick="someFunction('test', ''')">
То есть на самом-то деле у нас тут XSS, так как мы разорвали контекст строки!

Более того. Допустим, разработчики приложения умные и не стали так делать. А решили закодировать эту кавычку в "%27". Тогда, наверное, все пропало, и тег неуязвим?

Я бы не спешил так думать и попробовал передать в параметр саму HTML-сущность:
INJ=&

Продумали ли они такой вариант, или такое значение никак не будет экранировано и мы снова получим XSS в виде
<button onclick="someFunction('test', '&amp;')">
– это вопрос, которым я бы озадачился 🙂

Стоит ли переходить на фуллтайм?

#фуллтайм

В комментариях меня спросили, что в результате оказалось выгоднее по деньгам – моя предыдущая работа разработчиком или fulltime bugbounty? Отвечаю.

В первый год поиска багов на фуллтайме я заработал в 2 раза больше, чем за последний год в офисе. А в каждый из следующих двух лет – уже в 5 раз больше.

Значит ли это, что на это нужно и можно ориентироваться? Конечно нет. Многим не удаётся заработать ничего, другие зарабатывают буквально копейки. А некоторые – ещё в несколько раз больше меня. Если вам хотелось бы заняться баг-баунти на фуллтайме – мой совет простой.

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

И засекайте время. Как найдёте хотя бы с десяток багов и получите за них выплаты – посмотрите, сколько времени вы потратили на их поиск. Таким образом сможете хотя бы примерно рассчитать, сколько вы могли бы заработать за полный рабочий месяц.

У меня первый звоночек прозвенел ещё очень давно. Я тогда зарабатывал намного меньше, как-то нашёл 3 бага по $2500 буквально за несколько часов и понял, что это моя зарплата за полгода. С того момента я стал засекать время и вот в результате понял, что для меня баг-хантинг будет выгоднее.

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

Сколько зарабатывают на Bug Bounty

#деньги

В начале предлагаю посмотреть на статистику самого HackerOne. Она не самая свежая, но общее представление дает хорошее.

Согласно ей, к 2019 году:
⁃ на платформе было зарегистрировано более 1 млн исследователей;
⁃ более 9000 из них заработали хотя бы что-то;
⁃ более 200 человек заработали более $100 000;
⁃ 9 человек заработали более $1 млн.

Также я знаю, что сейчас уже есть как минимум 1 человек, который заработал более $2 млн.

Хочется отдельно отметить Сергея Тошина (bagipro) из Москвы, он стал одним из тех, кто смог заработать более $1 млн на H1. Помимо того, что мне просто приятно, что он из России, я хочу отметить его необычный подход к поиску уязвимостей.

Насколько я знаю (я не знаком с ним лично, только читал несколько интервью и видел его раскрытые отчеты) – все это время он исследовал исключительно мобильные приложения. В результате он даже запустил свой стартап по анализу защищенности мобильных приложений, который профинансировал со своих доходов в баг баунти.

Что касается меня, мои доходы за 3 года фуллтайм-работы составили:
⁃ $91 тыс за 2019 год;
⁃ $229 тыс за 2020 год;
⁃ $252 тыс за 2021 год.

И суммарно, за все время моей работы, мне удалось заработать $588 тыс.

Хочу сразу отметить, что идти в эту сферу исключительно за деньгами, не имея интереса – гиблый подход. Мое мнение такое, что здесь, как и в любой профессии, только лишь человек, искренне получающий удовольствие от работы, может добиться значительных успехов.

P.S.: большая просьба не писать мне в личку, все ваши вопросы задавайте в комментариях к постам.

Если у кого-нибудь есть аккаунт на Medium – большая просьба подписаться на меня
https://medium.com/@skavans_

Я хочу попробовать там монетизировать посты с канала, нужно набрать 100 подписчиков. Пока набралась только половина :)

​​К чему может привести инъекция в jQuery-селектор

#техническое #think_different

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