메모리 손상 취약성을 넘어 - 보안 소멸 및 악용의 미래

저자: Chintan Shah · 2022년 1월 24일

최신 악용 기법은 공격자가 공격 전략을 실행하는 방법과 방어자가 취약성에서 악용까지의 경로를 분석하는 방법에 변화를 가져왔습니다. 지난 10년 동안 당사는 전체 운영 체제와 애플리케이션 모두에서 보안의 강화에 확고하게 집중하여 몇 가지 익스플로잇 완화를 도입하는 데 주목할 만한 진전을 이루었습니다. 이러한 진전 덕분에 몇몇 경우에 전체 클래스의 메모리 손상 취약성이 점진적으로 제거되었습니다. UAF(Use-After-Free)는 예를 들어 웹 브라우저와 같은 대규모 복합 코드 기반에서 매우 일반적인 취약성 클래스입니다. 악용의 용이성 때문에 Microsoft는 자체 브라우저 엔진(mshtml.dll)에서 아이솔레이티드 힙 및 지연된 객체 할당 해제 기능을 도입하여, UAF 악용 고리를 끊고 공격자가 익스플로잇을 재설계하여 이러한 장벽을 해결하도록 만들었습니다. 아래의 그림 1은 UAF 취약성을 완화하기 위해 도입된 코드 부분을 보여줍니다.

보호된 코드와 보호되지 않은 코드의 차이점을 알 수 있습니다. 이것은 빙산의 일각에 불과했지만, 공격자가 특정 타이밍 제약과 메모리 임계값도 해결해야 했기 때문에 UAF 취약성을 악용하기가 매우 어려웠습니다. 아래의 그림 2는 지난 10여 년 동안 도입된 Windows OS 메모리 익스플로잇 완화를 간단하게 시각화한 것입니다.

그러나 이러한 익스플로잇 완화가 도입된 후 짧은 기간 내에 바이패스되는 경우가 자주 발생했습니다. 그 주요 이유는 타사 종속 코드를 포함한 모든 코드가 호환되는 것은 아니었고, 컴파일러에서 완화 기능이 작동되는 상태에서 컴파일되지는 않았기 때문입니다. 이것은 본질적으로 익스플로잇 완화가 코드의 모든 부분에 적용되지 않았거나 완화 자체가 완전히 구현되지 않아서 악용될 수 있는 여러 허점을 남겼음을 의미합니다. 예를 들어, 위의 시각화에서 살펴보면 주소 공간 레이아웃 임의화(ASLR)가 처음에 전체적으로 구현된 것이 아니라 오히려 단계적으로 구현되어 많은 코드가 여전히 바이패스에 취약하다는 것을 알 수 있습니다.

메모리 손상 취약성 - 이것은 과거의 일이 될까요?

메모리 손상 취약성은 계속해서 가장 널리 보고되는 버그 클래스이지만, OS와 클라이언트 측 애플리케이션(예: 스크립팅 엔진)에 도입된 익스플로잇 완화로 인해 최근 몇 년 동안 이를 본격적인 무기화된 익스플로잇으로 변환하는 것은 어려운 일이 되었습니다. 메모리 손상 취약성을 임의 코드 실행으로 이어지는 전면적인 익스플로잇으로 전환하려면 엔드포인트 보안 솔루션 보호 또는 탐지를 트리거하지 않고 여러 완화를 바이패스해야 합니다. 이는 이제 공격자가 익스플로잇 완화 바이패스를 연구하기 위해 노력, 시간, 비용에 상당한 투자를 해야 함을 의미합니다. 여러 경우에 공격자는 대상 시스템에서 작동하는 익스플로잇을 실행하기 위해 여러 취약성을 연결해야 할 수도 있으며, 이에 따라 개발 비용이 크게 증가하여 악용의 난이도가 높아집니다.

