Зачем мне этот канал
У меня всегда была какая-то тяга к тому, чтобы делится информацией. Некоторые коллеги и близкие люди считают, что у меня это неплохо получается. Что я могу простыми словами рассказывать сложные вещи и находить такое объяснение, которое поймет каждый.
В разное время у меня были мысли о преподавании в школе, создании своих курсов для детей или взрослых, даже обучении людей отдельно из глубинки страны. Потому что у меня есть такая позиция: если найти дело, которое тебе интересно - ты будешь одновременно счастливым и обязательно добьешься определенного материального успеха. А мне кажется, что на данный момент я такое дело для себя нашел. И мне хочется рассказывать о нем другим людям, рассказывать интересно, чтобы они также смогли его полюбить и при этом неплохо зарабатывать. Это первая причина.
Я считаю, что наш век - это время открытой информации. Всему, что я знаю и умею, я обязан открытым отчетам на HackerOne, блогам исследователей из разных стран, видео на YouTube и прочим публичным источникам. Так как у меня есть свой опыт, свои наработки и идеи - хочется также поделиться ими с другими людьми. Плюс, к сожалению, наша страна объективно отстает по количеству и качеству подобного контента. И я подумал, что я могу хотя бы немножко это исправить. Вот и вторая причина.
Если честно, на несколько дней я просто выпал из работы, хотя я не могу себе это позволить, так как есть куча обязательств перед моей семьей. А вот этот пост написать все-таки захотелось. И как-то это настраивает на рабочий лад, не смотря ни на что. Наверное это третья причина - иметь возможность просто иногда выговориться.
Не смотря на то, откуда вы, и как вы сейчас относитесь к России, если вам интересны мои посты, если они мотивируют вас, учат чему-то новому - я этому очень рад.
Сейчас пока проблемы со свободным временем, но буду стараться писать почаще.
Если хотите поддержать мой канал, можете стать его спонсором на
https://boosty.to/skavans (минимальная стоимость подписки - 99р в месяц).
👍19👏2🔥1
По поводу того, где хантить сейчас.
Яндекс – это прям наше все на данный момент) Я его тут было в черный список заносил, но они в результате ответили и есть надежда, что будут пока работать. У них огромный скоуп и можно там засесть надолго. Да и платят достойно для РУ проги.
Bugcrowd – тут пока непонятно. Я им писал. Насколько понял их позицию – они не собираются просто блочить всех, как H1. Сказали, могут быть проблемы с выплатами в Россию, Беларусь и Украину. Из-за санкций. Попробую туда что-нибудь зарепортить в ближайшее время – отпишусь.
Google, FB – инфы нет, но есть надежда, что они не будут заниматься таким самоуправством и будут строго следовать санкциям. Но сказать сложно. Если есть инфа – делитесь плиз, буду шарить на канале.
Если кто не заметил, все русские проги на H1 на сегодня заблокированы. Они сейчас находятся в поиске альтернативных решений. Так что наверняка будут анонсировать запуск на других площадках или в виде self-hosted решений. Но надо ждать.
Есть еще вот такой список self-hosted программ: https://github.com/projectdiscovery/public-bugbounty-programs/blob/master/chaos-bugbounty-list.json
Наверняка тут тоже можно с кем-то поработать, но это требует изучения.
Если есть еще идеи – делитесь, также буду рад пошарить.
Яндекс – это прям наше все на данный момент) Я его тут было в черный список заносил, но они в результате ответили и есть надежда, что будут пока работать. У них огромный скоуп и можно там засесть надолго. Да и платят достойно для РУ проги.
Bugcrowd – тут пока непонятно. Я им писал. Насколько понял их позицию – они не собираются просто блочить всех, как H1. Сказали, могут быть проблемы с выплатами в Россию, Беларусь и Украину. Из-за санкций. Попробую туда что-нибудь зарепортить в ближайшее время – отпишусь.
Google, FB – инфы нет, но есть надежда, что они не будут заниматься таким самоуправством и будут строго следовать санкциям. Но сказать сложно. Если есть инфа – делитесь плиз, буду шарить на канале.
Если кто не заметил, все русские проги на H1 на сегодня заблокированы. Они сейчас находятся в поиске альтернативных решений. Так что наверняка будут анонсировать запуск на других площадках или в виде self-hosted решений. Но надо ждать.
Есть еще вот такой список self-hosted программ: https://github.com/projectdiscovery/public-bugbounty-programs/blob/master/chaos-bugbounty-list.json
Наверняка тут тоже можно с кем-то поработать, но это требует изучения.
Если есть еще идеи – делитесь, также буду рад пошарить.
👍8
Появился Sanctions FAQ на H1:
https://www.hackerone.com/sanctions-faq
Тезисно:
- проблемы с выплатами украинским исследователям ошибочны, будут предприниматься попытки все починить;
- выплаты российским и белорусским исследователям временно на паузе "в строгом соответствии с законодательством";
- выплаты будут перенаправлены на благотворительность только в случае прямого указания исследователя (приносим извинения за неточность в прошлых заявлениях).
В принципе ничего нового, но это уже официальная позиция, а не просто твит.
На данный момент выплаты в российские банки отклоняются со статусом
https://www.hackerone.com/sanctions-faq
Тезисно:
- проблемы с выплатами украинским исследователям ошибочны, будут предприниматься попытки все починить;
- выплаты российским и белорусским исследователям временно на паузе "в строгом соответствии с законодательством";
- выплаты будут перенаправлены на благотворительность только в случае прямого указания исследователя (приносим извинения за неточность в прошлых заявлениях).
В принципе ничего нового, но это уже официальная позиция, а не просто твит.
На данный момент выплаты в российские банки отклоняются со статусом
rejection_verified.Hackerone
Sanctions FAQ | HackerOne
We sincerely sympathize with the frustration and uncertainty faced by hackers and customers affected by exports controls and sanctions in areas such as Russia, Belarus, and occupied areas of Ukraine. We also recognize delays have occurred with various payment…
Есть информация, что выплаты до сих пор можно получать в крипте через Coinbase:
https://news.1rj.ru/str/WebPwnChat/131201
Кто хочет – может попробовать. Для небольших сумм это вполне себе вариант, как мне кажется.
Только нужно учесть, что на данный момент невозможно легально получать оплату криптой в России за свои услуги согласно Закону о Цифровых Финансовых Активах и Цифровой Валюте. Это просто-напросто запрещено.
Однако, сейчас идут обсуждения на этот счет. Возможно, в скором будущем это станет легальным способом получения оплаты.
P.S.: речь о России, в Беларуси это разрешено, насколько я понимаю.
https://news.1rj.ru/str/WebPwnChat/131201
Кто хочет – может попробовать. Для небольших сумм это вполне себе вариант, как мне кажется.
Только нужно учесть, что на данный момент невозможно легально получать оплату криптой в России за свои услуги согласно Закону о Цифровых Финансовых Активах и Цифровой Валюте. Это просто-напросто запрещено.
Однако, сейчас идут обсуждения на этот счет. Возможно, в скором будущем это станет легальным способом получения оплаты.
P.S.: речь о России, в Беларуси это разрешено, насколько я понимаю.
👍2
Получил письмо от Bugcrowd.
Говорят, что могут быть проблемы в перечислении платежей в Россию, Украину и Беларусь. Но эмбарго нет (соответственно нет и законного запрета).
Поэтому всем ресерчерам из данных регионов при проблемах с оплатой рекомендуют обращаться на support@bugcrowd.com для помощи.
Звучит неплохо, но как по факту – информации пока нет.
Говорят, что могут быть проблемы в перечислении платежей в Россию, Украину и Беларусь. Но эмбарго нет (соответственно нет и законного запрета).
Поэтому всем ресерчерам из данных регионов при проблемах с оплатой рекомендуют обращаться на support@bugcrowd.com для помощи.
Звучит неплохо, но как по факту – информации пока нет.
И позиция Intigriti.
Мы не останавливаем работу с российскими исследователями. Так как Swift и Paypal приостановили операции в России и других связанных регионах, мы не можем быть уверены, что платежи дойдут куда надо.
В связи с этим мы приняли решение временно не совершать платежи на аккаунты, с которыми, как нам кажется, могут быть проблемы.
https://kb.intigriti.com/en/articles/6059051-important-information-regarding-intigriti-s-response-to-the-russian-invasion-of-ukraine
Мы не останавливаем работу с российскими исследователями. Так как Swift и Paypal приостановили операции в России и других связанных регионах, мы не можем быть уверены, что платежи дойдут куда надо.
В связи с этим мы приняли решение временно не совершать платежи на аккаунты, с которыми, как нам кажется, могут быть проблемы.
https://kb.intigriti.com/en/articles/6059051-important-information-regarding-intigriti-s-response-to-the-russian-invasion-of-ukraine
👍3👎1
Какие новости?Всем привет! Почти месяц ничего не писал по двум причинам.
Как вы знаете, для меня бб уже давно стало основной работой. Соответственно, после всем известных событий пошел по одному месту мой единственный источник дохода, зато остались обязательства перед семьей, охеренных размеров ипотека и планы на ремонт в ближайшем будущем.
Кстати, наверняка тут есть люди, которым разнообразные бб-платформы остались должны денег. I know that feel bros.
H1 торчит мне ни много ни мало $50700 🙂
Что, конечно же, очень неприятно, но, слава богу, не смертельно. Я решил, что просто отчаяться и все бросить – не самый плодотворный вариант, и стал искать другие.
Так что первая причина в том, что я, собственно, изучал варианты для продолжения работы в багбаунти. Их не так уж и много:
1) перейти на российские платформы;
2) каким-то образом продолжать работать на забугорных площадках.
По первому пункту все достаточно просто. Есть бб у Яндекса, СКБ Контур, можно найти еще какие-то self-hosted проги. Плюс, ожидается запуск как минимум двух агрегаторов – bugbounty.ru и площадки от Positive Technologies. По площадкам пока достоверной инфы нет, будем ждать открытия. По self-hosted решениям основной для меня минус – это достаточно маленькие суммы выплат. В общем, я решил все же попробовать возобновить работу за USD 🙂
Так как переезжать из России я совершенно не собираюсь, единственным вменяемым вариантом для меня пока что кажется открытие компании в неподсанкционной стране и работа от ее имени с зарубежными площадками. Я нашел команду юристов, которые помогают с регистрацией ООО, сейчас процесс уже запущен. В ближайшее время надеюсь посетить эту страну и открыть там счет в банке для приема выплат. Дальше создам новые аккаунты на бб-платформах уже от имени этой компании и надеюсь, что получится продолжить работу таким образом.
Новый аккаунт, равно как и компанию публично раскрывать не буду, так как, к сожалению, есть много недоброжелателей, которые будут рады проинформировать площадки. Но расскажу обязательно, все ли сработало как надо, и смогу проконсультировать, если кто-то захочет повторить мой опыт.
Вторая причина, по которой долго не писал – не понимаю теперь, насколько актуальна тема бб. И уж тем более в плане фуллтайма. Это и раньше был, скажем так, очень скромный рынок в России, а теперь чувствую, что и от него останется процентов 10.
Мне бы хотелось и дальше продолжать писать, но не понимаю, нужно ли оно кому-то. Если вот лично тебе это интересно и все еще нужно по каким-то причинам – поставь лайк этому посту.
👍111👎2
Недооцененное: ClickJacking
Многие программы безусловно не принимают кликджекинг – просто помещают его целиком в Out Of Scope.
Вообще достаточно глупо при определении суммы выплаты или in-scope/out-of-scope оперировать типом уязвимости, а не ее импактом, мне всегда казалось это очень странным.
Например, в скоупе может быть reflected XSS со сложным user interaction на домене, на котором лежит статическая страница без каких-либо пользовательских данных. И в то же время, clickjacking, позволяющий, например, в один клик удалять объекты из польховательского аккаунта (или весь аккаунт целиком) будет вне скоупа. При этом, очевидно, что первая уязвимость не имеет реального импакта, в отличие от второй.
А видели ли вы когда-нибудь clickjacking, который никак не влияет на целостность информации, а влияет на ее конфиденциальность? Кажется странным, да?
Я вот как-то раз нашел у NewRelic clickjacking на странице, на которой был размещен пользовательский API-ключ, и придумал такой забавный вариант эксплуатации (см. видео).
Если обобщить, можно таким образом похищать у пользователя чувствительные данные. В моем примере я создал вредоносную страницу регистрации на некотором ресурсе, и на последнем шаге выдаю фрейм с ключом пользователя в NewRelic за ключ от этого сайта и прошу скопировать его в текстовое поле, чтобы подтвердить, что ключ сохранен в надежном месте (так как он, типа, отображается только один раз).
Еще, как вариант, можно такие токены представлять пользователю в виде капчи, которую нужно ввести на вредоносном сайте. Я думаю, что можно даже навернуть поверх айфрейма с токеном какие-нибудь CSS-искажения, чтобы было совсем правдоподобно.
P.S.: реальный импакт конечно невысок, но я что-то очень люблю такие нестандартные PoC и техники эксплуатации придумывать 🙂
👍13🔥3👏1
Чуть не забыл: если есть желание – можете поддержать мой канал на Boosty (любая сумма от 99р):
https://boosty.to/skavans
https://boosty.to/skavans
👍5
Где искать баги этим летом1) Если кто-то еще не видел – The Standoff на днях запустили первую российскую багбаунти платформу:
https://bugbounty.standoff365.com/#programs
Пока что доступны 2 программы: Азбука Вкуса и Positive Technologies.
Азбука платит немного (хотя и на H1 они платили примерно такие же суммы, если мне не изменяет память, может чуть больше). Но хочется все равно похвалить их за то, что не забили на бб, хотя казалось бы, что среди российских компаний они точно не на первом месте среди тех, кому полезно было бы запуститься.
Positive Technologies впервые вышли на этот рынок, насколько мне известно. По выплатам – примерно в 2 раза меньше Яндекса, что неплохо. Особенно в нынышних условиях отсутствия рынка и конкуренции. Пока не очень понятно, насколько у них широкий скоуп в плане принимаемых уязвимостей. Гарантируется вознаграждение только за 5 типов не самых распространенных багов, остальные «могут быть оплачены по решению комиссии, в зависимости от их критичности, но оплата не гарантируется». Как будет появляться информация – буду делиться, а также жду обсуждения в комментах.
2) Как-то раньше не обращал внимания, но есть еще такая (достаточно известная в своих кругах) платформа, как Immunefi:
https://immunefi.com/explore/
Она посвещена криптовалютным проектам, оплата также идет исключительно в криптовалюте. При этом, многие программы там не требуют прохождения процедуры KYC, а значит, никакой дополнительной информации об исследователях они не запрашивают. Просто присылаете адрес кошелька (не обязательно на бирже, подойдет и некастодиальный!) и после подтверждения баги вам будет отправлено вознаграждение.
Что меня удивило, что там многие проекты добавили в скоуп web-уязвимости, а стало быть можно искать всем нам знакомые уязвимости. Причем, выплаты в некоторых программах весьма и весьма хорошие.
Единственная проблема, что в РФ запрещено принимать оплату за услуги в крипте. Но для тех моих читателей, кто живет в стране, где это разрешено – советую попробовать.
P.S.: ну Яндекс тоже пока никуда не делся, само собой.
👍8🔥1
Казахстанская bugbounty.kz также не стоит на месте и выделила уже $700k на вознаграждения исследователям до конца 2023 года, что звучит достаточно интересно:
https://habr.com/ru/post/666072/
У них есть и международная версия: tumar.one
https://habr.com/ru/post/666072/
У них есть и международная версия: tumar.one
👍3
У нас, кстати, есть еще и чат:
https://news.1rj.ru/str/+zlEZJnR5o7kxN2Ey
https://news.1rj.ru/str/+zlEZJnR5o7kxN2Ey
🤯3👏1
Единственное, что я не люблю в РоссииВы, наверное, догадываетесь, что я люблю нашу страну и мне нравится тут жить. Именно поэтому я и решил завести этот канал когда-то – чтобы рассказывать о багбаунти, о том, как можно достаточно неплохо зарабатывать, занимаясь любимым делом. Тем более, что материалов на эту тему на русском практически ноль. Я не собирался никуда уезжать после 24 февраля, а наоборот старался максимально поддерживать всех, кто оказался в схожей ситуации, делиться своими идеями. Ну и все в таком духе.
Но есть одна вещь, которая меня у нас раздражает. Это местная "культура хакерства". Я не знаю, с чем это связано, но у нас каждый маломальски толковый спец по ИБ считает себя как минимум Митником. Общается со всеми свысока, всегда считает возможным и даже необходимым ткнуть новичка лицом в грязь.
При этом, свои собственные ошибки признавать не умеет. Я не знаю, то ли это синдром Даннинга-Крюгера, то ли просто ощущение своей принадлежности к элитарному классу "хакеров". Ответа у меня нет. Есть только просьба ко всем вам – не надо так. Сила не в том, чтобы показывать свое превосходство и быть пренебрежительным, а ровно в обратном.
👍28🔥19👏1
Господа, я для теста решил попробовать размещать тут посты, которые пишите вы, если это кому-то интересно. В особенности, посты для новичков. Самому мне такие посты писать не всегда весело, а тем, кто сами только учатся, может и зайти.
Как я это вижу: кто-то нашел интересный источник информации, канал на Ютубе или ещё что-то, что может быть полезно новичкам, которые делают первые шаги в бб, но своего ресурса у него нет, а поделиться интересно.
В таком случае, вы можете написать пост, скинуть его мне, я его при необходимости подредактирую, укажу вас автором (по желанию), также могу разместить реквизиты для донатов вам. И опубликую здесь.
Все, что угодно, можно небольшие заметки. Главное, чтобы они были полезны новичкам.
Если кто-то захочет – пишите в личку.
Как я это вижу: кто-то нашел интересный источник информации, канал на Ютубе или ещё что-то, что может быть полезно новичкам, которые делают первые шаги в бб, но своего ресурса у него нет, а поделиться интересно.
В таком случае, вы можете написать пост, скинуть его мне, я его при необходимости подредактирую, укажу вас автором (по желанию), также могу разместить реквизиты для донатов вам. И опубликую здесь.
Все, что угодно, можно небольшие заметки. Главное, чтобы они были полезны новичкам.
Если кто-то захочет – пишите в личку.
👍18🔥1
Первый пост от подписчика, который пожелал остаться анонимным. Поддержите лайком и комментариями!
Опасно ли узнать список пользователей сервиса? В совокупности со слабой парольной политикой – очень.
При неправильной настройке парольной политики сервиса, то есть если в качестве пароля можно установить такой, который мы легко найдем в Seclists, получить доступ хотя бы до одной из учеток не составит особого труда. Достаточно всего лишь попытаться войти под каждым пользователем с использованием списка популярных паролей. Но пароли – отдельная тема.
Стоит отметить, что именно в баг баунти такие репорты принимаются нечасто (хотя есть исключения). По-умолчанию от бага ожидается более внушительный импакт в отношении сервиса, однако, основы должен знать каждый уважающий себя охотник.
Как можно перечислить пользователей?
Если не принимать во внимание ситуацию, когда через другую уязвимость мы смогли найти готовый файлик юзернеймов, то классических ситуаций две.
1) Ответ сервера отличается в зависимости от того, зарегистрирован ли пользователь.
Часто видели фразу "Пользователь с таким логином уже зарегистрирован в системе"? Такой дизайн веб-приложения несет в себе гораздо больше опасности, чем может показаться на первый взгляд. Для перечисления достаточно использовать удобный нам fuzzer, например, Burp Suite. Готовим словарь, заряжаем intruder, и в бой.
2) По разным причинам существует временная задержка ответа от сервера для все той же ситуации.
Два классических примера:
– перечисление пользователей ssh. Если пользователь существует, то сервер начинает вычислять хэш, и отвечает позже (это если очень грубо). Эксплуатация через metasploit: модуль auxiliary/scanner/ssh/ssh_enumusers.
– перечисление пользователей домена из-за неправильной конфигурации ldap-сервера. Часто бывает, что на внешний периметр не смотрят порты служб Active Directory (в таком случае можно запросить информацию о домене), однако, нам доступен веб-интерфейс почты Microsoft Exchange. В таком случае можно попробовать идентифицировать существующих пользователей, если видно, что сервер отвечает с явной задержкой при попытке войти под реальным и фейковым юзером. Наглядно это будет видно, если отсортировать результат работы intruder по времени ответа от сервера.
Про user enumeration
Опасно ли узнать список пользователей сервиса? В совокупности со слабой парольной политикой – очень.
При неправильной настройке парольной политики сервиса, то есть если в качестве пароля можно установить такой, который мы легко найдем в Seclists, получить доступ хотя бы до одной из учеток не составит особого труда. Достаточно всего лишь попытаться войти под каждым пользователем с использованием списка популярных паролей. Но пароли – отдельная тема.
Стоит отметить, что именно в баг баунти такие репорты принимаются нечасто (хотя есть исключения). По-умолчанию от бага ожидается более внушительный импакт в отношении сервиса, однако, основы должен знать каждый уважающий себя охотник.
Как можно перечислить пользователей?
Если не принимать во внимание ситуацию, когда через другую уязвимость мы смогли найти готовый файлик юзернеймов, то классических ситуаций две.
1) Ответ сервера отличается в зависимости от того, зарегистрирован ли пользователь.
Часто видели фразу "Пользователь с таким логином уже зарегистрирован в системе"? Такой дизайн веб-приложения несет в себе гораздо больше опасности, чем может показаться на первый взгляд. Для перечисления достаточно использовать удобный нам fuzzer, например, Burp Suite. Готовим словарь, заряжаем intruder, и в бой.
2) По разным причинам существует временная задержка ответа от сервера для все той же ситуации.
Два классических примера:
– перечисление пользователей ssh. Если пользователь существует, то сервер начинает вычислять хэш, и отвечает позже (это если очень грубо). Эксплуатация через metasploit: модуль auxiliary/scanner/ssh/ssh_enumusers.
– перечисление пользователей домена из-за неправильной конфигурации ldap-сервера. Часто бывает, что на внешний периметр не смотрят порты служб Active Directory (в таком случае можно запросить информацию о домене), однако, нам доступен веб-интерфейс почты Microsoft Exchange. В таком случае можно попробовать идентифицировать существующих пользователей, если видно, что сервер отвечает с явной задержкой при попытке войти под реальным и фейковым юзером. Наглядно это будет видно, если отсортировать результат работы intruder по времени ответа от сервера.
👍25
Web3 bounty plz
Моя первая пятизначная выплата #истории #разборы #техническое #деньги Первую пятизначную выплату ($10000) я получил от Gitlab. Это произошло спустя месяц с тех пор, как я уволился и стал искать баги фулл-тайм. До этого я занимался баг-хантингом лишь изредка…
Недавно вспоминали в другом чате этот баг.
Если максимально выделить суть – она сводится к тому, что если некоторые данные являются секретными, то нельзя эти данные использовать как ID для управления этими данными (звучит супер-очевидно, однако далеко не всегда разработчики это понимают).
Был еще один схожий кейс. Там дело касалось API-ключей пользователей. Админ мог удалять ключи любого пользователя (что нормально), но проблема была в том, что запрос на удаление был вида
То есть внутри этого запроса лежал сам ключ в открытом виде. Таким образом, админ мог узнать ключ другого админа, и отправлять запросы от его имени.
А вчера наткнулся на такую же ошибку при подтверждении емейла пользователя. Админ может пригласить пользователя в организацию по email, далее пользователю приходит ссылка на почту, по которой он заходит и ставит себе пароль. Все как обычно. Почти.
После отправки приглашения у админа появлялась возможность отозвать это приглашение. И угадайте, какой ID использовался для отзыва? Верно, тот же самый, что и приходил пользователю на почту внутри «секретной ссылки». Таким образом, админ мог приглашать пользователей с любыми емейлами и подтверждать их 🙂
К сожалению, я пока не обнаружил в последнем кейсе импакта, так как не нашел привилегий от подтверждения произвольного емейла. Однако, бывают вот такие вот интересные последствия (и вознаграждения), если пользователь может создать и верифицировать аккаунт с произвольной почтой:
https://hackerone.com/reports/791775
Если максимально выделить суть – она сводится к тому, что если некоторые данные являются секретными, то нельзя эти данные использовать как ID для управления этими данными (звучит супер-очевидно, однако далеко не всегда разработчики это понимают).
Был еще один схожий кейс. Там дело касалось API-ключей пользователей. Админ мог удалять ключи любого пользователя (что нормально), но проблема была в том, что запрос на удаление был вида
/api_keys/delete?id=<api_key>То есть внутри этого запроса лежал сам ключ в открытом виде. Таким образом, админ мог узнать ключ другого админа, и отправлять запросы от его имени.
А вчера наткнулся на такую же ошибку при подтверждении емейла пользователя. Админ может пригласить пользователя в организацию по email, далее пользователю приходит ссылка на почту, по которой он заходит и ставит себе пароль. Все как обычно. Почти.
После отправки приглашения у админа появлялась возможность отозвать это приглашение. И угадайте, какой ID использовался для отзыва? Верно, тот же самый, что и приходил пользователю на почту внутри «секретной ссылки». Таким образом, админ мог приглашать пользователей с любыми емейлами и подтверждать их 🙂
К сожалению, я пока не обнаружил в последнем кейсе импакта, так как не нашел привилегий от подтверждения произвольного емейла. Однако, бывают вот такие вот интересные последствия (и вознаграждения), если пользователь может создать и верифицировать аккаунт с произвольной почтой:
https://hackerone.com/reports/791775
👍8
Пост от @lalka_1337 про "закрепление" прав пользователя, поддержите лайками!
Решил тут набросать небольшую заметку, возможно будет полезна делающим свои первые шаги в бб.
У каждого багхантера спустя некоторое время появляется свой собственный чек-лист, который он обязательно выполняет. Наткнулся на интересный параметр, пристально проверю его на sqli, xss, lfi. Работаю в админке какой-нибудь организации - в обязательном порядке все критичные функции на CSRF, а все формы отправки сообщений между сотрудниками - обязательно на XSS, возможный слом парсера markdown'а(даже если на первый взгляд кажется, что формы не поддерживают разметку) + зашлю набор пейлоадов на ssti.
Год назад я решил похантить по скоупу msrc.microsoft.com, и нашел там баг, который внес в свой персональный чек-лист и обязательно проверяю его. Работа по Azure(это такая огроменная экосистема всяких интересных штук, типа Google Сloud'а)
Был домен, да и сейчас наверное есть, домен portal.azure.com, где располагается административная часть вашей организации.
Суть. Была система инвайтов пользователей в организацию и система выставления прав и ролей. Так получилось, что тестировал из-под овнера, и случайно кинул приглос на другое свое мыло инвайт, и для этого нового пользователя, и по ошибке выставил роль овнера. Когда мне потребовался новый пользователей с более низким уровнем доступа, я решил пидорнуть второго овнера из организации, и кинуть ему новый инвайт, понизив в уровне доступа. Каково же было мое удивление, что после удаления из организации и нового инвайта, этот бывший овнер, минуя все выставления ролей оказывался сразу, да-да, овнером, а не просто членом организации, для которого нужно выставить роль и права доступа. Я тестировал это и так и сяк - выжидал сутки, использовал разные почтовые сервисы, но суть оставалась неизменной - если тебя пидорнули из овнеров, то при следующем инвайте ты автоматом становился им.
Парни в MS по достоинству оценили баг, лишних вопросов не задавали, фиксанули за пару дней и выплатили 5k$; c учетом того за RCE они платили 30k$, это был неплохой результат. Ну и да, починили они быстро, учитывая что reflected и stored XSS, которые я находил в той же панеле, они устраняли неделями.
Спустя некоторое время, функционал инвайтов новых пользователей стал обязательным пунктом в моем чек-листе. И из предыдущего бага вырос еще один обязательный пункт, сам для себя я называю его "Закрепление", хотя наверняка у этого есть какое-то научное название. Ну мы же не кукаретики, а практики, все же.
Суть. Пригласить нового пользователь, выставить ему высший уровень доступа, и попытаться максимально закрепиться, чтобы после удаления его из организации, получить какой-то импакт. Так и вышло, на парочке приватных H1 программ.
Оба раза это было связано с генерацией API ключей. Думаю, уже понятно.
Мы приглашаем нашего условного атакующего, он генерит свой токен для работы с АPI, удаляем его из организации, токен не удаляется/не уходит в инактив вслед за пользователем. И используя этот ключ, атакующий, уже по факту не являясь членом организации, может выполнять обращения через API c этим токеном. Ну, и следует понимать, что это не обязательно могут быть ключи API, а что угодно. Например, прикрутить домен для каких-нибудь вебхуков/отладки, а потом сидеть и смотреть на запросы. И так далее.
Как-то так. Надеюсь, кому-то будет полезно и возьмет на вооружение. Добра.
Решил тут набросать небольшую заметку, возможно будет полезна делающим свои первые шаги в бб.
У каждого багхантера спустя некоторое время появляется свой собственный чек-лист, который он обязательно выполняет. Наткнулся на интересный параметр, пристально проверю его на sqli, xss, lfi. Работаю в админке какой-нибудь организации - в обязательном порядке все критичные функции на CSRF, а все формы отправки сообщений между сотрудниками - обязательно на XSS, возможный слом парсера markdown'а(даже если на первый взгляд кажется, что формы не поддерживают разметку) + зашлю набор пейлоадов на ssti.
Год назад я решил похантить по скоупу msrc.microsoft.com, и нашел там баг, который внес в свой персональный чек-лист и обязательно проверяю его. Работа по Azure(это такая огроменная экосистема всяких интересных штук, типа Google Сloud'а)
Был домен, да и сейчас наверное есть, домен portal.azure.com, где располагается административная часть вашей организации.
Суть. Была система инвайтов пользователей в организацию и система выставления прав и ролей. Так получилось, что тестировал из-под овнера, и случайно кинул приглос на другое свое мыло инвайт, и для этого нового пользователя, и по ошибке выставил роль овнера. Когда мне потребовался новый пользователей с более низким уровнем доступа, я решил пидорнуть второго овнера из организации, и кинуть ему новый инвайт, понизив в уровне доступа. Каково же было мое удивление, что после удаления из организации и нового инвайта, этот бывший овнер, минуя все выставления ролей оказывался сразу, да-да, овнером, а не просто членом организации, для которого нужно выставить роль и права доступа. Я тестировал это и так и сяк - выжидал сутки, использовал разные почтовые сервисы, но суть оставалась неизменной - если тебя пидорнули из овнеров, то при следующем инвайте ты автоматом становился им.
Парни в MS по достоинству оценили баг, лишних вопросов не задавали, фиксанули за пару дней и выплатили 5k$; c учетом того за RCE они платили 30k$, это был неплохой результат. Ну и да, починили они быстро, учитывая что reflected и stored XSS, которые я находил в той же панеле, они устраняли неделями.
Спустя некоторое время, функционал инвайтов новых пользователей стал обязательным пунктом в моем чек-листе. И из предыдущего бага вырос еще один обязательный пункт, сам для себя я называю его "Закрепление", хотя наверняка у этого есть какое-то научное название. Ну мы же не кукаретики, а практики, все же.
Суть. Пригласить нового пользователь, выставить ему высший уровень доступа, и попытаться максимально закрепиться, чтобы после удаления его из организации, получить какой-то импакт. Так и вышло, на парочке приватных H1 программ.
Оба раза это было связано с генерацией API ключей. Думаю, уже понятно.
Мы приглашаем нашего условного атакующего, он генерит свой токен для работы с АPI, удаляем его из организации, токен не удаляется/не уходит в инактив вслед за пользователем. И используя этот ключ, атакующий, уже по факту не являясь членом организации, может выполнять обращения через API c этим токеном. Ну, и следует понимать, что это не обязательно могут быть ключи API, а что угодно. Например, прикрутить домен для каких-нибудь вебхуков/отладки, а потом сидеть и смотреть на запросы. И так далее.
Как-то так. Надеюсь, кому-то будет полезно и возьмет на вооружение. Добра.
👍30🔥2