CVE-2025-60704: Windows Kerberos S4U의 유효성 검사 결함: 프로토콜 전환부터 권한 상승까지

케르베로스 제한 위임(Kerberos Constrained Delegation)은 서비스 또는 애플리케이션이 사용자를 대신하여 작업을 수행해야 할 때 사용되는 케르베로스의 가장 메커니즘입니다. 

2025년 7월, 저는 윈도우가 가장 하위 프로토콜 내에서 무결성 검사를 시행하는 방식에서 흥미로운 문제점을 발견했습니다. 

구체적으로 말하자면, 기존 RSA-MD4 지원 기능과 이러한 무결성 검사 중 하나의 클라이언트 측에서 암호화 유효성 검사 단계가 누락된 점이 결합되어 보호되어야 할 필드를 조작할 수 있게 되었습니다. 여기에는 사칭 대상 사용자의 신원 정보도 포함됩니다. 

적절한 조건 하에서, 이러한 행동은 위임 신뢰 가정을 우회하는 데 악용될 수 있으며, 이는 다음과 같은 결과를 초래할 수 있습니다. 승인되지 않은 접근   권한 상승. 

케르베로스와 위임: 배경 

케르베로스는 강력한 암호화 기본 요소를 기반으로 구축된 네트워크 인증 프로토콜입니다. 주요 목표는 다음과 같습니다. 상호 인증이를 통해 사용자와 애플리케이션 모두 서로의 신원을 확인할 수 있습니다. 

케르베로스에서 가장(Impersonation)은 오래전부터 존재해 왔습니다. 최초의 MIT 케르베로스 사양은 위임 메커니즘을 도입했습니다. RFC 4120 (2005) 실제로 그것은 본질적으로 티켓을 패스하는 것을 특징으로 합니다.. 

마이크로소프트는 위임 기능을 다른 방식으로 구현하기로 결정했습니다. 다음과 같은 도입을 통해 위임 기능을 구현했습니다. 사용자 서비스(S4U) in 윈도우 서버 2008그리고 이후의 개선 사항들 윈도우 서버 2012마이크로소프트는 두 가지 서로 다른 형태를 포함하여 자체 프로토콜 확장 기능을 추가했습니다. 제한된 위임. 

케르베로스와 케르베로스 위임단은 블로그와 연구 자료에서 광범위하게 다뤄져 왔습니다. 이러한 자료들 중 일부는 본 연구에 영감과 기초적인 참고 자료로 활용되었습니다. 

• 개를 흔드는 – 엘라드 샤미르 
• RC4는 여전히 유해한 것으로 간주됩니다. – 프로젝트 제로 (제임스 포쇼) 
• S4U2Pwnage – 하르미제이 

이 글에서는 케르베로스에 대한 일반적인 소개는 의도적으로 생략하고 마이크로소프트의 위임 확장 기능 구현에 집중하겠습니다.  

취약점 자체를 살펴보기 전에, 먼저 이러한 기능들이 어떻게 작동해야 하는지 이해해야 합니다. 

케르베로스 대표단  

위임은 서비스가 사용자를 대신하여 리소스에 접근할 수 있도록 하는 메커니즘입니다. Active Directory위임은 다계층 애플리케이션이 자격 증명을 복사하거나 애플리케이션 수준의 가장을 구현하지 않고 권한 부여 컨텍스트를 유지하는 방법입니다. 

기본 아이디어는 간단합니다. 사용자는 인증을 받습니다. 서비스 1 (프런트엔드)그리고 해당 서비스는 접근 권한이 필요합니다. 서비스 2 (백엔드) 사용자로서. 

기존 케르베로스 인증 방식은 어떻게 되나요? 

표준 케르베로스 흐름에서: 

1. 사용자가 프런트엔드에 인증하고 다음을 표시합니다. 서비스 티켓. 
2. 프런트엔드는 다음과 같은 이유로 해당 티켓을 재사용하여 백엔드에 인증할 수 없습니다. 
   • 티켓은 기본적으로 전달되지 않음. 
   • 티켓은 암호화되어 있습니다. 프런트엔드의 장기적인 핵심따라서 프런트엔드만 이를 해독할 수 있습니다. 

또 다른 방법은 프런트엔드에서 요청하는 것입니다. 자신의 백엔드로 서비스 티켓을 보냅니다. 하지만 이로 인해 새로운 문제가 발생합니다. 

1. 권한 부여 컨텍스트는 더 이상 사용자의 것이 아니라 서비스 계정의 것입니다. 
2. 보안 관점에서 볼 때, 이는 백엔드가 프런트엔드를 완전히 신뢰해야 함을 의미합니다. 
   • 서비스에 백엔드 리소스에 대한 무제한 액세스 권한을 부여하는 것은 일반적으로 허용되지 않습니다. 
   • 단순히 "일을 원활하게 진행하기 위해" 애플리케이션에 포괄적인 접근 권한을 부여해서는 안 됩니다. 

예시: 캘리포니아 온라인 등록 

CA 웹 애플리케이션을 예로 들어 보겠습니다. https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/configure-kerberos-constrained-delegation. 

먼저 사용자는 인증서 서비스 웹 인터페이스를 호스팅하는 IIS에 인증합니다. IIS는 RPC를 통해 CA 백엔드와 통신하여 사용자에게 인증서를 발급하는 역할을 합니다. 

이 시점에서: 

• IIS는 사용자의 서비스 티켓을 보관합니다. 
• IIS는 이제 인증이 필요합니다. CA의 RPCSS 사용자로서. 

하지만 사용자의 티켓은 단순히 전달될 수 없습니다. 

• IIS의 장기 암호화 키로 암호화되어 있습니다. 
• CA는 암호화된 티켓이 필요합니다. 그 자체의 열쇠 이를 해독하고 사용자를 인증합니다. 

IIS가 자체 인증을 사용하는 경우 자신의 서비스 티켓: 