이러한 악용 완화의 진화는 향후 공격자들이 관심을 갖게 될 취약성 클래스의 특성을 형성하는 데 매우 중요한 역할을 할 것입니다. 다음의 질문, "메모리 손상 취약성이 사라질 것인가?"는 논쟁의 여지가 있으며 어느 정도의 성찰이 필요합니다.

미래의 악용 전략 - 앞으로 어떤 일이 펼쳐질까요?

애플리케이션에 메모리를 잘못 처리하는 일부 코드가 있는 한 메모리 손상 취약성은 애플리케이션에 계속 존재하겠지만, 이러한 취약성 클래스의 악용 강도와 빈도는 결국 수그러들 것입니다. 과거에는 공격자가 메모리 손상 결함을 악용하고 해당 프리미티브를 사용하여 애플리케이션 메모리의 특정 플래그 또는 데이터를 변경해 코드 실행을 유도함으로써 임의의 메모리 R/W(읽기/쓰기)를 구현하는 여러 악용 기법 사례가 있었습니다. "data only attacks"(데이터 전용 공격)라는 코드명을 가진 이러한 종류의 방법은 많은 익스플로잇에서 볼 수 있는 비교적 쉬운 전략이었습니다. 메모리의 중요한 특정 데이터 구조 위치를 궁극적으로 무작위로 지정하면서 시간이 지남에 따라 이러한 공격 특성이 감소했습니다.

기능이 풍부한 애플리케이션의 경우 공격자는 대상 시스템에서 코드를 실행하기 위한 좀 더 쉬운 전략을 항상 모색할 것입니다. 인터넷에 노출된 레거시 시스템 중에는 완화 기능이 도입되지 않아서 공격자에게 저항이 거의 없는 경로를 제공하는 시스템이 항상 있습니다. 그러나 이 방향으로 나아가는 방법 중 하나는 애플리케이션 또는 네트워크 프로토콜에서 기능이나 설계 결함을 남용하는 것입니다. 공격자가 대상 애플리케이션의 고유한 설계나 기능을 남용하는 방법을 결정할 수 있는 경우(예: 메모리를 명시적으로 조정하지 않은 채 애플리케이션이나 서비스를 공격자가 제어하는 시스템에 연결) 원격 코드 실행을 더 쉽게 구현할 수 있으며 이와 동시에 대상 시스템에 대혼란을 일으킬 수 있습니다. 익스플로잇 프로세스에서 실행되는 임의 코드의 기능이 전적으로 공격자의 상상력에 달려 있기 때문입니다. 아래의 그림 3은 지난 몇 년간 진행된 악용 전략의 진행 상황을 간략하게 보여줍니다.

지난 몇 년간 데이터 전용 공격과 애플리케이션 기능/설계 결함의 남용이 여러 차례 목격되었습니다. 이들은 기존의 메모리 손상 익스플로잇에 비해 여러 이점을 제공하는데, 이것이 미래의 익스플로잇 전략이 될 것이라고 생각하는 데에는 다음과 같은 몇 가지 이유가 있습니다.

• 잠재적으로 익스플로잇 완화를 바이패스할 수 있으므로 공격자는 이러한 장벽을 해결하기 위해 특별히 익스플로잇을 설계할 필요가 없습니다.
• 임의 코드는 익스플로잇 프로세스의 권한으로 실행되므로 권한 상승에 도움이 됩니다.
• 애플리케이션의 내장 기능이나 설계 결함을 이용하는 익스플로잇은 취약성이 악용되기 전에 명시적인 메모리 조작 및 공간 제약을 처리할 필요가 없습니다. 그 결과 메모리에 셸코드 주입하기와 오래된 스택 피벗 기법이 제거됩니다.
• 개발/유지 관리 비용과 무기화 시간이 덜 들기 때문에 상대적으로 악용이 더 수월합니다.

