שלבים ועדכונים בחולשה ZeroLogon

המאמר מתמקד בחולשה CVE-2020-1472 המוכרת גם כחולשה ZeroLogon ובהשפעותיו על סביבת Active Directory ודרכים להתמודדות עם שלבים מסוימים בתהליך העדכון.

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

העדכון לחולשה מקבל את הדירוג הגבוה ביותר של מספר גורמים, בין אם זה דירוג CVSS 3.0 ברמה 10 של Microsoft, או דירוג 5 של CERT-EU וכן הדירוג 4 של CISA.

תקציר החולשה

החולשה היא חולשה סופר קריטית בגלל שניתן לבצע פעולות שונות בתקיפה, כמו, לבצע כניסה ללא הזדהות מול שרתי DC's, או לנוע רוחבית בסביבת Active Directory, במקרים מסוימים ניתן לקחת DA וחמור מכך ניתן להשתמש בחולשה ולשלב אותה יחד עם מתקפות כופר מסוימות.

בספטמבר 2020 יצאו מספר כלים, PoCים וסקריפטים המאפשרים לבצע את כל אותן הפעולות מול חולשת ZeroLogon כאשר הדומיננטי הוא הכלי של Secura, ויתרה מכך, קבוצות תקיפה שונות בעולם מנצלים את הבעיה הקריטית ומבססים את הקמפיין שלהם עם ZeroLogon.

קבוצת התקיפה CHIMBORAZO החלה לפעול כבר באוקטובר 2020 ולנצל את החולשה יחד עם מתקפות כופר בכדי להאיץ את התשפטות הכופר באמצעות ZeroLogon ולקבל אחיזה טובה יותר בסביבת AD.

טיפ: לא כל הכלים הקיימים של ZeroLogon אמינים ברשת, ולכן מומלץ להריץ כלים נבחרים בלבד וחשוב מכך להריץ את הכלים בסביבות שאינן סביבות ייצור.

מכיוון שמדובר על חולשה קריטית ועל סיכון גבוה במיוחד יצאו אינספור הנחיות ומדריכים כיצד להתגונן, איך לזהות ואיך למנוע ZeroLogon, אבל חשוב להדגיש כי העדכון נחלק לשניים ומומלץ להיצמד למאמר KB הראשי שהתעדכן לאחרונה ומתמקד בדרכים לניהול שינויים מול Netlogon secure channel.

המאמר KB שיצא בסוף אוקטובר מביא איתו הנחיות חדשות לעדכון CVE-2020-1472 ומחלק את התהליך לארבעה שלבים כאשר השניים החשובים הם בתאריכים הבאים: העדכון הראשון באוגוסט 2020 וכן העדכון השני בפברואר 2021.

הפרוטוקול Netlogon רוכב על גבי RPC ולכן עושה שימוש בתת רכיב שנקרא MS-NRPC אשר מספק רכיב ליבה לטובת אימות מבוסס מכונה. האימות נעשה ע"י משאבים שונים ברשת, כמו,שרתים, תחנות ואובייקטים שונים אשר צריכים גישה והתחברות אל סביבת Active Directory.

הרכיב MS-NRPC מספק יכולות נוספות כמו רפליקציה של אובייקטים מסוג משתמשים לטובת מערכות הפעלה בין DC's, לתחזק קשרים בין אובייקטים ברמת Domain מול DC's ולזהות קשרים בין Domain ובין DC's. המטרה העיקרית של הרכיב היא לבצע תקשורת מאובטחת בין אובייקטים לבין DC's.

החולשה שנמצאה ע"י הצוות של Secura מאפשרת לבצע זיוף של הטוקן מול הפונקציונליות של Netlogon וע"י כך לבצע קריאה של קריאת פונקציות נוספות בדומיין שמאפשרות בין היתר לקרוא סיסמאות ברמת אובייקט מול DC, ומכאן התוקף יכול להשתמש בסיסמה ולבצע Take Over על Domain Controller ולקחת DA.

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

