Log4j 취약점, 즉 'Log4Shell'은 지금까지도 가장 치명적인 소프트웨어 결함 중 하나로 여겨지고 있습니다. Apache는 2021년 12월에 이 결함에 대한 패치를 적용했지만, 여전히 보안팀의 우려 사항으로 남아 있습니다. 실제로 이는 여전히 가장 많이 악용되는 보안 취약점 중 하나입니다.
Log4Shell은 영향을 미치는 Apache Log4j 2 소프트웨어 패키지가 세계에서 가장 널리 사용되는 로깅 라이브러리 중 하나이기 때문에 지속되고 있습니다. 미국 국토안보부에 따르면 Log4Shell의 모든 인스턴스를 찾아서 수정하는 데는 10년이 걸릴 것으로 예상됩니다.
그 동안 보안팀은 네트워크에서 Log4Shell 완화 및 수정 속도를 높이기 위해 몇 가지 조치를 취할 수 있습니다.
Log4Shell을 탐지하고 패치하는 방법을 살펴보기 전에 취약점의 특성을 이해하는 것이 중요합니다.
Log4j는 Apache 소프트웨어 재단에서 관리하는 오픈 소스 로거로, 프로그램의 정보와 이벤트를 기록합니다. Log4j는 독립 실행형 소프트웨어가 아니라 개발자가 자신의 Java 앱에 연결할 수 있는 코드 패키지입니다. Apache Log4j 프레임워크는 AWS(Amazon Web Services) 및 Cisco 솔루션과 같은 네트워크 인프라부터 Twitter 및 Minecraft와 같은 인기 앱에 이르기까지 웹에서 가장 큰 서비스 중 일부에서 사용됩니다.
Log4j의 일부 버전, 특히 Log4j 2.17.0 이하에는 심각한 취약점이 있습니다. 이 중 가장 위험한 것은 Log4j 버전 2.14.1 이하에서 발견된 원격 코드 실행(RCE) 제로데이 취약점인 Log4Shell(CVE-2021-44228, CVSS 등급: 10)입니다.
Log4Shell은 취약한 버전의 Log4j가 Java 앱이 외부 서버에 호스팅된 리소스에 액세스하는 데 사용하는 API인 JNDI(Java 네이밍 및 디렉토리 인터페이스)를 처리하는 방식 때문에 발생합니다. 위협 행위자는 Log4j를 통해 악성 JNDI 조회 명령을 전송하여 취약한 시스템을 거의 완벽하게 제어할 수 있습니다. 이러한 명령은 앱을 속여 데이터 탈취, 랜섬웨어 설치, 디바이스 오프라인 전환 등 거의 모든 작업을 수행할 수 있는 임의의 코드를 실행하도록 합니다.
일반적인 Log4Shell 사이버 공격은 다음과 같이 작동합니다.
Apache가 Log4Shell을 패치하기 위해 노력하는 동안 보안 연구원들은 Log4j의 일부 버전에서 몇 가지 관련 결함을 확인했습니다. 그 예는 다음과 같습니다.
네트워크에서 취약한 Log4j의 모든 인스턴스를 찾는 것은 어려울 수 있습니다. Log4j는 수백만 개의 앱에 사용되는 것으로 추정되는데, 이는 보안팀이 검사해야 할 자산이 많다는 것을 의미합니다.
또한 Log4j는 종종 간접적인 종속성으로 존재합니다. 즉, 자산의 소스 코드에 직접 포함되어 있지는 않지만 자산이 의존하는 소프트웨어 패키지 또는 통합으로 나타납니다. Google은 취약한 Log4j 인스턴스 대부분이 종속성 체인의 깊이가 한 수준 이상이고 일부는 9단계에 달한다고 보고했습니다.
즉, 보안팀은 적절한 전술과 도구를 사용하면 Log4j 취약점을 탐지할 수 있습니다.
2.0-beta9부터 2.17까지 모든 버전의 Log4j 2는 Log4Shell 또는 관련 결함에 취약합니다. 다시 말해, 보안팀은 2.17.1 이전 버전의 Log4j를 찾아서 해결해야 합니다.
Log4Shell 및 관련 결함은 Log4j의 핵심 기능을 제공하는 'Log4j-core' 파일에만 존재합니다. 이 결함은 앱과 Log4j 로거 간의 인터페이스를 제어하는 'Log4j-api' 파일에는 존재하지 않습니다.
Log4j는 회사가 관리하는 자산, 회사가 사용하는 타사 자산(예: 클라우드 서비스), 회사 네트워크에 액세스할 수 있는 서비스 공급자가 사용하는 자산에 나타날 수 있습니다. Log4j는 Java 기반 앱에 나타날 가능성이 가장 높지만 종속성 및 통합을 통해 Java가 아닌 앱에도 나타날 수 있습니다.
Java 앱 내에서 Log4j와 같은 라이브러리는 Java 아카이브 파일 또는 'JAR 파일'로 패키징되는 경우가 많습니다. JAR 파일에는 다른 JAR 파일이 포함될 수 있으며, 이 파일에는 자체 JAR 파일 등이 포함될 수 있습니다. Log4j의 모든 취약한 버전을 찾으려면 보안팀은 최상위 파일뿐만 아니라 모든 수준의 JAR 파일을 검사해야 합니다.
전문가들은 Log4j 취약점을 찾기 위해 여러 가지 기술을 결합해 사용할 것을 권장합니다.
수동 검색. 보안팀은 Log4j 결함을 수동으로 검색할 수 있습니다. Apache Maven과 같은 개발 도구를 사용하여 앱의 모든 종속성을 매핑하는 종속성 트리를 생성하거나 외부 위협 인텔리전스를 사용하여 영향을 받는 자산을 식별할 수 있습니다. 예를 들어, 사이버 보안 및 인프라 보안국(CISA)은 Log4Shell로 고통받는 것으로 알려진 소프트웨어 목록을 작성했습니다. 목록은 GitHub에서 사용할 수 있습니다.
Linux, Microsoft Windows, macOS 운영 체제에서 보안팀은 명령줄 인터페이스를 사용하여 파일 디렉터리에서 Log4j의 인스턴스를 검색할 수 있습니다.
취약점 스캔 도구. Log4Shell이 발견된 후 일부 조직에서는 Log4j 취약점을 찾기 위한 무료 도구를 출시했습니다. 그 예로는 Palantir의 Log4j-sniffer와 CERT Coordination Center의 스캐너 등이 있습니다.
특수 스캐너는 여전히 사용 가능하지만 취약성 스캐너, 공격 표면 관리(ASM) 플랫폼, 엔드포인트 탐지 및 대응(EDR) 솔루션과 같은 많은 표준 보안 솔루션이 이제 Log4j 취약성을 탐지할 수 있습니다.
Log4Shell은 종속성 체인 깊숙이 숨어 있을 수 있으므로 보안팀은 침투 테스트와 같은 보다 실질적인 방법으로 자동화된 검사를 보완할 수 있습니다.
위협 헌팅. CISA에 따르면 공격자들은 Log4Shell을 사용하여 네트워크에 침입한 후 감염된 자산에 패치를 적용하여 흔적을 은폐하는 것으로 알려져 있습니다. 따라서 보안팀은 이미 침해가 발생했다고 가정하고 Log4Shell 악용의 징후를 적극적으로 찾아내는 것이 좋습니다.
보안 정보 및 이벤트 관리(SIEM) 솔루션 및 확장 탐지 및 대응(XDR) 플랫폼과 같은 사이버 보안 도구는 이상한 로그 항목이나 의심스러운 트래픽 패턴과 같은 Log4Shell과 관련된 비정상적인 활동을 탐지하는 데 도움이 될 수 있습니다. 보안팀은 공격의 결과가 얼마나 심각할 수 있는지 고려할 때 Log4Shell에 대한 모든 가능한 힌트에 대해 완전한 사고 대응 및 조사 절차를 시작해야 합니다.
보안팀은 Log4j 취약점을 해결할 때 몇 가지 옵션을 사용할 수 있습니다.
Log4Shell 및 관련 결함을 완전히 해결하려면 조직은 네트워크의 모든 Log4j 인스턴스를 최신 버전(또는 버전 2.17.1 이상)으로 업데이트해야 합니다. 최신 버전의 Log4j는 공격자가 악용할 수 있는 기능을 제거하고 LDAP와 같이 일반적으로 남용되는 프로토콜에 대한 지원을 제거합니다.
시스템 전체에 적용할 수 있는 단일 패치는 없으며 Java 자체를 업데이트해도 문제가 해결되지 않습니다. 보안팀은 영향을 받는 모든 자산에서 Log4j의 모든 인스턴스를 업데이트해야 합니다.
보안 연구원들은 패치가 이상적인 솔루션이라는 데 동의합니다. 패치가 불가능한 경우 조직은 다른 완화 단계를 사용하여 공격 가능성을 최소화할 수 있습니다.
취약한 앱에서 메시지 조회를 허용하지 않습니다. 공격자는 '메시지 조회 대체'라는 Log4j의 기능을 사용하여 취약한 앱에 악성 명령을 보냅니다. 보안팀은 'Log4j2.formatMsgNoLookups'를 변경하여 이 기능을 수동으로 허용하지 않을 수 있습니다. 시스템 속성을 'true"로 설정하거나 'LOG4J_FORMAT_MSG_NO_LOOKUPS' 환경 변수의 값을 'true'로 설정합니다.
메시지 조회 대체 기능을 제거하면 공격자가 공격하기는 더 어려워지지만, 완벽한 방법은 아닙니다. 악의적인 공격자는 여전히 CVE-2021-45046을 사용하여 기본 설정이 아닌 앱에 악성 JNDI 조회를 전송할 수 있습니다.
취약한 앱에서 JNDIlookup 클래스 제거Log4j에서 JNDIlookup 클래스는 로거가 JNDI 조회를 처리하는 방법을 제어합니다. 이 클래스가 Log4j의 클래스 디렉토리에서 제거되면 JNDI 조회를 더 이상 수행할 수 없습니다.
Apache는 다음 명령을 사용하여 취약한 앱에서 JNDIlookup 클래스를 제거할 수 있다고 말합니다.
zip -q -d Log4j-core-*.jar org/apache/logging/Log4j/core/lookup/JndiLookup.class
이 방법은 메시지 조회를 허용하지 않는 것보다 효과적이지만, 공격자가 재귀 조회를 통해 서비스 거부 공격을 유발하는 등 다른 악용 시도를 막지는 못합니다.
잠재적인 Log4Shell 공격 트래픽을 차단합니다. 보안팀은 웹 애플리케이션 방화벽(WAF), 침입 탐지 및 방지 시스템(IDPS), EDR 및 기타 사이버 보안 도구를 사용하여 LDAP 또는 RMI와 같이 일반적으로 사용되는 프로토콜을 차단함으로써 공격자가 제어하는 서버와의 트래픽을 가로채는 데 사용할 수 있습니다. 또한 보안팀은 공격과 관련된 IP 주소 또는 공격자가 악성 요청에 일반적으로 사용하는 문자열(예: 'jndi', 'ldap', 'rmi')을 차단할 수 있습니다.
그러나 공격자는 새로운 프로토콜과 IP 주소를 사용하거나 악성 문자열을 난독화하여 이러한 방어를 우회할 수 있습니다.
영향을 받은 자산을 격리합니다. 다른 모든 방법이 실패하면 보안팀은 패치를 기다리는 동안 영향을 받는 자산을 격리할 수 있습니다. 이를 수행하는 한 가지 방법은 인터넷에서 직접 액세스할 수 없는 격리된 네트워크 세그먼트에 취약한 자산을 배치하는 것입니다. 추가 보호를 위해 이 네트워크 세그먼트 주위에 WAF를 배치할 수 있습니다.
Log4Shell 수정의 까다로운 점 중 하나는 항상 패치가 유지되는 것은 아니라는 것입니다. 2022년 11월, Tenable은 Log4Shell에 여전히 취약한 자산의 29%가 '재발'로, 패치를 적용했지만 결함이 다시 발생했다고 보고했습니다. 반복은 개발자가 실수로 패치되지 않은 Log4j 버전이 포함된 소프트웨어 라이브러리를 사용하여 앱을 빌드하거나 업데이트할 때 발생합니다.
개발자는 사용하는 프레임워크를 더 면밀히 조사할 수 있지만, 취약한 버전의 Log4j가 JAR 파일에서 몇 단계 깊숙이 있는 경우 이를 놓치기 쉽습니다.
공식적인 취약점 관리 및 패치 관리 프로그램을 구현하면 보안팀이 자산을 모니터링하여 Log4j 취약점의 재발을 방지할 수 있는 보다 효과적인 방법을 제공할 수 있습니다. 정기적인 취약점 스캔 및 모의 침투 테스트를 통해 Log4Shell 등 새로운 취약점을 신속하게 발견할 수 있습니다. 패치 관리를 통해 공급업체가 수정 사항을 릴리스하는 즉시 새로운 취약점을 차단할 수 있습니다.