כיצד לפרוץ שרת Exchange ללא תיקון עם קוד PowerShell נוכל

לפני קצת פחות מחודשיים התפרסמו כמה חדשות באגים מדאיגות: זוג נקודות תורפה של יום אפס הוכרזו ב-Microsoft Exchange.

כפי שאנו יעץ בזמנו, פגיעויות אלה, שסומנו רשמית CVE-2022-41040 ו CVE-2022-41082:

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

הפגיעות הראשונה הזכירה את הבעייתיות והנוצלה לרעה חור אבטחה של ProxyShell מאז אוגוסט 2021, מכיוון שהוא הסתמך על התנהגות מסוכנת בתכונת הגילוי האוטומטי של Exchange, מתואר על ידי מיקרוסופט כפרוטוקול כלומר "בשימוש על ידי לקוחות Outlook ו-EAS [Exchange ActiveSync] כדי למצוא ולהתחבר לתיבות דואר ב-Exchange".

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

למרבה הצער, תיקוני ProxyShell לא עשו מספיק כדי לסגור את הניצול בפני משתמשים מאומתים, מה שהוביל ל-CVE-2022-40140 zero-day החדש, שהיה עד מהרה באופן לקוני, אם כי מטעה, דיבוב ProxyNotShell.

לא מסוכן, אבל מסוכן בכל זאת

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

אבל מהר מאוד התברר שבשרתי Exchange רבים, ידיעת שם הכניסה והסיסמה של כל משתמש יספיקו כדי לעבור כמאומתים ולהפעיל את ההתקפה הזו, גם אם אותו משתמש בעצמו יצטרך להשתמש באימות דו-שלבי (2FA) כדי להיכנס כראוי כדי לגשת האימייל שלהם.

בתור מומחה סופוס צ'סטר ויסנייבסקי שים את זה בזמן:

זו "פגיעות באמצע אימות", אם אתה רוצה לקרוא לזה כך. זו ברכה מעורבת. זה כן אומר שסקריפט אוטומטי של Python לא יכול פשוט לסרוק את כל האינטרנט ולנצל כל שרת Exchange בעולם תוך דקות או שעות, כפי שראינו קורה עם ProxyLogon ו- ProxyShell בשנת 2021. […]

אתה צריך סיסמה, אבל למצוא כתובת דוא"ל אחת ושילוב סיסמה תקפים בכל שרת Exchange נתון זה כנראה לא קשה מדי, למרבה הצער. וייתכן שלא ניצלו אותך עד היום, כי כדי להיכנס בהצלחה ל-Outlook Web Access [OWA] נדרש אסימון FIDO שלהם, או המאמת שלהם, או כל גורם שני שאתה עשוי להשתמש בו.

אבל ההתקפה הזו לא דורשת את הגורם השני הזה. […] רק רכישת שילוב של שם משתמש וסיסמה היא מחסום די נמוך.

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

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

אפילו ה-Patch Tuesday של נובמבר לא סיפק ישירות את התיקונים הדרושים, למרות שהתיקונים בכל זאת יצא באותו יום כחלק מעדכון אבטחה ספציפי ל-Exchange שניתן היה לאחזר ולהתקין בנפרד:

נחשפה הוכחת מושג

עכשיו, כשהאבק שקע וכולם הספיקו לתקן את שרתי ה-Exchange שלהם (אלה שהם לא שכחו מהם, לפחות), חוקרים ביוזמת Zero Day (ZDI), שהחולשות הללו נחשפו במקור באחריות להגשה ל מיקרוסופט, הסבירו כיצד ניתן לנצל את הבאגים.

החדשות הרעות, בהתאם לדעה שלך על גילויי ניצול גלוי, הן שצוות ZDI סיפק כעת למעשה הוכחת מושג (PoC) המסביר כיצד לתקוף שרתי Exchange.

החדשות הטובות, כמובן, הן ש:

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

איך זה עובד

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

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

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

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

