ב-389-ds-base, שרת המדריך שעליו נשענות מערכות רבות כדי לאמת משתמשים, נמצאה חולשה במעבר מחיבור פתוח לחיבור מוצפן. תוקף שיושב על נתיב התעבורה יכול להחדיר הודעה משלו בדיוק ברגע המעבר, ולגרום לכך שאפליקציה תקבל תשובה שאינה שייכת לבקשה שלה. התוצאה המעשית היא שניסיון התחברות שנכשל יכול להיראות לאפליקציה כאילו הצליח. הציון שניתן לחולשה הוא 9 מתוך 10.

מה החולשה?

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

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

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

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

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

מי מושפע?

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

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

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

האם מנוצלת בפועל?

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

מה עושים?

עקבו אחרי דף החולשה של Red Hat ואחרי הדיווח במערכת המעקב שלה, והתקינו את חבילת 389-ds-base המעודכנת כשהיא יוצאת להפצה שאתם מריצים. מפני שהרשומה אינה נוקבת בגרסה מתוקנת, הדף של הספק הוא המקום שבו מספר הגרסה יופיע.

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

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

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