遠隔医療会社からのデータ漏洩(起こる可能性はあったが、起こらなかった)

ほんの数日前、私は 私が書きました ハブレ氏は、ロシアのオンライン医療サービス DOC+ がどのようにして詳細なアクセス ログを含むデータベースをパブリック ドメインに残し、そこから患者やサービス従事者のデータを取得できたかについて語った。 そして、患者に医師とのオンライン診療を提供するロシアの別のサービス「Doctor Nearby」(www.drclinics.ru)での新たな事件が起きた。

すぐに書きますが、Doctor is Near のスタッフの適切な対応のおかげで、脆弱性はすぐに (夜の通知の瞬間から 2 時間!) 解消され、おそらく個人データや医療データの漏洩はなかったと思います。 DOC+ 事件とは異なり、サイズ 3.5 GB のデータを含む少なくとも XNUMX つの json ファイルが最終的に「オープンワールド」に流出したことは確実にわかっており、公式見解は次のとおりです。少量のデータが一時的に公開されていますが、それが従業員や DOC+ サービスのユーザーに悪影響を与えることはできません。"

遠隔医療会社からのデータ漏洩(起こる可能性はあったが、起こらなかった)

Telegram チャンネルのオーナーとして私と一緒に」情報漏洩」と匿名の加入者から連絡があり、Web サイト www.drclinics.ru の潜在的な脆弱性について報告されました。

この脆弱性の本質は、URL を知っていて自分のアカウントでシステムにアクセスすると、他の患者のデータを閲覧できるという点でした。

Doctor Nearby システムに新しいアカウントを登録するには、実際に必要なのは確認 SMS の送信先となる携帯電話番号だけなので、個人アカウントへのログインに問題はありません。

ユーザーは個人アカウントにログインした後、ブラウザのアドレス バーの URL を変更することで、患者の個人データや医療診断を含むレポートをすぐに表示できるようになりました。

遠隔医療会社からのデータ漏洩(起こる可能性はあったが、起こらなかった)

重大な問題は、このサービスがレポートに継続的な番号付けを使用しており、これらの番号から既に URL を形成していることでした。

https://[адрес сайта]/…/…/40261/…

したがって、システム内のレポートの総数 (7911) を計算し、(悪意があった場合には) ダウンロードするためには、許容される最小数 (42926) と最大値 (35015 - 脆弱性発生時) を設定するだけで十分でした。これらはすべて簡単なスクリプトで実行できます。

遠隔医療会社からのデータ漏洩(起こる可能性はあったが、起こらなかった)

閲覧可能なデータには、医師と患者の氏名、医師と患者の生年月日、医師と患者の電話番号、医師と患者の性別、医師と患者の電子メール アドレス、医師の専門分野などがあります。 、相談日、相談費用、場合によっては診断も(レポートへのコメントとして)。

この脆弱性は本質的に、以前の脆弱性と非常によく似ています。 2017年XNUMX月に発見 マイクロファイナンス組織「Zaimograd」のサーバー上。 その後、検索により、組織の顧客の完全なパスポート データを含む 36763 件の契約書を入手することができました。

私が最初から指摘したように、Doctor Nearby の従業員は真のプロフェッショナリズムを示し、私が 23 時 (モスクワ時間) に脆弱性について彼らに通知したにもかかわらず、私の個人アカウントへのアクセスは即座に全員に閉鎖され、00 時までに全員がアクセスできなくなりました。 1 (モスクワ時間) この脆弱性は修正されました。

同じDOC+(New Medicine LLC)の広報部門をまたしても蹴らずにはいられません。 と宣言する」少量のデータが一時的に公開されました」と主張すると、彼らは私たちが自由に使える「客観的管理」データ、つまりShodan検索エンジンを持っているという事実を見失います。 その記事へのコメントで正しく指摘されているように、Shodan によると、DOC+ IP アドレス上のオープン ClickHouse サーバーの最初の修正日: 15.02.2019/03/08 00:17.03.2019:09、最後の修正日: 52/ 00/40/XNUMX XNUMX:XNUMX:XNUMX。 データベースのサイズは約 XNUMX GB です。

合計 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

発言から分かるのは、 一時的に XNUMXヶ月ちょっと経ちますが、 少量のデータ これは約 40 ギガバイトです。 まあ、分かりませんが…

さて、「医者はそばにいます」に戻りましょう。

現時点では、私の職業上の妄想は、残りの XNUMX つの小さな問題に悩まされています。サーバーの応答によって、システム内のレポートの数がわかります。 アクセスできない URL (ただしレポート自体は利用可能) からレポートを取得しようとすると、サーバーは次のエラーを返します。 アクセス拒否存在しないレポートを取得しようとすると、返されます。 見つかりません。 システム内のレポート数の増加を時間の経過とともに (週に XNUMX 回、月に XNUMX 回など) 監視することで、サービスの負荷と提供されるサービスの量を評価できます。 もちろん、これは患者や医師の個人データを侵害するものではありませんが、企業秘密の侵害となる可能性があります。

出所: habr.com

コメントを追加します