Безлимитное облако и заурядные уязвимости

Волей случая наткнулся на приложение «IngoMobile» компании Ингосстрах.

И как это обычно бывает, я достал из широких штанин mitmproxy и тут началось самое интересное.

Статей как пользоваться mitmproxy и как с помощью него находить уязвимости уже достаточно много, например вот, так что перейдем к сути.

Безлимитное облако

Покопавшись немного в запросах приложения, мне на глаза попался обычный запрос обновления пользовательского аватара:

https://ingomobile.ingos.ru/api/user/profile/avatar

Ответ:

{
  "header": {
    "error_code": 0
  },
  "data": {
    "id": "81738613503"
  }
}

Пробуем загрузить файл, отличный от изображения — успех. Единственное ограничение такого облака: размер файла порядка 20-30 Мб.

Заурядные уязвимости

Так, файл мы загрузили, а как скачать? Пожалуйста:

https://ingomobile.ingos.ru/api/file/{id}

https://ingomobile.ingos.ru/api/file/81738613503

Здорово, а если id перебрать? То можно многое узнать.
Метод отдачи файла не контролирует доступ к нему.
Таким образом, за небольшой промежуток времени удалось обнаружить:

• Сканы паспортов, птс и ср, водительских удостоверений, договоров купли продажи и т.д.
• Расчеты страховой премии
• Фотографии всего, что страхуют, до и после страховых случаев
• Письма(.msg outlook), запросы, поручения и прочая приватная информация
• Ссылки на оплату и счета об оплате
• Прочие файлы

Схожие проблемы есть и у остальных методов api, самый примечательный из них:

policies/info/bank_card/{id}

который отдает такие поля, как:

card_valid_thru, card_number, card_holder

но к сожалению(или к счастью) мне не удалось подобрать нужный id.

Другие проблемы коснулись регистрации и номера телефона пользователя.
При регистрации от нас просят паспортные данные:

{
  "last_name": "К",
  "first_name": "К",
  "middle_name": "К",
  "doc_series": "3214",
  "doc_num": "567890",
  "doc_date": "21.11.2018",
  "doc_issued_by": "12",
  "birthday": "21.12.1998",
  "city_id": "33209416",
  "mail": "c7015346@urhen.com"
}

И мы получаем в ответ что-то вроде:

{
  "header": {
    "error_code": 0
  },
  "data": {
    "ais_user_id": "10596623603",
    "user_id": "628001203",
    "found": false
  }
}

Казалось бы, все хорошо, но нет.
Знаете ФИО клиента, но нет серии и номера паспорта? Перебирайте их в запросе на регистрацию, пока не получите "found": true.

Далее у нас на очереди смена номера телефона. Запрос на изменение номера выглядит следующим образом:

{"ais_user_id":"10596638503", "phone": "9628112489"}

Параметр ais_user_id может быть любым, как следствие, можно сменить номер телефона у любого пользователя и запустить процедуру восстановления пароля.
Полный сценарий атаки.

В чем соль?

Уязвимости очевидны, и как можно было их допустить — не понятно.
Зачем писать статью о таких простых уязвимостях?
Они до сих пор не пофикшены. Немного хронологии:

• 2 ноября 2019 уведомляю на почту об уязвимостях, получаю автоматический ответ.
• 5 ноября 2019 пишу в сообщения сообщества вк, получаю чуть менее, но все же автоматический ответ.
• 8 ноября 2019 пишу в вк и на почту подробный обзор уязвимостей.
• 18 ноября 2019 звоню в поддержку, уже лучше.
• 19 ноября 2019 получаю письмо "Мы получили ваш отчет и передали нашим специалистам на анализ и исправление.".
• 20 декабря 2019 все на своих местах.

Если Вы клиент Ингосстрах, есть ненулевая вероятность, что все переданные компании данные давно утекли.

Спасибо, что дочитали! Рекомендаций по безопасности не будет, потому что все текут, но хотя бы своевременно лотают дыры.

P.S. Кстати о соли, ребята зачем-то делают в приложении md5 от пароля, перед тем как отправить на сервер, наверное для безопасности.

Но не делают этого на сайте, из-за чего пароли расходятся, и чтобы войти на сайт, надо самому сделать md5 с солью.

Автор: Kolsha

Источник