Netwrix 1Secure는 데이터와 아이덴티티 전반에 걸쳐 통합된 가시성을 제공합니다 - 14일간 무료로 전체 액세스가 가능합니다.무료 평가판 시작

리소스 센터블로그

AD Certificate Services: 위험한 설정과 그에 대한 대응

AD Certificate Services: 위험한 설정과 그에 대한 대응

Dec 18, 2024

Active Directory Certificate Services는 오랫동안 사용되어 왔지만, 이를 학습할 수 있는 자료는 많지 않습니다. 그 결과, 공격이 점점 늘어나는 진입 경로가 될 만큼 잘못된 구성이 자주 존재합니다. 실제로 SpecterOps 가(가) whitepaper 를 발표해 다수의 구성 오류와 잠재적 공격을 자세히 다루고, 보안 강화를 위한 권장 사항도 제공합니다. 이 블로그에서는 잘못 설정될 수 있는 몇 가지 항목과 이를 식별하는 방법을 설명하고, 보안을 추가로 강화하기 위한 몇 가지 옵션을 제안하며, 무료 도구를 사용해 환경을 점검하는 방법을 안내합니다.

배경

인증 기반 인증서가 ID에 발급되면, 해당 인증서는 Subject Alternative Name (SAN)에 설정된 ID로 인증하는 데 사용할 수 있습니다. 이는 보통 UPN 또는 DNS 이름입니다. 그다음 이 인증서는 초기 인증 시 비밀번호 대신 사용됩니다. 이 초기 인증에 대한 기술적 참고 자료는 RFC4556 더 자세히 알아보고 싶다면 참고하세요.

인증 기반 인증서가 한 번 발급되면, 해당 인증서는 폐기되거나 만료될 때까지 주체(Subject)로 인증하는 데 사용할 수 있습니다. 이는 사용자의 비밀번호를 재설정해 공격자를 내쫓는 것과 같은 전략에 의존하는 사고 대응 계획을 우회하게 만듭니다. 인증서도 함께 폐기하지 않는 한 공격자는 계정에 지속적으로 접근할 수 있습니다.

Netwrix Threat Manager

위험한 템플릿 설정

다음은 잘못된 구성으로 이어질 수 있는 일부 인증서 템플릿 설정입니다.

인증 기반 EKU

먼저 어떤 종류의 도메인 수준 인증을 가능하게 하는 확장 키 용도(Enhanced Key Usages, EKUs)를 확인하세요. 간단한 목록은 다음과 같습니다:

  • 모든 목적(2.5.29.37.0)
  • SubCA(없음)
  • 클라이언트 인증(1.3.6.1.5.5.7.3.2)
  • PKINIT 클라이언트 인증 (1.3.6.1.5.2.3.4)
  • 스마트 카드 로그온 (1.3.6.1.4.1.311.20.2.2)

이 기능을 허용하는 인증서 템플릿을 수동으로 모두 찾는 가장 쉬운 방법은 Certificate Authority MMC 스냅인(보조 구성요소)을 열고, 해당 Certificate Authority에 연결한 다음, Certificate Template 섹션을 확인하고 Intended Purpose 열에서 이러한 인증 EKU가 있는지 스캔하는 것입니다. 예를 들어, 아래 그림은 Computer, Copy of Smartcard Logon 및 Domain Controller 템플릿 2개 모두에 PKU가 최소 하나 이상 포함되어 있음을 보여줍니다.

찾은 템플릿을 해결한 다음에도, 일반(정상) 인증서를 악용하는 방법 또한 존재한다는 점을 꼭 염두에 두세요. 예를 들어, PoshADCS의 Get-SmartCardCertificate 함수는 템플릿을 수정하고 해당 템플릿에 대한 인증서를 요청한 다음, 템플릿에 대한 변경 사항을 되돌릴 수 있습니다.

folder screenshot

“Enrollee Supplies Subject” 플래그

플래그 CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT 가 mspki-certificate-name-flag 속성에 존재하면, 인증서 등록자는 인증서 서명 요청(CSR)에서 자신의 대체 Subject Name을 제공할 수 있습니다. 즉, 이 설정이 적용된 인증서에 등록이 허용된 사용자는 네트워크 내의 어떤 사용자(권한이 높은 사용자 포함)로든 인증서를 요청할 수 있다는 뜻입니다.

이 플래그는 Certificate Template 콘솔에서 확인할 수 있습니다. Subject Name 탭 아래에 있는 “Supply in the request” 라디오 옵션으로 표시됩니다:

supply in the request screenshot

또는 다음과 같은 PowerShell 명령을 사용해 AD에서 템플릿을 가져오고, 인증서에서 플래그가 설정되어 있는지 확인할 수도 있습니다:

      Get-ADobject -Filter { ObjectClass -eq "PKIcertificateTemplate" } -SearchBase (Get-ADRootDSE).ConfigurationNamingContext -prop * | Select Name, mspki-certificate-name-flag, @{ Name = "SupplyInRequest" ; Expression = { $_.'mspki-certificate-name-flag' -band 0x00000001 } }
      

위험을 추가로 줄이기

