אפוקליפסת LDAP, אמצע 2020. מוכנים?

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

אז באמצע ריצה של חדשנות פסיכית מול הענן עם Azure וקצת עם AWS, ועם למידה בלתי פוסקת של IoT וכמובן הרבה Cloud Security מסביב אני מוצא את עצמי מתחקר עדכונים והשפעה על אחת המערכות הכי קריטית וישנה שאפשר > Active Directory.

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

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

עדכון נוסף (10.2) >>> מכיוון שישנם מספר שינויים העדכון יחולק לשניים: במרץ יבוצע עדכון חלקי שיכלול רק רישום לאירועי לוג, ולקראת החצי השני של 2020 ייצא החלק השני והעיקרי של העדכון שמבצע שינוי של LDAP Signing.

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

אז כמה שאלות לפני שנמשיך ונפרט בהמשך המאמר:

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

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

LDAP בקצרה

Lightweight Directory Access Protocol (בקצרה LDAP) הוא פרוטוקול תקשורת בשכבת היישום, המאפשר גישה וניהול אוביקטים מול תשתית Active Directory, ולכן פרוטוקול LDAP כלול בסטנדרט X.500 אך צורך פחות משאבים ולכן נקרא גם X.500-Lite.

המודל של LDAP מבוסס על שרת/לקוח, כאשר הלקוח פונה אל השרת (Active Directory) בחיבור LDAP על ידי התחברות לשרת עם פורט 389, ולאחר מכן הלקוח יכול לשלוח בקשות פעולה לשרת, למשל, הפעלת חיבור מאובטח, ביצוע אימות משתמש, חיפוש, השוואה, הוספה, שינוי, או מחיקה > אובייקטים או ערכים.

הגרסה העדכנית של LDAP בתשתית Active Directory היא גרסה LDAP v3.

הזדהות מול LDAP

הזדהות דיפולטית ובסיסית מול LDAP בגרסת LDAP v3 יכולה להיעשות על גבי צורות האוטנטיקציה הבאות:

• Simple Bind – מאפשרת אוטנטיקציה עפ”י שלושה מנגנונים:
  • Anonymous – קבלת סטטוס לגבי LDAP ואינו מומלץ להזדהות משתמש
  • Unauthenticated – למטרות ניתוח לוג ואינו מומלץ להזדהות משתמש
  • Name/Password – מאפשר גישה לשרת לאחר שמשתמש או אפליקציה ביצע הזדהות לפי שם משתמש וסיסמה
• Simple Authentication and Security Layer או בקצרה SASL מספק מנגנון מעט מאובטח יותר מאשר Simple Bind, וצורת האוטנטיקציה מזכירה ממש במעט הזדהות Kerberos. במהלך הזדהות של לקוח מתבצעים מספר Challenge / Response מול השרת שבסיומו האוטנטיקציה מצליחה או שלא. חשוב להדגיש כי כל התעבורה של SASL מתבצעת על גבי Clear Text בדיפולט, בקיצור כל מי שמסניף תעבורת LDAP יכול לקרוא סיסמאות.

קצת מהשטח: ארגונים רבים עובדים עם LDAP במצב של Simple Bind או SASL מול אפליצקיות רבות אשר מוגדרות עם חשבון בעל הרשאות ולעיתים האדמין הכי חזק ברשת, ולכן חשופות לבעית אבטחה קשה.

הצילום הבא מתוך Group Policy הינו המחשה של מצב ממוצע ברוב הארגונים

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

השינוי, מרץ 2020

בעדכוני אבטחה של Microsoft במרץ 2020 הקרוב ייצא עדכון שמטרתו להקשיח את פרוטוקול LDAP, ולכן כל תעבורת LDAP שאינה חתומה תיכשל מול Active Directory, העדכון יעביר את הגדרת LDAP signing למצב של Require Signing.

וזה אומר שאם לא תהיה הכנה נכונה של פרוטוקול LDAP עם אותה הגדרת Require Signing כל התעבורה בין לקוח לשרת, או ליתר דיוק אפליקציה או תחנה מול Active Directory תיכשל.

