위임 위협: CVE-2020-17049 KCD 취약점의 Microsoft 패치 심층 분석

*****Dor Segal, 보안 연구원 Silverfort*****

11년 2020월 2020일 Microsoft는 새로운 CVE-17049-XNUMX를 공개했습니다. Kerberos 보안 기능 우회 취약점. 취약점 자체는 8년 2021월 8일 이전에 수정되지 않지만 Microsoft는 그동안 악용을 완화하기 위해 8월 XNUMX일과 XNUMX월 XNUMX일에 패치를 발표했습니다. 공개 POC나 기술적 분석 없이 취약점의 내부 작업에 대해 공개된 내용은 거의 없습니다.
이 게시물은 일반적으로 Kerberos 위임에 대해 설명하고 Microsoft가 CVE-2020-17049 KCD 취약점 자체에 대해 발행한 패치에 대해 자세히 살펴봄으로써 이러한 격차를 해소하려고 시도합니다.

Kerberos 위임 101

Kerberos 위임은 Kerberos의 가장 복잡한 개념 중 하나입니다. 인증 프로세스. 표준 프로토콜에 대한 이 확장은 원래 서비스 제공을 위해 만들어졌으며 서비스 계정 실제로 어떤 종류의 권한도 부여하지 않고 리소스를 사용하고 액세스합니다.

위임은 초기 도입 이후 오늘날 우리가 사용하는 리소스 기반 제한 위임(일명 KCD)이 될 때까지 몇 가지 중요한 변경 사항을 거쳤습니다. 따라서 취약성 자체에 접근하기 전에 다양한 유형의 위임과 각각의 장단점을 검토해 보겠습니다.

1단계: 무제한 위임

무제한 위임은 Windows Server 2000에 도입되었으며 서비스가 액세스 권한이 있는 사용자를 가장할 수 있도록 허용한 최초의 위임입니다. 이름에서 알 수 있듯이 이러한 종류의 위임은 서비스에 사용자의 자격 증명을 사용하여 언제든지 모든 리소스에 액세스할 수 있는 권한을 부여합니다.

이 프로세스에서는 사용자가 전달 가능한 TGT를 요청하고 이를 서비스 티켓에 첨부해야 합니다. 그런 다음 서비스는 TGT를 가져와 나중에 사용할 수 있도록 lsass.exe 로컬 캐시에 주입합니다.

오늘날 우리는 이 방법이 위임된 서비스에 대한 무제한 액세스 권한을 부여하기 때문에 매우 위험하다는 것을 알고 있습니다. 이는 공격자가 모든 캐시된 티켓을 수집하고 모든 권한에 대한 전체 액세스 권한을 얻을 수 있도록 합니다.

이러한 종류의 위임은 오늘날에도 대부분 이전 버전과의 호환성을 지원하기 위해 존재하며 userAccountControl 속성에서 ADS_UF_TRUSTED_FOR_DELEGATION 플래그를 쿼리하여 감지할 수 있습니다. 이 플래그는 다음에 의해 모니터링됩니다. Silverfort, 무제한 위임을 사용하는 서비스에 대해 보고합니다.

2단계: 제한된 위임

차세대 위임은 더 제한적이며 "계정이 민감하여 위임할 수 없음" 플래그를 사용하여 서비스가 정의된 리소스에 대한 액세스만 가장할 수 있도록 허용합니다. Active Directory 특정 사용자의 사칭을 제한합니다.
이 유형의 위임은 서비스가 S4U2Self 및 S4U2Proxy 확장(MS-SFU)을 사용하여 인증을 수행하는 경우입니다.

그래서 어떻게 작동합니까?

서비스 계정에는 TRUSTED_TO_AUTH_FOR_DELEGATION 플래그가 켜져 있고 리소스의 SPN을 포함하는 ms-AllowedToDelegateTo 속성이 있어야 합니다.

사용자는 Kerberos 협상(TGT 및 TGS)을 사용하여 평소와 같이 서비스에 대해 인증합니다.

이제 이것은 복잡해지기 시작합니다. 위임된 서비스 계정이 전달 가능한 TGT를 자신에게 요청합니다. 이 티켓을 사용하여 cname PA-DATA 필드에 가장된 사용자 이름을 사용하여 S4U2SELF를 사용하여 서비스 티켓을 요청했습니다.

서비스는 이 티켓을 가져와 제한 위임 플래그를 사용하여 리소스 서비스 티켓(S4U2Proxy)에 첨부합니다.

수신된 티켓은 당사 서비스에서 현재 사용자를 가장한 것입니다.

3단계: 리소스 기반 제한 위임

이 위임의 주요 차이점은 대부분 관리입니다.

서비스가 리소스에 대한 액세스를 위임하도록 허용하는 대신 리소스 소유자에게 위임을 수행할 수 있는 서비스를 정의할 수 있는 권한을 부여합니다.

