Почему в Украине всё-таки есть белые хакеры

Эта статья будет ответом на недавнюю публикацию Владимира Таратушка.
Причин написания статьи у меня было несколько.
Первая — это показать, что белые хакеры в Украине есть. Существуют они благодаря одной из программ поощрения поиска уязвимостей, которую проводит Приватбанк.
Следующая причина — это рассказать свою success story работы с одним из крупнейшим банком Украины в рамках данной программы.
Так же я хочу показать эффективность работы такой программы на реальном примере и сподвигнуть к организации таких программ те компании, которые по каким то причинам сомневаются или не видят в них реальных плюсов.
Ну и последняя причина — показать будущим и настоящим ресёчерам, что участие в баг-баунти программах интересно, этично и материально выгодно.

Я не считаю себя профессиональным хакером, я не имею профильного образования в области безопасности, у меня нет сертификатов, я не читал талмуд спецификации TCP/IP протокола и я не участвовал в хакатонах и прочих соревнованиях профессиональных хакеров. В то же время у меня есть опыт программирования и написания различных веб-сервисов на PHP, Python, Java. И я примерно понимаю, где обычно программисты допускают ошибки и какие аспекты безопасности игнорируют при разработке веб-приложений. Для меня этого достаточно, что бы успешно находить уязвимости самого критичного уровня.

На данный момент мой опыт как ресёчера составляет 3 года. Именно столько времени я принимаю участие в программе поиска уязвимостей ПриватБанка.

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

Итак, на данный момент у меня собрана статистика по 55 заявленным мною уязвимостям, все из которых на данный момент закрыты.

Согласно статистике по статусам заявок, картина следующая:



Как видно, большинство заявок принимаются в работу. Некоторый уязвимости не были воспроизведены разработчиками банка по причине их сложности либо потому, что на момент того, как уязвимость брали в работу, данный сервис был кардинально переписан. Так же бывали дубликаты, но как правило это были простые, легко обнаружимые уязвимости. N/A — это значит, что по какой-то причине я не сохранил результатов по данной заявке. Все заявки со статусом “принята” в итоге были закрыты и за них были выплачены вознаграждения.

Тип уязвимости/атаки по классификации OWASP:

По классификации уязвимостей видно, что самый распространнёный тип — это Broken Access Control. Это те уязвимости, которые позволяют получить не авторизованный доступ простым перебором инкерментальных значений, которые задают id пользователя или операции. Причина в том, что такие уязвимости легче всего обнаружить и они являются следствием ошибок в архитектуре приложения. Так как банк — это сложная система многочисленных внутренних взаимодействующих друг с другом подсистем, таких как back-офис, процессинг, антифрод, это накладывает определённые трудности на реализацию взаимодействия веб-приложения с этими системами в рамках прав конечного пользователя сервиса. Это приводит к появлению таких уязвимостей, как доступ к выпискам по картам других пользователей, доступ к приватным данным и в конце концов, к доступу к финансовых средствам пользователей.

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

Тип получаемой информации или доступа в случае эксплуатации уязвимости:



Как видно по статистике, чаще всего удавалось получить доступ к приватным данным (ФИО, паспортные данные, номера карт, телефонов, адресов), финансовым данным (баланс счёта, выписки и тд.), аккаунтам в разных сервисах(как правило благодаря XSS или Open Redirect) и, что не маловажно, в 1 из 5 случаев доступ к финансовым средствам других пользователей.

Время фикса. Это условная величина. Так как я не обладал информацией о точном времени закрытия уязвимости, я брал время, которое прошло с момента подачи заявки и до оповещения о планируемой выплате вознаграждения.



Как видно, чаще всего оповещение приходило в пределах 2-х месяцев, но иногда по некоторым уязвимостям не было ответа по 3-4 месяца.

Ну и естественно, самый интересный момент для исследователей — это средний размер вознаграждения по закрытым заявкам. Сразу предупрежу, сумма вознаграждения не привязывалась к курсу доллара до середины 2015 года, поэтому какое-то время она уменьшалась в долларовом эквиваленте в связи со стремительным ростом курса доллара к гривне.



Как видно, чаще всего сумма вознаграждения попадает в диапазон $50-500.

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


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

Ну и напоследок, я хотел бы развеять стойкое, но ошибочное мнение многих, что с ПриватБанком лучше не работать, так как они могут обвинить в взломе, как это было описано в истории с Алексеем Моховым.

Главный принцип белого хакера — это этичность. Поиск уязвимостей должен проводиться исключительно на аккаунтах и счетах самих “взломщиков” либо их родственников/друзей/знакомых с их личного разрешения. Так же, если поиск уязвимости осуществлялся в рамках баг-баунти программы, раскрывать информацию о ней стоит только после её закрытия и только с разрешения владельца ресурса, на котором она была найдена. Тогда все ваши действия не будут осуществлять в ущерб компании и не будут нарушать закон, а поэтому претензий к вам, как к исследователю, не будет.