보안정보

전문화된 보안 관련 자료, 보안 트렌드를 엿볼 수 있는
차세대 통합보안관리 기업 이글루코퍼레이션 보안정보입니다.

취약점을 통해 살펴보는 액티브 디렉토리 보안 강화 방안

2022.09.03

6,266

01. Active Directory 개요

마이크로소프트에서 논리적이고 계층적인 디렉터리 정보 구성을 위해 구조화된 데이터 저장소를 통한 분산된 자원들을 중앙에서 관리하기 위한 목적으로 출시된 액티브 디렉토리(Active Directory, 이하 AD)는 대규모 자원들의 접근 관리를 위한 사용자 인증 및 권한 처리를 할 수 있는 서비스라고 할 수 있다. 재택근무 및 대규모 서비스 지원을 위한 서버의 증가로 인해 관리의 복잡성이 증가됨에 따라 단일화된 인증 및 관리가 가능한 AD 사용의 증가는 자연스러운 현상이라고 할 수 있다. 이러한 IT환경의 변화에 따라 공격자들 역시 AD를 타깃으로 하는 공격이 증가하게 되었다. 한국인터넷진흥원(KISA)에서 발간한 ‘TTPs#5 AD 환경을 위협하는 공격 패턴 분석’에 따르면 2019년 발생한 랜섬웨어의 상당수가 AD환경을 이용하는 환경의 미숙한 계정관리 및 관리자 권한 탈취로 인한 문제였다는 점을 통해 AD환경의 보안강화 방안의 필요성을 역설하고 있다.

[그림 1] 최근 10년간 발생한 AD 취약점 유형 별 발생 비율(출처 : MITRE, CVE 2013~2022 상반기 기준)

[그림 1]과 같이 마이터(MITRE)의 CVE(Common Vulnerabilities and Exposure)를 기준으로 2013년부터 2022년 상반기까지 최근 10년간 발생한 AD취약점 51종을 분석해본 결과 5가지의 공격 형태로 분류할 수 있다. 보안 기능 우회 (Security Feature Bypass)가 41%로 가장 높은 비율을 차지했으며 뒤를 이어 Elevation of 권한 상승(Elevation of Privilege), 서비스 거부(Denial of Service), 정보 공개(Information Disclosure), 원격 코드 실행(Remote Code Execution)순으로 취약점이 발견되었다. 발견된 취약점의 절반이상을 차지한 취약점은 보안 기능 우회와 권한 상승으로 XSS 및 응답 우회를 통해 AD의 보안기능을 우회하거나 잘못된 권한으로 인한 서비스 계정 암호 변경 및 케르베로스(Kerberos) 인증 우회 등을 통해 AD 관리자 계정으로 권한상승하여 AD를 제어하는 것으로 나타났다. 이처럼 중앙에서 하위서버들의 인증과 관리를 담당하는 구조적 특성을 이용하여 높은 권한을 가진 그룹 및 디렉토리를 이용하여 최소 권한(Least-Privilege)관리 모델을 우회하는 형태의 공격들이 주를 이루는 것으로 나타났다.

따라서 이번 호에서는 기업 및 조직 보안의 핵심요소인 AD의 보안성 강화를 위해 최근 이슈가 되고 있는 AD 취약점 2종(CVE-2021-42287, CVE-2022-26923)을 분석하여 AD구조 및 권한 설정 방법에 대해서 살펴봄으로써 보다 안전한 AD운영을 위한 최소 기준인 체크리스트를 통해 AD의 안전성을 판단할 수 있는 방안에 대해서 살펴보고자 한다.

02. 취약점 분석을 통한 Active Directory 이해

AD의 보안성 강화방안에 대해서 살펴보기에 앞서 최근 발생한 AD 취약점 2종(CVE-2021-42287, CVE-2022-26923)에 대해서 분석해보고자 한다. 취약점 발표시점이 서로 상이하나 ‘AD Domain Services Elevation of Privilege Vulnerability’이라는 공통점을 가지고 있어서 취약점에 악용되는 속성 및 설정이 유사함에 따라 취약점 설명에 앞서 각 속성 및 설정을 설명하고자 한다. [표 1]은 AD Domain Service에서 사용되는 속성 및 설정 값을 정리한 내용이다.

[표 1] AD Domain Services Elevation of Privilege Vulnerability에서 사용되는 속성 및 설정 값

1) CASE 1 : CVE-2021-42287, KDC 인증 시 권한 상승 취약점