지난 몇 분기 동안의 중요한 취약성을 돌아보면 미래의 공격이 어떻게 이루어질지에 대한 결정적 단서를 얻을 수 있습니다. 다음 섹션에서는 가장 최근에 큰 영향을 미친 몇 가지 취약성을 살펴보고 서비스 또는 애플리케이션에서 기능 또는 설계 결함이 어떻게 남용되어 최소한의 저항으로 코드 실행 또는 중요한 정보 유출로 이어졌는지 알아보겠습니다.

CVE-2021-44228 – Apache Log4j2 로깅 라이브러리 취약성이 원격 코드 실행으로 이어짐

Apache의 Log4j 로깅 라이브러리에서 보고된 이 RCE 취약성은 최근 몇 년간 보고된 가장 중요한 결함 중 하나로, Log4j 로깅 라이브러리를 사용하여 문자 메시지를 로그하는 취약한 서버에서 공격자가 임의 코드를 실행할 수 있도록 허용했습니다. 이전 블로그에서는 공개 소스 소프트웨어가 최근 소프트웨어 개발에서 어떻게 빌딩 블록 역할을 하는가와 취약성이 사용 제품에 상당한 영향을 미치므로 이를 감사하는 것이 얼마나 중요한지 자세히 설명했습니다.

취약성은 "jndimanager" 클래스의 "Lookup" 메서드에 있습니다. When the JNDI URL is included in the request message parameter to be logged by log4j, the apache\logging\log4j\core\lookup\JndiLookup.lookup () method is called with the JNDI URL which in turn calls the net\JndiManager.lookup () method as shown in figure 3 below, leading to the initiation of the remote JNDI lookup to the attacker controlled server. 그러면 공격자가 제어하는 서버는 취약한 서버에서 실행되는 임의 코드에 대한 응답으로 악의적인 JNDI 참조를 보낼 수 있습니다.

이 RCE는 Java가 LDAP, DNS, RMI, CORBA 같은 다양한 JNDI(Java Naming Directory Interface) 서비스 공급자를 구현하기 때문에 가능했습니다. 기본 시스템 속성 집합에 따라 원격 클래스를 로드하는 것도 가능했습니다.

CVE-2021-44228은 기능 악용의 전형적인 예입니다. 여기에서 남용된 기능은 조회를 지원하는 조회 대체였습니다. 조회는 정의된 맵을 사용하여 확인되거나 StrSubstitutor 및 StrLookup 클래스 같은 구현된 인터페이스를 통해 런타임에 확인되는 변수 이름인 로그 메시지에 값을 추가하는 방법입니다.

Log4j는 속성 구문 "${prefix:name}"을 지원합니다. 여기서 접두사는 변수 이름이 특정 컨텍스트에서 평가되어야 하는 Log4j를 나타냅니다. JNDI 컨텍스트는 아래와 같이 Log4j에 내장되어 있습니다.

JNDI 조회는 Log4J 버전 2.14.1 이하에서 기본적으로 활성화되었으므로(위의 그림 6 참조) 라이브러리는 서버에 기록된 HTTP 요청 헤더의 매개 변수 값으로서 전달된 JNDI 참조를 식별할 수 있습니다. 따라서 공격자는 HTTP 요청 매개 변수에 악성 JNDI 참조를 삽입하여 원격으로 Java 코드를 실행할 수 있습니다.

CVE-2021-34527 – Windows 인쇄 스풀러 서비스 취약성이 원격 코드 실행으로 이어짐

spoolsv.exe의 권한 있는 원격 코드 실행 취약성인 PrintNightmare는 작년에 보고된 또 다른 중요한 취약성으로, 프로토콜의 설계 결함을 남용하여 메모리에서 작동하지 않고도 대상 시스템에서 임의 코드를 실행하는 방법을 보여주는 좋은 예입니다.