עדכון האבטחה של מרץ 2020 הוא עדכון ברמת תחנה וברמת שרת ולגן גם תחנה וגם שרת חייבים להיות עם העדכון ולהיות במצב Require Signing, כלומר אם אחד הצדדים יהיה במצב שונה התעבורה לא תעבור גם כ, ולכן המצב שתחנה והבשרת חייב להיות זהה.

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

מהו LDAP Signing – רכיב (אפילו תת-רכיב) שמבצע אוטניטקציה על גבי LDAP עם Simple Authentication and Security Layer במטרה לבצע גישה מול Active Directory.

SASL מספק מספר מנגנונים בכדי להקשיח את האבטחה סביב תקשורת LDAP, בין היתר אימות משתמש, ביצוע anti-tampering כולל message signing והצפנה על גבי הפרוטוקול, ולכן מבצע את התקשורת על גבי פורט 389 וכן 3268.

השינוי במרץ 2020 – השינוי שיגיע אל LDAP הוא שינוי ברמת הפרוטוקול ומול תתי הרכיבים הבאים:

• LDAP Signing
• LDAP channal binding

השינוי חל מול מערכות Windows לתחנות קצה ושרתים בהתאם להמלצת אבטחה ADV190023, ולכן העדכון יאכוף Channel Binding על כל Domain Controller שמוגדר עם ערך בסיסי או כל ערך שאינו מבוטל במצב Off.

בקיצור ML;SS סביבה שלא תוגדר במבצ מבוטל לגמרי או עם הכנה לקראת Require Signing תקבל את העדכון בצורה ברוטלית כחלק מעדכוני אבטחה של מרץ 2020.

SASL מול TLS/SSL – מומלץ מאוד להפריד בין SASL לבין TLS/SSL כי אלה שני דברים נפרדים, הראשון עובד על גבי פורט 389 ופורט 3268 ומבצע אימות על סמך Challenge Reuqeust, ולעומת זאת TLS/SSL מבוסס על גבי PKI ועובד על גבי פורט 636 ופורט 3269.

יישום TLS בסביבת Active Directory מתבסס על תעודות דיגיטליות, כאשר כל הסביבה מקבלת תעודות מותאמות, ותחילה Domain Controllers ולאחר מכן שרתים נוספים, אפליקציות ותחנות.

שכבות של LDAP Signing – ישנם שלושה דרכים בהן SASL יכול לבצע התחברות מול Active Directory:

• מצב None או מצב 0 – בקשת LDAP Bind מופקת לפי הדורש.
• מצב Negotiate signing או מצב 1 – אם הופעל TLS, אז בקשת LDAP BIND מופעלת עם אפשרות של חתימת נתוני LDAP אשר מוגדרת בנוסף לדרישה. במידה והופעל TLS, אז בקשת LDAP BIND עובד על גבי אותה דרישה.
• מצב Require signing או מצב 2 – דומה למצב Negotiate signing, אך אם התגובה של  saslBindInProgress אינה מציינת כי נדרשת חתימה על LDAP, אז מתקבלת הודעה לדורש שבקשת LDAP BIND נכשלה.

השינוי בעדכון מרץ 2020 – העדכון אבטחה שיגיע במידה ויותקן יבצע שינוי בכל שרת ותחנה בערך LdalServerIntegrity ממצב של 1 למצב 2, שוב יחייב Require Signing, ולכן כל תחנה עם Windows 7 או Windows Server 2008 ומעלה יחויב בעדכון LDAP.

דגשים בהכנות

ישנם שתי אפשרויות להכנת השינוי בסביבת Active DIrectory כולל תחנות ושרתים:

• לדסבל את האפשרות של LDAP Signing
• להכין את הסביבה לקראת עדכון מרץ 2020

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

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

דגשים ונקודות חשובות בהכנת התשתית

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