인증서의 잘못된 구성(오구성)을 수정하는 것 외에도, 인증서 발급을 제어하기 위해 다음 옵션을 사용하는 것을 고려해 보세요.

CA 인증서 관리자 승인 또는 승인된 서명

첫 번째이자 아마도 가장 중요한 것은 각 인증서의 발급 요구 사항(Issuance Requirements) 탭을 확인하여, Certificate Authority(CA) 관리자 또는 한 명 이상이 승인해야 하는지 살펴보는 것입니다.

CA Certificate check screenshot

이 두 설정 중 하나 또는 둘 다를 사용하면, 인증서가 발급되기 전에 확인 절차를 요구함으로써 위험을 크게 줄일 수 있습니다. 승인된 서명을 요구해야 할지 확신이 없다면, 최소한 CA 인증서 관리자 승인을 요구하세요. 그러면 인증서를 요청할 때마다 발급 전에 Certificate Authority로 보내져 수동 검토를 거치게 됩니다.

등록 권한

두 번째로, 각 템플릿의 등록 권한을 확인하세요. 이는 Security 탭에서 찾을 수 있습니다. 많은 잘못된 구성은 일반적인 주체(generic principals)나 대규모 그룹이 이러한 권한을 가질 때에만 치명적일 수 있습니다. 특히 Authenticated Users, Domain Users 및 인증서를 요청할 수 없어야 하는 사용자 대규모 그룹이 있는지 확인하고, 그런 그룹을 발견하면 Enroll 또는 AutoEnroll 권한을 해지(철회)하는 것을 고려하세요.

Logon properties screenshot

EDITF_ATTRIBUTESUBJECTALTNAME2 레지스트리 키

마지막으로 EDITF_ATTRIBUTESUBJECALTNAME2 레지스트리 설정을 확인하세요. 이 설정은 가장 흥미로운 것 중 하나입니다. CA에서 이 기능이 활성화되어 있으면, 발급되는 any 인증 기반 인증서는 (주체가 Active Directory에서 자동으로 생성되는 인증서를 포함하여) SAN에 사용자 정의 값을 가질 수 있습니다.

이 설정을 확인하려면 다음 명령을 실행할 수 있습니다:

      certutil –getreg policyEditFlags
      

출력 목록에 EDITF_ATTRIBUTESUBJECALTNAME2 가 있으면, 다음 명령을 사용해 제거해야 합니다:

      certutil -config "CA CONNECTION STRING" -setreg policyEditFlags - EDITF_ATTRIBUTESUBJECTALTNAME2
      

이 설정에 대한 추가 지침은 here에서 확인할 수 있습니다.

PSPKIAudit을 사용한 위험한 설정 점검

PSPKIAudit 도구는 PKI 인프라를 감사하는 데 도움이 될 수 있습니다. PSPKIAudit을 사용하려면 GitHub에서 도구를 다운로드한 다음 모듈을 가져오고 Invoke-PKIAudit 명령을 실행하기만 하면 됩니다. 그러면 Active Directory에서 인증 기관(Certificate Authority)을 나열한 뒤, 일부 기본 옵션에 대해 이를 조회합니다.

아래에는 이 도구의 출력 결과를 보여주는 스크린샷 몇 가지가 있습니다. 이 결과에는 잘못 구성된 인증서와 CA에서의 구성 오류가 드러납니다. PSPKIAudit이 이 글에서 다루지 않은 다른 구성 오류를 발견하면, SpecterOps paper에서 수정(대응) 조언을 확인하세요.

PSPKIAudit screenshot
PSPKIAudit screenshot 2

결론

Active Directory Certificate Services에 대한 공격이 점점 늘어날 것으로 예상합니다. 실제로 PetitPotamADCS NTLM Relaying 공격은 SpecterOps 논문이 발표된 이후로 이미 공개되었으며, SpecterOps는 BlackHat 2021에서 ForgeCert (인증서의 골든 티켓)를 공개하고 있습니다. 따라서 환경에서 구성 오류가 있는지 즉시 점검하고 신속하게 조치(수정)한 다음, 정기적으로 동일한 과정을 반복하는 것이 급선무입니다.

종단 간 보호를 위해 Netwrix Active Directory security solution 를 고려해 보세요. 다음을 도와드립니다:

  • 심층 위험 평가를 통해 보안 취약 지점을 선제적으로 파악하세요.
  • 비용이 많이 드는 가동 중단과 업무 중단을 최소화하세요.
  • 고도화된 위협도 적시에 신속히 감지하고 빠르게 대응하세요.

Active Directory 보안 모범 사례

AD 보안을 강화하고 위험을 줄이기 위한 전문가 팁을 확인하세요

자세히 알아보기

공유하기

더 알아보기

저자 소개

Asset Not Found

Joe Dibley

보안 연구원

Netwrix의 보안 연구원이며 Netwrix Security Research Team의 일원입니다. Joe는 Active Directory, Windows 및 다양한 엔터프라이즈 소프트웨어 플랫폼과 기술 분야의 전문가로, 새로운 보안 위험, 복잡한 공격 기법, 그리고 이에 대한 대응(완화)과 탐지 방법을 연구합니다.