Log4J-Mitigation-CVE-2021-44228,CVE-2021-45046,CVE-2021-45105,CVE-2021-44832

Apache Log4j 팀이 CVE를 훨씬 더 많이 공개하고 보안 문제를 매우 빠르게 수정하고 있으므로 이 페이지를 계속 주시하시기 바랍니다.

업데이트 - 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 아키텍처:

jndiarch

다양한 환경에 대한 완화 조치:

업데이트 - 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

 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. 모든 컨테이너화된 애플리케이션

컨테이너화된 애플리케이션의 경우 사용 중인 Log4j 2 버전이 2.10.0 이상이면 안전하지 않은 대체 동작을 비활성화하는 데 사용할 수 있는 환경 변수 또는 Java 명령줄 옵션이 있습니다. 다음 줄을 추가할 수 있습니다:
```
 ENV LOG4J_FORMAT_MSG_NO_LOOKUPS=true
```
Dockerfile 참조: https://github.com/lhotari/Log4Shell-mitigation-Dockerfile-overlay/blob/master/Dockerfile
Dockerfile에 추가하거나, 컨테이너에서 실행하는 명령에 동일한 플래그 "-Dlog4j.formatMsgNoLookups=true"를 추가할 수 있습니다. 예:
```
 CMD ["java", "-Dlog4j.formatMsgNoLookups=true", "-jar", "..."]
```
런타임에 환경 변수를 구성할 수도 있는데, 이 방법이 더 쉬울 수 있습니다. 예를 들어 Kubernetes의 경우 구성에 다음 줄을 추가할 수 있습니다.
```
 spec:
   containers:
   - name: ...
     image: ...
     env:
     - name: LOG4J_FORMAT_MSG_NO_LOOKUPS
       value: "true"
```

5. Azure Functions:

시스템 속성 구성은 전용(dedicated), 프리미엄(premium) 또는 소비(consumption) 중 선택한 호스팅 옵션에 따라 달라집니다. 참고로 기본 권장 완화 조치는 Log4J를 2.15.0으로 업그레이드하고 애플리케이션을 다시 배포하는 것입니다. 어떤 이유로든 그렇게 할 수 없다면 시스템 속성을 적용할 수 있습니다.

- 전용 및 프리미엄 Functions:

값이 “-Dlog4j2.formatMsgNoLookups=true”인 JAVA_OPTS라는 앱 설정을 만드십시오. 이미 JAVA_OPTS 앱 설정이 설정된 경우 기존 값에 “-Dlog4j2.formatMsgNoLookups=true”를 추가하기만 하면 됩니다.

- 소비(Consumption) Functions:

Linux: “languageWorkers__java__arguments”라는 앱 설정을 값 “-Dlog4j2.formatMsgNoLookups=true”로 만드십시오. Windows: “languageWorkers:java:arguments”라는 앱 설정을 값 “-Dlog4j2.formatMsgNoLookups=true”로 만드십시오. **앱 설정을 업데이트하면 Web 및 Function 앱이 다시 시작되어 콜드 스타트 성능에 영향을 줄 수 있습니다. Log4J 버전 2.9 이하를 사용하는 경우 이 시스템 속성 완화는 작동하지 않으므로 v2.15.0으로 업그레이드해야 합니다.

6. Apache Log4j용 핫패치

어떻게 작동하나요? 이 도구는 실행 중인 JVM 프로세스에 Java 에이전트를 주입합니다. 에이전트는 로드된 모든 org.apache.logging.log4j.core.lookup.JndiLookup 인스턴스의 lookup() 메서드를 패치하여 문자열 “Patched JndiLookup::lookup()”을 무조건 반환하도록 시도합니다. 이는 Java 프로세스를 재시작하지 않고 Log4j의 CVE-2021-44228 원격 코드 실행 취약점을 해결하기 위해 설계되었습니다.

Java 프로세스를 재배포할 수 있는 경우 정적 에이전트로도 사용할 수 있습니다. 즉, 서버에 직접 로그인하지 않고 런타임에 이 패치를 포함할 수 있습니다.

Github : https://github.com/corretto/hotpatch-for-apache-log4j2

7. Defender for Cloud가 Log4j 취약점의 영향을 받는 머신을 찾는 방법

인벤토리를 사용하면 노출을 파악할 수 있는 두 가지 강력한 방법이 있습니다:

소프트웨어 인벤토리

취약성 평가 결과

https://techcommunity.microsoft.com/t5/microsoft-defender-for-cloud/how-defender-for-cloud-finds-machines-affected-by-log4j/ba-p/3037271

8. Azure Sentinel 및 WAF 로그에서 탐지:

Azure WAF Log4j CVE-2021-44228 헌팅

https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/AzureDiagnostics/WAF_log4j_vulnerability.yaml

Azure WAF Log4j 취약점(CVE-2021-44228) 매칭

https://github.com/Azure/Azure-Sentinel/blob/master/Detections/AzureDiagnostics/AzureWAFmatching_log4j_vuln.yaml

9. 향후 빌드에서 취약한 log4j2 버전을 금지하기 위한 Maven 플러그인 구성:

오래된 log4j2 버전의 사용을 방지하기 위해 부모 POM에 넣는 Maven 플러그인 구성입니다. 이러한 버전 중 일부는 RCE CVE-2021-44228

("Log4Shell"), CVE-2021-45046 및 CVE-2021-45105의 영향을 받습니다.

참조: https://gist.github.com/gunnarmorling/8026d004776313ebfc65674202134e6d

 <!-- plug-in configuration to put into your parent POM for avoiding any usages of
     outdated log4j2 versions, some of which are subject to the RCE CVE-2021-44228
     ("Log4Shell"), CVE-2021-45046, and CVE-2021-45105. Make sure to check for the
     latest version of log4j2 at
     https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core -->
...
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-enforcer-plugin</artifactId>
  <version>3.0.0</version>
  <executions>
    <execution>
      <id>ban-bad-log4j-versions</id>
      <phase>validate</phase>
      <goals>
        <goal>enforce</goal>
      </goals>
      <configuration>
        <rules>
          <bannedDependencies>
            <excludes>
              <exclude>org.apache.logging.log4j:log4j-core:(,2.17.0)</exclude>
            </excludes>
          </bannedDependencies>
        </rules>
        <fail>true</fail>
      </configuration>
    </execution>
  </executions>
</plugin>
...

기여:

커뮤니티의 기여를 환영합니다. 기여 지침:

-->PR을 보내주세요.

-->더 많은 맥락을 위해 참조 소스를 포함해 주세요.

수정할 수 있는 다양한 환경과 다른 방법이 있을 수 있습니다. 언제든지 풀 리퀘스트를 열어 주세요:

참조:

https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/

https://www.docker.com/blog/apache-log4j-2-cve-2021-44228/

https://github.com/justincormack/log4jpoc

https://www.rumble.run/blog/finding-log4j/

https://www.veracode.com/blog/research/exploiting-jndi-injections-java

https://github.com/lhotari/Log4Shell-mitigation-Dockerfile-overlay