Rogue Sandbox - כשהסריקה עצמה היא ה-Payload | Daniel Oz

TL;DR

Rogue Sandbox אינו sandbox escape; זהו דפוס ניצול מודל אמון בתוך גבולות הדפדפן הלגיטימיים.
המעבר הקריטי קורה כשמשתמשים מעניקים הרשאת readwrite ברמת תיקייה דרך File System Access API.
במודל הזה, עיצוב נרטיבי יכול לגרום לפעולות עם יכולת כתיבה להיראות כסריקה או ניקוי תמימים.
ייתכן שאין רגע הורדה קלאסי, ועדיין יכול להתרחש שינוי משמעותי בקבצים מקומיים.
Chromium יכול לנתב חלק מאירועי הכתיבה ללוגיקת Safe Browsing או Download Protection, בהתאם לקובץ ולהקשר המדיניות.
האתגר ההגנתי הוא לא רק מניעת exploits, אלא ממשל של הרשאות קבצים מקומיות שניתנות על ידי הדפדפן.

תקציר

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

ממשקי Web APIs מודרניים מתחילים לטשטש את הגבול הזה. ה-File System Access API מאפשר, לאחר אישור המשתמש, פעולות קריאה וכתיבה על קבצים ותיקיות מקומיים. עבור מפתחי Web, זו יכולת לגיטימית שמאפשרת אפליקציות מתקדמות בדפדפן. עבור תוקף, זו לא חולשה חדשה. זו נקודת מפנה חדשה באמון.

הטריגר למחקר הזה היה מאמר של Check Point Research שהדגים נתיב תקיפה שנבנה כולו על File System Access API, ללא exploit וללא payload מקומי. קריאת המאמר העלתה שאלה רחבה יותר: מה קורה כשמפסיקים למסגר את זה רק כ-ransomware מבוסס דפדפן, ובמקום זאת מנתחים את אותו פרימיטיב תחת מודל איומים רחב יותר?

במאמר זה, אני מציג את Rogue Sandbox, את תהליך המחקר שהוביל אליו, כולל ניסיונות כושלים, אילוצי Chromium, והקשר ל-Mark of the Web (MOTW). לאחר מכן אני מתמקד בתובנה מרכזית מהעבודה: בתרחיש הזה, אין בהכרח “רגע הורדה”. מנקודת המבט של המשתמש, זו פעולת סריקה. מנקודת המבט של הדפדפן, זו הרשאת כתיבה. הפער בין שני המודלים האלה הוא נקודת המוצא של מחקר זה.

סקירת Rogue Sandbox: מה המשתמש מאמין מול מה שהדפדפן באמת מרשה — איור 1 - כל המאמר בתמונה אחת

היקף המחקר

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

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

קרדיט ל-Check Point Research

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

ביולי 2026, Check Point Research פרסמו את Browser-Only Ransomware: From LLM Hallucinations to a Practical Attack Technique, שהראו כיצד רעיון שמקורו בפלט של LLM יכול להתפתח לטכניקת תקיפה מעשית שנבנית על File System Access API. העבודה שלהם הדגימה ששילוב של הנדסה חברתית, הרשאות שניתנו על ידי המשתמש, ויכולות דפדפן מקוריות יכול לגרום לשינוי קבצים מקומיים ללא exploit, ללא payload מקומי, וללא עקיפת מנגנוני אבטחה של מערכת ההפעלה.

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

מאמר Check Point היה הטריגר למחקר המוצג כאן. כל מה שבא אחריו, מה-PoC הראשוני דרך ניתוח קוד המקור של Chromium ועד למודל Rogue Sandbox, הונע מהניסיון לענות על השאלה הזו.

רקע ומוטיבציה

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

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

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

זו בדיוק הנקודה המפתח.

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

המעבר הזה מהדהד מחקר קודם שהתמקד בניצול מנגנוני אמון במקום ניצול חולשות תוכנה. במאמר ה-iOS הקודם שלי, ניתחתי Configuration Profiles, מנגנון לגיטימי שמאפשר למשתמשים להרחיב את מעגל האמון של המכשיר. העיקרון המרכזי דומה כאן: לא לפרוץ את ה-sandbox, אלא לגרום למשתמש לתת לו הרשאה.

מפעולת משתמש לתוצאת הרשאה ברמת המערכת — איור 2 - מהמשתמש אל המערכת

הרעיון

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

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

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

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

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

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

