Исследуем мобильные приложения для каршеринга

Растущая популярность сервисов краткосрочного проката автомобилей (carsharing) привела к тому, что некоторые эксперты прогнозируют в будущем полный отказ от персонального автотранспорта в крупных городах. В пользу этого прогноза говорит статистика: например, в Москве парк автомобилей, число активных пользователей и количество поездок, сделанных ими в 2017 году, практически удвоилось. Прекрасные новости, но вместе с этим у специалистов по информационной безопасности возникают резонные вопросы: как защищены пользователи сервисов и какие риски они несут в случае несанкционированного доступа к их аккаунтам?

Зачем преступникам каршеринг?

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

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

Мошенники предлагают аккаунты практически всех каршеринговых служб…

…и объясняют, в чем плюсы чужих учетных записей

Кроме этого, зная данные от аккаунта пользователя каршерингового сервиса, можно отслеживать его передвижения, а заметив в автомобиле забытые вещи — просто украсть их. В конце концов, взятую «в аренду» машину можно просто отогнать в безлюдное место и разобрать на запчасти.

Защищенность приложений

Итак, потенциальный интерес со стороны преступного мира есть. Посмотрим, отреагировали ли на него создатели каршеринговых приложений: позаботились ли о безопасности пользователей и защите собственного ПО от несанкционированного доступа? Мы протестировали 13 мобильных программ и, забегая вперед, — полученный ответ нас не обрадовал.

Для начала мы проверили ПО на противодействие запуску на Android-устройстве с root-правами и оценивали качество обфускации кода приложения. Это связано с двумя особенностями:

• подавляющее большинство приложений для Android можно декомпилировать, внести изменения в код (например, настроить отправку учетных данных на сервер злоумышленников), после чего собрать заново, подписать своим сертификатом и выложить обратно в магазин приложений;
• на рутованном устройстве можно внедриться в процесс нужного приложения и таким образом заполучить аутентификационные данные.

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

Пример дискредитирующего поста

Также мы обратили внимание на то, как приложения работают с сертификатами — есть ли у злоумышленников шансы на успех при проведении MITM­­-атак и проверили насколько легко перекрыть интерфейс ПО поддельным окном авторизации.

Реверс-инжиниринг и права суперпользователя

Лишь одно из рассмотренных нами приложений оказалось способно противостоять реверс-инжинирингу: оно было защищено с помощью решения DexGuard, разработчики которого обещают также невозможность запуска ПО в случаях, когда владелец получил root-права на своем устройстве или приложение было модифицировано (пропатчено).

Названия файлов установочного пакета выдают использование DexGuard

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

Пример хорошо зашифрованных учетных данный пользователя

Надежность паролей

Половина протестированных приложений не дают возможность самому создавать логин и пароль: в роли таковых выступают телефонный номер и PIN-код, который пользователь получает в SMS. С одной стороны, это не даст пользователю использовать ненадежный пароль вида 1234, а с другой — дает шанс злоумышленнику подобрать пароль (перехватить его, воспользовавшись уязвимостью SS7, или получить с помощью перевыпуска SIM-карты). Мы решили на собственных аккаунтах проверить насколько легко подобрать этот «пароль».

Если злоумышленник, нашедший в социальной сети номер телефона, попытается войти в приложение, его владелец получит SMS с кодом подтверждения:

Как видим, это четырехзначное число, т.е. всего лишь 10 000 комбинаций, что не так уж и много. По-хорошему, такие коды должны быть минимум шестизначными и содержать не только цифры, но и буквы разного регистра.

Другой каршеринговый сервис присылает более стойкие пароли, но и в его случае не все гладко: коды создаются по одному шаблону — цифры по краям и четыре латинских буквы в нижнем регистре в середине:

Таким образом, перебрать нужно 45 миллионов комбинаций, однако если бы положение цифр было произвольным, количество вариантов возросло до двух миллиардов. Конечно, 45 000 000 — тоже много, но в приложении нет таймаута на ввод следующей комбинации, следовательно, нет и препятствия для перебора.

