2021년 Log4Shell 취약성은 재고의 석탄

저자: Steve Povolny 및 Douglas McKee · 2022년 1월 19일

개요

12월 9일, Apache Log4j 로깅 라이브러리에 대해 GitHub의 PoC와 함께 취약성(CVE-2021-44228)이 Twitter에 공개되었습니다. 원래 Alibaba Cloud Security Team의 Chen Zhaojun이 11월 24일 Apache에 이 버그를 공개했습니다.

이 취약성의 영향은 Log4j 라이브러리를 해당 애플리케이션에 통합한 모든 제품(Apple iCloud, Steam, Samsung Cloud 스토리지와 같은 인터넷 대기업의 제품과 수천 개의 추가 제품 및 서비스 포함)에 미치는 영향으로 인해 잠재력이 매우 큽니다. Java는 거의 모든 산업 부문의 애플리케이션에서 많이 사용되기 때문에 이것은 시작에 불과하지만, 이러한 좀 더 현대적이고 널리 퍼진 위협으로부터 복원력과 보호 기능을 구축하기 위해 사전 예방적 보호와 같이 기업이 사용할 수 있는 예방법과 전략이 있습니다.

이게 뭐죠?

취약성은 JNDI(Java Naming and Directory Interface) 기능이 변수를 해결하는 방식으로 인해 존재합니다. JNDI 참조가 로그에 기록되면 JNDI는 변수를 해결하기 위해 모든 요구 사항을 가져옵니다. 이 프로세스를 완료하기 위해 JNDI는 필요한 모든 원격 클래스를 다운로드하고 실행합니다. 취약성에 대한 기본 요구 사항은 공격자가 제어하는 입력 필드 및 이 입력이 로그로 전달되는 것이기 때문에 서버 측 애플리케이션과 클라이언트 측 애플리케이션에 모두 적용됩니다.

이 공격을 조정하기 위해 공격자는 서로 다른 여러 JNDI 조회를 사용할 수 있습니다. 현재 PoC와 활성 악용 모두에서 볼 수 있는 가장 인기 있는 조회는 LDAP를 활용하는 것입니다. 그러나 RMI 및 DNS와 같은 다른 조회도 실행 가능한 공격 벡터입니다. 단순한 LDAP/RMI 공격 벡터는 이전 JDK 버전에서만 작동한다는 점을 주목해야 합니다. 공격에 복잡성이 추가되지만 코드 실행을 구현하기 위해 이러한 제약 조건을 우회하는 방법을 시연한 게시물이 있습니다.

Java 개체 역직렬화 취약성은 새로운 종류의 취약성 또는 공격이 아닙니다. "marshalsec" 같은 이전의 공격적인 연구를 이 취약성에 적용하여 코드 실행을 단순화할 수 있습니다.

진화하는 방법 + 헌재의 상황

• 12월 14일, Log4j 버전 1.2는 JMSAppender 구성 요소를 통한 유사 공격에 취약한 것으로 확인되어 CVE-2021-4104를 발급받았습니다. 이것은 2.0-alpha1 ~ 2.16.0 버전만큼 악용이 용이하지 않다는 점에 유의하는 것이 중요합니다. 악용이 발생하려면 JMSAppender를 활성화해야 하며, JMSAppender가 JNDI 요청을 수행할 수 있도록 TopicBindingName 또는 TopicConnectionFactoryBindingName 구성으로 설정해야 합니다. 이는 기본 구성이 아닙니다.

이 확인 이후 Apache는 Log4j의 새 버전인 2.16.0을 릴리스했습니다. 이 업데이트는 기본적으로 JDNI를 비활성화했습니다. 따라서 사용자는 JNDI 기능을 명시적으로 켜고 메시지 조회에 대한 지원을 완전히 제거해야 합니다.