1. 발급된 증서는 다음 사람에게 귀속됩니다. 서비스 계정, 사용자가 아닙니다. 
2. 또는 애플리케이션이 자체적인 가장 로직을 구현하여 IIS가 어떤 인증서를 발급할지 결정하도록 할 수도 있습니다. 
   • 이로 인해 민감한 권한 부여 결정이 애플리케이션 로직으로 이동하게 됩니다. 
   • 이러한 종류의 권한을 애플리케이션에 부여해서는 안 됩니다. 

이 문제에 대한 해결책은 다음과 같습니다. 케르베로스 대표단: 서비스 1(프런트엔드)이 명시적으로 가장되는 제어된 형태의 가장 행위 신뢰할 수있는 사용자가 서비스 2(백엔드)에 접근할 때 사용자를 대신하여 작업을 수행합니다. 

케르베로스 위임 유형: 제약 없음 / 제약 있음 

케르베로스 위임에는 크게 두 가지 유형이 있습니다. 무제한 위임   제한된 위임둘 다 서비스가 사용자를 대신하여 작동할 수 있도록 한다는 핵심 문제를 해결하는 것을 목표로 하지만, 접근 방식과 보안 측면에서 차이가 있습니다. 

무제한 위임 

제약 없는 위임은 다음에 의존합니다. 위임해도 괜찮습니다 플래그를 사용하면 서비스가 사용자의 정보를 수신하고 재사용할 수 있습니다. TGT를 전달했습니다즉, 서비스가 무제한 위임에 대해 신뢰를 얻게 되면, 해당 서비스는 사실상 사용자의 TGT(임시 위임 토큰)를 보유하게 되며 사용자를 사칭할 수 있습니다. 어떤 해당 도메인 내의 서비스입니다. 이로 인해 제약 없는 위임이 강력해지지만, 해당 서비스가 손상될 경우 위험하기도 합니다. 

제한된 위임(KCD) 

제한적 위임은 보다 통제된 접근 방식을 취합니다. 사용자의 TGT를 넘겨주는 대신, 프런트엔드 서비스가 이를 처리하도록 신뢰합니다. 특정 백엔드 서비스에 대해서만 사용자를 가장합니다. 사용하여 전달 가능한 서비스 티켓. 

자원 기반 제약 위임(RBCD)  

RBCD는 KCD의 최신 진화형으로, 대상 리소스 프런트엔드 서비스 계정에서 위임 권한을 구성하는 대신, 어떤 서비스가 해당 계정에 위임할 수 있는지를 제어합니다. 

KCD와 RBCD는 제약 없는 위임에 비해 공격 표면을 크게 줄여줍니다. 적어도 이론상으로는 그렇습니다. 

더 자세한 내용을 보려면 다음 링크를 클릭하세요. https://www.silverfort.com/glossary/kerberos-delegation/. 

KCD와 RBCD는 모두 마이크로소프트에서 구현한 케르베로스 프로토콜 확장 기능인 MS-SFU입니다. 

Microsoft Service-For-User Protocol 확장 

마이크로 소프트 사용자 서비스(S4U) 프로토콜 확장 기능은 서로 관련된 두 가지 메커니즘을 정의합니다. 프로토콜 전환   제한된 위임이 모델에서 서비스는 자체 기능을 사용합니다. TGT 소유 사용자 주체를 포함하는 특수 케르베로스 티켓을 요청하는 동안, KDC는 여전히 책임이 있습니다. 위임 정책을 시행하기 위해 다음을 기반으로 합니다. Active Directory 구성. 

S4U 확장 기능은 두 가지 TGS 하위 프로토콜을 도입합니다. 

S4U2Self (사용자가 스스로에게 제공하는 서비스) 
S4U2Self는 TGS-REQ 서브프로토콜로 사용됩니다. 프로토콜 전환이 기술은 최종 사용자가 Kerberos를 사용하여 애플리케이션에 인증하지 않지만, 애플리케이션이 사용자의 신원을 나타내는 Kerberos 티켓을 획득해야 하는 시나리오를 처리하도록 설계되었습니다. 

S4U2Proxy (사용자-프록시 서비스) 
S4U2Proxy는 TGS-REQ 서브프로토콜로서, 특정 작업을 수행하는 데 사용됩니다. 제한된 위임그 목적은 얻는 것이다. 전달 가능한 서비스 티켓 이전에 설정된 인증 증거를 사용하여 사용자를 대신하여 하위 서비스에 정보를 전송합니다. 

이 두 하위 프로토콜은 독립적인 메커니즘으로 작동하며 별도로 사용할 수 있습니다. 하지만 실제로는 종종 함께 사용됩니다. 서로 연결되어 있다S4U2Self는 증거 티켓을 생성하고, 이 티켓은 S4U2Proxy에 의해 사용되어 위임된 접근 권한을 완료합니다. 

S4U2Proxy – 제한된 위임 

S4U2프록시 TGS-REQ 실제 제약 조건이 있는 위임 메시지입니다. 서비스는 하위 서비스에 티켓을 요청합니다. 타겟 SPN 해당 사용자를 대신하여 사용자의 티켓을 증거로 제공합니다. KDC는 위임 정책(KCD 또는 RBCD)을 시행하고, 허용되는 경우 증거 티켓에서 파생된 클라이언트 ID를 사용하는 하위 티켓을 발급합니다. 

일반적인 TGS 요청과 달리 S4U2Proxy는 다음을 제공해야 합니다. 증거 사용자가 이미 인증되었다는 증거는 다음 두 가지 방법 중 하나로 얻을 수 있습니다. 

• (케르베로스 인증이 사용된 경우) 사용자가 처음 제시한 서비스 티켓에서 또는 

• 다음을 통해 얻은 서비스 티켓에서 S4U2셀프. 

S4U2Proxy는 수정된 형태로 구현되었습니다. TGS-REQ 및 TGS-REP  그리고 변화를 도입합니다 KDC 옵션, PA-데이터, PAC   추가 티켓. 

S4U2Proxy TGS-REQ 주요 매개변수 

1. The KDC 옵션 제한된 위임(cname-in-addl-tkt라고도 함) 설정해야 합니다. 
   • 이 플래그는 KDC에게 클라이언트 주체 식별자(CPRI)를 추출하도록 지시합니다.이름) 로부터 추가 티켓일반적인 TGS-REQ에서처럼 인증 기관으로부터가 아니라, 
