Intro

ใน Windows Domain Environment เมื่อเครื่องที่อยู่ใน domain ต้องการสื่อสารกันจะใช้ Kerberos เป็น Protocol หลักในการทำ Authentication หากไม่สามารถใช้ได้จะหนีไปใช้ NTLMv2 แทน (สามารถเรียกอีกอย่างได้ว่า Net-NTLMv2*)

สำหรับ Kerberos เองเป็น Network Authentication Protocol ที่อาศัยการใช้งานของ “ticket” เป็นหลัก มีหน้าที่พิสูจน์ตัวตนว่าต่างฝ่ายต่างเป็นคนคนนั้น หรือ entity ที่จะสื่อสารด้วยตัวจริง สามารถใช้งานผ่าน channel ที่ไม่ secure ก็ได้ แต่มีข้อแม้ว่า entity ทั้งสองที่จะคุยกันต้องเชื่อตัวกลาง (trust party) ซึ่งก็คือ Kerberos Server นั่นเอง โดยเจ้า trust party ในโลกของ Windows Domain ก็คือเครื่อง Domain Controller Server นั่นเอง

Component ที่ต้องรู้จักใน Kerberos ประกอบด้วย

1. KDC (Key Distribution Centre) : เป็นตัวกลางหรือ trust party ถ้าไปดู Services บน Windows Domain Controller จะมี service ชื่อ “Kerberos Key Distribution Centre” ที่ทำหน้าที่นี้อยู่ ทำหน้าที่เป็น Authentication service และ Ticket Granting service
2. client : เป็น entity ที่อยากจะ request เข้าหา resource/service ใน domain ให้มองง่าย ๆ ว่าเป็นเครื่อง workstation ใน domain ก็ได้
3. service : เป็น entity ที่ client อยากใช้บริการ มองว่าเป็น service บน server ก็ได้ โดย service จะมีชื่อเรียกที่เป็น unique name ซึ่งชื่อในที่นี้เราจะเรียกว่า SPN (Service Principal Name)

อ่านมาถึงนี่แล้วขอสรุปสั้น ๆ ก่อนที่จะไปต่อ
1) Kerberos เป็น Authentication Protocol ไม่ได้ทำหน้าที่ Authorisation
2) มี 3 party คือ KDC, client และ service
3) ใช้งานบน insecure network ก็ได้ เหนือกว่า NTLMv2 เพราะถูก capture ไปก็ทำอะไรไม่ได้ ไม่เหมือน NTLMv2 ที่อาจโดน capture ค่า hash ที่คุยระหว่างกัน โดยใน Windows environment นั้น Kerberos ใช้งานผ่าน TCP/88 และ UDP/88

Authentication Flow

ลำดับต่อไปจะอธิบายถึง Authentication Flow ซึ่งข้อมูลที่รับส่งระหว่าง entity จะขออธิบายเฉพาะค่าที่จำเป็นหรือค่าที่อยากให้สนใจเท่านั้น แน่นอนว่ามีค่าหรือตัวแปรอื่น ๆ อีกพอสมควรซึ่งไม่ขอกล่าวถึง ในช่วงท้ายของบทความจะทิ้งท้ายด้วย Reference ที่สามารถไปศึกษาต่อได้

1. TGT Request (KRB_AS_REQ)

เมื่อ client ต้องการ authenticate เข้าไปยัง domain จะต้องส่ง request ไปยัง Authentication Server ก่อน (KDC หรือ Domain Controller รับหน้าที่เป็น authentication server หรือ AS ด้วย) โดยจะส่ง username และ cipher text ที่ได้จากการนำ timestamp ไป encrypt ด้วยค่า hash ของ password ของผู้ใช้งาน ตามรูปคือ

เพิ่มเติมอีกนิดเพื่อความเข้าใจ

ใน message จะมีการส่ง SPN ของ krbtgt (ชี้ Service Principal Name ไปยัง krbtgt ที่เป็น account ที่รับผิดชอบเรื่อง ticket ทั้งหลายใน Kerberos Ecosystem โดย 1 domain จะมี 1 krbtgt account) และ nonce ฝั่ง client ด้วย

