Log4j 脆弱性 - 概念実証

このリポジトリには、log4j の脆弱性を再現するために必要な docker と k8s の YAML が含まれています（下記参照）。

すべてがどのように関連しているかを理解するには、このブログを参照してください。

Docker イメージのビルド

docker イメージをカスタマイズする必要がある場合

  cd <Git-Repo>/web-server
  make build push

  cd <Git-Repo>/marshalsec
  make build push

  cd <Git-Repo>/attack-server
  make build push

プッシュする前に、DockerHub が自分のユーザー ID を反映するように更新してください。

POC では、docker イメージをカスタマイズする必要はありません。

Kubernetes へのデプロイ

k8s フォルダ配下の YAML は、任意の Kubernetes クラスタにデプロイできます。

  cd <Git-Repo>/k8s
  kubectl create -f .

これにより、クラスタ上に 3 つの POD がデプロイされます。各 POD は「アクター」を表し、log4j の脆弱性がどのように機能するのかを私たちが理解できるように、それぞれの役割を果たします。

ここに含まれる YAML に加えて、パブリックなエンドポイントから脆弱な Web アプリをテストできるように、Kubernetes クラスタに Ingress をデプロイする必要があります。

以下は、Ngnix-Ingress で動作するサンプルです。

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: log4j-ingress
  labels:
    app: log4j
    env: dev
  namespace: log4j
  annotations:
    nginx.ingress.kubernetes.io/affinity: "cookie"
    nginx.ingress.kubernetes.io/session-cookie-name: "route"
    nginx.ingress.kubernetes.io/session-cookie-expires: "172800"
    nginx.ingress.kubernetes.io/session-cookie-max-age: "172800"
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
    nginx.ingress.kubernetes.io/force-ssl-redirect: "false"
    #nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  tls:
  - hosts:
    - <YOUR-DOMAIN-NAME-HERE>
    #secretName: tls-java-secret
  rules:
  - host: <YOUR-DOMAIN-NAME-HERE>
    http:
      paths:
        - path: /
          backend:
            serviceName: log4j-webserver
            servicePort: 8080

著者

@ankur-katiyar

リソース

CVE-2021-44228

ライセンス

GNU General Public License v3.0

log4j-docker

人気