Поскольку корни Bugcrowd уходят в Австралию, работать с местным сообществом безопасности всегда приятно. В Австралии одни из лучших специалистов по информационной безопасности, и в центре внимания на этой неделе один из их багхантеров: Джастин Стивен.
Джастин — один из первых участников сообщества Bugcrowd, занявший верхнюю строчку в нашем списке общих выплат за все время и 31-е место в глобальном рейтинге исследователей. Его путь привел его от моддинга оригинального Xbox к постоянной роли специалиста по безопасности приложений в уважаемой технологической компании.
Найдите Джастина на Bugcrowd и подпишитесь на него в Twitter @JustinSteven.
Как вы начали заниматься исследованиями безопасности? Как долго вы занимаетесь программами bug bounty?
Я не уверен, что я на самом деле «исследователь». Я равняюсь на тех, кого считаю исследователями, на тех, кто делает новаторскую и оригинальную работу, пишут статьи в LaTeX. Надеюсь, однажды я сделаю то же самое. А пока я просто практик и тот, кто все ломает, находя в основном одни и те же ошибки в разных местах, и я стараюсь делать это как можно лучше 🙂
Что касается того, как я пришел в безопасность и безопасность приложений, я (бездарно?) потратил свою юность на изучение текстовых файлов и зинов, восхищаясь фрикерами прошлых лет, влюбившись в культуру, сообщество и чувство любопытства, которое ими двигало. Первая статья, которую я действительно понял, была посвящена софтмоддингу оригинального Xbox: «горячей» замене IDE-диска для сброса файлов шрифтов (которые не были защищены цифровой подписью), которые эксплойтили системную оболочку при каждой загрузке. Возникло ощущение: «Я бы не смог сам найти эту цепочку атак, но это не магия вуду. Заставить Xbox разжевывать свой собственный жесткий диск, сбрасывать файлы, не защищенные цифровой подписью, эксплуатировать переполнение буфера при загрузке, потому что шрифт сообщает что-то длинное как имеющее длину 0 или типа того, и это каким-то образом сбивает систему с толку. Кажется, я это понимаю. Может быть, однажды я сам стану что-то взламывать».
Я пошел получать степень бакалавра, отработал положенное в техподдержке, а через некоторое время устроился на постоянную работу по реагированию на инциденты. Я начал заниматься bug bounty примерно во время запуска Bugcrowd. С тех пор я перешел на постоянную роль специалиста по безопасности приложений и мне это очень нравится. Я почти уверен, что если бы не то, чему я научился в окопах bug bounty, и если бы не портфолио, которое помогло мне создать, я бы, наверное, не работал на текущей позиции и с такими обязанностями.
Есть ли у вас конкретная направленность или специализация, которой вы предпочитаете уделять время?
Мой абсолютный фаворит среди багов — это состояние гонки TOCTOU (время проверки до времени использования). С ними сталкиваешься нечасто, но когда это происходит, последствия могут быть катастрофическими, особенно в финансовых системах.
Функциональные ошибки/ошибки логики, небезопасные прямые ссылки на объекты (простые, но трагичные) и OSINT доставляют мне особое удовольствие.
Я поклонник слепого и не очень слепого Persistent XSS, который приходит из странных мест или пересекает неожиданные границы — когда имя агента, стучащегося на сервер, попадает на дашборд, название блога, для совместной работы над которым вы можете пригласить другого пользователя системы («Джастин приглашает вас присоединиться к блогу «Мой блог<script src=…»»), или вредоносный секретный вопрос, всплывающий без экранирования в веб-интерфейсе аналитика техподдержки, когда вы звоните в службу поддержки.
Что мотивирует вас делать то, что вы делаете? Что заставляет вас двигаться дальше?
Я люблю сообщество. Некоторые из моих лучших друзей появились благодаря общению на IRC-канале Bugcrowd, питью пива на конференциях, совместному прохождению CTF (привет rand0ml0l2) и взлому вещей в составе команды.
Я стараюсь постоянно учиться и равняюсь на тех, кто ломает системы гораздо круче меня. Видя, чего могут добиться настоящие эксперты в этой области, мне хочется пробовать новые вещи и развивать свои навыки в самых разных направлениях.
Наконец, азарт погони. Найти свой собственный укромный уголок приложения, чтобы покопаться в нем, думая, что там что-то должно быть, и этот прилив сил, когда вы натыкаетесь на золотую жилу — надеюсь, это никогда не устареет >:)
Какие советы или рекомендации вы бы дали другим багхантерам?
Особенно для новичков — придерживайтесь скоупа. Может быть обидно думать: «но ведь клиент колоссально уязвим вон там» или «баг есть баг, а у плохих парней нет скоупа», но вы все равно должны придерживаться скоупа. Если вы думаете: «но если я выйду за рамки скоупа, я с большей вероятностью найду то, чего не ищет никто другой», то вы ведет себя не очень хорошо. Вам предоставили возможность изучить определенные вещи либо потому, что на это были выделены средства на тестирование, либо потому, что для клиента риск тестирования в другом месте сейчас слишком высок. Разочарование от отклонения отчета вне скоупа и раздражение, которое вы вызовете у клиента ковырянием в том, в чем они не хотели ковыряться, того не стоят.
Уделите пристальное внимание приоритетной зоне клиента, если таковая имеется. Довольный клиент — это обычно хорошо платящий клиент. Если у вас создается впечатление, что их приоритетная зона также тщательно изучалась разработчиками и там особо нечего ловить, попробуйте, а затем двигайтесь дальше и задайте им жару в другом месте.
Всегда доводите дело до конца (Always Be Closing). Клиенты часто осознают всю серьезность бага или доведут его до логического завершения (и заплатят на его основе), до которого вы не докопались или не смогли докопаться, но на случай, если они устранят баг, не оценив его полный масштаб, заявите о себе. Напишите немного JavaScript, который обходит CSRF или извлекает конфиденциальные данные из DOM, чтобы они не расслаблялись в духе «Ну, наши куки HttpOnly, так что XSS нам не страшен». Найдите способ обойти их CSP. Напишите скрипт, который перебирает IDOR, если (и только если) вы находитесь в тестовой песочнице и не будете затрагивать конфиденциальные данные клиентов.
Как только вы детализировали баг, напишите отличный отчетов — не позволяйте вашему крутому багу быть испорченным двухминутной отпиской «и так сойдет». Сделайте его сияющим. Хороший баг, описанный плохо — это плохой отчет. Сделайте такой отчет, который можно будет показать руководству в качестве обоснования расходов на программу.
Копать глубоко и хорошо составлять отчеты — это весело, вы будете больше довольны своей собственной работой, и вас часто будут вознаграждать за это лучше.
И наконец, заводите знакомства! Большинство из нас в основном нормальные ребята. Учитесь у других, учите других, ведите блоги, болтайте в Twitter, знайте свои инструменты, всегда учитесь, развивайте свои методологии, будьте в тонусе и получайте удовольствие!
Что вы думаете о будущем программ bug bounty? Куда, по вашему мнению, они движутся и куда бы вы хотели, чтобы они двигались?
Часть меня верит, что у bug bounty светлое будущее. Компьютеры — это сложно, у разработчиков в голове крутится гораздо больше, чем просто безопасность, а давление со стороны клиентов и менеджеров продуктов заставляет их делать все возможное с тем, что у них есть. Толпа исследователей — это фантастический и гибкий ресурс контроля качества, который может прийти на помощь и собрать то, что упало на пол. Учитывая текущее положение дел и эффективность краудсорсинга, я не думаю, что ему что-то серьезно угрожает.
Тем не менее, я действительно надеюсь, что по мере дальнейшего технического развития программной инженерии (например, в части фреймворков и средств минимизации уязвимостей), а также по мере того, как компании осознают преимущества качественного жизненного цикла разработки ПО (SDLC) и проактивной, тщательной разработки, отпадет часть необходимости в ретроспективном контроле безопасности. Возможно, краудсорсинг останется востребованным, но со временем багов станет меньше (что будет компенсировано некоторым увеличением вознаграждений за обнаружение каждого отдельного бага). [Примечание редактора: это откроет для краудсорсинга новые и интересные возможности!]
Во мне как в эгоистичном охотнике за баунти мало что хочет меняться, но если через 5 или 10 лет мы все еще будем заниматься поиском XSS, как сегодня, значит, что-то идет не так. Нам необходимо уделять внимание проактивной инженерии безопасности в той же степени, в какой мы продолжаем реактивное обеспечение безопасности разработанных систем.
[Обсудите этот материал в центре внимания на форумах Bugcrowd]