ที่ต้อง encrypt ค่า timestamp เพราะเป็นกระบวนการของ pre-authentication ซึ่งโดย default แล้วจะบังคับให้ทำ

2. TGT Reply (KRB_AS_REP)

เมื่อ AS ได้รับ message มาแล้ว (Domain Controller ได้รับ) จะไปดึงข้อมูล password ที่เก็บในรูปแบบ hash ของ username คนนั้น ที่ส่งมา นำมา decrypt ค่า cipher text หากทำได้สำเร็จ client จะได้รับ TGT (ticket-granting ticket)
โดย message ที่ตอบกลับประกอบด้วย

• enc([username,period,session_key,PAC], krbtgt_key) ชุดนี้เราเรียกว่า TGT ประกอบด้วย การนำ username, expiration time ของ TGT, ค่า session_key สำหรับคุยกับ KDC ในอนาคต และค่า PAC (Privilege Attribute Certificate) ไปเข้ารหัสด้วยค่า krbtgt_key ซึ่งเป็น hash ของ password ของ krbtgt account
• enc([session_key, period, nonce], hash_of_password) คือ message อีกส่วนที่นำ ค่า session_key สำหรับคุยกับ KDC ในอนาคต, expiration time ของ TGT และ user nonce เพื่อ prove ว่าไม่ได้เกิดจากเอา message มา replay ไปเข้ารหัสด้วยค่า hash ของ password ผู้ใช้งานที่กำลังคุยกับ KDC

มาถึง step นี้หลังจาก client ได้รับค่า message ชุดนี้ แสดงว่า client ผ่าน authentication process แล้ว จากนี้จะไปแงะเอาค่า session_key ไปใช้คุยกับ KDC ในห้วงเวลาถัดไป

ขยายความค่า PAC

สำหรับค่า PAC มีความสำคัญมากเพราะเป็นค่าที่กำหนด privilege ของผู้ใช้งาน โดยถ้ามองโครงสร้างข้างในจะขออธิบายด้วย slide จากหัวข้อ “Abusing Microsoft Kerberos sorry you guys don’t get it” by Alva `Skip` DUCKWALL & Benjamin DELPY (น่าจะคุ้นหูคุ้นตากันมาบ้างนะครับเพราะ Benjamin DELPY คือผู้สร้าง mimikatz นั่นเอง)

1) ใน PAC จะมีข้อมูลสำหรับ account นั้น ๆ ซึ่งค่านี้มีความสำคัญสุด ๆ จึงถูก sign ด้วย target key และ KDC key สำหรับ target key ใน step ของการ request TGT นั้นจะใช้ krbtgt NT hash ซึ่งก็คือ KDC key ตัวเดียวกัน (target หมายถึง entity ที่กำลังคุยด้วย)

2) client ไม่สามารถแงะเพื่อดูของใน TGT ได้ เอาไว้ส่งให้ KDC ดูในอนาคตว่า client มี TGT แล้วนะ

3. TGS Request (KRB_TGS_REQ)

เมื่อ client ต้องการใช้บริการของ service ที่ต้องการ ก็จะทำการร้องขอ TGS (ticket-granting service) จาก KDC โดยจะส่ง

• TGT : บอกว่าผ่าน TGT Request มาแล้ว ซึ่ง KDC แงะได้เท่านั้น
• SPN of target service : บอกว่าอยากจะใช้บริการใคร; target service ชื่อ SPN ว่าอะไร
• enc([username,timestamp],session_key) หรือ authenticator : ค่า cipher text ที่ประกอบด้วย username และ timestamp เข้ารหัสด้วย session_key

4. TGS Reply (KRB_TGS_REP)

KDC จะเปรียบเทียบ content ใน authenticator กับของที่แงะออกมาจาก TGT ถ้าสอดคล้องกัน แสดงว่า client คือคนที่เคยผ่าน authentication มาแล้ว จากนั้นจะส่ง message กลับ 2 ส่วนคือ

