Буквально пару дней назад я писал на Хабре про то, как российский медицинский онлайн-сервис 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)


  1. Desavian
    21.03.2019 09:35
    +2

    Только есть два больших но. Они не умаляют профессионализма админов, но не дают ответа на то, сколько ваш информатор пользовался данной дырой и сколько данных он уже слил до того, как вам о ней рассказать, так что я бы зарубочку в памяти оставил всем, кто данным сервисом пользуется.


    1. ashotog Автор
      21.03.2019 09:39
      +1

      согласен полностью. поэтому я и написал «скорее всего утечки персональных и медицинских данных не случилось»


  1. LukaSafonov
    21.03.2019 09:46
    +1

    Это скорее не утечка, как в первом случае, это уязвимость IDOR.


    1. ashotog Автор
      21.03.2019 09:47
      +2

      «Утечка данных, которая могла произойти»


  1. tuxi
    21.03.2019 10:05

    Когда пытаешься получить отчет по URL, к которому нет доступа (но сам отчет при этом есть), то сервер возвращает ACCESS_DENIED, а когда пытаешься получить отчет, которого нет, то возвращается NOT_FOUND.
    Сразу вспоминаются жаркие баталии на тему идеологии RESTful :)


    1. kmansoft
      21.03.2019 10:35
      +1

      Если у текущего пользователя нет прав смотреть чужие отчёты (а их нет) то должен был бы быть access denied. А уж в каком виде не важно.


      Но у них видимо гибкая система прав и права хранятся в самом отчёте. Всё равно можно было бы access denied если отчёт не найден, ради безопасности.


      Вообще ещё хорошо бы не использовать скваозную числовую нумерацию...


      1. tuxi
        21.03.2019 10:39
        +1

        Я точно также считаю. Если это не твой отчет или такого отчета нет совсем — получи access denied. Нефиг 404 кидать. Аналогичная ситуация с парами логин/пароль. Если оба значения не совпадают или логин не найден — надо отдавать всегда «логин и пароль не валидные». Подсказки тут не уместны.


      1. ashotog Автор
        21.03.2019 10:40

        Вообще ещё хорошо бы не использовать скваозную числовую нумерацию


        да! это вообще зло, на мой взгляд. ну возьмите хеш от номера отчета и его в URL-используйте (а еще и с солью, для параноиков)…


        1. tuxi
          21.03.2019 10:43
          +2

          Это если есть возможность влиять на эту часть логики. Зачастую за фронтом и за бекендом, сидит второй бекенд из зоопарка разных учетных систем, 1С или что то подобное. Тогда либо на уровне своего бекенда хэшировать и жить с этим, либо ".як.як и в продакшен"


          1. ashotog Автор
            21.03.2019 19:50

            ну пипец же вот с этим ".як.як". они же реально сливают все персданные своими этими.як. где органы сертификации, где регуляторы? ;)


            1. tuxi
              21.03.2019 19:58
              +1

              Знаете как бывает? Вот сейчас есть 1С, вот ТЗ на разработку, по ТЗ 1С сама отдает хэшированные номера отчетов/заказов/и тп. Вот мы все сделали, вот все работает.
              А через какое то время, полгода, год, после каких либо обновлений и/или доработок, 1С начинает отдавать номера в голом виде. И это вполне себе реальность. На стороне 1С обычно мало заморачиваются соблюдением контрактов и ТЗ.


  1. vilgeforce
    21.03.2019 11:23
    +1

    2 часа, да еще и ночью? Молодцы!


    1. ashotog Автор
      21.03.2019 20:02

      да, удивили. это прямо редкость. их пиар менеджер Варвара мгновенно ответила в ФБ, все разрулила.

      и как обратный пример — дня три добивался ответа или реакции на нотификацию об открытой базе с заемщиками от компании Финсервис и… ничего. но базу сегодня втихаря прикрыли. тут вот уже отчет опубликовал: https://t.me/dataleak/863


    1. Borz
      22.03.2019 08:17

      2 часа ночи по какому поясу? где-то это ночь, а у кого-то рабочий день в самом разгаре.


      1. ashotog Автор
        22.03.2019 09:27

        в статье указано, что время по Москве и не в два часа ночи, а два часа ночью. в час ночи прикрыли.


  1. atmega644
    21.03.2019 14:43
    +2

    json-файл с данными, размером 3.5 Гб попал в «открытый мир»


    Нашел "открытый мир", что удивительно, через Твиттер. Кому интересно — https://t.me/freedom_fox/740


    Автору — огромная благодарность, за проделанную работу. Статьи весьма актуальны современным трендам борьбы за анонимность ПДн.


    1. ashotog Автор
      21.03.2019 19:48

      всегда пожалуйста ;)

      Действительно, первым файл в паблик вывалил Ситников (FlatL1ne) через свой телеграмчик. Примерно через 4 часа после публикации у меня в канале (я никакие IP разумеется не показывал), нашел сам…