SMB를 통해 RPC를 호출하여 Print System Remote Protocol(MS-RPRN) 및 Print System Asynchronous Remote(MS-PAR) 프로토콜을 통해 취약성이 악용되었습니다. 이 익스플로잇은 대상 시스템에 프린터 드라이버를 설치하기 위해 MS-RPRN 및 MS-PAR 인터페이스에 대한 RPC 요청이 이루어질 때 스풀러 서비스의 인쇄 서버 구성 요소 구현에 있는 전형적인 설계 결함을 이용합니다. RpcAddPrinterDriverEx(MS-RPRN Opnum 89) 또는 RpcAsyncAddPrinterDriver(MS-PAR Opnum 39)에 대해 RPC 호출을 수행하려면 DRIVER_CONTAINER 구조를 인수로서 전달해야 합니다.

위의 구조 세부 정보에 나와 있듯이 DRIVER_CONTAINER에는 각각 프린터 드라이버와 구성 모듈이 포함된 파일 이름의 전체 경로인 pDriverPath 및 pConfigFile이 포함되어 있습니다. 임의 코드가 로드되지 않도록 pDriverPath와 pConfigFile 모두 UNC 경로에 대해 검사됩니다.

여기에서 코드의 설계 또는 논리 결함은, 동일한 UNC 경로 검사가 프린터 데이터를 포함하는 파일의 전체 경로인 pDataFile에 적용되지 않는다는 것입니다. 공격자는 다음을 사용하여 RpcAddPrinterDriverEx를 여러 번 호출할 수 있습니다.

1. pDataFile을 대상 시스템에 액세스할 수 있는 악성 DLL의 UNC 경로로 사용하며, 성공할 경우 악성 DLL을 대상 시스템에 로컬로 복사합니다.
2. pConfigFile에 할당된 복사된 파일 이름과 동일한 API를 사용하며(이때 악성 DLL이 로컬 경로가 됨), 인쇄 스풀러 서비스에 의해 악성 코드가 로드됩니다.

CVE-2021-36942 - Windows의 LSA Spoofing 취약성이 자격 증명 유출로 이어짐

SMB를 통한 RPC는 많은 악용 방법 중 항상 선두를 차지했었습니다. 이 취약성은 다시 MS-EFSRPC 프로토콜을 남용하여 악용될 수 있습니다. 이 프로토콜은 Windows에서 원격 시스템의 파일을 관리하는 데 사용되며 EFS(Encrypting File System)를 사용하여 암호화됩니다.

공격자는 LSARPC 인터페이스를 통해 EfsRpcOpenFileRaw 같은 특정 RPC 호출을 수행함으로써 하나의 Windows 호스트가 다른 서버에 인증되도록 할 수 있습니다. 이는 본질적으로 대상 서버가 NTLM 인증을 통해 공격자가 제어하는 서버에 인증하도록 만들 수 있음을 의미합니다. 더 중요한 것은 사전 인증 없이 RPC 호출을 사용하여 LSARPC를 발급할 수 있다는 것입니다. 이 대상 서버가 AD(Active Directory)인 경우 공격자는 NTLM 인증을 위해 컴퓨터 계정을 사용하여 AD를 임의의 서버에 연결할 수 있습니다. 이 EFSRPC 프로토콜은 공격자가 제어하는 서버에 NTLM 자격 증명을 전달하기 위해 엔터프라이즈 네트워크 내의 여러 취약성을 연결하는 데 남용될 수 있습니다. 이는 측면 이동을 수행하는 데 사용될 수 있으며 결국 완전한 도메인 침투로 이어집니다.

AD CS(Active Directory Certificate Services) 기능이 설치되고 HTTP상의 NTLM 인증을 사용하도록 구성된 IIS 웹 서버를 공격자가 제어하는 경우, IIS에 대해 Active Directory를 인증하도록 하면 NTLM 자격 증명이 공격자에게 유출되어 완전한 도메인 침투가 발생합니다. NTML 릴레이 공격이 새로운 것은 아니지만, 이와 같은 프로토콜 남용을 방지하기 위해 Kerberos 같은 좀 더 안전한 인증 메커니즘을 사용하는 것이 좋습니다.