זה הוביל לשאלת המחקר המרכזית במאמר הזה: האם ניתן לנצל את מודל האמון של File System Access API כדי לשנות קבצים קיימים ולהזריק תוכן payload מבלי שהמשתמש יחווה את האירוע כהדבקה?

השאלה

השאלה הראשונה הייתה פשוטה: האם זה רלוונטי ל-Chrome Desktop?

התשובה הייתה כן. ה-File System Access API נתמך במספר סביבות מבוססות Chromium ומאפשר לפתוח picker, לקבל handle לתיקייה, ולפעול על קבצים בתוך אותה תיקייה בהתאם להרשאות שניתנו.

לאחר שזה נענה, השאלה החשובה יותר התחלפה.

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

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

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

למה Rogue Sandbox?

דיוק חשוב כאן - Rogue Sandbox אינו שם נוסף ל-sandbox escape.

זה לא אתר שפורץ גבולות בידוד, עוקף את Chromium, או מקבל גישה בלתי מוגבלת למערכת הקבצים. ההיפך הוא הנכון. המודל מעניין דווקא כי הדפדפן נשאר בתוך הגבולות המיועדים שלו: secure context, user gesture, תהליך picker, הרשאה שניתנה על ידי המשתמש, אילוצי תמיכת דפדפן, הגבלות תיקיות מוגנות, והיקף הרשאה (read או readwrite).

Rogue Sandbox מצביע על משהו אחר: תהליך עבודה שהמשתמש תופס כבטוח.

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

המשתמש רואה Scan. בפועל, Write עשוי להתרחש. המשתמש רואה Clean. בפועל, Modify עשוי להתרחש. המשתמש רואה Quarantine. בפועל, הקובץ המקומי עשוי להשתנות.

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

ההסוואה אינה טכנית. היא נרטיבית.

בתרחיש הזה, המשתמש לא בהכרח עיוור למה שקורה. הוא רואה אתר, כפתור, picker לתיקייה, סרגל התקדמות, ותוויות סטטוס כמו Analyzing, Uploading, Cleaning, Quarantining, או Repairing. הפעילות לעיתים קרובות מתרחשת מולו, לא מאחורי גבו.

הבעיה היא פרשנות דרך נרטיב.

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

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

איור 3 - הסיפור שהמשתמש רואה מול המציאות הטכנית

צלילה לעומק: File System Access API

מה ה-API מאפשר קונספטואלית

ה-File System Access API תוכנן לאפשר לאפליקציות אינטרנט לעבוד עם קבצים מקומיים בצורה עשירה יותר.

במודל הישן, אתר בדרך כלל קיבל קובץ דרך input type="file" ויכול לקרוא אותו כ-Blob. במודל החדש, התנהגות הדפדפן הרבה יותר קרובה לאפליקציות מקומיות: המשתמש בוחר קובץ או תיקייה, הדפדפן מחזיר handle, והאפליקציה יכולה לבצע פעולות על בסיס ההרשאות שניתנו.

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

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

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

ברמה גבוהה:

לחיצת משתמש ← showDirectoryPicker() ← Directory Handle ← הרשאה ניתנה ← Writable Handle ← שינוי קובץ מקומי

Pseudo-Code ופרספקטיבה ברמת קוד המקור

// Safe defensive pseudo-code, not an implementation of file modification.
if (!('showDirectoryPicker' in window)) {
	showUnsupportedBrowserMessage();
}

button.addEventListener('click', async () => {
	// Must be triggered by a user gesture.
	const dir = await window.showDirectoryPicker({
		mode: 'readwrite',
		startIn: 'documents'
	});

	const permission = await dir.queryPermission({ mode: 'readwrite' });
	if (permission !== 'granted') {
		await dir.requestPermission({ mode: 'readwrite' });
	}

	// Defensive lesson: this is the trust boundary.
	logSecurityEvent('origin received directory read/write access');
});

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

הבהרות מפתח:

Secure Context ו-User Gesture

ה-API לא מיועד לרוץ בשקט ברקע. showDirectoryPicker() דורש secure context (בדרך כלל HTTPS) ו-transient user activation, כלומר פעולת משתמש מפורשת כמו לחיצה על כפתור. אם הקריאה לא מתבצעת מתוך אינטראקציה כזו, הדפדפן אמור לחסום אותה.

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

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

Directory Handle, `read`, ו-`readwrite`

