ブログ

Falcoを使用してCVE-2020-8555を検出する

Google Cloudとコンテナの継続的なセキュリティ

本文の内容は、2020年5月29日にKaizhe Huangが投稿したブログ(https://sysdig.com/blog/cve-2020-8555-falco/)を元に日本語に翻訳・再構成した内容となっております。

このCVEは、kube-controller-managerのServer Side Request Forgery(SSRF)の脆弱性であり、特定の許可されたユーザーがマスターのホストネットワーク内の保護されていないエンドポイント(リンクローカルサービスやループバックサービスなど)から最大500バイトの任意の情報を漏洩できるようにします。

特定の組み込みボリュームタイプ(GlusterFS、Quobyte、StorageFS、ScaleIO)でポッドを作成する権限またはStorageClassを作成する権限を持つ攻撃者が、マスターのホストネットワークからのリクエスト本文なしでkube-controller-managerにGETまたはPOSTリクエストを送信させることができます。

Severity:Medium

影響を受けるKubernetesバージョン

  • kube-controller-manager v1.18.0
  • kube-controller-manager v1.17.0 - v1.17.4
  • kube-controller-manager v1.16.0 - v1.16.8
  • kube-controller-manager <v1.15.11

Falcoを使用したCVE-2020-8555の検出

この脆弱性の悪用の試みを検出することは重要です。

Falcoは、コンテナとKuberenetesのランタイム脅威検出のためのCNCFオープンソースプロジェクトです。Falcoを使用して、ホストレベルとコンテナレベルの両方で悪意のあるアクティビティを検出できます。Falcoは、カスタマイズ可能な一連のルールによって定義される異常な振る舞いを検出すると、セキュリティイベントを生成します。

Falcoの利点の1つは、その強力で柔軟なルール言語を活用することです。この種の動作をフィルタリングするルールをすばやく簡単に作成して、誰かがCVE 2020-8555を悪用しようとしていることを検出できるようにする方法を見てみましょう。

これらの脆弱性は、GlusterFS、Quobyte、StorageFS、ScaleIOのストレージボリュームタイプを使用した場合にトリガーされる可能性があります。StorageClassオブジェクトがボリュームタイプの1つで作成されたか、ボリュームタイプの1つを使用してポッドが作成されたかを検出できます。

作成されたStorageClassオブジェクトを検出する

- list: affected_storage_provisioners
  items:
  - "kubernetes.io/scaleio"
  - "kubernetes.io/quobyte"
  - "kubernetes.io/glusterfs"
  - "kubernetes.io/storagefs"
- macro: affected_storageclasses
  condition: (jevt.value[/requestObject/provisioner] in (affected_storage_provisioners))
  append: false
- macro: storageclass
  condition: ka.target.resource=storageclasses
# Detect CVE-2020-8555
- rule: Vulnerable StorageClass Object Created
  desc: Detect a vulnerable StorageClass object is created
  condition: kevt and storageclass and kcreate and affected_storageclasses and\
    \response_successful
  output: "Vulnerable storage class is created successfully (user=%ka.user.name provisioner=%jevt.value[/requestObject/provisioner]\
    \ objectName=%ka.target.name)"
  priority: "WARNING"
  tags: [k8s]
  source: "k8s_audit"

出力は次のようになります。

successfully (user=admin provisioner=kubernetes.io/scaleio objectName=sio-small)

脆弱なボリュームタイプが作成されたポッドを検出する

- macro: affected_volumes_in_pod
  condition: jevt.value[/requestObject/spec/volumes] contains "scaleIO" or jevt.value[/requestObject/spec/volumes] contains "glusterFS" or jevt.value[/requestObject/spec/volumes] contains "quobyte" or jevt.value[/requestObject/spec/volumes] contains "storageFS"
# Detect CVE-2020-8555
- rule: Create Pod with Vulnerable Volume Type
  desc: Detect an attempt to start a pod with a vulnerable volume type.
  condition: kevt and pod and kcreate and response_successful and affected_volumes_in_pod
  output: "Pod started with vulnerable volume mount (user=%ka.user.name pod=%ka.resp.name ns=%ka.target.namespace images=%ka.req.pod.containers.image volumes=%ka.req.pod.volumes.volume_type)"
  priority: "WARNING"
  tags: [k8s]
  source: "k8s_audit"

出力は次のようになります。

Pod started with vulnerable volume mount (user=admin pod=pod-0 ns=default images=k8s.gcr.io/test-webserver volumes=(scaleIO,hostPath))

まとめ

アップグレードする前に、マスターでエンドポイント保護を追加するか、脆弱なボリュームタイプの使用を制限し、RBACを介してStorageClass書き込み権限を制限することで、この脆弱性を軽減できます。脆弱なボリュームタイプが使用されるのを防ぐことに加えて、脆弱なボリュームタイプで作成されたポッドまたはStorageClassオブジェクトを検出または監視することも重要です。脆弱性の緩和に役立つ詳細については、FalcoSysdig Secureを確認してください。

Sysdigに関するお問い合わせはこちらから

最近の投稿

カテゴリー

アーカイブ

ご質問・お問い合わせはこちら

top