שאלה בנוגע לאבטחת ההזדהות מול שרת בדומיין

[DXM]

שלום לכולם:

נגדיר את המצב הבא, יש לי דומיין כלשהו, עמדת קצה מנסה לבצע את הזדהות מול הDC, אני הצלחתי לזהות את העמדה הזאת (IP וכו') ומבצע עליה סניפינג, לצורך העניין נגיד שרק פרוטוקול של קרברוס פתוח (LM, NTLM2,NTLM "מכובים").

איפשהו צריך להתבצע האשינג של הסיסמא, כלומר הפכת הסיסמא לערך שהוא ONE WAY FUNCTION כפי שהוא מופיע בNTDS.DIT.

השאלה הראשונה היא היכן מתבצע האשינג, כבר אצל הקליינט, או שהDC מקבל את הסיסמא כמו שהיא, מבצע את האשינג ואז בודק מול הNTDS.DIT?

השאלה השניה, במידה וזה מבוצע אצל הקליינט, מה מונע ממני לבצע סניפינג על הפקט שנשלח, לעתיק אותו ורק לשנות את היעד? (הרי האשינג אצלי) במידה וזה מבוצע בצד השרת מה מונע ממני לבצע סניפינג לנתח את הפקט ולזהות ישר את הסיסמא?

השאלה השלישית: לפי מה שהבנתי הסיבה היא שהLSASS מצפין את המידע, אבל עדיין לא הנבתי מה מונע פשוט לקחת את החבילה כמו שהיא מוצפנת ולשנות את יעד אליי (איזשהי הצפנה מבוססת זמן מסויים או שההצפנה יכול להיות שונה בהתאם לקליינט... יכול להיות?)

תודה רבה...

נ.ב

יכול להיות שלא יריתי לכיוון בכלל.

[DOGMA]

1) בכלל לא בכיוון, בKerberos הקליינט והשרת לא מחליפים ססמאות(או מפתחות לייתר דיוק) בינהם כלל וכלל...

בכל מקרה הקליינט לא שולח שום דבר לשרת מעבר ל-Auth Request שמכילה את הID של היוזר, הוא מקבל בחזרה דבר שנקרא Session Key שמוצפן עם המפתח שנוצר בשרת שנגזר מהסיסמא של המשתמש.

אם המשתמש בצד הקליינט מצליח לפענח את ה-SK בעזרת המפתח שהוא יצר בעצמו שגם הוא נגזר מהסיסמא של המשתמש הוא משתמש בו בשביל להתחבר לרשת, השרת בנוסף ל-SK שולח גם TGT(Ticket Granting Ticket) שמוצפן עם מפתח נוסף שמופק מה-SK שאותו הקליינט פענח, הTGT מכיל את "ההרשאות" של המשתמש ברשת.

לאחר מכן כל ההזדהות מול משאבי הרשת מתבצעת בעזרת ה-TGT שאיננו מכיל שום מידע על גבי הסיסמא של המשתמש.

2) בכלל לא בכיוון כמו שנאמר אין החלפת סיסמאות בינהם, בעקרון כן ניתן "לתפוס" SK ו-TGT ולבצע התקפה קריפטוגרפית עליהם, אבל וזה אבל גדול לשינהם יש תוקף והסיכוי שלך לפצח בהצלחה הצפנה סימטרית כאשר שניהם עדיין בתוקף הוא אפסי. בנוסף יש הגנות מפצות נוספות כמו SSL ו Message Security מובנה בכל חבילה של Kerberos "שמונעות" התקפות "MiTM".

3) אם יש לך גישה פיזית לקליינט ברור שאתה יכול להשיג את הסיסמא, בכל אופן ה-LSASS לא מצפין סיסמאות, אלא אם מופעל מנגון Caching, זה למה גם מבטלים אותו בתחנות שנמצאות במקומות "מסוכנים", אבל אין לזה שום קשר ל-Kerberos עצמו, זאת סתם דרך לאפשר לתחנה להתחבר "לעצמה" כאשר אין גישה לשרת ה-AS של Kerberos.

[DXM]

או קי, טוב לדעת שאני בכלל לא בכיוון.

הנה מה שאני (חושב ש..) יודע, אם אפשר תאשר אם זה נכון:

(1)הNTDS.DIT מכיל עליו את היוזר ואת הסיסמא אחרי שהיא עברה האשינג. (2) כלומר בלתי אפשרי לשחזר אותה הפוך, אלא רק בצורה של ניחוש הסיסמא המקורית (דיקטושנרי או ברוטפורס ודומיו) ולהעביר אותה דרך אותה פונקציה שמשמשת את הפרוטוקול שאיתו אנחנו מבצעים (4) את האשינג (קרברוס, LM NTLM וכו').

(5)בעת ההזדהות הקליינט מבקש ממנו שישלח לו את ההזדהות. (6) ההזדהות הזו מוצפנת על ידי מספר פרוטוקלים, (7) שבמידה ולא הצלחנו לפרוץ אותם מספיק מהר הם חסרי פואנטה. (10 ) "מפתח" מועבר לקליינט לפתוח את הפרוטקולים הללו. (9)החבילה הזדהות מועברת לקליינט, (10) הקליינט משתמש בפרוטוקול שייצר את ה"האש" כמו (11) קרברוס, LM וכו', על מנת לבצע האשינג לסיסמא שהוקלדה. (12)במידה והמפתח שקיבלנו פותח את ההצפנות הקודמות, מבוצעת בדיקה האם ה"האש" מצליח לפתוח את ההצפנה האחרונה שנוצרה עוד בשרת, (13) במידה וכן נוצר הTOKEN ויש לנו הנתונים המתאימים לבצע הזדהות מול שירותים המסופקים על ידי הדומיין.

(אה אגב, דובי תודה רבה, קיוותי שתגיב בהתאם לדיון שהיה לנו פעם (בו אני יצאתי די אידיוט, אבל מטעיות לומדים) בנוגע להדהות מול דומיין).

ודרך כל התהליך הזה מתבצעת הזדהות ללא צורך בהחלפת הסיסמא, (14) ועקב מגבלת הזמן כמעט בלתי אפשרי לבצע את התקפה של "איש באמצע", (15) וזו הסיבה המחורבנת ללמה כאשר יש הפרשים גדולים מדי בשעונים של המחשבים יש דפקט ענק בהזדהות מול השרת?

[DOGMA]

הסיסמאות ב-AD מוצפנות, וניתנות "לפענוח", אחרת אתה לא יכול להשתמש בצורת הזדהות שלא מבוססת על העברת סיסמה....

בקובץ ה-DB של ה-AD יש 5 אובייקטים(רלוונטיים לנושא הזה) של סיסמאות, LM Hash, NT Hash, LM Hash History, NT Hash History וה-PEK(Password Enctryption Key), כל השדות האלה מוצפנים.

ה-PEK הראשי(שאיתו קובץ הNTDS מוצפן(או לייתר דיוק השדות הרלוונטיים מוצפנים) מוצפן עם ה-Bootkey של כל DC, והוא אחיד בכל ה-Domain.

הסיסמאות עצמן ששמורות ב-DB מוצפנות בד"כ עם Chain של PEK-RC4-DES.

ככה שהסיסמאות השמורות ב-DB ניתנות "לפריצה" באותה דרך שבה ניתן לפרוץ סיסמאות מקומיות ב-SAM, עושים Dump ל-DB ומוציאים את ה-Bootkey של ה-DC מה-Hive, בסופו של דבר אתה מקבל בוחטה של סימאות LM+NT מוצפנות.

ההצפנה ניתנת לפירצה בקלות יחסית, כאשר יש לנו PEK לא מוצפן, וסיסמאות מוצפנות.

השכבה הרשאונה של-RC4 מוצפנת בצורה דיי "מטומטמת"

משתמשים ב-PEK וב-16 בתים הראשונים של ה-Hash בשביל לייצר את המפתח ל-RC4.

שכבת ה-DES היא אותה הצפנה שמשמשת את ה-SAM, כאשר ה-SID וה-RID של חשבון המשתמש משמשים לייצרת המפתח במקום ה-Syskey בSAM מקומי.

בכל מקרה אם עדיין לא הבנת, ה-Session Key וה-TGT נוצרים בכל מקרה הקליינט פשוט לא מסוגל לפענח אותם ולכן הם לא שמישים.

לשעה יש פקטור חשוב בהרבה דברים, בין השאר ה-Time Stamp בשביל Message Security, והשעה זה גם אחד מהאלמנטים הרנדומאליים שמשמשים ל-One Way Function לצורך ייצירת המפתחות, מעבר לכך אין לה ממש השפעה מהיבט של תוקף, כיוון שהתוקף הדיפולטי לToken כפי ש-MS הכתיבה הוא 600 דקות.

אבל בכל מקרה אתה נכנס פה לדברים שלא קשורים להזדהות, יש הבדל בין איך ללמה...

איך זה עובד בצורה מאוד פשוטה, השרת והקליינט יוצרים שניהם לחוד מפתחות(שאם הסיסמה שהמשתמש הקיש היא נכונה, וכל שאר הגורמים נכונים הם יהיו זהים), השרת שולח מסר מוצפן לקליינט, הקליינט מנסה לפענח אותו, הצליח? יופי! לא הצליח? באסה...

אתה גם צריך להפריד בין Authentication ו-Authorization, מדובר על דברים שונים לגמרי, יש לך פה סלט לא קטן והמון "טעויות" אקסיאומאליות.

[DXM]

אוקי, נשמע הגיוני...

אבל לא הבנתי משהו, אם הקליינט מייצר בעצמו את המפתח, והמפתח מתבסס על נתונים שלא קיימים בקליינט, אלא על בDC בNTDS.DIT כמו RID ה וSID והPEK של היוזר, איך יודע הקליינט ליצור את המפתח להצפנה הזו?

יכול להיות שקיים תהליך ראשוני בו מועברים הנתונים האלו, כלומר לאחר שהקשנו שם משתמש וסיסמא, נשלחת בקשה לDC לשליחת הSID הRID והPEK בהתאם ליוזר שהקשנו?

כדי ליצור מפתח מתאים אתה חייב להיות בעל הנתונים של איך שיצרו את ההצפנה אחרת היא לא תעבוד.

[DOGMA]

אני לא מבין מה לא ברור, בקרברוס ה-AS והקליינט שניהם יוצרים מפתח בנפרד המבוסס על הסיסמא של המשתמש.

במימוש של -MS לתקן, ה-KDC בדומיין(שיושב על כל DC בד"כ) מכיל את ה-AS ואת ה-TGS(Ticket Granting Server).

בצורה גסה:

המשתמש מקליד סיסמא, התחנה הופכת את הסיסמא ל-NTLM Hash, לאחר מכן התחנה מריצה עליו One Way Function הפלט של פעולה זו יהיה המפתח הסודי של הקליינט

התחנה שולחת Authentication Request ל-KDC, השרת מבקש את ה-NTLM HASH של המשתמש מה-AD, מריץ עליו One Way Function שיהיה המפתח הסודי שיושב בשרת, יוצר Session Key ומצפין אותו עם המפתח שנוצר.

השרת שלוח את ה-Session Key המוצפן למשתמש.

השרת שולח את ה-TGT למשתמש שהוצפן ע"י ה-Session Key.

הפרוטוקול מבוסס על זה ששני המפתחות יהיו זהים, המשתמש מנסה לפענח את ה-Session Key, הצליח? יופי הוא יכול לפנעח את ה-Token שהוא קיבל מה-TGT שמוצפן עם ה-Session Key.

למשתמש עכשיו יש Session Key ו-TGT מפוענחים? יופי הוא יכול להתחבר למשאבים ברשת.

Kerberos תומך גם בPKI, שם ה-Session Key מוצפן ע"י השרת בעזרת המפתח הציבורי של המשתמש, כאשר השרת מזהה את המשתמש ע"פ המפתח הציבורי שלו, אם השרת לא מכיר את המפתח הציבורי הוא לא ינפיק למשתמש Session Key או -TGT.

בצורה פשוטה יותר - המשתמש חותם על ה-AS עם המפתח הפרטי שלו, השרת מצפין את ה-SESSION KEY עם המפתח הציבורי של המשתמש ומשם זה זהה לתהליך הרגיל של הקשת סיסמא, ככה ממומש Smart Card Logon ברשת.

[DXM]

רק להבנה, הHASH הוא לא גם סוג של OWF? כאילו לפי מה שהבנתי בלתי אפשרי לשחזר את הHASH לצורתו המקורית (אלא באמצעות ניחוש)

כלומר זה מוצפן פעמיים על ידי OWF, פעם ראשונה האש של הסיסמא שהוא קבוע, ופעם שניה OWF הספציפי לאותה ההזדהות?

[DOGMA]

פונקציות הצפנה לרוב דורשות מפתחות באורך אחיד, הסיבה למה משתמשים ב-hash ולא בסיסמה היא עלמנת לעבוד עם נתונים באורך זהה בכל פעם.

על מנת ליצור מפתח הצפנה חדש כל פעם משלבים גורמים רנדומאליים כמו למשל הזמן במילי שניות מ-00:00 @ 01/01/1970...

כאשר המפתחות שאתה משתמש בהם הם חלשים יחסית, אתה רוצה ליצור כל פעם מפתח חדש על מנת להוריד את הסיכוי שמישהו יצליח ליצור מפתח בעצמו בזמן שהמפתח נמצא בתוקף.

שוב ההסברים הנ"ל הם מאוד שטחיים, אם אתה רוצה להכנס ללמה ולא לאיך יש את ה-RFC של Kerberos.

בהצלחה...

http://www.ietf.org/rfc/rfc4120.txt

[DXM]

תודה רבה...