Kerberos
Kerberos는 주로 Active Directory 환경에서 보편적으로 사용되는 인증 프로토콜입니다.
다른 방식의 인증 프로토콜과는 다르게
권한 위임을 위한 권한 티켓을 사용하는 것이 가장 큰 특징이라고 할 수 있습니다.
총 6단계의 인증 과정을 갖게 되며 AD 환경에서는 AS와 TGS가 DC에 의해서 구현됩니다.
이 프로토콜은 암호학적 분야인만큼 깊은 지식을 다루기 때문에
아래 사진에서의 인증 과정을 원활하게 이해하기 위해 용어를 먼저 알아야 합니다.
AS(Authentication Server)
사용자를 인증하는 서버
TGS(Ticket Granting Server)
서비스 티켓을 분배하는 서버
SS(Service Server)
TGS를 통해 이용하고자 하는 서비스를 이용할 수 있는 서버
TGS Key
TGS 서버가 사용하는 비밀키이며, AD 환경에서는 krbtgt의 NT Hash
TGS Session Key
TGS에 ST를 요청하는 과정에서 사용되는 세션 키
SS Session Key
SS에 서비스를 요청하는 과정에서 사용되는 세션 키
먼저 인증 과정을 6단계로 간단하게 설명한 뒤, 세부적인 내용은 하단에서 다루겠습니다.
사용자는 AS에 본인의 NT Hash로 암호화한 메시지를 전송
AS는 AS-REQ 메시지의 타임스탬프를 확인하여 사용자가 일치한다면 TGT 발급
AS-REQ에 포함된 TGS 세션 키를 획득한 사용자는 TGS 서버에 ST를 요청
TGS는 TGS-REQ 메시지의 타임스탬프와 TGT를 확인하여 일치한다면 ST 발급
사용자는 서비스 이용을 위해 SS에 ST 전송
SS는 AP-REQ 메시지의 타임스탬프와 TGS를 확인하여 서비스 승인
Authentication Process
1. AS-REQ
사용자는 TGT 발급을 위해 AS에 다음의 정보를 전송합니다.
사용자의 패스워드 정보로 암호화한 타임스탬프
사용자 이름
SPN(Service Principal Name)
넌스
1번에서 암호화하는 것은 흔히 NT Hash로 알려져있지만
서버에서 사용하는 알고리즘에 따라 암호화하는 키가 달라집니다.
AES-128/256 -> PBKDF2 Hash
RC4 -> NT Hash
DES -> 패스워드로부터 계산
pfx -> 유저의 공개키
해당 장에서는 일반적인 상황인 NT Hash를 사용자의 비밀키로 사용하겠습니다.
타임스탬프를 전송하는 이유는 릴레이 공격을 방지하고자 하는 목적이며
2분 이상의 시간 차이가 발생할 시에는 유효하지 않은 요청이라고 여깁니다.
2. AS-REP
AS-REQ를 수신한 서버는 타임스탬프를 복호화 하기 위한 키를 데이터서버에서 찾은 뒤
그 값을 복호화하여 현재의 타임스탬프와 시간 차이가 발생하지 않는지 검사합니다.
만약 무결성에 이상이 없을 경우 2가지 메시지를 전송합니다.
유저의 NT Hash로 암호화한 세션 키, 유효 기간, 넌스
krgtgt의 NT Hash로 암호화한 유저 이름, 세션 키, 유효 기간, PAC
AS-REP으로부터 획득한 세션 키는 TGS에 ST 요청할 때 반드시 사용되는 세션 키입니다.
PAC은 사용자가 서비스를 이용할 때 획득할 정보 등에 관한 크리덴셜 데이터가 포함됩니다.
3. TGS-REQ
사용자는 TGS 세션 키를 이용해서 다음의 메시지를 전송합니다.
세션 키로 암호화한 유저 이름, 타임스탬프
AS-REP에서 수신된 TGT
SPN, 넌스
TGS는 사용될 TGS 세션 키에 대한 정보를 모르더라도 TGS 비밀키로 암호화 된
TGT를 복호화 할 수 있으며 이곳에서 TGS 세션 키를 획득할 수 있습니다.
획득한 TGS 세션 키를 이용하여 메시지를 복호화 한 뒤 획득한 유저 이름과
TGT에 기재된 유저 이름이 동일한지 확인하고, 타임스탬프를 비교합니다.
4. TGS-REP
TGS는 TGS-REQ가 유효한 요청일 시 2개의 메시지를 전송합니다.
TGS 세션 키로 암호화한 서비스 세션 키, TGS 유효 기간, 유저 넌스
서비스 주체의 NT Hash로 암호화한 서비스 세션 키, 유저 이름, TGS 유효 기간, PAC
TGS정보는 서비스 주체의 NT Hash로 암호화 되어있기 때문에 이것을 복호화하여
PAC 정보를 획득할 수는 없습니다.
하지만 커버로스 인증은 사용자가 직접 인증하는 것 외에도 자동화 등의 목적을 위해
다른 계정의 권한으로 대신 인증하는 것이 가능한데
이때 사용하는 방식이 S4U2self(Service for User to Self)입니다.
이 방식을 사용하면 대행하여 티켓을 발급받을 때 ST는 주체로부터 획득한 세션 키로 암호화됩니다.
S4U2self는 본인이 본인을 대행하여 티켓 요청 또한 가능하기 때문에
ST의 정보를 본인의 세션 키를 이용하여 복호화 하는 것이 가능하게 됩니다.
사용자는 TGS 세션 키를 이미 갖고있는 상태이기 때문에 TGS 세션 키를 통해
서비스 세션 키를 획득할 수 있습니다.
5. AP-REQ
ST를 무사히 발급받았다면 최종적으로 서비스 이용을 위해서 서비스 서버에 AP-REQ를 전송합니다.
서비스 주체의 NT Hash로 암호화된 ST
서비스 세션 키로 암호화된 유저 이름, 타임스탬프
서비스 서버에서는 ST를 본인의 NT Hash로 복호화 한 이후 ST에 포함된 서비스 세션 키를 획득합니다.
획득한 서비스 세션 키로 복호화한 유저 이름과 ST에 입력되었던 유저 이름이 동일하며
타임스탬프가 현재 시간과 큰 차이가 없다면 서비스 이용을 승인합니다.
Privileged Attribute Certificate
PAC에는 많은 인증 관련 정보들이 포함되어 있습니다.
많은 정보들이 겹겹이 쌓인 캡슐 형태로 이루어져 있으며
각각의 데이터는 구조체 형식을 띄고 있습니다.
예를 들어 가장 외곽의 PAC_CREDENTIAL_INFO는 아래와 같은 구조체입니다.
이 중 EncryptionType은 데이터가 암호화 되는 타입이며
SerializedData는 직렬화된 다음 데이터를 포함합니다.
레드팀의 입장에서 유심히 봐야할 부분은 NTLM에 관한 정보와 사용자의 자격 및 권한에 관한 정보입니다.
NTLM 구조체로부터 NT Hash를 가져올 수 있기 때문에
AD CS의 Misconfiguration 취약점을 악용하여 탈취한
다른 사용자의 pfx 파일을 가지고 이곳으로부터 NT Hash 덤핑이 가능합니다.
또한 자격 및 권한 정보를 변조한다면 Golden Ticket 공격이 성공될 수도 있습니다.
References
Last updated
Was this helpful?
