WOG

На данный момент существует так много типов уязвимостей, что разработчики совсем забывают об элементарных из них. На днях мне удалось обойти авторизацию в новом приложении WOG (ТОВ «ВОГ РІТЕЙЛ» — вторая по величине сеть АЗС в Украине). В 2017 году, точно такую же уязвимость я обнаружил в приложении одного из мобильных провайдеров Украины (тоже второго по величине). Идентичные ситуации — новое приложение и отсутствие защиты от брутфорса.

Не так давно мне пришло уведомление – компания выпустила новое приложение и предлагает его установить. Функционал приложения, честно сказать, мне понравился – просмотр бонусов на счету, за которые можно купить топливо. Возможность привязать банковскую карту и оплачивать товары безконтактно или по QR коду. Так же в профиле отображаются мои ФИО и контактные данные, полная история транзакций – список товаров и стоимость их на момент покупки.

Авторизация в приложении стала проще – теперь не нужно вводить номер карты лояльности, достаточно указать номер мобильного. Однако еще при входе я заподозрил, что мои данные может просмотреть кто угодно – я специально, более 5 раз, ввел код отличный от того, что пришел мне в СМС. Зачем? – Потому что ранее, в похожем приложении мобильного оператора, я нашел уязвимость, которая давала полный доступ к управлению счетом абонента.

Вводя некорректный код удалось выяснить, что защиты от брутфорса, вероятнее всего, нет.

Я оказался прав — защиты у приложения нет. Можно получить доступ к любому счету, и более того, «угнать» аккаунт — привязать на другой номер, потратить чужие средства.

У меня сложилось впечатление, что разработчики приложений напрочь забывают о том, что сетевой трафик не сложно перехватить, даже https запросы.

Лично я использую программу fiddler – данный инструмент дает возможность проксировать трафик, просматривать его или менять. Что бы получить доступ к содержимому https запросов, помимо настроек прокси, в свойствах подключения смартфона, нужно дополнительно установить доверенный сертификат, который генерирует программа.

В первую очередь меня порадовала самооценка разработчиков приложения – API, которое использует приложение, расположено на домене thebestapp4ever.wog.ua. Просто походив по URLам удалось выяснить, что на сервере живет IIS 7.5 и 1C:Enterprise 8, а так же картинка из заголовка (возможно API писали фанаты Machinarium?).

Схема авторизации проста – запрос с «просьбой» отправить код в СМС летит на один из методов API. И здесь первая уязвимость – отсутствие каких либо лимитов. На один и тот же номер телефона, с одного IP можно «заказать» сколько угодно СМС.

Позже, в тендерах компании, я нашел информацию о том, что они планируют рассылать до 1 000 000 СМС в месяц (за год готовы потратить на это ~98 000$). Выходит, что уязвимость способна принести компании убытки в размере ~8200$ в день, если слать 12 запросов в секунду.

Стоит заметить, что для корректной обработки запросов сервером, необходима базовая авторизация – это один из методов защиты который использовали разработчики. Зачем? Не понятно – толку от неё я не вижу – перехватить логин/пароль или нужный http заголовок совсем не проблема.

После того как пользователь получил СМС и ввел код в приложение, оно шлет запрос с целью проверки достоверности кода и получения токена. Очередная и самая критичная уязвимость была именно здесь – нет защиты от брутфорса. На подбор кода, который состоит из 4 (!) цифр, требуется совсем не много времени.

Получив токен, можно использовать другие методы API. Один из которых дает возможность сменить PIN код от карты лояльности. Процедура стандартная – введите старый PIN, введите новый. Хочу акцентировать внимание на данном методе, поскольку здесь разработчик использовал еще один метод бесполезной «защиты». Естественно, защиты от брутфорса так же не было, зато старый пин отправлялся в скрытом виде. Идея хороша – просто перебрать комбинации 0000-9999 не получится. Реализация плохая – вместо кода отправляется md5 хеш. Без подстановок к нему соли или чего либо еще.

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

Так же мне удалось не только сбрутфорсить токен для «чужого» аккаунта, но и подсунуть его в приложение – написал небольшой скрипт на node.js, который проксировал трафик и подменял только ответы метода gettoken.

Статья написана после общения с «заместителем директора департамента ИТ» компании. Ребята резво отреагировали — контакты для общения я смог получить в течении суток. Отправил описание уязвимостей и вопрос про наличие bug bounty.

