Uncategorized 

Kerberos Introduction

xiphiasilver 0 댓글

 

※ 원문 : Kerberos Authentication, HackTricks

 

1. 커버로스(kerberos)란?

 

커버로스는 인증 프로토콜이다. 인가 프로토콜이 아니다.

즉, 비밀번호로 각 사용자를 식별하지만, 사용자가 액세스할 수 있는 서비스 및 리소스를 검증하지 않는다.

커버로스는 AD(Active Directory)에서 사용한다.

AD에서 커버로스는 각 사용자의 권한에 관련된 정보를 제공하지만, 리소스에 대한 사용자의 액세스를 결정하는 것은 각 서비스의 책임이다.

 

 

2. 커버로스 주요 컴포넌트

 

2.1. 전송 계층

 

커버로스는 TCP 및 UDP 모두를 전송 프로토콜로 사용한다.

TCP 및 UDP는 데이터를 평문으로 보낸다.

따라서, 커버로스는 암호화를 제공해야 한다.

커버로스는 TCP/88 및 UDP/88번 포트를 사용한다.

KDC에서 이 포트로 리스닝한다.

 

2.2. 에이전트

 

  • 클라이언트 / 사용자 : 서비스에 액세스를 요청
  • AP(Application Server) : AP는 사용자가 요구하는 서비스를 제공
  • KDC(Key Distribution Center) : 커버로스의 메인 서비스, 티켓 발행 책임, DC(Domain Controller)에 설치, TGT를 발행하는 AS(Authentication Service)가 지원

 

2.3. 암호키

 

  • KDC / krbtgt key : krbtgt 계정 NTLM 해시에서 파생
  • User key : 사용자 NTLM 해시에서 파생
  • Service key : 서비스 오너의 NTLM 해시에서 파생, 서비스 오너는 사용자 또는 컴퓨터 계정일 수 있음.
  • Session key : 사용자-KDC 간 협상에 사용
  • Service Session key : 사용자-서비스 간 사용

 

2.4. 티켓

 

  • TGS(Ticket Granting Service) : 사용자가 서비스에 대한 인증을 위해 사용. 서비스 키로 암호화.
  • TGT(Ticket Granting Ticket) : TGS를 요청하기 위해 KDC에 제출. KDC 키로 암호화.

 

2.5. PAC

 

PAC(Privilege Attribute Certificate)는 대부분의 티켓에 포함되어 있는 구조체이다.

이 구조체는 사용자의 권한을 포함하고 있고, 이 권한은 KDC 키로 서명되어 있다.

서비스들은 KDC와 통신하여 PAC를 검증할 수 있지만, 이런 일은 거의 발생하지 않는다.

PAC 검증이란, 단지 서명을 확인하는 것이다. PAC에 포함된 권한이 올바른지 확인하지 않는다.

따라서, 클라이언트는 티켓의 PAC에 권한을 포함하지 않고, KERB-PA-PAC REQUEST에 권한을 명시할 수 있다.

 

2.6. 메시지

 

  • KRB_AS_REQ : KDC에 TGT를 요청할 때 사용
  • KRB_AS_REP : KDC가 TGT를 제공할 때 사용
  • KRB_TGS_REQ : TGT를 사용하여, KDC에 TGS를 요청할 때 사용
  • KRB_TGS_REP : KDC가 TGS를 제공할 때 사용
  • KRB_AP_REQ : TGS를 사용하여, 서비스에서 사용자를 인증할 때 사용
  • KRB_AP_REP : 서비스가 자체적으로 사용자를 식별할 때 사용(옵션)
  • KRB_ERROR : 에러 컨디션을 통신하기 위한 메시지

 

AP는 선택적으로 KERB_VERIFY_PAC_REQUEST를 사용할 수 있다.

KERB_VERIFY_PAC_REQUEST는 PAC 서명을 KDC로 보내서, 서명이 올바른지 검증하기 위해 사용한다.

KERB_VERIFY_PAC_REQUEST는 커버로스의 메시지는 아니다. NRPC에 속하는 메시지이다.

 

 

3. 인증 프로세스

 

3.1. KRB_AS_REQ

 

사용자는 KDC에서 TGT를 받아야 한다.

이를 위해 KRB_AS_REQ를 보내야 한다.

 

 

KRB_AS_REQ는 아래와 같은 필드로 구성된다.

  • 클라이언트 키로 암호화된 타임 스탬프. 사용자를 인증하고, 리플레이 공격을 방어.
  • 인증된 사용자의 이름
  • krbtgt 계정과 관련된 서비스 SPN(Service Principal Name)1커버로스 클라이언트는 SPN을 이용하여 서비스 인스턴스를 유니크하게 인식한다.
  • 사용자가 생성한 논스(nonce)

 

암호화된 타임 스탬프는 사용자가 사전 인증을 요청할 때만 필요하다.

즉, 사용자 계정에 DONT_REQ_PREAUTH 플래그가 설정된 경우를 제외하고는 일반적으로 사용된다.

 

3.2. KRB_AS_REP

 

KRB_AS_REQ를 받은 후, KDC는 타임 스탬프를 복호화하여 사용자 신원을 확인한다.

메시지가 올바르면, KRB_AS_REP로 응답한다.

 

 

KRB_AS_REP는 아래 정보를 포함한다.

  • Username
  • TGT
    • Username
    • Session Key
    • TGT 유효기간
    • PAC(사용자 권한 포함, KDC가 서명)
  • 사용자 키로 암호화된 데이터
    • Session Key
    • TGT 유효기간
    • 사용자 논스(리플레이 공격 방어)

 

완료되면, 사용자는 TGT를 갖는다.

TGT는 TGS를 요청하기 위해 사용된다.

 

3.3. KRB_TGS_REQ

 

TGS를 요청하기 위해서, KRB_TGS_REQ 메시지를 KDC로 보내야 한다.

 

 

KRB_TGS_REQ는 아래 정보를 포함한다.

  • 세션 키로 암호화된 데이터
    • Username
    • 타임 스탬프
  • TGT
  • 요청하는 서비스의 SPN
  • 사용자가 생성한 논스

 

3.4. KRB_TGS_REP

 

KRB_TGS_REQ를 받은 후, KDC는 KRB_TGS_REP에 TGS를 넣어 보낸다.

 

 

KRB_TGS_REP는 아래 정보를 포함한다.

  • Username
  • TGS
    • 서비스 세션 키
    • Username
    • TGS의 유효기간
    • PAC(사용자 권한 포함, KDC로 서명)
  • 세션 키로 암호화한 데이터
    • 서비스 세션 키
    • TGS 유효기간
    • 사용자 논스(리플레이 공격 방어)

 

3.5. KRB_AP_REQ

 

모든 것이 잘 수행된 경우, 사용자는 서비스와 상호 작용할 수 있는 유효한 TGS를 갖는다.

TGS를 사용하기 위해, 사용자는 AP에 KRB_AP_REQ를 보내야 한다.

 

 

KRB_AP_REQ는 아래 정보를 포함한다.

  • TGS
  • 서비스 세션 키로 암호화한 데이터
    • Username
    • 타임 스탬프(리플레이 공격 회피)

 

사용자 권한이 올바르면, 서비스에 액세스할  수 있다.

일반적으로 발생하지 않지만, AP는 KDC에 PAC를 검증한다.

또한, 상호 인증이 필요한 경우, 사용자에게 KRB_AP_REP로 응답한다.