패치만으로는 충분하지 않은 이유
Log4Shell이 발생한 지 수년이 지났지만, Log4j는 여전히 엄청난 규모로 다운로드되고
있습니다. 2025년에만 개발자들이 Log4j를 약 3억 회 다운로드했으며, 이 가운데 약 4천만
건은 취약한 버전의 다운로드였습니다. 2026년의 한 스냅샷에서는 단 7일 동안 410만 건의
취약한 Log4j 다운로드가 확인되었습니다.
바로 이것이 핵심입니다.
Log4Shell은 패치되었지만 해당 Component는 사라지지 않았습니다.
Log4j는 계속해서 Build, Dependency, Vendor Software, Container 및 Production
Application을 통해 이동했습니다. 그리고 취약한 Version이 수년이 지난 후에도 여전히
다운로드되고 있다면, 다음 보안 위기는 아무것도 없는 상태에서 시작되지 않을 것입니다.
이미 실행되고 있는 Code 내부에서 시작될 것입니다.
Log4Shell은 일반적인 Vulnerability가 아니었습니다.
이는 세계에서 가장 널리 사용되는 Java Logging Library 중 하나인 Apache Log4j에서 발생한
CVSS 10 Remote Code Execution Vulnerability였습니다.
단순히 Logging되는 Field에 악의적인 문자열을 입력하는 것만으로도 공격이 가능했습니다.
그것이 이 취약점이 그토록 위험했던 이유입니다.
공격자는 복잡한 Exploit Chain이 필요하지 않았습니다.
Source Code에 접근할 필요도 없었습니다.
먼저 개발자의 PC를 침해할 필요도 없었습니다.
많은 경우 공격자는 단순히 공격자가 제어하는 Input을 Vulnerable Application이
Logging하도록 만들기만 하면 됐습니다.
예를 들면:
● Username
● User Agent
● Header
● Search Field
● Error Message
즉, Log4j에 전달되는 모든 입력이 공격 경로가 될 수 있었습니다.
그리고 Race가 시작되었습니다.
Security Team은 다음과 같이 단순해 보이지만 실제로는 결코 간단하지 않은 질문에 답해야
했습니다.
● 우리는 어디에서 Log4j를 사용하고 있는가?
● 어떤 Application이 Internet-facing 상태인가?
● 어떤 Version이 취약한가?
● 어떤 Dependency가 Log4j를 간접적으로 포함하고 있는가?
● 어떤 Vendor가 영향을 받는가?
● 어떤 System을 지금 즉시 Patch할 수 있는가?
● 너무 빠르게 Patch하면 어떤 System이 영향을 받을 것인가?
그렇기 때문에 Log4Shell은 단순한 Patching Problem 이상의 문제가 되었습니다.
Runtime Visibility Problem이 된 것입니다.
이 가이드에서는 Log4j Vulnerability를 Patch하는 방법, 환경에서 Log4j를 탐지하는 방법,
초기 Patching Process가 왜 그렇게 복잡했는지, 그리고 Vulnerability 공개와 Remediation
사이의 Window 동안 왜 Runtime Prevention이 중요한지를 설명합니다.
핵심 요점
Log4Shell은 CVE-2021-44228로 추적되는 Critical Remote Code Execution Vulnerability로,
Apache Log4j의 안전하지 않은 JNDI Lookup 동작으로 인해 발생했습니다.
공격자는 Header, Form Field, Username 또는 기타 Application이 Logging하는 데이터에
악의적인 Lookup String을 삽입하여 Log4j를 공격할 수 있었습니다.
Log4j Patching Process가 복잡했던 이유는 초기 Fix가 완전하지 않았고, 후속 CVE가 빠르게
등장했으며, Vulnerable Version이 Dependency Chain 깊숙한 곳에 묻혀 있는 경우가 많았기
때문입니다.
가장 안전한 Remediation 방법은 영향을 받은 Log4j 2.x Deployment를 지원되는 Fixed
Version으로 Upgrade하고, 즉시 Upgrade가 불가능한 경우 안전하지 않은 Vulnerable
Component를 제거하며, 지원이 종료된 Log4j 1.x 사용을 폐기하는 것입니다.
그러나 Patching만으로는 Live Exposure Window가 남습니다.
Runtime Prevention은 Security Team이 Vulnerable Code를 찾고, 우선순위를 지정하고,
Patch하고, Test하고, 다시 Deploy하는 동안 Application을 보호하는 역할을 합니다.
Runtime Application Detection 활용
Static Scanning은 Log4j가 어디에 존재할 수 있는지 알려줍니다.
Runtime Application Detection은 Log4j가 실제로 어디에서 Load되고 실행되는지
알려줍니다.
이 차이는 중요합니다.
사용되지 않는 Build Artifact에 묻혀 있는 Vulnerable Library와 Internet-facing Production
Service 내부에 Load되어 있는 Vulnerable Library는 동일하지 않습니다.
둘 다 Remediation이 필요할 수 있지만 Urgency는 동일하지 않습니다.
Runtime Visibility는 다음과 같은 실제 Production 상황을 기반으로 우선순위를 지정할 수
있도록 합니다.
● Vulnerable Package가 존재하는가?
● Load되었는가?
● Vulnerable Function이 Reachable한가?
● Application이 Internet-facing인가?
● 누군가 Vulnerable Path를 Trigger하려고 시도했는가?
● 어떤 Service, Container, Pod, Node, Workload 및 Application Owner가 관련되어
있는가?
이것이 단순히 긴 Vulnerability List를 만드는 것과 실제로 실행 가능한 Response Plan을
만드는 것의 차이입니다.
Log4j Patching Process: 단계별 절차
Log4Shell Patching은 단 한 번의 Update로 끝나는 작업이 아니었습니다.
초기 Fix가 Risk를 완전히 제거하지 못했기 때문에 여러 차례의 Update, Mitigation, Retesting
및 Redeployment가 필요했습니다.
Security 및 Engineering Team이 따라야 할 실질적인 Patching Process는 다음과 같습니다.
Step 1: 모든 영향받는 Version 식별
Code Repository, Build Artifact, Container Image, Deployed Workload, Vendor Software 및
Internal Tool 전반에서 Vulnerable Log4j의 모든 Instance를 식별합니다.
Log4j 2.x의 경우 CVE-2021-44228 및 관련 후속 Vulnerability와 연관된 Vulnerable log4j-core
Version을 우선적으로 확인해야 합니다.
Service가 Internal이라고 해서 문제가 없다고 가정해서는 안 됩니다.
Internal Service 역시 다음을 통해 접근될 수 있습니다.
● Compromised System
● CI/CD Environment
● Service-to-Service Traffic
● VPN User
● 노출된 Management Interface
또한 Repository가 Update되었다고 해서 Production이 안전하다고 가정해서도 안 됩니다.
Patched Version은 Build되고 Deploy되어 실제로 실행되고 있어야 합니다.
Step 2: Fixed Version으로 Upgrade
가장 우선적인 해결 방법은 Log4j를 안전하고 지원되는 Version으로 Upgrade하는 것입니다.
초기 Incident 당시 많은 Team은 먼저 2.15.0으로 이동했습니다.
그러나 이후 CVE-2021-45046이 특정 조건에서 초기 Fix가 불완전했음을 보여주었습니다.
이에 따라 다시 Update가 필요했습니다.
이후에도 CVE-2021-45105 및 CVE-2021-44832 등의 추가 Issue로 인해 추가적인
Remediation 작업이 발생했습니다.
이 역사는 중요합니다.
교훈은 Patching이 실패했다는 것이 아닙니다.
교훈은 Active Exploitation 상황에서 Patching 자체가 계속 변화하는 Target이었다는
것입니다.
현재 Remediation의 경우 조직의 환경에 맞는 최신 지원 Log4j 2.x Version을 사용하고
Apache의 최신 Security Guidance를 따라야 합니다.
Step 3: 즉시 Upgrade가 불가능한 경우 JndiLookup 제거
경우에 따라 즉시 Upgrade가 불가능할 수 있습니다.
예를 들어:
● Legacy Application
● Compatibility 불확실
● Vendor의 지원 Fix 미출시
● Production Deployment Window 부재
등의 상황입니다.
이러한 경우 Temporary Mitigation이 필요할 수 있습니다.
과거에 사용된 하나의 Mitigation 방법은 Vulnerable Log4j Package에서 JndiLookup
Class를 제거하는 것이었습니다.
이를 통해 공격자가 악용하던 Lookup Behavior를 제거하여 Exposure를 감소시킬 수
있었습니다.
그러나 Mitigation은 Remediation과 동일하지 않습니다.
Temporary Measure는 Permanent Fix가 아니라 Patching이 완료될 때까지의 Bridge로
취급해야 합니다.
Step 4: 지원이 종료된 Log4j 1.x 폐기
Log4j 1.x는 별도의 문제입니다.
Log4j 1.x는 End-of-Life 상태이며 장기적인 대안으로 안전하게 사용할 수 있는 것으로
취급해서는 안 됩니다.
여전히 Log4j 1.x를 사용하는 조직은 Production System 내부에서 지원되지 않는 Software에
의존하기보다 지원되는 Logging Framework로 Migration하는 계획을 수립해야 합니다.
이 작업은 단순 Version Bump보다 시간이 오래 걸릴 수 있습니다.
다음 작업이 필요할 수 있습니다.
● Code Change
● Dependency Change
● Testing
● Compatibility 작업
그러나 Production 환경에서 지원되지 않는 Logging Infrastructure를 계속 유지하는 것은
장기적인 Risk를 발생시킵니다.
Step 5: Rebuild, Redeploy 및 Verify
Dependency File을 Update하는 것만으로는 충분하지 않습니다.
Patched Dependency가 실행 중인 Application까지 실제로 반영되어야 합니다.
이를 위해 다음이 필요합니다.
● Artifact Rebuild
● Service Redeployment
● Container Image Update
● Vulnerable Package 교체
● 필요한 경우 Application Restart
● Production에서 실제 Fixed Version이 실행되고 있는지 검증
이 단계에서 Team이 자주 문제를 놓칩니다.
Ticket에는 “Patched”라고 표시되어 있을 수 있습니다.
Repository에는 “Updated”라고 표시될 수 있습니다.
Container Registry에도 Fixed Image가 존재할 수 있습니다.
하지만 기존 Workload가 여전히 실행 중일 수 있습니다.
따라서 Verification은 Pipeline뿐만 아니라 Runtime에서 수행되어야 합니다.
Step 6: Exploitation Attempt 모니터링
Patching이 과거의 Exposure를 지워주는 것은 아닙니다.
Team은 다음과 같은 항목을 검토해야 합니다.
● Log
● Outbound Connection
● Process Activity
● DNS Lookup
● 의심스러운 LDAP 또는 RMI Traffic
● 예상하지 못한 Child Process
● 비정상적인 Download
● Persistence Attempt
● Compromise 징후
목표는 별도의 질문에 답하는 것입니다.
“Patch하기 전에 이 Vulnerability가 Exploit되었는가?”
이 조사를 위해서는 Vulnerability Scanner만으로는 부족합니다.
Runtime 및 Application Context가 필요합니다.
Patching만으로 조직이 계속 노출되었던 이유
모든 Security Team은 Patching이 중요하다는 사실을 알고 있습니다.
Log4Shell이 증명한 것은 Patching이 필요 없다는 것이 아닙니다.
Exploitation이 활발하고 광범위하며 Enterprise Remediation Cycle보다 빠르게 진행되는
상황에서는 Patching만으로 충분하지 않다는 것을 증명했습니다.
Log4Shell은 Runtime Prevention이 Patching과 함께 존재해야 한다는 것을
보여주었습니다.
Patching은 Vulnerable Code Surface를 줄입니다.
Runtime Prevention은 실제로 Code가 Remediation되는 동안 발생하는 Live Execution
Window를 보호합니다.
두 가지는 서로 다른 역할입니다.
Scanner는 Log4j가 존재한다는 사실을 알려줄 수 있습니다.
SCA는 Dependency Version이 Vulnerable하다는 것을 알려줄 수 있습니다.
Ticket은 Engineering Team에 Patch 작업이 할당되었다는 것을 알려줄 수 있습니다.
Runtime Prevention은 다른 질문에 답합니다.
“Application은 지금 무엇을 하고 있는가?”
Active Exploitation 상황에서는 이 질문이 특히 중요합니다.
Runtime Prevention은 Application이 실행되는 동안 위험한 Execution Behavior를 관찰할 수
있습니다.
예를 들어 다음과 같은 동작을 확인할 수 있습니다.
● 예상하지 못한 Outbound Connection
● Process Spawning
● Command Execution
● 해당 Code Path에 존재하지 않는 기타 의심스러운 동작
그리고 중요한 것은 단순한 Detection만이 아닙니다.
핵심은 Attribution입니다.
● 어떤 Application이 해당 동작을 발생시켰는가?
● 어떤 Library가 원인이었는가?
● 어떤 Function Path가 관련되었는가?
● 어떤 Container, Image, Pod, Node 또는 Workload가 영향을 받았는가?
● 어떤 Team이 해당 Fix를 담당하는가?
이러한 Context가 없다면 Security Team은 Log, Endpoint Alert, Network Event, Scanner
Output 및 Ticket Data를 서로 연결하면서 공격자가 이미 이동하는 상황에 대응해야 합니다.
Runtime Application Security는 이러한 Gap을 해결합니다.
Raven은 어디에 위치하는가?
Raven은 Runtime에서 Application을 보호하도록 설계되었습니다.
Log4Shell과 같은 Incident에서 Raven은 Security Team이 실제 Production에서 어떤
Vulnerable Library가 존재하고, Load되고, Reachable하며, 실행되고 있는지를 파악하도록
지원합니다.
또한 Runtime Behavior를 다음과 같은 정보와 연결합니다.
● Application
● Library
● Function
● Call Chain
● Container
● Image
● Pod
● Node
● Workload
이러한 Context는 Response 방식을 변화시킵니다.
모든 Vulnerable Package를 동일한 수준의 Risk로 취급하는 대신 실제로 노출된 대상을
우선순위화할 수 있습니다.
모든 Patch가 모든 Pipeline을 통과할 때까지 기다리는 대신 Remediation Window 동안
Application을 보호할 수 있습니다.
단순히 Process 또는 Network Event만 보는 것이 아니라 해당 Event를 발생시킨
Application Code Path를 이해할 수 있습니다.
Log4Shell은 Patching Crisis였습니다.
그러나 동시에 Runtime Crisis이기도 했습니다.
Raven은 바로 이 Gap을 해결하기 위해 설계되었습니다.
결론: Log4j를 Patch하되, 거기서 멈추지 마십시오
Log4Shell에 대한 올바른 대응은 항상 Patching이었습니다.
Vulnerable Log4j Version을 찾고,
지원되는 Fixed Version으로 Upgrade하고,
즉시 Upgrade가 불가능한 경우 Unsafe Component를 제거하고,
지원이 종료된 Log4j 1.x 사용을 폐기하고,
Rebuild, Redeploy 및 Verify해야 합니다.
그러나 Log4Shell은 동시에 다음과 같은 사실을 분명하게 보여주었습니다.
Patching은 즉시 이루어지지 않습니다.
Visibility는 완전하지 않습니다.
Vendor Timeline은 항상 빠르지 않습니다.
Transitive Dependency는 찾기 어렵습니다.
Production System은 스스로 Update되지 않습니다.
그리고 공격자는 그 Gap 동안 움직입니다.
AI는 이러한 Gap을 더욱 위험하게 만들고 있습니다.
AI는 공격자가 다음 Vulnerable Open-Source Package를 더 빠르게 찾고, Exploit Path를 더
빠르게 생성하며, 대부분의 Team이 Inventory를 구축하고, Test하고, Patch하고,
Redeploy하는 것보다 빠르게 Payload를 변경하도록 도울 수 있습니다.
따라서 Exploit되기 전에 모든 Vulnerable Dependency를 찾아 Patch하는 것만으로는 확장
가능한 방어 모델이 될 수 없습니다.
그렇기 때문에 Runtime Prevention이 중요합니다.
Security Team은 여전히 Patch해야 합니다.
동시에 Patching이 진행되는 동안에도 보호가 필요합니다.
그리고 Patching이 진행되는 동안에도 보호가 필요합니다.
Log4Shell이 증명한 것은 바로 이 Layer가 기존 보안 체계에서 빠져 있었다는 것입니다.
https://softwidesec.com/raven
Raven에 관련된 소개자료 및 데모요청은 소프트와이드시큐리티로 연락바랍니다.
패치만으로는 충분하지 않은 이유
Log4Shell이 발생한 지 수년이 지났지만, Log4j는 여전히 엄청난 규모로 다운로드되고
있습니다. 2025년에만 개발자들이 Log4j를 약 3억 회 다운로드했으며, 이 가운데 약 4천만
건은 취약한 버전의 다운로드였습니다. 2026년의 한 스냅샷에서는 단 7일 동안 410만 건의
취약한 Log4j 다운로드가 확인되었습니다.
바로 이것이 핵심입니다.
Log4Shell은 패치되었지만 해당 Component는 사라지지 않았습니다.
Log4j는 계속해서 Build, Dependency, Vendor Software, Container 및 Production
Application을 통해 이동했습니다. 그리고 취약한 Version이 수년이 지난 후에도 여전히
다운로드되고 있다면, 다음 보안 위기는 아무것도 없는 상태에서 시작되지 않을 것입니다.
이미 실행되고 있는 Code 내부에서 시작될 것입니다.
Log4Shell은 일반적인 Vulnerability가 아니었습니다.
이는 세계에서 가장 널리 사용되는 Java Logging Library 중 하나인 Apache Log4j에서 발생한
CVSS 10 Remote Code Execution Vulnerability였습니다.
단순히 Logging되는 Field에 악의적인 문자열을 입력하는 것만으로도 공격이 가능했습니다.
그것이 이 취약점이 그토록 위험했던 이유입니다.
공격자는 복잡한 Exploit Chain이 필요하지 않았습니다.
Source Code에 접근할 필요도 없었습니다.
먼저 개발자의 PC를 침해할 필요도 없었습니다.
많은 경우 공격자는 단순히 공격자가 제어하는 Input을 Vulnerable Application이
Logging하도록 만들기만 하면 됐습니다.
예를 들면:
● Username
● User Agent
● Header
● Search Field
● Error Message
즉, Log4j에 전달되는 모든 입력이 공격 경로가 될 수 있었습니다.
그리고 Race가 시작되었습니다.
Security Team은 다음과 같이 단순해 보이지만 실제로는 결코 간단하지 않은 질문에 답해야
했습니다.
● 우리는 어디에서 Log4j를 사용하고 있는가?
● 어떤 Application이 Internet-facing 상태인가?
● 어떤 Version이 취약한가?
● 어떤 Dependency가 Log4j를 간접적으로 포함하고 있는가?
● 어떤 Vendor가 영향을 받는가?
● 어떤 System을 지금 즉시 Patch할 수 있는가?
● 너무 빠르게 Patch하면 어떤 System이 영향을 받을 것인가?
그렇기 때문에 Log4Shell은 단순한 Patching Problem 이상의 문제가 되었습니다.
Runtime Visibility Problem이 된 것입니다.
이 가이드에서는 Log4j Vulnerability를 Patch하는 방법, 환경에서 Log4j를 탐지하는 방법,
초기 Patching Process가 왜 그렇게 복잡했는지, 그리고 Vulnerability 공개와 Remediation
사이의 Window 동안 왜 Runtime Prevention이 중요한지를 설명합니다.
핵심 요점
Log4Shell은 CVE-2021-44228로 추적되는 Critical Remote Code Execution Vulnerability로,
Apache Log4j의 안전하지 않은 JNDI Lookup 동작으로 인해 발생했습니다.
공격자는 Header, Form Field, Username 또는 기타 Application이 Logging하는 데이터에
악의적인 Lookup String을 삽입하여 Log4j를 공격할 수 있었습니다.
Log4j Patching Process가 복잡했던 이유는 초기 Fix가 완전하지 않았고, 후속 CVE가 빠르게
등장했으며, Vulnerable Version이 Dependency Chain 깊숙한 곳에 묻혀 있는 경우가 많았기
때문입니다.
가장 안전한 Remediation 방법은 영향을 받은 Log4j 2.x Deployment를 지원되는 Fixed
Version으로 Upgrade하고, 즉시 Upgrade가 불가능한 경우 안전하지 않은 Vulnerable
Component를 제거하며, 지원이 종료된 Log4j 1.x 사용을 폐기하는 것입니다.
그러나 Patching만으로는 Live Exposure Window가 남습니다.
Runtime Prevention은 Security Team이 Vulnerable Code를 찾고, 우선순위를 지정하고,
Patch하고, Test하고, 다시 Deploy하는 동안 Application을 보호하는 역할을 합니다.
Runtime Application Detection 활용
Static Scanning은 Log4j가 어디에 존재할 수 있는지 알려줍니다.
Runtime Application Detection은 Log4j가 실제로 어디에서 Load되고 실행되는지
알려줍니다.
이 차이는 중요합니다.
사용되지 않는 Build Artifact에 묻혀 있는 Vulnerable Library와 Internet-facing Production
Service 내부에 Load되어 있는 Vulnerable Library는 동일하지 않습니다.
둘 다 Remediation이 필요할 수 있지만 Urgency는 동일하지 않습니다.
Runtime Visibility는 다음과 같은 실제 Production 상황을 기반으로 우선순위를 지정할 수
있도록 합니다.
● Vulnerable Package가 존재하는가?
● Load되었는가?
● Vulnerable Function이 Reachable한가?
● Application이 Internet-facing인가?
● 누군가 Vulnerable Path를 Trigger하려고 시도했는가?
● 어떤 Service, Container, Pod, Node, Workload 및 Application Owner가 관련되어
있는가?
이것이 단순히 긴 Vulnerability List를 만드는 것과 실제로 실행 가능한 Response Plan을
만드는 것의 차이입니다.
Log4j Patching Process: 단계별 절차
Log4Shell Patching은 단 한 번의 Update로 끝나는 작업이 아니었습니다.
초기 Fix가 Risk를 완전히 제거하지 못했기 때문에 여러 차례의 Update, Mitigation, Retesting
및 Redeployment가 필요했습니다.
Security 및 Engineering Team이 따라야 할 실질적인 Patching Process는 다음과 같습니다.
Step 1: 모든 영향받는 Version 식별
Code Repository, Build Artifact, Container Image, Deployed Workload, Vendor Software 및
Internal Tool 전반에서 Vulnerable Log4j의 모든 Instance를 식별합니다.
Log4j 2.x의 경우 CVE-2021-44228 및 관련 후속 Vulnerability와 연관된 Vulnerable log4j-core
Version을 우선적으로 확인해야 합니다.
Service가 Internal이라고 해서 문제가 없다고 가정해서는 안 됩니다.
Internal Service 역시 다음을 통해 접근될 수 있습니다.
● Compromised System
● CI/CD Environment
● Service-to-Service Traffic
● VPN User
● 노출된 Management Interface
또한 Repository가 Update되었다고 해서 Production이 안전하다고 가정해서도 안 됩니다.
Patched Version은 Build되고 Deploy되어 실제로 실행되고 있어야 합니다.
Step 2: Fixed Version으로 Upgrade
가장 우선적인 해결 방법은 Log4j를 안전하고 지원되는 Version으로 Upgrade하는 것입니다.
초기 Incident 당시 많은 Team은 먼저 2.15.0으로 이동했습니다.
그러나 이후 CVE-2021-45046이 특정 조건에서 초기 Fix가 불완전했음을 보여주었습니다.
이에 따라 다시 Update가 필요했습니다.
이후에도 CVE-2021-45105 및 CVE-2021-44832 등의 추가 Issue로 인해 추가적인
Remediation 작업이 발생했습니다.
이 역사는 중요합니다.
교훈은 Patching이 실패했다는 것이 아닙니다.
교훈은 Active Exploitation 상황에서 Patching 자체가 계속 변화하는 Target이었다는
것입니다.
현재 Remediation의 경우 조직의 환경에 맞는 최신 지원 Log4j 2.x Version을 사용하고
Apache의 최신 Security Guidance를 따라야 합니다.
Step 3: 즉시 Upgrade가 불가능한 경우 JndiLookup 제거
경우에 따라 즉시 Upgrade가 불가능할 수 있습니다.
예를 들어:
● Legacy Application
● Compatibility 불확실
● Vendor의 지원 Fix 미출시
● Production Deployment Window 부재
등의 상황입니다.
이러한 경우 Temporary Mitigation이 필요할 수 있습니다.
과거에 사용된 하나의 Mitigation 방법은 Vulnerable Log4j Package에서 JndiLookup
Class를 제거하는 것이었습니다.
이를 통해 공격자가 악용하던 Lookup Behavior를 제거하여 Exposure를 감소시킬 수
있었습니다.
그러나 Mitigation은 Remediation과 동일하지 않습니다.
Temporary Measure는 Permanent Fix가 아니라 Patching이 완료될 때까지의 Bridge로
취급해야 합니다.
Step 4: 지원이 종료된 Log4j 1.x 폐기
Log4j 1.x는 별도의 문제입니다.
Log4j 1.x는 End-of-Life 상태이며 장기적인 대안으로 안전하게 사용할 수 있는 것으로
취급해서는 안 됩니다.
여전히 Log4j 1.x를 사용하는 조직은 Production System 내부에서 지원되지 않는 Software에
의존하기보다 지원되는 Logging Framework로 Migration하는 계획을 수립해야 합니다.
이 작업은 단순 Version Bump보다 시간이 오래 걸릴 수 있습니다.
다음 작업이 필요할 수 있습니다.
● Code Change
● Dependency Change
● Testing
● Compatibility 작업
그러나 Production 환경에서 지원되지 않는 Logging Infrastructure를 계속 유지하는 것은
장기적인 Risk를 발생시킵니다.
Step 5: Rebuild, Redeploy 및 Verify
Dependency File을 Update하는 것만으로는 충분하지 않습니다.
Patched Dependency가 실행 중인 Application까지 실제로 반영되어야 합니다.
이를 위해 다음이 필요합니다.
● Artifact Rebuild
● Service Redeployment
● Container Image Update
● Vulnerable Package 교체
● 필요한 경우 Application Restart
● Production에서 실제 Fixed Version이 실행되고 있는지 검증
이 단계에서 Team이 자주 문제를 놓칩니다.
Ticket에는 “Patched”라고 표시되어 있을 수 있습니다.
Repository에는 “Updated”라고 표시될 수 있습니다.
Container Registry에도 Fixed Image가 존재할 수 있습니다.
하지만 기존 Workload가 여전히 실행 중일 수 있습니다.
따라서 Verification은 Pipeline뿐만 아니라 Runtime에서 수행되어야 합니다.
Step 6: Exploitation Attempt 모니터링
Patching이 과거의 Exposure를 지워주는 것은 아닙니다.
Team은 다음과 같은 항목을 검토해야 합니다.
● Log
● Outbound Connection
● Process Activity
● DNS Lookup
● 의심스러운 LDAP 또는 RMI Traffic
● 예상하지 못한 Child Process
● 비정상적인 Download
● Persistence Attempt
● Compromise 징후
목표는 별도의 질문에 답하는 것입니다.
“Patch하기 전에 이 Vulnerability가 Exploit되었는가?”
이 조사를 위해서는 Vulnerability Scanner만으로는 부족합니다.
Runtime 및 Application Context가 필요합니다.
Patching만으로 조직이 계속 노출되었던 이유
모든 Security Team은 Patching이 중요하다는 사실을 알고 있습니다.
Log4Shell이 증명한 것은 Patching이 필요 없다는 것이 아닙니다.
Exploitation이 활발하고 광범위하며 Enterprise Remediation Cycle보다 빠르게 진행되는
상황에서는 Patching만으로 충분하지 않다는 것을 증명했습니다.
Log4Shell은 Runtime Prevention이 Patching과 함께 존재해야 한다는 것을
보여주었습니다.
Patching은 Vulnerable Code Surface를 줄입니다.
Runtime Prevention은 실제로 Code가 Remediation되는 동안 발생하는 Live Execution
Window를 보호합니다.
두 가지는 서로 다른 역할입니다.
Scanner는 Log4j가 존재한다는 사실을 알려줄 수 있습니다.
SCA는 Dependency Version이 Vulnerable하다는 것을 알려줄 수 있습니다.
Ticket은 Engineering Team에 Patch 작업이 할당되었다는 것을 알려줄 수 있습니다.
Runtime Prevention은 다른 질문에 답합니다.
“Application은 지금 무엇을 하고 있는가?”
Active Exploitation 상황에서는 이 질문이 특히 중요합니다.
Runtime Prevention은 Application이 실행되는 동안 위험한 Execution Behavior를 관찰할 수
있습니다.
예를 들어 다음과 같은 동작을 확인할 수 있습니다.
● 예상하지 못한 Outbound Connection
● Process Spawning
● Command Execution
● 해당 Code Path에 존재하지 않는 기타 의심스러운 동작
그리고 중요한 것은 단순한 Detection만이 아닙니다.
핵심은 Attribution입니다.
● 어떤 Application이 해당 동작을 발생시켰는가?
● 어떤 Library가 원인이었는가?
● 어떤 Function Path가 관련되었는가?
● 어떤 Container, Image, Pod, Node 또는 Workload가 영향을 받았는가?
● 어떤 Team이 해당 Fix를 담당하는가?
이러한 Context가 없다면 Security Team은 Log, Endpoint Alert, Network Event, Scanner
Output 및 Ticket Data를 서로 연결하면서 공격자가 이미 이동하는 상황에 대응해야 합니다.
Runtime Application Security는 이러한 Gap을 해결합니다.
Raven은 어디에 위치하는가?
Raven은 Runtime에서 Application을 보호하도록 설계되었습니다.
Log4Shell과 같은 Incident에서 Raven은 Security Team이 실제 Production에서 어떤
Vulnerable Library가 존재하고, Load되고, Reachable하며, 실행되고 있는지를 파악하도록
지원합니다.
또한 Runtime Behavior를 다음과 같은 정보와 연결합니다.
● Application
● Library
● Function
● Call Chain
● Container
● Image
● Pod
● Node
● Workload
이러한 Context는 Response 방식을 변화시킵니다.
모든 Vulnerable Package를 동일한 수준의 Risk로 취급하는 대신 실제로 노출된 대상을
우선순위화할 수 있습니다.
모든 Patch가 모든 Pipeline을 통과할 때까지 기다리는 대신 Remediation Window 동안
Application을 보호할 수 있습니다.
단순히 Process 또는 Network Event만 보는 것이 아니라 해당 Event를 발생시킨
Application Code Path를 이해할 수 있습니다.
Log4Shell은 Patching Crisis였습니다.
그러나 동시에 Runtime Crisis이기도 했습니다.
Raven은 바로 이 Gap을 해결하기 위해 설계되었습니다.
결론: Log4j를 Patch하되, 거기서 멈추지 마십시오
Log4Shell에 대한 올바른 대응은 항상 Patching이었습니다.
Vulnerable Log4j Version을 찾고,
지원되는 Fixed Version으로 Upgrade하고,
즉시 Upgrade가 불가능한 경우 Unsafe Component를 제거하고,
지원이 종료된 Log4j 1.x 사용을 폐기하고,
Rebuild, Redeploy 및 Verify해야 합니다.
그러나 Log4Shell은 동시에 다음과 같은 사실을 분명하게 보여주었습니다.
Patching은 즉시 이루어지지 않습니다.
Visibility는 완전하지 않습니다.
Vendor Timeline은 항상 빠르지 않습니다.
Transitive Dependency는 찾기 어렵습니다.
Production System은 스스로 Update되지 않습니다.
그리고 공격자는 그 Gap 동안 움직입니다.
AI는 이러한 Gap을 더욱 위험하게 만들고 있습니다.
AI는 공격자가 다음 Vulnerable Open-Source Package를 더 빠르게 찾고, Exploit Path를 더
빠르게 생성하며, 대부분의 Team이 Inventory를 구축하고, Test하고, Patch하고,
Redeploy하는 것보다 빠르게 Payload를 변경하도록 도울 수 있습니다.
따라서 Exploit되기 전에 모든 Vulnerable Dependency를 찾아 Patch하는 것만으로는 확장
가능한 방어 모델이 될 수 없습니다.
그렇기 때문에 Runtime Prevention이 중요합니다.
Security Team은 여전히 Patch해야 합니다.
동시에 Patching이 진행되는 동안에도 보호가 필요합니다.
그리고 Patching이 진행되는 동안에도 보호가 필요합니다.
Log4Shell이 증명한 것은 바로 이 Layer가 기존 보안 체계에서 빠져 있었다는 것입니다.
https://softwidesec.com/raven
Raven에 관련된 소개자료 및 데모요청은 소프트와이드시큐리티로 연락바랍니다.