CVE-2025-55680 PoC: הפיכת מצב תחרות בקבצי ענן של Windows להרחבת הרשאות בעולם האמיתי

כאשר מיקרוסופט מוציאה תיקון נוסף לבעיית העלאת הרשאות מקומית, קל להתייחס אליו כאל "עוד CVE אחד ביום שלישי של התיקונים". CVE-2025-55680 ראוי ליותר תשומת לב מכך. זהו תנאי מירוץ זמן הבדיקה זמן השימוש (TOCTOU) ב מנהל התקן מסנן מיני של Windows Cloud Files (cldflt.sys) המאפשר למשתמש מקומי בעל הרשאות נמוכות ליצור קבצים שרירותיים במיקומים רגישים ולנצל זאת כדי להגיע ל-SYSTEM.NVD)

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

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

הבנת CVE-2025-55680 בהקשר

על פי NVD והרשמי CVE.org לפי הרישום, CVE-2025-55680 הוא תנאי מירוץ TOCTOU במנהל ההתקן Windows Cloud Files Mini Filter Driver, המאפשר לתוקף מקומי מאומת להגדיל את הרשאותיו. הוא נושא ציון בסיס CVSS v3.1 בטווח הגבוה (בין 7.0 ל-7.8, בהתאם לרשות המדרגת), עם וקטור טיפוסי:

AV:L / AC:(L או H) / PR:L / UI:N / S:U / C:H / I:H / A:H (NVD)

ספק אבטחת ענן Wiz מדגיש כמה עובדות מטא חשובות: (wiz.io)

• הדבר משפיע על מספר גרסאות Windows נתמכות, הן לקוח והן שרת.
• הוא מסווג כ CWE-367 (תנאי מירוץ TOCTOU).
• הוא כבר קשור לקוד ניצול ציבורי ונחשב ל"בעל ערך גבוה" מכיוון שהוא מספק SYSTEM על גבי מערך תכונות נפוץ מאוד (OneDrive / Files On-Demand).

מספר התראות (Wiz, Tenable, H-ISAC) מציינות כי CVE-2025-55680 הוא עוד ערך בסדרת פגיעויות Cloud Files Mini Filter שנשלחו מאז 2022.wiz.io) עבור צוותים המנהלים צי מחשבים גדול המבוסס על Windows או חוות VDI, יש להתייחס לסדרת בעיות זו כאל קטגוריית סיכון קבועה, ולא כאל באג חד-פעמי.

מה באמת עושה מסנן הקבצים הקטן בענן?

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

ברמה גבוהה:

• ספק סנכרון רושם סנכרון שורש באמצעות CfRegisterSyncRoot ב cldapi.dll.
• תחת שורש זה, הקבצים יכולים להיות: מלאים, מוצמדים או מחליפים, אשר מתמלאים רק בעת השימוש.
• ממשקי API במצב משתמש כגון CfCreatePlaceholders להניע את יצירת הערכים הזמניים הללו.
• בגרעין, cldflt.sys יירט I/O ומנהל פעולות אלה, כולל יצירת קבצים וספריות באמצעות FltCreateFileEx2.

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

הגורם הבסיסי: מרוץ TOCTOU קלאסי בערימת סנכרון מודרנית

Exodus Intelligence פרסמה ניתוח טכני מפורט של CVE-2025-55680, ובו הסבירה כיצד מתרחשת התקלה בתוך ה- HsmpOpCreatePlaceholders() פונקציה ב cldflt.sys.(אינטליגנציית אקסודוס)

במילים פשוטות:

1. קוד במצב משתמש קורא CfCreatePlaceholders() ליצור קובץ אחד או יותר של מחליפים תחת שורש סנכרון.
2. במנהל המסנן, HsmpOpCreatePlaceholders() מקבל בקרת קלט/פלט (IOCTL 0x903BC) עם מאגר הכולל שדה שם קובץ יחסי (relName).
3. הנהג:
   • חיישנים ו ממפה את מאגר המשתמש למרחב הקרנל (באמצעות MDL ו- MmMapLockedPagesSpecifyCache).
   • חוזר על relName כדי להבטיח שזה יקרה לא מכילים תווים אסורים כמו \\ או : (הפחתה שהוכנסה לאחר CVE קודם).
4. אם האימות עובר, הנהג מתכונן OBJECT_ATTRIBUTES והתקשרות FltCreateFileEx2() ליצור את הקובץ, באמצעות שם הקובץ המאומת ומזהה ספריית השורש הנגזר משורש הסנכרון.

הבאג נמצא בשלבים 3–4: יש חלון זמן בין אימות מאגר המשתמש לבין השימוש בו ב- FltCreateFileEx2(), במהלכו התוקף יכול לשנות את אותו זיכרון ממופה ממצב המשתמש. מכיוון שהקרנל ותצוגות המשתמש חולקים את הדף הפיזי, כל שינוי במאגר המשתמש בא לידי ביטוי גם במצביע הקרנל.אינטליגנציית אקסודוס)

בפסיאודוקוד, הלוגיקה נראית בערך כך:

// קוד מדומה, מפושט לצורך ההדגמה NTSTATUS HsmpOpCreatePlaceholders(USER_BUFFER* userBuf) { // מיפוי מאגר המשתמש למרחב הקרנל KERNEL_VIEW* kview = MapUserBuffer(userBuf); WCHAR* relName = kview->relName; // 1. אמת שם קובץ: דחה תווים '\\' ו-':' if (contains_forbidden_chars(relName)) { return STATUS_INVALID_PARAMETER; } // 2. בנה OBJECT_ATTRIBUTES עם RootDirectory = sync root OBJECT_ATTRIBUTES oa = {0};
    oa.RootDirectory = SyncRootHandle; oa.ObjectName = relName; // עדיין מצביע על זיכרון המשתמש הממופה // 3. יצירת הקובץ return FltCreateFileEx2(..., &oa, IO_IGNORE_SHARE_ACCESS_CHECK, ...); }

ה TOCTOU ברור: מכיל_תווים_אסורים(relName) קורא את המחרוזת פעם אחת ומחליט שזה בטוח, אך אין כל ערובה לכך. relName נשאר אותו מחרוזת עד FltCreateFileEx2() רצות.

על ידי ניצול זהיר של חלון ההזדמנות הזה, תוקף יכול:

• עבור את האימות עם משהו שנראה כמו שם יחסי תמים תחת שורש הסנכרון, לדוגמה: JUSTASTRINGDnewfile.dll, ואז
• הפוך תו אחד במאגר הממופה כך שעד שהקובץ ייווצר הוא יהפוך ל- JUSTASTRING\\newfile.dll, שם JUSTASTRING הוא צומת או קישור סימבולי המפנה לספרייה מיוחסת כגון C:\\Windows\\System32.(אינטליגנציית אקסודוס)

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

מודל ניצול: מ-Low-Priv Shell ל-SYSTEM

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

1. הגדרת סביבה
   • רשום ספריית שורש סנכרון באמצעות CfRegisterSyncRoot.
   • צור ספרייה תחת השורש הזה (לדוגמה JUSTASTRING) ולהפוך אותו לצומת לתיקיית יעד בעלת ערך גבוה (לדוגמה, C:\\Windows\\System32).
2. תזמור המירוץ
   • השתמש במספר רב של תהליכים כדי:
     • הפק בקשות ליצירת מחליפים באופן רציף (CfCreatePlaceholders → IOCTL 0x903BC) עם שם יחסי "בטוח".
     • הפוך באופן רציף בייט אחד במאגר שמות הקבצים הממופה כדי להוסיף או להסיר \\ בדיוק ברגע הנכון.
     • עקוב אחר הקובץ היעד (לדוגמה, System32\\newfile.dll) הופיע.
3. העלאת הרשאות באמצעות חטיפת DLL
   • לאחר שה-DLL או הקובץ ההפעלה השרירותי הועבר לספרייה מיוחסת, השתמש ב-DLL ידוע או בוקטור חטיפת שירות כדי להפעיל את הקוד עם הרשאות SYSTEM.
4. ניקוי
   • הסר עקבות כגון קבצי צומת וקבצים זמניים כדי להפחית את כמות הממצאים הפורנזיים.

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

אף אחד מהדברים הללו אינו יוצא דופן עבור צוותי EDR או DFIR מודרניים, אך הם דורשים מתאם פעולות שנראות תמימות (תצורת סנכרון ענן, צמתים, תחלופת מחזיקי מקום) עם יצירת DLL "מוזר" אחד.

השקפה הגנתית: איתור, חיזוק ואסטרטגיית תיקון

הצעד הראשון והברור הוא עדיין היעיל ביותר: החל את עדכוני Patch Tuesday של מיקרוסופט מאוקטובר 2025 המתקנים את CVE-2025-55680.חדשות אבטחת סייבר)

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

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

מארח וטלמטריה EDR

מנקודת מבט של נקודת קצה, כדאי לכוון את הזיהוי והציד:

• התנהגות חריגה של קבצי ענן
  • רישומים נדירים או חד-פעמיים של שורש סנכרון בשרתים או בתחנות עבודה בעלות ערך גבוה.
  • נפח IOCTL 0x903BC בלתי צפוי במערכות שאינן משתמשות רבות ב-OneDrive.חדשות אבטחת סייבר)
