สวัสดีครับทุกท่าน วันนี้ผมจะพูดถึง Network Authentication Protocol ที่มีชื่อว่า Kerberos ซึ่งมีการทำงานในรูปแบบของ Ticket โดยโปรโตคอลนี้อนุญาตให้ 2 แหล่ง (Client และ Server) ที่จะสามารถยืนยันตัวกันเองได้บนระบบ network จากการทำงานของ Kerberos server ครับ
โดยองค์ประกอบของ Kerberos จะมีอยู่ 3 ส่วนหลักๆ ครับ
— KDC (Key Distribution Center)
- Authentication Server (AS)
- Ticket Granting Service (TGS)
— Client (เพื่อขอการเข้าถึง)
— Service (Client พยายามที่ขอเข้าถึง)
พูดไปยังคงไม่เห็นภาพกันแน่ๆ ดังนั้นมาดูขั้นตอนการทำงานกันดีกว่า
ใน Active Directory นั้น เมื่อ Client ได้ยืนยันตัวตนบน Domain Controller แล้ว จะได้รับ ticket-granting-ticket (TGT) ซึ่งนี่คือตั๋วในการยืนยันตัวของเรานั้นเองงง โดยกระบวนการยืนยันตัวตนจะเป็นแบบนี้
- Client จะส่งคำขอไปยัง Authentication Server (AS) บน Domain Controller โดยคำขอนี้จะมี encrypted timestamp ติดไปด้วย หลังจากนั้น AS จะตรวจสอบ account’s password hash และพยายามที่จะถอดรหัส
- หากสำเร็จ Client จะได้รับ Ticket-granting-ticket (TGT) จาก Ticket Granting Service (TGS)
- หลังจากที่ Client ได้รับ TGT แล้วจะสามารถเข้าถึง service อื่นได้ๆ เช่น Resource server โดยการที่จะเข้าถึงได้นั้น Client ต้องส่ง TGT ไปให้ TGS พร้อมกับข้อมูล service ที่ต้องการจะเข้าถึง แล้ว TGS จะตรวจสอบ TGT และเช็คกับ AD ว่ามีสิทธิ์ใน service นี้หรือไม่ ในกรณีที่มีสิทธิ์ที่จะเข้าถึง TGS จะให้ ticket ไว้สำหรับการเข้าถึง service นั้นๆ
- สุดท้ายก่อนจะเข้าถึง service, Client ต้องส่ง ticket ไปยัง service ปลายทางก่อน โดย service ปลายทางนั้นก็จะเชื่อมระบบของ Kerberos (TGS) เช่นกัน ทำให้ service ยอมรับ ticket ที่ได้มาและให้เข้าถึง service ได้
โดยปกติแล้ว TGT จะมีอายุเพียง 10 ชั่วโมง หากหมดอายุแล้ว windows จะทำการสร้างใหม่โดยอัตโนมัติ
และตลอดทั้งกระบวนการของ Kerberos จะมีการใช้ Long-term security keys อยู่ 3 อัน นั่นก็คือ
— Client Long-term secret key โดยได้มาจาก password ของ client ใช้เพื่อเช็ค encrypted timestamp และเข้ารหัส session key
— Target Long-term secret key โดยได้มาจาก password ของ service เป้าหมาย ใช้เพื่อเข้ารหัส TGS แล้ว sign PAC
— KDC Long-term secret key โดยปกติแล้วจะเรียกว่า “Domain Key” ที่ได้รับจาก krbtgt service account ใช้เพื่อเข้ารหัส TGS แล้ว sign PAC
แล้ว Long-term Keys พวกนี้เอามาใช้ตอนไหนบ้างล่ะ เราจะกลับไปใช้รูปแบบของการยืนยันตัวตนของ Kerberos กันอีกครั้ง แต่ในครั้งนี้เราจะขอเพิ่มรายละเอียดเข้าไปอีก เริ่มจาก
1. AS-REQ: เริ่มต้นที่ Client ได้ทำการ pre-authenticated โดยการส่ง AS-REQ ไปยัง AS โดย AS-REQ ประกอบไปด้วย encrypted timestamp (เข้ารหัสด้วย password hash ของ client) ที่ได้ตรวจสอบจาก KDC แล้ว โดย “encrypted timestamp” ถูกเรียกอีกชื่อว่า “pre-authentication” และถูกตั้งค่าให้เป็น Default ใน Microsoft Kerberos Environment
2. AS-REP: หลังจากที่ pre-authentication สำเร็จแล้ว KDC จะส่ง 2 อย่างไปให้แก่ Client นั้นก็คือ
— Client/TGS session key ที่ถูกเข้าด้วย Client long-term key
— Ticket-Granting-Ticket (TGT) ซึ่งมี Client/TGS session key ที่ถูกเข้ารหัสด้วย KDC long-term key และถูกใช้ในการ sign PAC ด้วย โดยภายใน TGT จะมีข้อมูลต่อไปนี้
- Name: ชื่อของผู้ใช้งาน
- Start time & End time: ทำเครื่องหมายอายุการใช้งานของ ticket โดยปกติใน Window AD Environment จะมีระยะแค่ 10 ชั่วโมง
- Authorization data: ข้อมูลสิทธิ์ของผู้ใช้งาน และสิทธิ์การเข้าถึง ใน Windows ข้อมูลสิทธิ์จะอยู่ในรูปของ Privilege Attribute Certificate (PAC) object
- The Client/TGS session key: ใช้ในการสื่อสารระหว่าง Client และ TGS
3. TGS-REQ: ในตอนที่ผู้ใช้งานต้องการที่จะเข้าไปใช้งาน service จะต้องส่งบางอย่างไปที่ TGS นั้นคือ
— Authenticator message (ถูกเข้ารหัสด้วย Client/TGS session key)
— Encrypted TGT และ Ticket request
ถ้า TGS ได้รับ TGS-REQ กับ valid TGT, มันจะส่ง response “TGS-REP” กลับไป และ TGS จะตรวจสอบว่า service ที่ถูกขอการเข้าถึงมีอยู่หรือไม่ และสร้าง Service ticket (ST) ขึ้นมา และส่งกลับไป ซึ่ง ST มีองค์ประกอบอยู่ 2 ส่วนคือ
- Client Portion ซึ่งถูกเข้ารหัสด้วย Client/TGS session key
- Server Portion ซึ่งถูกเข้ารหัสด้วย Target long-term key และภายในมี PAC ของผู้ใช้งานอยู่ และเป็น ST ที่ผู้ใช้งานจะส่งไปยังบริการที่พยายามจะเข้าถึงในภายหลัง
4. AP-REQ: เพื่อที่เข้าถึงข้อมูล Client จะส่ง AP-REQ message ไปให้ที่ Service Server ที่เราต้องการ โดยที่ภายในมี ST ที่ได้มาจาก TGS-REP หลังจากนั้น Service Server จะตรวจสอบความถูกต้องโดยใช้ lightweight cryptographic function และส่วนอื่นๆ เพื่อให้มั่นใจได้ว่า ST ถูกต้องจริงๆ
5. AP-REP: Service Server ได้ส่ง AP-REP message กลับมายัง client โดยmessage นี้มีส่วนที่อาจใช้เพื่อกำหนดความสัมพันธ์ด้านความปลอดภัยระหว่าง Client และ Service Server โดยไม่ต้องแลกเปลี่ยนอะไรอีก
และนี่ก็คือขั้นตอนทั้งหมดในการยืนยันตัวตนบน Kerberos เยอะแยะไปหมดเลยใช่มั้ยล่ะครับ แต่นั้นก็เพื่อเพิ่มความปลอดภัยในการใช้งานนั้นเอง จึงมีองค์กรหลายแห่งบนโลกที่เลือกใช้งาน Kerberos เพราะว่ามันมีความสามารถในการใช้งาน strong encryption algorithms เพื่อป้องกัน password และ authentication ticket ได้ไงครับ
แต่ถ้าจะถามว่าเราไม่สามารถโจมตี Kerberos ได้เลยใช่มั้ย คำตอบก็คือ “มันยังสามารถโจมตี” ได้อยู่ครับ โดยวิธีบางส่วนที่ได้ผลในการโจมตีแล้วมีโอกาสที่จะสำเร็จจะมี
- Pass-the-ticket: เป็นวิธีที่ hacker จะปลอม session key ขึ้นมาแล้วส่งไปยัง resource ในระบบ (เช่น file share, administrative share) จากการสร้างหรือได้รับมาจาก TGT หรือ TGS
- Golden Ticket: การใช้ ticket ที่ให้สิทธิ์เป็น Domain admin
- Silver Ticket: การปลอม ticket เพื่อเข้าถึง Service
- Credential Stuffing/ Brute Force: เป็นวิธีที่พยายามที่จะเดารหัสผ่าน (มักใช้เวลาที่ค่อนข้างนาน)
- DCShadow: วิธีที่ hacker จะสร้างเข้าไปใน network แล้วสร้าง Domain Controller ของตัวเองขึ้นมาเพื่อใช้ในการโจมตีต่อไป
จะเห็นได้ว่าถึงระบบจะมีความสามารถในการเช็คความถูกต้องของ ticket,การเข้ารหัส,การใช้ long-term key ที่เรียกได้ว่า “แน่นโครตๆ” ก็ยังไม่วายโดน hacker โจมตีได้อยู่ดี ดังนั้งถึงท่านผู้อ่านที่มีระบบอยู่นี้ในมือ ก็ขอให้ติดตั้งตาม best security practice เพื่อป้องกันการโจมตีที่อาจจะเกิดขึ้นภายในอนาคตนะครับผมมมม
Reference:
Kerberoasting Active Directory Attack Explained — Blog | QOMPLX
Kerberos Authentication Explained (varonis.com)
Kerberos Single Sign-On System (ipfonix.com)
What is Kerberos and How Does it Work? — Definition from SearchSecurity (techtarget.com)
Kerberos Authentication Overview | Microsoft Docs