...כדי שתדעו מראש למה הסיפור לוקח את הכיוונים שהוא עושה:

• שלב 4. להערים מרחוק על Exchange ליצור אובייקט NET לפי בחירתך, עם פרמטר אתחול לבחירתך.

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

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

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

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

במילים פשוטות, אם אתה מייצר, נניח, א TextString אובייקט (אנחנו ממציאים את השמות האלה, אבל אתה מבין את הרעיון) באמצעות פרמטר שהוא עצמו מחרוזת טקסט כגון example.com:8888...

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

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

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

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

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

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

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

בתיאוריה, רק אובייקטים בטוחים או בסיכון נמוך יכולים להיווצר מרחוק באמצעות PowerShell, כך שיצירת מופע דמיוני שלנו TextString למעלה, או א SimpleIntegerValue, עשוי להיחשב מקובל, בעוד א ConnectedTCPClient או RunCmdAndReadOutput בהחלט לא יהיה.

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

• שלב 3. להטעות מרחוק את Exchange לחשוב שאובייקט בסיכון נמוך שעבר את מבחן הבטיחות הוא, למעשה, אובייקט אחר לבחירתך.

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

אבל החוקרים גילו שהם יכולים:

• שלב 2. להערים מרחוק על Exchange להשתמש בו מרחוק PowerShell תכונה ליצירת אובייקט המבוסס על פרמטרי אתחול הנשלטים מבחוץ.

וזה היה אפשרי בגלל החור דמוי ProxyShell שהיה רק ​​תיקון למחצה:

• שלב 1. להערים מרחוק על Exchange לקבל ולעבד בקשת אינטרנט עם קוד על ידי אריזה חוקית username:password גם בשדה הבקשה.

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

באופן רופף, כל תקף username:password השילוב יתאים, בהתחשב בכך שה"אימות" היה נחוץ פשוט כדי למנוע מ-Exchange לדחות את בקשת ה-HTTP מראש.

מה לעשות?

שימו לב שהתקפה זו פועלת רק:

• אם יש לך שרתי Exchange מקומיים. מיקרוסופט טוענת כי סגרה את שירותי הענן שלה במהירות, כך ש-Exchange Online לא מושפע. תהיה בטוח ש לדעת היכן נמצאים שרתי ה-Exchange שלך. גם אם אתה משתמש כעת ב-Exchange Online, ייתכן שעדיין פועלים שרתים מקומיים, אולי נשארו בטעות מתהליך ההגירה שלך.
• אם השרתים שלך לא מתוקנים. ודא שיש לך החיל את עדכון תוכנת Exchange של 2022-11-08 ל לסגור את הפגיעות שהניצול דורש.
• אם השרתים שלך עדיין מקבלים אימות בסיסי, המכונה גם אימות מדור קודם. ודא שיש לך חסם את כל ההיבטים של אימות מדור קודם כך שהשרתים שלך לא יקבלו את username:password כותרות שהוזכרו לעיל, ולא יקבלו מלכתחילה בקשות פרוטוקול Autodiscover מסוכנות. זֶה עוצר תוקפים להערים על שרת לקבל את הטריקים שלו ליצירת אובייקטים לכודים, גם אם השרת הזה לא תוקן.

אתה יכול המשיכו לעקוב מהייעוץ הרשמי שלנו למניעה, תיקון ותגובה, ולקוחות Sophos יכולים לעקוב אחר שמות זיהוי האיומים המשמשים את המוצרים שלנו, באמצעות עדכון הטוויטר של Sophos X-Ops (@SophosXOps).

מידע חדש פורסם לגבי CVE-2022-41040 ו-CVE-2022-41082: https://t.co/pHUVBjUeDI 1/3

— Sophos X-Ops (@SophosXOps) 21 בנובמבר 2022

---

למידע נוסף על אימות EXCHANGE ועל OAUTH2

עם פול דאקלין וצ'סטר ויסנייבסקי
מוזיקת ​​אינטרו ואאוטרו מאת אדית מדג'.

---