Java 프로젝트가 공격받기 쉬운 Log4j 버전에 의존하는지 확인하는 방법

Log4j(CVE-2021-44228)으로 추적된 Log4Shell의 빈틈은 공격자가 시스템에서 임의의 코드를 실행할 수 있도록 허용한다.만약 응용 프로그램이 2.0-alpha1~2.14.1 버전의 Log4j를 사용한다면 가능한 한 빨리 latest version(본문을 작성할 때 2.16.0)으로 업데이트해야 한다.
스위스 정부는 이 빈틈을 설명하기 위해 published에 아주 좋은 도표를 제공했다.

이제 우리 완화 전략을 깊이 연구합시다...

Maven 종속 플러그인 사용

Maven 프로젝트에서 의존 항목 트리에서 log4j 핵심 의존 항목을 검색하고 영향을 받는 의존 항목을 사용하는지 검사할 수 있습니다.이 작업을 수행하는 간단한 방법은 다음 명령을 실행하는 것입니다.

mvn dependency:tree -Dincludes=org.apache.logging.log4j:log4j-core

이 명령은 Maven Dependency Plugin을 사용하여 프로젝트의 의존 관계 트리를 표시합니다. (전달 가능한 의존 관계 포함)includes 옵션은 출력을 필터합니다.log4 핵심 의존항만 표시합니다.프로젝트가 공격받기 쉬운 Log4j 버전에 의존하는 경우 다음과 같은 내용이 표시됩니다.

이 예에서 출력 디스플레이 항목은 Log4j의 2.14.1 버전을 직접 사용합니다. (공격받기 쉽습니다.)이 항목은 종속성을 업데이트해야 합니다.

<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.14.1</version> <!-- update this! -->
</dependency>

다음은 다음과 같습니다.

<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.16.0</version> <!-- or newer version -->
</dependency>

나는 JDBC connector의 MariaDB database 프로젝트에서 이 점을 시험해 보았는데 다음과 같은 결과를 얻었다.

이것은 좋은 소식입니다. 이 프로젝트는 Log4j를 사용하지 않기 때문에 Log4Shell의 공격을 받지 않습니다. (MariaDB에 대한 구체적인 사례는 this article 참조)

Maven 도움말 플러그인 사용

더 자세히 조사하려면 유효한 POM을 확인하고 항목에 사용된 로그 프레임워크를 검색해야 할 수도 있습니다.MariaDB JDBC 연결기 프로젝트를 계속 진행하고 있습니다. 저는 Maven Help Plugin을 사용하여 효과적인 POM을 생성합니다. 저는 클래스 Unix 운영체제(macOS)를 사용하기 때문에 grep 필터 출력(Windows에서 findstr을 사용할 수 있습니다)을 사용합니다. 아래와 같습니다.

mvn help:effective-pom | grep log

다음과 같은 출력을 얻었습니다.

이것은MariaDB JDBC 드라이버가 로그 프레임워크로 Logback을 사용하고 있음을 나타낸다.Logback은 Log4Shell의 영향을 받지 않지만 fixed in version 1.2.8 과 1.3.0-alpha11에 관련된 빈틈이 있습니다.나는 연결기가 사용하는 버전을 검사했는데, 그것이 1.3.0-alpha10을 사용한 것을 발견했다.MariaDB 드라이버에서 Logback은 테스트 의존항으로 포함되어 있지만, GitHub에 pull request을 보내서 업데이트했습니다.공격을 받기 쉬운 의존항을 포함해서 발견한 모든 개원 항목에서도 이렇게 하도록 격려합니다.

Syft 및 Grype 사용

대량의 JAR 파일을 포함하는 더 복잡한 프로젝트에서는 Syft과 Grype 등의 도구를 사용할 수 있다.Syft는 컨테이너 이미지 및 파일 시스템에서 소프트웨어 BOM(Software BoM)을 생성하는 CLI 도구 및 Go 라이브러리입니다.Grype와 함께 사용할 수 있으며, Grype는 용기 이미지와 파일 시스템을 여러 층으로 끼워서 스캔해서 빈틈을 찾을 수 있습니다.

LunaSec 도구 사용

LunaSec(소스 데이터 보안 플랫폼)의 직원이 소스 오픈 도구를 개발하여 디렉터리를 스캔하여 공격받기 쉬운 Log4j 의존 항목과 일치하는 해시 파일을 찾을 수 있습니다.tool은 Windows, Linux 및 macOS 시스템에 적합합니다.네가 해야 할 일은 디렉터리를 통해 검색하는 도구를 실행하는 것이다.예를 들면 다음과 같습니다.

log4shell scan your-project-dir

공격을 받기 쉬운 항목에서 당신은 다음과 같은 결과를 얻을 수 있습니다.

10:04AM INF identified vulnerable path fileName=org/apache/logging/log4j/core/net/JndiManager$1.class path=test/struts-2.5.28-all/struts-2.5.28/apps/struts2-rest-showcase.war::WEB-INF/lib/log4j-core-2.12.1.jar versionInfo="log4j 2.8.2-2.12.0"

log4j 검색 사용

FullHunt에 위치한 팀은 log4j-scan이라는 소스 오픈 도구를 제공했다. 이것은 공격받기 쉬운 Log4j 호스트를 찾는 자동화되고 광범위한 스캐너이다.팀이 인프라를 검색할 수 있지만 WAF(Web 응용 프로그램 방화벽) bypasses을 테스트할 수도 있습니다. 이로 인해 코드가 실행될 수 있습니다.이 도구에는 몇 가지 옵션이 있지만, 간단하게 말하면, 검색할 URL을 이 도구에 전달하면, 발견된 빈틈에 대한 보고서를 얻을 수 있다.예를 들면 다음과 같습니다.

python3 log4j-scan.py -u https://log4j.lab.secbot.local

다음은 출력된 화면 캡처입니다.

Huntess Log4Shell 취약성 측정기 사용

Huntress Log4Shell vulnerability tester은 애플리케이션이 공격받기 쉬운 Log4j 버전을 사용하는지 확인하는 온라인 소스 오픈 툴입니다.이 도구는 검사할 프로그램에서 입력으로 사용할 문자열을 생성합니다. 예를 들어 텍스트 필드에서 이 문자열을 사용합니다.이 문자열에는 LDAP 서버에 대한 JNDI 검색이 포함됩니다.서버는 응용 프로그램에서 요청을 기록하고 해당 요청의 IP 주소를 표시합니다.나는 비디오를 녹화하여 이 도구를 보여 주었다.

결론

더 많은 도구가 등장하고 있습니다. 안전 전문가가 어떤 publishing인지 주목해 주십시오.내가 MariaDB JDBC connector에 한 것처럼, Log4j를 사용하는 소스 프로젝트에 패치를 보내는 것을 권장합니다. 공격받기 쉬운 버전을 사용한 것을 발견하면.