מהי חולשה? פגם, איום, סיכון ואקספלויט

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

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

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

#ארבע מילים, ארבעה תפקידים

מתחילים מההגדרה הרשמית. המילון של NIST Computer Security Resource Center מגדיר חולשה כפגם במערכת מידע, בנהלי האבטחה שלה, בבקרות הפנימיות שלה או במימוש שלה, שמקור איום יכול לנצל או להפעיל. המילה החשובה היא "פגם". חולשה היא תכונה של מערכת. היא קיימת בין אם מישהו מחפש אותה ובין אם לא.

#חולשה

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

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

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

#איום

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

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

#סיכון

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

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

#אקספלויט

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

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

#איך הארבעה מתחברים

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

1. פגם. טופס ההתחברות מקבל ניחושי סיסמה ללא הגבלה. אין נעילה ואין מגבלת קצב. זו החולשה.
2. מקור איום. למישהו יש רשימת סיסמאות מדליפת נתונים ישנה, והוא משתמש בהן שוב נגד חשבונות רבים. זה האיום.
3. אקספלויט. סקריפט קצר שולח אלפי ניסיונות התחברות ורושם את אלה שמצליחים. הסקריפט הזה הוא האקספלויט.
4. השפעה. חשבון תואם עובר לשליטת התוקף. התוקף קורא את הנתונים של אותו משתמש, וזה אובדן סודיות, ועשוי לשנות הגדרות, וזה אובדן שלמות.
5. סיכון. המשקל של זה תלוי בשני דברים: עד כמה שלבים 2 ו-3 סבירים בסביבה שלך, ועד כמה שלב 4 יהיה חמור עבור החשבונות הרלוונטיים. האם אפשר להגיע לטופס מהאינטרנט? האם החשבונות משתמשים באימות רב־שלבי? למה כל חשבון יכול להגיע?

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

#איך CWE ו-CVE נותנים שמות לפגמים

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

#CWE: סוג הפגם

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

לכל ערך ב-CWE יש מספר. הערך של SQL injection הוא CWE-89, שעוסק בנטרול לא תקין של תווים מיוחדים בפקודת SQL. הערך של cross-site scripting הוא CWE-79. הערכים האלה לא נוקבים בשם של מוצר. הם מתארים דפוס שמופיע במוצרים רבים, ועוזרים למפתחים לזהות אותו לפני שהוא יוצא לשטח.

#CVE: הפגם הספציפי

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

CVE-YEAR-NUMBER

דוגמה אמיתית היא CVE-2021-44228, הפגם ב-Apache Log4j 2 שנודע בשם Log4Shell. המזהה אומר איזה פגם זה. הרשומה אומרת איזה מוצר ואילו גרסאות מושפעים ואיפה נמצא התיקון של הספק.

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

#קריאה של השניים יחד

בקריאת רשומת CVE מחפשים לאיזה סוג פגם היא ממופה. רשומה שממופה ל-CWE-89 מלמדת שהפגם הוא SQL injection, גם אם המוצר לא מוכר. כך אפשר להחיל את מה שידוע על הקטגוריה על מקרה חדש. גם הכיוון ההפוך עוזר: אם למוצר יש היסטוריה של סוג פגם מסוים, ברור מה לבדוק קודם.

#למה חולשה בלי נתיב הגעה היא בדרך כלל בסיכון נמוך

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

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

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

• שינוי ברשת, כמו port forward חדש, כלל security group בענן או נתיב VPN, יכול להפוך שירות לנגיש.
• מחשב שנפרץ באותה רשת יכול להגיע לשירותים שלא נראים מבחוץ.
• עובד שנופל בהודעת פישינג יכול להפוך לנתיב אל מערכת פנימית.
• האפליקציה עצמה עלולה לחשוף את השירות בנתיב אחר, כמו proxy או הפניה.

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

#למה הגדרה שגויה נחשבת לחולשה

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

הנה דוגמה פשוטה. בלוק ה-nginx הזה מפעיל רישום תיקיות עבור נתיב:

location /backup/ {
    autoindex on;
}

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

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

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

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

#תרגיל מעשי: סיווג חמישה ממצאים על נייר

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

1. אפליקציית web מריצה גרסת ספרייה עם פגם שמתועד בפומבי. אפשר להגיע לאפליקציה מהאינטרנט.
2. רישום תיקיות מופעל על נתיב גיבוי. אפשר להגיע לשרת רק מרשת המשרד.
3. שירות עם פגם ידוע מאזין רק על כתובת ה-loopback של מחשב נייד.
4. לטופס התחברות אין מגבלת קצב, אבל כל חשבון דורש גורם שני.
5. דלי אחסון בענן מוגדר לקריאה ציבורית, וכרגע הוא ריק.

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

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

#טעויות נפוצות

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

#איך ממשיכים

קוראים את הערך על חולשה במילון של NIST ואת סעיפי הערכת הסיכונים ב-NIST SP 800-30 Revision 1. אחר כך פותחים כל רשומת CVE שמעניינת ומאתרים בה שלושה דברים: המוצר והגרסאות המושפעים, תיאור הפגם ומיפוי ה-CWE, אם מופיע כזה. ההרגל הזה הופך רשימת מזהים לתמונה ברורה, וזו המיומנות הבסיסית בקריאת הודעות.

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

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

#מקורות

• NIST CSRC glossary: vulnerability
• CWE: About CWE
• CVE: Overview
• NIST SP 800-30 Rev. 1: Guide for Conducting Risk Assessments