Каршеринг. Касперский проверил безопасность приложений - ч2
Самое интересное, имхо, из статьи "Исследуем мобильные приложения для каршеринга" Виктор Чебышев - July 31, 2018. 13:00 на SECURELIST.
Часть 2.
Надежность паролей
Половина протестированных приложений не дают возможность самому создавать логин и пароль: в роли таковых выступают телефонный номер и 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-трафика:
Часть 3. Завершающая. Будет после полуночи.