באגים, פגיעויות, ניצול: התנאים לפשרה

(של מרקו רוטיני)
14/08/24

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

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

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

נתחיל עם כמה אמיתות מוחלטות שחשוב לי לזכור.

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

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

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

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

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

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

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

כדי להבין טוב יותר את הניואנס הזה, בואו ננסה לבחון כיצד מדווחת על פגיעות - בהשראת ארגון ניתוח האיומים האמריקאי MITER. בין אינספור הפעילויות של MITER יש למעשה ניהול ועדכון של מסד נתונים פגיעות בשם CVE (Common Vulnerabilities and Exposures).

להלן דוגמה לאופן שבו פגיעות מיוצגת לציבור הרחב:

מיד מתברר שתיאור ההקשר אומר הרבה יותר מהדרכים האפשריות לניצול הבאג מבלי לתת דוגמאות על כמו בפועל: למשל, זה מודיע לנו שלדגם Omada ER605 מהיצרן TP-Link יש בעיית גלישת מאגר: המשמעות היא שבשל שגיאת פיתוח הזיכרון של המכשיר מקבל יותר נתונים ממה שהוא יכול להכיל; אומר לנו שאין צורך באימות כדי לכתוב לזיכרון זה; מדגיש לנו איך הניצול של זה קרֶפּ יכול להתקיים גם מרחוק, עם ההסמכה של ביצוע קוד מרחוק.

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

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

שנית, ה משימה הפיכת פגיעות לניצול היא באחריות הכותב לנצל.

L 'לנצל מייצג קוד ו/או הליך שאם מבוצע גורם לשגיאה המנצלת את באג נשאר בקוד המפתח.

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

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