עצירה וחסימה של NTLMRelayX
MiTM6 Mitigation

בלי כתוביותעם כתוביות

מילון מושגים:

LDAP - פרוטוקול לגישה ולשאילתה של שירותי מדריך כמו Active Directory, לאיתור וניהול משתמשים ומשאבים.

SMB - פרוטוקול של Windows לשיתוף קבצים ומדפסות ברשת ולגישה למשאבים מרוחקים.

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

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

NTLM - פרוטוקול אימות ותיק של מיקרוסופט המבוסס על ערכי האש של סיסמאות, שקדם ל-Kerberos.

רג'יסטרי - מסד נתונים מרכזי ב-Windows ששומר הגדרות של מערכת ההפעלה ושל תוכנות מותקנות.

שרת DNS - שרת שמתרגם שמות מתחם קריאים, כמו example.com, לכתובות IP שהמחשבים משתמשים בהן.

IPv6 - הדור החדש של פרוטוקול IP, עם מרחב כתובות גדול בהרבה מ-IPv4, שנכתבות בפורמט הקסדצימלי.

עצירה וחסימה של NTLMRelayX MiTM6 Mitigation

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

נושאי הסיכום המוצגים בשיעור:

1. עיקרון ההגנה: בדיוק כפי שמנענו הממסר ב-SMB באמצעות חתימה, כך מונעים גם כאן, וההגנה פשוטה מאוד, למנוע את הממסר של NTLM עצמו.

2. הבעיה של הפרוטוקול: פרוטוקול NTLM אינו יודע למנוע התקפת ממסר ואינו יודע להתמודד איתה, ולכן הפתרון הוא לא בשלב האימות אלא בשלב הבא של הפרוטוקול עצמו.

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

4. LDAP signing והאסימונים: כפי שעשינו SMB signing צריך לעשות גם LDAP signing, שהפרוטוקול ידרוש חבילות חתומות עם הסיסמה של המשתמש, אבל גם LDAP signing היה פגום, ולכן הוסיפו לו אסימונים נוספים, תוספת שקרתה לפני שנים בודדות, ואותם אסימונים חדשים הם מה שיציל אותנו.

5. ההודאה הרשמית של מיקרוסופט: באתר של מיקרוסופט הם מודים בעצמם שיש להם באג שהתגלה ב-2017, עם מספר CVE משלו, שהיא בעיה של התקפת איש בתוך הרשת שבה התוקף מצליח להעביר קדימה בקשות אימות אל שרת ה-LDAP.

6. ביצוע ההקשחה: בניהול המדיניות הקבוצתית יוצרים הגדרה שתיכנס אל הרישום של כל המחשבים בארגון ובמיוחד של בקרי הדומיין ותדרוש את החתימה הזאת, כדי שבקר הדומיין לא יקבל חבילות LDAP שאינן חתומות, ומעניין לגלות שבהגדרות האבטחה הקיימות בקר הדומיין מוגדר מראש כמי שאינו דורש חתימה, אך הגדרה זו אינה עוזרת ואיננו נוגעים בה.

7. הגדרת האסימונים: בתוך אפשרויות האבטחה מאתרים את ההגדרה החדשה של האסימונים, פותחים אותה, מסמנים אותה ומגדירים לתמיד לדרוש את האסימונים, ואז סוגרים, מריצים עדכון מדיניות עם כפייה כדי שהשרת המקומי יאכוף מחדש את המדיניות ויכניס אותה אל הרישום המקומי, ומוודאים בכלי הצגת המדיניות שההגדרה נקלטה על בקר הדומיין ומאיזו מדיניות, ומבצעים הפעלה מחדש ליתר ביטחון כדי ששירות ה-LDAP יעבוד מחדש.

8. המלצה על מדיניות נפרדת: מומלץ לא לשנות את המדיניות הקיימת של ברירת המחדל אלא ליצור מדיניות חדשה ולשים בה רק את ההגדרה הזאת, שינוי מדיניות ברירת המחדל נחשב לא כל כך יפה.

9. ההדגמה מחדש והכישלון: מפעילים שוב את התקפת ההתחזות לשרת DNS על שרת אחד בלבד כדי שלא לפגוע בכל הרשת, מוודאים שהשרת שהופעל מחדש קיבל את ה-DNS שלנו, הדפדפן עם ההרשאות של מנהל הדומיין מחפש פרוקסי ואנחנו מגלגלים את העימות של הפרוקסי אל ה-LDAP, אך הפעם ההתקפה נכשלת, מפני שבקר הדומיין דרש חתימה.