2. 하나 이상 추가 티켓 포함되어야 합니다. 
   • 이 티켓은 인증된 사용자를 나타냅니다. 
3. (선택 사항) 클라이언트에는 다음이 포함될 수 있습니다. PA-PAC-옵션 요청하려면: 
   • 자원 기반 제약 위임(RBCD) 
   • 청구 기반 승인 

이 단계에서 KDC는 다음 두 가지를 모두 검증합니다. 위임 권한 요청하는 서비스와 증거의 무결성 티켓. 

예시: S4U2Proxy TGS-REQ  

S4U2프록시 TGS-REP 

결과 TGS-REP 사용자가 직접 요청한 서비스 티켓처럼 보입니다. 하지만 추가적인 인증 메타데이터가 포함되어 있습니다. PAC. 

구체적으로 KDC는 다음을 추가합니다. S4U_위임_정보 두 개의 핵심 영역을 포함하는 구조: 

• S4U2프록시타겟 대상 서비스의 SPN 
• S4UTransitedServices - 해당 사용자를 사칭한 계정 

이 정보는 다음과 같은 목적으로 제공됩니다. 애플리케이션에 의해 검증됨 티켓을 수령하여 이해할 수 있도록 합니다. 누구 사칭을 당하고 있습니다. 어떤 서비스가 위임을 수행했습니까?. 

예시: S4U2Proxy TGS-REP 

앞서 언급했듯이, 사용자가 Kerberos 프로토콜이 아닌 다른 프로토콜을 사용하여 애플리케이션을 인증한 경우, S4U2Self 프로토콜을 사용하여 인증 티켓을 요청해야 합니다. 

S4U2Self – 프로토콜 전환  

S4U2Self는 TGS-REQ 하위 프로토콜 프로토콜 전환에 사용됩니다. 최종 사용자가 다음과 같은 상황을 처리하도록 설계되었습니다. 지원 Kerberos를 사용하여 애플리케이션에 인증하지만, 애플리케이션은 여전히 ​​사용자의 보안 컨텍스트에서 하위 리소스에 대한 Kerberos 서비스 티켓을 획득해야 합니다.  

실질적으로, 서비스 계정에 TRUSTED_TO_AUTH_FOR_DELEGATION 권한이 구성되면 사용자계정컨트롤 플래그는 도메인이 해당 서비스를 명시적으로 신뢰함을 나타냅니다. 사용자를 대신 인증합니다.도메인 컨트롤러가 초기 인증을 수행하도록 하는 대신, 자체적으로 인증을 수행합니다.

이러한 신뢰를 통해 서비스는 요청할 수 있습니다. S4U2셀프 서비스 티켓 이는 사용자와 서비스 간에 Kerberos 인증이 이루어지지 않았더라도 사용자의 신원을 나타냅니다. 

S4U2Self TGS-REQ 주요 매개변수 

S4U2Self 요청은 일반 TGS 요청과 몇 가지 중요한 점에서 다릅니다. 

• The 사기 필드가로 설정되었습니다 자기 (예: machineaccount1$). 

• TGT와 인증기 이름 또한 이러한 신원은 신뢰할 수 있는 계정을 나타냅니다. 

이 시점에서 서비스는 여전히 명시해야 합니다. 어떤 사용자를 사칭하려는 것인가사용자와 서비스 간에 Kerberos 인증이 이루어지지 않았으므로 티켓 자체에서 사용자 신원을 확인할 수 없습니다. 

이는 다음 두 가지 방법 중 하나를 사용하여 수행됩니다. 사전 인증 데이터(PA-DATA) 구조: 

• PA-FOR-USER – 사용자 이름 기반 식별  

• PA-FOR-X509-USER – 인증서 기반 신원 확인 

예시: S4U2Self TGS-REQ

다음 섹션에서는 이러한 데이터 구조 간의 차이점을 이해하고 약점을 살펴보겠습니다. 

PA-데이터 유형 129: PA-FOR-USER – 사용자 이름 기반 식별  

이것은 가장 간단하고 일반적으로 사용되는 PA-DATA 구조입니다.  

모든 입력란은 필수입니다. 

• userName.type – 기본값은 0(NT-UNKNOWN)입니다. 
• userName.name-string – 사용자 이름 또는 UPN 
• userRealm – 사용자의 영역 
• 인증 패키지 – 문자열 "Kerberos" 

체크섬 (정액) 위의 모든 필드에 대해 다음과 같은 방식으로 계산됩니다. 

S4UByteArray =  
(LE 4-Byte int) userName.type +  
userName string +  
userRealm string +  
“Kerberos” 

An HMAC-MD5 체크섬은 다음을 사용하여 계산됩니다. 

• The TGT 세션 키 
• 주요 사용 번호 17 (KERB_NON_KERB_CKSUM_SALT) 
• S4UByteArray 

cksum = HMAC-MD5(SessionKey, 17, S4UByteArray) 

이 설계는 공격자가 다음 사항을 알아야 함을 보장합니다. TGT 세션 키 구조체의 모든 필드를 수정할 수 있습니다. 

그리고 공격자가 이미 세션 키를 가지고 있다면, 그때는 또 다른 문제가 발생합니다.  

PA-DATA TYPE 130: PA-FOR-X509-USER – 인증서 기반 식별  

이 데이터 구조는 더 복잡하고 보안 관점에서 훨씬 더 흥미롭습니다. 

이는 두 가지 주요 구성 요소로 구성됩니다. 

1. 사용자 ID (S4UUserID)사용자 신원 정보를 담고 있는 
2. 체크섬이는 무결성 보호를 제공하기 위한 것입니다. 

사용자 ID(S4UUserID) 

The S4UUserID 해당 구조에는 KDC가 궁극적으로 신뢰하게 될 신원 정보가 포함되어 있습니다. 

필수 입력 항목:  

• 로마 교황 사절: KDC 요청 본문에서 복사함 
• 크렐름: 사용자의 영역  

선택 입력 항목: 

이름 생략할 경우 인증서를 제공해야 합니다. CNAME이 없으면 KDC는 인증서 확장 프로그램에서 사용자 ID를 추출합니다. 

