사고 & 취약점
Log4Shell(CVE-2021-44228) — 자신이 그 버그를 가졌는지조차 확인할 수 없어 전 세계가 두려워한 밤
2021년 12월 Log4j에 CVSS 10.0 RCE가 있었습니다. 진짜 공포는 자신도 모르게 쓰던 라이브러리를 통해 영향을 받는 것(전이 의존성)이었습니다. 로깅이 어떻게 공격 벡터가 되었는지, 그리고 SBOM·머신 모니터링·빠른 패치라는 교훈을 다룹니다.
한 획을 그은 사건을 되짚습니다 — 공격을 재현하기 위해서가 아니라, 여전히 여러분의 운영에 적용되는 교훈을 위해.
무슨 일이 있었나 — 수동적 경로가 공격 벡터가 되다
Log4j는 로그를 기록하는 평범한 작업을 처리했고, Java 세계에서 사실상 어디에나 있었습니다. 결함은 이것입니다: 이 라이브러리가 기록되는 문자열 안의 특정 패턴을 "외부로 손을 뻗어 해석할 것"으로 처리해, 결국 외부에서 지정한 코드를 실행하고 만 것입니다.
그래서 "기록되는 어딘가"(사용자 이름, 헤더)에 조작된 문자열을 넣은 공격자는 코드 실행에 도달할 수 있었습니다. 로깅이라는 수동적 행위가 공격 경로가 된다는 충격은 깊었습니다.
왜 "우리는 영향을 받는가?"에 답하기가 그토록 어려웠나
대부분의 앱은 Log4j를 직접 설치한 적이 없었습니다. 프레임워크나 SDK가 끌어온 것 — 전이 의존성, 즉 의존성의 의존성의 의존성이었습니다. 자신의 "자재 명세서"가 없으면 영향 여부조차 알 수 없었습니다.
가장 무서웠던 건 '알 수 없다'는 점이었다
"쓰는지 알 수 없을" 때는 대응의 우선순위조차 정할 수 없습니다. 자재 명세서(SBOM)를 보유했는지 여부가 그날 밤의 향방을 갈랐습니다.
타임라인
2021-12-09–10
결함이 널리 알려지고, 전 세계가 "우리는 영향을 받는가?" 확인에 분주해짐.직후
긴급 패치와 임시 완화책이 쏟아지고, 악용 시도가 급증.이후
여러 후속 CVE(수정에 대한 수정)가 공개됨 — "한 번 고쳤다"가 끝이 아니었음.
여전히 적용되는 교훈
SBOM(자재 명세서)을 갖춘다
여러분의 앱이 내부적으로 무엇을 쓰는지 가시화하십시오 — npm ls / 락파일 / SBOM 도구가 실제로 동작 중인 것을 보여줍니다. "직접 설치한 것"만 보는 것으로는 부족합니다.
의존성을 기계로 모니터링한다
CVE가 공개되는 순간, 전이 의존성을 포함해 그것이 적용되는지 자동으로 알 수 있게 하십시오(Dependabot / osv-scanner). 수동 순찰은 늘 놓칩니다.
패치를 빠르게 한다
"업그레이드하고, 검증하고, 배포하는" 근육을 비상시를 위해 늘 풀어 두십시오. 의존성 모니터링 구축하기를 참고하십시오.
후속 CVE를 추적한다
Log4Shell 이후 수정에 대한 수정이 나타났습니다. "한 번 고쳤다"에서 멈추지 말고 후속을 추적하십시오.
이어서 읽기
FAQ
QLog4Shell의 공포에서 '새로운' 점은 무엇이었나요?
전이 의존성의 위험을 전 세계 규모로 드러냈습니다. 직접 설치하지 않았더라도 다른 라이브러리 안에서 쓰이는 라이브러리를 통해 취약해지는 것입니다. SBOM을 모르면 자신이 영향을 받는지조차 알 수 없었습니다.
Q왜 로깅이 공격 벡터가 되었나요?
Log4j는 기록되는 문자열 안의 특정 텍스트를 '외부로 손을 뻗어 해석할 것'으로 처리했습니다. 공격자는 기록되는 어딘가(사용자 이름, HTTP 헤더)에 조작된 문자열을 넣기만 하면 되었고, 그것이 수동적인 로깅 경로를 코드 실행으로 바꾸었습니다.
Q반복을 피하려면 어떻게 해야 하나요?
세 가지입니다. 의존성을 기계로 모니터링하고(Dependabot/osv-scanner), SBOM을 생성해 실제로 무엇을 쓰는지 파악하며, 빠르게 패치할 만큼 신속한 업데이트 프로세스를 운영하는 것 — 그리고 후속 CVE(수정에 대한 수정)를 추적하는 것입니다.