stihl не предоставил(а) никакой дополнительной информации.
Уязвимость, о которой пойдет речь, была использована при проведении внешнего тестирования в рамках редтиминга. Атака строилась на том, что корпоративное мобильное приложение позволяло выпускать сертификаты, которые были валидными не только на внешнем периметре организации, но и в корпоративной сети.
Это исследование получило третье место на Для просмотра ссылки Войдиили Зарегистрируйся в категории «Мобильный разлом». Соревнование ежегодно проводится компанией Awillix.
Внешний нарушитель мог использовать баг в API мобильного приложения, имея валидную пару из логина и OTP любого сотрудника компании, для выпуска сертификата на любого другого сотрудника.
Выпущенный сертификат содержал информацию об обоих сотрудниках и позволял получать доступ к одной части веб‑ресурсов от лица жертвы фишинга, а к другой части немаловажных ресурсов — от лица работника, который свой OTP никому не раскрывал.
Для просмотра ссылки Войдиили Зарегистрируйся
Как потом выяснилось, он должен был открываться строго при наличии сертификата, но эта проверка не работала, из‑за чего зайти на портал мог любой желающий.
Включив в браузере режим адаптивного дизайна, я нашел прямую ссылку для скачивания корпоративного мобильного приложения и без проблем скачал файл APK на свой компьютер.
Для просмотра ссылки Войдиили Зарегистрируйся
Для ручного статического анализа APK я использовал Для просмотра ссылки Войдиили Зарегистрируйся и сразу отметил для себя, что при сборке мобильного приложения обфускацию не использовали, — это сильно облегчило реверс.
Для просмотра ссылки Войдиили Зарегистрируйся
Пробежавшись глазами по коду и используя фильтры для поиска по ключевым словам, я определил, что для аутентификации в приложении пользователь вводит свои логин и OTP.
Для просмотра ссылки Войдиили Зарегистрируйся
Следующим шагом я нашел конечную точку, куда мобильное приложение отправляет учетные данные пользователя.
Для просмотра ссылки Войдиили Зарегистрируйся
Оставалось только определить правила формирования и отправки приложением зашифрованного запроса на выпуск сертификата (он же Certificate Signing Request, CSR).
Для просмотра ссылки Войдиили Зарегистрируйся
Следом я установил, что в ответ на отправляемый приложением HTTP-запрос с CSR и валидными учетными данными бэкенд возвращает пользовательский сертификат. Этот серт объединяется с приватным ключом, который приложение создает для подписи CSR, и сохраняется в локальную базу данных мобильного приложения.
Таким образом удалось определить логику формирования пользовательских сертификатов, прибегнув лишь к статическому анализу приложения.
Полученной информации было достаточно для того, чтобы полностью воссоздать логику выпуска пользовательских сертификатов в скрипте на Bash.
Если бы код мобильного приложения был обфусцирован, мы могли бы использовать Для просмотра ссылки Войдиили Зарегистрируйся для динамического анализа и определить, какие данные отсылаются на бэкенд.
Для просмотра ссылки Войдиили Зарегистрируйся
Чтобы не тратить время на обход SSL pinning, можно воспользоваться одним из публичных Для просмотра ссылки Войдиили Зарегистрируйся для Frida, который выводит в консоль содержимое HTTP-запросов и ответов. Так нарушитель может стать пассивным слушателем между приложением и эндпоинтами API.
Так у меня появилась возможность выпускать сертификаты от лица работников, попавшихся на фишинг и оставивших свои логин и одноразовый пароль, причем выпуск уже не зависел от мобильного приложения и работал в виде отдельного скрипта.
При анализе мобильного приложения у меня возникла гипотеза, что при вводе валидных значений логина и OTP одного работника организации можно внести в формируемый CSR такие изменения, чтобы бэкенд вернул сертификат, содержащий данные любого другого работника организации, который свой OTP и логин никуда не вводил (то есть не был непосредственной жертвой фишинга).
Я подумал: а нельзя ли добавить в мой скрипт возможность подменять атрибуты CN в формируемом CSR?
Для выпуска пользовательского сертификата требовалось лишь знать логин жертвы и ее OTP. Полученный скрипт принимал на вход три значения: логин цели (на кого мы хотим получить сертификат), логин работника, попавшегося на фишинг, и его OTP.
Для просмотра ссылки Войдиили Зарегистрируйся
Скрипт работал достаточно быстро, чтобы успевать выпускать пользовательские сертификаты за время жизни OTP.
Полученный сертификат после объединения с приватным ключом (используемым для подписи CSR) можно было применять для работы с корпоративными сайтами как из интернета, так и внутри сети. Причем от лица сотрудника организации, который никак с нами не взаимодействовал.
Это исследование получило третье место на Для просмотра ссылки Войди
Внешний нарушитель мог использовать баг в API мобильного приложения, имея валидную пару из логина и OTP любого сотрудника компании, для выпуска сертификата на любого другого сотрудника.
Выпущенный сертификат содержал информацию об обоих сотрудниках и позволял получать доступ к одной части веб‑ресурсов от лица жертвы фишинга, а к другой части немаловажных ресурсов — от лица работника, который свой OTP никому не раскрывал.
Пример эксплуатации
Началось все с того, что я пошел гуглить корпоративные приложения организации. И сразу наткнулся на один интересный портал.Для просмотра ссылки Войди
Как потом выяснилось, он должен был открываться строго при наличии сертификата, но эта проверка не работала, из‑за чего зайти на портал мог любой желающий.
Включив в браузере режим адаптивного дизайна, я нашел прямую ссылку для скачивания корпоративного мобильного приложения и без проблем скачал файл APK на свой компьютер.
Для просмотра ссылки Войди
Для ручного статического анализа APK я использовал Для просмотра ссылки Войди
Для просмотра ссылки Войди
Пробежавшись глазами по коду и используя фильтры для поиска по ключевым словам, я определил, что для аутентификации в приложении пользователь вводит свои логин и OTP.
Для просмотра ссылки Войди
Следующим шагом я нашел конечную точку, куда мобильное приложение отправляет учетные данные пользователя.
Для просмотра ссылки Войди
Оставалось только определить правила формирования и отправки приложением зашифрованного запроса на выпуск сертификата (он же Certificate Signing Request, CSR).
Для просмотра ссылки Войди
Следом я установил, что в ответ на отправляемый приложением HTTP-запрос с CSR и валидными учетными данными бэкенд возвращает пользовательский сертификат. Этот серт объединяется с приватным ключом, который приложение создает для подписи CSR, и сохраняется в локальную базу данных мобильного приложения.
Таким образом удалось определить логику формирования пользовательских сертификатов, прибегнув лишь к статическому анализу приложения.
Полученной информации было достаточно для того, чтобы полностью воссоздать логику выпуска пользовательских сертификатов в скрипте на Bash.
Если бы код мобильного приложения был обфусцирован, мы могли бы использовать Для просмотра ссылки Войди
Для просмотра ссылки Войди
Чтобы не тратить время на обход SSL pinning, можно воспользоваться одним из публичных Для просмотра ссылки Войди
Так у меня появилась возможность выпускать сертификаты от лица работников, попавшихся на фишинг и оставивших свои логин и одноразовый пароль, причем выпуск уже не зависел от мобильного приложения и работал в виде отдельного скрипта.
При анализе мобильного приложения у меня возникла гипотеза, что при вводе валидных значений логина и OTP одного работника организации можно внести в формируемый CSR такие изменения, чтобы бэкенд вернул сертификат, содержащий данные любого другого работника организации, который свой OTP и логин никуда не вводил (то есть не был непосредственной жертвой фишинга).
Я подумал: а нельзя ли добавить в мой скрипт возможность подменять атрибуты CN в формируемом CSR?
Для выпуска пользовательского сертификата требовалось лишь знать логин жертвы и ее OTP. Полученный скрипт принимал на вход три значения: логин цели (на кого мы хотим получить сертификат), логин работника, попавшегося на фишинг, и его OTP.
Для просмотра ссылки Войди
Скрипт работал достаточно быстро, чтобы успевать выпускать пользовательские сертификаты за время жизни OTP.
Полученный сертификат после объединения с приватным ключом (используемым для подписи CSR) можно было применять для работы с корпоративными сайтами как из интернета, так и внутри сети. Причем от лица сотрудника организации, который никак с нами не взаимодействовал.
Выводы
Из‑за уязвимости в логике выпуска сертификатов в мобильном API возникла ситуация, при которой работник, ставший жертвой фишинга и раскрывший свой логин и OTP, непроизвольно позволял внешнему нарушителю выпускать валидный сертификат для любого другого служащего. В частности, такие «франкенсертификаты», выпущенные на топ‑менеджеров, позволили реализовать ряд недопустимых событий внутри сети организации.Рекомендации по устранению
- Приложение, занимающееся выпуском сертификатов, не должно по умолчанию доверять данным, получаемым от пользователя, при формировании пользовательских сертификатов. Например, следует сверять значение поля CN, полученного из CSR, с логином, введенным пользователем при аутентификации. Использование CN без такой проверки создает риск подмены личности.
- Перед публикацией мобильного приложения (даже корпоративного) необходимо убедиться, что при сборке продуктовой версии приложения включены правила для обфускации и они корректно настроены.
- Нужно корректно настроить процесс аутентификации на корпоративном портале, откуда планируется распространять среди работников корпоративное мобильное приложение.
- Необходимо регулярно проводить анализ защищенности доступных из интернета основных корпоративных веб‑ресурсов, а также корпоративных мобильных приложений, так как они тоже могут стать точкой доступа в инфраструктуру организации.
- Периодически проводить учебный фишинг.