Я уже писал об уязвимости в мобильном приложении Альфа-Банка, которая позволяла получать выписки по любому клиенту банка.
В этот раз я решил проверить мобильное приложение сервиса по приёму платежей 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-х месяцев после моего обращения в компанию, уязвимость остаётся открытой.
Комментарии (14)
russum
29.05.2015 14:51Клёва, сделал похожую установку, нашел у себя кучу уязвимых приложений некоторые из которых хоть и отправляют с запросами куки/токены/пароли но в тоже время абсолютно не проверяют это все на стороне сервера и подмена парамеров возвращает чужие данные…
Из самого интересного:
— приложение для вызова такси (~10 служб в одном приложении) которое при подмене номера телефона на чужой в запросе вернет кучу информации о предыдущих/текущих закзах с подробной информацией о времени, адресах (+геотеги), перемещениях, ценах и много всего другого…
— приложение для заказа доставки суши на дом которое отправляет параметр «verified=0» виесте с адресом доставки, заменив параметр на «verified=1» — можно анонимно заказать суши на любой адрес без предварительного звонка/подверждения со стороны суши-ресторана.
splav_asv
30.05.2015 12:58+1— приложение для заказа доставки суши на дом которое отправляет параметр «verified=0» виесте с адресом доставки, заменив параметр на «verified=1» — можно анонимно заказать суши на любой адрес без предварительного звонка/подверждения со стороны суши-ресторана.
Отлично! Никогда не любил эти звонки. Особенно неприятно, если сейчас не можешь говорить, а заказать хочется.
marinaler
29.05.2015 17:07-9Данная проблема уже исправлена. Спасибо, за пост и внимание к нашему сервису.
ReaM
29.05.2015 17:23+8Ну зачем-же нужно было доводить это до крайности, а не исправить сразу?
chemistmail
30.05.2015 11:07+1Проблема в том что обновить сервисы можно быстро, а вот мобильные клиенты быстро обновить не получится.
Так что «сразу» проблематично, и это касается любого сервиса имеющего клиент серверную архитектуру и завязанного на тыкалки.
Suvitruf
30.05.2015 12:072 месяца, Карл! (с)
chemistmail
30.05.2015 15:20И какой процент пользователей обновит клиент?
Suvitruf
30.05.2015 15:26Подобные вещи надо изначально закладывать. К примеру, чтобы при старте приложения было обращение к серверу на получение статуса/новостей/обновлений. Если обновление критическое, то выдавать сообщение, чтобы пользователи зашли в GP и обновили приложение.
nikitasius
30.05.2015 02:05+3Собственно это и есть подтверждения отличия российского саппорта от иностранного: в России юзер это враг и головна боль, а в иностранной это клиент и feedback.
Доводить до крайности — глупее не придумать. Или это имидж большой компании и больших денег, когда наклиентовмелочи вниманию не обращают?
resetnow
30.05.2015 12:54+2Тут как повезет — в недавней истории про старбакс тоже не очень сильно озаботились безопасностью. Интересно, кстати, чем все закончилось.
HangGlider
Ща почитаем :)