과목 인증서: DER 인코딩됨 공개 키 X509 인증서   

옵션: 추가 플래그:  

체크섬   

체크섬은 DER로 인코딩된 사용자 ID(S4UUserID) 구조체에 대해 계산됩니다. 

PA DATA 129에서는 체크섬이 항상 TGT의 세션 키를 사용한 HMAC-MD5 방식이지만, 여기서는 체크섬 유형이 다릅니다. TGT 세션 키 암호화 유형에 따라 다릅니다.(!) 

예 : 

• TGT 세션 키 유형이 다음과 같을 경우 AES256-CTS-HMAC-SHA1-96(18),  체크섬 유형은 다음과 같습니다.  HMAC-SHA1-96-AES-256 (16) 
• TGT 세션 키 유형이 다음과 같을 경우 AES128-CTS-HMAC-SHA1-96(17),  체크섬 유형은 다음과 같습니다. HMAC-SHA1-96-AES-128 (15) 

하지만 구형의 "새로운" 암호화 방식이 사용될 경우, 유산 체크섬 알고리즘을 사용할 수 있습니다. 

예 : 

• TGT 세션 키 유형이 다음과 같을 경우 RC4-HMAC-NT(23), 그렇다면 체크섬 유형은 다음과 같을 수 있습니다. RSA-MD4(2) 

HMAC 기반 체크섬은 다음과 같습니다. 건이 있는즉, 그들의 진실성은 통신 당사자들만이 알고 있는 비밀 자료에 달려 있다는 뜻입니다. 이와 대조적으로, RSA-MD4 는 Teledyne LeCroy 오실로스코프 및 LSA-XNUMX 시리즈 임베디드 신호 분석기가  키가 없는 체크섬. 

RFC3961에 따르면 RSA-MD4 메시지 무결성 검사(MIC)는 단순히 md4(메시지) 세션 키가 필요하지 않습니다. 

키가 없는 체크섬은 변조 방지 기능을 제공하지 않으며 평문 구조를 보호하는 데 적합하지 않습니다. 따라서 사용을 권장하지 않으며 기존 시스템과의 호환성을 위해서만 존재합니다. 

S4U의 맥락에서, 결과적으로 생성되는 PA-DATA 구조는 두 가지 모두를 지원할 수 있을 만큼 충분히 유연합니다. 인증서 기반   사용자 이름 기반 신원 주장 S4U2셀프실제로 이러한 구조들은 공존할 수 있으며, 어떤 경우에는 함께 전달되기도 합니다. 

이것이 중요한 이유 

요점은 사용자 자격 증명은 필요하지 않습니다. 사용자를 대신하여 Kerberos 티켓을 발급받기 위한 것입니다. 사용자 신원을 확인하는 데 필요한 유일한 입력값은 다음과 같습니다. 사용자 이름 문자열.  

S4U 흐름 중 하나에서 해당 문자열은 다음과 같습니다. 암호화 방식으로 보호되지 않음 공격자에 의한 수정으로부터 보호합니다. 

즉, 공격자가 해당 문자열을 제어할 수 있다면 전체를 제어할 수 있다는 의미입니다. 사칭 흐름그 결과로 생성된 티켓은 다음으로 전달됩니다. S4U2프록시이는 S4U2Self 결과를 맹목적으로 신뢰하는 것입니다. 그 시점부터 위임 체인은 설계된 대로 진행됩니다. 

이러한 약점을 해결하기 위해 마이크로소프트는 보완적인 보안 조치를 도입하려고 시도했습니다. 

클라이언트(애플리케이션) 측에서: 

• 때 "더 새롭지 않은" TGT 세션 키만 사용됩니다. PA-DATA 129 허용됩니다. 
• PA-FOR-X509-USER 전송되지 않습니다. 
• 그 결과, MD4 기반 체크섬은 나타나지 않아야 합니다. 요청 내용에. 

서버(KDC) 측에서: 

• 인셀덤 공식 판매점인 MD4 는 사용됩니다. 의뢰   댓글 체크섬 값은 내부에 포함되어 있습니다. 암호화된 부분 KDC의 답변 중 일부입니다. 
• 이러한 값들은 클라이언트로 반환되며, 클라이언트는 이를 보완적인 무결성 검사로 검증해야 합니다. 

CVE-2025-60704 1부: PA-S4U-X509-USER에서 다운그레이드가 활성화된 키 없는 체크섬 취약점 

원시적 개요 

첫 번째 기본 요소는 강제로 작동시킬 수 있는 능력입니다. 인증서 기반 S4U2Self 신원 주장 유산으로, 키가 지정되지 않은 체크섬 모드. 

이는 보안과 관련이 있는데, 그 이유는 체크섬이 보호 기능을 하기 때문입니다. S4UUserID 구조는 다음을 기준으로 선택됩니다. 서비스의 TGT 세션 키에 대해 협상된 암호화 유형만약 그 협상의 결과가 다음과 같다면 RC4에서 사용되는 체크섬 PA-S4U-X509-유저 저하될 수 있습니다 RSA-MD4암호화 키를 제공하지 않습니다. 

이러한 상황이 발생하면 주장된 사용자 신원의 무결성 보호가 사실상 상실됩니다. 

1단계: 중간자 공격(MITM)을 통해 TGT 암호화 유형을 다운그레이드합니다.  

MD4 코드 경로에 도달하려면 애플리케이션(이하 "애플리케이션"이라 함) 사이의 경로에 변이 코드를 삽입해야 합니다.Client"부터는" (KDC)서버", 그리고 Kerberos 교환에 사용되는 암호화 유형을 낮춥니다. 즉, 강제로 AS-REQ 협상하다 RC4-HMAC (etype 23). 

윈도우에서는 이 과정이 매우 간단합니다. 

• 기본값은 AS-REQ 서명이나 날인 없이 평문으로 전송됩니다. 
• 클라이언트는 정책에서 허용하는 경우 이전 암호화 유형을 협상합니다. 

수정 후 KDC는 다음과 같이 응답합니다. AS-REP그리고 새로운 TGT가 캐시에 설치됩니다. 

