Resource Based Constrained Delegation
Last updated
Was this helpful?
Last updated
Was this helpful?
제약없는 위임의 경우 Kerberos 인증을 사용하지 않을 때의 호환성 문제와, 위임이 구성된 객체의 제어권이 탈취당할 경우 공격자는 객체의 메모리에 캐시된 모든 사용자의 TGT를 악용할 수 있는 문제가 있었습니다.
제약된 위임의 경우 위임이 구성된 객체의 메모리에 사용자들의 TGT를 캐시하는 대신, 객체가 특정 서비스에 대해서는 모든 사용자들을 가장하여 접근할 수 있도록 설정하여 이용 가능한 서비스를 제한함으로써 보안성의 향상을 기대했습니다. 하지만 이 역시 Alternate Service Name에서 설명하는 것처럼 SPN을 임의로 변경해도 KDC는 이를 검사하지 않는 것에서 권한 남용 가능성이 있습니다.
위와 같은 두가지 방식은 모두 제어권을 프론트엔드에 위임하는 방식의 구성입니다. 실제 서비스를 운용하는 백엔드에 대한 가장 권한을 프론트엔드에서 구성함에 따라 백엔드는 자신에게 가장하여 접근하는 객체가 어떤 것인지 모르며, 프론트엔드가 침해당할 시 백엔드는 그대로 타격받을 수 없다는 보안상의 문제가 대두되었습니다. 부가적으로는 두 위임 방식은 도메인 관리자 권한을 요구하기 때문에 불편함이 있었습니다. 이러한 상황에서 Windows Server 2012에 리소스 기반의 위임 방식이 추가되었으며 이는 백엔드에서 위임 구성을 함에 따라 기존의 보안 문제를 해결하는데 집중했습니다.
첫 번째로 기존의 위임 방식들은 도메인 사용자 중 SeEnableDelegationPrivilege
권한이 있는 계정만이 위임에 관련된 도메인 객체 속성을 변경할 수 있는 반면, RBCD는 객체에 대한 적절한 속성 변경 제어권(WriteProperty, GenericAll, GenericWrite, WriteDacl)만 있다면 위임 구성이 가능합니다.
두번째로 어떤 객체가 사용자를 가장하여 서비스 티켓을 요청할 수 있는지에 관해 프론트엔드가 아닌 백엔드(서비스를 배포하는 주체)가 정의합니다. 리소스 관리 계정의 msDS-AllowedToActOnBehalfOfOtherIdentity
속성에 위임을 허용할 객체의 SID를 기입하게 되면 위임이 구성됩니다.
객체 속성 변경 제어권을 가진 객체와 위임에 사용할 머신 계정을 모두 획득했다면 다음과 같은 순서로 공격이 가능합니다.
DC01$ 계정의 msDS-AllowedToActOnBehalfOfOtherIdentity
속성에 FakeMachine$ SID 등록
FakeMachine$ 계정의 TGT 발급
발급한 TGT를 통해 DC01$에서 실행하는 서비스에 대한 관리자 권한의 서비스 티켓 요청
Pass the Ticket 기법을 통해 세션 획득
공격을 위해 요구되는 조건은 서비스 계정에 대한 객체 속성 변경 제어권과 위임 구성에 사용할 머신 계정에 대한 제어권이지만, 기본적으로 도메인 계정은 머신 계정을 최대 10개 생성할 수 있도록 구성할 수 있습니다.