10. ההגנות האלטרנטיביות והסיבה שאיננו מיישמים אותן: היינו יכולים לנתק את השירות של חיפוש הפרוקסי האוטומטי, לבטל את IPv6, או להכניס את מנהל הדומיין לקבוצת המשתמשים המוגנים כדי ש-NTLM לא יעבוד עליו בכלל ורק קרברוס, אך כל אלה מייצרים הרבה אי נוחות, שכן רוצים שמנהל הדומיין יוכל להתחבר דרך כתובות IP ולא רק דרך שמות מחשבים, ולא רוצים לבטל את הפרוקסי האוטומטי כי יש פרוקסי בארגון ומשתמשים עם מחשבים ניידים, ולא לבטל IPv6, ולכן פשוט מקשיחים את ה-LDAP ודורשים חתימה, ואם יש תוכנות צד שלישי ישנות שלא יעבדו עם זה, זו בעיה שלהן, כי רשת חשופה מסוכנת הרבה יותר.

11. כיצד מבטלים את שירות הפרוקסי האוטומטי למי שרוצה: השירות אינו מאפשר ביטול מהממשק הגרפי כיוון שהוא מוצג אפור, ולכן נכנסים לרישום במקום שממנו מגיע גם הממשק הגרפי, משנים את ערך ההתחלה משלוש לארבע, כאשר ארבע פירושו מבוטל, ומיד מתעדכן בממשק שהשירות מבוטל, וקיימים גם ערכי רישום לביטול הגילוי האוטומטי של הפרוקסי ולביטול IPv6, שכן בדקנו והם עובדים, אך איננו ממליצים על כל הביטולים האלה, פשוט להקשיח את ה-LDAP עם מדיניות פשוטה מאוד.

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

פרקי ההרצאה: עצירה וחסימה של NTLMRelayX MiTM6 Mitigation

תמלול ההרצאה: עצירה וחסימה של NTLMRelayX MiTM6 Mitigation

הטקסט המלא של הדקות הראשונות בהרצאה «עצירה וחסימה של NTLMRelayX MiTM6 Mitigation» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.