• enc( [service_session_key, TGS period, nonce], session_key) : ประกอบด้วย service_session_key สำหรับคุยกับ target service ในลำดับต่อไป, ช่วงเวลาที่ TGS ใช้งานได้ และ nonce ป้องกัน replay attack ทั้งหมดถูกเข้ารหัสด้วย session_key ที่ client สามารถเอามาแงะ client portion ได้
• TGS:enc([username,service_session_key,TGS period,PAC],target_key) : ชุดนี้เราจะเรียกว่า TGS ที่ target service สามารถแงะออกมาได้ ประกอบด้วย username ของคนที่ร้องขอ, ค่า service_session_key สำหรับคุยกับ user คนนั้น, ช่วงเวลาที่ TGS ใช้งานได้ และค่า PAC ที่ระบุสิทธิ์ของ user โดยถูก sign ด้วย target key และ krbtgt key (รอบนี้ใช้ทั้ง target_key และ krbtgt_key ในการ sign แล้ว ต่างกับ step ก่อนที่ทั้ง target_key และ krbtgt_key คือ krbtgt_key หรือ NT Hash ของ password ของ krbtgt account)

เมื่อ client รับ message ก็จะแงะเอา service_session_key มาใช้ และได้ TGS เอาไปแสดงให้กับ service ที่กำลังจะร้องขอต่อไป

5. AP Request (KRB_AP_REQ)

เมื่อ client พร้อมใช้บริการ service ก็จะส่ง

ไปหา target service

6. AP Reply

service ทำการเปรียบเทียบ content ใน TGS และ authenticator ว่าสอดคล้องกันหรือไม่ ถ้าใช่ก็จะตอบ message กลับ

โดยการนำ timestamp ที่แงะออกมาได้ เอามา encrypt ด้วย service_session_key หลังจาก client ได้รับก็จะแงะและเปรียบเทียบ timestamp ว่าตรงกันหรือไม่ ถ้าตรงกัน client ก็จะมั่นใจว่า service ที่กำลังคุยอยู่คือตัวจริง แล้ว connection ก็เริ่มต้นขึ้นหลังจากนี้

Remark

*Kerberos เจ๋งกว่า NTLMv2 เพราะไม่ต้องส่งหรือเก็บ password อีกทั้ง performance ดีกว่า ในแง่ของความยืดหยุ่น ถ้าเราใช้ Kerberos เราจะมี concept ของ Delegation ที่ impersonate เป็น entity อื่นได้
*ขอเคลียให้ชัดก่อนทุกคนจะได้เข้าใจ ใน Windows Environment จะพบเรื่องพวกนี้ตลอด

• LM มักจะหมายถึงรูปแบบการจัดเก็บ password ในรูปแบบ LM Hash รายละเอียดลองไปหาอ่านกันดู
• NTLM มักจะหมายถึงรูปแบบการจัดเก็บ password ในรูปแบบทั้ง LM Hash และ NT Hash
• NTLMv1 และ NTLMv2 เป็น Authentication protocol รูปแบบ challenge-response สามารถเรียกอีกแบบว่าเป็น Net-NTLMv1 และ Net-NTLMv2 ได้ตามลำดับ เพื่อแสดงความแตกต่างจาก NTLM (สังเกตว่าเรียกคล้าย ๆ NTLM เลย เนื่องจากเจ้า NTLMv1 มีการใช้ NT Hash และ LM Hash ด้วย ส่วน version สำหรับ v2 ก็จะ secure กว่า v1)

ดังนั้นความหมายและ Notation ที่เขียนออกมาอาจจะทำให้สับสนได้ Professional Penetration Tester ที่ดีควรต้องเข้าใจและสามารถอธิบายให้คนอื่นเข้าใจถึงความแตกต่างได้ด้วย

Reference

1. https://docs.microsoft.com/en-us/windows/win32/secauthn/client-server-exchange
2. https://msdn.microsoft.com/en-us/library/cc223948.aspx
3. https://www.sans.org/webcasts/kerberos-attacks-101-111735
4. Kerberos Authentication 101: Understanding the Essentials of the Kerberos Security Protocol; Redmon Magazine; Geir Olsen