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