Log4j 취약점 또는 “Log4Shell,”는 지금까지 가장 치명적인 소프트웨어 결함 중 하나로 간주됩니다. Apache는 2021년 XNUMX월에 이 결함을 패치했지만 여전히 보안 팀의 우려 사항입니다. 사실 아직도 그 중엔 가장 많이 악용되는 보안 취약점.

Log4Shell은 영향을 받는 Apache Log4j 2 소프트웨어 패키지가 세계에서 가장 널리 사용되는 로깅 라이브러리 중 하나이기 때문에 지속됩니다. Log4Shell의 모든 인스턴스를 찾아서 수정하는 데는 XNUMX년이 걸릴 것으로 예상됩니다. 미국 국토 안보부.

그 동안 보안 팀은 네트워크에서 Log4Shell 완화 및 교정 속도를 높이기 위해 몇 가지 조치를 취할 수 있습니다. 

Log4j 취약점 이해  

Log4Shell을 감지하고 패치하는 방법을 알아보기 전에 취약점의 특성을 이해하는 것이 중요합니다.

로그4j 프로그램의 정보와 이벤트를 기록하는 오픈 소스 로거(Apache Software Foundation에서 유지 관리)입니다. Log4j는 독립형 소프트웨어가 아니라 개발자가 자신의 Java 앱에 연결할 수 있는 코드 패키지입니다. Apache Log4j 프레임워크는 Amazon Web Services(AWS) 및 Cisco 솔루션과 같은 네트워크 인프라부터 Twitter 및 Minecraft와 같은 인기 앱에 이르기까지 웹에서 가장 큰 일부 서비스에 사용됩니다.

Log4j의 일부 버전, 특히 Log4j 2.17.0 이하 버전에는 심각한 취약점이 있습니다. 그 중 가장 위험한 것은 Log4Shell (CVE-2021-44228; CVSS 등급: 10), 원격 코드 실행(RCE) 제로 데이 취약점 Log4j 버전 2.14.1 및 이전 버전에서 발견되었습니다. 

Log4Shell은 취약한 Log4j 버전이 JNDI(Java Naming and Directory Interface)를 처리하는 방식의 결과입니다. API Java 앱이 외부 서버에서 호스팅되는 리소스에 액세스하는 데 사용합니다. 위협 행위자는 Log4j를 통해 악의적인 JNDI 조회 명령을 전송하여 취약한 시스템을 거의 완전히 제어할 수 있습니다. 다음 명령은 거의 모든 작업을 수행할 수 있는 임의의 코드를 실행하도록 앱을 속입니다. 데이터를 훔치다설치 랜섬, 장치를 오프라인 상태로 만드는 등의 작업을 수행할 수 있습니다.

Log4Shell 공격

일반적인 Log4Shell 사이버 공격 다음과 같이 작동합니다. 

1. 해커는 LDAP(Lightweight Directory Access Protocol) 또는 DNS(Domain Name System)와 같은 일반 프로토콜을 사용하여 서버를 설정합니다. 
2. 해커는 서버에 악성 코드나 기타 악성 페이로드를 저장합니다.
3. 해커는 Log4j를 실행하는 앱에 JNDI 조회를 보내 앱을 해커의 서버로 연결합니다. 
4. JNDI 조회를 통해 앱이 해커의 서버에 연결되고, 악성 페이로드를 다운로드하고, 악성 코드를 실행하게 됩니다. 

관련 Log4j 취약점 및 악용 방법

Apache가 Log4Shell을 패치하기 위해 작업하는 동안 보안 연구원들은 Log4j의 일부 버전에서 몇 가지 관련 결함을 식별했습니다. 여기에는 다음이 포함됩니다. 

• CVE-2021-45046 해커가 기본이 아닌 특정 설정을 사용하는 시스템에 악의적인 JNDI 조회를 보낼 수 있습니다. 해당 시스템에 Log4Shell이 ​​수정되었더라도 마찬가지입니다. Log4j 버전 2.15 이하에 존재합니다.  
• CVE-2021-45105 해커가 실행할 수 있게 해줍니다. DoS (Denial-of-Service) 공격 Log4j에 악성 메시지를 보내서. Log4j 버전 2.16 이하에 존재합니다. 
• CVE-2021-44832 원격 코드 실행 취약점입니다. 이 결함은 해커가 이를 악용하기 전에 높은 권한을 얻어야 하기 때문에 Log4Shell보다 덜 중요합니다. Log4j 버전 2.17 이하에 존재합니다.  

