
잘 알려진 공격을 분류하고 보안 팀이 신속하게 대응하는 방법을 배우는 것이 목표입니다.
이 실습의 목표는 또 다른 잘 알려진 실제 취약점인 Log4Shell을 트라이지하는 것이었습니다. Log4Shell은 영향을 받는 라이브러리가 엔터프라이즈 소프트웨어 전반에 걸쳐 매우 흔했기 때문에 최근 몇 년간 가장 널리 악용된 취약점 중 하나입니다.
National Vulnerability Database(NVD)에 접속하여 CVE를 검색했습니다:
https://nvd.nist.gov/vuln/search#/nvd/home?resultType=records
CVE-2021-44228을 검색하고 결과 페이지를 열었습니다.
설명을 읽은 후, 실제로 무엇이 위험에 처해 있는지 이해하기 위해 몇 가지 기본 질문에 답했습니다:
페이지에 나열된 CVSS 점수와 벡터 문자열을 확인했습니다:
벡터 문자열을 하나씩 살펴보며 각 부분이 실제로 무엇을 의미하는지 확인했습니다:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
이 벡터 문자열은 사실상 최악에 가깝습니다: 필요한 권한이 없고, 사용자 상호작용이 없으며, 네트워크를 통해 도달 가능하고, 취약한 구성 요소 자체 외부에 있는 대상에도 영향을 미칠 수 있습니다(범위: 변경됨). 이러한 조합이 Log4Shell이 공개되었을 때 매우 긴급하고 광범위한 이슈로 취급된 이유 중 하나입니다.
이 CVE에 대한 NVD 페이지의 Weakness Enumeration 섹션을 확인했습니다.
나열된 CWE는 CWE-917: 표현식 언어(Expression Language) 문에 사용되는 특수 요소의 부적절한 중화입니다. 쉽게 말하면, 소프트웨어가 입력을 제대로 검사하지 않고 이를 표현식의 일부로 평가한다는 뜻이며, 이로 인해 공격자가 일반 로그 메시지를 통해 악성 JNDI 조회를 몰래 주입할 수 있었습니다.
두 가지 서로 다른 시나리오에서 이 취약점을 더 높은 위험 또는 더 낮은 위험으로 취급할지 고려했습니다.
시나리오 1: 취약한 소프트웨어가 실행 중이며 접근 가능한 경우. 더 높은 위험입니다. 이 취약점은 공격자가 EL(Expression Language) 문에 접근하고 수정할 수 있게 하여 기밀성과 무결성에 직접적인 영향을 미칩니다.
시나리오 2: 취약한 소프트웨어가 전원이 꺼져 있고 접근할 수 없는 시스템에 설치된 경우. 더 낮은 위험입니다. 취약한 소프트웨어에 전혀 접근할 수 없다면, 공격자가 상호작용할 방법이 없으므로 기밀성과 무결성은 그대로 유지됩니다.
지금까지 트라이지한 CVE 중에서 이 CVE는 특히 눈에 띄었습니다. 공격자가 악용하는 데 필요한 것이 권한도, 사용자 상호작용도 없이 네트워크 접근뿐일 정도로 적었고, 게다가 취약점이 구성 요소 자체를 넘어 시스템에 영향을 미칠 수 있었기 때문입니다. 이는 Log4Shell이 공개되었을 때 업계 전반에서 광범위한 혼란이 발생한 이유를 잘 보여주는 사례입니다.