thedevappsecguy/log4j-mitigation-cve-2021-44228--cve-2021-45046--cve-2021-45105--cve-2021-44832Log4J CVE-2021-44228 : 완화 치트 시트
업데이트 - 28-Dec-2021
CVE-2021-44832: 공격자가 구성을 제어할 때 Apache Log4j2는 JDBC Appender를 통한 RCE에 취약합니다.
Log4j 2.17.1(Java 8), 2.12.4(Java 7) 및 2.3.2(Java 6)에서 수정됨
업데이트 - 17-Dec-2021
하룻밤 사이에 Apache가 Log4j 버전 2.16도 서비스 거부 공격에 취약하다고 공개했으며, 그 영향은 애플리케이션 전체 충돌입니다. 이 심각도는 높음(High, 7.5) 으로 분류되었으며 CVE-2021-45105가 발행되었습니다. Apache는 새로운 수정 버전(2.17)을 게시했으므로 업그레이드를 권장합니다.
배경:
인터넷에서는 Java용 Apache의 인기 있는 Log4J 로깅 라이브러리에서 원격 코드 실행을 유발할 수 있는 0-day 취약점에 대한 논의가 뜨거웠습니다. CVE-2021-44228로 추적되고 CVSS 점수 10의 최대 "치명적(critical)" 등급을 받은 이 취약점은 Log4J의 조회(lookup) 기능과 JNDI(Java Naming and Directory Interface)가 결합된 데 있습니다. 많은 개발자가 Log4J를 필터링되지 않은 입력과 함께 사용하는 것이 위험하다는 사실을 인지하지 못했기 때문에 이 문제는 광범위하게 퍼졌습니다.
가장 중요한 영향은 공격자가 문자열을 로거에 도달하게 하여 Log4J가 처리할 때 임의 코드를 실행할 수 있다는 것입니다. 첫 번째 예로는 ${jndi:ldap} 경로를 사용했으며, 이로 인해 원격 URL에서 임의 코드가 로드될 수 있습니다. 이 경로는 기본적으로 URL 기반 클래스 로더를 차단하는 최신 Java 런타임을 사용하면 부분적으로 완화됩니다. 불행히도 최신 버전의 Java만으로는 애플리케이션 자체가 임의 코드를 실행하는 데 사용할 수 있는 클래스를 노출할 수 있으므로 악용을 방지하기에 충분하지 않을 수 있습니다.
JNDI 아키텍처:
다양한 환경에 대한 완화 조치:
업데이트 - 17-Dec-2021
보안 취약점 CVE-2021-45105
세부 정보:
Apache Log4j2 버전 2.0-alpha1부터 2.16.0까지는 자기 참조 조회(self-referential lookups)로 인한 통제되지 않은 재귀로부터 보호하지 못했습니다. 로깅 구성이 기본값이 아닌
Context Lookup(예: $${ctx:loginId})이 포함된 Pattern Layout을 사용하는 경우 Thread Context Map(MDC) 입력 데이터를 제어하는 공격자는 재귀 조회를 포함하는 악의적인 입력 데이터를 조작하여
프로세스를 종료시키는 StackOverflowError를 유발할 수 있습니다. 이는 DOS(Denial of Service) 공격으로도 알려져 있습니다.
완화 조치:
버전 2.17.0(Java 8 기준)부터는 구성(configuration)의 조회 문자열만 재귀적으로 확장됩니다. 다른 모든
용도에서는 최상위 조회만 해석되며 중첩된 조회는 해석되지 않습니다.
이전 릴리스에서는 로깅 구성이 다음을 수행하도록 하여 이 문제를 완화할 수 있습니다:
로깅 구성의 PatternLayout에서 ${ctx:loginId} 또는 $${ctx:loginId} 같은 Context Lookup을 Thread Context Map 패턴(%X, %mdc 또는 %MDC)으로 바꾸십시오.
또는 구성에서 HTTP 헤더나 사용자 입력과 같이 애플리케이션 외부 소스에서 비롯된 ${ctx:loginId} 또는 $${ctx:loginId} 같은 Context Lookup 참조를 제거하십시오.
업데이트 - 13-Dec-2021
** Log4j(릴리스 2.16.0 – 2021-12-13)에는 두 가지 개선된 기능이 있습니다:**
---------------!!메시지 조회가 기본적으로 비활성화되어 있으므로 사용 가능한 최신 버전으로 업그레이드하는 것이 매우 권장됩니다.!!------------
https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0
JNDI를 기본적으로 비활성화합니다. JNDI를 허용하려면 log4j2.enableJndi를 true로 설정해야 합니다.
메시지 조회(Message Lookups)에 대한 지원을 완전히 제거합니다.
새로운 업데이트:
------------------CVE-2021-45046-----------------
Apache Log4j2 Thread Context Message Pattern 및 Context Lookup Pattern은 서비스 거부 공격에 취약합니다.
완화 조치:
Log4j 1.x 완화: Log4j 1.x는 이 취약점의 영향을 받지 않습니다.
Log4j 2.x 완화: 아래 완화 기법 중 하나를 구현하십시오.
Java 8(이상) 사용자는 릴리스 2.16.0으로 업그레이드해야 합니다. Java 7이 필요한 사용자는 릴리스 2.12.2가 제공되면 업그레이드해야 합니다(작업 진행 중이며 곧 제공될 예정입니다).
그렇지 않으면 classpath에서 JndiLookup 클래스를 제거하십시오: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
이 취약점의 영향을 받는 것은 log4j-core JAR 파일뿐입니다. log4j-core JAR 파일 없이 log4j-api JAR 파일만 사용하는 애플리케이션은 이 취약점의 영향을 받지 않습니다.
------------------CVE-2021-44228-------------------
완화 조치
Log4j 1.x 완화: Log4j 1.x에는 Lookup이 없으므로 위험이 더 낮습니다. Log4j 1.x를 사용하는 애플리케이션은 구성에서 JNDI를 사용하는 경우에만 이 공격에 취약합니다.
이 취약점에 대해 별도의 CVE(CVE-2021-4104)가 제출되었습니다. 완화하려면 로깅 구성을 감사하여 JMSAppender가 구성되어 있지 않은지 확인하십시오.
JMSAppender가 없는 Log4j 1.x 구성은 이 취약점의 영향을 받지 않습니다.
Log4j 2.x 완화: 아래 완화 기법 중 하나를 구현하십시오.
Java 8(이상) 사용자는 릴리스 2.16.0으로 업그레이드해야 합니다.
Java 7이 필요한 사용자는 릴리스 2.12.2가 제공되면 업그레이드해야 합니다(작업 진행 중이며 곧 제공될 예정입니다).
그렇지 않으면 classpath에서 JndiLookup 클래스를 제거하십시오: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
이 취약점의 영향을 받는 것은 log4j-core JAR 파일뿐입니다. log4j-core JAR 파일 없이 log4j-api JAR 파일만 사용하는 애플리케이션은 이 취약점의 영향을 받지 않습니다.
1. Apache Log4j:
릴리스 >=2.10** 및
릴리스 >=2.0-beta9 및 <=2.10.0의 경우
2. pom.xml 수정:
3. Azure App Service(Windows 및 Linux):
4. 모든 컨테이너화된 애플리케이션:
5. Azure Functions:
6. Apache Log4j용 핫패치
7. Defender for Cloud가 Log4j 취약점의 영향을 받는 머신을 찾는 방법
8. Azure Sentinel 및 Azure WAF 로그에서 탐지
9. 향후 빌드에서 취약한 log4j2 버전을 금지하기 위한 Maven 플러그인 구성
1. Apache Log4j:
CVE-2021-44228: Apache Log4j2의 JNDI 기능은 공격자가 제어하는 LDAP 및 기타 JNDI 관련 엔드포인트로부터 보호하지 못합니다.
영향을 받는 버전: 모든 log4j-core 버전 >=2.0-beta9 및 <=2.14.1 Apache Log4j <=2.14.1의 구성, 로그 메시지 및 매개변수에 사용되는 JNDI 기능은 공격자가 제어하는 LDAP 및 기타 JNDI 관련 엔드포인트로부터 보호하지 못합니다. 로그 메시지 또는 로그 메시지 매개변수를 제어할 수 있는 공격자는 메시지 조회 대체(message lookup substitution)가 활성화된 경우 LDAP 서버에서 로드된 임의 코드를 실행할 수 있습니다. log4j 2.15.0부터 이 동작은 기본적으로 비활성화되었습니다.
**릴리스 >=2.10****에서는 시스템 속성 log4j2.formatMsgNoLookups 또는 environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true를 설정하여 이 동작을 완화할 수 있습니다. 릴리스 >=2.7 및 <=2.14.1의 경우 모든 PatternLayout 패턴을 수정하여 메시지 변환기를 단순히 %m 대신 %m{nolookups}으로 지정할 수 있습니다.
릴리스 >=2.0-beta9 및 <=2.10.0의 경우 완화 방법은 classpath에서 JndiLookup 클래스를 제거하는 것입니다: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
2. pom.xml 수정:
pom.xml의 dependency를 업데이트하고 dependencies 섹션에서 사용 가능한 최신 버전으로 교체하십시오: https://search.maven.org/artifact/org.apache.logging.log4j/log4j/2.15.0/pom
<dependencies>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.14.1</version>
<!-- Swap with the below to prove it's fixed -->
<!-- <version>2.17.0</version>-->
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>2.14.1</version>
<!-- Swap with the below to prove it's fixed -->
<!-- <version>2.17.0</version>-->
</dependency>
</dependencies>
참조: https://github.com/justincormack/log4jpoc/blob/main/pom.xml#L18
3. Azure App Service(Windows 및 Linux):
가능하면 고객은 Log4j를 v2.15.0으로 업그레이드하고 애플리케이션을 다시 배포해야 합니다. 이것이 기본 권장 완화 조치입니다. 애플리케이션을 다시 배포할 수 없다면 Log4j 버전 2.10 이상에서 시스템 속성 “-Dlog4j2.formatMsgNoLookups=true”를 설정하여 이 동작을 완화할 수 있습니다. App Service에서 JAVA_OPTS라는 앱 설정을 값 “-Dlog4j2.formatMsgNoLookups=true”로 만들어 이 속성을 설정할 수 있습니다. JAVA_OPTS 앱 설정은 Java 애플리케이션이 시작될 때 전달됩니다. 이미 JAVA_OPTS 앱 설정이 설정된 경우 기존 값에 “-Dlog4j2.formatMsgNoLookups=true”를 추가하기만 하면 됩니다. Log4J 버전 2.9 이하를 사용하는 경우 이 시스템 속성 완화는 작동하지 않으므로 v2.15.0으로 업그레이드해야 합니다.
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings <setting-name>="<value>"
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings JAVA_OPTS="-Dlog4j2.formatMsgNoLookups=true"
4. 모든 컨테이너화된 애플리케이션