Эта статья будет ответом на недавнюю публикацию Владимира Таратушка.
Причин написания статьи у меня было несколько.
Первая — это показать, что белые хакеры в Украине есть. Существуют они благодаря одной из программ поощрения поиска уязвимостей, которую проводит Приватбанк.
Следующая причина — это рассказать свою success story работы с одним из крупнейшим банком Украины в рамках данной программы.
Так же я хочу показать эффективность работы такой программы на реальном примере и сподвигнуть к организации таких программ те компании, которые по каким то причинам сомневаются или не видят в них реальных плюсов.
Ну и последняя причина — показать будущим и настоящим ресёчерам, что участие в баг-баунти программах интересно, этично и материально выгодно.
Я не считаю себя профессиональным хакером, я не имею профильного образования в области безопасности, у меня нет сертификатов, я не читал талмуд спецификации TCP/IP протокола и я не участвовал в хакатонах и прочих соревнованиях профессиональных хакеров. В то же время у меня есть опыт программирования и написания различных веб-сервисов на PHP, Python, Java. И я примерно понимаю, где обычно программисты допускают ошибки и какие аспекты безопасности игнорируют при разработке веб-приложений. Для меня этого достаточно, что бы успешно находить уязвимости самого критичного уровня.
На данный момент мой опыт как ресёчера составляет 3 года. Именно столько времени я принимаю участие в программе поиска уязвимостей ПриватБанка.
С самого начала я вёл учёт всех найденных уязвимостей. Я сохранял в отдельный файл детальное описание уязвимости, способа воспроизведения, скриншоты подтверждения. Последние помогают, если по какой-то причине разработчикам банка не удаётся воспроизвести уязвимость, либо она оказывается закрытой очередным апдейтом до начала проверки. Спустя некоторое время я начал заносить в файл время подачи заявки, время фикса, сумму вознаграждения. Благодаря этому у меня есть некоторая статистика, с которой я хотел бы вас сегодня познакомить.
Итак, на данный момент у меня собрана статистика по 55 заявленным мною уязвимостям, все из которых на данный момент закрыты.
Согласно статистике по статусам заявок, картина следующая:
![](https://habrastorage.org/r/w1560/files/c71/121/4a5/c711214a56a144b8935ab3eb05a923ae.png)
Как видно, большинство заявок принимаются в работу. Некоторый уязвимости не были воспроизведены разработчиками банка по причине их сложности либо потому, что на момент того, как уязвимость брали в работу, данный сервис был кардинально переписан. Так же бывали дубликаты, но как правило это были простые, легко обнаружимые уязвимости. N/A — это значит, что по какой-то причине я не сохранил результатов по данной заявке. Все заявки со статусом “принята” в итоге были закрыты и за них были выплачены вознаграждения.
Тип уязвимости/атаки по классификации OWASP:
По классификации уязвимостей видно, что самый распространнёный тип — это Broken Access Control. Это те уязвимости, которые позволяют получить не авторизованный доступ простым перебором инкерментальных значений, которые задают id пользователя или операции. Причина в том, что такие уязвимости легче всего обнаружить и они являются следствием ошибок в архитектуре приложения. Так как банк — это сложная система многочисленных внутренних взаимодействующих друг с другом подсистем, таких как back-офис, процессинг, антифрод, это накладывает определённые трудности на реализацию взаимодействия веб-приложения с этими системами в рамках прав конечного пользователя сервиса. Это приводит к появлению таких уязвимостей, как доступ к выпискам по картам других пользователей, доступ к приватным данным и в конце концов, к доступу к финансовых средствам пользователей.
Так же безусловно отпечаток на этот рейтинг откладывают мои личные предпочтения и набор знаний, которым я обладаю и который я использую при поиске уязвимостей.
Тип получаемой информации или доступа в случае эксплуатации уязвимости:
![](https://habrastorage.org/r/w1560/files/649/7a8/6a8/6497a86a8b97402b89bb83087f863b2f.png)
Как видно по статистике, чаще всего удавалось получить доступ к приватным данным (ФИО, паспортные данные, номера карт, телефонов, адресов), финансовым данным (баланс счёта, выписки и тд.), аккаунтам в разных сервисах(как правило благодаря XSS или Open Redirect) и, что не маловажно, в 1 из 5 случаев доступ к финансовым средствам других пользователей.
Время фикса. Это условная величина. Так как я не обладал информацией о точном времени закрытия уязвимости, я брал время, которое прошло с момента подачи заявки и до оповещения о планируемой выплате вознаграждения.
![](https://habrastorage.org/r/w1560/files/ff4/bf8/a50/ff4bf8a503b240ad9a8590c46b8dad08.png)
Как видно, чаще всего оповещение приходило в пределах 2-х месяцев, но иногда по некоторым уязвимостям не было ответа по 3-4 месяца.
Ну и естественно, самый интересный момент для исследователей — это средний размер вознаграждения по закрытым заявкам. Сразу предупрежу, сумма вознаграждения не привязывалась к курсу доллара до середины 2015 года, поэтому какое-то время она уменьшалась в долларовом эквиваленте в связи со стремительным ростом курса доллара к гривне.
![](https://habrastorage.org/r/w1560/files/72a/515/5a1/72a5155a1bee45d181a54d1fee4b515c.png)
Как видно, чаще всего сумма вознаграждения попадает в диапазон $50-500.
Теперь немного деталей. Ниже я собрал длинный список с кратким описанием по каждой уязвимости, что бы можно было составить приблизительное представление о критичность каждой из них:
Таким образом, анализируя критичность перечисленных выше уязвимостей, вы можете оценить эффективность данной программы для банка.
Ну и напоследок, я хотел бы развеять стойкое, но ошибочное мнение многих, что с ПриватБанком лучше не работать, так как они могут обвинить в взломе, как это было описано в истории с Алексеем Моховым.
Главный принцип белого хакера — это этичность. Поиск уязвимостей должен проводиться исключительно на аккаунтах и счетах самих “взломщиков” либо их родственников/друзей/знакомых с их личного разрешения. Так же, если поиск уязвимости осуществлялся в рамках баг-баунти программы, раскрывать информацию о ней стоит только после её закрытия и только с разрешения владельца ресурса, на котором она была найдена. Тогда все ваши действия не будут осуществлять в ущерб компании и не будут нарушать закон, а поэтому претензий к вам, как к исследователю, не будет.
Причин написания статьи у меня было несколько.
Первая — это показать, что белые хакеры в Украине есть. Существуют они благодаря одной из программ поощрения поиска уязвимостей, которую проводит Приватбанк.
Следующая причина — это рассказать свою success story работы с одним из крупнейшим банком Украины в рамках данной программы.
Так же я хочу показать эффективность работы такой программы на реальном примере и сподвигнуть к организации таких программ те компании, которые по каким то причинам сомневаются или не видят в них реальных плюсов.
Ну и последняя причина — показать будущим и настоящим ресёчерам, что участие в баг-баунти программах интересно, этично и материально выгодно.
Я не считаю себя профессиональным хакером, я не имею профильного образования в области безопасности, у меня нет сертификатов, я не читал талмуд спецификации TCP/IP протокола и я не участвовал в хакатонах и прочих соревнованиях профессиональных хакеров. В то же время у меня есть опыт программирования и написания различных веб-сервисов на PHP, Python, Java. И я примерно понимаю, где обычно программисты допускают ошибки и какие аспекты безопасности игнорируют при разработке веб-приложений. Для меня этого достаточно, что бы успешно находить уязвимости самого критичного уровня.
На данный момент мой опыт как ресёчера составляет 3 года. Именно столько времени я принимаю участие в программе поиска уязвимостей ПриватБанка.
С самого начала я вёл учёт всех найденных уязвимостей. Я сохранял в отдельный файл детальное описание уязвимости, способа воспроизведения, скриншоты подтверждения. Последние помогают, если по какой-то причине разработчикам банка не удаётся воспроизвести уязвимость, либо она оказывается закрытой очередным апдейтом до начала проверки. Спустя некоторое время я начал заносить в файл время подачи заявки, время фикса, сумму вознаграждения. Благодаря этому у меня есть некоторая статистика, с которой я хотел бы вас сегодня познакомить.
Итак, на данный момент у меня собрана статистика по 55 заявленным мною уязвимостям, все из которых на данный момент закрыты.
Согласно статистике по статусам заявок, картина следующая:
![](https://habrastorage.org/files/c71/121/4a5/c711214a56a144b8935ab3eb05a923ae.png)
Как видно, большинство заявок принимаются в работу. Некоторый уязвимости не были воспроизведены разработчиками банка по причине их сложности либо потому, что на момент того, как уязвимость брали в работу, данный сервис был кардинально переписан. Так же бывали дубликаты, но как правило это были простые, легко обнаружимые уязвимости. N/A — это значит, что по какой-то причине я не сохранил результатов по данной заявке. Все заявки со статусом “принята” в итоге были закрыты и за них были выплачены вознаграждения.
Тип уязвимости/атаки по классификации OWASP:
![](https://habrastorage.org/files/488/a9d/5e0/488a9d5e0787474db2d8f4d6ccb16849.png)
Так же безусловно отпечаток на этот рейтинг откладывают мои личные предпочтения и набор знаний, которым я обладаю и который я использую при поиске уязвимостей.
Тип получаемой информации или доступа в случае эксплуатации уязвимости:
![](https://habrastorage.org/files/649/7a8/6a8/6497a86a8b97402b89bb83087f863b2f.png)
Как видно по статистике, чаще всего удавалось получить доступ к приватным данным (ФИО, паспортные данные, номера карт, телефонов, адресов), финансовым данным (баланс счёта, выписки и тд.), аккаунтам в разных сервисах(как правило благодаря XSS или Open Redirect) и, что не маловажно, в 1 из 5 случаев доступ к финансовым средствам других пользователей.
Время фикса. Это условная величина. Так как я не обладал информацией о точном времени закрытия уязвимости, я брал время, которое прошло с момента подачи заявки и до оповещения о планируемой выплате вознаграждения.
![](https://habrastorage.org/files/ff4/bf8/a50/ff4bf8a503b240ad9a8590c46b8dad08.png)
Как видно, чаще всего оповещение приходило в пределах 2-х месяцев, но иногда по некоторым уязвимостям не было ответа по 3-4 месяца.
Ну и естественно, самый интересный момент для исследователей — это средний размер вознаграждения по закрытым заявкам. Сразу предупрежу, сумма вознаграждения не привязывалась к курсу доллара до середины 2015 года, поэтому какое-то время она уменьшалась в долларовом эквиваленте в связи со стремительным ростом курса доллара к гривне.
![](https://habrastorage.org/files/72a/515/5a1/72a5155a1bee45d181a54d1fee4b515c.png)
Как видно, чаще всего сумма вознаграждения попадает в диапазон $50-500.
Теперь немного деталей. Ниже я собрал длинный список с кратким описанием по каждой уязвимости, что бы можно было составить приблизительное представление о критичность каждой из них:
Таблица уязвимостей
№ | Домен | Тип уязвимости/атаки (OWASP) | Тип доступа | Краткое описание |
---|---|---|---|---|
1 | privat24.privatbank.ua | Broken Access Control | Приватные данные | Получение критичных данных любой карты |
2 | privat24.privatbank.ua | Broken Access Control | Приватные данные | Доступ к архиву платежей пользователей |
3 | privat24.privatbank.ua | Broken Access Control | Приватные данные | Доступ к приватным данным пользователей (ФИО, паспортные данные, сумма остатка и задолженности) |
4 | privat24.privatbank.ua | Broken Access Control | Приватные данные | Доступ к приватным данным пользователей (ФИО, паспортные данные, девичья фамилия матери) |
5 | privat24.privatbank.ua | Broken Access Control | Финансовые данные | Просмотр выписок по номеру карты |
6 | privat24.privatbank.ua | Broken Access Control | Финансовые операции | Оплата sms рассылки с чужой карты |
7 | liqpay.com | Broken Access Control | Финансовые данные | Данные по платежам клиентов |
8 | napi.privatbank.ua | Broken Access Control | Приватные данные | Получение критичных данных чужой интернет карты |
9 | napi.privatbank.ua | Broken Access Control | Финансовые данные | Покупка авто/жд билетов по чужой карте |
10 | privat24.privatbank.ua | Broken Access Control | Финансовые операции | Создание регулярного платежа по чужой карте |
11 | pcalendar.privatbank.ua | Broken Access Control | Финансовые операции | Изменение статуса любого регулярного платежа, пересоздание, даже если он был удален, просмотр данных по нему |
12 | siteheart.com | Session Variable Overloading | Доступ к аккаунту | Полный доступ к любому аккаунту siteheart.com |
13 | privat24.privatbank.ua | CSRF | Приватные данные | Подключение своего телефона к смс-информированию об операциях по чужой карте |
14 | privat24.privatbank.ua | Broken Access Control | Финансовые операции | Создание регулярного платежа по чужой карте |
15 | cards.privatbank.ua | XSS | Доступ к аккаунту | Кража куки авторизованного пользователя |
16 | privat24.privatbank.ua | Broken Access Control | Финансовые операции | Массовое пополнение мобильных телефонов с чужой карты |
17 | ecommerce.liqpay.com | Broken Access Control | Финансовые операции | Платеж с чужой карты при оплате услуг на сайте мерчанта, подключенного к ПриватБанку |
18 | privat24.privatbank.ua | Broken Access Control | Приватные данные | Получение номеров телефонов, подключенных к услуге SMS-уведомления для любой карты ПриватБанка |
19 | privat24.privatbank.ua | Broken Access Control | Приватные данные | Просмотр информации по коммунальным платежам клиентов приват24 (ФИО, адрес проживания, моб. телефон, задолженность) |
20 | pcalendar.privatbank.ua | Broken Access Control | Финансовые данные | Баланс по любой карте ПриватБанка |
21 | pcalendar.privatbank.ua | Broken Access Control | Финансовые операции | Создание регулярного платежа по чужой карте |
22 | pcalendar.privatbank.ua | Broken Access Control | Финансовые операции | Создание регулярного платежа по чужой карте |
23 | privat24.privatbank.ua | Insecure Configuration | Серверные данные | Открыта структура каталогов |
24 | privat24.privatbank.ua | Broken Access Control | Операция модификации | Получение и изменение интернет-лимита по любой карте ПриватБанка |
25 | privat24.privatbank.ua | Broken Access Control | Финансовые данные | Просмотр выписок по номеру карты, присутствуют адреса и gps координаты банкоматов и терминалов самообслуживания, которыми пользуется клиент |
26 | privat24.privatbank.ua | Insecure Configuration | Финансовые данные | Доступны Google чеки |
27 | transfers.privatbank.ua | Broken Access Control | Финансовые данные | Информация по переводам в приват24 (PrivatMoney, Золотая корона, Unistream, Western Union, Contact, Coinstar и Swift) |
28 | privat24.privatbank.ua | Broken Access Control | Финансовые операции | Создание регулярного платежа по чужой карте |
29 | privat24.privatbank.ua | Broken Access Control | Приватные данные | Просмотр информации по коммунальным платежам клиентов приват24 (ФИО, адрес проживания, моб. телефон, задолженность) |
30 | privat24.privatbank.ua | Broken Access Control | Финансовые данные | Информация по заявкам на кредитный рейтинг в УБКИ (ФИО, ИНН, дата рождения, кредитный рейтинг и пр.) |
31 | client-bank.privatbank.ua | Broken Access Control | Финансовые данные | Получение выписки по эквайрингу по любому мерчанту ПриватБанка |
32 | client-bank.privatbank.ua | Broken Access Control | Пароли | Получение пароля любого мерчанта, зарегистрированного в приват24 в эквайринге. Помимо пароля доступен номер карты для приёма платежей, название клиента, адрес сайта клиента, ip адрес и пр. |
33 | limit.pb.ua | Broken Authentication and Session Management | Приватные данные | Подробная информация по клиенту (ФИО, номера карт, телефонов, дата рождения, адреса проживания и т.д.) |
34 | privat24.privatbank.ua | Broken Access Control | Приватные данные | Получение по номеру карты ФИО владельца, номера телефона, срока действия карты |
35 | socauth.privatbank.ua | Insecure Configuration | Приватные данные | Подробная информация по клиенту (ФИО, номера карт, телефонов, дата рождения, адреса проживания и т.д.) |
36 | privat24.privatbank.ua | Broken Authentication and Session Management | Доступ к аккаунту | Многократно вход в приват24 по сформированной ссылке без ввода статического и отп пароля даже после окончания действия сессии ользователя |
37 | chat.sender.mobi | XSS | Доступ к аккаунту | Кража куки авторизованного пользователя |
38 | msb.privatbank.ua | XSS | Доступ к аккаунту | Кража куки авторизованного пользователя |
39 | mypayments.privatbank.ua | Broken Authentication and Session Management | Приватные данные | Подробная информация по клиенту (ФИО, номера карт, телефонов, дата рождения, адреса проживания и т.д.) |
40 | privat24.privatbank.ua | Broken Authentication and Session Management | Финансовые данные | Выписки по картам пользователей. |
41 | liqpay.com | Broken Authentication and Session Management | Доступ к аккаунту | Cлабая защита сессии пользователя при авторизации через звонок на мобильный телефон |
42 | client-bank.privatbank.ua | Broken Access Control | Финансовые данные | Выписки по любому терминалу, подключенному к эквайрингу. |
43 | client-bank.privatbank.ua | Broken Access Control | Финансовые данные | Просмотр документов юр. лиц, созданных при помощи конструктора документов |
44 | chat.sender.mobi | XSS | Доступ к аккаунту | Кража куки авторизованного пользователя |
45 | bank24.privatbank.ua | XSS | Доступ к аккаунту | Кража куки авторизованного пользователя |
46 | blago.privatbank.ua | Broken Access Control | Финансовые операции | Уязвимость позволяет любому зарегистрированному пользователю подменить карту любого другого пользователя на свою для получения пожертвований |
47 | client-bank.privatbank.ua | Broken Access Control | Финансовые данные | Информация по чужим договорам с зарубежными партнерами |
48 | client-bank.privatbank.ua | Broken Access Control | Приватные данные | Информация о пользователях, имеющих доступ к указанному счёту, а именно логин(иногда это номер телефона), ФИО, email. |
49 | privat24.privatbank.ua | Broken Access Control | Операция модификации | Массовое измение (как минимум уменьшение) кредитных лимитов по картам клиентов ПриватБанка |
50 | nkk.privatbank.ua | Broken Access Control | Приватные данные | Доступ к информации, которую клиент заполняет при оформлении заявки на кредит |
51 | privat24.privatbank.ua | Redirects and forwards | Доступ к аккаунту | Доступ к аккаунту пользователя через токен, полученный через Open Redirect |
52 | client-bank.privatbank.ua | Broken Authentication and Session Management | Доступ к аккаунту | Доступ к аккаунту пользователя через токен, полученный через referer на сайте статистики |
53 | client-bank.privatbank.ua | Redirects and forwards | Доступ к аккаунту | Доступ к аккаунту пользователя через фишинг, используя Open Redirect |
54 | client-bank.privatbank.ua | Broken Authentication and Session Management | Доступ к аккаунту | Доступ к аккаунту пользователя через токен, полученный через referer на сайте статистики |
55 | client-bank.privatbank.ua | Broken Access Control | Финансовые данные | Доступ к к договорам с зарубежными партнерами клиентов |
Таким образом, анализируя критичность перечисленных выше уязвимостей, вы можете оценить эффективность данной программы для банка.
Ну и напоследок, я хотел бы развеять стойкое, но ошибочное мнение многих, что с ПриватБанком лучше не работать, так как они могут обвинить в взломе, как это было описано в истории с Алексеем Моховым.
Главный принцип белого хакера — это этичность. Поиск уязвимостей должен проводиться исключительно на аккаунтах и счетах самих “взломщиков” либо их родственников/друзей/знакомых с их личного разрешения. Так же, если поиск уязвимости осуществлялся в рамках баг-баунти программы, раскрывать информацию о ней стоит только после её закрытия и только с разрешения владельца ресурса, на котором она была найдена. Тогда все ваши действия не будут осуществлять в ущерб компании и не будут нарушать закон, а поэтому претензий к вам, как к исследователю, не будет.