[그림 2] CVE-2021-44287 취약점 발현 시퀀스 다이어그램

[그림 2]는 CVE-2021-42287취약점이 발생되는 과정을 정리한 시퀀스 다이어그램이다. CVE-2021-42287은 사용자가 Kerberos를 사용하지 않고 다른 방식으로 서비스 인증을 하기 위한 방식인 S4U2Self(Kerberos Service-for-User-to-Self)를 이용해 서비스 인증 시도 시 Kerberos를 사용한 것처럼 권한이 부여된 Ticket을 획득 가능한 취약점이다. S4U2Self 과정에서 KDC(Key Distribution Center)에 요청한 Machine Account(sAMAccountName)인 ‘AD-DC-IGLOO’가 AD에 존재하지 않기 때문에 KDC에서는 sAMAccountName인 ‘AD-DC-IGLOO’에 ‘$를 붙여서 TGS(Ticket-granting service)를 발급해주게 된다.

[그림 3]부터 [그림 8]까지의 설명을 통해 CVE-2021-44287취약점 발현 과정을 보다 자세하게 설명해보고자 한다. [그림 3]과 [그림 4]는 [그림 2]의 공격 흐름도 중 ①, ② 에 해당하는 과정으로 머신계정(sAMAccountName)인 ‘IGLOOTEST$’ 계정을 생성한다. 이후 [그림 4]와 같이 sAMAccountName값을 ‘AD-DC-IGLOO’으로 변조해준다.

[그림 3] 머신계정(IGLOOTEST$) 생성
[그림 4] servicePrincipalName, sAMAccountName 값 변조 전(위), 변조 후(아래)

[그림 4]와 같이 servicePrincipalName, sAMAccountName 값을 변조한 후에는 공격 흐름도 중 ③, ④에 해당하는 [그림 5]와 같이 KDC에 변조된 sAMAccountName값인 ‘AD-DC-IGLOO’로 티켓 발급을 요청하게 된다. 티켓 발급이 완료된 후에는 sAMAccoutName을 원래 값인 ‘IGLOOTEST$’으로 변경하거나 ‘AD-DC-IGLOO’와 다른 계정 값으로 변경해주면 된다.(동일 계정 명이 AD상에서 검색되지 않으면 되기 때문에 계정 명은 어떤 값으로 변경 하든 무관)

[그림 6] Ticket 발급 후 sAMAccountName 변경

[그림 7]은 [그림 2]의 공격 흐름도에서 ⑥~⑨에 해당하는 과정으로 [그림 5]에서 발급된 티켓을 이용해 S4U2Self 요청을 KDC로 전송한다. KDC에서는 요청된 티켓의 sAMAccountName를 기존의 AD목록에서 확인하게 되고 AD내에 sAMAccountName가 존재하지 않는 경우에는 ‘$’붙여 계정을 생성하게 된다. 이후 KDC에서는 권한이 부여된 TGS가 발급되게 된다.

[그림 7] 변경된 sAMAccountName(AD-DC-IGLOO)로 TGS발급 완료 화면

[그림 7]과정까지 마치게 되면 CVE-2021-42287에서 목표로 했던 TGS가 발급되게 되면서 이를 이용한 추가 공격이 가능해지게 된다. [그림 8]은 ‘AD-DC-IGLOO’의 TGS를 이용하여 권한 탈취 공격에 사용되는 Mimikatz를 이용해 Domain Controller의 동작을 시뮬레이션하고 도메인 복제를 통해 암호데이터를 검색할 수 있도록 하는 DCSync공격의 수행 결과다. 해당 공격에서 사용된 DCSync는 Mimikatz의 공격명령으로 MS-DRSR(Directory Replication Service Remote Protocol)를 사용해 AD의 정보를 복제할 때 사용되게 된다.

[그림 8] CVE-2021-42287로 발급된 TGS를 이용한 DCSync 공격 성공결과

2) CASE 2 : CVE-2022-26923, AD DS 인증서 발급 시 권한 상승 취약점

CVE-2022-26923은 AD 인증서비스인 AD CS(Active Directory Certificate Service)가 설치된 AD 환경에서 권한이 낮은 사용자가 Domain Controller로 권한 상승이 가능한 취약점이다. 취약점에서 악용되는 AD CS는 파일 시스템 암호화부터 디지털 서명 및 사용자 인증까지 모든 것을 제공하는 PKI구현기술이다. 도메인 컴퓨터 계정 등록 시 등록 계정이 컴퓨터 계정의 소유자가 되며 dNSHostName, servicePrincipalName(SPN) 속성값을 변경하여 속성이 가지고 있는 제약 조건의 우회가 가능하다. 인증서의 경우 계정의 암호가 재설정되더라도 인증서는 무효화되지 않는다는 특성이 존재하기 때문에 공격이후에도 인증서를 사용할 수 있게 된다.

