본문 바로가기
컴소니/보안

Apache Log4j 2.x 취약점 조치 및 결과

by 금소니 2021. 12. 23.
반응형

#196

1. Apache Log4j 2.x 취약점[CVE-2021-4428]

 

Apache Log4j 2.x 취약점[CVE-2021-44228]

#193 1. Log4j 2.x 취약점 - 취약점 : CVE-2021-44228 - 취약한 버전 : 2.0-beta9 ~ 2.14.1 모든 버전(Log4j 2.12.2 제외) CVE - CVE-2021-44228 Apache Log4j2 2.0-beta9 through 2.12.1 and 2.13.0 through 2.1..

goldsony.tistory.com

2. Apache Log4j 2.x 취약점 PoC

 

Apache Log4j 2.x 취약점 PoC

#195 1. Apache Log4j 2.x 취약점[CVE-2021-4428] Apache Log4j 2.x 취약점[CVE-2021-44228] #193 1. Log4j 2.x 취약점 - 취약점 : CVE-2021-44228 - 취약한 버전 : 2.0-beta9 ~ 2.14.1 모든 버전(Log4j 2.12.2..

goldsony.tistory.com

3. Apache Log.4j 2.x 취약점 조치 및 결과

취약점에 대해서 알아봤고 PoC도 해봤으니 이제 어떻게 조치를 해야하는지 알아보도록 하겠습니다.

(조치의 경우 각자 운영환경에 맡게 조치하셔야 합니다.)

 

조치 방법으로는 최신 버전으로 업데이트 하는 방법JNDI Lookup과 관련된 클래스를 삭제하는 방법이 있습니다.

 

우선 조치 전에 본인이 취약한 버전을 사용하고 있는지 확인이 필요합니다.

 

어플리케이션은 PoC 진행하였던 프로젝트를 이용해보도록 하겠습니다.

 

1) Log4j 버전 확인하기

1)-1 IDE(Eclipse)를 통한 확인

해당 프로젝트를 Eclipse를 통하여 Import 해본 결과, 프로젝트는 gradle을 사용하였고 log4j 2.14.1버전을 사용하고 있는 것을 확인할 수 있었습니다.

1)-2 배포된 서버에서 확인

서버에는 jar파일로 배포가 되어있습니다.

그리고 해당 jar파일 내부에서 log4j를 사용하고 있는지 없는지 확인을 위하 아래의 명령을 통해 확인하실 수 있습니다.

jar -tf [jar파일] | grep 'log4j'

확인해보니 당연히 Log4j 2.14.1 버전을 사용하고 있는 것을 확인할 수 있었습니다.

 

2) JNDI Lookup 클래스 삭제하기(실패)

취약한 버전이 확인되었으니 이제 조치를 해보도록 하겠습니다.

먼저 서버에서 JNDI Lookup 클래스를 삭제해보도록 하겠습니다.

jar파일 안의 위에 찾은 경로에 있는 log4j-core-*.jar 파일 안에 있는 클래스를 삭제해야 합니다.

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

PoC한 버전의 경우 어플리케이션을 구동할 때 jar 파일이 풀리지 않고 jar 상태로 동작하여 위와 같은 작업을 해보려고 했으나 실패하였습니다. ㅠㅠ

혹시 jar로 서비스할 경우 저 클래스만 삭제하는 방법을 알고 계시면 댓글 꼭 부탁드립니다.

(jar파일을 풀었다가 삭제한 뒤 다시 압축해보기도 했지만 정상적인 방법이 아니더라구요.)

 

3) Log4j 최신 버전으로 업데이트하기

첫 번째 방법은 실패하여 최신 버전으로 업데이트 해보도록 하겠습니다.

먼저 PoC 진행하였던 프로젝트는 gradle로 빌드 도구를 사용하고 있습니다.

spring gradle 공식 문서를 보니 라이브러리를 업데이트 할 경우 maven의 pom.xml과 같이 build.gradle이라는 파일을 이용하라고 되어있습니다.

 

Spring Boot Gradle Plugin Reference Guide

To manage dependencies in your Spring Boot application, you can either apply the io.spring.dependency-management plugin or use Gradle’s native bom support. The primary benefit of the former is that it offers property-based customization of managed versio

docs.spring.io

그리고 라이브러리를 커스터마이징하는 방법은 다음과 같이 안내되어 있습니다.

이렇게 build.gradle에 추가하면 라이브러리가 빌드 시 변경된다고 합니다.

 

그럼 변경해보도록 하겠습니다.

먼저 프로젝트 구성와 build.gradle 소스입니다.

기본적으로 spring-boot 2.6.1의 의존 라이브러리를 가져오는 것으로 보입니다.

여기서 저희는 log4j와 관련된 버전을 변경하면 되므로 아래와 같이 추가해보도록 하겠습니다.

현재 log4j의 최신 버전은 2.17.0 버전이라고 합니다.

 

이제 빌드해보도록 하겠습니다.

PoC 프로젝트는 Dockerfile을 통해 빌드에서 jar 배포까지 되는 이미지를 생성하도록 되어 있습니다.

따라서 Dockerfile만 빌드하면 해당 프로젝트까지 빌드가 완료됩니다.

(빌드 부분의 경우 각 프로젝트마다 다르므로 상황에 맞게 진행하시기 바랍니다.)

저의 경우에는 아래와 같이 빌드 후 이미지를 생성하여 컨테이너를 실행하였습니다.

docker build . -t vulnearble-app-new
docker run -p 8080:8080 --name vulnearble-app-new vulnearble-app-new

그럼 컨테니어 내부로 들어가서 과연 log4j 버전이 변경되었는지 확인해보도록 하겠습니다.

확인결과, 최신 버전인 2.17.0 버전으로 변경된 것을 볼 수 있었습니다.

 

4) 다시 테스트해보기

조치가 완료되었으니 과연 아무일이 없을지 테스트를 해보도록 하겠습니다.

환경은 PoC 진행하였던 환경과 동일한 상태입니다.

 

Apache Log4j 2.x 취약점 PoC

#195 1. Apache Log4j 2.x 취약점[CVE-2021-4428] Apache Log4j 2.x 취약점[CVE-2021-44228] #193 1. Log4j 2.x 취약점 - 취약점 : CVE-2021-44228 - 취약한 버전 : 2.0-beta9 ~ 2.14.1 모든 버전(Log4j 2.12.2..

goldsony.tistory.com

동일하게 위의 서버에 test라는 폴더를 생성하도록 명령을 실행할 예정입니다.

구동 중인 LDAP 서버에 동일하게 피해 서버로 curl을 이용하여 요청을 보냈습니다.

과연 결과가 어떻께 되었을까요?

확인해보니 디렉토리 생성에 대한 명령이 실행되지 않을 것을 알 수 있었습니다.

 

다행히 조치가 된 것으로 보입니다.

 

정말 심각한 취약점이다보니 해당되시는 분들은 꼭 조치하신 후 사용하시기 바랍니다.

 

참고사이트

https://github.com/christophetd/log4shell-vulnerable-app

https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/htmlsingle/#managing-dependencies.dependency-management-plugin.customizing

반응형

댓글