הדוח המפורט של החולשה ותיאור הבעיות זמין בקישור הבא Zerologon by Secura

הכלי הרשמי של Zerologon זמין בקישור הבא ZeroLogon testing script by Secura – לשים לב לדגשים בהרצת הסקריפט

בנוסף לכך ישנה בחולשה שימוש בשני אלמנטים נוספים של Netlogon שהם חלק מהבעיה, והם: הצפנה מסוג AES-CFB8 ובקשות NetrServer.

הצפנה מסוג AES-CFB8 הוא תת רכיב וחלק מתוך פרוטוקול Netlogon וכן חלק מתוך הרכיב של ComputeNetlogonCredential. ההצפנה AES-CFB8 יושמה בצורה לא מאובטחת ומכאן נגרמה החולשה עצמה.

AES-CFB8 הוא חלק בתהליך הצפנה של AES עצמו וכולל בתוכו 16 סיביות ובפועל מקבל בחזרה אורך בן 8 סיביות, הרכיב שמקבל את 8 הסיביות מצרף אותן אל 16 הסיביות הרנדומליות ומכאן נולד Initialization Vector שבהמשך נוכל להבין איך עושה שימוש בערכים שונים כולל Zero-Value.

הערה: במקור הצפנה מסוג AES מקבלת 16 סיביות ומקבלת בחזרה גם 16 סיביות באותו אורך

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

הבעיה עצמה טעונה באופן שבו מתבצעת ההצפנה של AES-CFB8 מול פרוטוקול Netlogon ובאופן שבו יש בקשות עם אותו ווקטור ואותם ערכים (Zero-Value IV), ובחלק מהתהליך של בדיקות ComputeNetlogonCredential נשלחים 256 ניסיונות ליצירת מפתח רנדומלי שמהלכו יותר Zero Byte.

במצב כזה הקריאה של NetrServerReqChallenge בפרוטוקול Netlogon עושה שימוש בקריאה נוספת של NetrServerAuthenticate3 שמקבל את הפרמטר של ClientCredential .

ClientCredential מעביר את הבקשה אל NetrServerReqChallenge והערכים יכולים להכיל כל ערך שהוא חלק מאותם 8 בייטים וכאן התוקף יכול לנצל כל חלק באותם 8 סיביות בכדי למצוא ערך Zero (ערך 0X8) ולבצע איטרציות של כל אותן בקשות עד שימצא בצורה מוצלחת ערך Zero.

במצב כזה התוקף משתמש בגישה של NetrServerPasswordSet2 בכדי לנצל Session Key (כל אותם ערכי Zero על CFB8), ומכיוון שמבנה הסיסמאות של Netlogon בנוי מ 516 בייטים התוקף ישתמש ב 4 בייטים אחרונים אשר מייצגים את אורך הסיסמה וע"י כל יכול לבצע שכתוב של הבייטים האחרונים לערכים Zero שבהם ניתן להשתמש בסיסמה ריקה ומכאן לבצע הזדהות ללא פרטים נוספים.

הממצאים בחולשה נחלקים למספר ממצאים שניתן לראות אותם בממשק Event Viewer ובנוסף ניתן לראות את הממצאים בניטור עם כלי ניתוח שונים והכלי הפשוט בינהם הוא Process Explorer.

הממצאים ברמת Event Viewer כוללים לוגים שמספרם הוא:

• לוג 5829 שמתריע על תעבורה לא תקינה עם הודעה vulnerable Netlogon secure channel

לוגים נוספים אשר קשורים אך ורק להודעות הקדומות

• לוג 4742 עם תיאור A computer account was changed
• לוג 4742 עם תיאור Special privileges assigned to new logon
• לוג 4673 עם תיאור Sensitive Privilege Use

טיפ: הלוגים האחרונים של 4742 יכולים להופיע בבעיות אבטחה אחרות ולא בהכרח לחולשה של ZeroLogon ולכן יש להתייחס אליהם בצורה ספציפית בכל אירוע 

