Inter-realm Kerberoasting
도메인에서 양방향 신뢰 관계를 구축할 때, 대상 도메인의 관리자 자격 증명을 이용하여 단일 도메인에서 양방향 신뢰 관계를 구축하는 방법과 서로가 서로에게 일방향 신뢰를 맺을 수 있습니다.
신뢰 관계는 모델에 관계없이 양측 도메인에서 서로 신뢰 모델을 등록해야지 맺어지는 관계입니다. 이때 신뢰를 맺을 땐 두 가지 방법을 사용할 수 있는데,
A 도메인이 B 도메인의 관리자 평문 자격 증명을 통해서 양측 도메인에 신뢰 관계를 등록
A 도메인과 B 도메인에서 각각 서로가 일치하는 신뢰 관계를 등록
어떤 방법으로 신뢰를 구축하냐에 따라 TDO의 Inter-realm Key 값이 달라지게 되는데, 첫번째 방법을 선택할 경우 양 도메인간은 서로가 신뢰하는 공용 키가 없기 때문에 신뢰 관계 구축 시 신뢰 비밀번호를 생성합니다.
신뢰 비밀번호의 경우 128비트의 랜덤 값으로 알려져 있지만, 이 값은 변경이 가능하고 1번 옵션을 선택하여 신뢰 비밀번호를 통해 맺어진 경우 30일 동안은 수동으로 입력한 신뢰 비밀번호를 사용합니다.
일반적으로 아무리 같은 회사라고 하더라도 도메인의 관리자 자격 증명을 평문으로 전달하는 일은 드물기 때문에 보통 서로 신뢰 관계를 구성합니다. 이럴 경우 신뢰 관계가 구성된지 30일 미만이면 해시 크랙 가능성이 있습니다.
Root Couse
Blue 도메인 객체가 Green 도메인의 서비스에 접근할 수 있는 상황에서 Blue 도메인의 KDC는 Green 도메인에 있는 정보를 알 수 있는 수단이 없습니다. 때문에 신뢰 관계 설계상 Blue 도메인 KDC에서 알 수 없는 SPN이 요청되면 KDC는 신뢰 관계가 있는지 확인하고, 이때 요청된 sname 필드의 KDC FQDN 값이 신뢰받는 도메인과 일치한다면 레퍼럴 티켓을 반환합니다.
문제는 Green 도메인의 실제 SPN까지는 확인할 수단이 없어서 KDC FQDN만 검증하는 것인데, 이 때문에 SPN을 모르는 상태에서도 가짜 서비스를 요청하여 레퍼럴 티켓 발급이 가능합니다.
PENTEST 도메인 사용자 계정으로 CONTOSO에 없는 SPN을 요청했을 때 getST.py는 없는 SPN이라는 결과를 반환합니다. 하지만 여기서 반환된 에러 메시지는 레퍼럴 티켓에 대한 요청 결과가 아닌, 레퍼럴 티켓을 통해 CONTOSO KDC에 요청한 TGS-REQ의 결과입니다.
전체 패킷 흐름을 확인하더라도 TGS-REQ가 두번 나오는 것이 확인되고, 두번째 TGS-REP에서 위에서 확인한 에러와 동일한 코드가 나온 것이 확인됩니다. 우리가 탈취하기 위한 Inter-realm Key로 암호화된 레퍼럴 티켓은 첫번째 요청이기 때문에 전혀 문제가 없다는 것을 알 수 있습니다.
레퍼럴 티켓 요청 패킷을 조금 더 자세히 확인하면 응답 값에서 TGT 정보가 암호화되어 있음이 확인됩니다.
$krb5tgs$23$*<trustAccount>$$<domain>$krbtgt*$<checksum>$<enc> 형식으로 맞게 넣어주면 해시 크랙을 할 수 있게 됩니다. 레퍼럴 티켓에서 얻은 암호문은 앞 32비트가 체크섬이고 나머지는 암호문입니다.
이제 Inter-realm Key를 획득했으므로, 신뢰하는 도메인을 장악하지 않고도 신뢰받는 도메인의 객체와 서비스 이용 등이 가능해집니다.
References
Last updated
Was this helpful?