[그림 9] AD CS 인증서 발급 구조

[그림 10]과 같이 임의의 컴퓨터 계정(IGLOOPC$) 생성 후 [그림 12]와 같이 servicePrincipalName과 dNSHostName 값(AD-DC-IGLOO)을 변조한다.

[그림 10] 컴퓨터 계정 생성
[그림 11] servicePrincipalName, dNSHostName 변조 전
[그림 12] servicePrincipalName, dNSHostName 변조 후

[그림 13]은 Domain Controller로 기존의 IGLOOPC$에서 변조된 계정인 AD-DC-IGLOO로 인증서 발급 시 dNSHostName 값을 읽어 들여 Domain Controller의 인증서(ad-dc-igloo.pfx)를 발급해준다.

[그림 13] 인증서 발급 시도 시 Domain Controller로 인증서 발급

발급된 인증서(ad-dc-igloo.pfx)를 통해 [그림 14]와 같이 Domain Controller의 NT Hash 값 획득을 시도 후 획득한 NT Hash 값을 통해 [그림 15]와 같이 서버 내 모든 계정들의 해시값을 덤프 할 수 있게 된다. AD환경에서는 앞서 CVE-2021-42287에서 사용된 DCSync공격이나 NT Hash획득 이외에도 Kerberos Golden/Silver Ticket 공격, SSP, DSRM남용 등의 다양한 도메인 지속성 공격을 활용할 수 있다.

[그림 14] Domain Controller 인증서를 통해 NT Hash 획득
[그림 15] NT Hash 값을 이용하여 AD 내 계정 정보 획득

03. 체크리스트를 이용한 Active Directory 보안 강화방안

앞서 AD 취약점 2종(CVE-2021-42287, CVE-2022-26923)을 통해서 AD환경에서 인증관리부재 및 미흡으로 인해 야기될 수 있는 문제들에 대해서 간단하게 살펴보았다. 이번 장에서는 앞서 설명한 취약점들을 관리하고 보다 안전한 AD환경을 구축하고 운영하기 위한 최소기준을 체크리스트를 통해 알아보고자 한다. 체크리스트 작성을 위해서 KISA에서 발간한 ‘당신의 AD는 안녕하십니까? Season2: 관리자가 피해야 할 AD 운영 사례’와 Dnsstuff의 ‘The Ultimate Guide to Active Directory Best Practices’를 기반으로 [표 2]와 같이 정리해보았다. [표 2]에서는 △ 설정관리, △ 계정관리, △ 접근관리리, △ 백업관리, △ 패치관리, △ 로그관리의 6가지 카테고리로 재그룹핑하여 보안성 강화를 위한 구체적인 방안을 제시하고 있다.

[표 2] 안전한 AD운영을 위한 체크리스트 (출처 : KISA, 당신의 AD는 안녕하십니까? Season2 및 Dnsstuff, The Ultimate Guide to Active Directory Best Practices 일부 재구성 )

[표 2]에서 언급되고 있는 ‘관리자 그룹(Privileged Accounts and Groups)’은 AD환경에서 가장 높은 권한의 그룹을 의미하며 일반적으로 △ Domain Admins(DA), △ Enterprise Admins(EA), △ Group Policy Creator Owners, △ Schema Admins(SA)의 4가지로 구분하고 있다. [표 3]은 앞으로 설명할 관리자그룹에서 명시하고 있는 4가지 유형을 설명한 내용이다.

[표 3] 체크리스트 내 ‘관리자 그룹(Privileged Accounts and Groups)’의 정의

1) 설정 관리

설정관리는 AD환경에서 제공하고 있는 모든 보안설정(Security Setting 및 Configuration)의 안전하지 않은 보안설정(Misconfiguration)에 관련된 항목을 의미하게 된다. AD에서 제공하고 있는 설정은 다양하지만 CVE-2021-42287에서 살펴본 설정의 취약점을 통해서 보다 자세하게 설명해보고자 한다. AD에서는 사용자의 컴퓨터 계정 생성 속성(MachineAccountQuota)을 기본적으로 10(Default)이 설정되어 있기 때문에 최대 10개의 컴퓨터 계정을 생성할 수 있게 된다. 따라서 [그림 16]과 같이 MachineAccountQuota값을 기존 10에서 0으로 설정한다면 계정생성으로 인한 공격은 제한할 수 있게 된다.

