Log4Shell, פגיעות אינטרנט, השפיעה לאחרונה על מיליוני מכונות. Log4j, תוכנה לא ברורה אך כמעט בכל מקום, גורמת לכך.
Log4j משמש לתיעוד כל הפעולות המתרחשות מאחורי הקלעים במגוון מערכות מחשב.
הוא מבוסס על ספריית רישום בקוד פתוח המשמשת עסקים ואפילו ארגונים ממשלתיים ברוב היישומים.
בהיותו אחד מפרקי אבטחת הסייבר הגרועים ביותר שנחשפו אי פעם, חיוני להגן על המערכות שלך מפני הפגיעות הזו. אבל איך?
בואו נחקור את הפגיעות של Log4j בפירוט ואת כל פתרונות התיקון האפשריים עבורה.
מה זה Log4j?
Log4j הוא an קוד פתוח מסגרת רישום המאפשרת למפתחי תוכנה להקליט נתונים שונים בתוך האפליקציות שלהם. זהו מרכיב בפרויקט Apache Loging Services, המנוהל על ידי קרן אפאצ 'י תוכנה.
מאות אתרים ואפליקציות משתמשים ב-Log4j כדי לבצע פעולות קריטיות כמו רישום נתונים לצורך ניפוי באגים ושימושים אחרים.
כאשר אתה מזין או לוחץ על קישור מקוון גרוע ומקבל הודעת שגיאה 404, זו דוגמה תכופה של Log4j בעבודה. שרת האינטרנט המריץ את הדומיין של קישור האינטרנט שאליו ניסית לגשת מודיע לך שלא קיים דף אינטרנט כזה. זה גם רושם את האירוע ב-Log4j עבור מנהלי המערכת של השרת.
בכל תוכנות, אותות אבחון דומים משמשים. במשחק המקוון Minecraft, למשל, השרת משתמש ב-Log4j לתיעוד פעילות כגון זיכרון RAM הכולל בשימוש והוראות משתמש שנשלחו לקונסולה.
כיצד מתרחשת הפגיעות?
חיפושים הם תכונה חדשה שהוצגה ב-Log4j 2.0, שעוזרת לשלב מידע נוסף בערכים ביומן. אחד מהחיפושים הללו הוא בדיקת JNDI (Java Naming and Directory Interface), שהוא ממשק API של Java לתקשורת עם שירות ספריות.
באמצעות גישה זו, ניתן למפות מזהי משתמש פנימיים לשמות משתמשים בפועל. שאילתה זו חושפת את הפגיעות החדשה של RCE שהתגלתה, מכיוון שאחד מסוגי הנתונים המסופקים על ידי שרת LDAP הוא URI המצביע על מחלקה של Java, אשר לאחר מכן נטען לזיכרון ומופעל על ידי מופע Log4j.
עקב חולשה באימות הקלט של ספריית Log4j, ניתן להחדיר שרת LDAP שרירותי ממקור לא מהימן. מכיוון שמפתחים מניחים שהנתונים הנשלחים ליומנים יטופלו כטקסט רגיל, לא מתבצע אימות קלט נוסף, וקלט משתמש מסוכן נכנס ליומנים.
הצהרת יומן עשויה להיראות כך:
משתמש זדוני יוסיף כעת בדיקת JNDI המתייחסת לשרת LDAP נוכל בפרמטר של כתובת URL. בדיקת JNDI תהיה כדלקמן:
לאחר מכן, ספריית Log4j מדברת עם שרת LDAP זה ב-attacker.com כדי לקבל מידע על ספריות, כולל ערכים עבור Java Factory ו-Java Codebase.
שני ערכים אלו כוללים את מחלקת ה-Java של התוקף, הנטענת לזיכרון ומבוצעת על ידי המופע של Log4j, ומשלים את ביצוע הקוד.
מי נמצא בסיכון?
הפגיעות של Log4j היא רחבה להפליא, ומשפיעה על יישומים עסקיים, התקנים משובצים ותתי המערכות שלהם. האפליקציות המושפעות כוללות Cisco Webex, Minecraft ו-FileZilla FTP.
עם זאת, אין מדובר ברשימה שלמה. הפגם אפילו משפיע על משימת הצ'ופר של Ingenuity Mars 2020, המשתמשת ב- Apache Log4j עבור הקלטת אירועים.
קהילת האבטחה ערכה א רשימה של מערכות פגיעות. חשוב לציין שרשימות אלו מתעדכנות ללא הרף, כך שאם תוכנית או מערכת מסוימת אינה מוצגת, אל תניח שהיא לא מושפעת.
חשיפה לפגיעות זו היא די סבירה, ואפילו אם ספציפית מחסנית טק אינו מחיל Java, מנהלי אבטחה צריכים לצפות ממערכות ספקים קריטיות, ספקי SaaS, ספקי אירוח בענן וספקי שרתי אינטרנט לעשות זאת.
כיצד לבדוק פגיעות של Log4j?
הצעד הראשון הוא לקבוע אם כבר התרחשה תקיפה. אתה יכול לעשות זאת על ידי בדיקת יומני המערכת עבור שברי מטען RCE.
אם חיפוש אחר מונחים כמו "jndi", "ldap" או "$::" מניב יומנים כלשהם, חוקרי אבטחה צריכים לחקור יותר כדי לראות אם זו הייתה התקפה לגיטימית או רק טביעת אצבע.
התגלו תקיפות רבות בטבע שלא סיפקו מטענים מזיקים. למרות זאת, הם בוצעו על ידי מומחי אבטחה כדי לקבוע כמה אפליקציות היו פגיעות להתקפה זו.
השלב הבא הוא להשתמש בספריית Log4j כדי לזהות את כל הפרויקטים. אם נעשה שימוש בגרסאות בין 2.0-beta9 ל-2.14.1, הפרויקט יכול להיות רגיש.
בהתחשב בקושי לקבוע היכן קיימת פגיעות זו, יכול להיות עדיף להניח שהפרויקט רגיש וכי עדכון הספרייה הוא דרך הפעולה הטובה ביותר להסרת הסכנה של ביצוע קוד.
הפרויקט אינו פגיע אם הגרסה המשומשת היא פחות מ-2.0 בטא 9, אם כי עדיין יש לשדרג את ספריית Log4j מכיוון שגרסאות בטווח 1.x ישנות ואינן מקבלות עוד עדכונים.
בין אם מתגלה פרויקט רגיש, מומלץ לבדוק אותו כדי לראות אם מידע כלשהו שנרשם באמצעות Log4j מכיל מידע שהמשתמש יכול לשנות. כתובות אתרים, פרמטרי בקשות, כותרות וקובצי Cookie הם דוגמאות לנתונים אלו. אם אחד מאלה מתועד, הפרויקט בסכנה.
ידע זה יכול לעזור לך להתעמק ביומני המערכת ולקבוע אם יישום האינטרנט שלך כבר הותקף.
ישנם כלים מקוונים בחינם שיכולים לזהות אם יישום אינטרנט פגיע. אחת מהתוכניות הללו היא ציידת Log4Shell. זה קוד פתוח וזמין ב GitHub.
אם מתגלה אזור קוד פגיע באפליקציה המקוונת, ניתן להשתמש במטען המסופק על ידי הכלי שנחשף כדי להחדיר אותו לאפליקציית האינטרנט. כלי הבדיקה יחשוף את החיבורים שנוצרו בין יישום האינטרנט שלך לשרת ה-LDAP שלהם אם הפגיעות נוצלה.
פתרונות לתיקון פגיעות Log4j
הצעד הראשון הוא לעדכן את Log4j, מה שאתה יכול לעשות על ידי שימוש במנהלי החבילות הרגילים או על ידי הורדה ישירות מכאן עמוד.
אפשר גם להקטין את יכולת הניצול של הפגיעות על ידי הגדרת משתנה הסביבה FORMAT MSG NO LOOKUPS ל-true. עם זאת, אמצעי נגד זה חל רק על גרסאות Log4j הגדולות או שווה ל-2.10.
הבה נבחן כעת אפשרויות חלופיות.
1. דרכים לעקיפת הבעיה עבור Log4j גרסה 2.17.0
בהחלט מומלץ מאוד להשתמש ב-Log4j גרסה 2.15.0 כדי להגן מפני Log4Shell, עם זאת, אם זה לא אפשרי, פתרונות אחרים זמינים.
גרסאות 2.7.0 ואילך של Log4j: ניתן להגן מפני כל התקפה על ידי שינוי פורמט האירועים לרישום באמצעות תחביר האחוזים של nolookups עבור הנתונים שסופקו על ידי המשתמש. עדכון זה דורש עריכת קובץ התצורה של Log4j כדי ליצור גרסה חדשה של התוכנית. כתוצאה מכך, לפני פריסת גרסה חדשה זו, יש לחזור על שלבי האימות הטכני והפונקציונלי.
Log4j גרסאות 2.10.0 ואילך: אפשר גם להגן מפני כל התקפה על ידי הגדרת פרמטר התצורה log4j2.formatMsgNoLookups ל-true, למשל, בעת הפעלת המחשב הוירטואלי של Java עם אפשרות -Dlog4j2." formatMsgNoLookups = true, אפשרות נוספת היא להסיר את המחלקה JndiLookup מהארגומנט classpath, מה שיסיר את וקטור ההתקפה הראשי (החוקרים לא שוללים אפשרות של וקטור התקפה נוסף).
שירותי האינטרנט של אמזון מספקים תיקון חם ש"צריך להשתמש בו על אחריותך בלבד". "טכניקות" אחרות, כמו Logout4Shell, ש"משתמשת בפגיעות זו נגד עצמה", פורסמו. מומחה האבטחה מטיל ספק בחוקיות המהלך הזה, הכולל "פריצה למכונה כדי לתקן אותו".
2. הבעיה נפתרה ב-Log4j v2.17.0.
עבור גרסאות גדולות מ-2.10: Log4j2.formatMsgNoLookups צריך להיות מוגדר כ-true.
עבור גרסאות 2.0 עד 2.10.0: הפעל את הפקודה הבאה כדי להסיר את מחלקת LDAP מ-Log4j.
Log4j2.formatMsgNoLookups צריך להיות מוגדר כ-true בהגדרות המערכת.
הקלה ב-JVM
הפחתה עם פרמטרי JVM כבר אינה אופציה. שיטות מקלות אחרות ממשיכות להצליח. שדרג לגרסה 4 של Log2.17.0j במידת האפשר. יש מדריך הגירה זמין עבור Log4j v1.
אם עדכון אינו אפשרי, ודא שלרכיבי צד הלקוח וצד השרת יש את ערכת המאפיין -Dlog4j2.formatMsgNoLookups = true system.
שימו לב ש-Log4j v1 הגיע לסוף חייה (EOL) ולא יקבל עוד תיקוני באגים. וקטורי RCE אחרים רגישים גם ל-Log4j v1. לפיכך, אנו קוראים לך לשדרג ל-Log4j 2.17.0 בהקדם האפשרי.
3. אמצעי הפחתה
ניצול נוכחי לא יכול לעבוד גם אם Log4j רגיש במקרים מסוימים, כגון אם המחשב המארח מריץ גרסת Java גבוהה מ-6u212, 7u202, 8u192 או 11.0.2.
זה נובע מהגנה טובה יותר על טעינת מחלקות מרחוק של Java Naming and Directory Interface (JNDI) בגרסאות הנוכחיות, אשר נחוצה כדי שהמתקפה תפעל.
יתר על כן, עם גרסאות Log4j גדולות מ-2.10, ניתן להימנע מהבעיה על ידי הגדרת ערך המערכת formatMsgNoLookups ל-true, מתן הארגומנט JVM -Dlog4j2.formatMsgNoLookups = true, או מחיקת המחלקה JndiLookup מ-classpath.
בינתיים, עד לתיקון המופעים הפגיעים, ניתן לטפל בפגיעות באמצעות הטכניקות שלהלן:
- הגדר את מאפיין המערכת log4j2.formatMsgNoLookups ל-true עבור >=2.10.
- הגדר את אפשרות הסביבה LOG4J FORMAT MSG NO LOOKUPS ל-true עבור >=2.10.
- הסר את JndiLookup.class מה-classpath עבור 2.0-beta9 עד 2.10.0: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
אחת השיטות המומלצות היא להגביל תעבורת יציאה לאינטרנט ליציאות המתאימות בלבד.
למרות שרוב ההתקפות בשטח מועברות באמצעות HTTP, הפגיעות עשויה להיות מנוצלת באמצעות כל פרוטוקול שמתעד נתוני קלט משתמש באמצעות Log4j.
עם זאת, עדכון ל-log4j 2.17.0 הוא התרופה הטובה ביותר מכיוון שמישהו יכול לגלות גישה נוספת לבעיה. יתר על כן, הרבה מפרסמים ויצרנים הכריזו על שיפורים בשירותים או באפליקציות שלהם.
4. תיקון פגיעות של Log4Shell
Log4j נמצא בכל מקום, במיוחד עכשיו כשהפגיעות מנוצלת. לסיכום, כל מה שאתה צריך לעשות הוא לכלול את התווים הבאים ביומנים שנבדקו על ידי Log4j.
וזה יוריד ויבצע את קובץ ה-Java שנמצא בסוף ה-URL. זה פשוט כמו שזה דרמטי.
כפי שאתה מודע, חיוני לשדרג את log4j לגרסה >= 2.17.0 כדי לתקן פגיעות זו של Log4Shell (CVE-2021-44228).
אם זה לא אפשרי:
עבור יישומים המשתמשים בספריית Log4j בגרסאות 2.10.0 ואילך, ניתן גם להגן מפני כל התקפה על ידי הגדרת פרמטר התצורה log4j2.formatMsgNoLookups ל-true, למשל, תוך הפעלת המחשב הוירטואלי של Java עם ה-Dlog4j2.formatMsgNoLookups = true אוֹפְּצִיָה.
אפשרות נוספת היא למחוק את המחלקה JndiLookup מהארגומנט classpath, מה שיסיר את וקטור ההתקפה הראשי (החוקרים לא שוללים קיומו של וקטור התקפה נוסף).
הערות
ארגונים אשר מהססים או אינם מוכנים לבצע התאמות למערכות רגישות (או שרוצים להתקין אמצעי הגנה נוספים) צריכים לחשוב על:
- ודא שכל התעבורה מנותבת דרך iSensor/WAF/IPS. זה יכול למנוע מהתקיפה לקבל גישה למערכת.
- הגבלת כמות התעבורה שיכולה להגיע למערכת הרגישה אם המערכת לא צריכה להיות מחוברת לאינטרנט, הגבל את הגישה רק ל-IPS וטווחים חיוניים ומהימנים.
- צמצום התעבורה היוצאת המורשית של המארח. מכיוון שמתקפה זו פועלת על ידי התחברות לשרת נוכל, יש לחסום את כל כתובות ה-IP והיציאות המיותרות בחומת אש.
- אם השירות אינו נדרש עוד, יש להשבית אותו עד שהתיקון מוכן.
סיכום
הפגמים ב-Log4j זעזעו את הקהילה שלנו והזכירו לכולנו עד כמה אנחנו תלויים בתוכנת קוד פתוח.
Log4j הוא ייחודי. זו לא מערכת הפעלה, גם לא דפדפן וגם לא תוכנה. במקום זאת, זה מה שמתכנתים מתייחסים אליו כאל ספרייה, חבילה או מודול קוד. זה רק משרת מטרה אחת, כלומר לשמור תיעוד של מה שקורה בשרת.
אנשים שכותבים קוד מעדיפים להתרכז במה שמייחד את התוכנה שלהם. הם לא מעוניינים להמציא את הגלגל מחדש. כתוצאה מכך, הם מסתמכים על שפע של ספריות קוד קיימות, כגון Log4j.
מודול Log4j נגזר מ-Apache, תוכנת שרת האינטרנט הנפוצה ביותר. לכן ניתן לגלות אותו במיליוני שרתים. לפיכך, הגדלת איומי האבטחה.
אני מקווה שהפתרונות לעיל יעזרו לך לשמור על בטיחות המכשירים שלך.
הישאר מעודכן אל HashDork לקבלת מידע מועיל נוסף מעולם הטכנולוגיה.
השאירו תגובה