ソフトウェア サプライチェーンにリスクをもたらす開発者アカウントの乗っ取り
- ここ数年、重大なソフトウェア サプライチェーン攻撃が頻発しています。こうした攻撃は検出が難しいため、本調査ではソースコードリポジトリに注目しました。
- 開発者アカウントの乗っ取りは、ソフトウェア サプライチェーンに重大なリスクをもたらします。開発者アカウントの侵害に成功した攻撃者が、他のユーザーが使用するソフトウェアパッケージ内に悪意のあるコードを潜ませる可能性があるからです。
- Talos は、いくつかの主要なソフトウェアリポジトリを分析し、開発者アカウントのセキュリティレベルを評価しました。特に重視したのは、有効期限の切れたドメイン名を再登録してパスワードをリセットさせるというやり方で開発者アカウントを復活させられるかという点です。
- 多くのソフトウェアリポジトリは、開発者アカウントのセキュリティを強化するための措置をすでに講じ始めています。Talos は、開発者アカウントのセキュリティをさらに改善できる新たな領域を特定しました。脆弱なリポジトリとは連携を取り、発見された問題の解決にあたっています。
ソフトウェア サプライチェーン攻撃といえば、かつては国家の支援を受けた高度なスキルを持つ攻撃者の専売特許でした。しかし最近では、さまざまなサイバー犯罪者の間に広まっています。ソフトウェア サプライチェーン攻撃が非常に効果的であり、多数の被害者を出す可能性があることに、そこかしこにいる攻撃者が気付いているのです。2021 年のソフトウェア サプライチェーン攻撃の発生件数は、2020 年と比較して 3 倍以上に増加
しました。ソフトウェア サプライチェーン攻撃がこれほど効果的なのはなぜなのでしょうか。強固なサイバー防御を備えた組織に直接攻撃を仕掛けるのは難しいものです。ですが、そうした組織も、ソフトウェア サプライチェーン攻撃に対しては脆弱な可能性があります。結局のところ、信頼を置いているベンダーから入手したソフトウェアを定期的に実行/構築しているからです。
ソフトウェア サプライチェーンの侵害は、ソフトウェアリポジトリ全体を攻撃したり、パッチ未適用のソフトウェアパッケージの脆弱性を特定したりするより簡単です。パッケージの開発者や保守管理者のアカウントを攻撃するのと同程度の難しさだと考えられます。ほとんどのソフトウェアリポジトリでは、ソフトウェア開発者の身元確認に電子メールアドレスを使用しています。サイバー犯罪者が何らかの方法で開発者の電子メールアカウントにアクセスできるようになれば、理論上、ソフトウェアリポジトリでパスワードリセットの電子メールを生成し、その開発者のアカウントを乗っ取ることができます。ソフトウェアリポジトリに侵入すれば、開発者が保守管理しているコード向けの悪意のある更新を公開できます。そうすれば、同ライブラリを使用する他のすべてのソフトウェアに影響を与えられます。
Cisco Talos は、頻繁に使用されるコードリポジトリをいくつか調べました。特に開発者アカウントのセキュリティに注目し、攻撃者が開発者のアカウントを乗っ取るのがどの程度難しいかを調査したところ、厳格なセキュリティを備えているリポジトリもありましたが、備えていないところもありました。幸い、セキュリティ面に問題のあるリポジトリについては、管理者と協力し、発見された主要な問題を解決できました。
ソフトウェア サプライチェーンが抱えるリスク
一般的に言って、一からの開発は得策とは言えません。これは多くのことに当てはまり、ソフトウェア開発についても例外ではありません。現在作成されているソフトウェアの多くは、サードパーティのパッケージとソフトウェアライブラリを活用しています。そうすることで、プログラムに含まれる必要な機能を容易に実装できるようにしているのです。サードパーティのライブラリとパッケージ、特にオープンソースを利用すると、開発のスピードを上げつつコストを下げられます。
人気のあるソフトウェアパッケージも、攻撃者にとって魅力的な標的になっています。ソフトウェアライブラリの人気が高ければ高いほど、使用する外部ソフトウェアが増えるため、潜在的なアタックサーフェス（攻撃対象領域）が拡大します。ソフトウェアライブラリを侵害すれば、そのソフトウェアライブラリを活用した機能を搭載しているすべてのソフトウェアを侵害できる可能性があります。このリスクは、ソフトウェア サプライチェーンにはつきものです。
GitHub のように言語を限定しないソフトウェアリポジトリもありますが、特定の言語に限定されているリポジトリがほとんどです。たとえば JavaScript の作成者は主に NPM、Python 開発者は PyPI を使用します。また、Perl プログラマは CPAN で取得したパッケージをよく使用します。それぞれのソフトウェアリポジトリで、開発者のアカウントに関する独自のルールが設定されています。
さらに、多くのプログラマが認識していることですが、特定のタイプの問題を解決するには、特定のプログラミング言語が他より適している場合があります。たとえば組み込みシステムのドライバは、Perl ではなく C で作成されるのが一般的です。一方、テキスト解析は、C ではなく Perl や Python で作成されるのが一般的です。つまり、サードパーティのライブラリをコードに統合するプログラムを作成するプロセスも、言語ごとに異なるということです。サードパーティのライブラリを C で記述されたシステムレベルのドライバに統合するとします。この場合、関連するコードを注意深くレビューして速度と機能をテストすることなく統合することはまず考えられません。ですが、機能が豊富な Perl の概念実証アプリケーションや Web ベースの JavaScript アプリケーションを開発する場合は、必ずしもそうとは限りません。もしかしたら、先にパッケージをインポートして、後で質問するプログラマがいるかもしれません。つまり、ソースコードにマルウェアが潜んでいる場合、一部のソフトウェアリポジトリは相対的にリスクが高くなります。
NPM
Node Package Manager は JavaScript のソフトウェアリポジトリであり、最近いくつかの「独立した」セキュリティ監査の対象となりました。この件は、オンラインで大いに議論を呼びました。特に懸念されたのは、開発者アカウントのセキュリティと、期限切れの電子メールドメインを再登録することでアカウントを簡単に乗っ取ることができるかどうかという点です。
NPM リポジトリには 200 万個を超えるパッケージがあります。「all-the-package-names」という NPM パッケージには、便利なことに、NPM リポジトリ内のすべてのパッケージのリストが記載されています。NPM の各パッケージには、パッケージについての説明文、パッケージ tarball へのリンク、パッケージ保守管理者のリストなどのメタデータが関連付けられています。ここで特に重要なのは、パッケージ保守管理者のリストにパッケージ開発者のユーザー名と電子メールアドレスが掲載されていることです。
すべてのパッケージ名を反復処理して電子メールアドレスを抽出し、電子メールアドレスからドメイン名をさらに抽出すると、期限切れのドメインに関連付けられている開発者アカウントを見つけるのに必要な生データが入手できます。期限切れのドメインが見つかったら、それを再登録して使えば、理論的には NPM 開発者アカウントを乗っ取ることができます。しかし、このやり方は実際にうまくいくのでしょうか。
数千の期限切れの開発者アカウントのドメイン名が見つかりましたが、関連付けられている開発者アカウントを復活させることはできませんでした。NPM 管理者の Myles Borins 氏（@MylesBorins）が上記のツイートで言及している「『アカウントの乗っ取り』から保護するためのいくつかの対策」は、計画どおりに機能しているようです。
古いメタデータが攻撃者の企みをくじく一助に
NPM は、開発者が自分のアカウントに関連付けられている電子メールアドレスを更新する機能を提供しています。開発者が電子メールアドレスを変更することにした場合、新しい電子メールアドレスは以降のパッケージ/バージョンのメタデータだけに記載されることになります。過去に公開されたパッケージに関連付けられている古いメタデータを遡及的に更新することはありません。つまり、NPM 開発者アカウントを乗っ取ろうとしている誰かが、パッケージのメタデータに記載されている期限切れの電子メールドメインに関連付けられた開発者アカウントを見つけたとしても、その開発者が自分の NPM アカウントを新しい電子メールアドレスに更新しただけということもあり得るのです。
ここで 2022 年 5 月の事例をご紹介しましょう。あるセキュリティ研究者が、NPM パッケージ「foreach」の開発者の電子メールアドレスを再登録したことをもって、同パッケージを乗っ取ったと主張しました。この研究者は把握していなかったのですが、当の開発者は実際には NPM アカウントを更新して Gmail アドレスに変更していました。なので、たとえパスワードの復活を試みたとしても失敗に終わったはずです。NPM が生成したパスワードリセットメールの送信先はファイルにある新しい Gmail アカウントであり、元の開発者が今も管理しているからです。
PyPI
PyPI（Python Package Index）には、現在、約 40 万件のプロジェクトが掲載されています。PyPI の開発者の電子メールアドレスはアカウントに関連付けられていますが、デフォルトでは公開されません。メールアドレスを公開するオプションを有効にするかどうかは、開発者が明示的に選択する必要があります。もちろん、多数の開発者がこのオプションを有効にしても不思議ではありません。多くの開発者は自分のコードを実行している他のユーザーとやり取りしたいと考えるものだからです。
PyPI アカウントでは、MFA がデフォルトでは有効になっていないので、有効にするかどうかは開発者が選択する必要があります。ただし、2020 年 7 月に PyPI は、「重要なプロジェクト」、すなわち PyPI の上位 1% のプロジェクト（ダウンロード数に基づく）では MFA を必須にすると発表しました。
PyPI パッケージの全リストはオンラインで入手できます。パッケージの多くには、電子メールアドレスが記載された mailto: リンクが記載されています。パッケージの保守管理者のリストもあります。開発者が電子メールアドレスを公開している場合、ユーザーの公開プロフィールページに掲載されています。PyPI プロジェクトに関連付けられている電子メールアドレスは、比較的簡単に入手できます。PyPI では、電子メールアドレスがアカウントに関連付けられているかどうかが分かります（本来なら明らかにすべきではないでしょう）。
PyPI では、過去にアカウントの乗っ取りが問題になりました。2022 年 5 月 14 日には、攻撃者が開発者アカウントを乗っ取って「ctx」パッケージを置き換えるという事件が発生しています。ユーザーの環境変数を盗み、base64 でエンコードしてデータを攻撃者の C2 サーバーに送信する悪意のあるコードをこの攻撃者は追加しました。幸い、PyPI の管理者が変更を実施したことで、アカウントのセキュリティは適切な方向へと進んでいるようです。
CPAN
Comprehensive Perl Archive Network（CPAN）には、20 万個を超える Perl モジュールが掲載されています。また、モジュール作成者全員の索引も公開されています。
モジュールの作成者は、自身が手掛けたモジュールを一覧表示する独自の「ホームページ」を持っています。開発者に連絡したい人のために、作成者の電子メールアドレスが掲載されています。
その気になれば、攻撃者は CPAN の Web サイトからすべての作成者 ID のリストを簡単に入手できます。さらに、それらの ID を使用すれば開発者の電子メールアドレスを収集できます。開発者の電子メールアドレスの電子メールドメインで whois 検索を行えば、アカウントを乗っ取りやすい脆弱な開発者アカウントのリストが手に入ります。あとは、当該ドメインをどこかで立ち上げてメールサーバーを実行するだけです。パスワードのリセットを行えば、開発者のアカウントにアクセスできる魔法のリンクが手に入ります。
Talos は CPAN の管理者に連絡を取り、発見された脆弱な開発者アカウントのリストを提供しました。CPAN はこれらのアカウントを無効にしています。
NuGet
NuGet は、.NET 開発者向けのソフトウェアリポジトリです。NuGet の「ギャラリー」には、31 万 7,000 個を超えるパッケージが掲載されています。幸い、NuGet に登録されている開発者のメールアドレスはデフォルトでは非表示となっています。NuGet の Web サイトには、ユーザーがフォームを使用して開発者に連絡できるオプションが用意されています。このフォームを使った場合、開発者の電子メールアドレスは開示されません。開発者には Twitter ハンドルを追加するオプションが用意されており、多くの開発者が利用しています。攻撃者が NuGet の開発者をまとめて攻撃しようとしても、開発者の電子メールアドレスのリストを作成するのは非常に困難です。
RubyGems
RubyGems は、Ruby 開発者向けのソフトウェアリポジトリです。現在、リポジトリには約 17 万 2,000 個の gem（パッケージ）が掲載されています。開発者のメールアドレスは、デフォルトでは一般公開されません。[Hide email in public profile（公開プロファイルでメールを非表示にする）] チェックボックスをオフにしても目に見える効果はなく、メールアドレスは非表示のままです。
開発者の連絡先メールアドレスを記載した「maintainers」ファイルのある gem もありますが、すべての gem がそうではありません。最近、RubyGems チームは、上位開発者のアカウントには MFA を必須にすると発表しました。
まとめ
ソフトウェア サプライチェーン攻撃の問題は、すぐには解決しそうにありません。組織に、自環境で実行されるすべてのソフトウェアを精査するよう求めるのは不合理です。ソフトウェアベンダーとサプライヤーのことは、いずれにしてもある程度信頼せざるを得ないのです。ただし、だからといって防御側がこの種の攻撃に対して無力であるというわけでもありません。
組織は、さまざまな内部システムで必要となっているソフトウェアを分析しておく必要があります。特定のソフトウェアを実行しているシステム群を他の内部ネットワークからセグメント化する機会なら、多々あるのではないかと思います。そうしておけば、たとえソフトウェア サプライチェーン攻撃を受けても、結果的に生じる侵害の範囲を限定できるでしょう。ただ、このアプローチでは限界があるのは確かです。
ソフトウェア サプライチェーンの全関係者は、セキュリティに対してより多くの責任を引き受ける必要があります。たとえばソフトウェアリポジトリでは、開発者の電子メールアドレスに関連する情報の公開や開示を停止した方がはるかに安全でしょう。もちろん、非公開にすることでセキュリティを確保するということには多少議論の余地があると思います。ですが、開発者の電子メールアカウントと特定のソフトウェアパッケージを関連付けようとしている攻撃者は退散するしかなく、リポジトリのセキュリティが大幅に高まることになります。リポジトリが開発者の電子メールアドレスを公開したいのなら、各自のアドレスの代わりにリポジトリのドメインの電子メールアドレス（@npmjs.com、@cpan.org など）を付与してもよいでしょう。
最も人気のあるパッケージの保守管理者には MFA を必須にするという対応も、理にかなった解決策のように思われます。現在、いくつかのリポジトリがこの対策を講じようとしているところです。ただし、セキュリティには微妙なさじ加減が必要です。セキュリティを追求するためにユーザビリティを犠牲にしすぎれば、開発者の反発を招くかもしれません。PyPI 開発者「untitaker」の例もあります。
期限切れのドメインの登録による開発者アカウントの乗っ取りに対する確実な対抗策としては、コード署名があります。使用するコードが最後に署名されてから改ざんされておらず、本当に信頼できる開発者が作成したものであることを確認できるので、最善の策と言えるでしょう。攻撃者は、開発者の期限切れのドメイン名を乗っ取ることはできても、開発者に属するコード署名キーを復元することも、開発者になりすますこともできないのです。
本稿は 2022 年 10 月 04 日に Talos Group
Tags:
