Behind the Kerberos Attacks Part 1 — Kerberos Authentication Flow

Introduction

ถ้าเพื่อนๆ เคยซ้อมโจทย์ Active Directory Labs มาบ้าง น่าจะเคยใช้ AS-REP Roasting, Kerberoasting มาบ้าง แต่เพื่อนๆ เคยสงสัยไหมว่า เบื้องหลังการโจมตีพวกนี้ มันทำงานอย่างไร
อย่างKerberoasting ทำไมถึงสามารถดึง crack offline password ได้แค่บาง account , ทำไม ได้ hash password มา เราสามารถ loginด้วย hashนั้นได้เลย โดยไม่ต้องผ่านการ crack ก่อน (Pass-the-Hash) หรือ ทำไม "เวลาไม่ตรงกัน" เป็นปัญหาใหญ่ใน AD
จึงได้เป็นบทความชุด Behind the Kerberos Attacks ครับ
เริ่มจาก Part1 — Kerberos Authentication Flow เป็นการปูว่า จริงๆ Kerberos ทำงานอย่างไรครับ

alice ต้องการใช้ File Share (cifs) ใน domain โดยมีเงื่อนไขว่า Network ไม่ปลอดภัย ถูกดักฟังได้ตลอด

alice จะพิสูจน์ตัวตนได้อย่างไร โดยไม่ต้องส่ง password ออกไปเลยสักครั้ง

{data}K หมายถึง "data" ที่ถูก encrypt ด้วย key K ใครที่จะอ่านข้างในได้ ต้องมี key K เท่านั้น

Kerberos Authentication Flow

AS-REQ / AS-REP alice พิสูจน์ตัวตนกับ KDC เพื่อขอ TGT
TGS-REQ / TGS-REP alice ใช้ TGT ขอ Service Ticket สำหรับ service ที่ต้องการ
AP-REQ / AP-REP alice ยื่น Service Ticket ให้ service ปลายทาง

AS-Request (Authentication Server Request)

AS-REQ: alice encrypt Timestamp ด้วย Kc แล้วส่งให้ KDC ถ้า KDC ไขได้ แสดงว่าเป็น alice จริง

AS-REQ
├─ cname  : alice
├─ sname  : krbtgt/CORP.LOCAL
├─ nonce  : 8812 (random on client)
└─ padata : {timestamp}Kc

AS-REQ
├─ cname  : alice
├─ sname  : krbtgt/CORP.LOCAL
├─ nonce  : 8812 (random on client)
└─ padata : {timestamp}Kc

cname : ชื่อ user ที่ขอ TGT
krbtgt : Kerberos Ticket-Granting Ticket เป็น service ที่ออก TGT
padata : pre-authentication data Timestamp ที่เข้ารหัส (Encrypt) ด้วย Kc
Kc : client long-term key ได้มาจากการนำ password ของ user ผ่าน hash function
แน่นอนว่า การขอ Ticket ต้องระบุว่า user ที่ขอคือใคร
ท้ายที่สุดแล้ว TGS ก็เป็น service หนึ่ง จึงต้องแจ้งชื่อ service เป็น krbtgt
ที่น่าสนใจคือ padata ว่าทำไมต้องใช้ Timestamp? แล้วจริงๆ Kc คืออะไร

Password in KDC

ก่อนที่จะไปถึง Kc อยากจะให้เพื่อนๆ เข้าใจระบบ Password ของ KDC ก่อนนะครับ

แน่นอนว่า Kerberos จะไม่เก็บ Password เป็น plain text แต่จะเก็บuser password ที่ผ่าน hash function แทน — ในกรณีทั่วไปจะเป็น MD4
เราจะเรียก user password ที่ผ่าน MD4 hash function ว่า NT hash
ว่ากันตามตรง MD4 hash function ไม่ถือเป็นมาตรฐานที่ปลอดภัยแล้ว แต่หลายๆ ระบบ รวมถึง Labs ที่เพื่อนๆ มักซ้อมกัน ยังใช้เป็น NT hash อยู่
ปัจจุบันใช้เป็น PBKDF2 hash function โดยเรียก user password ที่ผ่าน hash function นี้ว่า AES key

NT hash (รวมไปถึง AES key) คือ Kc ที่เอาไปใช้ encrypt

password → MD4    → NT hash ─┐
                             ├─► Kc
password → PBKDF2 → AES key ─┘

password → MD4    → NT hash ─┐
                             ├─► Kc