요약하면, CVE-2021-44228 Log4j 취약성에서 볼 수 있듯이, 프로토콜이나 기능을 남용하여 중요한 자산을 외부 소유의 공격자 서버에 연결할 수 있을 경우 위험한 결과가 발생합니다.

CVE-2021-40444 - Windows MSHTML 취약성이 원격 코드 실행으로 이어짐

이것은 작년에 악용된 또 다른 중요한 취약성이며, 간단한 기능 남용으로 어떻게 논리 결함을 임의 코드 실행과 연결할 수 있는지를 보여주는 좋은 예입니다. 첫째, OLE(Object Linking and Embedding)를 사용하여 문서를 외부 OLE 개체에 연결했습니다. 전에는 OLE가 무기화된 Office 익스플로잇을 구축하는 데 중요한 역할을 했는데, OLE는 상호 운용성을 해결하기 위해 특별히 설계된 Microsoft Office 파일 형식의 핵심 기능 중 하나이기 때문에 이 문제는 계속해서 발생할 것입니다.

Microsoft Office Open XML 사양은 문서가 내부 또는 외부 개체에 포함되거나 링크되도록 하며, 특히 외부 OLE 개체에 대한 링크는 관계를 통해 지정됩니다. 아래의 조작된 익스플로잇 문서에서 볼 수 있듯이 document.xml.rels 파일에서 Type 특성은 "oleObject", Target 특성은 OLE 개체 링크, TargetMode는 External로 설정되어 있습니다. 이렇게 하면 조작된 문서가 외부에서 호스트되는 악성 개체에 연결되고, 개체를 렌더링하기 위해 해당 프로토콜/리소스 처리기를 호출하여 처리기의 잠재적인 논리/설계 결함을 악용할 수 있습니다. 이는 과거 많은 OOXML 익스플로잇에 사용된 전형적인 OOXML 템플릿 주입 기술입니다. 이전 블로그 게시물에서 OLE 익스플로잇을 자세히 살펴보았습니다.

HTML 코드 처리는 mshtml.dll에서 수행되는 반면, HTTP 프로토콜 및 MSHTML 다운로드는 신뢰를 확인하고 urlmon.dll에서 처리됩니다. urlmon.dll 코드의 설계 결함은 다운로드한 CAB 파일의 추출 및 신뢰 확인과 관련이 있었습니다. CAB 파일은 위의 그림 11과 같이 side.html 페이지 내에 포함된 JS(JavaScript) 코드를 통해 다운로드되었습니다. CAB 파일을 추출하는 동안 누락된 경로 이스케이프 검사로 인해 익스플로잇은 아래의 그림 12에 있는 상대 경로를 사용하여 CAB 내에 포함된 파일을 추출할 수 있었습니다. 그 결과, 만들어진 TEMP 디렉터리 외부에 악성 페이로드가 심어졌고 결국 설치된 페이로드가 실행될 수 있었습니다.

결론

지난 몇 년간 내재적 처리 결함을 이용하고 주로 기능을 남용하는, 위에서 설명한 CVE-2021-44228, CVE-2021-34527, CVE-2021-36942, CVE-2021-40444 같은 취약성의 추세가 있었습니다. 안전하지 않은 코드가 Rust 이외의 안전한 비메모리 언어에 존재하는 한 메모리 손상 결함은 계속해서 확산되겠지만, 설계 또는 논리 결함의 악용과 프로토콜 남용의 방향으로 악용 추세가 확실히 이동할 것으로 예상됩니다. 이러한 결함으로 인해 공격자가 최근의 성숙한 메모리 익스플로잇 완화의 심층 방어에 대해 걱정하지 않고 네트워크 내에서 측면으로 이동하는 초기 시스템 수준 목표를 달성할 수 있기 때문에 공개 소스 소프트웨어의 개발자와 소비자는 더욱 경계해야 합니다.