1. JAVA 보안 취약점 사태는 무슨 일인가요?

먼저 Log4j는 Java, Kotlin, Scala 코딩 도중 프로그램의 로그를 기록하는 라이브러리로, 프로그램 작성 중 로그를 남기기 위해 사용되는 자바 기반의 오픈 소스 유틸리티입니다.

이번 Log4j 취약점은 JNDI(Java Naming and Directory Interface)와 LDAP(Lightweight Directory Access Protocol)에서 시작합니다. JNDI는 1990년대 후반부터 Java에 추가된 인터페이스로, Java 프로그램이 디렉터리를 통해 데이터를 찾을 수 있는 디렉터리 서비스입니다.

Java 프로그램들은 앞서 말씀드린 JNDI와 LDAP를 통해 Java 객체를 찾을 수 있습니다. 여기서 문제의 Log4j에 편하게 사용하기 위해 특정 문법을 통해 Java 객체를 볼 수 있게 됩니다. 이 문법들은 로그가 기록될 때도 사용이 가능하며, 결론적으로 해커들은 로그가 기록되는 곳을 찾아 취약점을 이용할 수 있게 되는 것이었습니다.

2.와탭은 이번 Log4j 취약점과 관련이 되어 있나요?

아닙니다. 관련이 없습니다. 와탭 모니터링 서비스는 Logging 모듈로 Logback 을 사용합니다.

물론 이런 일을 예상하고 Logback 을 사용한 것은 아니지만 대표적인 Java Logging Library 인 Log4j 와 Logback을 비교했을 때 저희 서비스에는 Logback을 이용하는 것이 Log4j를 이용하는 것보다 장점이 많았습니다.

따라서 Logback을 사용하는 와탭은 이번 Log4j 취약점 과 무관합니다.

와탭 표준 프레임워크는 SpringBoot 입니다. slf4j 구현체가 기본 로깅 모듈이라 logback을 별도로 log4j로 바꿀 일은 없을 예정입니다.

Logback을 사용하지만 혹여 Log4j가 사용된 사례는 없는지 이번 이슈를 계기로 면밀히 점검 해 보았습니다.

와탭 서비스를 사용하는 분들이라면 직접 확인도 가능합니다.
와탭 애플리케이션 모니터링에서 [애플리케이션] - [에이전트 설정] - [로딩된 클래스] 기능을 사용하면 JVM 시작 후 로딩된 모든 클래스 정보를 살펴 볼 수 있습니다.

위 그림과 같이 일부 log4j 클래스가 확인은 되었지만, 최종적으로는 SpringBoot 내부 의존성 때문에 포함되어 로딩된 것으로 확인 되었기에 문제를 유발 하지 않습니다.

라이브러리 자체가 포함된 것만으로 문제가 되지 않습니다. SpringBoot 나 타 라이브러리 의존성에 의해 log4j가 포함되는 경우가 있을 수 있는데 이 경우에도 log4j-core 만 포함되지 않는다면 문제 되지 않습니다.

취약점 세부 내역을 살펴보면 log4j-core-*.jar 에 포함된 org/apache/logging/log4j/core/lookup/JndiLookup.class 가 유발하는 것으로 설명되어 있으니 SpringBoot 에서는 기본 값인 Logback 을 명시적으로 Log4j 로 변경해서 사용한 경우만 아니라면 해당되지 않겠습니다.

와탭 이용자라면 [로딩된 클래스]에서 org.apache.logging.log4j.core.lookup.JndiLookup 를 검색하는 것이 가장 쉬운 확인 방법입니다.

3. 그렇다면 영향을 받는 범위가 궁금해요

영향을 받는 버전은 Apache Log4j2 2.0-beta9 ~ 2.14.1 사이의 버전을 사용하는 애플리케이션 입니다. 대표적인 애플리케이션들 목록은 아래 링크에서도 확인이 가능합니다.

4. 라이브러리 버전은 어떻게 확인해야 할까요?

와탭 이용자라면
[애플리케이션] → [에이전트 설정]에서 [라이브러리 버전] 기능에서 확인 할 수 있습니다. log4j-core를 검색 해 보세요

또 다른 방법으로는 애플리케이션의 pom.xml 또는 gradle.build 파일을 열어 log4j-core로 검색 해 볼 수도 있습니다.

5. 조치는 어떻게 하면 될까요?

가장 확실한 조치는 log4j 라이브러리를 2.15 이상으로 업데이트 하는 것입니다.

다만, 빠른 시간 내에 라이브러리를 업데이트 하고 재 검증하는 게 현실적으로 어려울 수 있는데요. 이 경우 다음과 같은 선제 조치를 할 수 있습니다.

JndiLookup 를 log4j-core 에서 제거 하는 방법

: 라이브러리 경로에서 아래 명령을 실행하면 JndiLookup.class 가 제거됩니다.

JVM 옵션으로 JndiLookup 기능을 제한 하는 방법

: -Dlog4j2.formatMsgNoLookups=true 옵션과 함께 애플리케이션을 실행합니다.

[결론]

와탭랩스는 SaaS 모니터링 국내 1위 기업으로 여러분들이 모니터링 서비스를 안심하고 이용할 수 있도록 만전을 다하고 있습니다. 와탭랩스 역시 Log4j 보안 취약 이슈를 접하며 사용자 여러분들과 고객사 여러분의 불안함을 없애기 위해 많은 고민을 하며 이 글을 올리게 되었습니다.

와탭랩스는 개발자와 서비스 운영자, 데브옵스 엔지니어들이 안정적으로 안전한 모니터링 서비스를 만들어 가는데 총력을 기울이겠습니다.

[추가: Logback 보안 취약점 공지 안내]

Logback 취약점의 경우 다음 세 가지 조건이 모두 충족되어야 발현합니다.

1. Logback 버전이 1.2.3~1.2.6인 경우

2. logback.xml 접근 및 쓰기 권한이 있어야 합니다.

3. 공격자가 변조한 설정 파일(logback.xml)이 시스템에 적용되어야 합니다.
(변조된 설정 파일 배치 후 시스템 재기동 or Scan="true"로 설정 필요)

와탭은 Logback 보안 취약점이 발견되었을 때 최신 버전 (1.2.9) 이상을 사용해 서비스 보안을 지키고 있습니다.

와탭이 내부 전수 조사를 통해 확인된 내용을 고객 여러분에게 공유 드립니다.

• 2021/12/20 이후 버전부터는 logback 1.2.9 버전 이상을 사용하고 있습니다.
• logback.xml 파일을 Jar 파일 내부에 위치하여 변경이 불가합니다.
• 와탭은 Executable Jar 기반으로 기동되는 구조입니다.
• 와탭의 logback 에서 사용하는 Appender 는 ConsoleAppender, RollingFileAppender 입니다.

와탭의 수집 서버는 RCE 취약점인 Log4Shell (CVE-2021-44228/CVE-2021-45046/CVE-2021-45105) 에 문제가 되지 않습니다. 보안 이슈와 관련하여 logback 1.2.9 버전 대응이 필요한 경우, 최신 WhaTap 수집 서버 버전의 적용을 검토 하실 수 있습니다.