password → PBKDF2 → AES key ─┘

เกร็ด ระวังสับสน NT hash กับ NTLM ซึ่งเป็น protocolการ authenticateก่อนมีการใช้ Kerberos

AS-Request (Authentication Server Request) (continue)

เราทราบแล้วว่า Kc คือ Key ที่ได้จาก user password ที่ผ่าน hash function อย่าง MD4
แล้วทำไมต้องใช้ Timestamp ที่ encrypt ด้วย Kc? เป็นค่าอื่นไม่ได้หรือ?
เมื่อเพื่อนๆ พิจารณาจาก AS-Req จะเห็นว่า เราส่ง alice ซึ่งเป็นค่าที่แก้ไขได้ KDC เองจะไม่รู้เลยว่า alice นั้น มาจาก alice จริงหรือไม่
aliceต้องพิสูจน์ได้ว่าเป็นตัวจริง โดยการบอกสิ่งที่มีเพียง aliceตัวจริงเท่านั้นที่รู้ คือ password
เพื่อนๆ ที่มาจากสาย Developer อาจสงสัยว่า แล้วส่ง passwordไปยืนยันตรงๆ ไม่ได้หรือ? Login form ปกติก็ส่ง password กันตรงๆ
เมื่อเพื่อนๆ ส่ง password ผ่าน browserจะมี HTTPS(TLS) ป้องกันไม่ให้สามารถ "ดัก" password กลางทางได้
Kerberosออกแบบตั้งแต่ยุคที่ยังไม่มี HTTPS จึงต้องสันนิษฐานไว้ก่อนว่า Networkไม่ปลอดภัย ถูก "ดักฟัง" ได้เสมอ

แทนที่จะส่ง password(รวมถึง hash) ไปตรงๆ KDCจะ "ทดสอบ" ว่า

ลองล็อกกุญแจ(Encrypt) ด้วยกุญแจ(Password) ให้ดูหน่อย ถ้าเป็น Alice ตัวจริง ต้อง "ล็อกกุญแจ" ได้

ถ้า KDC สามารถ Decrypt ด้วย NT Hash ที่ KDCเก็บไว้ KDCก็มั่นใจได้ว่า alice ใช้ "กุญแจดอกเดียวกัน" หมายถึงเป็น Alice ตัวจริง

ทำไมต้อง Timestamp

เราทราบว่า ทำไมต้อง Encryptด้วย NT hash แต่ทำไม KDCต้องให้เรา Encrypt Timestamp
ถ้าหากว่า KDC ให้ลอง Encrypt username แทน สิ่งที่เกิดขึ้นคือ "ผู้โจมตี สามารถดักเอา AS-Request" ไปส่งได้ โดยไม่ต้อง Encrypt เองเลย (Replay Attack)
สิ่งที่ Encrypt ต้องมีคุณสมบัติสำคัญคือ "แยกใหม่-เก่าได้" ถ้าจะพิสูจน์ตัวตนว่ารู้ Kcต้อง Encryptใหม่เท่านั้น
Timestamp เป็นสิ่งที่ตอบโจทย์พอดี ถ้าถูกดัก AS-Request KDC จะทราบว่า "Timestamp นั้น ห่างจากปัจจุบันมากไหม(มาตรฐานคือ 5 นาที)"
จึงเป็นเหตุผลว่า ทำไมถ้าเพื่อนๆ ทำ Labs AD แล้วเวลาเครื่องไม่ตรง มักจะเจอปัญหา

ถ้าเพื่อนๆ เข้าใจว่า Password ใน KDCไม่ได้ใช้เทียบตรงๆ แต่ใช้เพื่อพิสูจน์ว่า aliceสามารถ Encrypt ได้จริงไหม ถือว่าเข้าใจ Key concept ของ AS-Request แล้วครับ

AS-Response (Authentication Server Response)

AS-Response: KDC ส่ง {alice, SK_tgs}Kkrbtgt (TGT) กลับมาคู่กับ {Sk_tgs}Kc

User เก็บ TGT ไว้โดย decryptไม่ได้ และ decrypt {Sk_tgs}Kc แล้วเก็บ Sk_tgs ไว้

AS-REP
├─ cname    : alice
├─ ticket   : {alice, SK_tgs, endtime, PAC}Kkrbtgt   ← TGT
└─ enc-part : {SK_tgs, endtime, nonce}Kc

AS-REP
├─ cname    : alice
├─ ticket   : {alice, SK_tgs, endtime, PAC}Kkrbtgt   ← TGT
└─ enc-part : {SK_tgs, endtime, nonce}Kc

