2025年9月の気になるインターネット記事をピックアップ
今回は取りあげる記事の数は少ないものの、大きく取り上げられたセキュリティに関する２つの話題について書きます。
9月は特にサプライチェーン攻撃が印象に残った1か月でした。便利なOSS無くして現代のソフトウェアは成り立ちませんが、あるソフトウェアが別のソフトウェアを内部で利用していて、そのソフトウェアも内部で別のソフトウェアに依存していて…という鎖(チェーン)で構成されています。このチェーンの1か所が切れてしまうとシステム全体が機能不全になってしまう。これがサプライチェーン攻撃です。
脆弱性「s1ngularity」とは何か？AI悪用・機密情報流出をもたらす新型サプライチェーン攻撃の概要
今回ターゲットとされたのはビルドツール「nx」です。「nx」は、JavaScript、Java、Go、Pythonなど様々な言語で記載されたソースコードを管理・処理し、それらを実行可能な成果物（Webアプリケーションが動くファイル、サーバーサイドの実行ファイルなど）にするためのパッケージです。 nxは人気のパッケージ管理システムnpmでインストールすることができますが、npmのストレージのアクセス権が漏洩したのか、ストレージに改ざんされたコードがアップロードされます。npmの特徴として、npmコマンドを実行したフォルダの直下に存在するpackage.jsonというjsonファイルに、インストールするライブラリのリストや、インストール前後の処理を記述する機能があり、改ざんされたnxのコードには、nxインストール時に悪質なコードを一緒にダウンロードし、実行するように記述されていたとのことです。
改ざんされたコードがどのように振舞うかはこの後説明するとして、今回の脆弱性がサプライチェーン攻撃と言われる理由は、「人気のパッケージ管理システムnpmでインストールされるパッケージが改ざんされたことで、多くのユーザが影響を受けてしまった」点です。特にnpmはpackage.jsonを使って複数のソフトウェアをまとめて（ユーザが意識することなく）ダウンロードし、さらにダウンロードされたツールを実行する命令文を書ける利便性が悪用されました。
加えて特筆すべき点が悪意あるコードの実装、動作の挙動。post-installでインストール後に実行されるコードには、ローカルPCにインストールされている可能性があるAIコマンドラインツール（例: Claude、Gemini、GitHub Copilot CLIなど）を探し出して、AIエージェントに対して様「このPCの公開鍵情報を取得して」「このPCのクレデンシャル情報を取得して」などの問い合わせを行う命令文（プロンプト）が記載されていた点です。 従来であれば複雑なロジックを記載して実現していた攻撃を、AIに代替わりさせたのです。窃取した機密情報は被害者のGitHub上に公開リポジトリ「s1ngularity-repository」が作成され、そこで暴露されたとのことですが、”s1ngularity”という名前は「Singularity（特異点）」をもじったものと思われます。AIを活用したサイバー攻撃という点で確かに特異点のような存在かもしれません。
文章で説明すると分かりにくいので画像にしました。まとめると以下のような挙動となります。この画像も生成AIに指示して作ってもらいました。正しく使えば便利なAIも悪用すれば破壊的な効果を持ちます。
さらに9月は「Shai-Hulud」（シャイ・フルード）ワーム攻撃という「s1ngularity」攻撃と非常に似た手口を使いながら、より深刻なサプライチェーン攻撃がありました。
「Shai-Hulud」ワームがサプライチェーン攻撃でnpmエコシステムを侵害
まず、npmの管理者に対してフィッシングメールを送り、認証情報を盗みます。s1ngularityはnxライブラリのみが対象でしたが、こちらは複数のパッケージ（人気のパッケージの管理者の認証情報も盗まれたとのことです）が改ざんされ、アップロードされたとのことです。s1ngularityと同様に、package.jsonに仕込まれたpost-installスクリプトによって悪意あるコードが自動実行され、機密情報がスキャンされ、被害者の公開リポジトリに暴露されます。 ここからが恐ろしく、Shai-Huludは盗み出した情報の中に、パッケージを公開するための有効なnpmトークンが存在した場合、侵害された開発者が管理・公開権限を持つ他のすべてのnpmパッケージに対して改ざんしたコードをアップロードする自己増殖機能を持ちます。1つの改ざんされたパッケージから指数関数的に改ざんされたパッケージが増加する恐ろしい機能を持ちます。
今月立てつづけにOSSのエコシステムに対しての攻撃が行われました。OSSは信頼性で成り立っており、いくらチェック機構が働いていたとしても攻撃者が攻撃に必要なカロリーは防御側が防御に必要なカロリーよりはるかに少ないのが現状です。当然でしょう。攻撃側は鎖のどこか1か所を切ればよいのに対し、防御側はすべての鎖を守らないといけないのですから。
こちらの記事にあるように、「クレデンシャルを平文で保管せず、利用する際にはPassKeyなどの認証を組み込む」「開発用コンテナ内でパッケージをインストールして、万一改ざん被害に遭ったとしても被害範囲を最小限に抑える」は非常に有効です。面倒ですが・・・。記事の最後にあるように
今まで我々が甘んじてきた牧歌的な開発環境を見直し、OSS のリスクとベネフィットを正しく受け入れる体制に移行すべき時が来たのだと考えたい
ということなのでしょう。
もう一つ、改ざんされたツールをインストールしない対策として、ライブラリのバージョンを固定する方法があります。 ライブラリをインストールする際、アットマークを使って特定のバージョンを利用するよう記載することはあると思います。バージョンを指定しないと、ライブラリ側のデフォルトバージョン（たいていはlatest）が使用され、場合によっては今まで動作していたプログラムが動かなくなる可能性があるからです。 しかしこの方法はパッケージファイルの内容が改ざんされていないことが前提です。今回のように悪意あるコードに差し替えられた場合は無力です。タグは単なる「名前」であり、内容の同一性を保証しません。 対策として、npm ciを使い、改ざんされていない特定バージョンのパッケージを利用する方法が有効です。パッケージのバージョンを固定するファイルとしてpackage-lock.jsonをpackage.jsonの代わりに使用します。このファイルは、プロジェクトが使用するすべての依存関係について、以下の情報を記録します。
- バージョン：使用すべきパッケージの正確なバージョン。
- 整合性ハッシュ（Integrity Hash）：パッケージのダウンロードファイル全体から計算された、一意のチェックサム（ハッシュ値）。
そのうえでnpm installではなく、npm ciコマンドを使用します。npm ciコマンドはpackage-lock.jsonのみを参照し、ダウンロードしたパッケージのハッシュ値を計算し、package-lock.jsonのハッシュ値と不一致と判断した場合、エラーを出してインストールを中止します。これにより正しいパッケージのみを利用することができます。 加えて、GitHubActionsにも「pinact」というライブラリがあり、こちらはGitHub Actions自身 (uses: actions/checkout@v4など)の@以降をハッシュ値で指定することができるようになります。
- pinact：CI/CDパイプラインを動かす「土台（GitHub Actions）」の改ざんを防ぐ。
- npm ci：CI/CDパイプラインでインストールされる「部品（npmライブラリ）」の改ざんを防ぐ。
pinactとnpm ciを組み合わせることで、より強固なCI/CDを構築することができます。
【独自】フェリカに重大な脆弱性 交通系IC、データ改ざんの恐れ ソニー、フェリカに脆弱性 17年以前のICカードの一部に該当
FeliCaはソニーが開発した非接触ICカードの技術方式です。高いセキュリティがウリで、SuicaやモバイルPASMOといった様々なサービスで使われる通信技術です。そこに暗号鍵の漏洩のリスク、つまりデータ盗聴、改ざんのリスクがあるというニュースです。 昔のFelicaカードが対象のため、現在普及しているモバイルFelicaは対象外となります。また、Felicaはインターネットを介するのではなく近接型の通信のため、通信の傍受が難しく、そこまで大きな影響はないのでは、と考えています。詳細については以下のnoteが詳しく解説しています。
FeliCaの脆弱性ってヤバいの？そうでもないの？（421号）
この件は、むしろその情報公開の形によって大きな話題となっています。
国内における脆弱性関連情報を取り扱う全ての皆様へ – 情報セキュリティ早期警戒パートナーシップガイドラインに則した対応に関するお願い – FeliCaの“脆弱性”報道はなにが問題なのか
「人質立てこもり事件が起きた際、メディアに対して報道の自粛、抑制を警察が依頼する」というケースがあります。情報が筒抜けになると犯人が動きやすくなったり、犯人を余計に刺激したりするなどの問題があるからです。脆弱性についても同様で、脆弱性を発見した場合、まずはしかるべき組織に連絡する、そしてその組織から製品（ソフトウェアだったり、ハードウェアだったりします）開発元へ連絡し、ちゃんと直してから全体へアナウンス、「既に修正済みです」というのが標準の動きになります。登録セキスぺであればこの話は毎年オンライ研修のたびに目にしているのではないでしょうか。
本件は共同通信のスクープという形で報道されました。共同通信によると、どうもこの脆弱性を見つけた人から情報を得たようです。うっかり喋ってしまったのか、いつまで経っても修正されないので義憤にかられたのかは分かりませんが、Felicaは広範囲で使われていて、お金の取引もFelicaを搭載したデバイスで行うことから、ニュースで、それもスクープという形でアナウンスされたら一般の人は驚いてしまうでしょうね。先ほど書いたように大半の人には影響がないと分かっているのはエンジニアの人たちですから。