לפני מספר שבועות החדשות על בעיות האבטחה של Log4j הפכו משתמשים רבים ברשת על פיה וזה אחד הפגמים שניצלו הכי הרבה ושמומחים רבים תייגו אותו כ"המסוכנים ביותר ב- זמן רב », מבין הפגיעויות שהתפרסמו ברשת אנחנו מדברים על חלק מהן כאן בבלוג והפעם מצאנו את החדשות של אחר.
וזהו לפני כמה ימים פורסמה הידיעה כי זוהתה פגיעות נוספת בספריית Log4j 2 (שכבר רשום תחת CVE-2021-45105) ושבניגוד לשתי הבעיות הקודמות, סווג כמסוכן, אך לא קריטי.
הבעיה החדשה מאפשר מניעת שירות ומתבטא בצורה של לולאות והפסקות חריגות בעת עיבוד קווים מסוימים.
פגיעות משפיע על מערכות המשתמשות בחיפוש הקשר, כגון $ {ctx: var}, כדי לקבוע את פורמט פלט היומן.
לאס ל-Log4j גרסאות 2.0-alpha1 עד 2.16.0 חסרה הגנה מפני רקורסיה בלתי מבוקרת, מה אפשר לתוקף לתפעל את הערך המשמש בהחלפה לגרום ללולאה אינסופית שיגמר לו מקום בערימה ותגרום לתהליך להיתקע. בפרט, הבעיה התרחשה בעת החלפת ערכים כגון "$ {$ {:: - $ {:: - $$ {:: - j}}}}".
בנוסף, ניתן לציין כי חוקרי Blumira הציעו מתקפה על יישומי Java פגיעים שאינם מקבלים בקשות מרשתות חיצוניות, למשל, ניתן לתקוף מערכות של מפתחים או משתמשי יישומי Java בצורה זו.
המהות של השיטה היא שאם יש תהליכי Java פגיעים במערכת של המשתמש שמקבלת חיבורי רשת רק מהמארח המקומי (localhost), או מעבדות בקשות RMI (Remote Method Invocation, יציאה 1099), ניתן לבצע את ההתקפה על ידי קוד JavaScript המופעל כאשר המשתמש פותח דף זדוני בדפדפן. כדי ליצור חיבור ליציאת הרשת של אפליקציית Java במתקפה כזו, נעשה שימוש ב-WebSocket API, שעליו, בניגוד לבקשות HTTP, לא מוחלות הגבלות על אותו מקור (ניתן להשתמש ב-WebSocket גם לסריקת יציאות רשת על המקומית מארח כדי לקבוע מנהלי התקנים זמינים ברשת).
התוצאות של הערכת הפגיעות של הספריות הקשורות לתלות ב-Log4j שפורסמה על ידי Google הן גם מעניינות. לפי גוגל, הבעיה משפיעה על 8% מכל החבילות במאגר המרכזי של Maven.
בפרט, 35863 חבילות Java הקשורות ל-Log4j עם תלות ישירה ועקיפה נחשפו לפגיעויות. בתורו, Log4j משמש כתלות ישירה של הרמה הראשונה רק ב-17% מהמקרים, וב-83% מהחבילות המכוסות על ידי הפגיעות, הקישור מתבצע באמצעות חבילות ביניים התלויות ב-Log4j, כלומר. תלות של הרמה השנייה והגבוהה (21% - הרמה השנייה, 12% - השלישית, 14% - הרביעית, 26% - החמישית, 6% - השישית).
קצב תיקון הפגיעות עדיין משאיר הרבה מה לרצות, שבוע לאחר זיהוי הפגיעות, מתוך 35863 חבילות שזוהו, הבעיה תוקנה עד כה רק ב-4620, כלומר ב-13%.
שינויי חבילה נחוצים כדי לעדכן את דרישות התלות ולהחליף את כריכת הגרסה הישנה בגרסאות קבועות של Log4j 2 (חבילות ג'אווה מתרגלות כריכה לגרסה ספציפית, ולא לטווח פתוח המאפשר התקנה של הגרסה העדכנית ביותר).
ביטול הפגיעות ביישומי Java נפגע מהעובדה שתוכנות כוללות לרוב עותק של הספריות במסירה, ואין זה מספיק לעדכן את גרסת Log4j 2 בחבילות המערכת.
בינתיים, הסוכנות האמריקאית להגנה על תשתיות ואבטחת סייבר הוציאה הוראת חירום המחייבת סוכנויות פדרליות לזהות מערכות מידע המושפעות מהפגיעות של Log4j ולהתקין עדכונים שחוסמים את הבעיה. לפני ה-23 בדצמבר.
מנגד, ניתנה הנחיה עד 28 בדצמבר, במסגרתה חלה על הארגונים חובת דיווח על העבודות שבוצעו. כדי לפשט את הזיהוי של מערכות בעייתיות, הוכנה רשימת מוצרים שבהם אושרה ביטוי של פגיעות (ברשימה יש יותר מ-23 אלף פניות).
לבסוף, ראוי להזכיר שהפגיעות תוקנה ב-Log4j 2.17 שפורסם לפני מספר ימים ולמשתמשים שהעדכונים מושבתים מומלץ לבצע את העדכון המתאים, בנוסף לעובדה שהסכנה של הפגיעות מתמתנת על ידי העובדה שהבעיה מתבטאת רק במערכות עם Java 8.
מקור: https://logging.apache.org/