결과 : 
TGT 세션 키는 이제 다음과 같습니다. RC4-HMAC-MD5 (etype 23). 

클라이언트 행동 관찰: 키가 지정되지 않은 체크섬에 대한 보호 기능 하향 조정 

예상대로 클라이언트의 행동은 다음과 같습니다. S4U2셀프 TGS-REQ 변화할 때 RC4 세션 키 암호화 유형으로 사용됩니다. 

• 만 PA-DATA 129 (PA-FOR-USER) 보냈다. 
• PA-DATA 129는 사용하도록 하드코딩되어 있습니다. HMAC-MD5. 

현재 마이크로소프트는 클라이언트 측 제한 의도한 대로 작동하는 것으로 보입니다. 

서버 측 동작 및 바이패스 조건 

이러한 제한을 어떻게 우회할 수 있는지 이해하려면 다음을 살펴봐야 합니다. 서버 측 구현특히 KDCSVC!KdcFindS4UClientAndRealm의 KDC 로직에 문제가 있습니다. 

이 기능은 간단한 의사 결정 흐름을 따릅니다. 

1. 먼저 전화를 겁니다 KerbFindPerAuthDataEntry 찾다 PA-DATA 130형. 
2. PA-DATA 130을 찾을 수 없는 경우, 다음으로 대체됩니다. PA-DATA 129형. 
3. 그 다음에는 추가적인 검증 단계가 진행됩니다. 

이러한 행동은 중요한 의미를 지닙니다. 만약 PA-DATA 유형이 두 가지 모두 존재합니다., PA-DATA 129는 무시됩니다. PA-DATA 130을 지지합니다. 

이 단계에서 KDC는 협상된 암호화 유형에 대한 유효성 검사를 수행하지 않으며 RC4 ​​사용 시 허용되는 PA-DATA 구조에 대한 어떠한 제한도 적용하지 않습니다. 또한 세션 키 유형과 신원 확인에 사용되는 PA-DATA 간에 암호화 바인딩이나 변조 방지 기능이 없기 때문에 공격자는 조작된 키를 삽입할 수 있습니다. PA-DATA 130형 RC4 기반 거래소에서도 마찬가지입니다.  

즉, 클라이언트는 PA-DATA 130을 전송하지 않지만, 공격자가 이를 추가하는 것을 막을 방법은 없습니다. 

2단계: PA-DATA 130 주입 

이 시점에서 중간자 공격자는 추가적인 신호를 주입할 수 있습니다. PA-S4U-X509-USER (유형 130) 요소에 S4U2셀프 TGS-REQ. 

주입된 PA-DATA에는 공격자가 선택한 신원이 인코딩되어 있습니다. S4UUserID 구조. 예를 들어 다음과 같이 명시적으로 설정함으로써 이를 수행할 수 있습니다. 

• 이름 대상 계정으로 
• 크렐름 대상 도메인으로 

다른 선택적 필드는 생성 모드에 따라 포함되거나 생략될 수 있습니다. 

체크섬이 이제 키에 의존하지 않으므로 계산은 다음과 같습니다. 

Checksum = md4(DER(S4UUserID)) 

결과 

요청이 처리될 때 KDC는 다음을 검사합니다. 첫 번째 PA-DATA 타입 130 입력, 선택 RSA-MD4 체크섬 알고리즘을 통해 요청을 유효한 것으로 판단하고 수락합니다. 따라서 위조된 신원 주장은 KDC에 의해 신뢰됩니다. 

파트 1의 성과 

파트 I이 성공하면 KDC는 클라이언트 주체와 PAC가 공격자가 선택한 ID에 해당하는 유효한 S4U2Self 서비스 티켓을 발급할 수 있습니다. 이는 S4U2Self 티켓이 이후 S4U2Proxy 과정에서 KDC에 제시되는 티켓이 되고, 하위 단계의 위임 티켓 ID가 이 티켓에서 파생되기 때문에 중요합니다. 

CVE-2025-60704 2부: 클라이언트 유효성 검사 프로세스 우회 

파트 I에서는 공격자가 선택한 신원을 나타내는 유효한 S4U2Self 서비스 티켓을 생성합니다. 그러나 이 결과만으로는 충분하지 않습니다. 티켓이 클라이언트에 설치되지 않기 때문입니다. S4U2Self 티켓은 이후의 S4U2Proxy 처리에 필요하며 사용 가능해야 하므로 이는 매우 중요한 문제입니다. 

2부에서는 설치를 방지하는 클라이언트 측 유효성 검사 로직과 티켓을 사용할 수 있게 하는 우회 방법을 설명합니다. 

TGS-REP 암호화된 pa-데이터 

MS-SFU는 기존 또는 키가 없는 체크섬 모드에 대한 보완적인 무결성 메커니즘을 정의합니다. KDC가 TGS-REP의 암호화된 부분의 encrypted-pa-data 필드 내에 관련 S4U PA-DATA를 반환할 때, 클라이언트는 요청 및 응답과 관련된 체크섬 값을 반드시 검증해야 합니다. 이러한 설계의 목적은 응답을 복호화한 후에만 사용 가능한 값을 이용하여 요청과 응답 간의 연결을 강제하는 것입니다. 이는 호환성 체크섬 알고리즘을 사용할 때 외부 PA-DATA 구조가 공격자에 의해 수정될 수 있다는 점을 보완합니다. 

TL; DR  

제거 S4U 관련 PA-DATA 답장 메시지로 인해 클라이언트가 완전히 문제가 발생합니다. 검증 로직을 건너뛰세요 그리고 티켓을 받으세요. 

검증 과정을 자세히 이해할 필요가 없고 바로 활용 단계로 넘어가고 싶다면, 이 부분을 건너뛰셔도 됩니다. 1단계. 

이해하다 why 이 우회 방법이 작동하는지 확인하기 위해 먼저 KDC가 암호화된 응답을 구성하는 방식과 유효성 검사 데이터가 포함되는 방식을 살펴보아야 합니다. 다음 섹션에서는 이 과정을 단계별로 설명합니다. 

