AD CS Domain Escalation
이는 다음 게시물의 승격 기술 섹션 요약입니다:
잘못 구성된 인증서 템플릿 - ESC1
설명
잘못 구성된 인증서 템플릿 - ESC1 설명
Enterprise CA에 의해 낮은 권한을 가진 사용자에게 등록 권한이 부여됩니다.
관리자 승인이 필요하지 않습니다.
인증된 인원의 서명이 필요하지 않습니다.
인증서 템플릿의 보안 기술서는 너무 허용적이어서 낮은 권한을 가진 사용자가 등록 권한을 얻을 수 있습니다.
인증서 템플릿은 인증을 용이하게 하는 EKU(Extended Key Usage)를 정의하도록 구성됩니다:
클라이언트 인증 (OID 1.3.6.1.5.5.7.3.2), PKINIT 클라이언트 인증 (1.3.6.1.5.2.3.4), 스마트 카드 로그온 (OID 1.3.6.1.4.1.311.20.2.2), 모든 용도 (OID 2.5.29.37.0) 또는 EKU 없음 (SubCA)과 같은 EKU 식별자가 포함됩니다.
요청자가 인증서 서명 요청(CSR)에 subjectAltName을 포함할 수 있는 능력이 템플릿에서 허용됩니다:
주체 대체 이름(SAN)이 인증서에 포함되어 있으면 Active Directory(AD)는 신원 확인을 위해 SAN을 우선시합니다. 이는 CSR에서 SAN을 지정함으로써 인증서를 요청하여 모든 사용자(예: 도메인 관리자)를 흉내 낼 수 있음을 의미합니다. 요청자가 SAN을 지정할 수 있는지 여부는 인증서 템플릿의 AD 개체에서
mspki-certificate-name-flag속성을 통해 나타납니다. 이 속성은 비트마스크이며CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT플래그의 존재는 요청자가 SAN을 지정할 수 있도록 허용합니다.
설정된 구성은 낮은 권한을 가진 사용자가 선택한 SAN을 사용하여 인증서를 요청할 수 있도록 하므로 Kerberos 또는 SChannel을 통해 모든 도메인 주체로 인증할 수 있습니다.
이 기능은 때로는 제품이나 배포 서비스에 의해 HTTPS 또는 호스트 인증서를 동적으로 생성하거나 이해 부족으로 인해 활성화된 경우가 있습니다.
이 옵션을 사용하여 인증서를 만드는 것은 기존 인증서 템플릿(예: WebServer 템플릿, CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT가 활성화된)을 복제한 다음 인증 OID를 포함하도록 수정하는 경우에는 경고가 트리거됨을 주의해야 합니다.
남용
취약한 인증서 템플릿을 찾으려면 다음을 실행할 수 있습니다:
이 취약점을 악용하여 관리자를 사칭하기 위해 다음을 실행할 수 있습니다:
그럼 생성된 인증서를 .pfx 형식으로 변환하고 다시 Rubeus 또는 certipy를 사용하여 인증할 수 있습니다:
Windows 이진 파일 "Certreq.exe" 및 "Certutil.exe"를 사용하여 PFX를 생성할 수 있습니다: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee
AD Forest의 구성 스키마 내에서 인증서 템플릿을 열거할 수 있습니다. 특히, 승인이나 서명이 필요하지 않는 것들, 클라이언트 인증 또는 스마트 카드 로그온 EKU를 가지고 있으며 CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT 플래그가 활성화된 것들은 다음 LDAP 쿼리를 실행하여 수행할 수 있습니다:
잘못 구성된 인증서 템플릿 - ESC2
설명
두 번째 악용 시나리오는 첫 번째와 다른 변형입니다:
기업 CA에 의해 저급 권한을 가진 사용자에게 등록 권한이 부여됩니다.
관리자 승인 요구 사항이 비활성화됩니다.
승인된 서명 필요 사항이 생략됩니다.
인증서 템플릿에 대한 지나치게 허용적인 보안 설명자가 낮은 권한을 가진 사용자에게 인증서 등록 권한을 부여합니다.
인증서 템플릿은 Any Purpose EKU 또는 EKU가 없도록 정의됩니다.
Any Purpose EKU는 인증서를 클라이언트 인증, 서버 인증, 코드 서명 등을 포함한 어떤 목적으로도 얻을 수 있게 합니다. ESC3에 사용된 기술과 동일한 기술을 사용하여 이 시나리오를 악용할 수 있습니다.
EKU가 없는 인증서는 하위 CA 인증서로 작동하며 어떤 목적으로도 악용될 수 있으며 새로운 인증서에 서명하는 데 사용될 수 있습니다. 따라서 공격자는 하위 CA 인증서를 활용하여 새로운 인증서에 임의의 EKU나 필드를 지정할 수 있습니다.
그러나 도메인 인증을 위해 생성된 새로운 인증서는 NTAuthCertificates 개체에 의해 신뢰되지 않는 경우 기본 설정입니다. 그러나 공격자는 여전히 임의의 EKU와 임의의 인증서 값으로 새로운 인증서를 생성할 수 있습니다. 이러한 인증서는 잠재적으로 다양한 목적 (예: 코드 서명, 서버 인증 등)으로 악용될 수 있으며 SAML, AD FS 또는 IPSec와 같은 네트워크의 다른 응용 프로그램에 중대한 영향을 미칠 수 있습니다.
AD Forest의 구성 스키마 내에서 이 시나리오와 일치하는 템플릿을 나열하려면 다음 LDAP 쿼리를 실행할 수 있습니다:
잘못 구성된 등록 에이전트 템플릿 - ESC3
설명
이 시나리오는 첫 번째와 두 번째와 유사하지만 다른 EKU(인증서 요청 에이전트)를 남용하고 2개의 다른 템플릿(따라서 2개의 요구 사항 세트가 있음)을 사용합니다.
인증서 요청 에이전트 EKU(OID 1.3.6.1.4.1.311.20.2.1)인 Enrollment Agent로 알려진 것은 Microsoft 문서에서 주체가 다른 사용자를 대신하여 인증서를 등록할 수 있도록 합니다.
**"등록 에이전트"**는 이러한 템플릿에 등록하고 결과로 나온 인증서를 다른 사용자를 대신하여 CSR에 공동 서명합니다. 그런 다음 공동 서명된 CSR을 CA에 보내어 "대신하여 등록"을 허용하는 템플릿에 등록하고 CA는 "다른" 사용자에게 속한 인증서로 응답합니다.
요구 사항 1:
기업 CA에 의해 낮은 권한을 가진 사용자에게 등록 권한이 부여됩니다.
관리자 승인 요구 사항이 생략됩니다.
승인된 서명 요구 사항이 없습니다.
인증서 템플릿의 보안 설명자가 지나치게 허용되어 낮은 권한을 가진 사용자에게 등록 권한이 부여됩니다.
인증서 템플릿에는 인증서 요청 에이전트 EKU가 포함되어 있어 다른 주체를 대신하여 다른 인증서 템플릿을 요청할 수 있습니다.
요구 사항 2:
기업 CA가 낮은 권한을 가진 사용자에게 등록 권한을 부여합니다.
관리자 승인이 우회됩니다.
템플릿의 스키마 버전이 1이거나 2를 초과하며 인증서 요청 에이전트 EKU를 필요로 하는 Application Policy Issuance Requirement를 지정합니다.
인증서 템플릿에 정의된 EKU가 도메인 인증을 허용합니다.
CA에 대해 등록 에이전트에 대한 제한이 적용되지 않습니다.
남용
이 시나리오를 남용하기 위해 Certify 또는 Certipy를 사용할 수 있습니다:
사용자들은 등록 에이전트 인증서를 획득할 수 있는 템플릿 및 등록 에이전트가 등록할 수 있는 템플릿, 그리고 등록 에이전트가 작동할 계정들은 기업 CA에 의해 제한될 수 있습니다. 이는 certsrc.msc 스냅인을 열고 CA를 우클릭한 후 속성을 클릭한 다음 “Enrollment Agents” 탭으로 이동하여 달성됩니다.
그러나 CA의 기본 설정은 “등록 에이전트 제한 없음”으로 되어 있다는 것에 유의해야 합니다. 관리자가 등록 에이전트에 대한 제한을 활성화하면, “등록 에이전트 제한”으로 설정하더라도 기본 구성은 매우 허용적인 상태로 유지됩니다. 이는 모든 사용자가 누구나 모든 템플릿에 등록할 수 있도록 허용합니다.
취약한 인증서 템플릿 액세스 제어 - ESC4
설명
인증서 템플릿의 보안 설명자는 AD 주체들이 템플릿에 대해 가지는 권한을 정의합니다.
공격자가 템플릿을 변경하고 이전 섹션에서 설명한 취약한 구성을 도입할 필요 권한을 가지고 있다면, 특권 상승이 용이해질 수 있습니다.
인증서 템플릿에 적용되는 주요 권한은 다음과 같습니다:
소유자: 객체에 대한 암시적 제어를 부여하여 모든 속성을 수정할 수 있게 합니다.
FullControl: 객체에 대한 완전한 권한을 부여하여 모든 속성을 변경할 수 있게 합니다.
WriteOwner: 객체의 소유자를 공격자가 제어하는 주체로 변경할 수 있게 합니다.
WriteDacl: 액세스 제어를 조정하여 공격자에게 FullControl을 부여할 수 있게 합니다.
WriteProperty: 모든 객체 속성을 편집할 수 있게 합니다.
남용
이전과 같은 특권 상승의 예시:
ESC4는 사용자가 인증서 템플릿에 대한 쓰기 권한을 가지는 경우를 가리킵니다. 이는 예를 들어 인증서 템플릿의 구성을 덮어쓰고 해당 템플릿을 ESC1에 취약하게 만들기 위해 남용될 수 있습니다.
위 경로에서 볼 수 있듯이, JOHNPC만 이러한 권한을 가지고 있지만, 우리 사용자 JOHN은 JOHNPC에 대한 새로운 AddKeyCredentialLink 엣지를 가지고 있습니다. 이 기술은 인증서와 관련이 있기 때문에, 흔히 Shadow Credentials로 알려진 이 공격을 구현했습니다. 여기에는 피해자의 NT 해시를 검색하기 위한 Certipy의 shadow auto 명령어의 간단한 미리보기가 있습니다.
Certipy는 단일 명령어로 인증서 템플릿의 구성을 덮어쓸 수 있습니다. 기본 설정으로 Certipy는 구성을 덮어쓰기하여 ESC1에 취약하게 만듭니다. 또한 우리의 공격 이후 구성을 복원하는 데 유용한 -save-old 매개변수를 지정할 수도 있습니다.
취약한 PKI 객체 액세스 제어 - ESC5
설명
인증서 템플릿 및 인증서 기관을 넘어서는 여러 객체를 포함하는 ACL 기반 관계의 방대한 웹은 전체 AD CS 시스템의 보안에 영향을 미칠 수 있습니다. 보안에 상당한 영향을 미칠 수 있는 이러한 객체는 다음과 같습니다:
CA 서버의 AD 컴퓨터 객체로, S4U2Self 또는 S4U2Proxy와 같은 메커니즘을 통해 침해를 당할 수 있습니다.
CA 서버의 RPC/DCOM 서버.
특정 컨테이너 경로
CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM>내의 하위 AD 객체 또는 컨테이너. 이 경로에는 인증서 템플릿 컨테이너, 인증 기관 컨테이너, NTAuthCertificates 객체 및 Enrollment Services 컨테이너와 같은 컨테이너 및 객체가 포함됩니다.
PKI 시스템의 보안이 저렴한 권한을 가진 공격자가 이러한 중요한 구성 요소 중 하나를 제어할 수 있다면 위험에 노출될 수 있습니다.
EDITF_ATTRIBUTESUBJECTALTNAME2 - ESC6
설명
CQure Academy 게시물에서 논의된 주제는 또한 Microsoft에서 설명한 EDITF_ATTRIBUTESUBJECTALTNAME2 플래그의 영향에 대해 다룹니다. 이 구성은 인증 기관(CA)에서 활성화되면 사용자 정의 값을 주제 대체 이름에 포함할 수 있게 해줍니다. 이는 Active Directory®에서 생성된 요청을 포함한 모든 요청에 대해 적용됩니다. 결과적으로 이 제공은 침입자가 도메인 인증을 위해 설정된 모든 템플릿을 통해 등록할 수 있게 해줍니다. 특히 일반 사용자 템플릿과 같이 권한이 없는 사용자 등록에 열려 있는 것들입니다. 결과적으로 인증서를 안전하게 유지하여 침입자가 도메인 관리자로 인증하거나 도메인 내 다른 활성 엔티티로 인증할 수 있게 됩니다.
참고: -attrib "SAN:" 인수를 통해 certreq.exe에서 대체 이름을 인증서 서명 요청(CSR)에 추가하는 접근 방식(“이름 값 쌍”이라고 함)은 ESC1에서 SAN의 악용 전략과 대조를 이룹니다. 여기서 차이점은 계정 정보가 어떻게 캡슐화되는지에 있습니다. 즉, 인증서 속성 내에 캡슐화되는 것이 아니라 확장 내에 있습니다.
남용
설정이 활성화되었는지 확인하려면 조직은 certutil.exe를 사용하여 다음 명령을 사용할 수 있습니다:
이 작업은 본질적으로 원격 레지스트리 액세스를 사용하므로 대안적인 접근 방법은 다음과 같을 수 있습니다:
도구인 Certify와 Certipy는 이 구성 오류를 감지하고 악용할 수 있습니다:
위 설정을 변경하려면 도메인 관리자 권한 또는 동등한 권한이 있는 경우 다음 명령을 모든 워크스테이션에서 실행할 수 있습니다:
환경에서 이 구성을 비활성화하려면 다음과 같이 플래그를 제거할 수 있습니다:
2022년 5월 보안 업데이트 이후에는 새로 발급된 인증서에 보안 확장 기능이 포함될 것입니다. 이 확장 기능은 요청자의 objectSid 속성을 포함합니다. ESC1의 경우, 이 SID는 지정된 SAN에서 파생됩니다. 그러나 ESC6의 경우, SID는 **요청자의 objectSid**를 반영하며 SAN이 아닙니다. ESC6를 악용하기 위해서는 새로운 보안 확장 기능 대신 SAN을 우선시하는 ESC10 (약한 인증서 매핑)에 시스템이 취약해야 합니다.
취약한 인증서 발급 기관 접근 제어 - ESC7
공격 1
설명
인증서 발급 기관의 접근 제어는 CA 작업을 규제하는 권한 집합을 통해 유지됩니다. 이러한 권한은 certsrv.msc에 액세스하여 CA를 마우스 오른쪽 버튼으로 클릭한 다음 속성을 선택한 후 보안 탭으로 이동하여 볼 수 있습니다. 또한 PSPKI 모듈을 사용하여 권한을 나열할 수 있습니다.
이는 주요 권한인 ManageCA 및 **ManageCertificates**에 대한 통찰을 제공하며, 각각 "CA 관리자" 및 "인증서 관리자" 역할과 관련이 있습니다.
남용
인증 기관에서 ManageCA 권한을 가지면 PSPKI를 사용하여 원격으로 설정을 조작할 수 있습니다. 이는 어떤 템플릿에서도 SAN 지정을 허용하는 EDITF_ATTRIBUTESUBJECTALTNAME2 플래그를 전환하는 것을 포함하며, 이는 도메인 상승의 중요한 측면입니다.
이 프로세스를 간소화하는 것은 PSPKI의 Enable-PolicyModuleFlag cmdlet을 사용하여 직접 GUI 상호 작용 없이 수정을 허용합니다.
ManageCertificates 권한 소유는 보류 중인 요청을 승인하여 "CA 인증서 관리자 승인" 안전장치를 우회하는 것을 효과적으로 용이하게 합니다.
Certify 및 PSPKI 모듈의 조합을 사용하여 인증서를 요청, 승인 및 다운로드할 수 있습니다:
공격 2
설명
이전 공격에서는 Manage CA 권한을 사용하여 EDITF_ATTRIBUTESUBJECTALTNAME2 플래그를 활성화하여 ESC6 공격을 수행했지만, 이는 CA 서비스(CertSvc)가 다시 시작될 때까지는 어떤 효과도 없습니다. 사용자가 Manage CA 액세스 권한을 가지고 있을 때 사용자는 또한 서비스를 다시 시작할 수 있습니다. 그러나 사용자가 원격으로 서비스를 다시 시작할 수 있는 것은 아닙니다. 또한 대부분의 패치된 환경에서는 2022년 5월 보안 업데이트로 인해 ESC6가 기본적으로 작동하지 않을 수 있습니다.
따라서, 다른 공격이 여기에 제시됩니다.
전제 조건:
ManageCA권한만Manage Certificates권한 (**ManageCA**에서 부여 가능)인증서 템플릿 **
SubCA가 활성화되어 있어야 함 (ManageCA**에서 활성화 가능)
이 기술은 Manage CA 및 Manage Certificates 액세스 권한을 가진 사용자가 인증서 요청 실패를 발행할 수 있다는 사실에 의존합니다. SubCA 인증서 템플릿은 ESC1에 취약하지만 관리자만 템플릿에 등록할 수 있습니다. 따라서 사용자는 **SubCA**에 등록을 요청할 수 있지만 거부될 것이며, 그 후 관리자에 의해 발급될 것입니다.
남용
새로운 관리자로 사용자를 추가하여 Manage Certificates 액세스 권한을 자신에게 부여할 수 있습니다.
SubCA 템플릿은 -enable-template 매개변수를 사용하여 CA에서 활성화할 수 있습니다. 기본적으로 SubCA 템플릿이 활성화되어 있습니다.
만약 이 공격을 위한 전제 조건을 충족했다면, SubCA 템플릿을 기반으로 인증서를 요청하여 시작할 수 있습니다.
이 요청은 거부될 것이지만, 우리는 개인 키를 저장하고 요청 ID를 메모해야 합니다.
**Manage CA 및 Manage Certificates**를 사용하여 ca 명령 및 -issue-request <request ID> 매개변수로 실패한 인증서 요청을 발급할 수 있습니다.
그리고 마지막으로, req 명령어와 -retrieve <request ID> 매개변수를 사용하여 발급된 인증서를 검색할 수 있습니다.
NTLM Relay to AD CS HTTP Endpoints – ESC8
설명
AD CS가 설치된 환경에서는, 적어도 하나의 도메인 컴퓨터 등록 및 클라이언트 인증을 허용하는 인증서 템플릿이 게시된 경우 (예: 기본 Machine 템플릿), 웹 등록 엔드포인트에 취약점이 존재한다면, 스풀러 서비스가 활성화된 모든 컴퓨터가 공격자에 의해 침해될 수 있다!
AD CS에서는 여러 HTTP 기반 등록 방법이 지원되며, 관리자가 설치할 수 있는 추가 서버 역할을 통해 이러한 HTTP 기반 인증서 등록 인터페이스가 제공됩니다. 이러한 HTTP 기반 인증서 등록을 위한 인터페이스는 NTLM 릴레이 공격에 취약합니다. 공격자는 침해된 컴퓨터에서 수신 NTLM을 통해 인증하는 모든 AD 계정을 가장할 수 있습니다. 피해자 계정을 가장하는 동안, 공격자는 이러한 웹 인터페이스에 액세스하여 User 또는 Machine 인증서 템플릿을 사용하여 클라이언트 인증서를 요청할 수 있습니다.
웹 등록 인터페이스 (구식 ASP 애플리케이션으로
http://<caserver>/certsrv/에서 사용 가능)는 기본적으로 HTTP만 지원하며, NTLM 릴레이 공격에 대한 보호를 제공하지 않습니다. 또한, 인증 HTTP 헤더를 통해 명시적으로 NTLM 인증만 허용하므로 Kerberos와 같은 더 안전한 인증 방법을 사용할 수 없습니다.인증서 등록 서비스 (CES), 인증서 등록 정책 (CEP) 웹 서비스 및 네트워크 장치 등록 서비스 (NDES)는 기본적으로 인증 HTTP 헤더를 통해 협상 인증을 지원합니다. 협상 인증은 Kerberos 및 NTLM을 모두 지원하며, 공격자는 릴레이 공격 중에 NTLM으로 다운그레이드할 수 있습니다. 이러한 웹 서비스는 기본적으로 HTTPS를 지원하지만, HTTPS만으로는 NTLM 릴레이 공격으로부터 보호되지 않습니다. HTTPS 서비스의 NTLM 릴레이 공격으로부터의 보호는 HTTPS가 채널 바인딩과 결합될 때에만 가능합니다. 안타깝게도, AD CS는 채널 바인딩을 위해 필요한 IIS의 확장된 인증 보호를 활성화하지 않습니다.
NTLM 릴레이 공격의 일반 문제점은 NTLM 세션의 짧은 기간과 공격자가 NTLM 서명을 필요로 하는 서비스와 상호 작용할 수 없는 점입니다.
그러나 이 제한은 NTLM 릴레이 공격을 이용하여 사용자를 위한 인증서를 획들할 경우 극복됩니다. 인증서의 유효 기간이 세션의 기간을 결정하며, 인증서는 NTLM 서명을 필요로 하는 서비스에서 사용할 수 있습니다. 훔친 인증서를 사용하는 방법에 대한 지침은 다음을 참조하십시오:
pageAD CS Account PersistenceNTLM 릴레이 공격의 또 다른 제한은 공격자가 제어하는 컴퓨터가 피해자 계정에 의해 인증되어야 한다는 것입니다. 공격자는 이 인증을 기다리거나 강제로 시도할 수 있습니다:
pageForce NTLM Privileged Authentication남용
Certify의 cas는 활성화된 HTTP AD CS 엔드포인트를 열거합니다:
msPKI-Enrollment-Servers 속성은 기업용 인증 기관(CAs)가 인증서 등록 서비스(CES) 엔드포인트를 저장하는 데 사용됩니다. 이러한 엔드포인트는 Certutil.exe 도구를 활용하여 구문 분석하고 나열할 수 있습니다:
```powershell Import-Module PSPKI Get-CertificationAuthority | select Name,Enroll* | Format-List * ```
Certify를 악용하기
Certipy를 이용한 남용
인증서 요청은 Certipy에 의해 기본적으로 Machine 또는 User 템플릿을 기반으로 하며, 전달되는 계정 이름이 $로 끝나는지에 따라 결정됩니다. 대체 템플릿의 지정은 -template 매개변수를 사용하여 달성할 수 있습니다.
PetitPotam과 같은 기술을 사용하여 강제 인증을 수행할 수 있습니다. 도메인 컨트롤러를 다룰 때는 -template DomainController의 지정이 필요합니다.
보안 확장 없음 - ESC9
설명
새로운 값 CT_FLAG_NO_SECURITY_EXTENSION (0x80000)은 **msPKI-Enrollment-Flag**에 대한 ESC9로 참조되며, 인증서에 새로운 szOID_NTDS_CA_SECURITY_EXT 보안 확장을 포함하는 것을 방지합니다. 이 플래그는 StrongCertificateBindingEnforcement가 1로 설정된 경우 (기본 설정)에 중요해지며, 이는 2로 설정된 경우와 대조됩니다. ESC9의 중요성은 더 약한 인증서 매핑이 악용될 수 있는 경우 (ESC10과 같이)에서 더욱 부각되며, ESC9의 부재는 요구 사항을 변경하지 않을 것입니다.
이 플래그 설정이 중요해지는 조건은 다음과 같습니다:
StrongCertificateBindingEnforcement가2로 조정되지 않은 경우 (기본값은1), 또는CertificateMappingMethods에UPN플래그가 포함된 경우.인증서가
msPKI-Enrollment-Flag설정 내에서CT_FLAG_NO_SECURITY_EXTENSION플래그로 표시됨.인증서에 클라이언트 인증 EKU가 지정됨.
다른 계정을 침해하기 위해
GenericWrite권한이 제공됨.
남용 시나리오
John@corp.local이 Jane@corp.local에 대한 GenericWrite 권한을 보유하고 있으며, Administrator@corp.local을 침해하려고 하는 경우를 가정해 봅시다. Jane@corp.local이 등록할 수 있는 ESC9 인증서 템플릿은 msPKI-Enrollment-Flag 설정에서 CT_FLAG_NO_SECURITY_EXTENSION 플래그로 구성됩니다.
처음에는 Jane의 해시를 John의 GenericWrite 덕분에 얻습니다:
이후, Jane의 userPrincipalName이 의도적으로 @corp.local 도메인 부분을 생략하고 Administrator로 수정되었습니다:
이 수정은 Administrator@corp.local이 Administrator의 userPrincipalName으로서 구분되는 한 제약 조건을 위반하지 않습니다.
이후 Jane으로 요청된 ESC9 인증서 템플릿은 취약하게 표시됩니다:
다음은 userPrincipalName이 "Administrator"를 반영하고 "object SID"가 없는 인증서에 대한 주목이다.
그런 다음 Jane의 userPrincipalName이 원래 값인 Jane@corp.local로 복원된다:
인증을 시도하면 이제 Administrator@corp.local의 NT 해시가 발생합니다. 인증서에 도메인이 지정되어 있지 않기 때문에 명령에는 -domain <도메인>을 포함해야 합니다:
취약한 인증서 매핑 - ESC10
설명
도메인 컨트롤러의 레지스트리 키 값 두 개가 ESC10에 의해 언급됩니다:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel하위의CertificateMappingMethods의 기본 값은0x18(0x8 | 0x10)이며, 이전에는0x1F로 설정되었습니다.HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc하위의StrongCertificateBindingEnforcement의 기본 설정은1이며, 이전에는0이었습니다.
사례 1
StrongCertificateBindingEnforcement가 0으로 구성된 경우.
사례 2
CertificateMappingMethods에 UPN 비트 (0x4)가 포함된 경우.
남용 사례 1
StrongCertificateBindingEnforcement가 0으로 구성된 경우, GenericWrite 권한이 있는 계정 A를 악용하여 어떤 계정 B도 침해할 수 있습니다.
예를 들어, Jane@corp.local에 대한 GenericWrite 권한을 가지고 있는 공격자가 Administrator@corp.local을 침해하려고 합니다. 이 절차는 ESC9를 반영하여 어떤 인증서 템플릿이든 사용할 수 있습니다.
먼저, Jane의 해시를 가져와야 하는데, 이는 Shadow Credentials를 이용하여 GenericWrite를 악용합니다.
이후, Jane의 userPrincipalName이 Administrator로 변경되어 @corp.local 부분을 의도적으로 생략하여 제약 조건 위반을 피합니다.
다음으로, 기본 '사용자' 템플릿을 사용하여 'Jane'으로 클라이언트 인증을 가능하게 하는 인증서가 요청됩니다.
Jane의 userPrincipalName은 그 후 원래 값인 Jane@corp.local로 되돌려집니다.
인증서를 사용하여 인증하면 Administrator@corp.local의 NT 해시가 생성되며, 인증서에 도메인 세부 정보가 없기 때문에 명령에 도메인을 지정해야 합니다.
남용 사례 2
CertificateMappingMethods에 UPN 비트 플래그(0x4)가 포함된 경우, GenericWrite 권한을 가진 계정 A는 userPrincipalName 속성이 없는 계정 B(기계 계정 및 기본 도메인 관리자 Administrator 포함)을 침해할 수 있습니다.
여기서 목표는 GenericWrite를 활용하여 Jane의 해시를 얻어 DC$@corp.local을 침해하는 것입니다.
Jane의 userPrincipalName은 DC$@corp.local로 설정됩니다.
인증서를 요청할 때 기본 User 템플릿을 사용하여 Jane으로 클라이언트 인증서가 요청됩니다.
Jane의 userPrincipalName은 이 프로세스 후에 원래 값으로 되돌립니다.
Schannel를 통해 인증하려면 Certipy의 -ldap-shell 옵션을 사용하여 인증 성공을 u:CORP\DC$로 표시합니다.
LDAP 셸을 통해 set_rbcd와 같은 명령을 사용하면 Resource-Based Constrained Delegation (RBCD) 공격을 활성화할 수 있으며, 이는 도메인 컨트롤러를 잠재적으로 침해할 수 있습니다.
이 취약점은 userPrincipalName이 없는 사용자 계정 또는 sAMAccountName과 일치하지 않는 사용자 계정에도 확장됩니다. 기본 Administrator@corp.local은 userPrincipalName이 기본적으로 없고 LDAP 권한이 상승되어 있기 때문에 주요 대상입니다.
ICPR로 NTLM 릴레이 - ESC11
설명
CA 서버가 IF_ENFORCEENCRYPTICERTREQUEST로 구성되지 않은 경우 RPC 서비스를 통해 서명 없이 NTLM 릴레이 공격을 수행할 수 있습니다. 여기 참조.
certipy를 사용하여 Enforce Encryption for Requests가 비활성화되었는지 열거하고 certipy가 ESC11 취약점을 표시할 수 있습니다.
남용 시나리오
릴레이 서버를 설정해야 합니다:
참고: 도메인 컨트롤러의 경우, DomainController에 -template를 지정해야 합니다.
또는 sploutchy의 impacket 포크을 사용할 수 있습니다:
YubiHSM을 사용한 ADCS CA에 대한 셸 액세스 - ESC12
설명
관리자는 인증서 기관을 "Yubico YubiHSM2"와 같은 외부 장치에 저장할 수 있습니다.
USB 장치가 CA 서버에 USB 포트를 통해 연결되어 있거나 CA 서버가 가상 머신인 경우 USB 장치 서버를 통해 YubiHSM에서 키를 생성하고 활용하기 위해 인증 키(때로는 "암호"로 지칭됨)가 필요합니다.
이 키/암호는 레지스트리에 HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword에 평문으로 저장됩니다.
참조 여기.
남용 시나리오
CA의 개인 키가 물리적 USB 장치에 저장된 경우 셸 액세스를 얻으면 키를 복구할 수 있습니다.
먼저 CA 인증서(이는 공개적인 정보)를 획들한 후:
OID 그룹 링크 남용 - ESC13
설명
msPKI-Certificate-Policy 속성을 사용하면 인증서 템플릿에 발급 정책을 추가할 수 있습니다. 발급 정책을 담당하는 msPKI-Enterprise-Oid 객체는 PKI OID 컨테이너의 Configuration Naming Context (CN=OID,CN=Public Key Services,CN=Services)에서 발견할 수 있습니다. 이 객체의 msDS-OIDToGroupLink 속성을 사용하여 정책을 AD 그룹에 연결할 수 있으며, 이를 통해 사용자가 인증서를 제시하면 해당 그룹의 구성원인 것처럼 사용자를 인가할 수 있습니다. 여기에서 참조.
다시 말해, 사용자가 인증서를 등록할 권한이 있고 해당 인증서가 OID 그룹에 연결된 경우 사용자는 이 그룹의 권한을 상속할 수 있습니다.
OIDToGroupLink를 찾기 위해 Check-ADCSESC13.ps1을 사용하세요:
남용 시나리오
certipy find 또는 Certify.exe find /showAllPermissions을 사용할 수 있는 사용자 권한을 찾습니다.
만약 John이 VulnerableTemplate을 등록할 수 있는 권한을 가지고 있다면, 해당 사용자는 VulnerableGroup 그룹의 권한을 상속받을 수 있습니다.
템플릿을 지정하기만 하면, OIDToGroupLink 권한이 있는 인증서를 받을 수 있습니다.
인증서를 통한 포리스트 침범의 수동태로 설명
타협된 CA에 의한 포리스트 신뢰 깨기
크로스-포리스트 등록 구성은 비교적 간단하게 이루어진다. 자원 포리스트의 루트 CA 인증서는 관리자에 의해 계정 포리스트로 발행되며, 자원 포리스트의 엔터프라이즈 CA 인증서는 각 계정 포리스트의 NTAuthCertificates 및 AIA 컨테이너에 추가된다. 이러한 배치는 자원 포리스트의 CA가 관리하는 모든 다른 포리스트에 대해 완전한 통제권을 부여한다. 만약 이 CA가 공격자에 의해 타협되면, 자원 및 계정 포리스트의 모든 사용자를 대상으로 인증서가 위조될 수 있어, 이로써 포리스트의 보안 경계가 깨질 수 있다.
외부 주체에게 부여된 등록 권한
다중 포리스트 환경에서는 인증된 사용자 또는 외부 주체 (엔터프라이즈 CA가 속한 포리스트 외부의 사용자/그룹)에게 등록 및 편집 권한을 허용하는 인증서 템플릿을 발행하는 엔터프라이즈 CA에 대한 주의가 필요하다. 신뢰를 통해 인증되면, AD에 의해 사용자의 토큰에 인증된 사용자 SID가 추가된다. 따라서, 도메인이 인증된 사용자 등록 권한을 허용하는 템플릿을 보유하고 있다면, 다른 포리스트의 사용자가 템플릿에 등록할 수 있다. 마찬가지로, 템플릿에 의해 외부 주체에게 명시적으로 등록 권한이 부여된 경우, 포리스트 간 액세스 제어 관계가 생성되어, 한 포리스트의 주체가 다른 포리스트의 템플릿에 등록할 수 있게 된다.
두 시나리오 모두 한 포리스트에서 다른 포리스트로의 공격 표면을 증가시킨다. 인증서 템플릿의 설정은 공격자가 외부 도메인에서 추가 권한을 얻기 위해 악용될 수 있다.
Last updated
