11월 패치 화요일(Patch Tuesday)에 대한 Akamai의 관점

Windows 스크립팅 언어

Windows 스크립팅 언어는 Windows 내에서 VBScript, 자바스크립트 등의 여러 스크립트 언어 구현을 참조할 수 있습니다. Microsoft는 이번 릴리스에서 JScript와 Chakra의 두 가지 스크립팅 엔진에 패치를 적용했습니다.

JScript는 Microsoft에서 ECMAScript를 구축한 것으로, 자바스크립트에 적용된 표준과 같으며 Internet Explorer에서 사용됩니다. Chakra 또한 JScript에서 파생된 자바스크립트 엔진이며 Microsoft Edge Legacy에서 사용됩니다(최신 버전의 Edge는 Chromium 기반). 두 가지 모두 DLL로 구축되며, 각기 간단하게 jscript9.dll과 chakra.dll이라는 이름이 붙어 있습니다.

이번 업데이트는 이 두 스크립팅 엔진에 영향을 주는 두 가지 심각한 원격 코드 실행 취약점을 해결합니다.

첫 번째, CVE-2022-41128는 JScript9 스크립팅 언어에 영향을 주며 CVSS 점수는 8.8이고 위험(Critical)으로 분류되었습니다. 공격 복잡성이 낮을 뿐만 아니라 공공연히 악용되는 경우가 발견되었습니다. 취약점을 성공적으로 악용하려면, 공격자는 특수하게 조작된 서버 공유 또는 웹 사이트를 호스팅해야 합니다. 그런 다음 공격자는 영향을 받는 Windows 버전을 사용하는 사용자가 특수하게 조작된 서버에 접속하도록 유도해야 합니다. 

두 번째 취약점인 CVE-2022-41118은 JScript9와 Chakra에 모두 영향을 주며 CVSS 점수는 7.5이고 위험(Critical)으로 분류되었습니다. 이번에는 공격 복잡성이 높습니다. 공격자가 경쟁 상황에서 승리하는 것을 조건으로 하기 때문입니다. 공격 흐름과 사용자 상호 작용은 CVE-2022-41128과 유사합니다.

일반 권장 사항

JScript 및 Chakra 엔진은 Internet Explorer 및 Edge Legacy용으로 개발되었습니다. 최신 웹 브라우저(Chromium 기반 Edge 포함)가 존재하므로, 이 중 하나를 사용하는 것을 추천합니다. 그러나 다른 소프트웨어에서도 위 엔진을 사용할 수 있으므로 이러한 취약점으로부터 컴퓨터를 보호하는 유일한 방법은 패치를 적용하는 것임을 유의해야 합니다.

CVE

Windows Kerberos

Kerberos는 Windows 도메인 아키텍처의 중추 역할을 합니다. 기본 인증 메커니즘으로, NTLM을 대체했습니다. 이번에는 권한 상승에 사용할 수 있는 취약점 두 가지가 수정되었으며, 각기 CVSS 점수는 8.1과 7.2입니다. 

패치 적용과 별도로, 시스템 관리자는 Microsoft에서 레지스트리(registry)에 필요한 변경 사항에 관련해 릴리스한 KB(KB5020805, KB5021131) 두 건을 확인하시길 바랍니다.

영향

이 취약점 악용에 성공한 공격자는 관리자 권한을 얻을 수 있습니다.

취약점 위치

CVE-2022-37966

이 패치 이전에는 RC4-MD5가 Kerberos 협상의 기본 암호화에 사용되었습니다. RC4는 스트림 암호 암호화입니다. 즉, 일반 텍스트에 암호 스트림을 XOR해 암호문을 만드는 겁니다. John the Ripper와 같은 툴을 사용하면 오프라인에서 쉽게 해독할 수 있으므로 약하다고 간주합니다. 취약점은 바로 이 기본 설정에 있습니다.

공격자는 Active Directory와 협상할 때 Kerberos의 기본 인증을 사용하는 특수하게 조작된 요청을 보낼 수 있습니다. 요청이 성공한 후, 공격자는 Kerberos 세션 키를 악용해 해독하고 권한 상승에 사용할 수 있습니다.

Kerberos 협상의 기본 설정은 레지스트리 키 ms-DS-SupportedEncryptionType을 통해 수정되며, 이 레지스트리 키는 기본적으로 AES 암호화(0x27)로 설정됩니다.

CVE-2022-37967

이 취약점은 Kerberos의 Privilege Attribute Certificate(PAC) 확장 프로그램에 있습니다. 기본적으로 PAC는 사용자 ID, 그룹 ID, 계정 도메인 ID 및 그 외다양한 필드에 대한 정보 '컨테이너'입니다. PAC 정보는 도메인 컨트롤러에 의해 Kerberos 티켓에 추가됩니다. 