בדיקת הגדרות LDAP קיימות

טרם מתחילים בבדיקות תעבורה, הגדרות ושאר הפתעות שישנם בסביבת Active Directory מומלץ לבצע בדיקה של הגדרות קיימות:

הגדרת Domain controller: LDAP server signing requirements – בדיקת הגדרות LDAP קיימות מול אובייקטים שונים מול רכיב Group POlicy מול הנתיב וההגדרה הבאה

הערכים הדיפולטים שונים בין אובייקטים של Group Policy, וישנו הבדל בין Default Domain Policy לבין Defaul Domain COntroller Policy ואולי גם אובייקטים אחרים שנוצרו במהלך הזמן.

המלצות וערכים דיפולטים במאמר Domain controller: LDAP server signing requirements

בדיקת לוגים קיימים

ישנם מספר אירועי לוג שאנו נדרשים לדגום ולבצע מעקב, בין היתר הלוגים הבאים:

לוג 2886 – כותב אירוע שאין צורך בהגדרת LDAP signing Require.
קישור למאמר Event ID 2886 — LDAP signing

 לוג 2887 – כותב אירוע עם מספר הפעמים בהם בוצע LDAP Bind.
קישור למאמר Event ID 2887 — LDAP signing

לוג 2888 – אם מוגדר לדחות בקשות Unssigned של LDAP כולל SASL או Simple Bind על גבי TLS  והשרת כותב אירוע סיכום פעם אחת בכל 24 שעות כאשר מתרחשים בקשות מהסוג הנ”ל.

לוג 2889 – כותב אירועים עם פרטים של בקשות LDAP, אך מצריך הגדרת ספציפית ברישום של הערך 16 LDAP Interface Events.

הפעלת LDAP Interface Events

בכדי לדעת מה קורה בתחנות, אפליקציות, שרתים וכל מי שניגש באמצעות פרוטוקול LDAP יש להפעיל לוגים ברמה גבוהה יותר עם הערכים הבאים:

16 LDAP Interface Events – בכדי לקבל פרטים לגבי בקשות LDAP ולדעת מי עובד עם פרוטוקול Unsecure מצריך הגדרת ספציפית ברישום של הערך 16 LDAP Interface Events לפי ההגדרות הבאות והרצת הפקודה הבאה:

Reg Add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v “16 LDAP Interface Events” /t REG_DWORD /d 2 

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics
16 LDAP Interface Events
Value 2

בדיקת תעבורה LDAP מול סביבת Active Directory ע”י כלים או סקריפטים

ישנם דרכים רבות לבצע בדיקה לתעבורת LDAP עם כלים מובנים, כלים צד שלישי והמון סקריפטים:

• בדיקת Insecure LDAP Binds עם הסקריפט הבא Query-InsecureLDAPBinds.ps1
• מעקב אחר Insecure LDAP Binds לפי הסקריפטים במאמר הבא Track Insecure LDAP

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

בנוסף לסקריפטים ניתן לבדוק תעבורת פרוטוקול LDAP באמצעות שני כלים חזקים >>> MCAS + Azure ATP לפי הדוחות והתנועות הבאות:

תשתית MCAS – באמצעות MCAS ניתן לבצע בדיקות מעמיקות תוך דקות בודדות, בממשק MCAS נבחר באפשרויות הבאות:

Investigate > Idenitity Secure Posture > Stop clear text credentials exposure

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

תשתית Azure ATP – בנוסף לכך ניתן להוציא דוח פסיכי ברמת הבורג עם Azure ATP מתוך ממשק הדוחות ובחירת דוח Password Exposed in Cleartext.

הדוח שיורד גישה של כל בקשה מול איזה DOmain Controller היא ביצעה פעילות, מהי רמת הבקשה והאם היא Insecure LDAP.

תשתית Javelin – במידה וישנו גם Javelin (או בשמו החדש TDAD) אז גם שם ישנה אפשרות לראות בממשק Dark Corner את האובייקטים שמבצעים Insecure LDAP.