כשהמשתמש בוחר תיקייה, האתר לא מקבל נתיב מוחלט קונבנציונלי. הוא מקבל FileSystemDirectoryHandle. ה-handle מייצג את האובייקט שנבחר ומאפשר פעולות דרך ה-API.

ההבחנה הקריטית היא מצב ההרשאה: read מול readwrite.

read מאפשר קריאה ומיפוי.
readwrite מאפשר גם שמירת שינויים, ובהתאם למימוש והיקף ההרשאה, יצירה, שינוי, או מחיקה של קבצים.

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

מיפוי פרימיטיב לסיכון

פרימיטיב	שימוש לגיטימי	נקודת סיכון
`showDirectoryPicker`	בחירת תיקייה לעבודה מקומית	המשתמש עלול לבחור היקף רחב מדי
`FileSystemDirectoryHandle`	ייצוג התיקייה שנבחרה	ה-handle הופך את התיקייה למרחב העבודה של האתר
`entries()` / `values()`	מעבר על קבצים ותיקיות משנה	מאפשר מיפוי תוכן מקומי בתוך ההיקף המורשה
`getFileHandle`	גישה לקובץ בתוך התיקייה שנבחרה	פעולות יכולות להשפיע על קבצים שהמשתמש לא הערים לגביהם בנפרד
הרשאת `readwrite`	שמירת עריכות או תיקון קבצים	המעבר הקריטי מסריקה לשינוי

היקף פלטפורמה: לא ישים באופן אוניברסלי

בשלב זה, נקודה חשובה אחת חייבת הדגשה: היכולת הזו אינה אוניברסלית.

Chrome ו-Chromium נמצאים במרכז הסיפור הזה. Firefox ו-Safari לא מספקים את אותו מודל מלא עבור showDirectoryPicker() וגישת readwrite לתיקיות מקומיות. לעומת זאת, Chrome/Chromium בדסקטופ ו-Chrome באנדרואיד הם הסביבות שבהן השאלה הזו הופכת לרלוונטית מעשית.

מה קורה מתחת למכסה ב-Chromium

ה-File System Access API מפוצל בין שכבות מרובות:

תהליך ה-renderer שבו JavaScript רץ
ממשקי Blink/Mojo
רכיבי browser-process האחראים על הרשאות ובדיקות מדיניות
לוגיקת הקשר הרשאות
שירותי backend של מערכת הקבצים

ברגע שאתר מקבל handle, הפעולות עוברות דרך שרשרת אכיפה מלאה של הדפדפן.

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

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

איור 5 - Chromium מבצע אימות נוסף לפני החזרת גישה לרשומות קבצים שעשויות להוביל למיקומים רגישים

איור 6 - Chromium דוחה handle כשאימות רשומה רגישה נכשל.

מסקנת מחקר

הדפדפן אכן מנסה להגן על המשתמש. זה לא מודל פשטני של “תן לי את C:\ וזהו”. יש נקודות ביקורת אמיתיות בתהליך.

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

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

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

מתיאוריה למעשה

עד כה, המאמר התמקד בעיקר במודל ההרשאות של File System Access API, באיך Chromium אוכף אותו, ובפער בין איך שמשתמשים תופסים פעולת סריקה לבין איך שהדפדפן מפרש אותה.

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

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

שלב Ransomware והצפנה בתהליך התקיפה מבוסס הדפדפן — איור 8 - Ransomware והצפנה

לקוראים שרוצים לעיין בקוד אימות ה-ransomware, הפרסום זמין כאן: Browser-Based-Ransomware

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

שינוי זה הוליד את שאלת Rogue Sandbox המעשית: האם ניתן להשתמש באותו מודל אמון כדי לשנות קבצים קיימים בצד הלקוח מבלי שהמשתמש יחווה את האירוע כהדבקה?

בפשטות:

Ransomware מבוסס דפדפן היה הטריגר.
Rogue Sandbox הוא המודל.
הדבקת קבצים בצד הלקוח הפכה לכיוון המחקר.

הדבקת קבצים בצד הלקוח

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

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

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

ברמה גבוהה, תהליך המעבדה היה:

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

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

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

היכולת שנבדקה צרה וברורה יותר: לאחר אישור המשתמש, האם קובץ מקומי יכול להיקרא, להשתנות בתהליך צד לקוח מבוקר, ולהיכתב חזרה למיקומו המקורי דרך File System Access API?

לכן הדגש הטכני בסעיף זה הוא על שרשרת הפעולות ולא על התנהגות payload מתוחכמת:

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