체크섬 유효성 검사 프로세스 이해 (KDC - 서버 측) 

서버 측에서는 이 로직이 여러 곳에 걸쳐 구현됩니다. KDCSVC.DLL   크립트딜.딜. 

유효성 검사 흐름은 kdcsvc!HandleTGSRequest에서 시작되는데, 이름과는 달리 이 함수는 TGSRequest를 처리합니다. 두 요청 및 회신 메시지 처리. 

요청 검증은 다음과 같이 수행됩니다. 

1. HandleTGSRequest는 클라이언트 이름을 추출하기 위해 kdcsvc!KdcFindS4UclientAndRealm을 호출합니다.
2. KerbFindPreAuthDataEntry 함수가 호출되어 해당 위치를 찾습니다. PA-DATA 130형. 
3. 해당 구조체는 체크섬 검증을 위해 KerbSignS4UpreauthDataEx로 전달됩니다. 
4. 체크섬 유형은 먼저 다음 명령어를 사용하여 암호화 유형을 확인한 후 선택됩니다. 
   • cryptdll!CDLocateCSystem 
   • crytdll!CDLocateCheckSum 
5. 확인된 암호화 유형에 따라 적절한 체크섬 알고리즘이 선택됩니다. 
   • 등급 하락 시나리오에서는 다음과 같이 해결됩니다. MD4. 
6. KDC는 체크섬을 계산합니다. 의뢰 그리고 클라이언트가 제공한 체크섬과 비교합니다. 

결과가 유효하면 HandleTGSRequest는 BuildReply를 호출하여 응답 메시지를 구성하고 다음 단계를 진행합니다. 

1. KerbSignS4UPreauthDataEx 함수가 다시 호출되어 전체 체크섬을 계산합니다. 댓글. 
2. 암호화 유형이 다음과 같으면 AES가 아님KDC는 KdcAddEncryptedS4uPaData를 호출합니다. 
3. KDC는 계산된 체크섬을 연결합니다. 의뢰 체크섬은 다음과 같이 계산됩니다. 댓글. 
4. 요청 체크섬이 유효하면 KDC는 응답을 구성합니다. 
5. 두 체크섬 값(16바이트 요청 + 16바이트 응답)은 모두 다음과 같이 저장됩니다. pa-for-x509-user 아래의 암호화된 pa-데이터 TGS-REP의 섹션.   
6. 응답의 암호화된 부분은 세션 키를 사용하여 봉인된 후 클라이언트로 다시 전송됩니다. 

클라이언트가 TGS-REP를 수신하면 세션 키를 사용하여 메시지의 암호화된 부분을 복호화해야 합니다. PA-DATA 130형 및 평문 체크섬을 비교합니다. 댓글 와 더불어 마지막 16바이트 암호화된 PA-DATA의 첫 16바이트를 클라이언트 요청과 비교합니다.  

이러한 모든 검사가 성공한 경우에만 티켓을 승인하고 캐시에 설치해야 합니다. 

체크섬 유효성 검사 프로세스(클라이언트 측) 

클라이언트 측에서는 체크섬 유효성 검사 로직이 다음과 같이 구현됩니다. 케르베로스.DLL주로 'kerberos!KerbCheckX509S4uReply'라는 매우 직관적인 이름을 가진 함수 내에서 이러한 역할을 수행합니다. 이 함수는 케르베로스 인증에 적용되는 보상 무결성 메커니즘의 유효성을 검사하는 역할을 합니다. PA-S4U-X509-유저 답글. 

클라이언트가 암호화된 부분을 수신하고 복호화하면 검증 흐름이 시작됩니다. TGS-REP처리 논리는 다음과 같이 진행됩니다. 

1. 클라이언트는 응답 메시지에 예상되는 S4U 관련 구조가 포함되어 있는지 확인합니다. 
2. KerbFindPreAuthDataEntry 함수는 해당 위치를 찾기 위해 호출됩니다. PA-DATA 130형. 
3. PA-DATA 유형 130이 발견되면 클라이언트는 전체 체크섬을 계산합니다. 댓글 KerbCredIsoIum::SignS4UPreauthData를 사용합니다. 
4. 계산된 응답 체크섬은 KDC에서 제공한 체크섬 값과 비교됩니다. 
5. 이제 클라이언트는 세션 키와 연결된 암호화 유형을 확인합니다. 
   • 암호화 유형이 다음과 같으면 AES(etype 18 / 0x12)유효성 검사가 성공했으므로 추가적인 검증은 수행되지 않습니다. 

암호화 유형이 다음과 같을 때 RC4 (e타입 23)해당 함수는 다른 제어 경로를 따릅니다. 

6. 고객은 다음을 기대합니다. 암호화된 PA-DATA 유형 130 둘 다 포함함: 
   • 에코된 체크섬 댓글그리고 에코된 체크섬은 다음과 같습니다. 원래 요청. 
7. 해당 코드는 체크섬 버퍼의 크기를 확인하고 원래 요청에 대해 계산된 체크섬이 포함되어야 하는 버퍼를 추출하려고 시도합니다. 
8. 클라이언트는 이 값을 요청에 대해 로컬에서 계산된 체크섬과 비교하려고 시도합니다. 

이 시점에서 유효성 검사가 실패합니다. 

클라이언트 절대 계산하지 않습니다 요청에 대한 MD4 체크섬따라서 에코된 요청 체크섬과 비교할 로컬 값이 없습니다. 결과적으로 함수는 오류와 함께 종료되고 티켓이 설치되지 않습니다. 

가능한 성공 경로를 분석하는 과정에서 한 가지 분기가 두드러집니다. 만약 PA-DATA 유형 130이 없습니다.코드는 레이블이 지정된 내부 분기로 이동합니다. 라벨72이 경로에서는 여러 플래그를 확인하고 반환 값을 0으로 설정한 후 함수가 성공을 반환합니다. 암호화된 pa-데이터 체크섬 바인딩 검증을 수행하지 않고. 

이러한 동작은 우회를 직접적으로 가능하게 합니다. 

1단계: 응답에서 PA-DATA 객체 제거  