Log4j 취약점을 탐지하는 방법   

네트워크에서 모든 취약한 Log4j 인스턴스를 찾는 것은 어려울 수 있습니다. Log4j는 추정값으로 나타납니다. 수백만 개의 앱, 이는 보안 팀이 검사해야 할 자산이 많다는 것을 의미합니다. 

게다가 Log4j는 간접적인 종속성으로 존재하는 경우가 많습니다. 즉, 자산의 소스 코드에 직접 포함되지는 않지만 자산이 의존하는 소프트웨어 패키지 또는 통합의 종속성으로 나타납니다. 구글 보고서 가장 취약한 Log4j 인스턴스는 종속성 체인의 한 수준 이상 깊이에 있으며 일부는 최대 XNUMX개 수준 깊이에 있습니다.

즉, 보안 팀은 올바른 전술과 도구를 사용하여 Log4j 취약점을 탐지할 수 있습니다.  

무엇을 찾아야할까요?

4-beta2부터 2.0까지 모든 Log9j 2.17 버전은 Log4Shell 또는 관련 결함에 취약합니다. 다르게 말하면, 보안 팀은 4 이전의 모든 Log2.17.1j 버전을 찾아 해결해야 합니다.

Log4Shell 및 관련 결함은 Log4j의 핵심 기능을 제공하는 "Log4j-core" 파일에만 존재합니다. 앱과 Log4j 로거 간의 인터페이스를 제어하는 ​​"Log4j-api" 파일에는 결함이 없습니다.

Log4j는 회사가 관리하는 자산, 회사가 사용하는 타사 자산(예: 클라우드 서비스), 회사 네트워크에 액세스할 수 있는 서비스 공급자가 사용하는 자산에 나타날 수 있습니다. Log4j는 Java 기반 앱에 나타날 가능성이 가장 높지만 종속성 및 통합을 통해 Java가 아닌 앱에도 나타날 수 있습니다.

Java 앱 내에서 Log4j와 같은 라이브러리는 종종 Java 아카이브 파일 또는 "JAR 파일"로 패키지됩니다. JAR 파일에는 다른 JAR 파일이 포함될 수 있으며, 이 JAR 파일에는 자체 JAR 파일 등이 포함될 수 있습니다. 취약한 모든 Log4j 버전을 찾으려면 보안 팀은 최상위 파일뿐만 아니라 모든 수준의 JAR 파일을 검사해야 합니다.

그것을 찾는 방법 

전문가들은 Log4j 취약점을 찾기 위해 여러 가지 기술을 조합하여 사용할 것을 권장합니다.

수동 검색. 보안팀은 Log4j 결함을 수동으로 검색할 수 있습니다. Apache Maven과 같은 개발 도구를 사용하여 앱의 모든 종속성을 매핑하는 종속성 트리를 생성하거나 외부를 사용할 수 있습니다. 위협 정보 영향을 받은 자산을 식별합니다. 예를 들어 CISA(사이버보안 및 인프라 보안국)는 Log4Shell로 인해 피해를 입은 것으로 알려진 소프트웨어 목록을 편집했습니다. 목록을 사용할 수 있습니다 GitHub에서.

Linux, Microsoft Windows 및 macOS 운영 체제에서 보안 팀은 명령줄 인터페이스를 사용하여 Log4j 인스턴스에 대한 파일 디렉터리를 검색할 수 있습니다.

취약점 검색 도구. Log4Shell의 발견에 따라 일부 조직에서는 Log4j 취약점을 찾기 위해 설계된 무료 도구를 출시했습니다. 예를 들면 다음과 같습니다 Palantir의 Log4j 스니퍼 과 CERT 조정 센터의 스캐너많은 다른 사람의 사이에서.

