Получил письмо от Bugcrowd.

Говорят, что могут быть проблемы в перечислении платежей в Россию, Украину и Беларусь. Но эмбарго нет (соответственно нет и законного запрета).

Поэтому всем ресерчерам из данных регионов при проблемах с оплатой рекомендуют обращаться на 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

Какие новости?

Всем привет! Почти месяц ничего не писал по двум причинам.

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

Кстати, наверняка тут есть люди, которым разнообразные бб-платформы остались должны денег. I know that feel bros.

H1 торчит мне ни много ни мало $50700 🙂

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

Так что первая причина в том, что я, собственно, изучал варианты для продолжения работы в багбаунти. Их не так уж и много:
1) перейти на российские платформы;
2) каким-то образом продолжать работать на забугорных площадках.

По первому пункту все достаточно просто. Есть бб у Яндекса, СКБ Контур, можно найти еще какие-то self-hosted проги. Плюс, ожидается запуск как минимум двух агрегаторов – bugbounty.ru и площадки от Positive Technologies. По площадкам пока достоверной инфы нет, будем ждать открытия. По self-hosted решениям основной для меня минус – это достаточно маленькие суммы выплат. В общем, я решил все же попробовать возобновить работу за USD 🙂

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

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

Вторая причина, по которой долго не писал – не понимаю теперь, насколько актуальна тема бб. И уж тем более в плане фуллтайма. Это и раньше был, скажем так, очень скромный рынок в России, а теперь чувствую, что и от него останется процентов 10.

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

Недооцененное: ClickJacking

Многие программы безусловно не принимают кликджекинг – просто помещают его целиком в Out Of Scope.

Вообще достаточно глупо при определении суммы выплаты или in-scope/out-of-scope оперировать типом уязвимости, а не ее импактом, мне всегда казалось это очень странным.

Например, в скоупе может быть reflected XSS со сложным user interaction на домене, на котором лежит статическая страница без каких-либо пользовательских данных. И в то же время, clickjacking, позволяющий, например, в один клик удалять объекты из польховательского аккаунта (или весь аккаунт целиком) будет вне скоупа. При этом, очевидно, что первая уязвимость не имеет реального импакта, в отличие от второй.

А видели ли вы когда-нибудь clickjacking, который никак не влияет на целостность информации, а влияет на ее конфиденциальность? Кажется странным, да?

Я вот как-то раз нашел у NewRelic clickjacking на странице, на которой был размещен пользовательский API-ключ, и придумал такой забавный вариант эксплуатации (см. видео).

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

Еще, как вариант, можно такие токены представлять пользователю в виде капчи, которую нужно ввести на вредоносном сайте. Я думаю, что можно даже навернуть поверх айфрейма с токеном какие-нибудь CSS-искажения, чтобы было совсем правдоподобно.

P.S.: реальный импакт конечно невысок, но я что-то очень люблю такие нестандартные PoC и техники эксплуатации придумывать 🙂

Чуть не забыл: если есть желание – можете поддержать мой канал на Boosty (любая сумма от 99р):

https://boosty.to/skavans

Где искать баги этим летом

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.: ну Яндекс тоже пока никуда не делся, само собой.

Казахстанская bugbounty.kz также не стоит на месте и выделила уже $700k на вознаграждения исследователям до конца 2023 года, что звучит достаточно интересно:
https://habr.com/ru/post/666072/

У них есть и международная версия: tumar.one

У нас, кстати, есть еще и чат:
https://news.1rj.ru/str/+zlEZJnR5o7kxN2Ey

Единственное, что я не люблю в России

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

Но есть одна вещь, которая меня у нас раздражает. Это местная "культура хакерства". Я не знаю, с чем это связано, но у нас каждый маломальски толковый спец по ИБ считает себя как минимум Митником. Общается со всеми свысока, всегда считает возможным и даже необходимым ткнуть новичка лицом в грязь.

При этом, свои собственные ошибки признавать не умеет. Я не знаю, то ли это синдром Даннинга-Крюгера, то ли просто ощущение своей принадлежности к элитарному классу "хакеров". Ответа у меня нет. Есть только просьба ко всем вам – не надо так. Сила не в том, чтобы показывать свое превосходство и быть пренебрежительным, а ровно в обратном.

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

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

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

