התגלו נקודות חולשה באבטחה CVE-2021-44228 ו-CVE-2021-45046 בספריית Apache Log4j בגרסאות 2.0 עד 2.15. הכלי Apache Log4j הוא רכיב נפוץ לרישום בקשות. נקודת החולשה הזו, שנקראת גם Log4Shell, עלולה לאפשר פריצה למערכת שבה פועל Apache Log4j מגרסה 2.0 עד 2.15, ולאפשר לתוקף להפעיל קוד שרירותי.
הפגיעות הזו לא משפיעה על Cloud Logging או על הסוכנים שהוא מספק לאיסוף יומנים מאפליקציות של צד שלישי, אבל אם אתם משתמשים ב-Log4j 2, יכול להיות שהשירותים שלכם יושפעו.
אפשר להשתמש ב-Logging כדי לזהות מתקפות אפשריות. במסמך הזה נסביר איך:
- אפשר להשתמש ב-Logs Explorer כדי לשלוח שאילתות ליומנים ולחפש ניסיונות קיימים לנצל את נקודת החולשה ב-Log4j 2.
- מוודאים ששיטות ההגנה שהפעלתם, כמו מדיניות האבטחה של Cloud Armor ובקרת הגישה של שרת proxy לאימות זהויות (IAP), מוגדרות בצורה נכונה ופועלות כמצופה על ידי חסימת ניסיונות הניצול האלה של Log4j 2.
- יצירת מדיניות התראות כדי לקבל התראה כשנרשם ביומנים הודעה על ניצול פוטנציאלי של פרצה.
כדאי לעיין ב Google Cloudהמלצות האבטחה של Log4j 2 בנוגע להערכת המוצרים והשירותים הנוכחיים של Google Cloud . כדי להעריך את רמת החשיפה, אפשר לקרוא את דוח נקודת החולשה של המכון הלאומי לתקנים וטכנולוגיה (NIST) בנושא CVE-2021-44228.
זיהוי רישום
תוצאות השאילתה של רישום ביומן כוללות רק יומנים שכבר אוחסנו במאגרי יומנים, וגם נמצאים במסגרת מגבלות השמירה שצוינו על ידי המשתמש. רוב השירותים של Google Cloud כוללים יומנים שמופעלים כברירת מחדל, אבל יומנים שהושבתו או לא נכללו לא נכללים בשאילתות. מומלץ להפעיל את היומנים בכל הסביבה כדי להרחיב את הנראות של הסביבה.
אם אתם משתמשים במאזן עומסים מסוג HTTP(S), אתם צריכים להפעיל את רישום היומן כדי שיומני הבקשות יהיו זמינים ב-Logging. באופן דומה, אם יש לכם שרתי אינטרנט כמו Apache או NGINX שפועלים במכונה וירטואלית, אבל לא התקנתם את סוכן תפעול או את סוכן Logging, לא תהיה לכם גישה ליומנים האלה ב-Logging.
שאילתת היומנים
אתם יכולים להשתמש בLogs Explorer כדי לזהות מתקפות פוטנציאליות על השירות שלכם שמנצלות את נקודת החולשה ב-Log4j 2. אם אתם משתמשים ב-Logging כדי לרשום ביומן בקשות לשירות שלכם, אתם יכולים לבדוק שדות httpRequest עם תוכן שנוצר על ידי משתמשים כדי לזהות ניסיונות ניצול פוטנציאליים.
הערכים בשדות httpRequest עשויים להכיל טוקנים של מחרוזות כמו ${jndi:ldap://, אבל יש הרבה וריאציות של ניצול לרעה של הפגיעות הזו.
לדוגמה, יש הרבה דרכים להשתמש בביטול בריחה או ב-Unicode כדי להימנע מזיהוי.
המחרוזות הבאות מציגות כמה דוגמאות נפוצות שמצביעות על ניסיונות ניצול של המערכת, אבל זו לא רשימה מלאה של וריאציות:
${jndi:
$%7Bjndi:
%24%7Bjndi:
${jNdI:ldAp
${jndi:${lower:l}${lower:d}${lower:a}${lower:p}:
${${lower:j}${lower:n}${lower:d}i:
${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}:
${${env:BARFOO:-j}ndi${env:BARFOO:-:}${env:BARFOO:-l}dap${env:BARFOO:-:}
אתם יכולים ליצור שאילתות ב-Logs Explorer שיסרקו חלק מהמחרוזות האפשריות של ניצול לרעה. לדוגמה, השאילתה הבאה מנסה להתאים וריאציות שונות של המחרוזת ${jndi: שמוסתרות בשדות httpRequest ביומני הבקשות של מאזן עומסים מסוג HTTP(S). חשוב לזכור שהביטויים הרגולריים שמשמשים בשאילתה לא מזהים את כל הווריאציות, ויכול להיות שהם יובילו לתוצאות חיוביות שגויות:
resource.type="http_load_balancer"
httpRequest.requestUrl=~"(?i)(\$|\%24)(\{|\%7b).*j.*n.*d.*i.*(\:|\%3a)" OR
httpRequest.userAgent=~"(?i)(\$|\%24)(\{|\%7b).*j.*n.*d.*i.*(\:|\%3a)" OR
httpRequest.referer=~"(?i)(\$|\%24)(\{|\%7b).*j.*n.*d.*i.*(\:|\%3a)"
אפשר להשתמש בשאילתה הקודמת כדי לסרוק יומני בקשות בשירותים אחרים על ידי שינוי הערך של resource.type.
יכול להיות שייקח הרבה זמן עד שהשאילתה הקודמת תסתיים אם סורקים נפח גדול של יומנים. כדי שהשאילתות יפעלו מהר יותר, אפשר להשתמש בשדות שנוספו לאינדקס כמו resource.type, resource.labels או logName כדי לצמצם את השאילתה לקבוצה של שירותים ספציפיים או לזרמי יומנים.
זיהוי של רשומות תואמות ביומן לא אומר שהייתה פריצה מוצלחת. אם מזוהה משהו, מומלץ לפעול בהתאם לתהליך התגובה לאירועים בארגון. התאמה עשויה להצביע על כך שמישהו בודק את נקודת החולשה בפרויקט או בעומס העבודה כדי לנצל אותה. או שזו יכולה להיות תוצאת שווא חיובית, אם האפליקציה משתמשת בדפוסים כמו ${jndi: בשדות של בקשת ה-HTTP. כדאי לעיין ביומנים כדי לוודא שהדפוס הזה לא משקף התנהגות רגילה של האפליקציה.
משנים את השאילתה כך שתתאים לסביבה שלכם.
חיפוש כתובות IP שמהן נשלחו הודעות פוגעות
אם נמצאו תוצאות תואמות, ואם רוצים לצבור נתונים על כתובות ה-IP המרוחקות ששולחות בקשות כאלה, מוסיפים את השדה remoteIp לחלונית Log fields ב-Logs Explorer. כדי להוסיף את השדה remoteIp, לוחצים על ערך השדה ברשומה תואמת ביומן ובוחרים באפשרות הוספת השדה לחלונית השדות של היומנים, כמו שמוצג בצילום המסך הבא:
עכשיו אפשר לראות את כתובות ה-IP המרוחקות המובילות ששולחות בקשות תואמות בחלונית Log fields:
כך תוכלו לראות מאיפה מגיעות הסריקות של ניצול נקודת החולשה ב-Log4j 2. יכול להיות שחלק מהסריקות האלה הן סריקות לגיטימיות מכלי לסריקת פגיעויות באפליקציות שהגדרתם, כמו Web Security Scanner. אם אתם משתמשים ב-Web Security Scanner מתוך Security Command Center, כדאי לשים לב לטווחים של כתובות IP סטטיות שבהם נעשה שימוש ב-Web Security Scanner.
חיפוש אפליקציות מטורגטות ואימות של טכניקות להפחתת הסיכון
כדאי גם לצבור נתונים על האפליקציות המטורגטות ולבדוק אם בקשות זדוניות הגיעו לאפליקציות שלכם. אם הפעלתם טכניקות להפחתת הסיכון באמצעות מדיניות אבטחה של Cloud Armor או בקרת גישה באמצעות שרת proxy לאימות זהויות (IAP), תוכלו גם לוודא שהן פועלות כמצופה לפי המידע שמתועד ביומני מאזן העומסים של HTTP(S).
קודם כל, כדי להוסיף את האפליקציה הממוקדת לחלונית Log fields, בוחרים אחת מתוצאות רשומות היומן, מרחיבים את resource.labels, לוחצים על ערך השדה resource.labels.backend_service_name ואז בוחרים באפשרות Add field to Logs fields pane.
עכשיו אפשר לראות את האפליקציות או שירותי ה-Backend המובילים שמטורגטים על ידי סריקות של ניצול לרעה של Log4j 2. כדי לדעת אם ניסיונות הניצול האלה הגיעו לשירות הבק-אנד שלכם, אפשר להשתמש בשדה jsonPayload.statusDetails שאוכלס על ידי מאזן עומסים מסוג HTTP(S) כדי לדעת אם הבקשה הועברה באמצעות פרוקסי לבק-אנד, או אם היא נחסמה בהצלחה על ידי שירותים כמו IAP או Cloud Armor. לוחצים על ערך השדה jsonPayload.statusDetails מתוצאת רשומת היומן ובוחרים באפשרות הוספת השדה לחלונית Logs fields.
עכשיו אפשר לראות את פירוט הטיפול בבקשות בחלונית שדות היומן:
בדוגמה הזו, רוב הבקשות נחסמו על ידי IAP. כשהוא מופעל בשירות לקצה העורפי, הוא מאמת את זהות המשתמש ואת הקשר השימוש לפני שהוא מאפשר גישה. בקשות חסומות של רכישות מתוך האפליקציה (IAP) מוגדרות עם הערך statusDetails בתור handled_by_identity_aware_proxy. בנוסף (או לחלופין), אם משתמשים ב-Cloud Armor עם כללי מדיניות האבטחה הנכונים שמצורפים לשירות לקצה העורפי, כל הבקשות שנחסמות על ידי Cloud Armor מוגדרות כ-statusDetails ב-denied_by_security_policy. לפרטים על אופן ההחלה של כלל ה-WAF החדש שהוגדר מראש cve-canary על מדיניות האבטחה של Cloud Armor, אפשר לעיין במאמר כלל WAF של Google Cloud Armor שיעזור לצמצם את נקודת החולשה של Apache Log4j.
כדי לסנן את כל הבקשות המותרות שמגיעות בפועל לשירות לקצה העורפי, בוחרים באפשרות response_sent_by_backend בקטע statusDetails בחלונית Log fields.
כדאי להפעיל IAP בשירותי ה-Backend האלה ולהחיל כללי מדיניות אבטחה של Cloud Armor עם כלל WAF שהוגדר מראש cve-canary כדי לחסום את ניסיונות הניצול האלה.
יצירת מדיניות התראות שמבוססת על יומן
אחרי שתתכננו שאילתה שתמצא את היומנים שהושפעו בשירות שלכם, תוכלו להשתמש בשאילתה הזו כדי ליצור מדיניות התראות שמבוססת על יומנים. המדיניות הזו תשלח לכם התראה כשערכים חדשים ביומן יתאימו לשאילתה. אפשר להעביר תקריות שנוצרו על ידי מדיניות ההתראות למרכז התפעול לאבטחה (SOC) של הארגון או לצוות המתאים לטיפול בתקריות.
מידע על יצירת מדיניות התראות מבוססת-יומן זמין במאמר יצירת מדיניות התראות מבוססת-יומן (Logs Explorer). כשיוצרים את מדיניות ההתראות, חשוב להשתמש בשאילתה שלכם למחרוזת הניצול במקום בשאילתה שצוינה בדוגמה.
יצירת מדיניות התראות למדד מבוסס-יומן
כדי לעקוב אחרי נקודות קצה או שירותים שמתועדים בהם ניסיונות אפשריים לניצול לרעה, יוצרים מדיניות התראות על מדד שמבוסס על יומן:
יוצרים מדד מבוסס-יומן כדי לספור את המקרים של מחרוזות ניצול פוטנציאליות ביומנים. לדוגמה, אפשר להשתמש ב-Google Cloud CLI כדי ליצור מדד כזה:
gcloud logging metrics create log4j_exploits \ --description="Detect log4j exploits" \ --log-filter='httpRequest.requestUrl=~"(?i)(\$|\%24)(\{|\%7b).*j.*n.*d.*i.*(\:|\%3a)" OR httpRequest.userAgent=~"(?i)(\$|\%24)(\{|\%7b).*j.*n.*d.*i.*(\:|\%3a)" OR httpRequest.referer=~"(?i)(\$|\%24)(\{|\%7b).*j.*n.*d.*i.*(\:|\%3a)"'מידע נוסף על יצירת מדדים מבוססי-יומן זמין במאמר הגדרת מדדי מונה.
יצירת מדיניות התראות כדי לקבל התראה כשמגיעים למספר מקרים נבחר. מידע על הגדרת מדיניות התראות זמין במאמר יצירת מדיניות התראות על מדד של מונה.
המאמרים הבאים
כדאי לחזור למסמך הזה כדי לבדוק אם יש מידע חדש.
למידע נוסף על הפגיעות ב-Log4j 2 ועל שירותיGoogle Cloud :