padata-type 값을 130 이외의 다른 값으로 수정하거나 제거함으로써 PA-데이터 클라이언트가 응답 내용만으로 구조를 결정하면 엄격한 유효성 검사 경로를 거치지 않고 대체 경로를 따라 티켓의 무결성 검사를 수락하게 됩니다. 

요약하자면, 존재함 PA-DATA 130 클라이언트가 보완 무결성 검사를 시행할지 여부를 결정합니다. 이를 제거하면 유효성 검사 로직이 오류 없이 성공하여 위조된 S4U2Self 티켓이 설치 코드 흐름을 계속 진행할 수 있게 됩니다. 

2단계: 복원 이름 

이 단계에서 이름 반환된 티켓은 다음에서 복원되어야 합니다. 타겟 신원 다시 원래 사용자. 

이유는 미묘하지만 중요합니다. 해당 애플리케이션은 원래 다음과 같은 목적으로 사칭을 시작했습니다. 사용자 A하지만 조작된 S4U TGS-REP에는 이제 유효한 서비스 티켓이 포함되어 있습니다. 사용자 B가장 시도를 시작한 호스트가 이 티켓을 수신하면 예상 클라이언트 이름과 티켓의 CNAME이 일치하지 않아 티켓 설치가 실패합니다. 이는 성공적인 공격을 위한 추가적인 제약 조건을 만듭니다. 

하지만 공격자는 다음과 같은 사실을 악용할 수 있습니다. 이름 해당 필드는 무결성 보호 기능이 없습니다.반환된 티켓의 cname을 수정함으로써 사용자 B 뒤로 사용자 A그러면 티켓은 다시 한번 최초 로그인 세션의 기대치와 일치하며 승인됩니다. 

이러한 행동은 중요한 부차적인 문제점을 보여줍니다. 티켓 설치 과정에서 PAC에 대한 추가 검증은 수행되지 않습니다.클라이언트는 티켓에 포함된 PAC가 다른 사용자를 나타내더라도 표면적인 일관성 검사를 기반으로 티켓을 승인합니다. 

제2부의 성과 

이 시점에서 공격자는 유효한 정보를 얻습니다. S4U2셀프 서비스 티켓 설치된 것 사용자 A의 로그인 세션내장된 PAC는 사용자 B에 해당합니다.. 

이로써 클라이언트 측의 마지막 장벽이 제거되었습니다. 이제 티켓은 완전히 사용 가능하며 공격의 다음 단계에서 제시될 수 있습니다. S4U2프록시여기서 위임된 서비스 티켓의 식별자는 위조된 S4U2Self 티켓에서 파생됩니다. 

착취 및 실제 사례 

이러한 동작이 실제로 어떻게 악용될 수 있는지 보여주기 위해, 사용자 인증, 케르베로스 위임, 그리고 원격 파일 접근을 수행하는 간단한 웹 애플리케이션을 개발했습니다. CIFS.  

이 애플리케이션은 일반적인 다계층 패턴을 따릅니다. IIS 프런트엔드가 사용자를 인증한 다음 백엔드 파일 서버에 액세스 권한을 위임합니다.  

낮은 권한을 가진 도메인 계정(사용자)으로 인증한 후, 중간자 공격(MitM) 기법을 사용하여 관리자 권한을 획득하는 공격을 실행할 것입니다. 

해당 코드는 각 메시지를 검사하고 필요한 필드만 수정합니다. AS-REQ , TGS-REQ, TGS-REP 메시지는 다음과 같습니다. 

이 취약점을 이용하면 user1은 '관리자'(또는 민감하지 않은 다른 사용자) 권한 컨텍스트를 얻게 됩니다.

실제 사례 

이 취약점에 대한 실제 악용 시나리오를 조사하는 동안 두 가지를 확인했습니다. 민감하고 광범위하게 배포되는 애플리케이션 그 영향력을 보여주는 사례들입니다. 

인증기관 웹 등록 이 시스템은 기존의 다계층 모델에서 위임 기능을 사용합니다. IIS 프런트엔드는 사용자를 인증한 후 원격 인증 기관에 권한을 위임하여 사용자의 ID로 인증서를 발급하고, 도메인 정책, 템플릿 권한 및 발급 규칙을 적용합니다. 

Entra 애플리케이션 프록시 커넥터 기반 모델에서 위임 기능을 사용합니다. 온프레미스 커넥터는 프로토콜 전환 및 제한된 위임을 수행하여 클라우드 ID에서 온프레미스 Kerberos 애플리케이션으로의 단일 로그인(SSO)을 제공합니다. 

이러한 애플리케이션들은 서로 다른 비즈니스 목적을 가지고 있지만, 중요한 공통점을 공유합니다. 바로 둘 다 위임된 ID를 사용하여 민감한 하위 작업에 대한 권한을 부여한다는 점입니다. 결과적으로, 둘 다 다음을 나타냅니다. 고충격 확산 표면 위임된 신원의 무결성이 손상되었을 때. 

이러한 응용 프로그램들은 각각 악용될 수 있습니다. 독립하여더욱 중요한 것은, 그것들은 또한 다음과 같을 수도 있다는 것입니다. 결합 된이를 통해 한 계층에서의 정체성 혼란이 신뢰의 경계를 넘어 어떻게 확산될 수 있는지 보여주고 그 영향을 증폭시킵니다. 

캘리포니아 웹 등록   

인증 기관(CA) 웹 등록 서비스는 Microsoft에서 제공합니다. Active Directory AD CS(인증서 서비스)는 사용자와 컴퓨터가 인증 기관과 상호 작용할 수 있도록 웹 기반 인터페이스를 제공하는 서비스입니다. 

이는 사용자가 CA 서버와 직접적인 상호 작용 없이 웹 브라우저를 통해 인증서 요청을 제출하고, 인증서를 다운로드하고, 인증서 폐지 목록(CRL)을 검색할 수 있도록 하는 연결 고리 역할을 합니다. 

더 알아보기 : https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/configure-kerberos-constrained-delegation. 

Entra 애플리케이션 프록시 및 Kerberos 위임 