במימושים מלאים, פרטי השינוי תלויים בסוג הקובץ. עבור קבצי PE, עריכות בתים אקראיות אינן מספיקות. כדי לשמור על תקינות הקובץ לאחר השינוי, מבנה הקובץ, גבולות ה-sections, התנהגות נקודת הכניסה, ופרשנות ה-Windows loader כולם חשובים.

מגבלות טכניות

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

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

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

המסקנה היא לא שכל אתר יכול להדביק כל קובץ.

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

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

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

ה-File System Access API דורש פעולת משתמש. picker לא יכול להיפתח בשקט ברקע ללא אינטראקציה. בגלל זה, כל המודל תלוי באיך שמשתמשים משוכנעים לבצע פעולה לגיטימית שהם מאמינים ששייכת לתהליך בטוח.

לכן בניתי את התהליך סביב נרטיב של סורק נוזקות. משתמשים מצפים ממוצר כזה לגעת בקבצים: לקרוא, לנתח, לזהות, ולפעמים “לנקות” אותם. המילה clean יוצרת גשר פסיכולוגי בין read ל-write. המשתמש חושב במונחים של תיקון. הדפדפן מעריך הרשאת כתיבה.

התהליך המלא תוכנן סביב כמה עקרונות UX:

בדיקות תאימות דפדפן מוקדם בתהליך כדי לחזק את האמינות של המוצר.
בחירת תיקייה דרך תהליכי picker מקוריים של הדפדפן, לא דפוס העלאה קלאסי.
שפה מרוכזת סביב Scan, Analyze, Clean, ו-Protect במקום Modify או Write.
מוני איומים נמוכים והדרגתיים כדי לשמור על חוויה אמינה ולא תיאטרלית.
סרגלי התקדמות ויומני פעולה שנראים כפעילות סורק שגרתית.
מצב השלמה חיובי שמסמן “הקבצים מוגנים”, בזמן ששינויים בקבצים עשויים להיות התרחשו.

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

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

זו הסוואה נרטיבית.

המשתמש רואה “ניקוי”. המערכת רואה כתיבה. המשתמש רואה “קבצים מוגנים”. הקובץ רואה שינוי.

ארכיטקטורת ההזרקה

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

אין התקנת agent מקומי, אין הרצת binary מקומי, אין exploit בדפדפן, ואין בריחה מ-JavaScript ל-native. האתר רץ בתוך הדפדפן, משתמש ב-File System Access API, מקבל FileSystemDirectoryHandle לתיקייה שנבחרה על ידי המשתמש, ומבצע עיבוד דרך JavaScript על קבצים בתוך ההיקף המורשה.

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

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

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

צינור ההדבקה בצד הלקוח

אלמנט המימוש המרכזי הוא JavaScript שמבצע עיבוד בצד הלקוח ושינוי קבצים מבוקר.

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

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

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

לכן המימוש השתמש בגישת fail-closed: אם קובץ לא עומד באילוצים מוגדרים מראש, הוא מדולג.

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

סוג קובץ וסיומת.
סף גודל קובץ.
קשר נתיב להיקף שנבחר.
שמות ותיקיות ברשימות דילוג מפורשות.
קבצים שכבר עובדו.
קבצים שלא ניתן לקרוא או לכתוב.
קבצים שמבנם נכשל בבדיקות אימות.
מצב dry-run או test-mode.

רק אחרי שעובר סינון, קובץ נקרא לזיכרון דרך ה-handle שלו. בנקודה הזו, העיבוד מתרחש על ArrayBuffer או Uint8Array, כלומר ייצוג בינארי בדפדפן.

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

בקיצור, MessageBox אינו מטרת הסיום. הוא סמן.

לאחר העיבוד, הקוד יוצר גרסה שונה בזיכרון וכותב אותה חזרה דרך File System Access API עצמו.

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

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

מנקודת מבט של נראות לתוקף, זה משמעותי: המשתמש לא הוריד artifact חדש. הוא בחר תיקייה, התחיל תהליך עבודה דמוי סריקה, והקובץ המקומי השתנה במקומו.

מה הקוד חייב לקחת בחשבון

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

הכול תלוי במה שהמשתמש בחר ובמה שהדפדפן הסכים לחשוף.

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

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

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

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

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

ההשלכה המעשית היא ש-JavaScript אינו “רק ממשק” במודל הזה.

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