cname : ชื่อ user ที่ได้รับ TGT
ticket : TGT ที่เข้ารหัส (Encrypt) ด้วย Kkrbtgt user ถือไว้ได้แต่อ่านหรือแก้ไขข้างในไม่ได้
TGT : ย่อมาจาก Ticket Granting Ticket
enc-part : encrypted part ส่วนที่เข้ารหัส (Encrypt) ด้วย Kc มีเพียง user ตัวจริงเท่านั้นที่ถอดได้
Kkrbtgt : krbtgt long-term key ได้มาจาก password ของ account krbtgt มีเพียง KDC เท่านั้นที่รู้
SK_tgs : session key ticket granting service ที่ KDC สุ่มขึ้นมาใหม่ ใช้แทน Kc ในขั้นตอนต่อไป
endtime : เวลาหมดอายุของ TGT (default ใน AD คือ 10 ชั่วโมง)

krbtgt คืออะไร

krbtgt(Kerberos Ticket-Granting Ticket) ถือเป็น Service ซึ่ง Service ใน AD ถือว่าเสมือน account หนึ่ง ซึ่งมีทั้ง username, password
Kkrbtgtจึงเป็น long-term key ของ user krbtgt ที่ derive มาจาก password ของ krbtgt
krbtgt account ถูกสร้างมาพร้อม domain และถูกสุ่ม password ฉะนั้น Kkrbtgt จึงมีเพียง KDC ที่รู้

`SK_tgs` คืออะไร

SK_tgs session key ticket granting serviceคือ key ชั่วคราว ที่ KDC สุ่มขึ้นใหม่ ทุกครั้งที่ออก TGT ใช้แทน Kc ในขั้นตอนต่อไป เพื่อไม่ต้องใช้ key ที่มาจาก password ของ user ซ้ำบ่อย ๆ
หมายความว่า แทนที่ user จะพิมพ์ password ซ้ำ จะใช้ SK_tgsแทน
เก็บที่ clientเท่านั้น โดยเก็บคู่กับ TGT

เกร็ด — nonce กันไม่ให้ client ถูกหลอกให้ใช้ reply เก่าที่ session key อาจรั่วไปแล้ว ซึ่งสำคัญมากในยุค DES ที่ key crack ได้ แต่ในยุค AES แทบไม่ใช่ช่องทางโจมตีในทางปฏิบัติแล้ว

AS-Response (Authentication Server Response) (ต่อ)

user ไม่ทราบ Kkrbtgt จึงไม่สามารถอ่าน TGT ได้ จึงเก็บ TGT ไว้โดยไม่ decrypt
enc-part user สามารถ decrypt ได้ เพราะมี Kc จึงเก็บ SK_tgsไว้คู่กับ TGT
สังเกตว่า ต่อให้ดัก AS-Response มา ก็ไม่สามารถ decrypt SK_tgs มาใช้ได้

TGT มีเพียง KDC ที่อ่านได้ ใช้เพื่อขอ Service Ticket SK_tgs ใช้พิสูจน์ตัวตน User แทน Kc

TGS-Request (Ticket-Granting Service Request)

TGS-Request: user ส่ง authenticator ({alice, timestamp}Sk_tgs) คู่กับ TGT

KDC decrypt TGT ด้วย Kkrbtgt และได้ Sk_tgs มา ถ้าสามารถ decrypt authenticator ได้ แสดงว่าเป็น alice ตัวจริง

TGS-REQ
├─ sname         : cifs
├─ ticket        : {alice, SK_tgs, endtime}Kkrbtgt   ← TGT
├─ nonce         : 5307
└─ authenticator : {alice, timestamp}SK_tgs

TGS-REQ
├─ sname         : cifs
├─ ticket        : {alice, SK_tgs, endtime}Kkrbtgt   ← TGT
├─ nonce         : 5307
└─ authenticator : {alice, timestamp}SK_tgs

sname : service name ที่ user ต้องการใช้บริการ ในที่นี้คือ cifs(file share)
ticket : TGT ที่ได้จาก AS-Response
authenticator : usernameและ timestamp ที่ Encrypt ด้วย SK_tgs
SK_tgs : user ได้มาจาก enc-part ของ AS-Response
สังเกตว่า SK_tgs มีเพียง user ตัวจริงที่ decrypt ได้ เพราะทราบ Kc
หลังจากนี้ user ไม่จำเป็นต้องพิมพ์ password ใหม่ เพื่อที่จะขอใช้ service ใดๆแล้ว เพราะใช้ SK_tgs ยืนยันตัวตนแทน (จนกระทั่ง TGT expire)