Microsoft가 해당 CVE에 대응해 릴리스한 KB 를 봤을 때, 이 취약점을 악용해 서버로 전송되는 PAC 시그니처의 유효성 검사를 우회할 수 있다고 생각됩니다. 즉, 유효하지 않거나 누락된 시그니처를 사용해 보낸 PAC 구조가 유효성 검사 프로세스를 우회하고 권한 상승으로 이어질 수 있습니다.

이 패치는 CVE-2022-37067에 대한 단계별 릴리스의 첫 번째 단계입니다. CVE-2022-37967에 대한 해결책이 포함되어 있지만, 기본적으로 비활성화되어 있습니다. 다음 단계는 2022년 12월 13일부터  2023년 10월 10일까지로 계획되어 있으며, 각각 감사와 부분 시행을 가능하게 할 것입니다.

CVE-2022-37967의 경우,  패치는 레지스트리  키 KrbtgtFullPacSignature에 값 2를 추가합니다. 이 값을 사용하면 시스템에서 PAC을 감사할 수 있으며 시스템 관리자는 이 값을 사용해 비정상적인 동작을 추적할 수 있습니다.

키 KrbtgtFullPacSignature에는 불량 또는 누락된 PAC 시그니처를 적용하거나 거부할 수 있는 옵션이 있어 이 취약점을 처리할 수 있습니다.

범위

Kerberos는 모든 Windows 도메인 아키텍처의 일부입니다.

CVE

Netlogon RPC 

여기에서 Netlogon Remote Protocol은 Windows 도메인 환경에서 사용자와 컴퓨터 인증에 사용하는 프로토콜입니다. 도메인 컨트롤러 간의 동기화에도 사용합니다. 따라서 Windows 도메인 네트워크에서 큰 영향력을 갖기 때문에, CVE-2022-38023 이 대부분 환경에 영향을 줄 수 있습니다.

영향

공격자는 이 취약점을 악용해 도메인에서 관리 권한을 얻을 수 있습니다.

취약점 위치

Microsoft가 CVE에 대응해 릴리스한 KB 에 근거하면, CVE는 Netlogon 연결이 RPC 봉인이 아니라 RPC 서명으로 발생하는 경우와 관련이 있는 것으로 보입니다. RPC 서명의 경우, 발신자만이 RPC 메시지에 서명하며, 수신자는 무결성을 확인하기 위해 메시지 내용과 서명의 일치 여부를 확인합니다. 그에 반해 RPC 봉인은 전체 메시지를 암호화합니다.

앞서 언급한 관련 이벤트 로그(시스템 이벤트 로그의 이벤트 ID 5838–5841)를 고려하면, 취약점은 시그니처의 잘못된 처리 또는 확인과 관련된 것으로 보이며, 특히 RC4-HMAC 암호화 처리와 관련이 깊은 듯합니다.

일반 권장 사항

이 패치는 단계별 릴리스의 첫 번째 단계입니다. CVE를 수정하고 RPC 봉인을 적용하는 데 사용되는 새로운 레지스트리 키 RequireSeal을 도입했습니다. 첫 번째 단계의 일부인 레지스트리 키는 기본적으로 호환성 모드로 설정되지만, 도메인 관리자가 비활성화할 수 있습니다. 호환성 모드에서는 도메인 컨트롤러가 써드파티 클라이언트의 취약한 연결을 허용할 수 있지만, Windows 컴퓨터 및 도메인 컨트롤러에는 RPC 봉인을 적용합니다.

다음 단계는 2023년 4월 11일과 7월 11일로 계획되어 있으며, 각기 적용을 비활성화하는 옵션과 호환 모드를 제거할 것입니다.

도메인 관리자는 패치 적용 후 새로운 적용을 비활성화하지 않고 RPC 서명을 사용하는 클라이언트를 업그레이드하는 것이 좋습니다. 이러한 문제를 즉시 해결할 수 없고 RPC 서명을 반드시 허용해야 하는 경우, 최소한 기존 레지스트리 키 RejectMD5Clients를 사용해 약한 md5 서명을 사용하지 않도록 설정하는 것이 좋습니다.

CVE

기존 지원 서비스

이번 달 패치 화요일에 많은 CVE가 포함되었기 때문에 모든 CVE를 다룰 수는 없습니다. 이러한 CVE 중 일부는 지난 패치 화요일 분석에서 이미 다룬 서비스와 기능을 대상으로 합니다. 이러한 서비스에 대한 분석 또는 일반적인 권장 사항에 관심이 있으신 경우, 이전 게시물을 확인해 보시기 바랍니다.

본 요약에서는 가용한 정보를 바탕으로 현재 이해와 권장 사항을 대략 알아봤습니다. Akamai의 검토는 지속적으로 수행되므로 이곳의 모든 정보는 변경될 수 있습니다.

 최신 보안 리서치 내용을 찾고 있다면 Twitter에서 Akamai를 팔로우하세요!