[그림 16] ADSI 편집 내 MachineAccountQuota 설정 변경

다음은 CVE-2022-26923취약점에서 사용된 계정의 속성값을 제한하는 방법이다. CVE-2022-26923취약점에서 악용한 sAMAccountName, dNSHostName값을 변조하기 위해서는 선행적으로 servicePrincipalName값을 먼저 변조하여 제약조건위반을 우회할 수 있게 된다. servicePrincipalName값을 변조할 수 있게된 근간은 [그림 17]과 같이 컴퓨터 계정의 소유자 였던 ‘Client_03’의 권한 내 ‘서비스 사용자 이름에 유효한 쓰기’의 허용 설정으로 인해 발생되었다고 볼 수 있다.

[그림 17] servicePrincipalName 속성 변경 가능 권한

따라서 servicePrincipalName값이 공격에 의해 변조 되는 것을 대응하기 위해서는 AD내 ‘Active Directory 사용자 및 컴퓨터 그룹’의 ‘속성’ 내 ‘고급 보안 설정’에서 속성을 제한할 필요가 있는 그룹에서 상속할 수 있는 속성을 거부 설정하는 것이다. 다만 거부 권한 설정 시에는 두 그룹의 구성원일 경우 거부 권한이 우선적용되기 때문에 거부설정시에는 등록할 그룹의 사용자 특성이 선행적으로 고려 되어야 한다. 이처럼 계정에 부여될 속성 또는 설정을 그룹 또는 도메인 단위로 제한 설정하여 관리할 수 있으므로 조직 내 업무 유형을 파악하여 그룹에 적용되어 있는 불필요한 속성 및 설정을 제한해야 한다.

[그림 18] servicePrincipalName 속성 거부 설정

2) 계정 관리

계정관리에서는 계정명의 명명규칙이나 로그인 방식, 위급상황 발생시 조치 방안 등에 대한 항목들이 필요하다. 먼저 그룹 명명 규칙 및 불필요한 계정의 경우에는 조직의 IT자산관리방안 내에 자산 명 네이밍 규칙을 지정하여 그룹 명을 통해 그룹 사용자의 업무 파악 및 불필요한 사용자 관리가 가능할 수 있도록 해야한다. 특히 AD처럼 그룹을 기준으로 정책을 관리하는 구조에서는 그룹 명명 규칙의 부재는 AD의 복잡성을 높이는 원인으로 작용될 수 있게 된다.

[그림 19] ‘관리자 그룹’ 계정 로그온 기록 확인에 따른 공격 구성도

[그림 19]는 AD환경에서 ‘관리자 그룹’에 포함되어 있는 계정이 일반 사용자PC의 로그인 기록에 포함되어 있는 경우 일반 사용자PC가 공격자에 의해 접근이 가능한 경우 ‘관리자 그룹’의 계정이 파악될 수 있는 공격 시나리오다. 이처럼 사소하다고 생각될 수 있는 로그일지라도 공격에 활용될 수 있기 때문에 ‘관리자 그룹’에 포함되어 있는 계정을 이용해서는 일반 사용자PC나 권한이 낮은 사용자의 디바이스에 직접적으로 로그인하지 않도록 관리가 필요하다. 확보된 ‘관리자 그룹’의 계정 정보는 관리자 계정의 접근권한(Credential)을 확보하기 위한 추가공격(Post-Exploitation)에 활용되어 권한 탈취에 악용되게 된다.

이와 같이 ‘관리자 그룹’의 계정이 노출될 수 있는 위험요소를 최소화 하기 위해서는 AD의 ‘제어 위임’ 기능 내에 ‘사용자 암호를 원래대로 설정하고 다음 로그온 시에 암호 변경 강요’ 정책을 설정하여 모든 사용자의 암호 재설정을 요구할 수 있게 된다. 물론 [그림 20]의 조치는 사후대응방법이기는 하나 관리자 계정의 비밀번호가 노출되었을 경우 즉각적인 대응이 가능한 방법이기 때문에 주기적인 ‘관리자 그룹’의 계정 및 비밀번호 관리이외에도 다양한 대책을 강구해야 한다.

[그림 20] 비밀번호 재설정 정책 적용

3) 접근 관리