이는 다음을 사용하여 PowerShell에서 구성할 수 있습니다. 보안 주체AllowedToDelegateToAccount 매개변수 또는 단순히 속성을 편집하여 msDS-AllowedToActOnBehalfOfOtherIdentity

CVE-2020-17049용 Microsoft 보안 패치 – 기술 분석

프로토콜 취약성은 필요한 이전 버전과의 호환성 지원으로 인해 완화하기가 항상 더 어렵습니다.

우리는 공식 웹 사이트에 게시된 정보를 읽고 Microsoft의 패치를 살펴보기 시작했습니다.

우리는 취약점이 "티켓 변조"에 관한 것이며 Kerberos 제한 위임 프로세스 어딘가에 위치한다는 것을 이해했습니다.

취약한 도메인 컨트롤러에서 위임을 시뮬레이트하고 패치된 컨트롤러에서 재현하여 차이점을 확인했습니다.

첫 번째 눈에 띄는 변화는 각 패킷의 길이에 있습니다. 자체 서명된 티켓(S4U2Self) 요청이 동일하지만 응답이 40바이트 더 긴 것을 볼 수 있습니다.

이는 다음 S4U2Proxy 요청 및 응답에도 적용되므로 변경된 사항은 무엇입니까?

변경된 텍스트가 티켓 내부에서 암호화되기 때문에 텍스트 비교는 도움이 되지 않았습니다.

서비스의 keytab을 사용하여 암호를 해독한 후 텍스트를 읽을 수 있지만 여전히 이해해야 합니다.

AuthorizationData 필드를 보면 크기가 840인 오프셋 20에서 시작하는 새로운 Unknown 필드를 볼 수 있습니다.

이 새로운 분야는 어디에서 왔습니까? KDC는 어떻게 처리합니까?

내가 프로토콜에 대해 가장 좋아하는 점은 대부분의 프로토콜이 정기적으로 유지 관리되고 업데이트되는 RFC를 가지고 있다는 것입니다. Kerberos도 예외는 아닙니다.

방문 MS-SFU 11년 23월 2020일에 업데이트된 것을 확인했습니다. 우리가 열었을 때 문서 비교 섹션 3.2.5.2.2에서 티켓의 무결성을 확인하는 데 사용되는 새 서명이 있음을 배웠습니다. 또한 Microsoft의 패치는 첫 번째 수정 티켓이 S4U2Self임을 암시합니다.
티켓 서명의 참조를 살펴봄으로써 RFC에서 더 많은 정보를 추출했습니다. MS-PAC 2.8.3:
"KDC는 KDC(krbtgt) 키[RFC4120]를 사용하므로 다른 KDC가 PAC를 수신할 때 이 서명을 확인할 수 있습니다."
“티켓 서명은 KDC 이외의 당사자에 의한 티켓 변조를 감지하는 데 사용됩니다. 티켓 서명은 krbtgt 계정(비밀번호 변경 서비스 포함) 또는 트러스트 계정으로 암호화되지 않은 티켓에 포함되어야 합니다.”
"티켓 서명에 해당하는 값은 0x00000010입니다."
MS-PAC RFC는 오프셋 840의 알 수 없는 필드 뒤에 숨겨진 미스터리를 공개했습니다. 이 필드는 무결성을 확인하기 위해 krbtgt 키를 사용하여 암호화된 새로운 티켓 서명입니다.

Kerberos 브론즈 비트

8월 XNUMX일 시행 CVE-2020-17049 Kerberos의 KCD 취약성 브론즈 비트 어택 S4U2Self 티켓의 조작에 대해 더 많은 정보를 제공하면서 더 자세히 공개되었습니다.

익스플로잇은 티켓의 encRepPart 내부에 있는 전달 가능한 필드의 비트를 해독하고 편집합니다.

위임 기능이 있는 서비스는 다음에 대한 S4U2Self 티켓을 생성할 수 있습니다. 모든 사용자들 '계정이 민감하여 위임할 수 없습니다' 플래그가 켜져 있는 계정도 마찬가지입니다.
이 플래그는 전달 가능 플래그를 False로 설정하지만 티켓이 수정된 경우 KDC에서 유효성을 검사하지 않습니다.

최종 단어

새로운 취약점의 공개는 항상 보안 연구원들 사이에서 관심을 불러일으킵니다. 일반적으로 이러한 공개에는 수반되는 비트 및 바이트에 대한 자세한 설명이 포함되지 않습니다. 이는 운영 관점에서 의미가 있을 수 있지만 이러한 공개를 활용하여 소프트웨어 구현(이 경우 Kerberos 위임 메커니즘)에 대한 더 나은 통찰력을 얻는 것도 마찬가지로 중요합니다. 지식이 힘이라면 이 분석이 우리를 조금 더 강하게 만들었기를 바랍니다.