• שימוש לרעה בצמתים ובקישורים סימליים
  • צמתים שנוצרו מנתיבים הניתנים לכתיבה על ידי המשתמש לספריות מיוחדות (System32, Program Files וכו').
• יצירת קבצים חשודים בספריות מיוחסות
  • DLLs או קבצים הפעלה חדשים ב-System32 או בספריות אחרות של מערכת ההפעלה עם שמות לא סטנדרטיים או שהורכבו לאחרונה.
  • הקשרים בין יצירות כאלה לבין פעילות בתדירות גבוהה ב cldflt.sys.

מיפוי זה ל MITRE ATT&CK, CVE-2025-55680 הוא אמצעי להשגת טכניקות כגון T1068 (ניצול לצורך העלאת רמת הרשאות) ואז לעבור לשירות או לחטיפת DLL לצורך התמדה.

הקלות אדריכליות ומדיניות

מעבר לתיקון וזיהוי, יש לקחת בחשבון את הדברים הבאים:

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

מדוע CVE-2025-55680 חשוב עבור בדיקות חדירות מבוססות בינה מלאכותית

CVE-2025-55680 ממחיש גם נקודת תורפה כללית יותר: עד שצוות האבטחה שומע על עליית רמת הרשאות חדשה ב-Cloud Files, PoC ציבוריים לרוב אינם זמינים, אינם שלמים או ערוכים בכוונה תחילה.. אך השאלה הקשה אינה "האם ה-CVE קיים", אלא:

"האם תוקף יכול להשתמש באופן משמעותי ב-CVE-2025-55680 בסביבתנו, בנקודות הקצה שלנו, עם ה-EDR וההגנה שלנו?"

התשובה לשאלה זו דורשת:

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

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

מיון PoC בלחיצה אחת עם Penligent

פלטפורמות כמו Penligent נועדו להפוך את סוג החשיבה הזה לאוטומטי. עבור CVE כמו CVE-2025-55680, זרימת עבודה טיפוסית המונעת על ידי בינה מלאכותית נראית כך:

1. קלט מידע מובנה
   • משוך את ה-NVD / CVE.org כניסה, הודעת MSRC וניתוחים טכניים (Exodus, Wiz, CyberPress).(NVD)
   • אילוצים של חילוץ: נדרשת אימות מקומי, Cloud Files מופעל, מניפולציה של נתיב מבוסס צומת, תחרות סביב HsmpOpCreatePlaceholders ו FltCreateFileEx2.
2. מפה לסביבה היעד בפועל
   • זהה מחשבי Windows שמריצים cldflt.sys עם Cloud Files / OneDrive מופעל.
   • בדוק אם קיימים שורשי סנכרון ומדיניות רלוונטית במחשבים אלה.
3. סינתזה של תרחיש PoC מבוקר
   • יצירת לוגיקת ניצול שלדית אשר רושמת שורש סינכרון בדיקה, מגדירה צומת תקינה ומנסה ליצור קובץ מבוסס מחזיק מקום. רק בתוך סביבת מעבדה מבודדת.
   • השתמשו רבות ברישום כדי שהמגנים יקבלו נראות מקסימלית במקום ניצול של קופסה שחורה.

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

# פסאודו-קוד: רתמת מירוץ (לצורך אימות במעבדה בלבד, לא ניצול מלא) def run_lab_race(target_path): shared = create_mapped_buffer(initial_name="SAFEPLACEHOLDER") stop_flag = False

    def creator_thread(): while not stop_flag: issue_placeholder_ioctl(shared) def flipper_thread(): while not stop_flag: flip_buffer_byte(shared) tiny_sleep()

    def monitor_thread(): while not stop_flag: if privileged_file_exists(target_path): log("[+] פוטנציאל מירוץ זכה, קובץ נוצר ב", target_path) stop_flag = True start_threads([creator_thread, flipper_thread, monitor_thread])

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

1. תעד ראיות והפק דוח
   • אם המירוץ יצליח, Penligent תוכל לאסוף באופן אוטומטי:
     • אובייקטים של מערכת הקבצים (איזה קובץ נוצר ואיפה).
     • אירועי Windows רלוונטיים ועקבות ETW.
     • תיאור המסביר את ההשפעה ואת התיקונים המומלצים.
   • אם הוא נכשל בתנאים מציאותיים, גם זה בעל ערך: זה אומר שהתיקונים והחיזוקים שלכם עושים את העבודה.

מ-CVE Feed להשפעה מאומתת

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

על ידי שילוב מקורות מובנים כמו NVD ו-MSRC עם מאמרים טכניים מעמיקים כמו מחקר Cloud Files של Exodus, ולאחר מכן מתן אפשרות למנוע מבוסס AI לתאם את הקוד והניסויים, תוכלו:

• אל תתייחסו ל-CVE-2025-55680 רק כאל ערך בטבלת אקסל, אלא כאל סיכון ספציפי ומבוסס שנבדק על מחשבים ספציפיים.
• בנה זיהויים ולוחות מחוונים סביב התנהגות ניצול שנצפתה, לא רק ספקולציות.
• השתמש באותו צינור בפעם הבאה ש-Cloud Files Mini Filter (או כל ערימה דומה הקרובה לקרנל) יופיע ב-Patch Tuesday.

המטרה של Penligent בתחום זה היא פשוטה: להפוך CVE כמו CVE-2025-55680 לתשובות קונקרטיות ומגובות בראיות ל"האם אנחנו באמת נמצאים בסיכון, ואם כן, היכן?" — מבלי לצפות מכל מהנדס לבצע הנדסה לאחור של מנהלי התקנים של הקרנל וליצור PoC מאפס.

• חדשות אבטחת סייבר
• חדשות אבטחת סייבר
• איגוד בתי החולים האמריקאי
• איגוד בתי החולים האמריקאי