• 그런 다음 12월 18일, Log4j 버전 2.0-alpha1 ~ 2.16.0에 영향을 미치는 새로운 서비스 거부(DoS) 취약성인 CVE-2021-45105가 검색되었습니다. 원래의 Log4j 취약성을 완화하기 위해 Apache는 버전 2.16.0에서 JNDI 조회를 완전히 비활성화했지만 기본이 아닌 구성에서는 자체 참조 조회가 여전히 가능했습니다. 중첩 변수가 StrSubstitutor 클래스로 대체되면 이 클래스는 재귀적으로 substitute() 클래스를 호출합니다. 이 중첩 변수가 교체되는 변수를 재귀적으로 참조하면 서버에서 무한 재귀 및 DoS 조건이 발생합니다. 현재 연구에 따르면 이것이 이전 취약성처럼 코드 실행으로 이어지지는 않습니다.

여기에서 Apache는 최신 DoS 취약성을 해결하기 위해 Log4j의 새 버전 2.17.0을 릴리스했습니다. 사용자 입력을 포함할 수 있는 구문 분석 문자열을 관리하기 위해 StrSubstitutor에서 두 개의 추가 클래스가 생성되었습니다. 이러한 추가는 재귀 평가를 허용하지 않습니다. DoS로 이어지는 이 취약성의 악용으로 인해, 이것은 원격 코드 실행으로 이어질 수 있는 이전에 보고된 Log4j 취약성보다 덜 중요한 것으로 간주됩니다.

악용이 성공하려면 몇 가지 비표준 조건이 충족되어야 한다는 점에 유의하는 것이 중요합니다. Log4j 상황이 계속 진화하고 있으므로 가능한 경우 버전 2.17.1로 업그레이드하는 것이 좋습니다. 또한 시간을 내어 새해를 맞이하여 전반적인 보안 전략과 관행을 검토하는 것이 좋습니다.

앞으로의 긍정적인 전망

인간과 기계가 상시 가동 방식으로 함께 학습하고 적응하면서 이 취약성을 완화하는 다양한 방법에 대한 많은 정보가 있습니다. 위협이 더욱 역동적으로 변화함에 따라 비즈니스 운영을 최적화하고 보호하기 위한 전략과 프로세스도 필요합니다. Log4j에서 제시하는 실행 가능한 기회를 통해 기업은 위협을 피할 수 없는 유해한 것이라는 사고방식에서 벗어나 성장, 학습, 적응의 기회로 삼으며 복원력을 구축하고 비즈니스 장점을 살려 나갈 수 있습니다.

Log4j처럼 빠르게 진화하는 위협에 보조를 맞추는 살아 있는 엔터티가 되는 것이 보안에 얼마나 중요한지를 잘 알고 있기 때문에 당사는 이 취약성이 알려지기 시작한 이후 면밀히 추적해 왔습니다. 당사의 초기 목표는 재생산하고 확인한 공개 POC를 사용하여 악용될 가능성을 판단하는 것이었습니다. 이 작업은 공개 Docker 컨테이너와 LDAP 및 RMI를 모두 활용하는 클라이언트/서버 아키텍처, 그리고 marshalsec을 사용하여 Log4j 버전 2.14.1을 악용하는 방식으로 수행되었습니다.

앞으로 DNS와 같은 추가 서비스를 사용하여 제공되는 익스플로잇의 변형을 테스트할 계획입니다. 그동안 당사는 NSP(Network Security Platform)를 활용하는 고객을 위해 네트워크 시그니처 KB95088을 릴리스했습니다. 이 시그니처는 LDAP를 통해 CVE-2021-44228을 악용하려는 시도를 탐지합니다. 이 시그니처는 다른 프로토콜이나 서비스를 포함하도록 확장될 수 있으며, 적용 범위를 보완하기 위해 추가 시그니처가 릴리스될 수 있습니다.

추가 리소스를 찾고 계신가요?

이 취약성에 대한 전체 내용은 여기의 보안 게시판에서 추적할 수 있으며 더 많은 PoC 및 도구 목록을 여기에서 찾을 수 있습니다.

• https://github.com/pedrohavay/exploit-CVE-2021-44228
• https://github.com/christophetd/log4shell-vulnerable-app
• https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
• https://www.greynoise.io/viz/query/?gnql=tags%3A%22Apache%20Log4j%20RCE%20Attempt%22
• https://rules.emergingthreatspro.com/open/
• https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes
• https://github.com/corretto/hotpatch-for-apache-log4j2
• https://github.com/nccgroup/log4j-jndi-be-gone