富士通 2021年 ProjectWEB への不正アクセス
顧客や協力会社と情報を共有するための社外向けのツールに、第三者が正規のIDとパスワードで入り、142の顧客の情報の一部を閲覧または取得した。多要素認証は無く、正常な認証と通信に見えるアクセスを早く見つける仕組みも足りず、ログの管理が不適切で、範囲の確定に時間がかかった。
要点
- 富士通は2021年5月6日に不正アクセスの可能性を知り、5月25日に公表した。被害のあった顧客の数は8月に129、2022年3月に142と発表された。
- 第三者は正規のIDとパスワードで、正常な認証と正常な通信で入った。ProjectWEB には数種類の脆弱性があり、そのいずれかでIDとパスワードを盗んだと富士通は判断した。
- ProjectWEB に多要素認証は無く、不正アクセスを早く見つける仕組みも十分でなかった。
- 終わったプロジェクトのデータが長く残り、別のプロジェクトの領域にデータが置かれた例もあった。漏れる量を決めるのは、置いてある量である。
- 委託元の側には、委託先が同種のツールを使っているかを確かめ、漏れた前提で資格情報の更新を考える、という守りがある。
何が起きたか
| 日付 | 公表資料の内容 |
|---|---|
| 2021年5月6日 | ProjectWEB を使う一部のプロジェクトで不正アクセスの可能性を認知し、調査を始めた[2] |
| 2021年5月24日 | 内閣サイバーセキュリティセンターが、政府機関等と重要インフラ事業者等へ、同種のツールの不正アクセス対策の確認を注意喚起。5月25日に公表[8] |
| 2021年5月25日 | 富士通が公表。顧客から預かった情報の一部が不正に窃取されたことが判明し、更なる不正アクセスを防ぐため運用を停止していると発表[1] |
| 2021年5月26日 | 国土交通省が発表。省のシステムを構成する機器類の情報と、少なくとも約7.6万件のメールアドレスが流出したと報告を受けた。省のシステムへの不正アクセスは確認されていない[9] |
| 2021年8月11日 | 第二報。129の顧客について情報の一部が閲覧またはダウンロードされた。システムを構成する機器の情報、体制図、打合せのメモ、進捗の管理表などで、一部に氏名とメールアドレスなどの個人情報があった。第三者は正規のIDとパスワードで、正常な認証と通信で入った[2] |
| 2021年9月 | 関係役員を処分。9月24日の第三報で、10月1日付の専任の CISO の任命を発表[3][6] |
| 2021年12月9日 | 第四報。ProjectWEB の利用終了と新しいツールへの移行を決定。社内の調査は完了し、数種類の脆弱性があったが悪用されたものは特定できなかった。多要素認証が無く、早期に検知する仕組みも十分でなかった。内閣サイバーセキュリティセンター等に検証を相談[4] |
| 2022年3月7日 | 第五報。外部からの協力等で、被害のあった顧客は142と判明[5] |
| 2022年3月28日、4月22日 | 外部の有識者による検証委員会の報告書を受領し、4月22日の第六報で原因の分析と再発防止の提言を公表[6][7] |
政府の側では、内閣官房の内閣サイバーセキュリティセンター、国土交通省、外務省などが使う情報システムの情報が流出したと発表された[10]。
通った道筋
富士通の判断は、ProjectWEB に数種類の脆弱性があり、第三者がそのいずれかを用いるなどして正規のIDとパスワードを盗み、正常な認証と通信に見える形で外から入った、というものである。脆弱性の悪用、運用の管理者や利用者の端末のマルウェア感染など、あらゆる可能性を調べたが、悪用された脆弱性は特定できなかった[4]。
認証が通った後の操作は、記録の上では正規の利用者の操作と区別が付かない。区別の手掛かりになるのは、どこから入ったか、いつ、どれだけ読んだか、ふだんその利用者が触らない案件かどうか、という振る舞いである。富士通は、ログの収集と管理の方法を調査で分かった問題に挙げ、新しいツールでは複数のログを一元的に集めて不審な挙動を監視するとした[4]。
報道には、すべての案件を管理する管理用のアカウントが不正アクセスされた、という説明がある。富士通の公表資料は、正規のIDとパスワードが使われたこと、悪用された脆弱性は特定できなかったことだけを書き、どの種類のアカウントかを書いていない[2][4]。
架空の監査の記録と、振る舞いで見つける規則。値はすべて説明用
# share.example.com の監査の記録。認証は成功し、通信も正常
time=02:13 user=pm-0142 src=198.51.100.23 action=login result=ok mfa=none
time=02:14 user=pm-0142 src=198.51.100.23 action=download project=P-0091 files=37
time=02:15 user=pm-0142 src=198.51.100.23 action=download project=P-0307 files=52
# 規則の例。1件ずつは正常でも、組み合わせで知らせる
alert if src not in known_ranges(user) # 初めて見る接続元
alert if count(distinct project, 1h) > usual(user) * 3 # ふだん触らない案件
alert if sum(files, 1h) > usual(user) * 10 # 取得の量の急増規則の値は例である。ふだんの値を持つには、利用者ごと、案件ごとの記録を1か所に集めて残しておく必要がある。記録の置き方は A09 セキュリティログとアラートの不備 にある。
どこで止められたか
| 段 | この件で公表資料にあること | 止める仕組み |
|---|---|---|
| 1 盗む | ProjectWEB に数種類の脆弱性があった。人員と予算の制約からセキュリティの強化と管理に手が回らなかった、と検証委員会は指摘した[4][7] | 外に開いた社内のシステムを台帳に載せ、診断し、修正の期限を決める。検証委員会は社内のITシステムの一元管理を提言した[7] |
| 2 入る | 多要素認証が採用されていなかった[4] | 社外から入れる共有の基盤は、多要素認証を必須にする[4][6] |
| 3 気付かれず | 不正アクセスを早期に検知する仕組みも、直ちに検知する体制も整っていなかった[4][7] | 複数のログを一元的に集め、不審な挙動を監視する[4] |
| 4 多く読める | 別の案件の領域にデータがあった例、終了した案件のデータが長く残った例があった。各テナントの管理の多くがテナントの管理者に委ねられていた[4][7] | 案件ごとに分け、終了したら消す。秘密度に応じたアクセス制御。運用を任せる場合も、全社で現物を確かめる[4] |
| 5 範囲が不明 | 属人的な運用とログの管理の不適切さで、構造の把握に時間を要した。個別の案件のインシデントとして扱い、全社の対応が遅れた[7] | ログの一元管理で原因と範囲の調査を速くする。大規模な事案の緊急の体制と訓練を平時に用意する[4][6] |
1と2 盗む、入る。根本の段
IDとパスワードは、どの経路で漏れても同じように使える。脆弱性、端末の感染、使い回し、どこから漏れたかが最後まで特定できなくても、2つ目の要素が要るなら、盗んだ組だけでは入れなかった。新しいツールは、多要素認証で不正なログインを防ぐとしている[4]。認証の規則は A07 認証の不備 にある。
脆弱性が数種類あったことは、外に開いたシステムに対する弱点の管理が回っていなかったことを示す。検証委員会は、ProjectWEB が当初の想定より幅広い環境と目的でなし崩しに使われ、性質や使われ方に合った扱いがされていなかったこと、社内のシステムが全社で一元に管理されていなかったことを真因に挙げた[7]。何が外に開いていて、何を預かっているかの台帳が無ければ、直す順番も決められない。
3 気付かれず。振る舞いで見る
正規の資格情報による操作は、認証の成否だけを見ても区別できない。接続元、時間帯、触った案件の数、取得の量を利用者ごとに比べて初めて、異常として浮かぶ。上の架空の規則のように、1件ずつは正常な操作の組み合わせで知らせる。
4 多く読める。置く量を減らす
漏れた量の上限は、入られた時点で置いてあった量で決まる。終了した案件のデータを残さない、案件の領域を混ぜない、秘密度に応じて読める人を分ける、の3つは、入られた後の被害を直接小さくする[4]。テナントを分ける設計は A06 安全性を欠いた設計 にある。
5 範囲が不明。ログと体制
被害のあった顧客の数は、公表から約10か月後に129から142へ直された[2][5]。誰がどの案件の何を読んだかが後から引けなければ、範囲は広く見積もるか、遅れて確定するしかない。検証委員会は、発覚後の対応の遅れの原因に、個別の案件の事案という前提で動いたこと、属人的な運用とログの管理の不適切さ、インシデントの体制が効果的に働かなかったことを挙げた[7]。
委託元の側
この件で情報を流出させたのは委託先の共有のツールで、委託元のシステムへの侵入は国土交通省の発表では確認されていない[9]。ただ、取られた機器の構成の情報は、委託元のシステムへの次の攻撃の材料になりうる。内閣サイバーセキュリティセンターの注意喚起は、委託先を含めて同種のツールを使っているかを確かめ、不正アクセス対策を設置者に確かめること、格納された情報資産を確かめ、漏れた際の処置として資格情報の更新などを検討すること、を挙げた[8]。委託先に渡した資料の中の資格情報は、渡した時点で自社の外にある。
守り方
- 社外から入れる共有の基盤は、多要素認証を必須にする。回復の手段も同じ強さにそろえる[4]。A07 認証の不備
- 外に開いた社内のシステムを台帳に載せ、持ち主、預かる情報、使われ方を決める。診断と修正の期限を回す[7]。部品の弱点の管理は A03 ソフトウェアサプライチェーンの不備 にある。
- 置く量を減らす。案件ごとに領域を分け、終了したら消し、秘密度に応じて読める人を絞る[4]。A01 アクセス制御の不備
委託先の公開の誤りから鍵が漏れた件は T-Connect 2022年 公開されたソースの中の鍵 にある。
参照
- プロジェクト情報共有ツールへの不正アクセスについて 富士通、2021年5月25日
- プロジェクト情報共有ツールへの不正アクセスについて 第二報 富士通、2021年8月11日
- プロジェクト情報共有ツールへの不正アクセスについて 第三報 富士通、2021年9月24日
- プロジェクト情報共有ツールへの不正アクセスについて 第四報 富士通、2021年12月9日
- プロジェクト情報共有ツールへの不正アクセスについて 第五報 富士通、2022年3月7日
- プロジェクト情報共有ツールへの不正アクセスについて 第六報 富士通、2022年4月22日
- 別紙 検証委員会からご指摘頂いた事項 富士通、2022年4月22日
- プロジェクト情報共有ツールに対する不正アクセス対策の確認に関する政府機関等及び重要インフラ事業者等への注意喚起の発出について 内閣サイバーセキュリティセンター、2021年5月25日。元の場所から消えているため Internet Archive の写し
- 富士通株式会社が管理・運営するプロジェクト情報共有ツールへの不正アクセスによる国土交通省関係情報の流出について 国土交通省、2021年5月26日
- サイバーセキュリティの最近の動向及びICTサイバーセキュリティ政策分科会について 資料1-2 総務省、2024年2月