כבר עברו למעלה מ-6 שבועות, ב-9 בדצמבר 2021 התגלתה חולשת האבטחה בספריית הקוד Log4j. למי שלא בילה את כל סוף השבוע שאחרי הגילוי במשרד (ואולי גם את זה שאחריו) כדי לעדכן גרסה, נזכיר כי החולשה התגלתה במקרה, כשבמיינקראפט נעשה שימוש בספרייה זו לצורך רישום פעולות בקבצי LOG. החולשה דווחה לקהילה, נבחנה, ופורסמה עם רמת החומרה הגבוהה ביותר – 10 מתוך 10. הפאניקה היתה במקומה: חולשה ברמת חומרה כמו זו לא דווחה מזה שנים. הסיבה לחומרה הגבוהה הייתה כפולה: יכולת ניצול קלה למדי מצד אחד, ומצד שני הרצה של כל פקודה רצויה בצד המשתמש ברכיב Log4j בגרסה המכילה את החולשה.
עיקר הבעיה נבעה מכך שרכיב הקוד הפתוח Log4j הוא פופולרי מאוד. הרכיב קיים למעשה בשליש משרתי האינטרנט בעולם ומשמש כרכיב משנה של למעלה מ-7,000 תוכנות קוד פתוח אחרות. המספרים המדויקים אינם ניתנים למדידה אבל קצב של 30 מיליון הורדות בארבעת החודשים האחרונים, ממחיש את גודל השימוש.
החולשה נוצלה לכריית קריפטו
ביום שישי, 10 בדצמבר, קרא מערך הסייבר הלאומי לכל משתמשי ספריית Log4j בגרסאות המכילות את החולשה, אשר נמצאות בשימוש מאז שנת 2013, לשדרג באופן בהול לגרסה עדכנית של הספרייה אשר התפרסמה יחד עם ההתראה. מחול השדים יצא לדרך: האקרים זריזים הפיצו אלפי תוכנות לכריית מטבעות קריפטו במטרה לנצל יכולת העיבוד של מערכות מחשב המשתמשות בספריית Log4j, ומצד שני אלפי עובדים בחברות תוכנה הגיעו למשרדים במהלך סוף השבוע כדי לעדכן את ספריית Log4j לגרסה התקינה, במטרה למנוע מאותם האקרים זריזים לממש את החולשה.
האקרים תמיד מנסים להיות צעד אחד לפני מערכות ההגנה. מצד ההתקפה ידוע כי כבר בשלושת הימים הראשונים נעשה שימוש בכ-60 מוטציות של נוזקות המנצלות את חולשת Log4j בצורות שונות. נוסף על השימוש בחולשה לכריית מטבעות קריפטו, רשת המחשוב של הצבא הבלגי נפרצה והושבתו בה מערכות מרכזיות, וכן גוף פינטק במזרח הרחוק הותקף והושבת על ידי כופרה שהושתלה ברשת הארגונית בחסות השימוש ב-Log4j.
קהילת המתחזקים של Log4j מנתה עד אותו אירוע כארבעה מפתחים פעילים, שתחזקו את הפרויקט בזמנם החופשי וללא תמורה. התרומה הכספית הגדולה ביותר לפרויקט עד לדיווח החולשה עמדה על כ-500 דולר
קהילת המתחזקים של Log4j מנתה עד אותו אירוע כארבעה מפתחים פעילים, שתחזקו את הפרויקט בזמנם החופשי וללא תמורה. התרומה הכספית הגדולה ביותר לפרויקט עד לדיווח החולשה עמדה על כ-500 דולר (לרוב חברות תורמות לפרויקטים אותם הן רואות כחשובים, במטרה לשמר את קהילת המתחזקים. עד 9.12 זה לא היה המקרה).
פרסום החולשה החמורה ברכיב הפופולרי הביא להרחבה מיידית של הקהילה (אשר מונה כעת 123 מתחזקים רשומים), שמצאה חולשה חדשה גם בגרסה התקינה לכאורה, ושלושה ימים בלבד לאחר פרסום החולשה והגרסה המתוקנת פורסמה גרסה נוספת – וכל אותם עובדים אשר זה עתה סיימו סופ"ש של עדכונים נאלצו להתחיל הכל מחדש. אם אתם קוראים את tech12 כנראה שאתם גם יודעים שהסאגה הזו קרתה שוב כעבור כמה ימים נוספים ואז פעם נוספת (נכון לשעת כתיבת שורות אלה).
אז מי אשם?
חוק מספר אחת: חפש את מי להאשים. אבל את מי? את קהילת המפתחים שמתחזקת את ספריית Log4j ללא תמורה ובזמנם החופשי? ברישיון הקוד הפתוח כתוב מפורשות "Is Given As Is". יכול להיות שהאחריות היא של מי שאימץ את הספרייה? ושל מי האחריות לבדוק איפה נמצאת כל ספריית Log4j, בין עשרות התוכנות בארגון, בין עשרות הגרסאות שהופצו ללקוחות – האם זו אחריותו של כל מנהל מוצר באופן פרטני, או שקהילת המתחזקים אמורה לתחזק גם שירות לקוחות? ומה אם אני "סתם" לקוח של חברת תוכנה, שלא פתחה חדר מצב לעדכון הלקוחות, שגם לא עונים למיילים – הרי עכשיו סופ"ש, ותמיד האירועים האלה קורים בסופ"ש – אבל אם אחכה עד יום שני יש מצב שאצטרף לסטטיסטיקה? איך אני בודק במוצר – שלא אני כתבתי! – אם יש בו Log4j?
עוד לפני אירוע ה-Log4j לממשל האמריקאי נמאס מהסלט הרגולטורי הזה, ובמאי 2021 פורסם צו נשיאותי של הבית הלבן הקורא לשקיפות בשרשרת אספקת התוכנה, כשלוחות הזמנים ליישום הצו מדברים על אמצע 2022. מה זה אומר בפועל? חברות שירצו למכור תוכנה לגופים פדרליים יצטרכו לתת ביחד עם התוכנה קובץ המפרט את רשימת רכיבי המשנה ממנה בנויה התוכנה (ממש כמו רשימת הרכיבים שעל קופסת הקורנפלקס המפרטת כמה סוכר, שומן רווי, חיטה וכו').
חברות שירצו למכור תוכנה לגופים פדרליים יצטרכו לתת ביחד עם התוכנה קובץ המפרט את רשימת רכיבי המשנה ממנה בנויה התוכנה (ממש כמו רשימת הרכיבים שעל קופסת הקורנפלקס)
בשפה המקצועית קוראים לקובץ הזה SBOM, ראשי תיבות של Software Bill of Materials. כלומר, אם אני רוצה לדעת האם יש Log4j במוצר X אני בודק את ה-SBOM שיש לי כבר ביום שישי - ולא מחכה לספק שיענה לי במייל בשלב שעלול להיות מאוחר מדי עבורי. גם לשכת הסחר הפדרלית (FTC) לא נשארה אדישה לכאוס שחולשת Log4j יצרה ושחררה הודעה רשמית שיפעילו את מלא כוחם כנגד חברות שלא ייקחו אחריות ויתקנו את החולשות ברכיבי הקוד הפתוח (ולא רק Log4j).
לאן הולכת מכאן קהילת הקוד הפתוח?
המסקנה הראשונה היא שחברות הבינו בדרך הקשה שקהילת הקוד הפתוח צריכה תמיכה (כספית, עזרה בתחזוקת הספריות, בדיקות איכות וכו'). תם עידן "אמץ קוד פתוח כפי יכולתך", ואז תבוא בטענה אל הקהילה אם משהו משתבש. בתקופה האחרונה נראו חברות שתרמו אלפי דולרים לפרויקט של Log4j, כאלה שכלל לא השתמשו בספרייה ועשו זאת רק מתוך סולידריות לקהילה.
המסקנה הראשונה היא שחברות הבינו בדרך הקשה שקהילת הקוד הפתוח צריכה תמיכה. תם עידן "אמץ קוד פתוח כפי יכולתך", ואז בוא בטענה אל הקהילה אם משהו משתבש
נוסף על כך, מעתה הסכמי רכש של תוכנה יכללו סעיפים סטנדרטיים במסגרתם אחריות יצרן התוכנה בנוגע לקוד הפתוח תוסדר באופן ברור, לרבות דיווח על חולשות ותיקונן בתוך זמן סביר. כמו כן, לא עוד "תוכנה כקופסה שחורה": חברות הצורכות תוכנה כחלק משרשרת אספקת התוכנה שלהן ידרשו לקבל SBOM כדי לנהל בעצמן תוכנות קריטיות לתפקודן. חשוב לציין שכבר היום ישנם מספר תקני ISO העוסקים בניהול ושקיפות שימוש בקוד פתוח (ISO/IEC 5230:2020, ISO/IEC 5962:2021) כך שהדרך אל השקיפות והאמון בין יצרני התוכנה ולקוחותיהם עוברת למסלול של ניהול נכון והתראות בזמן אמת.
הכותב: צביקה רונן הוא שותף מייסד והCTO של חברת FOSSAware, חברת ייעוץ ושירותים לניהול סיכוני שימוש בקוד פתוח