LastPass のソースコード流出 – インシデント対応レポートが公開される

** 本記事は、LastPass source code breach – incident response report released の翻訳です。最新の情報は英語記事をご覧ください。**

今月の大きな話題が、ハッカーがライドシェアリング会社のネットワークを広くアクセスしたとされる、Uber の情報漏洩についてであったとするならば、先月の大きな話題は、攻撃者が LastPass のネットワークの一部にアクセスし、同社のソースコードを窃取したとされる LastPass の情報漏洩になるでしょう。

Uber の事件に関しては、攻撃者がスクリーンショットを撮影してオンラインで大量に拡散したり、会社の Slack やバグバウンティのフォーラムにて「UBER がハッキングされた」といったメッセージを用いて挑発をしたりと、すばやく大げさに PR しようと試みたことが、Uber にとっては幸運でした。

しかし LastPass の攻撃者は、LastPass の開発者を騙してマルウェアをインストールさせ、そのマルウェアを使って同社のソースコードのリポジトリに侵入するなど、非常に巧妙な攻撃だったと考えられます。

LastPass は、侵入直後に把握した攻撃と攻撃者に関する情報に基づいて、このインシデントに関する公式のフォローアップレポートを公開しました。

LastPass の記事は、LastPass ユーザーでなくても読む価値があるものです。なぜなら、優れたインシデント対応レポートを読めば、現状で把握できている情報と同様に、何が把握できていかったのかも再認識できるからです。

現在把握できていること

以下の太字の文章は、LastPass が発表した内容の概要を示しています。

• 攻撃者は、セキュリティが侵害された開発者のエンドポイントを使用して、開発環境へアクセスしました。これは、攻撃者がプログラマーのコンピュータにシステムをスパイするマルウェアを埋め込んだことが原因だと推測されます。
• マルウェアを埋め込むために使用された手口は特定できませんでした。今回の攻撃が実際にどのように行われたかを把握できれば、予防、検知、対応の手順を見直すことができ、今後攻撃を阻止できる可能性があると顧客を安心させることにつながるため、この手口を特定できなかったのは残念なことです。たとえば、パッチが適用されていないローカルソフトウェア、「シャドー IT」による安全でないローカル設定、フィッシングリンクのクリック、安全でないダウンロード、コーダーが信頼するソースコードのサプライチェーンの汚染、悪意のあるメール添付ファイルなどが、潜在的な攻撃経路として考えられます。LastPass が今回の攻撃手法が未知であることを認めたことは評価すべきです。
• 開発者が多要素認証に成功した後、攻撃者は、永続的なアクセス権を利用して開発者になりすましました。このため、ハッカーがユーザーのパスワードや 2FA コードを取得する必要はなく、単に Cookie を窃取する攻撃や、プログラマーの通常のアクセスに便乗するために、正規のネットワークトラフィックから (あるいはユーザーのコンピュータの RAM から) 開発者の認証トークンを抽出したと推測されます。

• LastPass はこの侵入にすぐには気づきませんでしたが、4 日以内に攻撃者を発見し、ネットワークから追い出しました。システムログのタイムスタンプがあいまいな場合のリスクについて最近の記事で述べたように、攻撃時のイベントの発生順序を正確に判断することは、インシデント対応において重要な要素です。

• LastPass は、開発用ネットワークと本番用ネットワークを物理的に分離しています。これは素晴らしいサイバーセキュリティ対策です。なぜなら、開発ネットワーク (環境が継続的に変化し、テストされているネットワーク) への攻撃が、顧客やその他のビジネスに直接利用可能な正規のソフトウェアの侵害につながることを阻止できるからです。
• LastPass は顧客データを開発環境には一切残していません。開発者は、全面的なセキュリティレビューと品質保証プロセスが完了していないソフトウェアを開発していることを考えると、顧客データを開発環境に残さないのは優れた取り組みであると言えます。この開発用ネットワークと本番用ネットワークの分離により、LastPass はパスワード保管庫のデータ (いずれにせよユーザーの秘密鍵で暗号化されているはず) が流出することはないと主張することができます。これは単に「流出した証拠が見つからなかった」と言うよりも強い主張となります。実環境のデータを開発ネットワークから排除することは、プログラマーが善意で、規制で保護されているデータを誤って入手して、認められていないテスト目的で使用するのを防ぐことにもなります。
• ソースコードは流出しましたが、攻撃者によって不正にコードが変更されたわけではありません。もちろん、LastPass の主張しか証拠はありませんが、インシデントレポートで公開された情報を考えると、同社の言葉を信じない理由はないでしょう。
• ソースコードが開発ネットワークから本番環境に移行するのは、「厳格なコードレビュー、テスト、検証のプロセスが完了した後でなければ起こりえない」と思われます。.このことから、LastPassによる「たとえ攻撃者がバージョン管理システムに不正なコードを埋め込んだとしても、改変または汚染されたソースコードが顧客や他の企業に届くことはなかった」という主張がより真実味を帯びてきます。
• LastPass が、ユーザーの個人的な復号化キーを保存したり、知ってしまうということさえも起こりえません。つまり、仮に攻撃者がパスワードデータを盗んだとしても、それは単なるデジタルの紙クズでしかないということです。(LastPass はまた、パスワード保管庫のデータをオフラインでのクラッキングから保護する方法についての説明を公開しています。たとえば、クライアント側の PBKDF2-HMAC-SHA256 を使用して、オフラインパスワードのソルト化・ハッシュ化・ ストレッチングにより、100,100 回イテレーションする方法などです。これにより、攻撃者がパスワード保管庫のローカルに保存したコピーを盗んだとしても、パスワードのクラッキングは難しくなるでしょう。)

対策

ソフォスによる当初の想定は当たっていたと言えるでしょう。また。このハッキングは LastPass にとって恥ずべき事件であり、株主価値の一部であると考えていた企業秘密が明らかになってしまうかもしれませんが、この攻撃で顧客のパスワードが解読されたわけでもないことから、LastPass が自社で解決すべき問題として捉え、対処することが妥当だと考えています。

この攻撃と LastPass のインシデントレポートによって、ゼロトラストという専門用語でも知られる「分割型の統治手法」が現代のサイバー防衛にとって重要であることを再確認できます。

ソフォスのエキスパートである Chester Wisniewski 氏が、最近の Uber へのハッキングの分析で説明しているように、ネットワークの一部にアクセスした犯罪者が、ネットワーク全体にアクセスするために自由に動き回ることができてしまうと、より多くの危険にさらされることになります。