Dockerコンテナをスキャンすると、いくつかの脆弱性が見つかりました

ドッカーハッキング

最近知られるようになった 介して ブログ投稿、 脆弱性を特定するためのテストツールの結果 パッチなしでセキュリティの問題を特定する 分離されたDockerコンテナイメージ内。

テストでは、4台のスキャナーのうち6台が 既知のDockerイメージ 重大な脆弱性がありました これにより、スキャナー自体を攻撃し、システム上でそのコードを実行できるようになりました。場合によっては(たとえば、Snykを使用して)root権限を使用します。

攻撃の場合、 攻撃者は自分のDockerfileのチェックを開始するだけで済みます またはmanifest.json。これには特別にフォーマットされたメタデータが含まれます。 または、Podfileファイルとgradlewファイルを画像内に配置します。

WhiteSource、Snyk、Fossa、anchoreシステムのエクスプロイトプロトタイプを準備することができます。

エルパケテ クレア、 もともと安全を念頭に置いて書かれた、 最高のセキュリティを示しました。

Trivyパッケージで問題は特定されていません その結果、Dockerコンテナスキャナーは分離された環境で実行するか、独自のイメージを検証するためにのみ使用する必要があり、そのようなツールを自動化された連続統合システムに接続する場合も注意が必要であると結論付けられました。

これらのスキャナーは、複雑でエラーが発生しやすい処理を実行します。 彼らは、ドッカーを扱ったり、レイヤー/ファイルを抽出したり、パッケージマネージャーとやり取りしたり、さまざまな形式を分析したりしています。 開発者のすべてのユースケースに対応しようとしている間、それらを守ることは非常に困難です。 さまざまなツールがどのようにそれを実行しようとし、管理するかを見てみましょう。

責任ある開示スコアは私の個人的な意見を反映しています。ソフトウェアベンダーは、報告されたセキュリティの問題を受け入れ、脆弱性について正直かつ透明であり、製品を使用する人々が確実に使用できるようにすることが重要だと思います。更新について決定を下すように適切に通知されます。 これには、更新にセキュリティ関連の変更があるという最も重要な情報が含まれ、CVEを開いて問題を追跡および伝達し、潜在的に顧客に通知します。 これは、製品がCVEに関するものであり、ソフトウェアの脆弱性に関する情報を提供している場合に想定するのが特に合理的だと思います。 また、迅速な対応、合理的な修正時間、攻撃を報告した人とのオープンなコミュニケーションに安心しています。

FOSSA、Snyk、WhiteSourceでは、脆弱性は関連していた 電話で 外部パッケージマネージャーへ 依存関係を判別し、gradlewファイルとPodfileファイルでtouchコマンドとsystemコマンドを指定することにより、コードの実行を整理できるようにします。

En SnykとWhiteSourceも、起動システムコマンドに関連する脆弱性を発見しました Dockerfileを解析した組織(たとえば、Dockefileを介したSnykでは、スキャナーによって引き起こされたユーティリティls(/ bin / ls)を置き換えることができ、WhiteSurceでは、「echo」の形式の引数を介してコードを置き換えることができます。 ; / tmp / hacked_whitesource_pip; = 1.0 '«をタップします。

Anchoreでは、脆弱性はskopeoユーティリティの使用によって引き起こされました Dockerイメージを操作します。 操作は、 '»os»:«$(touch hacked_anchore)»'の形式のパラメーターをmanifest.jsonファイルに追加するように削減されました。これらは、適切なエスケープなしでskopeoを呼び出すときに置き換えられます(文字«;&<のみが削除されました) > "、しかし、構成" $() ")。

同じ著者が脆弱性検出の有効性に関する調査を実施しました パッチが適用されていません セキュリティスキャナー経由 ドッカーコンテナの数と誤検知のレベル。

著者の他に これらのツールのいくつかは パッケージマネージャーを直接使用して依存関係を解決する。 これは彼らを守るのを特に難しくします。 一部の依存関係マネージャーには、シェルコードを含めることができる構成ファイルがあります。 

これらの単純な方法が何らかの形で処理されたとしても、これらのパッケージマネージャーを呼び出すことは、必然的にお金を払うことを意味します。 これは、控えめに言っても、アプリケーションの防御を容易にするものではありません。

脆弱性を含む73枚の画像のテスト結果 既知のほか、画像内の一般的なアプリケーション(nginx、tomcat、haproxy、gunicorn、redis、ruby、node)の存在を判断するための有効性の評価。 相談することができます 作成された出版物内 次のリンクで。


記事の内容は、次の原則に準拠しています。 編集倫理。 エラーを報告するには、 ここで.

コメントを最初に

コメントを残す

あなたのメールアドレスが公開されることはありません。

*

*

  1. データの責任者:MiguelÁngelGatón
  2. データの目的:SPAMの制御、コメント管理。
  3. 正当化:あなたの同意
  4. データの伝達:法的義務がある場合を除き、データが第三者に伝達されることはありません。
  5. データストレージ:Occentus Networks(EU)がホストするデータベース
  6. 権利:いつでも情報を制限、回復、削除できます。

bool(true)