В ответ получил письмо с информацией о том, что меня, якобы, «засекли» — «Мы Вас (380958302---) увидели сразу и сработали блокировки… О всех блокировках рассказывать не буду, но за вчера их появилось достаточно большое множество»

Как по мне, больше похоже на мороз – ибо, как я и ответил на данное письмо, «шутка в том, что этот номер мне не знаком. Я тестил на номерах 095866...»

В отличии от компании WOG, начальник отдела ИБ оператора мобильной связи был куда разговорчивее, да и в качестве благодарности подогнали смартфон =)

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


  1. rivizoft
    23.02.2019 00:32

    Странно, что такие приложения для крупных компаний не тестируются…


    1. Samber Автор
      23.02.2019 00:36

      Не знаю, кто создавал приложение для ВОГа, но для оператора точно внешняя контора. В ТЗ, которые я выполнял, требования к безопасности, если и были, то в общих чертах. А тесты как правило по ТЗ и делают. Вот и выходит, как всегда… Кто крайний?


  1. TechnoMag
    23.02.2019 09:48

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


  1. anador
    23.02.2019 14:47

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

    Могу заблуждаться, но разве после какой-то версии Андроида https-трафик с приложений без пересборки .apk оных не перестал быть виден?


    1. TrueBers
      23.02.2019 22:09
      +1

      Пока руками в коде пиннинг не захардкодите, всё работает. Почему оно не должно работать?
      А пиннинг уже пересборкой снимается, да.


  1. PavelOborin
    23.02.2019 18:56

    Тоже когда-то разрабатывал приложение для дополнительной верификации пользователя через sms.

    На один и тот же номер телефона, с одного IP можно «заказать» сколько угодно СМС
    не совсем понимаю, как это поможет сделать брутфорс? Обычно в таких приложениях стандартный алгоритм: есть определенный временной интервал между повторными отправками sms; код каждый раз генерируется заново; при проверке, после нескольких неудачных попыток сбрасывается и высылается повторно. Да и обычно временное окно, в течение которого можно провалидировать код после авторизации по логину и паролю тоже сильно ограничено — несколько минут. Еще часто системы рейт-лимитов могут не торчать наружу, система продолжает принимать от вас запросы, но на самом деле уже внесла вас в черный список и просто выдает какой-то стандартный ответ.
    перехватить логин/пароль или нужный http заголовок совсем не проблема
    — как вы перехватите логин/пароль другого пользователя, траффик же шифруется https?


    1. mkll
      24.02.2019 20:08
      +1

      как вы перехватите логин/пароль другого пользователя, траффик же шифруется https?


      Буквально следующий абзац в статье дает ответ на этот вопрос.


  1. Codewaves
    24.02.2019 01:16

    Единственное в чем виноват разработчик приложения, это в том, что не сделал certificate pinning. Все остальное это проблемы серверной части.


    1. TrueBers
      24.02.2019 13:40
      +1

      Pinning — защита от скрипт-киддисов, которые повторяют шаги по туториалам с кулхацкеских форумов. На деле же, он снимается в несколько строк шелл-скрипта. Даже реверсер-любитель снимет его без каких-либо усилий и точно так же разберёт трафик.


      1. Codewaves
        24.02.2019 15:22

        Снимет с чего? Речь ведь идет об мобильном приложении и возможности украсть чужой аккоунт. Certificate pinning исключает MITM атаки, доступа к установленной программе или телефону у злоумышлинника нету, а подбор пин кода это проблемы сервера.
        А если есть физический доступ к телефону жертвы, никакая защита не поможет.


        1. TrueBers
          24.02.2019 16:20

          Ну, украсть данные аккаунта в 2019-м году через MitM мне вообще не видится возможным в серьёзном ПО. Pinning здесь играет не последнюю роль, да.

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


    1. pyrk2142
      24.02.2019 14:47

      Имхо, certificate pinning предназначен для решения достаточно специфичных проблем. Но его применение для защиты от уязвимостей в API может нанести больше вреда, чем пользы. Остановит ли он исследователя, который решил посмотреть на приложение (особенно, если это первые разы)? Вполне возможно. Остановит ли это злоумышленника, который собирается получать финансовую выгоду? Сомневаюсь, обход таких вещей — его «работа». В итоге получается защита от статьи на Хабре или где-то еще, а не от реального взлома.


      1. Codewaves
        24.02.2019 15:25

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


        1. pyrk2142
          24.02.2019 19:24

          Примерно об этом и говорю: если с логикой работы приложения все хорошо, то нет смысла пытаться все скрывать и прятать.

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