00:02
שלום לכולם, בהרצאה הזו אנחנו נראה איך מונעים את ההתקפה הזאת ומונעים אותה על ידי הלד-אפ סיינינג עם טוקנים כמו שב-SMB מנענו SMB ריליי על ידי חתימה, ככה אנחנו גם פה מונעים. המניעה היא מאוד מאוד פשוטה: לא לאפשר NTLM ריליי עתה, כל ה-NTLM ריליי הזה, למנוע אותו.
00:23
הבעיה שפרוטוקול ה-NTLM לא יודע למנוע התקפת ריליי, הוא לא יודע להתמודד עם זה. אז מה שעושים? אומרים טוב אם אתה לא יודע להתמודד עם זה אז בשלב הבא אחרי העימות של NTLM כבר בשלב ה-LDAP עצמו נחתום כל חבילה ואז האקר לא יוכל לעשות כלום כי האקר לא יכול לחתום על החבילות
00:45
כי אין לו את הסיסמה של היוזר זאת אומרת ש-NTLM ריליי עתק יצליח ההתקפה של NTLM ריליי תצליח אתה תעבור עימות תגיע כבר לשלב הבא של LDAP או SMB ואז כבר בשלב הבא השרת ידרוש פקטים שיהיו חתומים עם הסיסמה של היוזר והאקר לא יודע את הסיסמה של היוזר והוא לא יצליח לחתום על הפקטים אז למרות שהוא עבר אימות
01:10
של ntlm בשלב הפרוטוקול בשלב התכלס השרת לא יקבל ממנו פקטים כי הם לא יהיו חתומים כאילו המניעה היא לא ברמת ה ntlm אלא בשלב הבא של הפרוטוקול עצמו אז כמו שראינו smb סיינינג אז צריך לעשות אותו דבר ldap סיינינג שפרוטוקול אלדאפ ידרוש פאקטים חתומים עם הסיסמה של היוזר,
01:32
אבל גם אלדאפ סיינינג הזה הוא דפוק, אז הוסיפו לו טוקנים נוספים. זה דרך אגב יחסית חדש, כי אלדאפ סיינינג היה דפוק, אז הוסיפו לו טוקנים, וזה קרה לפני כמה שנים בודדות.
01:44
איך עושים את כל זה תכלס? איך מונעים את ההתקפה הזאת? אנחנו באים ל-Tools, בתוך ה-Tools Group Policy Management אנחנו הולכים לעשות שייכנס ל-registry של כל המחשבים בארגון, במיוחד הדומיין קונטרולרים, וידרשו את החתימה הזאת.
02:02
כמו שאתם יכולים לראות, באתר של מייקרוסופט הם מודים בעצמם שיש להם באג שהתגלה ב-2017, זה מספר הבאג הזה, זה נקרא CVE. מייקרוסופט בעצמם מודים בזה שיש בעיה של התקפת Man in the Middle, כאשר האטאקר, התוקף, מצליח לעשות forward, לגלגל קדימה Authentication Request בקשות
02:24
העימות לתוך שרת ה-LDAP בואו נמנע את זה ניכנס כאן לדומיין שלנו נראה שיש לנו כבר פוליסה שעשינו לפני כן שמבטלת אלה למנהר רק שזה לא עוזר כי IPv6 עבד אבל אני לא רוצה לבטל IPv6 אני רוצה בדומיין קונטרולר לדרוש LDAP סיינינג זה הכל שדומיין קונטרולר לא יקבל חבילות LDAP לא חתומות אז מה יש לנו פה בתוך הפוליסה יש
02:49
לנו פה כל מיני הגדרות ובסיקיוריטי סטינגס כבר מוגדר לנו שהדומיין קונטרולר לא צריך בכלל חתימה. אתם רואים איזה שטות זאת? דומיין קונטרולר מראש מוגדר כאחד שלא דורש חתימה.
03:02
לא יודע למה מייקרוסופט עשו את זה כברירת מחדל, נעשה אדיט, ניכנס לפוליסה הזאת, יש פה מעל 3,000 הגדרות, אז אל תנסו לסקור את זה.
03:12
נגיע ל-Security Options של המחשב, ונחפש פה דומיין קונטרולר. ויש פה את ההגדרה הזאת: עכשיו אני לא הולך לגעת בזה כי זה לא באמת יעזור לי בכלום אני צריך משהו יותר חדש וחכם האופציה הזאת עם הטוקינים זה מה שיציל אותי, הטוקינים החדשים האלו שהם הכניסו אני עושה על זה דאבל
03:34
קליק, עושה V ומגדיר תמיד לדרוש את הטוקינים נסגור את הפוליסה אנחנו יכולים לחכות שהשרת יעדכן את הפוליסות שלו לבד או יעשה ריסטארט ואפשר לעשות gp update / force כדי שהשרת המקומי יאכוף מחדש את הפוליסות ויכניס אותן לרג'יסטרי המקומי שלו.
03:54
בואו נעשה ארסופ לבדוק שכרגע ההגדרה הזאת פועלת. ריזלט אנד סט אוף פוליסי. אתם רואים למעלה כתוב ארסופ? זה אומר מה קורה תכלס במחשב הזה ברקע זה לגבי אגרופוליסי, איזה הגדרות פועלות עליו, ואני רואה שההגדרה שלי תפסה על דומיין קונטרולר
04:12
שאני דורש את הטוקינים החדשים ומאיזה פוליסה. אני ממליץ לכם לא לשנות את הפוליסה הקיימת, הדפולטית, אלא ליצור פוליסה חדשה ולשים בה רק את ההגדרה הזאת.
04:24
אני שיניתי פוליסת בריאת מחדל וזה נחשב לא כל כך יפה. בואו נעשה גם ריסטארט ליתר ביטחון כדי שהסרוויס של LDAP יעבוד מחדש.
04:32
ואחרי הריסטארט ננסה את ההתקפה שלנו. לפני כן אני רק רוצה לבדוק מי הם שרתי ה-DNS של הקורבן שלי, שזה פייל סרבר. כרגע יש לו רק שני שרתי DNS ב-IPv4. אני מפעיל את ה-man in the middle v6 רק על השרת הזה כדי לא לדפוק את כל הרשת כי אני הולך להתחזות ל-DNS של הדומיין הזה וכל הבקשות ה-DNSיות יעברו אליי ואני לא ה-DNS האמיתי הזה, קצת אדפוק לו את העבודה.
04:59
עשיתי ריסטארט לפייל סרבר והנה אני רואה שהוא מבקש מ-DHCP לקבל כתובת. הנה הפייל סרבר עושה ריסטארט ומתקשר עם DHCP. הנה אני שולח לו ספוף ריפליי, ריפליי מזויף.
05:13
בואו נפעיל את ההתקפה של ntlm-relay-x אני רק בודק שב-IP-config/all השרת אחרי ה-restart קיבל את ה-DNS שלי זה חלק מאוד מאוד חשוב בהתקפה שאני אכנס כ-DNS שלו אם זה לא עובד לי אני עושה ריסטארט למחשב אם ה-Renew לא עובד בקיצור אני שרת DNS
05:30
ועכשיו הדפדפן עם ההרשאות של דומיין אדמין יחפש פרוקסי ואני אגלגל את החיפוש של הפרוקסי שלו את העימות של הפרוקסי שלו ל-LDAP אבל הפעם זה פיילד, אתם רואים? זה נכשל.