Приложения для каршеринга содержат сотни уязвимостей

Растущая популярность сервисов краткосрочного проката автомобилей (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 и записан в файл на устройстве).

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

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

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

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

Что в итоге

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

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

Компания Cisco опять разбирается с уязвимостью WebExec

• «Делимобиль»
• «Карусель»
• «Яндекс.Драйв»
• Anytime
• BelkaCar
• CAR4YOU
• CAR5
• Carenda
• Carlion
• Colesa
• EASY RIDE
• Lifcar
• MatreshCar
• Rent-a-Ride
• RENTMEE
• TimCar

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

Среди приложений для Android лучшие результаты показал мобильный клиент «Яндекс.Драйв». В нем не обнаружено ни одной критической уязвимости и лишь две бреши среднего уровня. Эксперты оценили степень защищенности разработки в 4,2 балла. Программы сервисов Anytime, Lifcar и «Карусель» набрали по 3,3 балла. Тестирование выявило в каждом из них по одной серьезной ошибке и около двух десятков мелких недостатков.

Остальные участники исследования показали невысокий результат, получив в среднем два балла из пяти возможных. Наибольшие проблемы с безопасностью, по мнению экспертов, у программы компании CAR5, набравшей 1,4 балла.

Почти все Android-клиенты содержат в коде учетные данные, которые могут быть использованы злоумышленниками для несанкционированного доступа к аккаунту. Среди других проблем — небезопасное хранение паролей и персональной информации, а также уязвимость перед DoS-атаками и DNS-спуфингом.

Уровень защищенности программ для iOS оказался ниже, чем у Android-клиентов. Ни одно из протестированных приложений не дотянуло до трех баллов, а разработка компании Anytime, замыкающая рейтинг, получила лишь 0,5 балла из 5.

Эксперты отметили, что приложения из App Store нередко используют незащищенный протокол HTTP для обмена данными и хранят конфиденциальную информацию в незашифрованном виде.

Представители каршеринговых компаний, чьи программы подверглись анализу, отметили, что оценивать работу мобильного приложения в отрыве от серверной части и установленного в автомобиле ПО — некорректно. Компании Rent A Ride и RENTMEE заявили, что ни один из их клиентов не стал жертвой киберпреступников.

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

Согласно данным отчета «Лаборатории Касперского», россияне чаще, чем жители любой другой страны, подвергаются нападениям банковских троянов. По информации Центробанка РФ, в 2017 году с их помощью с карт граждан было украдено около миллиарда рублей.

Смотрите видео: Лаборатория Касперского выявила угрозы в каршеринговых приложениях