דוגמה: זיהוי ניצול לרעה של פרצות אבטחה ב-Log4Shell

נקודות החולשה באבטחה CVE-2021-44228 ו-CVE-2021-45046 נחשפו בספריית Apache Log4j בגרסאות 2.0 עד 2.15. הכלי Apache Log4j הוא רכיב נפוץ לרישום בקשות. נקודת החולשה הזו, שנקראת גם Log4Shell, יכולה לאפשר פריצה למערכת שפועלת בה גרסה 2.0 עד 2.15 של Apache Log4j, ולאפשר לתוקף להריץ קוד שרירותי.

הפגיעות הזו לא משפיעה על Cloud Logging או על הסוכנים שהוא מספק לאיסוף יומנים מאפליקציות של צד שלישי, אבל אם אתם משתמשים ב-Log4j 2, יכול להיות שהשירותים שלכם יושפעו.

אפשר להשתמש ב-Logging כדי לזהות מתקפות אפשריות. במאמר הזה נסביר איך:

  • כדי לראות ניסיונות קיימים לנצל את הפגיעות ב-Log4j 2, שולחים שאילתות ליומנים באמצעות Logs Explorer.
  • מוודאים ששיטות ההגנה שהפעלתם, כמו מדיניות האבטחה של 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.

אתם יכולים להשתמש בכלי לבדיקת יומנים כדי לזהות מתקפות פוטנציאליות על השירות שלכם שמנצלות את הפגיעות ב-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, לוחצים על ערך השדה ברשומה תואמת ביומן ובוחרים באפשרות הוספת השדה לחלונית Logs fields, כמו שמוצג בצילום המסך הבא:

מוסיפים את השדה remoteIp לחלונית Log fields (שדות יומן) כדי לזהות את כתובות ה-IP ששולחות את רוב הבקשות התואמות.

עכשיו אפשר לראות את כתובות ה-IP המרוחקות המובילות ששולחות בקשות תואמות בחלונית Log fields (שדות יומן):

כתובות ה-IP שצריך להסיר מופיעות בכלי Logs Explorer.

כך תוכלו לראות מאיפה מגיעות הסריקות האלה של ניצול נקודות החולשה של Log4j 2. יכול להיות שחלק מהסריקות האלה הן סריקות לגיטימיות מכלי לסריקת פגיעויות באפליקציות שהגדרתם, כמו Web Security Scanner. אם אתם משתמשים ב-Web Security Scanner מתוך Security Command Center, כדאי לשים לב לטווחים של כתובות IP סטטיות שבהם נעשה שימוש ב-Web Security Scanner.

חיפוש אפליקציות ממוקדות ואימות של טכניקות להפחתת הסיכון

כדאי גם לצבור נתונים על האפליקציות המטורגטות ולבדוק אם בקשות זדוניות הגיעו לאפליקציות שלכם. אם הפעלתם טכניקות להפחתת סיכונים באמצעות מדיניות אבטחה של Cloud Armor או בקרת גישה באמצעות Identity-Aware 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.

עכשיו אפשר לראות פירוט של אופן הטיפול בבקשות בחלונית שדות היומן:

השירותים לקצה עורפי שהכי הרבה מטרגטים אותם מופיעים בכלי Logs Explorer

בדוגמה הזו, רוב הבקשות נחסמו על ידי IAP. כשה-IAP מופעל בשירות לקצה העורפי, הוא מאמת את זהות המשתמש ואת הקשר השימוש לפני שהוא מאפשר גישה. הבקשות האלה לחסימת רכישות מתוך האפליקציה כוללות את הערך statusDetails שמוגדר כ-handled_by_identity_aware_proxy. בנוסף (או לחלופין), אם משתמשים ב-Cloud Armor עם כללי מדיניות האבטחה הנכונים שמצורפים לשירות לקצה העורפי, כל הבקשות שנחסמות על ידי Cloud Armor מוגדרות כ-statusDetails עם הערך denied_by_security_policy. פרטים על אופן ההחלה של כלל ה-WAF החדש שהוגדר מראש cve-canary על מדיניות האבטחה של Cloud Armor מופיעים במאמר Google Cloud Armor WAF rule to help mitigate Apache Log4j vulnerability.

כדי לסנן את כל הבקשות המורשות שמגיעות בפועל לשירות לקצה העורפי, בוחרים באפשרות response_sent_by_backend בקטע statusDetails בחלונית Log fields. כדאי להפעיל IAP בשירותי ה-Backend האלה ולהחיל כללי מדיניות אבטחה של Cloud Armor עם כלל ה-WAF שהוגדר מראש cve-canary כדי לחסום את ניסיונות הניצול האלה.

יצירת מדיניות התראות שמבוססת על יומן

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

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

יצירת מדיניות התראות למדד מבוסס-יומן

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

  1. יוצרים מדד מבוסס-יומן כדי לספור את המקרים של מחרוזות ניצול פוטנציאליות ביומנים. לדוגמה, אפשר להשתמש ב-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)"'

    מידע נוסף על יצירת מדדים מבוססי-יומן זמין במאמר הגדרת מדדי מונה.

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

המאמרים הבאים