פגיעויות Log4j כאן כדי להישאר - האם אתה מוכן?

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

מועצת סקירת בטיחות הסייבר של המשרד לביטחון המולדת יצאה לראשונה בשנת 2021, ובשנת 2022 פרסמה את דוח בטיחות ראשוני (PDF). בו, הדירקטוריון כינה את Log4j "פגיעות אנדמית", בעיקר בגלל שאין "רשימת לקוחות" מקיפה עבור Log4j, מה שהופך את השמירה על נקודות תורפה למשימה כמעט בלתי אפשרית. מחלקת קבינט פדרלית אחת אפילו השקיעה 33,000 שעות בתגובת Log4j.

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

ניצול מול פגיעות

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

לכל חברה יש אלפי נקודות תורפה וחשיפות נפוצות (CVE), שרבות מהן ניקוד גבוה ב-Common Vulnerability Scoring System (CVSS), כך שאי אפשר לתקן את כולן. כדי להילחם בזה, התקווה היא שכלי ניהול נקודות תורפה מבוססות סיכונים (RBVM) יצליחו להקל על סדר העדיפויות על ידי הבהרת מה ניתן לניצול.

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

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

לדוגמה, עם Log4j, יש לזהות את הפרמטרים הבאים:

• האם קיימת ספריית Log4j הפגיעה?
• האם הוא נטען על ידי יישום Java פועל?
• האם חיפוש JNDI מופעל?
• האם Java מאזינה לחיבורים מרוחקים, והאם יש חיבור למכונות אחרות?

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

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

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

מאבק בפגיעויות Log4j

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

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

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

כדאי גם לעשות את הפעולות הבאות:

• תיקון: זהה את כל המוצרים שלך שפגיעים ל-Log4j. ניתן לעשות זאת באופן ידני או באמצעות סורקי קוד פתוח. אם פורסם תיקון רלוונטי עבור אחד מהמוצרים הפגיעים שלך, תקן את המערכת בהקדם האפשרי.
• דרך לעקיפת הבעיה: ב-Log4j גרסאות 2.10.0 ומעלה, בשורת Java CMD, הגדר את הדברים הבאים: log4j2.formatMsgNoLookups=true
• לַחסוֹם: במידת האפשר, הוסף כלל לחומת האש של יישום האינטרנט שלך כדי לחסום: "jndi:"

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

• הפצת תוכן ויחסי ציבור מופעל על ידי SEO. קבל הגברה היום.
• Platoblockchain. Web3 Metaverse Intelligence. ידע מוגבר. גישה כאן.
• מקור: https://www.darkreading.com/attacks-breaches/log4j-vulnerabilities-are-here-to-stay-are-you-prepared-