Добавляем произвольный телефон в личном кабинете оператора мобильной связи Киевстар (Украина)

Я являюсь клиентом украинского оператора сотовой связи Киевстар и пользователем их веб-сервиса my.kyivstar.ua. Как и многие другие операторы, Киевстар предлагает веб-версию личного кабинета, в котором можно просмотреть баланс счёта, детализацию звонков, изменить тариф, заказать или отключить услугу и пр.
Так же у них недавно была запущена новая версия личного кабинета new.kyivstar.ua. В ней появилась интересная функция — добавление другого телефона Киевстар через смс верификацию. Я взялся её проверить на наличие уязвимостей, так как она фактически давала такой же доступ к добавляемому телефону, как и к своему, что меня не особо радовало, как клиента.
Новый сайт имеет следующий интерфейс добавления телефона:
b32aa701271b4198800fe270a7a33b8e.png

Добавление производится в 4 шага:
Ввод номера телефона
40bf6a0e8092490eb1449cd72e23dda3.png

Выбор варианта через присоединения по смс (бывает ещё через статический пароль, но у меня он не отображается)
1e538b3e343d4b92bf42759ea1a150e5.png

Ввод полученной смс.
86f05442948547a39562f968e509dcfa.png

Подтверждение.

Эти 4 шага преобразуются в серию POST и GET запросов. Последние три запроса из этой серии отвечают за добавление номера после пройденной ОТП верификации.
И я решил проверить: что, если повторить эти запросы без тех, что отвечают за СМС верификацию.
Рассмотрим более детально эти последние 3 запроса.
Они имеют следующий вид в инструменте разработчика Google Chrome (Shift+Ctrl+I):
7a28c989bdb948f3858115da8a7a9ed3.png

Запросы merge.rpc отправляются на адрес account.kyivstar.ua/cas/merge/merge.rpc.
Содержимое первого запроса:
a0f86ea36d2f4d1dbb344cab40fe6780.png

Запрос содержит номер добавляемого телефона (097…)
Содержимое второго запроса:
c1f811deb9b84d50a403743b8a89ead6.png

Третий запрос на адрес new.kyivstar.ua/ecare/addOrMerge — это GET запрос без параметров, подтверждающий предыдущие две операции.

Далее я решил повторно воспроизвести эти 3 запроса, предварительно удалив добавленный только-что телефон из личного кабинета.
Для воспроизведения я использовал приложение Postman.
1f4cae27a8604e60994c3a663c964d48.png

Как и предполагалось, после обновления страницы, телефон был успешно добавлен в личный кабинет.
677b3a6ea6fe4e8481f3eb6f2588ea0a.png

Что мы имеем.
Мы можем добавлять любой номер телефона в свой личный кабинет без СМС верификации и управлять им как своим, а именно:

  • просматривать баланс и детализацию звонков
  • просматривать PUK1 код и серийный номер SIM-карты, что позволяет самостоятельно заменить сим-карту
  • добавлять новые услуги и менять тарифный план
  • и самое главное — переводить деньги с телефона на телефон

Лучшего подарка мошенникам и не придумаешь.

Как и полагается, я сразу связался с клиентской поддержкой Киевстар и попросил предоставить мне контакты службы безопасности или ответственного сотрудника отдела разработки, что бы им детально описать суть уязвимости и способ её воспроизведения. Как и стоило ожидать, мне отказали в моей просьбе и предложили прислать описание уязвимости либо в чат, либо через универсальную форму на сайте.
Понимая, какие возможны риски, если подробное описание уязвимости будет доступно любому сотруднику клиентской поддержки, я всё таки настоял на своей просьбе, но опять же безуспешно. Понимая, что другого выхода нет, я оформил подробную инструкцию по воспроизведению уязвимости в файлик Google Docs, завернул его в ссылку через сервис для трекания ссылок clickmeter.com и отправил в чат.
Как я и ожидал, моя заявка вызвала ажиотаж и повышенный интерес среди сотрудников компании, что отобразилось в аналитике сервиса clickmeter.com:
99b6d8c959d1461983e75c8e8f198c9e.png

Заявку за 2 дня просмотрел 22 уникальный пользователь.
ad77f577dbad48ccafc9b57d07017342.png

По статистике видно, что ссылку смотрели как с компьютеров, так и с мобильных устройств. География просмотров также не ограничилась киевским офисом, в списке Киев, Львов, Днепропетровск, Тбилиси.
Анализирую статистику, становится ясно, что существующий канал связи с компанией не предназначен для подачи заявок подобного рода и может привести к утечке информации и эксплуатации её сторонними лицами до закрытия уязвимости.

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

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

Комментарии (1)

  • 15 июля 2016 в 10:21

    0

    Меня больше удивило то, что при открытии сервиса с другого устройства используя телефон, как хотспот — авторизация не требуется. Реакция саппорта — this is feature, by design.

© Habrahabr.ru