아파치 log4j 취약점 확인 및 조치하기 (CVE-2021-44228)

log4j 취약점에 대해

제로데이 어택으로 구분될만큼 심각한 보안문제로 log4j CVE-2021-44228가 보고 되었다.

이와 관련한 내용을 정리해 본다.

 

제로데이 어택

앞서 말한 제로데이 어택이란 무엇일까?

어떤 보안상 문제가 발견되고, 그 문제가 미처 공표되기도 전에 해당 문제점을 목표로 행해지는 위협/공격을 말한다.

취약점이 발견되고, 아직 패치 등이 적용되기 전에 이뤄지는 공격이므로 마땅한 대처 방안이 없고, 피해 규모도 가늠할 수 없는 상태를 말한다.

즉, 빨리 해결책이 나올 때까지 기다리고, 그 패치를 적용하는 것 외에는 뾰족한 방법이 없다.

 

 

 

 

 

 

log4j란?

log4j는 자바 애플리케이션에 로그를 쉽게 기록할 수 있도록 도와주는 라이브러리 구현체 중 하나이다.

공식사이트)
https://logging.apache.org/log4j/2.x/

사실, 수 많은 애플리케이션에서는 sl4fj (Simple Logging Facade for Java)라는 인터페이스를 보통 참조하고, 그 인터페이스에 맞춰 로그를 기록한다.

그리고, slf4j의 구현체로 log4j, logback, java.util.logging 등을 사용할 수 있다.

즉, slf4j의 인터페이스에 맞춰 로그를 남길 수 있도록 되어 있다면, 로그 구현체를 다른 것으로 나중에 쉽게 바꿀 수 있다는 뜻이다.

 

이번에 밝혀진 아파치 log4j 취약점

수많은 자바 애플리케이션이 Spring으로 작성되어 있다면, 특히 최신 Spring Boot로 작성을 했다면 아마 slf4j의 구현체로 logback을 사용하고 있을 가능성이 높다.

그러나, 모든 자바 애플리케이션이 Spring 기반 애플리케이션은 아니며, 모든 Spring 기반 애플리케이션 또한 최신 Spring Boot 기반은 아니다.

이번에 밝혀진 log4j의 취약점은 제목에도 소개했듯이, RCE(Remote Code Execution)이라는 이름이 붙어있다.

수많은 네트워크 프로그램들이 로컬에서 실행되는 것이 아니라, 서버와 통신하면서 데이터를 주고 받는 세상이라면 원격 실행은 당연한 게 아니겠냐 생각할 수도 있겠다.

문제는, 의도하지 않은 제 3자가 악의적인 코드를 원격으로 실행할 수 있도록 취약점이 존재한다는 것이다.

그리고, 그 대상 프로그램은 특정 프로그램으로 국한되는 것이 아니라 log4j 라이브러리를 쓰는 시스템들에 모두 적용된다는 점이 더 심각한 점이다.

해당 취약점은 마인크래프트 게임을 통해 최초로 확인되었으며, 이후 알리바바 클라우드 보안팀에서 해당 문제를 공식 재현 증명하였다.

이후 아파치 log4j에서도 위와 같이 해당 문제를 기술하였다.

마인크래프트 개발팀에서도 해당 문제를 재현하여 POC를 아래와 같이 진행하였다.

https://github.com/HyCraftHD/Log4J-RCE-Proof-Of-Concept

해당 문제는 아파치 log4j 버전 2.14.1 이하 버전에서 발견된다. (단, 2.12.2 제외)

반응형

 

문제 확인 방법

내가 사용중인 log4j 버전 확인은 어떻게 할 수 있을까?

스프링 애플리케이션을 사용하는 사람들이라면, 본인이 관리하는 pom.xml 혹은 build.gralde 파일을 우선 참고하는 것으로 시작할 수 있다.

그러나, 여러 라이브러리가 순환 참조를 거쳐서 인용되고 있을 수도 있고, pom.xml 및 build.gralde 파일에 모든 정보가 있는 것은 아닐 수도 있다.

따라서, 누군가 작성해 놓은 scanner 프로그램 같은 것을 쓰는 것이 더 편리할 것이다.

• 자바 버전 스캐너
  https://github.com/logpresso/CVE-2021-44228-Scanner
• 파이썬 버전 스캐너
  https://github.com/CERTCC/CVE-2021-44228_scanner

 

문제 해결 방법

위와 같이 검사를 해서, 만약 문제가 되는 버전의 log4j를 사용하고 있는 것으로 판정했다면 조치를 아래와 같이 해주자.

 

log4j 최신 버전으로 업데이트

가장 권고되는 방법이다.

• log4j 업데이트: log4j 최신버전 (2.16.0 이상)

pom.xml 및 build.gradle에 해당 라이브러리의 버전을 2.16.0 (작성시점 기준)으로 변경하여 재배포하자.

 

property 설정

라이브러리 업데이트가 불가능하다면, 아래와 같이 property 설정을 추가하는 방법도 우선적으로 적용해야 한다.

자바 애플리케이션의 JVM 파라미터로

-Dlog4j2.formatMsgNoLookups=true

와 같이 지정하거나, 애플리케이션이 실행되는 서버나 컨테이너 상의 환경 변수를 아래와 같이 설정하는 방법도 가능하다.

LOG4J_FORMAT_MSG_NO_LOOKUPS=true

 

 

 

 

 

 

 

JndiLookup 클래스 직접 삭제하기 (비추)

몇몇 사이트에서는 아래와 같이 해당 JndiLookup.class를 직접 삭제하는 방안도 소개하는데, 개인적으로 이 방안은 그다지 추천하지 않는다.

zip -q -d log4-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

만약, 문제가 있는 버전의 jar 파일을 다시 다운로드 받게 된다면 조치한 내용이 다시 원복되어 버려 다시 문제에 노출될 가능성이 있다.

 

참고

https://blog.cloudflare.com/ko-kr/inside-the-log4j2-vulnerability-cve-2021-44228-ko-kr/

 

더 보기

아파치 Log4J 보안 취약점 (CVE-2021-45105) 조치 방법