Но вернемся пока к PIN-кодам первого приложения. На их ввод нам дают минуту после чего рекомендуют повторить запрос на получения кода. Оказалось, что время жизни комбинации чуть больше двух минут. Мы написали небольшую брутфорс-утилиту, далее воспроизвели часть протокола взаимодействия приложения с сервером и запустили перебор. Скажем честно, что код мы так и не подобрали: то ли интернет-канал нас подвел, то ли оператор каршеринга заложил адекватный таймаут в две минуты на актуальность PIN-кода, за которых даже на хорошем канале не успеть «забрутфорсить» PIN. Мы решили не продолжать, ограничившись подтверждением факта, что даже после нескольких попыток по 10 000 запросов сервис продолжает отвечать и можно дальше продолжать атаку.

При этом мы специально запустили перебор в один поток, с одного IP-адреса, чтобы дать сервису шанс выявить и заблокировать атаку, а также связаться с потенциальной жертвой и, в крайнем случае, деактивировать учетную запись. Но ничего из этого сделано не было. На этом мы решили остановиться и перешли к следующему приложению.

С ним было решено проделать все те же процедуры, с той лишь разницей, что мы не стали фиксировать успешный подбор пароля, решив, что если сервер позволяет проверить 1000 комбинаций, то возможна и проверка 45 миллионов, просто на это уйдет больше времени.

Сервер продолжает отвечать после 1000 попыток перебора пароля

В общем, процесс трудоемкий и результат предсказуем. Кстати, в этом приложении логин и пароль хранятся в локальном хранилище в зашифрованном виде, но, зная их формат, подбор займет пару минут, большая часть которых уйдет на генерацию пары пароль/MD5-хэш (пароль захэширован с помощью MD5 и записан в файл на устройстве).

MITM-атака

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

Скриншот успешной MITM-атаки с дампом HTTPS-трафика

Защита от перекрытия

В целом, если заразить Android-устройство, то «проблемы» можно решить гораздо быстрее и эффективнее: «авторизационную» SMS можно перехватить и мгновенно авторизоваться на другом устройстве. А если проблема в сложном пароле, то перехватить запуск приложения, показав поверх его интерфейса поддельное окно с полями ввода логина и пароля. Ни одно из рассмотренных нами приложений этим действиям противодействовать не будет. Если же версия операционной системы достаточно стара, можно выполнить эскалацию привилегий и в некоторых случаях «вытянуть» нужные данные.

Что в итоге

Ситуация очень похожа на ту, что мы обнаружили с приложениями для connected car: складывается впечатление, что у разработчиков нет понимания текущих угроз для мобильных платформ как при проектировании приложений, так и при создании инфраструктуры. Неплохо было бы расширить функции по оповещению пользователя о подозрительных действиях — на данный момент только один сервис отправляет пользователю оповещение о том, что в его аккаунт пытаются зайти с другого устройства. Большинство из рассмотренных нами приложений сырые с точки зрения безопасности и нуждаются в доработке. Более того, многие программы не просто очень похожи друг на друга, но и вовсе основаны на одном и том же коде.

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

Памятка пользователям

• Не оставляйте в открытом доступе номер телефона (да и электронную почту не стоит).
• Заведите для оплаты услуг в Сети и, в частности, каршеринга, отдельную банковскую карту (можно виртуальную) и не храните на ней деньги сверх необходимого.
• Если каршеринговый сервис вдруг присылает SMS с PIN-кодом от аккаунта, стоит сообщить об этом в службу безопасности и отвязать от аккаунта банковскую карту.
• Не используйте рутованные устройства.
• Используйте защитное решение, которое обезопасит вас от зловредов, крадущих SMS. Это осложнит жизнь не только любителям бесплатной быстрой езды, но и тем, кого интересуют банковские SMS.

Советы сервисам

• Используйте коммерческие упаковщики и обфускаторы для усложнения реверс-инжиниринга, особое внимание уделяйте контролю целостности, чтобы приложение невозможно было модифицировать.
• Используйте механизмы детектирования работы на рутованных устройствах.
• Дайте возможность пользователю придумать данные для авторизации и следите за криптостойкостью паролей.
• Информируйте пользователя о фактах успешной авторизации на других устройствах.
• Переходите на PUSH-уведомления: зловреды пока еще редко «мониторят» Notification bar в Android.
• Защищайте приложение от перекрытия другим приложением.
• Добавьте проверку сертификата сервера.