접근주체(Subject)가 접근객체(Object)에 접근하기 위한 접근방법 및 정책 등을 관리하는 일련의 과정인 접근관리는 AD환경에서 가장 중요한 요소 중 하나라고 할 수 있다. 따라서 AD에서 운영중인 서비스에 대한 불필요한 접근시도 및 비인가 접근 등 사용자에 대한 인증정책을 주기적으로 관리하고 접근정책을 현행화 하는 것이 필요하다. 특히 중요한 것은 서비스 구동계정이 ‘관리자 그룹’에 속한 계정인지 확인하고 불필요한 서비스가 ‘관리자 그룹’에 속한 계정일 경우에는 서비스를 중지시키고 추가적인 작업이 수행되었는지 분석을 해야한다.

[그림 21] AD 내 Administrator 계정으로 구동 중인 서비스 목록

불필요한 서비스 구동 등의 이상행위를 대응하기 위해서는 AD에서 운영 중인 서비스 및 데이터에 접근하는 사용자에 대한 인증 정책과 접근 제한이 필요하다. AD환경에서 사용자 인증 정책을 수행하기 위한 접근통제 방법으로 권고되는 것은 MFA(Multi-Factor Authentication)방식이다.

지식, 소유, 생체 등의 인증방식을 사용하여 MFA를 구현할 수 있게 되는데, Microsoft에서 발표한 ‘It's Time to Hang Up on Phone Transports for Authentication’에서는 SMS 및 통화 등을 통해 다중 디바이스를 통한 패스워드리스(Passwordless)방식의 인증방식을 권고하고 있다. 패스워드리스방식은 사전에 이름 및 이메일 주소 등의 사용자 정보를 입력한 다음 등록한 장치 및 토큰을 통해서 인증하는 방식으로 Microsoft에서는 ‘Authentication App’이 대표적이라고 할 수 있다. 또한 그룹에 대한 제한 정책을 설정해 그룹 내 구성원 모두에게 사용 권한의 허용/거부 설정을 통해 제한할 수 있다.

[그림 22] 그룹 구성원의 사용 권한 적용

접근관리 시에 사용자 인증정책의 관리항목만큼 중요한 것은 AD에서 운영되는 서비스의 접근관리 역시 중요하다. 앞서 살펴본 CVE-2022-26932에서 권한탈취에 사용되었던 AD CS의 웹 인증서 사이트를 통해 접근관리 방안에 대해 설명해보고자 한다. AD에서는 웹 인증서 서비스를 통해 인증서 서비스 기능을 제공하고 있기 때문에 웹 인증서 서비스를 사용하는 경우 반드시 IIS 웹 서비스가 구동될 수 밖에 없다. 웹 인증서 서비스의 접근통제를 하기 위해서는 인증 및 SSL설정을 통한 보안을 강화할 수 있다. [그림 23]을 통해 ‘IIS 관리자 서비스’의 ‘인증’에서 제공하는 ‘Windows 인증’을 설정할 수 있게 된다. [그림 23]과 함께 적용해야 하는 것은 [그림 24]의 web.config 파일 내 를 ‘Always(항상)’로 변경 후 저장하면 된다. 이렇게 적용하게 되면 웹 인증서 서비스 사용시에 항상 ‘Windows 인증’기능을 적용할 수 있게 된다.

[그림 23] IIS 관리자 서비스 내 인증서 웹 서비스 확장된 보호 설정
[그림 24] IIS 관리자 서비스 내 인증서 웹 서비스 확장된 보호 설정 후 web.config 업데이트

추가적으로 웹 인증서 서비스의 접근통제 이후에는 [그림 25]와 같이 SSL을 적용하여 HTTP 환경에서 발생할 수 있는 보안위협들을 대응할 수 있게 된다.

[그림 25] IIS 관리자 서비스 내 인증서 웹 서비스 SSL 설정 적용

4) 백업 관리

일반적으로 IT인프라를 운영하는 경우에는 거버넌스 및 안전성 등을 고려하여 백업정책을 운영하고 있다. 특히 AD환경은 다수의 서버들이 디렉터리 형태로 계층구조를 가지고 있기 때문에 잘못된 백업정책을 운영하는 경우에는 시스템 전반에 영향을 미칠 수 있게 된다. [그림 26]은 AD구성 중 백업서버가 존재하는 환경에서 AD의 Domain Controller가 랜섬웨어에 감염되는 경우 백업서버까지 랜섬웨어에 감염되는 공격 구성도이다. 이처럼 조직 내 백업 시스템 구성 및 운영방법, 보완 주기 등 백업대상의 관리 미흡 및 부재로 인해 문제가 야기되는 경우 서비스 전반에 영향을 미치게 되기 때문에 별도의 관리가 필요하다.

