Я являюсь клиентом украинского оператора сотовой связи Киевстар и пользователем их веб-сервиса my.kyivstar.ua. Как и многие другие операторы, Киевстар предлагает веб-версию личного кабинета, в котором можно просмотреть баланс счёта, детализацию звонков, изменить тариф, заказать или отключить услугу и пр.
Так же у них недавно была запущена новая версия личного кабинета new.kyivstar.ua. В ней появилась интересная функция — добавление другого телефона Киевстар через смс верификацию. Я взялся её проверить на наличие уязвимостей, так как она фактически давала такой же доступ к добавляемому телефону, как и к своему, что меня не особо радовало, как клиента.
Новый сайт имеет следующий интерфейс добавления телефона:
Добавление производится в 4 шага:
Ввод номера телефона
Выбор варианта через присоединения по смс (бывает ещё через статический пароль, но у меня он не отображается)
Ввод полученной смс.
Подтверждение.
Эти 4 шага преобразуются в серию POST и GET запросов. Последние три запроса из этой серии отвечают за добавление номера после пройденной ОТП верификации.
И я решил проверить: что, если повторить эти запросы без тех, что отвечают за СМС верификацию.
Рассмотрим более детально эти последние 3 запроса.
Они имеют следующий вид в инструменте разработчика Google Chrome (Shift+Ctrl+I):
Запросы merge.rpc отправляются на адрес account.kyivstar.ua/cas/merge/merge.rpc.
Содержимое первого запроса:
Запрос содержит номер добавляемого телефона(097...)
Содержимое второго запроса:
Третий запрос на адрес new.kyivstar.ua/ecare/addOrMerge — это GET запрос без параметров, подтверждающий предыдущие две операции.
Далее я решил повторно воспроизвести эти 3 запроса, предварительно удалив добавленный только-что телефон из личного кабинета.
Для воспроизведения я использовал приложение Postman.
Как и предполагалось, после обновления страницы, телефон был успешно добавлен в личный кабинет.
Что мы имеем.
Мы можем добавлять любой номер телефона в свой личный кабинет без СМС верификации и управлять им как своим, а именно:
Лучшего подарка мошенникам и не придумаешь.
Как и полагается, я сразу связался с клиентской поддержкой Киевстар и попросил предоставить мне контакты службы безопасности или ответственного сотрудника отдела разработки, что бы им детально описать суть уязвимости и способ её воспроизведения. Как и стоило ожидать, мне отказали в моей просьбе и предложили прислать описание уязвимости либо в чат, либо через универсальную форму на сайте.
Понимая, какие возможны риски, если подробное описание уязвимости будет доступно любому сотруднику клиентской поддержки, я всё таки настоял на своей просьбе, но опять же безуспешно. Понимая, что другого выхода нет, я оформил подробную инструкцию по воспроизведению уязвимости в файлик Google Docs, завернул его в ссылку через сервис для трекания ссылок clickmeter.com и отправил в чат.
Как я и ожидал, моя заявка вызвала ажиотаж и повышенный интерес среди сотрудников компании, что отобразилось в аналитике сервиса clickmeter.com:
Заявку за 2 дня просмотрел 22 уникальный пользователь.
По статистике видно, что ссылку смотрели как с компьютеров, так и с мобильных устройств. География просмотров так же не ограничилась киевским офисом, в списке Киев, Львов, Днепропетровск, Тбилиси.
Анализируя статистику, становится ясно, что существующий канал связи с компанией не предназначен для подачи заявок подобного рода и может привести к утечке информации и эксплуатации её сторонними лицами до закрытия уязвимости.
Стоит отдать должное компании, ответственный сотрудник со мной связался на второй день, поблагодарил и попросил убрать ссылку из общего доступа. В течении следующих нескольких недель уязвимость была закрыта, и со мной повторно связались и сообщили о том, что заявка выполнена.
Эта история напоминает нам о том, что нужно более внимательно относиться к вопросам информационной безопасности в компаниях таких масштабов, как Киевстар, создавать для этого отдельные каналы связи, доступ к которым будут иметь только уполномоченные на это сотрудники. Ну а так же участие компании в bug-bounty программах или создание своей собственной так же положительно влияет на укрепление безопасности сервисов.
Так же у них недавно была запущена новая версия личного кабинета new.kyivstar.ua. В ней появилась интересная функция — добавление другого телефона Киевстар через смс верификацию. Я взялся её проверить на наличие уязвимостей, так как она фактически давала такой же доступ к добавляемому телефону, как и к своему, что меня не особо радовало, как клиента.
Новый сайт имеет следующий интерфейс добавления телефона:
Добавление производится в 4 шага:
Ввод номера телефона
Выбор варианта через присоединения по смс (бывает ещё через статический пароль, но у меня он не отображается)
Ввод полученной смс.
Подтверждение.
Эти 4 шага преобразуются в серию POST и GET запросов. Последние три запроса из этой серии отвечают за добавление номера после пройденной ОТП верификации.
И я решил проверить: что, если повторить эти запросы без тех, что отвечают за СМС верификацию.
Рассмотрим более детально эти последние 3 запроса.
Они имеют следующий вид в инструменте разработчика Google Chrome (Shift+Ctrl+I):
Запросы merge.rpc отправляются на адрес account.kyivstar.ua/cas/merge/merge.rpc.
Содержимое первого запроса:
Запрос содержит номер добавляемого телефона(097...)
Содержимое второго запроса:
Третий запрос на адрес new.kyivstar.ua/ecare/addOrMerge — это GET запрос без параметров, подтверждающий предыдущие две операции.
Далее я решил повторно воспроизвести эти 3 запроса, предварительно удалив добавленный только-что телефон из личного кабинета.
Для воспроизведения я использовал приложение Postman.
Как и предполагалось, после обновления страницы, телефон был успешно добавлен в личный кабинет.
Что мы имеем.
Мы можем добавлять любой номер телефона в свой личный кабинет без СМС верификации и управлять им как своим, а именно:
- просматривать баланс и детализацию звонков
- просматривать PUK1 код и серийный номер SIM-карты, что позволяет самостоятельно заменить сим-карту
- добавлять новые услуги и менять тарифный план
- и самое главное — переводить деньги с телефона на телефон
Лучшего подарка мошенникам и не придумаешь.
Как и полагается, я сразу связался с клиентской поддержкой Киевстар и попросил предоставить мне контакты службы безопасности или ответственного сотрудника отдела разработки, что бы им детально описать суть уязвимости и способ её воспроизведения. Как и стоило ожидать, мне отказали в моей просьбе и предложили прислать описание уязвимости либо в чат, либо через универсальную форму на сайте.
Понимая, какие возможны риски, если подробное описание уязвимости будет доступно любому сотруднику клиентской поддержки, я всё таки настоял на своей просьбе, но опять же безуспешно. Понимая, что другого выхода нет, я оформил подробную инструкцию по воспроизведению уязвимости в файлик Google Docs, завернул его в ссылку через сервис для трекания ссылок clickmeter.com и отправил в чат.
Как я и ожидал, моя заявка вызвала ажиотаж и повышенный интерес среди сотрудников компании, что отобразилось в аналитике сервиса clickmeter.com:
Заявку за 2 дня просмотрел 22 уникальный пользователь.
По статистике видно, что ссылку смотрели как с компьютеров, так и с мобильных устройств. География просмотров так же не ограничилась киевским офисом, в списке Киев, Львов, Днепропетровск, Тбилиси.
Анализируя статистику, становится ясно, что существующий канал связи с компанией не предназначен для подачи заявок подобного рода и может привести к утечке информации и эксплуатации её сторонними лицами до закрытия уязвимости.
Стоит отдать должное компании, ответственный сотрудник со мной связался на второй день, поблагодарил и попросил убрать ссылку из общего доступа. В течении следующих нескольких недель уязвимость была закрыта, и со мной повторно связались и сообщили о том, что заявка выполнена.
Эта история напоминает нам о том, что нужно более внимательно относиться к вопросам информационной безопасности в компаниях таких масштабов, как Киевстар, создавать для этого отдельные каналы связи, доступ к которым будут иметь только уполномоченные на это сотрудники. Ну а так же участие компании в bug-bounty программах или создание своей собственной так же положительно влияет на укрепление безопасности сервисов.