Все, что угодно, можно небольшие заметки. Главное, чтобы они были полезны новичкам.

Если кто-то захочет – пишите в личку.

Первый пост от подписчика, который пожелал остаться анонимным. Поддержите лайком и комментариями!

Про user enumeration

Опасно ли узнать список пользователей сервиса? В совокупности со слабой парольной политикой – очень.

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

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

Как можно перечислить пользователей?

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

1) Ответ сервера отличается в зависимости от того, зарегистрирован ли пользователь.

Часто видели фразу "Пользователь с таким логином уже зарегистрирован в системе"? Такой дизайн веб-приложения несет в себе гораздо больше опасности, чем может показаться на первый взгляд. Для перечисления достаточно использовать удобный нам fuzzer, например, Burp Suite. Готовим словарь, заряжаем intruder, и в бой.

2) По разным причинам существует временная задержка ответа от сервера для все той же ситуации.

Два классических примера:

– перечисление пользователей ssh. Если пользователь существует, то сервер начинает вычислять хэш, и отвечает позже (это если очень грубо). Эксплуатация через metasploit: модуль auxiliary/scanner/ssh/ssh_enumusers.

– перечисление пользователей домена из-за неправильной конфигурации ldap-сервера. Часто бывает, что на внешний периметр не смотрят порты служб Active Directory (в таком случае можно запросить информацию о домене), однако, нам доступен веб-интерфейс почты Microsoft Exchange. В таком случае можно попробовать идентифицировать существующих пользователей, если видно, что сервер отвечает с явной задержкой при попытке войти под реальным и фейковым юзером. Наглядно это будет видно, если отсортировать результат работы intruder по времени ответа от сервера.

Недавно вспоминали в другом чате этот баг.

Если максимально выделить суть – она сводится к тому, что если некоторые данные являются секретными, то нельзя эти данные использовать как ID для управления этими данными (звучит супер-очевидно, однако далеко не всегда разработчики это понимают).

Был еще один схожий кейс. Там дело касалось API-ключей пользователей. Админ мог удалять ключи любого пользователя (что нормально), но проблема была в том, что запрос на удаление был вида
/api_keys/delete?id=<api_key>

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

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

После отправки приглашения у админа появлялась возможность отозвать это приглашение. И угадайте, какой ID использовался для отзыва? Верно, тот же самый, что и приходил пользователю на почту внутри «секретной ссылки». Таким образом, админ мог приглашать пользователей с любыми емейлами и подтверждать их 🙂

К сожалению, я пока не обнаружил в последнем кейсе импакта, так как не нашел привилегий от подтверждения произвольного емейла. Однако, бывают вот такие вот интересные последствия (и вознаграждения), если пользователь может создать и верифицировать аккаунт с произвольной почтой:
https://hackerone.com/reports/791775

Пост от @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, а что угодно. Например, прикрутить домен для каких-нибудь вебхуков/отладки, а потом сидеть и смотреть на запросы. И так далее.

Как-то так. Надеюсь, кому-то будет полезно и возьмет на вооружение. Добра.

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

Тут всего-навсего можно было следить за изменениями тайтла issue после удаления из проекта :)

BI.ZONE открыл предварительную регистрацию на своей бб-платформе, официальный запуск запланирован уже на лето.

Автозаполнение паролей

Все знают, что включать автозаполнение паролей в браузере – не очень безопасно.

Но я уверен, что ты нет-нет, да и пользуешься этой удобной штукой, правда? Ну а что такого, ведь небезопасность здесь только теоретическая! Ведь для того, чтобы использовать твой предзаполненный пароль в корыстных целях, злоумышленнику нужно как минимум завладеть твоим устройством, а на нем еще и общий пароль установлен... В общем это все ерунда и не стоит волноваться.

Или все-таки нет?

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

Тут ты можешь мне возразить: но это же опять теоретическая уязвимость, для эксплуатации которой хакеру нужно завладеть...

Позволю себе тебя перебить. А как думаешь, что будет, если на этом сайте есть вредоносный JS, внедренный через XSS? А будет вот что – этот JS сможет легко прочитать твой предзаполненный пароль и отправить его к атакующему вместе со всеми другими твоими данными 🙂

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

На bugbounty.ru:

Во-первых, уже доступна регистрация для всех желающих.

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

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

P.S.: есть инфа, что мерч будет)