[그림 26] 백업 서버 위치에 따른 공격 구성도

보안위협에 대응할 수 있는 강건성(Resillience)을 보유한 백업정책을 적용하기 위해서는 조직의 서비스 유형 및 조직규모에 따른 백업절차를 수립하여 주기적인 모니터링이 필요하다. [그림 27]은 백업정책을 수립하고 운영하기 위한 흐름도로서 크게 △백업 시스템 구축, △백업 방식 선택, △백업 시스템 보호 관리, △백업 수행 점검의 4가지 단계로 구성되게 된다. 백업 관리를 위해 다양한 요소들이 중요할 수 있으며 본 문서에서는 조직의 서비스 유형에 따른 가용성을 고려한 백업용량의 크기, 편의성, 백업매체의 저장공간 확보 등을 중점적으로 살펴보고자 한다.

[그림 27] 백업 관리 절차 예시

백업관리의 가장 첫 번째 절차는 백업 시스템 구축을 위해 백업 대상을 선정하는 것이다. 이후 선정된 백업 대상을 어떻게 백업 할 것인지 백업 방식을 선택하게 된다. [표 4]는 백업 방식에 대한 간단한 장·단점의 예시이며, 이 외에도 클라우드 백업 방식 등을 고려하여 백업 시스템을 구성할 수 있다.

[표 4] 백업방식별 장단점 비교

백업 시스템 구축 후에는 백업 주기 및 백업 범위를 선택한다. 산정된 백업 서비스 특성을 고려하여 대상 별 백업 주기를 선택하고 전체 백업, 증분 백업 등 백업 범위를 선택한다. [표 5]는 백업 범위에 대한 간단 설명으로 조직이 구성하고 있는 백업 매체 저장공간을 고려하여 선택해야 한다.

[표 5] 백업 범위별 설명

백업 방식을 도입한 백업 시스템 구축 후에는 백업 시스템 보호 관리를 통하여 안전한 시스템을 운영해야 한다. 백업 시스템 내 계정 등록, 삭제 등의 기록 및 사용자 별 접근 권한 관리, 접근 로그 관리를 통해 불필요한 접근 시도 및 비인가 접근을 제한하고 백업 데이터의 무결성을 유지해야한다.

앞선 백업 시스템 구축, 백업 방식 선택한 뒤 백업 시스템을 보호 관리 시 마지막으로 수행해야하는 단계는 백업 수행 점검이다. 백업 수행 점검이 필요한 이유는 조직의 시스템 위협 시 재빠른 백업을 통하여 서비스 가용성을 유지하기 위함이다. 그러므로 백업 대상의 점검을 통해 백업 데이터의 무결성을 확인하고, 복구 훈련을 통해 백업 데이터 복구 시간을 산정하여 복구 시간 단축을 위한 관리가 필요하다.

5) 패치 관리

앞서 살펴본 AD 취약점 2종(CVE-2021-42287, CVE-2022-26932)은 모두 ‘AD Domain Services Elevation of Privilege Vulnerability’라는 공통점을 갖고 있으나, 인증서 서비스를 통한 권한 상승 취약점인 CVE-2022-26923의 경우 조직이 운영하는 AD 내 인증서 서비스를 사용하지 않을 경우 취약점의 영향도가 낮다고 판단할 수 있다. 이러한 패티 우선순위를 판단 및 결정하기 위해서는 조직의 패치관리 절차를 수립하여 서비스 유형별 취약점 패치 방안을 관리해야 한다.

[그림 28]은 패치 관리 절차의 예시이다. 패치 관리 절차의 첫번째는 패치 대상 분류이다. 조직 내 운영하고 있는 IT 자산의 용도를 분류하고, 중요 자산을 재 분류 하여 관리한다. 패치 대상 분류는 두번째 절차인 패치 우선순위 분류를 위한 기준이 되는데, IT 자산의 중요도, 패치 영향도 등의 지표를 생성해야 하기 때문이다.

[그림 28] 패치 관리 절차 예시