KDC ตรวจ TGS-Request อย่างไร

KDC เริ่มจาก decrypt TGT ด้วย Kkrbtgt ที่มีเพียง KDC รู้ — KDC จะได้ SK_tgs , username ของ user ที่ต้องการใช้บริการ service
KDC นำ SK_tgs จากขั้นตอนที่แล้ว มา decrypt authenticatorเพื่อตรวจสอบว่า user ใน TGT เป็น userเดียวกับ userใน authenticator หรือไม่

TGS-Reply (Ticket-Granting Service Reply)

KDC ออก Service Ticket คู่กับ enc-part ({SK_svc, endtime}Sk_tgs)

alice เก็บ Service Ticket ไว้ และ decrypt enc-part ด้วย Sk_tgs และเก็บ SK_svc ไว้

TGS-REP
├─ cname    : alice
├─ ticket   : {alice, SK_svc, PAC, endtime}Ks   ← Service Ticket
└─ enc-part : {SK_svc, endtime, nonce}SK_tgs

TGS-REP
├─ cname    : alice
├─ ticket   : {alice, SK_svc, PAC, endtime}Ks   ← Service Ticket
└─ enc-part : {SK_svc, endtime, nonce}SK_tgs

cname : ชื่อ user ที่ได้รับ service ticket
ticket : Service Ticket ที่เข้ารหัส (Encrypt) ด้วย Ks user ถือไว้ได้แต่อ่านหรือแก้ไขข้างในไม่ได้ มีเพียง service ปลายทางที่ถอดได้
enc-part : encrypted part ที่เข้ารหัสด้วย SK_tgs — user ที่มี SK_tgs ถอดได้
Ks : service long-term key ได้มาจาก password ของ accountที่เป็นเจ้าของ SPN(Service principle name) มีเพียง KDCและ serviceนั้นที่รู้
SK_svc : session key ตัวใหม่ที่ KDC สุ่มขึ้น ใช้ระหว่าง user กับ service ปลายทาง
PAC : Privilege Attribute Certificate ข้อมูลสิทธิ์ของ user เช่น SID และ group
ทำแค่ ครั้งแรกต่อ service หลังจากนั้น client ใช้ตั๋วใน cache ได้จนกว่าตั๋วจะหมดอายุ

Ks คืออะไร

เช่นเดียวกับ krbtgt — ทุก service ถือว่าเป็น account หนึ่ง จึงมี password ของตัวเอง ซึ่งมีเพียง KDC และ service นั้น ที่รู้
ในเมื่อมีเพียง KDC และ service ที่รู้ password หมายความว่า มีเพียง service ปลายทางเท่านั้น ที่เปิด Service Ticket ได้
และเป็นการรับประกันว่า Service Ticket ถูกออกโดย KDC จริง

PAC `คืออะไร`

เป็นข้อมูลสิทธิของ user เช่น SID , group
เพราะว่า TGS จะออก Service Ticket ให้เสมอ โดยไม่สนใจว่า user นั้นมีสิทธิใน Service นั้นหรือไม่
PAC เป็นข้อมูลให้ Service พิจารณาว่า user นั้น มีสิทธิใน Service นั้นจริงไหม

Sk_svc คืออะไร

session key ตัวใหม่ที่ KDC สุ่มขึ้น ใช้ระหว่าง user กับ service ปลายทาง
ใช้เพื่อพิสูจน์กับ Service ว่า เป็น user ตัวจริง ที่มี Sk_tgs ถึงจะสามารถ decrypt มาอ่านได้
Sk_tgs, SK_svcทำหน้าที่เดียวกัน คือ พิสูจน์ว่า เป็น key ที่นำมาใช้แทน Kc, Ks
ต่างกันที่ Sk_tgs จริงๆ สามารถใช้ Kc แทนได้เสมอ แต่อาจทำให้ user จำเป็นต้องพิมพ์ password บ่อยๆ
เพื่อนๆ คงสงสัยว่า ใช้ Ks เพื่อพิสูจน์กับ Service แทนไม่ได้หรือ?
สามารถทำได้ในทางทฤษฎ ีแต่จะทำให้ user รู้ Ks
ถ้า "user รู้ Ks" หมายความว่า user สามารถ "ออก Ticket ปลอม" เป็นชื่อใครก็ได้ สิทธิเท่าไหร่ก็ได้ เสมอ