העדכון והתהליך

כאמור, בעקבות החולשה יצא באוגוסט 2020 עדכון קריטי לשרתי Windows Serer המתפקדים כשרתי Domain Controller בסביבת Active Directory, והעדכונים נחלקים לשני עדכונים ספציפיים שאותם צריך לעדכן בדחיפות וזאת במטרה לבצע הגנה על המנגונים השונים של RPC ושל Netlogon:

• הגנה על מנגנון RPC לאובייקטים
• חוסם תעבורה זדונית של Netlogon
• מאפשר החרגה של אובייקטים

המיטיגציה דורשת לבצע מספר פעולות של עדכונים על כלל שרתי ADDS כולל שרתים בתפקיד RODC, לוודא ניטור לוגים ברמת Event Viewer ולנטר פעילות חשודה מול LSASS מול RPC ומול Netologn.

העדכון נחלק לתהליך בן ארבעה שלבים:

• עדכון שרתי DC עם עדכון אוגוסט 2020
• ניטור מול אובייקטים שמבצעים תקשורת זדונית מול שרתי DC
• להחריג אובייקטים מוכרים שמצבעים תקשורת לא מאובטחת באמצעות פוליסי
• לבצע את החלק השני בעדכון שיגרום למצב אכיפה מול שרתי DC

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

הערה: אין אפשרות לדסבל את מצב האכיפה

תאריכי העדכון

העדכון נחלק לשני שינויים מרכזים בהם העדכון חל, הראשון שבהם הוא העדכון הראשון של CVE-2020-1472 שסוגר את הבעיה עצמה ובנוסף לכך יוצר רישום חדשים ומוסיף התראות ולוגים חדשים. העדכון השני מבצע אכיפה של אחד מהערכים ברישום – אכיפה ברמת Enforcement.

העדכון בתאריך אוגוסט 2020 הינו עדכון שמבצע שינויים לפרוטוקול Netlogon, מוסיף ערכים לרישום (ערכים ברמת Regedit), מוסיף רשומות חדשות אל הלוגים ברמת Event Viewer ומבצע הגנה על כלל שרתי Active Directory מפני התקפות ZeroLogon.

העדכון של אוגוסט 2020 מכיל הגנה לפרוטוקול Netlogon ולכלל הפעולות שהוזכרו קודם לכן במאמר, בין היתר:

• מבצע אכיפה מאובטחת על מנגנון RPC
• מבצע הגנה על רכיב Trust
• אוכף RPC מאובטח מול אובייקטים צד שלישי
• מכיל פוליסי חדש לאובייקטים צד שלישי שנקרא  "Domain controller: Allow vulnerable Netlogon secure channel connections"
• ערך חדש ברישום שנקרא FullSecureChannelProtection
• סט חדש של Eventים עם הלוגים הבאים:
  • לוג 5827 במידה ותהעבורה נכשלה
  • לוג 5828 במידה והתעבורה נכשלה
  • לוג 5830-5831 במידה והתעבורה הצליחה ובהתאם לפוליסי Allow vulnerable Netlogon secure channel connections

העדכון של פברואר 2021 מביא איתו מספר שינויים נוספים כאשר המרכזי שבהם הוא מעבר למצב אכיפה של Netlogon מאובטח והשינויים הנוספים:

• אכיפה של Netlogon מאובטח עם הרישום של FullSecureChannelProtection במצב מופעל (1)
• הסרה של רשומת לוג 5829 וניטור לפי רשומות לוג אחרות
• מעבר למצב של תעבורת Netlogon מאבוטוחת וחסימה כל תעבורה זדונית

חשוב להדגיש כי רק אובייקטים מוחרגים לפי הגדרת פוליסי "Domain controller: Allow vulnerable Netlogon secure channel connections" יכולו לדבר עם שרתי ADDS.

דגשים בתהליך

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