[그림 29]는 Microsoft의 패치 중요도 구분(‘Security Update Severity Rating System’) 및 NIST의 ‘NATIONAL VULNERABILITY DATABASE(NVD)’의 취약성 지표를 기반으로 패치 우선순위를 재그룹핑한 자료이다. 우순순위 구분은 크게 △ Critical, △ Important, △ Moderate, △ Low의 4가지로 분류되며 CVSS v3.0기준과 매핑하였을때 수치가 높을수록 높은 패치 우선순위를 갖게 된다.

[표 6] 패치 우선순위 결정 구분에 대한 설명 (출처: NIST, ‘NATIONAL VULNERABILITY DATABASE(NVD)’ 및 Microsoft, ‘Security Update Severity Rating System’ 재구성)

[그림 29]에서 제시한 Microsoft의 패치 중요도 구분 및 NVD의 취약성 지표에 대한 심각성 기준 외에도 CVSS 점수 산정 시 제공하는 Vector를 참고하여 우선순위를 분류할 수 있다. [그림 30]은 CVE-2022-26923의 Base Score 및 Vector이며, Vector의 정보를 간략히 설명하자면 CVSS의 버전, AV(공격 벡터), AC(공격의 복잡성), PR(필요한 권한), UI(사용자 참여 정도), S(공격 범위), C(기밀성), I(무결성), A(가용성)의 정도 등을 알 수 있다. 패치 우선순위 적용 시 Vector 내 공격의 복잡성 기준 또는 필요한 권한 등의 정보를 추가해 적용할 수 있다.

[그림 29] CVE-2022-26923 의 Base Score 및 Vector (출처 : NIST, CVE-2022-26923)

패치 우선순위 분류 뒤에는 우선순위에 따른 패치 적용 일정을 수립해야 한다. 만일 중요 자산의 긴급한 패치가 나왔을 경우 재빠른 패치 우선순위 결정 후 일정을 수립해 패치를 적용하여야 조직이 운영하는 서비스의 가용성을 유지할 수 있기 때문이다. [그림 31]은 우선순위 기준 및 우선순위 별 적용 일정에 대한 기준이다. [그림 31]을 기준으로 중요 자산에 대한 패치의 우선순위가 3일 경우 ‘Placement in Patch Cycle’내 일정 기준에 따라 최대 1분기 이내 패치를 적용해야 하며, 우선순위가 가장 높은 1일 경우 최소 4시간에서 24시간 이내에 시작해야 하며, 7일 이내에 패치 적용을 완료해야 한다.

[그림 30] 패치 우선 순위 분류 및 패치 적용 일정 수립 기준 예시
(출처: Gartner, Example of patch prioritization and timing, 2016.03 재구성)

패치의 중요도가 높을 수록 빠른 시간 내에 적용해야하기 때문에 적용 시 시스템에 영향이 생길 가능성이 높으므로 패치 적용이 마무리 된 후에는 모니터링을 통하여 패치가 적용된 시스템 또는 서비스의 정상 동작을 확인해야 한다. 그러므로 조직은 시스템 또는 서비스에 발견될 수 있는 취약점에 대한 재빠른 대응을 위해 조직의 IT 자산 특성에 맞는 패치 관리 절차를 수립하여 관리해야 한다.

6) 로그 관리

로그란 인프라 및 시스템에서 발생하는 모든 작업의 기록으로 운영 환경에 대한 감사 및 모니터링을 위해 수집하며, 사고에 대한 원인을 파악하기 위한 증적 자료로 사용된다. 로그 관리에서는 AD 환경에서 수집할 수 있는 이벤트 로그에 대해 알아보고 수집 된 로그에 대한 이상 행위 분석에 대해 설명하고자 한다. Windows 환경에서는 △ 개체 액세스, △ 계정 관리, △ 계정 로그온 이벤트, △ 권한 사용 감사, △ 디렉터리 서비스 액세스, △ 로그온 이벤트, △ 시스템 이벤트, △ 정책 변경, △ 프로세스 추적 정책으로 총 9가지 감사 정책을 통해 관리할 수 있으며, 조직 내 수립한 감사 정책을 통해 성공/실패에 대한 이벤트 로그 기록에 따라 운영 환경에서 발생하는 이상 행위를 수집 할 수 있다.

조직에서 로그를 수집하는 방법으로는 로그 관리 솔루션을 통한 로그 수집, 자동 분석, 로그 보관 기간 관리 등의 기능을 사용할 수 있으며, AD에서 제공하는 이벤트 로그 수집기(Windows Event Collector) 기능을 통해 특정 이벤트 ID를 수집하고, ‘로그 덮어씀 기간’ 등 로그 보관 기간 설정을 통해 운영 환경에 맞게 관리할 수 있다.

