Буквально пару дней назад я писал на Хабре про то, как российский медицинский онлайн-сервис DOC+ умудрился оставить в открытом доступе базу данных с детальными логами доступа, из которых можно было получить данные пациентов и сотрудников сервиса. И вот новый инцидент, с уже другим российским сервисом, предоставляющим пациентам онлайн-консультации врачей – «Доктор рядом» (www.drclinics.ru).
Напишу сразу, что благодаря адекватности сотрудников «Доктор рядом», уязвимость была быстро (2 часа с момента уведомления ночью!) устранена и скорее всего утечки персональных и медицинских данных не случилось. В отличии от инцидента с DOC+, где мне точно известно, что как минимум один json-файл с данными, размером 3.5 Гб попал в «открытый мир», а при этом официальная позиция выглядит так: "В открытом доступе временно оказался незначительный объем данных, который не может привести к негативным последствиям для сотрудников и пользователей сервиса DOC+.".
Со мной, как с владельцем Telegram-канала «Утечки информации», связался анонимный подписчик и сообщил о потенциальной уязвимости на сайте www.drclinics.ru.
Суть уязвимости заключалась в том, что, зная URL и находясь в системе под своей учетной записью, можно было просматривать данные других пациентов.
Для регистрации новой учетной записи в системе «Доктор рядом» фактически требуется только номер мобильного телефона, на который приходит подтверждающая СМС, поэтому проблем со входом в личный кабинет возникнуть ни у кого не могло.
После того как пользователь заходил в личный кабинет он мог сразу, меняя URL в адресной строке своего браузера, просматривать отчеты, содержащие персональные данные пациентов и даже медицинские диагнозы.
Существенная проблема заключалась в том, что сервис использует сквозную нумерацию отчетов и из этих номеров уже формирует URL:
https://[адрес сайта]/…/…/40261/…
Поэтому достаточно было установить минимальное допустимое число (7911) и максимальное (42926 — на момент наличия уязвимости), чтобы вычислить общее количество (35015) отчетов в системе и даже (при наличии злого умысла) выкачать их все простым скриптом.
Среди доступных для просмотра данных были: ФИО врача и пациента, даты рождения врача и пациента, телефоны врача и пациента, пол врача и пациента, адреса электронной почты врача и пациента, специализация врача, дата консультации, стоимость консультации и в некоторых случаях даже диагноз (в виде комментария к отчету).
Данная уязвимость по сути очень похожа на ту, что была обнаружена в декабре 2017 года на сервере микрофинансовой организации «Займоград». Тогда перебором можно было получить 36763 договоров, содержащих полные паспортные данные клиентов организации.
Как я указал с самого начала, сотрудники «Доктор рядом» проявили реальный профессионализм и несмотря на то, что об уязвимости я им сообщил в 23:00 (Мск), доступ в личный кабинет был сразу закрыт для всех, а к 1:00 (Мск) данная уязвимость была устранена.
Не могу не пнуть еще раз PR-отдел все того же DOC+ (ООО «Новая Медицина»). Заявляя «в открытом доступе временно оказался незначительный объем данных», они упускают из вида, что в нашем распоряжении есть данные "объективного контроля", а именно поисковик Shodan. Как верно подметили в комментариях к той статье — согласно Shodan, дата первой фиксации открытого сервера ClickHouse на IP-адресе DOC+: 15.02.2019 03:08:00, дата последней фиксации: 17.03.2019 09:52:00. Размер базы данных около 40 Гб.
А всего было 15 фиксаций:
15.02.2019 03:08:00
16.02.2019 07:29:00
24.02.2019 02:03:00
24.02.2019 02:50:00
25.02.2019 20:39:00
27.02.2019 07:37:00
02.03.2019 14:08:00
06.03.2019 22:30:00
08.03.2019 00:23:00
08.03.2019 14:07:00
09.03.2019 05:27:00
09.03.2019 22:08:00
13.03.2019 03:58:00
15.03.2019 08:45:00
17.03.2019 09:52:00Из заявления получается, что временно это чуть более месяца, а незначительный объем данных это примерно 40 гигабайт. Ну не знаю...
Но вернемся к «Доктор рядом».
На данный момент моя профессиональная паранойя не дает покоя только по одной оставшейся мелкой проблеме — по ответу сервера можно узнать количество отчетов в системе. Когда пытаешься получить отчет по URL, к которому нет доступа (но сам отчет при этом есть), то сервер возвращает ACCESS_DENIED, а когда пытаешься получить отчет, которого нет, то возвращается NOT_FOUND. Следя за увеличением количества отчетов в системе в динамике (раз в неделю, месяц и т.п.) можно оценить загруженность сервиса и объёмы предоставляемых услуг. Это конечно не нарушает персональных данных пациентов и врачей, но может быть нарушением коммерческой тайны компании.
Автор: ashotog
