Java разработчик
0,0
рейтинг
29 мая 2015 в 12:24

Разработка → Читаем переписку клиентов Ubank с саппортом



Я уже писал об уязвимости в мобильном приложении Альфа-Банка, которая позволяла получать выписки по любому клиенту банка.
В этот раз я решил проверить мобильное приложение сервиса по приёму платежей Ubank.
Для анализа запросов, посылаемых на сервер, я опять использовал программу Fiddler. Как её настраивать, я повторно описывать не буду, кому интересно, могут прочитать об этом в вышеуказанной статье. Единственное, что я сделал по другому, это воспроизводил запросы не через плагин Postman в Google Chrome, а используя встроенный в Fiddler инструмент Composer.

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

Итак, используя Fiddler, я записал запрос получения содержимого сообщения из переписки с саппортом:



Потом я открыл его в Composer:



В запросе увеличил значение параметра question_id на единицу и отправил на сервер.
В ответе я получил содержимое чужого сообщения:



При дальнейшем анализе удалось выяснить, что помимо id сообщения, не проверялись на привязку к сессии пользователя и отправленные в сообщении файлы.



Как и с мобильным приложением Альфа-Банка, приложение Ubank также не использовало SSL Pinning, что в свою очередь позволяло провести MitM атаку, если злоумышленнику удастся установить свой сертификат на устройство жертвы, что вполне реализуемо следующими способами:

1) пользователь делает все сам из-за неосведомленности. Например, для получения доступа к wi-fi точке доступа в общественном месте
2) приобретенный подержанный телефон уже может содержать установленный вредоносный сертификат
3) сертификат устанавливается на телефон с iOS за несколько секунд, если оказывается случайно в руках злоумышленника (например, он попросил позвонить)
4) заражение сетевого оборудования через уязвимость

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

К сожалению, моё общение с представителями компании ни к чему не привело, кроме как к спору в целесообразности SSL Pinning.

На данный момент, по истечении более 2-х месяцев после моего обращения в компанию, уязвимость остаётся открытой.
Денис @dinikin
карма
83,0
рейтинг 0,0
Java разработчик
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

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

  • 0
    Ща почитаем :)
  • 0
    Клёва, сделал похожую установку, нашел у себя кучу уязвимых приложений некоторые из которых хоть и отправляют с запросами куки/токены/пароли но в тоже время абсолютно не проверяют это все на стороне сервера и подмена парамеров возвращает чужие данные…

    Из самого интересного:

    — приложение для вызова такси (~10 служб в одном приложении) которое при подмене номера телефона на чужой в запросе вернет кучу информации о предыдущих/текущих закзах с подробной информацией о времени, адресах (+геотеги), перемещениях, ценах и много всего другого…

    — приложение для заказа доставки суши на дом которое отправляет параметр «verified=0» виесте с адресом доставки, заменив параметр на «verified=1» — можно анонимно заказать суши на любой адрес без предварительного звонка/подверждения со стороны суши-ресторана.
    • +1
      — приложение для заказа доставки суши на дом которое отправляет параметр «verified=0» виесте с адресом доставки, заменив параметр на «verified=1» — можно анонимно заказать суши на любой адрес без предварительного звонка/подверждения со стороны суши-ресторана.

      Отлично! Никогда не любил эти звонки. Особенно неприятно, если сейчас не можешь говорить, а заказать хочется.
  • –9
    Данная проблема уже исправлена. Спасибо, за пост и внимание к нашему сервису.
    • +8
      Ну зачем-же нужно было доводить это до крайности, а не исправить сразу?
      • +11
        if об этом уже написали на хабре?
        исправляем
        else
        да ну чот лень
        end
      • +1
        Проблема в том что обновить сервисы можно быстро, а вот мобильные клиенты быстро обновить не получится.
        Так что «сразу» проблематично, и это касается любого сервиса имеющего клиент серверную архитектуру и завязанного на тыкалки.
        • 0
          2 месяца, Карл! (с)
          • 0
            И какой процент пользователей обновит клиент?
            • 0
              Подобные вещи надо изначально закладывать. К примеру, чтобы при старте приложения было обращение к серверу на получение статуса/новостей/обновлений. Если обновление критическое, то выдавать сообщение, чтобы пользователи зашли в GP и обновили приложение.
  • –1
    Ручки зачесались… сейчас проверим одно интересное приложение
  • 0
    В прошлом году и Альфа-Банк не использовал SSL Pinning, сейчас не знаю…
  • +3
    Собственно это и есть подтверждения отличия российского саппорта от иностранного: в России юзер это враг и головна боль, а в иностранной это клиент и feedback.
    Доводить до крайности — глупее не придумать. Или это имидж большой компании и больших денег, когда на клиентов мелочи вниманию не обращают?
    • +2
      Тут как повезет — в недавней истории про старбакс тоже не очень сильно озаботились безопасностью. Интересно, кстати, чем все закончилось.

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