תוסף אחד בדפדפן יכול לחשוף את כל הארגון

זו לא דרמה טכנית. זו בעיית ניהול סיכונים. הדפדפן הוא היום מערכת העבודה המרכזית של הארגון. שם נמצאים Microsoft 365, Google Workspace, מערכות CRM, בנקים, מערכות כספים, פורטלים של לקוחות, כלי AI, מערכות HR, קונסולות ניהול, לוחות בקרה, קבצים רגישים וסשנים פתוחים. כשנותנים לתוסף דפדפן הרשאות רחבות, לא נותנים לו רק מקום בסרגל הכלים. נותנים לו נקודת תצפית על העסק.

למה תוסף דפדפן מסוכן יותר ממה שהוא נראה

הטעות הנפוצה היא לחשוב שתוסף דפדפן הוא ״תוכנה קטנה״. בפועל, תוסף יכול לקבל הרשאות לקרוא דפים, לשנות תוכן באתר, לגשת להיסטוריית גלישה, לעבוד מול Cookies, להזריק JavaScript, לצפות במה שהמשתמש עושה באפליקציות ענן ולעיתים לתקשר עם רכיבים מקומיים במחשב. לפי MITRE ATT&CK, תוקפים יכולים לנצל תוספי דפדפן כדי להשיג התמדה במערכת, לגנוב מידע שמוזן בדפדפן, לשנות הגדרות פרטיות ואבטחה ואף להשתמש בתוסף כערוץ שליטה.

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

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

הבעיה אינה רק תוסף זדוני. הבעיה היא תוסף עם יותר מדי כוח

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

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

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

כך נראה אירוע דלף דרך תוסף דפדפן

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

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

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

המשפט הכי מסוכן: ״זה מהחנות הרשמית״

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

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

מה צריך למדוד לפני שמאשרים תוסף

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

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

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

המדיניות הנכונה: חסימה כברירת מחדל, אישור לפי צורך

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

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

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

מה SOC צריך לראות

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

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

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

הקשר לזהויות, סודות גישה ויישומי ענן

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

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

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

צ׳קליסט פעולה למנהלי IT ואבטחת מידע

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

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

מודעות עובדים, אבל בלי אשליות

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

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

השורה התחתונה

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

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

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