דפדפני אינטרנט מותקנים על מיליארדי מכשירים ברחבי העולם, מה שהופך אותם למטרות עיקריות עבור פושעי סייבר. מכיוון שלדפדפני אינטרנט גדולים יש בסיסי משתמשים עצומים, פגיעות אחת יכולה להיות בעלת השלכות מרחיקות לכת. שמירה על דפדפנים מעודכנים היא קריטית לשמירה על הגנה מפני איומים מתפתחים.
כדי להמחיש את חומרת הפגיעויות בדפדפני אינטרנט, עמיתינו ערכו ניתוח מקיף של CVE-2024-6778, פגיעות בדפדפנים מבוססי Chromium, המשפיעה במיוחד על כלי פיתוח של Chrome. בלוג זה מספק בחינה מפורטת של ההיבטים הטכניים של הפגיעות, ההשפעה הפוטנציאלית ואסטרטגיות הפחתה.
רקע של CVE-2024-6778
CVE-2024-6778 היא פגיעות מסוג "מצב מרוץ" שהתגלתה בכלי הפיתוח של Chrome. היא מאפשרת לתוקפים להחדיר HTML או JavaScript זדוניים לדפי דפדפן בעלי זכויות יוצרים באמצעות הרחבות דפדפן זדוניות. על פי NVD (מסד הנתונים הלאומי של פגיעויות), פגיעות זו דורגה בחומרה גבוהה, עם ציון CVSS של 8.8.
דירוג החומרה הגבוה של פגיעות זו נובע מהפוטנציאל שלה לאפשר ביצוע קוד מרחוק, מה שעלול לגרום לפגיעה במערכות, לפגוע בסודיות ולהפחתת הזמינות.
סקירת אבטחת Chromium
כדי להבין לעומק את ההשלכות של CVE-2024-6778, חשוב להכיר את ההיבטים המרכזיים של מודל האבטחה של Chromium. Chromium הוא הבסיס בקוד פתוח לדפדפנים כמו Google Chrome, Microsoft Edge, Opera ו-Brave. הוא משתמש במודל רב-תהליכי שבו כל כרטיסייה, המכונה גם רנדרר, ורכיבי דפדפן שונים פועלים בתהליכים מבודדים כדי לשפר את היציבות והאבטחה על ידי הגבלת היקף הפגיעות הפוטנציאליות.
אלמנט בסיסי באבטחה של Chromium הוא מנגנון ה-sandbox שלו, אשר מגביל את תהליכי הרינדור מגישה ישירה למשאבי המערכת. במקום זאת, כל האינטראקציות מנוהלות דרך ערוצי IPC (תקשורת בין תהליכים) כדי להבטיח שרק פעולות מורשות מבוצעות.
לא כל הרכיבים בתוך Chromium כפופים ל-sandbox מלא. דפי WebUI, כגון chrome://settings ו-chrome://downloads , עוברים עיבוד בתוך תהליכי הרינדור אך פועלים עם מגבלות sandbox חלקיות. תהליך זה מעניק להם גישה לממשקי API של דפדפן שבדרך כלל אינם נגישים דרך האינטרנט.
לדוגמה, לדף chrome://policy תפקיד חיוני בסביבות ארגוניות, שכן הוא מאפשר למנהלי מערכת ולמשתמשים להגדיר ולאכוף מדיניות אבטחה של דפדפנים. מדיניות זו מנוהלת גם באמצעות מדיניות קבוצתית במערכות Windows.
מכיוון ש-chrome://policy יכול לתקשר ישירות עם מערכת ההפעלה, הוא מהווה מטרה חשובה לתוקפים. הפגיעות CVE-2024-6778, המנצלת מצב מרוץ בתוך Chrome DevTools, מאפשרת לתוקפים להחדיר קוד זדוני לדפים אלה, וליצור סיכוני אבטחה חמורים.
ניתוח טכני של CVE-2024-6778
תַגלִית
פגיעות זו התגלתה בתכונת בדיקה שהוצגה בגרסה 117 של Chrome Enterprise. תכונה זו מאפשרת בדיקת מדיניות דרך דף chrome://policy/test . עקב תיעוד רשמי מוגבל על תכונה זו, עמיתינו ביצעו בדיקה יסודית של קוד המקור של Chromium, בתוספת תובנות ממחבר ה-CVE, כדי להבין באופן מלא את יישומו ולזהות פגיעויות אבטחה קשורות.
רכיבי ניהול מדיניות
OPSWAT ניתוח קוד המקור של העמיתים גילה שבתוך chrome://policy/test, מדיניות מנוהלת באמצעות מידע על מדיניות ממשק ומתקשר בין WebUI לתהליכי הדפדפן דרך מדיניותבדיקתדפדפןפרוקסי כיתה. ה מידע על מדיניות המבנה מוגדר כדלקמן:
על ידי בחינה נוספת של המחלקה האחראית על טיפול במדיניות זו, זיהתה שיטה בשם החלת מדיניות בדיקהשיטה זו ממנפת גישה פרטית API , הגדר מדיניות בדיקה מקומית, כדי להחיל באופן דינמי רשימה של מדיניות.
כדי לקבל תובנות לגבי אופן עיבוד בקשות מדיניות באמצעות זה API , העמיתים מנתחים את מדיניות בדיקה מקומית של HandleSet שיטה בתוך ה מטפל מדיניותUI מַחלָקָה:
ה מדיניות בדיקה מקומית של HandleSet השיטה מאחזרת את נתוני המדיניות מהארגומנטים שסופקו ומקבלת מצביע אל ה- ספק מדיניות בדיקה מקומי לדוגמה, באמצעות מחבר המדיניות הגלובלי של הדפדפן. לאחר מכן, הוא מאמת את קיומו של ספק זה לפני שהוא מורה לפרופיל המשתמש הנוכחי להשתמש בו.
אימות זה נמצא כבלתי מספק, שכן הוא רק מבטיח ש ספק_בדיקות_מקומי אינו ריק לפני החלת המדיניות. יצירה ואתחול של ספק_בדיקות_מקומי נשלטים על ידי ה- צור אם מותר שִׁיטָה:
בתוך ה צור אם מותר שיטה, ערך ההחזרה תלוי לחלוטין בתוצאה של האם בדיקת מדיניות מופעלת פונקציה. פונקציה זו קובעת האם ספק מדיניות בדיקה מקומי נוצר מופע, בהתבסס על שילוב של העדפות משתמש וערוץ ההפצה של הדפדפן:
מֵאָז שירות_העדפה מוגדר באופן עקבי ל-null בכל פעם האם בדיקת מדיניות מופעלת () כאשר נקרא, התנאי הראשון מעקף, מה שמשאיר את החלטת ההפעלה תלויה אך ורק בערוץ השחרור של הדפדפן.
בבניות Chromium ללא מותג, ערוץ השחרור מוגדר כברירת מחדל ל- ערוץ::לא ידועלפי הלוגיקה של הפונקציה, ערוץ::לא ידוע מטופל באותה מידה כמו ערוץ::ברירת מחדל, אשר מאפשר את תכונת בדיקת המדיניות כברירת מחדל. ניתוח זרימת הקוד גילה שהפרטי API הגדר מדיניות בדיקה מקומית ניתן להפעילו דרך WebUI כדי להחיל מדיניות ללא הגבלות גישה משמעותיות.
ניצול
על ידי זיהוי ומינוף הפרטי הזה API , תוקף יכול להחיל מדיניות באופן שרירותי דרך ממשק המשתמש של האינטרנט, מה שמאפשר מניפולציה של הגדרות כגון מחליף דפדפנים מופעל, רשימת כתובות URL של מחליף דפדפנים, נתיב דפדפן חלופי, ו פרמטרים חלופיים של דפדפן כדי לבצע פקודות. לדוגמה, על ידי הגדרת נתיב דפדפן חלופי ל-powershell ו- פרמטרים חלופיים של דפדפן אֶל חישוב, ניתן לבצע פקודות מעטפת שרירותיות כאשר מבקרים בכתובת URL ספציפית.
החל מדיניות משתמשים זדוניים שרירותית באמצעות גישה פרטית API
כדי להדגים כיצד ניתן ליישם מדיניות באמצעות הגישה הפרטית הגדר מדיניות בדיקה מקומית API כפי שזוהה בניתוח הקודם, קוד ה-JavaScript הבא הוא סקריפט שמגדיר את אפשר דינוזאורביצת פסחא מדיניות ומיישמת אותה ביעילות באמצעות ממשק משתמש אינטרנטי על ידי קריאה הגדר מדיניות בדיקה מקומית:
ניתן ליישם בהצלחה את המדיניות כדי להשבית את אפשר דינוזאורביצת פסחא סְבִיבָה.
להשפעה גדולה יותר, תוקף עשוי למקד את מחליף דפדפנים מְדִינִיוּת:
מדיניות זו מאפשרת לדפדפן להפעיל נתיב דפדפן חלופי אם כתובת ה-URL עומדת בתנאים מסוימים. ניתן לנצל זאת על ידי הגדרת נתיב זה כך שיפנה לקובץ הרצה של המערכת כדי לבצע פקודות של מערכת ההפעלה. קוד ה-JavaScript הבא מדגים גישה זו:
סקריפט זה מבצע את המשימות הבאות:
- מאפשר את
מחליף דפדפניםתכונה לדוגמה.com - מגדיר את נתיב הדפדפן החלופי ל-PowerShell
- מבצע
חישובבכל פעם שניגשים לכתובת ה-URL שצוינה.
סימולציה של הרחבת Chrome זדונית
זיהוי הפרטי API שמאפשר יישום של מדיניות מציג וקטור תקיפה משמעותי עבור יריבים. כדי לנצל ביעילות את הפגיעות הזו, תוקף יצטרך לפתח תוסף Chrome זדוני המשתמש בכלי הפיתוח של Chrome. API כדי להריץ קוד JavaScript זדוני.
כדי להדגים את ההשפעה הפוטנציאלית בעולם האמיתי, עמיתינו ביצעו סימולציה של תרחיש שבו תוסף זדוני של Chrome מותקן בדפדפן פגיע ומשמש לביצוע המתקפה. ממשקי ה-API של chrome.devtools בתוספי Chrome מאפשרים למפתחים להרחיב ולקיים אינטראקציה עם ממשק DevTools של Chrome.
עם זאת, הפעלת כלי הפיתוח API באמצעות הרחבה יש אתגרים מסוימים שיש לעקוף. ראשית, כלי הפיתוח API פועל רק כאשר DevTools פתוחים ובודקים באופן פעיל אתר אינטרנט. שנית, DevTools API אינו מאפשר ביצוע קוד בממשק המשתמש של האינטרנט, WebUI. מגבלה זו מסייעת לשמור על האבטחה והשלמות של WebUI במהלך תהליכי פיתוח ובדיקה.
סימנים המעידים על ביצוע Javascript באמצעות טעינה מחדש API
ניתוח נוסף גילה כי לפונקציה chrome.devtools.inspectedWindow.reload חסרה האימות המאשר האם הרחבה מורשית להריץ סקריפטים בדף שנבדק. רמת ההגנה היחידה שלה היא שרת ההרחבה של devtools, החוסם גישה לאחר שינוי כתובת ה-URL של הדף שנבדק.
דפי About:blank יורשים את ההרשאות והמקור של הדף שפתח אותם. משמעות הדבר היא שהיכולת לבצע קוד ב-about:blank כאשר הוא מופנה מחדש מאותות WebUI היא פגיעות פוטנציאלית.
ביצוע קוד בממשק המשתמש של webUI באמצעות טעינה מחדש API
תנאי הגזע ב chrome.devtools.inspectedWindow.reload() מאפשר ביצוע קוד בדפי WebUI של Chrome (למשל, chrome://policy), שבדרך כלל מוגנים. הניצול מנצל את טעינת הקוד מחדש. API היכולת של להזריק JavaScript במהלך מעברי עמודים. כך זה עובד:
- ממשק משתמש אינטרנטי יעד: פתח דף ממשק משתמש אינטרנטי (למשל, chrome://policy) בכרטיסייה וצרף כלי פיתוח.
- סקריפט הזרקה: השתמש בפונקציה reload() API עם
injectedScriptפרמטר להפעלת JavaScript שרירותי במהלך טעינה מחדש. - תנאי מרוץ לניצול: תנאי המרוץ מתרחשים כאשר הטעינה מחדש מופעלת לפני שמנגנוני האבטחה של ממשק המשתמש של האינטרנט מאותחלים במלואם, מה שמאפשר לסקריפט שהוזרק לבצע את עצמו.
בהקשר של ניווט מדף about:blank אל chrome://policy:
מכיוון שרק כתובת ה-URL מאומתת במקום מקור הדף, קיים פרק זמן קצר לאחר הניווט שבו המקור משקף את הדף החדש בעוד שכתובת ה-URL נשארת ללא שינוי.
אִם chrome.devtools.inspectedWindow.reload מופעל במהלך חלון זה, הוא עלול להפעיל בטעות JavaScript בדף היעד.
שיפור אמינות בתנאי מרוץ
ניצול תנאי המרוץ אינו אמין מטבעו בשל תלותו בתזמון. בנוסף, טעינות מהירות או סקריפטים בעלי מבנה פגום עלולים לגרום לקריסות עמוד. גישה חדשה לשיפור האמינות כרוכה בגרימת קריסת עמוד באופן מכוון, שכן פקודות המונפקות דרך DevTools בדרך כלל מבוטלות במהלך קריסה, אך טעינת עמוד ממופה ל chrome.devtools.inspectedWindow.reload() נמצא ברשימה הלבנה ומופעל לאחר טעינת הדף מחדש.
להלן מודל זרימת עבודה לקריסת דף על ידי לחיצה על פקודות עוקבות:
משפט ניפוי באגים בסקריפט תוכן עלול לגרום לקריסה
שימוש פעמיים ברצף מהיר של ניפוי הבאגים משבש את תהליך הניווט בסקריפט תוכן. זה יכול להוביל לקריסה על ידי הצבת ניווט_commit_state_ למצב בלתי צפוי. בעיה זו מתעוררת כאשר RenderFrameImpl::SynchronouslyCommitAboutBlankForBug778318 מבוצע, שינוי _navigation_commit_state לערך בלתי צפוי.
הקריאה הראשונה עוצרת את הביצוע, ומשאירה ניווט_commit_state_ במצב לא עקבי, והשנייה נעצרת במהלך CHECK_EQ בדיקה, נכשלת באימות המצב וגורמת לקריסה.
תיקון
הזנחה של עדכון קבוע של גרסת הדפדפן שלך עלולה לחשוף את המכשיר שלך לאיומי אבטחה חמורים, במיוחד כאלה הקשורים ל-CVE (פגיעויות וחשיפות נפוצות). כדי לסייע במתן סיכון זה, MetaDefender Endpoint™ מספק הגנה חזקה על ידי זיהוי גרסת הדפדפן שלך ובדיקת פגיעויות, כולל CVE ידועות כמו CVE-2024-6778.
MetaDefender Endpoint מוודא שהאפליקציה שלך מעודכנת ומסמנת גרסאות מיושנות או נגועות. היא גם מפרטת יישומים מותקנים עם פגיעויות ידועות, מסווגות לפי חומרת CVE, וממליצה על תיקונים כדי להפחית ביעילות איומים פוטנציאליים. כדי לראות הדגמה חיה כיצד MetaDefender Endpoint יכולים לעזור לכם להפחית את הסיכונים הללו, צרו קשר עם אחד המומחים שלנו עוד היום.