זה בדיוק המקום שבו Rogue Sandbox הופך למשמעותי תפעולית.

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

Mark of the Web: כשעורכים קובץ במקום להוריד אותו

קרדיט מחקרי

Sagi Olshansky העלה את שאלת ה-Mark of the Web (MOTW) המפתח שעיצבה את הפרק הזה.

אחת השאלות החשובות ביותר במחקר הזה הייתה Mark of the Web (MOTW).

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

בתרחיש Rogue Sandbox, המסגור שונה. אין בהכרח קובץ שהורד מחדש. במקום זאת, קובץ מקומי שכבר קיים עשוי להשתנות על ידי הדפדפן. שאלת המחקר הפכה אפוא: האם MOTW עדיין רלוונטי כשהאירוע הוא עריכה ולא הורדה?

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

קובץ מקומי שנוצר במעבדה ללא MOTW, ואז שונה דרך הדפדפן.
קובץ ממקור אינטרנטי שכבר מסומן עם MOTW, ואז שונה דרך הדפדפן.
קובץ חדש שנוצר או נכתב על ידי הדפדפן דרך File System Access API.

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

SmartScreen ומה קורה כשאין הורדה

אחד הממצאים המפתיעים ביותר במחקר הזה הופיע בעת בדיקת כתיבה חוזרת לקבצים קיימים דרך File System Access API.

עד לאותה נקודה, התייחסתי לתהליך הזה כמשהו מחוץ לנתיב אבטחת הורדות הקלאסי. המשתמש לא הוריד קובץ אינטרנטי חדש. לא היה אירוע מדף הורדות, לא artifact חדש ב-Downloads, לא תהליך Content-Disposition, ואף אירוע שנראה כמו הורדה מסורתית.

ברמה גבוהה, הרצף נראה פשוט:

המשתמש בוחר תיקייה ← האתר מקבל הרשאת כתיבה ← קובץ מקומי נערך במקומו

בבדיקה מעשית מול Chrome, עם זאת, התמונה הייתה מורכבת יותר. במקרים מסוימים, כשהאתר ניסה לכתוב חזרה קבצים ספציפיים דרך File System Access API, Chrome הפעיל הגנות הקשורות ל-Safe Browsing / Download Protection.

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

זה בדיוק המקום שבו הפרק הזה הופך למעניין.

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

Chromium כולל גם נתיב ייעודי שמגשר בין פעולות כתיבה של File System Access לערימת Download Protection. בקוד המקור של Chromium, ישנם רכיבים ייעודיים כמו check_file_system_access_write_request.cc ו-file_system_access_metadata.cc, וב-download_protection_service.cc ישנה פונקציה מפורשת בשם CheckFileSystemAccessWrite.

מנקודת המבט של Chromium, כתיבה דרך File System Access API לא תמיד מטופלת כ”סתם עריכת קובץ”. היא יכולה להיות מורמת לאירוע שעובר דרך לוגיקת בדיקת Safe Browsing / Download Protection.

בשלב זה, Chromium מקבל FileSystemAccessWriteItem, בודק אם ה-delegate מאפשר בדיקת הגנה לפעולת הכתיבה הזו, ואם מותר, יוצר CheckFileSystemAccessWriteRequest ומתחיל את תהליך הבדיקה.

איור 15 - הטריגר הוא לא רק המקור. Chromium גם מסתכל על הקובץ הנכתב כאובייקט עם סוג, נתיב, מטא-נתונים והקשר מדיניות.

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

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

Chrome מול Edge

שניהם מבוססי Chromium, כך ששכבת File System Access API דומה מאוד ברמת פלטפורמת האינטרנט.

עם זאת, שכבת המוניטין וההגנה אינה זהה. Chrome מסתמך על Google Safe Browsing, בזמן ש-Edge משלב את Microsoft Defender SmartScreen. Microsoft מתעדת את SmartScreen כהגנה מפני אתרי פישינג/נוזקות, אפליקציות חשודות, והורדות שעשויות להיות זדוניות; תיעוד Edge גם מציין שאותות URL/קובץ רלוונטיים יכולים להישלח לשירותי SmartScreen לבדיקות מוניטין.

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

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

הדגמה

שימו לב ששני הסרטונים מציגים את Rogue Sandbox.

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

לנוחיות, הפרויקט זמין כאן לעיון ומשוב: מאגר פרויקט Rogue Sandbox

מה ניתן לעשות מבחינה הגנתית?

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

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

