サプライチェーン攻撃とは
こんにちは、シニアソフトエンジニアのriddleです。 このポッドキャストは、IT業界のいろんな話やリアルをお届けします。
今回は、最近問題になっているサプライチェーン攻撃について、ちょっとお話ししたいなと思います。
サプライチェーンって流通の世界でよく言うんですけれども、 工場から次の卸へ、卸から工場へ、工場から出荷先のスーパーへ、みたいな感じで
原材料の調達から製造とか在庫、配送、販売を経て、最終消費者に届くまでのものの一連の流れのことをサプライチェーンって言うんですけれども、
ことITの世界においてはですね、OSSとかがよく槍玉に上がるんですけれども、そういうものをベースに最終的に我々が作っているプログラムに組み込まれていくわけなんですけれども、
そういった、例えばOSSのパッケージとかを自分たちのところに取り込んでいく一連の流れの中に、攻撃というかいろんな悪意あるものが詰め込まれて、
結果的にいろいろ問題を起こしてしまうような問題のことを俗にサプライチェーン攻撃と呼んでいます。
なんで今回このテーマを持ってきたかというと、最近ですね、このサプライチェーン攻撃に分類されるOSSを狙った攻撃が結構増えていてですね、
結果的にそのOSSを使っている各社のサービスも被害を受けてしまうというようなことが結構問題になっています。
普通ね、こういうセキュリティ系の攻撃って有名な企業とか有名なサービスとか、
あとはあんまりここセキュリティ強くないだろうなって思われるような小さな会社とか小さなサービスとか狙うこともあるんですけれども、
そういう場合ってなんかその会社のサーバーとかアプリケーションを直接攻撃してくるイメージあると思います。
また標的型攻撃といって特定の人に対してですね、狙いを定めて集中的に攻撃するとかそういったことがあるかなと思います。
そういうのって結局ターゲットがいてそのターゲットをピンポイントで狙うって感じなんですけれども、
最近はそれだけじゃないんです。最近だと日常的に使っているライブラリとかパッケージとかコンテナのイメージとかクラウドサービスとかいわゆるOSSって言わなくてもいいのかもしれないですが、
様々なライブラリとかパッケージを組み合わせて今のソフトウェアはほとんどできています。何にも頼ってないものって存在しないんじゃないのかな。
結果としていろんなものを組み込んでいるがゆえに一つでも何か悪いものがあったりすると自分のプログラムだったりアプリだったりサービスが侵害されてしまうというようなものになっています。
結構怖いわけですよね。直接狙われたというか、狙われたのは別のところなんだけど結果としてそこをベースに自分のところを侵害されてしまうような感じです。
サプライチェーン攻撃の具体例
例えばね自分たちアプリ作るときはもちろんゼロから全部作るんですよね。外部ライブラリ使いますしパッケージマネージャーで依存関係解決しますし
暗号化のライブラリなんてね自分たちで作ったら絶対バグだらけになるからそれは外部から扱いますよね。
例えばそれをデプロイしようと思ったらベースはどっかのコンテナイメージでしょうしGitHub使っていればCDIのGitHub Actions使うし
GitHub Actions使っていれば外部のActionsファイルとかも使えますよね。という感じでもう我々が開発するにはですねもう様々な先人が作ってくれたですねいろんなソフトウェアだったりパッケージだったりってものが必要になってくるわけで問題なのはまあそういうのって毎日毎日どんどん新しいものでできてよしバージョンアップだ入れようとか同じバージョンだからCDIで毎回ダウンロードできるよねとかなんかそんな感じのことやってるんですけど
いつも通り更新したりとかいつも通り同じバージョンインストールしただけなのにある日突然おかしくなるみたいなことが起きるんですよだから怖いんですよね
例えばですけど最近あったやつでGitHub Actionsというものですねよくあの人気のActionsだったレビュードックかな
特定のリンターとかでここの行おかしいよみたいなことをGitHub Actions上でわかりやすく表示してくれるGitHub Actionsがあったんですけどもレビュードックですね
これがその標的になりまして問題になったことがありますとサプライチェーンの攻撃対象となってしまったことがありますとそうするとこのレビュードックを使っていた
全然関係ないいろんなリポジトリがですねレビュードックきっかけで悪さに引っかかってしまったということがあります
そうするとそこから例えばちょっとクレゼンシャルに本番環境のトークンとかを何か入れさせてきてそしたらそれが取られちゃってそこから本番環境入られたとか
そういう二次被害とか三次被害にどんどんつながっていくという感じになっていく
今回もAxiosっていうJavaScriptのICTPリクエストとかを送るためのですね有名なライブラリがあったんですけどもそちらが侵害されて
それだとさらに立ちの悪いことにそのパッケージ自体は全然侵害されてないんだけどパッケージをインストールした後に動くなんかポストインストールっていうコマンドの中で
悪意あるファイルがダウンロードされて動き出すみたいなそういう感じだったんですよね
サプライチェーン攻撃への対策
なので現代のですね複雑化したソフトウェアの中でこれを対策をやっていかないといけないっていうのが結構難しいと言われております
だってね例えば1個アプリ作るのに何個外部ライブラリ使ってるのって話じゃないですか
GitHub使っててDependabotで有効にしている人は見て欲しいんですけどDependabotのディペンデンシーところから依存しているものがバーって見れるんですよ
今SBOMっていう共通の企画がありましてどんなライセンスでどんなパッケージを作っているかとかバーって見れるものがあるんですけど
ソフトウェアを構成する部品群みたいな感じですねそこを見ればどんなものを使っているかバーって見れるんですけど
まあそんだけ数がたくさんあるわけですよそれを全部ちゃんと管理しようと思うとめちゃくちゃ大変じゃないですか
でちょっとバージョン変わるだけでまたなんか問題が発生したバージョンになってるかもしれないっていうことなのでちょっと対策は難しいですよと
今なんか魔法のような解決策はですね正直自分は知らないです
なので一般的にこういう対策をすればだいぶリスクは減らせるんじゃないかって言われるものについてちょっとご紹介したいと思います
いくつかあるんですけどまず1個目はですねクールダウンですね
クールダウン何かというとプレートを頻繁にする組織の場合リノベートとかディペンダーボットみたいなものでですね
新しいそのパッケージとかライブラリが出てきたらそのバージョンアップをしますとって感じなんですけど
今だとパッケージが新しく出てからすぐ入れるのが良くないと言われてますこれはすぐ入れちゃうと誰かがもしくはあの
脆弱性をスキャンするスキャナーみたいなのがあるんですけどもそれが検知するのに時間がかかってしまったりすることがあるんですね
そうするとすぐ入れちゃうとそういう検査が終わる前に入れることになってしまうので良くないと
なので最近は1週間ぐらいですねクールダウン期間を設けて新しいライブラリが出たら1週間後に入れましょうみたいな
そういう対策が取られています ディペンダーボットとかリノベートとかそういう設定でクールダウン何日って
ウィンリリース何日みたいな設定する項目があったりします ただですねゼロデイ攻撃っていうものもありますのでこっちについては
セキュリティパッチですねそこについてはもうさっさと当てた方がいいというところでゼロデイに関してはすぐ当てる
みたいな積み分けされていることもあります 2つ目ですねシャアのピニングですねこれ何かというとライブラリを入れる場合とかですね
バージョン指定していることまあ普通あると思いますバージョン2.2を入れますとか バージョン3を入れます
でこれ参照先がどっかにもよるんですけれども多くの場合ですね バージョンで指定しているだけだと同じバージョンのものが裏側で別のものに差し
変わっていることがあります 例えばGitHubでバージョンタグみたいなものを設定しておいて
V3はこのコミットハッシュだよ指定できると思うんですけどもタグって消せちゃうんですよ 消した後に別のとこに同じ名前のタグを打つことが可能なんですね
そうすると利用者からすると常にV3っていうライブラリを参照してたはずなのに ある日突然そのV3の指先が変わっていて
悪いあるものをダウンロードしてしまうということがあります そのためですね最近はV3みたいな変わるかもしれないものじゃなくて
シャアハッシュコミットシャアとかその変更を1位に示すハッシュ関数によって生成された
すごい長い文字列があるんですけどもそれをですね 指定しようということになっています
ドッカーファイルでもUbuntu 24.02じゃなくてシャアみたいなやつですね これのことをシャアピーニングって呼んでいます
いろんなパッケージで使えると思いますので特にGitHub Actionsとかあるとシャアピーニングをエンフォースする設定とかもありますし
エンタープライズプランだけかも あとはビルドとかはサンドボックス環境でやっちゃおうね
結局パッケージのダウンロードしてそれを使って何かするっていうと問題が起きるわけですね
どういうパッケージなのか次第にもよりますけど 例えばインストールとか自体だけはサンドボックス環境でやってしまうみたいなのもありますね
例えばDevContainerみたいなユーザーの開発環境をコンテナで実現してあげるみたいな場合だとその環境自体をですね
作るのをどっかのクラウドサービス上でやってGitHub Actionsとかですかね そこでNPMのインストールとかそういうことをすることで
仮に問題あるパッケージをダウンロードしたとしても影響範囲を可能な限り小さくすることができます
もちろんですねインストールした後に実際に使った時に問題が起こるようなものについては防げないんですけども
一定ですね自分のローカル環境でパッケージを外からインストールしてくるみたいなことは防げるかなと思います
あとはパッケージダウンロードするときにプロキシを介するとかですね
ただのプロキシというよりかは脆弱性のスキャンが行われるプロキシですね
ちょうどAxiosの問題が起きているときには GMOの参加にあるFlat Securityという会社の方がですね
匠ガードという今だとPythonのPIPとJavaScriptのNPMのですね
レジストリを無料で公開してくれているみたいなツイートが結構盛り上がっていましたが
そのサービスを使うことによってNPMでダウンロードするパッケージとかPIPでダウンロードするパッケージを
そのFlat Security社のレジストリを経由してスキャンを押してくれる
問題があるかどうかチェックしてくれるみたいなこともできたりして
そういった感じですね
今から使おうとしてるやつが問題あるのかといったところの事前のチェックだったり
そもそも1週間ぐらいはダウンロードしないようにしようねとか
ダウンロードした問題があったとしてもできることがすごい限られているサンドボックス環境で作業するとか
そういった形で根本的な解決策ではないんですけれども
どうにかこのサプライチェーンアタック複雑な依存関係がある現代のアプリケーションにおいて
これをサプライチェーン攻撃を回避しようというようなことになっています
多層防御とその他の対策
もうね最近はインターネットに口開いてないから大丈夫でしょうみたいな世界観ではなくてですね
外部から自分がダウンロードしてきたファイルにもいろいろ入っていったり
そこから自分の環境の情報が外に出ていったりといったことが
まあまあよく聞く話になっていますので
ぜひですねサプライチェーンアタックについてはですね
実際に対策をしっかりとしていくってことが今後大事になるかなと思います
またですねセキュリティって基本的に考え方としては多層防御が大事なので
サプライチェーンアタックを仮に食らったとしてもそこからラテラルムーブメントとかを防ぐ
要するに他のことができないようにするっていうように
いろんなセキュリティの対策を講じていくことであったり
仮にそれが発生しまったときに何が起こったのかっていったことをきちんと覆えるような設定も必要です
できることを減らすって意味では仮に乗っ取られたとしてもその権限できることを最小化しておく
セキュリティの最小化の原則に乗っ取るってことですし
可視化の点で言えばこれは情報システム部とかの範疇になることが多いと思いますが
どういうところに通信をしてるんだみたいなネットワークのロゴを残すとか
意図しないところに対するアップロードとかをそもそも禁止してしまうみたいな
そういうネットワークレイヤー的な対策もあるかなと思います
あとは不正な通信というか振る舞いを検知するEDRみたいなものを入れるということもあるかなと思います
そんな感じで多層防御は前提になってくるんですけども
まずはサプライチェーンアタックの入り口というか
最初のところをいかに防ぐかというところを考えてやってみるというのが大事かなと思います
番組へのメッセージ募集
このポッドキャストはハッシュタグリアリティで皆様からの感想やコメント募集しております
またチャンネルの概要欄にありますGoogleフォームのリンクからもご投稿可能です
ありがとうございました