הערה: אפשר להקל ראש ולהחריג אובייקטים צד שלישי שאין באפשרותינו לבצע בהם התאמה מול פרוטוקול Netlogon – אך לא מומלץ כלל

שלב ראשון – עדכון אוגוסט 2020

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

• בשלב ראשון מבצעים עדכון CVE-2020-1472 לשרתי Domain Controllers כולל RODC
• לאחר מכן אובייקטים מסוג Windows Devices יתחילו לדבר עם DC's על גבי Netlogon מאובטח
• לוגים חדשים שמספרים 5827 + 2828 יופיעו בממשק Event Viewer של System וידווחו על תעבורה שנדחתה
• לוגים חדשים שמספרם 5830 + 5831 יופיעו בממשק Event Viewer של System וידווחו על אובייקטים שעושים שימוש מול הפוליסי
• חוג חדש ונוסף הוא לוג 5829 שיופיעו בלוג System ויתריע על תעבורה זדונית של Netlogon

טיפ: במצב של לוג 5829 ההתרעה תדווח על ניסונות גישה וחסימה בגלל העדכון וכך זה נראה בממשק של Defender for Identity עם הזיהוי של CVE-2020-1472 ועם אלפי ניסיונות כושלים של Impersonation מול שרתי DC's.

שלב שני – ניטור תעבורה

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

תחילה הניטור ייעשה ע"י לוג 5829 שידווח על תעבורת Netlogon זדונית בין אם התעבורה מגיעה מתוקף או אובייקט צד שלישי אשר עובד בצורה לא תקינה מול Netlogon – בשני המצבים הגישה תהיה חסומה.

לצד הלוגים הנ"ל אנו צריכים לנטר את הלוגים 5827 + 5828 בכדי להבין האם יש לנו תעבורה שנחסמת ומבידה וכן להבין מי הם האובייקטים שנחסמים.

שלב שלישי – טיפול באובייקטים צד שלישי

בדיפולט אובייקטים של Wdinwos 10 ושל Windows Server תומכים תעבורת Netlogon מאובטחת ולכן אובייקטים מהסוג הנ"ל לא ייחסמו, אלא אם כן המכונות לא מעודכנות כלל ואינן תומכות במצב של Secure Netlogon.

במצב כזה יתכן כי אובייקטים צד שלישי אינם נתמכים במצב של Secur Netlogon ומכאן ישנם שתי אפשרויות:

• לבצע התאמה של האובייקט צד שלישי, ואוביקטט צד שלישי יכול להיות Device או אפליקציה ולכן יש לבצע התאמה מול הוונדור
• האפשרות הנוספת והפשוטה היא לבצע החרגה ע"י Group Policy – במצב כזה אנו מפספסים את המהות של ביצוע העדכונים והקשחה של AD

טיפ: במידה ואין תעבורה זדונית של Netlogon בסביבת AD ניתן להפעיל את הערך FullSecureChannelProtection עוד לפני פברואר 2021 

שלב רביעי – עדכון פברואר 2021

בשלב האחרון שיחל בפרואר 2021 מתבצע העדכון השני של CVE-20201472 ובעדכון הזה מתרחשים שתי פעולות חשובות:

• האפשרות של FullSecureChannelProtection נכנסת למצב של אכיפה
• הערך FullSecureChannelProtection אינו זמין יותר ולכן אינו מאפשר הפעלה (הוספה ידנית מחדש של הערך לא תשנה הגדרות בשרת)

לסיכום, החולשה הקריטית במנגנון Netlogon והעדכון CVE-2020-1472 שמגיע בעקבותיו צריכים להיות מטופלים בסביבת ADDS, ולהיעשות בצורה זהירה בכדי למנוע בעיות בתקשורת מול Netlogon.

המאמר הבא יתמקד בכלים ובפעולות לניטור, זיהוי ומניעה של ZeroLogon ושל תעבורת Netlogon זדונית

מאמרים נוספים של אבטחת מידע