Entra 애플리케이션 프록시 이는 하이브리드 아이덴티티 아키텍처의 대표적인 예이며, 인증은 클라우드에서 수행됩니다.반면 인증은 Kerberos를 사용하여 온프레미스에서 시행됩니다.. 

간략히 설명하자면, Entra Application Proxy는 다음과 같은 역할을 합니다. 클라우드 기반 리버스 프록시 온프레미스 웹 애플리케이션의 경우, 사용자는 다음을 사용하여 애플리케이션에 인증합니다. Microsoft Entra ID 싱글 사인온그러면 인증된 세션은 터널링을 통해 전달됩니다. 온프레미스 애플리케이션 프록시 커넥터. 

커넥터는 이 두 세계를 연결하는 역할을 합니다. 

여기를 보아라: https://learn.microsoft.com/en-us/entra/identity/app-proxy/how-to-configure-sso-with-kcd. 

클라우드에서 사용자 인증이 완료되면 커넥터는 해당 ID를 온프레미스 서비스에서 이해할 수 있는 형식으로 변환해야 합니다. 백엔드 애플리케이션이 Kerberos를 사용하는 경우 이 변환은 다음을 사용하여 수행됩니다. S4U 프로토콜 전환.  

커넥터는 자체 Kerberos 컨텍스트를 사용하여 요청을 보냅니다. S4U2셀프 티켓 인증된 사용자를 나타낸 다음 사용합니다. 제한된 위임(S4U2Proxy) 하위 온프레미스 리소스에 대한 서비스 티켓을 발급받기 위해서입니다. 

즉, 프로토콜 변환은 여기서 예외적인 경우가 아니라 필수적인 사항입니다. 디자인의 기본 요소. 

그림 20마이크로소프트 가이드에 나오는 구성 예시로, 설계된 프로토콜 전환 방식을 보여줍니다. 

이는 본 연구에서 설명하는 취약점 연쇄에 필요한 조건과 정확히 일치합니다. 클라우드 인증, 프로토콜 전환 및 제한된 위임이 설계상 결합될 경우, S4U 신뢰 모델의 결함이 보안상 중요한 문제로 대두됩니다. 

여기에서 Entra Proxy 앱과 CA WebEnroll의 예시를 확인하세요.

주요 테이크 아웃 

인격화먼저 이해하고, 그 다음에 구현하십시오. 위임과 S4U(서비스 포 언리미티드)는 서비스가 사용자를 대신하여 작업을 수행할 수 있도록 합니다. 사용자를 "대신하여" 티켓을 요청할 수 있는 모든 시스템은 보안 경계로 간주해야 합니다. ID의 출처, 바인딩 방식, 그리고 이를 강제하는 구성 요소를 제대로 이해하지 못하면 위임이 오히려 문제 발생의 원인이 될 수 있습니다. 

인증 보안은 가장 약한 연결 고리만큼만 강력합니다. 티켓 계층에서 강력한 암호화를 사용하더라도 신원 정보가 취약한 경로를 통해 입력되거나, 취약한 방식으로 협상되거나, 취약한 검증 분기를 통해 승인된다면 소용이 없습니다. 종단 간 신원 보증은 체인에서 가장 보호가 취약한 단계에 의해 결정됩니다. 

올바른 기술과 올바른 사용법: 

• 해싱 ~에 사용됩니다. 보전. 

• 서명/MAC 에 사용된다 진정성과 성실성. 

• 봉인(암호화) ~에 사용됩니다. 기밀 유지. 

이 경우, 오직 청렴함만이 의지되었다. 어디에 보전   정품 필요했다.  

완화 

1. 벤더에서 제공하는 수정 사항을 적용하고 동작을 검증합니다. Windows 시스템에 패치를 적용합니다. 2025년 11월 보안 업데이트 안내 또한 도메인 컨트롤러와 프로토콜 전환 및 위임을 수행하는 시스템을 우선적으로 고려하여 Kerberos 동작이 환경의 고정 모델과 일치하는지 확인하십시오. 

2. Kerberos FAST(보안 강화)를 활성화하면 사전 인증 및 협상 단계에서 다운그레이드 및 MITM 조작 기회를 줄이고 트래픽 수준의 간섭으로부터 Kerberos 교환의 무결성을 강화할 수 있습니다.  

3. 암호화 보안 및 호환성 표면을 강화하십시오. 협상을 통해 취약한 체크섬 매핑에 접근할 수 있게 만드는 이전 암호화 유형을 가능한 한 비활성화하여 레거시 모드에 대한 노출을 줄이십시오. 서비스 계정 및 도메인 정책 설정이 최신 기본값에서 벗어나는지 모니터링하십시오. 

4. 위임은 위험도가 높은 구성 요소로 간주해야 합니다. 프로토콜 전환 및 위임에 대해 신뢰하는 서비스 계정 수를 최소화하십시오. 위임을 제한적으로 사용하고 허용되는 대상 SPN의 범위를 엄격하게 관리하십시오. 프로토콜 전환에 대해 신뢰하는 서비스 계정, 위임 가능한 SPN을 감사하고, 엄격한 비즈니스 요구 사항이 있는 경우를 제외하고는 권한 있는 계정은 위임 불가능으로 표시해야 합니다. 

5. 모니터링 및 탐지 지침 – 비정상적인 S4U2Self 및 S4U2Proxy 사용 패턴, 예상치 못한 대상 SPN, 위임된 티켓이 시작 세션과 일치하지 않는 주체를 반영하는 ID 불일치를 모니터링하십시오. 인증서 서비스의 경우, 권한 있는 ID의 예상치 못한 등록, 비정상적인 템플릿 사용, 프록시를 통해 게시된 애플리케이션 경로에서 발생하는 발급 활동을 모니터링하십시오. 

참고자료 

MS-SFU

케르베로스 v5 rfc4120

Kerberos 5용 암호화 및 체크섬 사양 RFC 3961

애플리케이션에 신분 도용 기능을 구현하세요

CA 웹 등록 페이지에 대한 제한된 위임을 구성합니다.

'개를 흔드는 것'

'RC4는 여전히 유해한 것으로 간주됩니다'

'S4U2Pwnage'

FAST(케르베로스 아머링)