특수 스캐너를 여전히 사용할 수 있지만 다음과 같은 많은 표준 보안 솔루션이 있습니다. 취약점 스캐너, 공격 표면 관리 (ASM) 플랫폼 및 엔드포인트 탐지 및 대응 (EDR) 솔루션은 이제 Log4j 취약점을 감지할 수 있습니다.

Log4Shell은 종속성 체인 깊숙이 숨어 있을 수 있으므로 보안 팀은 다음과 같은 보다 실질적인 방법으로 자동화된 스캔을 보완할 수 있습니다. 침투 테스트.

위협 사냥. CISA에 따르면, 공격자는 Log4Shell을 사용하여 네트워크에 침입한 다음 자신의 흔적을 감추기 위해 손상된 자산을 패치하는 것으로 알려져 있습니다. 이러한 이유로 보안 팀은 위반이 이미 발생했다고 가정하고 적극적으로 사냥하다 Log4Shell 악용 징후가 있는지 확인하세요.

다음과 같은 사이버 보안 도구 보안정보 및 이벤트 관리t(SIEM) 솔루션 및 확장 된 탐지 및 대응 (XDR) 플랫폼은 이상한 로그 항목이나 의심스러운 트래픽 패턴 등 Log4Shell과 관련된 비정상적인 활동을 감지하는 데 도움이 될 수 있습니다. 보안 팀은 전체 출시를 시작해야 합니다 사고 대응 공격의 결과가 얼마나 심각한지를 고려하여 Log4Shell의 가능한 힌트에 대한 조사 절차를 제공합니다.

Log4j 취약점을 수정하는 방법

보안 팀에는 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 조회를 더 이상 수행할 수 없습니다.

아파치 다음 명령을 사용하여 취약한 앱에서 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을 방지하기

Log4Shell을 교정할 때 까다로운 점 중 하나는 항상 패치가 유지되지 않는다는 것입니다. 2022년 XNUMX월, 테너블 보고됨 Log29Shell에 여전히 취약한 자산 중 4%는 "반복"이었습니다. 즉, 패치가 적용되었지만 결함이 다시 나타났습니다. 개발자가 실수로 패치되지 않은 Log4j 버전이 포함된 소프트웨어 라이브러리를 사용하여 앱을 빌드하거나 업데이트하는 경우 재발이 발생합니다.

개발자는 자신이 사용하는 프레임워크를 더 면밀히 조사할 수 있지만 JAR 파일의 여러 수준에 깊이 있는 취약한 Log4j 버전을 놓치기 쉽습니다.

공식 구현 취약점 관리 과 패치 관리 프로그램은 보안 팀에 Log4j 취약점이 반환되는지 자산을 모니터링하는 보다 효과적인 방법을 제공할 수 있습니다. 정기적인 취약성 검색 및 침투 테스트는 Log4Shell 등의 새로운 취약성을 신속하게 파악하는 데 도움이 됩니다. 패치 관리를 통해 공급업체가 수정 사항을 출시하는 즉시 새로운 취약점이 해결됩니다.   

Log4Shell 및 기타 제로데이 취약점에 대한 추가 도움말

점점 더 많은 해커들이 Log4Shell과 같은 제로데이 취약점을 쉽게 악용하고 랜섬웨어 공격 및 기타 사이버 위협을 퍼붓기 위해 자동화된 도구를 사용하고 있습니다. 기존의 엔드포인트 보안 접근 방식을 사용하는 보안 팀은 경고 피로, 복잡한 도구 및 오랜 조사에 직면하고 있으며 이를 따라잡는 데 어려움을 겪고 있습니다.

IBM Security® QRadar® EDR(이전 ReaQta)은 인간 상호 작용이 거의 필요하지 않은 사용하기 쉬운 지능형 자동화를 통해 거의 실시간으로 알려지거나 알려지지 않은 엔드포인트 위협을 해결합니다. QRadar EDR을 사용하면 분석가는 정보에 기초하여 신속하게 결정을 내리고 자동화된 경보 관리를 사용하여 가장 중요한 위협에 집중할 수 있습니다. 고급 연속 학습 AI 기능과 사용자 친화적인 인터페이스를 통해 보안 직원이 다시 제어권을 확보하고 비즈니스 연속성을 보호하는 데 도움이 됩니다.

IBM Security QRadar EDR 살펴보기