Буквально пару дней назад я писал на Хабре про то, как российский медицинский онлайн-сервис 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. Следя за увеличением количества отчетов в системе в динамике (раз в неделю, месяц и т.п.) можно оценить загруженность сервиса и объёмы предоставляемых услуг. Это конечно не нарушает персональных данных пациентов и врачей, но может быть нарушением коммерческой тайны компании.
Комментарии (17)
tuxi
21.03.2019 10:05Когда пытаешься получить отчет по URL, к которому нет доступа (но сам отчет при этом есть), то сервер возвращает ACCESS_DENIED, а когда пытаешься получить отчет, которого нет, то возвращается NOT_FOUND.
Сразу вспоминаются жаркие баталии на тему идеологии RESTful :)kmansoft
21.03.2019 10:35+1Если у текущего пользователя нет прав смотреть чужие отчёты (а их нет) то должен был бы быть access denied. А уж в каком виде не важно.
Но у них видимо гибкая система прав и права хранятся в самом отчёте. Всё равно можно было бы access denied если отчёт не найден, ради безопасности.
Вообще ещё хорошо бы не использовать скваозную числовую нумерацию...
tuxi
21.03.2019 10:39+1Я точно также считаю. Если это не твой отчет или такого отчета нет совсем — получи access denied. Нефиг 404 кидать. Аналогичная ситуация с парами логин/пароль. Если оба значения не совпадают или логин не найден — надо отдавать всегда «логин и пароль не валидные». Подсказки тут не уместны.
ashotog Автор
21.03.2019 10:40Вообще ещё хорошо бы не использовать скваозную числовую нумерацию
да! это вообще зло, на мой взгляд. ну возьмите хеш от номера отчета и его в URL-используйте (а еще и с солью, для параноиков)…tuxi
21.03.2019 10:43+2Это если есть возможность влиять на эту часть логики. Зачастую за фронтом и за бекендом, сидит второй бекенд из зоопарка разных учетных систем, 1С или что то подобное. Тогда либо на уровне своего бекенда хэшировать и жить с этим, либо ".як.як и в продакшен"
ashotog Автор
21.03.2019 19:50ну пипец же вот с этим ".як.як". они же реально сливают все персданные своими этими.як. где органы сертификации, где регуляторы? ;)
tuxi
21.03.2019 19:58+1Знаете как бывает? Вот сейчас есть 1С, вот ТЗ на разработку, по ТЗ 1С сама отдает хэшированные номера отчетов/заказов/и тп. Вот мы все сделали, вот все работает.
А через какое то время, полгода, год, после каких либо обновлений и/или доработок, 1С начинает отдавать номера в голом виде. И это вполне себе реальность. На стороне 1С обычно мало заморачиваются соблюдением контрактов и ТЗ.
vilgeforce
21.03.2019 11:23+12 часа, да еще и ночью? Молодцы!
ashotog Автор
21.03.2019 20:02да, удивили. это прямо редкость. их пиар менеджер Варвара мгновенно ответила в ФБ, все разрулила.
и как обратный пример — дня три добивался ответа или реакции на нотификацию об открытой базе с заемщиками от компании Финсервис и… ничего. но базу сегодня втихаря прикрыли. тут вот уже отчет опубликовал: https://t.me/dataleak/863
atmega644
21.03.2019 14:43+2json-файл с данными, размером 3.5 Гб попал в «открытый мир»
Нашел "открытый мир", что удивительно, через Твиттер. Кому интересно — https://t.me/freedom_fox/740
Автору — огромная благодарность, за проделанную работу. Статьи весьма актуальны современным трендам борьбы за анонимность ПДн.
ashotog Автор
21.03.2019 19:48всегда пожалуйста ;)
Действительно, первым файл в паблик вывалил Ситников (FlatL1ne) через свой телеграмчик. Примерно через 4 часа после публикации у меня в канале (я никакие IP разумеется не показывал), нашел сам…
Desavian
Только есть два больших но. Они не умаляют профессионализма админов, но не дают ответа на то, сколько ваш информатор пользовался данной дырой и сколько данных он уже слил до того, как вам о ней рассказать, так что я бы зарубочку в памяти оставил всем, кто данным сервисом пользуется.
ashotog Автор
согласен полностью. поэтому я и написал «скорее всего утечки персональных и медицинских данных не случилось»