[표 7] Active Directory 운영 시 감사에 필요한 이벤트 ID 목록

[표 7]은 AD 운영 시 수집할 수 있는 이벤트 ID이며, 컴퓨터 계정의 생성, 삭제 및 관리자 그룹에 구성원 추가 및 삭제, AD에서 개체 접근에 대한 이벤트 로그이다. 조직에서 AD를 운영하고 있으며, 특정 이벤트 ID를 수집하고자 할 경우 [표 6]과 같이 AD에서만 수집할 수 있는 이벤트 ID를 수립하고 관리할 수 있다.

[표 7]처럼 특정 이벤트 ID를 수집했을 경우 [그림 32]와 같은 이상 행위 탐지가 가능하다. 이벤트 ID 4742는 머신 계정이 수정될 경우 남게 되며, 시간 및 로그 내용 확인 시 짧은 순간에 머신 계정의 $가 변경된 것을 확인할 수 있다.

[그림 31] 이벤트 ID 4742 로그 확인

만약 특정 이벤트 수집 알림 등이 존재할 경우 [그림 32]와 같은 이벤트 ID 발견 시 이상 행위에 대한 분석을 통해 취약점 발현 전에 조치가 가능할 것이다. 또는 정기적인 로그 분석이 이루어 지고 있을 경우 이상 행위 판단 후 공격 성공 여부 파악, 악용한 계정 정보 확인, 공격 시도 시간 등을 확인하여 분석에 활용할 수 있다. 이 외에도 계획되지 않은 관리자 그룹 내 구성원의 추가, 삭제 같은 행위의 로그가 탐지 될 수 있도록 관리해야 한다.

마무리

이번 문서를 통해 AD 권한 상승 취약점 2종(CVE-2021-42287, CVE-2022-26923) 분석 및 체크리스트를 통한 안전한 AD 관리 방안에 대해 알아보았다. 취약점 분석에서 보았듯 공격자들은 운영 체제 또는 서비스가 가지고 있는 기본 설정에 의한 정보 노출 및 데이터 접근 권한을 놓치지 않고 취약점으로 악용하기 위해 끊임없이 공격을 시도한다. 공격자들의 다양한 공격의 예방을 위한 쟁점은 관리하고 있는 모든 주체(Subject)에 대한 불필요한 권한 제거 및 예정되지 않은 모든 작업에 대한 정상 여부 검증이다. ‘안전한 AD운영을 위한 체크리스트’를 따라 현재 운영중인 환경을 점검하고 미흡한 항목의 보안 강화를 통해 안전한 AD 운영 환경을 구축하기 바란다.

04. 참고자료

1) Exploiting the CVE-2021-42278 (sAMAccountName spoofing) and CVE-2021-42287 (deceiving the KDC) Active Directory vulnerabilities, 4sysops, Feb/10/2022
https://4sysops.com/archives/exploiting-the-cve-2021-42278-samaccountname-spoofing-and-cve-2021-42287-deceiving-the-kdc-active-directory-vulnerabilities/
2) Certifried: Active Directory Domain Privilege Escalation (CVE-2022–26923), Oliver Lyak, May/11/2022
https://research.ifcr.dk/certifried-active-directory-domain-privilege-escalation-cve-2022-26923-9e098fe298f4
3) AD(Active Directory) 관리자가 피해야 할 6가지 AD 운영 사례, KISA, 2019.04.02
https://www.krcert.or.kr/data/reportView.do?bulletin_writing_sequence=34988
4) The Ultimate Guide to Active Directory Best Practices, Dnsstuff
https://www.dnsstuff.com/active-directory-best-practices
5) 랜섬웨어 대응을 위한 안전한 정보시스템 백업 가이드, KISA, 2018.02.28
https://www.krcert.or.kr/data/guideView.do?bulletin_writing_sequence=27049
6) Configure Windows Event collection, Microsoft, 06/17/2022
https://docs.microsoft.com/en-us/defender-for-identity/configure-windows-event-collection
7) Appendix B: Privileged Accounts and Groups in Active Directory, Microsoft, 07/30/2021
https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-b--privileged-accounts-and-groups-in-active-directory
8) Patch Management Can Save Your Business: Here's How, PTG, 03/04/2022
https://blog.goptg.com/how-patch-management-can-save-your-business
9) Privileged access security levels, Microsoft, 12/02/2021
https://docs.microsoft.com/en-us/security/compass/privileged-access-security-levels