המלצות ארגוניות

הגדירו מדיניות דפדפן כדי להגביל או לשלוט בבקשות אתרים לגישת קריאה/כתיבה למערכת הקבצים.
אפשרו File System Access רק למקורות ידועים ומאושרים שבהם הצורך העסקי מפורש.
הכשירו משתמשים שהרשאת תיקייה אינה שווה להעלאה רגילה; זו הרשאה לפעול על קבצים מקומיים.
נטרו תהליכי דפדפן שכותבים לקבצים רבים או משנים סיומות רגישות.
התייחסו לשינויי קבצים על ידי chrome.exe או msedge.exe כאותות התנהגותיים שדורשים הקשר.

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

סיכום

Rogue Sandbox הוא לא סיפור sandbox-escape. הדפדפן לא פרץ את גבולותיו. הוא פעל בדיוק כפי שתוכנן: user gesture, בחירת תיקייה, מתן הרשאה, ויכולת ברמת מקור.

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

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

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

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

הערות מחקר

סעיף זה לוכד תצפיות חשובות שלא התאימו לזרימה העיקרית אבל שוות שימור.

Safari ו-Firefox

מודל ה-showDirectoryPicker() + readwrite לתיקיות מקומיות המלא אינו נתמך באותו אופן בכל הדפדפנים. Safari ו-Firefox לא חושפים כרגע את אותו משטח תפעולי כמו Chromium בהקשר הזה.

Chrome באנדרואיד

Check Point הדגישו את הרלוונטיות של Chrome באנדרואיד לתרחישי תיקיות מדיה. מחקר זה מתמקד בעיקר בדסקטופ כי שינוי מבוקר של פורמטים ניתנים להרצה קיימים רלוונטי יותר לתהליכי עבודה של Windows desktop.

תיקיות רגישות

Chromium אינו מספק גישת נתיבים בלתי מוגבלת. הוא כולל בדיקות לתיקיות ורשומות רגישות, כולל תרחישי symlink-למיקום-חסום. מודל זה לא עוקף את הבדיקות האלה; הוא ממנף אזורים לא חסומים שנבחרו על ידי המשתמש.

`startIn` וגישה לכל המערכת

startIn לא מעניק גישת root או גישה לכל המערכת. הוא רק משפיע על מיקום ההתחלה של ה-picker. הגישה בפועל נשארת תלויה בבחירת המשתמש ובאכיפת הדפדפן.

User Gesture

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

סנכרון ענן

כיוון עתידי רלוונטי הוא תיקיות מסונכרנות כמו OneDrive, Google Drive, או Dropbox. עריכות מקומיות באמצעות דפדפן עשויות להיות מופצות על ידי לקוחות סנכרון. זה לא היה מקרה התקיפה העיקרי כאן, אבל הוא כיוון מעקב חשוב.

חתימות דיגיטליות

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

נראות EDR

מוצרי EDR עשויים לצפות ב-chrome.exe או msedge.exe כותבים קבצים מקומיים. עם זאת, בהיעדר שינוי קבצים מהיר בנפח גבוה, פעילות זו עשויה להישאר בעלת רעש נמוך ותחת סיווג.

Safe Browsing אינו רק פישינג

המחקר מצביע על כך שהרלוונטיות של Safe Browsing נמתחת מעבר לדפי פישינג ותרחישי הורדה קלאסיים. Chromium כולל נתיבי בדיקת כתיבה ייעודיים לפעולות File System Access, אבל ההתנהגות עדיין תלויה בסוג הקובץ, בסיווג, ובמדיניות הדפדפן.

מקורות

1 Browser-Only Ransomware: From LLM Hallucinations to a Practical Attack Technique research.checkpoint.com · Check Point Research 2 The File System Access API developer.chrome.com · Chrome Developers 3 File System API developer.mozilla.org · MDN Web Docs 4 file_system_access_directory_handle_impl.cc chromium.googlesource.com · Chromium Source 5 File System Access Specification wicg.github.io · WICG 6 Macros from the Internet Are Blocked by Default in Office learn.microsoft.com · Microsoft 7 Microsoft Edge Support for Microsoft Defender SmartScreen learn.microsoft.com · Microsoft 8 DefaultFileSystemWriteGuardSetting chromeenterprise.google · Chrome Enterprise Policy 9 DefaultFileSystemWriteGuardSetting learn.microsoft.com · Microsoft Edge Policy