AP-Request (Application Request)

AP-REQ:_ alice ส่ง Service Ticket คู่กับ authenticator ที่ encrypt ด้วย SK_svc_

service จะ decrypt ticket ด้วย Ks ของตัวเองได้ Sk_svc

service นำ Sk_svc ไป decrypt authenticator ถ้าได้ แสดงว่าเป็น alice ตัวจริง

service ตรวจสอบ PAC ว่า alice มีสิทธิใน Service นี้จริงหรือไม่

AP-REQ
├─ ticket        : {alice, Sk_svc, PAC, endtime}Ks   ← Service Ticket
└─ authenticator : {alice, timestamp}Sk_svc

AP-REQ
├─ ticket        : {alice, Sk_svc, PAC, endtime}Ks   ← Service Ticket
└─ authenticator : {alice, timestamp}Sk_svc

ticket : Service Ticket ที่ได้จาก TGS-Response ส่งต่อให้ service
authenticator : username และ timestamp(เวลาฝั่ง client) ที่ Encrypt ด้วย Sk_svc
Sk_svc : user ได้มาจาก enc-part ของ TGS-Response

AP-Response (Application Reply)

AP-REP:_ service ส่ง {_timestamp}Sk_svc ที่ได้จาก authenticator กลับไป

alice decrypt enc-part ด้วย Sk_svc และตรวจว่า timestamp ตรงกันกับ timestamp ที่ alice เก็บไว้ไหม

หลังจากนี้ alice, service จะใช้ Sk_svc ในการ encrypt, decrypt message หากัน

AP-REP
└─ enc-part : {timestamp}SK_svc

AP-REP
└─ enc-part : {timestamp}SK_svc

เกร็ด — ทำไมต้องส่ง timestampกลับมา จริงๆ ในขา AP-Response timestamp ใช้แทน nonce

Epilogue

ก่อนนี้ ช่วงที่ทำโจทย์ AD เจ้าของบทความชอบ run command อย่างเดียวเลย ซึ่งว่ากันตามตรง มันก็พอที่จะทำ HTB-Lab ระดับ easy ได้นั่นละครับ
แต่เจ้าของบทความคิดว่า การทำโจทย์โดยที่ไม่เข้าใจ Mechanic เลย อาจจะเป็นการเรียนที่ผิดวิธีไปนิดหนึ่ง
แล้วเจ้าของบทความมีโอกาสได้อ่าน web novel ยุค 80 เรื่องหนึ่งมา ชื่อว่า "Designing an Authentication System: a Dialogue in Four Scenes"
ซึ่งประทับใจมากครับ เป็น web novel ที่ Athena และ Euripides ถกเถียงกัน เรื่อง "ระบบยืนยันตัวตนบน network ตั้งแต่ 0 จนเป็น Charon(Kerberos)ที่ใช้กันถึงทุกวันนี้"
ตอนแรก บทความนี้จะเป็นสรุปเรื่องที่ Athena คุยกับ Euripides นั่นละครับ แต่รู้สึกว่า "อรรถรส" น่าจะหายไปเยอะเลย ก็แนะนำให้เพื่อนๆ ลองอ่านดูนะครับ ส่วนตัวชอบที่ "Euripides นั่งหาปัญหามาให้ Athena แก้เรื่อยๆ" มากครับ
ขอบคุณเพื่อนๆ ที่อ่านมาจนถึงตรงนี้นะครับ เจอกันใหม่ในบทความหน้าครับ

Reference

Bill Bryant (1988), Designing an Authentication System: a Dialogue in Four Scenes

Contents

Introduction

Kerberos Authentication Flow

AS-Request (Authentication Server Request)

Password in KDC

AS-Request (Authentication Server Request) (continue)

ทำไมต้อง Timestamp

AS-Response (Authentication Server Response)

krbtgt คืออะไร

SK_tgs คืออะไร

AS-Response (Authentication Server Response) (ต่อ)

TGS-Request (Ticket-Granting Service Request)

KDC ตรวจ TGS-Request อย่างไร

TGS-Reply (Ticket-Granting Service Reply)

Ks คืออะไร

PAC คืออะไร

Sk_svc คืออะไร

AP-Request (Application Request)

AP-Response (Application Reply)

Epilogue

Reference

`SK_tgs` คืออะไร

PAC `คืออะไร`