보안 사고 사후 분석(포스트모템) —— 엔지니어링 팀을 위한 근본 원인 분석 및 완화 청사진.
flawopen.com/보안 사고/Log4Shell
Log4Shell: 로그 파일에 문자열을 남기던 기능이 원격 코드 실행이 된 이유
쉬운 설명 (ELI5)
사무실 방문객의 말을 공책에 받아 적는 서기가 있습니다. 그런데 방문객이 특정 주소가 담긴 문장을 말하면, 서기가 필기를 멈추고 그 주소로 달려가 낯선 이에게 밀봉된 편지를 받아 그 안의 지시를 그대로 수행한다는 사실이 드러났습니다. 서기는 오직 기록만 해야 했으며 실행을 해서는 안 되었습니다.
The lessons that actually transfer
- ✓Template and data must stay separate. This is the same principle behind parameterised SQL queries and safe HTML templating. Log4Shell is what happens when a library quietly interpolates the data side.
- ✓Features reachable from untrusted input are attack surface, however benign they look. Nobody logged a bug saying "our logger can load remote classes" — it was an emergent property of two reasonable features meeting.
- ✓You cannot patch what you cannot inventory. The hardest part of Log4Shell for most organisations was not applying the fix — it was discovering which of their applications bundled Log4j transitively. This is the strongest argument in recent memory for maintaining a software bill of materials.
- ✓Restrict outbound network egress from application servers. Exploitation depended on the victim server making an outbound connection to the attacker. Default-deny egress broke the chain even on unpatched systems.
- ✓Expect the first patch to be incomplete. 2.15.0 was not sufficient; two further CVEs followed. When a flaw is this structural, treat the first release as the start of remediation rather than the end.
FAQ
Was Log4j 1.x affected?
Log4j 1.x did not contain the message-lookup feature that caused CVE-2021-44228. However, 1.x reached end of life in 2015 and carries its own unpatched issues, so it is not a safe destination — the correct move is forward to a current 2.x release.
Were the mitigation flags a real fix?
Early guidance circulated several stopgaps, including setting formatMsgNoLookups. These reduced exposure but were incomplete in some configurations and versions. Upgrading was, and remains, the reliable answer.
Related reading
출처 및 공식 보안 권고