בדיקת מצב LDAP Signing מול כלל הפוליסים של Group Policy

בכל אובייקט של Group pOlicy מומלץ לבדוק את מצב הערכים הבאים, כאשר הראשון הוא בדיקת ערך LdapEnforceChannelBinding שהוא מגיע מעדכון מרץ LDAP server signing requirements.

הערך השני פחות חשוב אך עדיין מומלץ לבדוק במצבים של שרתי Windows Server 2008

Get-GPRegistryValue -Name “Default Domain Policy” -Key “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LdapEnforceChannelBinding”

Get-GPRegistryValue -Name “Default Domain Policy” -Key “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\ldapserverintegrity” -ValueName “1”

בדיקת עדכון CVE-2017-8563

עדכון CVE-2017-8563 הוא עדכון אבטחה שנועד לסגור בעית אבטחה שנועד בפרוטוקול LDAP בתחנות ושרתים, העדכון אינו חדש ויצא בשנת 2017

קישור להורדה ופרטים נוספים אודות עדכון CVE-2017-8563

• חשוב להדגיש עדכון CVE-2017-8563 חייב להיות מותקן בתחנות קצה טרם ביצוע שינויים בשרתי DC’s
• שרתים מבוססים Windows Server 2008 חייבים בעדכון CVE-2017-8563 לצד עדכונים נוספים הקשורים אליו
• שרתי DC’s חייבים גם הם בעדכון CVE-2017-8563 כולל עדכוני תלות

המלצות

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

אני ממליץ לדסבל את כל מה שקשור לשינויים בפרוטוקול LDAP בגלל הסיבות הבאות:

• ישנן בעיות אבטחה נוספות סביב פרוטוקול LDAP והשינוי של LDAP Require Signing לא יפתור את כל בעיות האבטחה של LDAP
• דיסבול של LDAP Require Signing לא יגרום לבעית אבטחה כי אנו נמצאים עם הבעיה הזאת כבר שני עשורים
• ישנם כלים צד שלישי שיודעים להגן על Active Directory ועל תנועות LDAP לא מאובטחות
• הדיסבול לא אומר שצריך לוותר על הקשחת Active Directory וצריך להמשיך בהקשחה מול פרוטוקולים ובעיות אבטחה אחרות
• העברה של LDAP למצב LDAP Require Signing הינה פרויקט לכל דבר ופרויקט ארוך ולכן צריך לבצע בהדרגה
• מדובר על Bind של LDAP Signing ולא LDAP TLS

רק העברת LDAP Signing למצב Off ומבוטל לחלוטין תמנע בעיות מול פרוטוקול LDAP ותמנע מעדכון מרץ לשנות את הערך למצב אחר

בכדי לדסבל את הערך של Bind מול פרוטוקול LDAO יש לבצע את הפעולות הבאות:

• הגדרת ערך LDAPServerIntegrity עם נתון 0 בשרתי Windows Server 2008
• הגדרת ערך LdapEnforceChannelBinding עם נתון בשרתי Windows Server 2016/2019

הערה: יש לבצע מול כלל התחנות והשרתים ורק ע”י Regedit כי הממשק אינו מאפשר מבצע ביטול לגמרי.

הערה חשובה: הבדיקת נעשו לאחר בדיקה מול המאמרים הבאים ומול קבוצת המוצר

• LDAP Channel Binding and LDAP Signing Requirements – March update NEW behaviour
• ADV190023 | Microsoft Guidance for Enabling LDAP Channel Binding and LDAP Signing

בנוסף נעשו מספר בדיקות מול קבוצת המוצר לגבי השינוי הנ”ל והמידע במאמרים המצורפים של Microsoft הוא המידע המעודכן נכון לימים אלה.

מומלץ לבצע בדיקות על הסביבה טרם ביצוע שינויים בסביבת ייצור ולמנוע את עדכון מרץ, שינוי לא נכון בסביבת הייצור עלול לגרום להשבתה של מערכות