CVE-2024-3094 והדלת האחורית ב-liblzma של XZ Utils: מדוע עדכון שגרתי כמעט הפך למשבר אמון

התשובה המהירה שחיפשת, במילים פשוטות

CVE-2024-3094 אינו באג זיכרון טיפוסי או פונקציה פגיעה אחת שאפשר לתקן ולהמשיך הלאה. זהו פגיעה בשרשרת האספקה: התגלה קוד זדוני ב- קובצי tar של גרסאות קודמות של XZ Utils החל מגרסאות 5.6.0 ו-5.6.1, שם לוגיקת בנייה מוסתרת חילצה קובץ אובייקט שנבנה מראש מתוך ארכיון בדיקה מוסווה ושינתה פונקציות במהלך ה- liblzma תהליך הבנייה. התוצאה הייתה ספריית liblzma שעברה שינוי, אשר עלולה הייתה להשפיע על תוכנות המקושרות אליה. (NVD)

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

רוב אנשי האבטחה חיפשו את הסיפור הזה באמצעות כמה ביטויים פופולריים, המופיעים שוב ושוב בדיווחים על תקריות חמורות: דלת אחורית xz, דלת אחורית של XZ Utils, דלת אחורית של liblzma, ובשל ההשלכות המעשיות הצפויות, דלת אחורית ב-sshd. ההמשות בין מונחים אלה בהודעות השונות של הספקים אינה מקרית; היא משקפת את מה שהמגיבים היו זקוקים לו יותר מכל: היקף, חשיפה, ראיות, ו מסלול תיקון בטוח. (אקמאי)

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

נסה את הכלי AI Hacker >>

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

היא התמקדה בפער האמון בין קוד המאגר לבין התוצרים הסופיים

אחת העובדות החשובות ביותר בתיעוד הרשמי אינה ש"מישהו כתב קוד לקוי". בתיאור ה-NVD מצוין במפורש כי קובצי ה-tar של המקור כללו הוראות הרכבה נוספות שלא היו קיימות במאגר, וכי תהליך ההידור חילץ אובייקט מוכן מראש מקובץ בדיקה מוסווה כדי לשנות את liblzma בזמן ההידור. (NVD)

זוהי קטגוריה של איומים שונה בתכלית:

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

דף ה-backdoor של פרויקט Upstream עצמו ממחיש את היקף הליבה בצורה כואבת: קובצי ה-tar של גרסאות XZ Utils 5.6.0 ו-5.6.1 מכילים דלת אחורית, והוא אף דן בשאלה מי חתם על אילו קבצי tar, ובכך מחזק את הרעיון שמקורם של הקבצים והחתימה עליהם הם חלק מהסיפור, ולא תוספת של הרגע האחרון. (טוקאני)

זה היה קרוב מאוד, וממקרים כאלה לומדים

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

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

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

מה קרה? ציר זמן מהימן שתוכל לצטט

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

סוף מרץ 2024, גילוי וחשיפה

ברשימת התפוצה oss-security פורסמה הודעה פומבית המתארת תסמינים חריגים (ובפרט חריגות בביצועי SSH וסימני ניפוי באגים נלווים) שהובילו לחקירה מעמיקה יותר ולמסקנה כי במאגר xz ובקובצי ה-tarballs של הפרויקט המקורי הוכנסו דלתות אחוריות. (openwall.com)

הדיווח של Rapid7 על התגובה לאירוע מסכם את אותו אירוע חשיפה ומציין במפורש את הגרסאות המושפעות 5.6.0 ו-5.6.1, תוך התייחסות אליו כ-CVE-2024-3094. (Rapid7)

החל מ-29 במרץ 2024, תגובה מתואמת

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

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

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

בתחילת אפריל 2024, הורחבו ההנחיות בנושא איתור והגנה

Elastic Security Labs פרסמה ניתוח הכולל רעיונות מעשיים לזיהוי, לרבות חיפושים ב-YARA, osquery ו-SIEM, המסייעים לצוותים לעבור משאלה "איזו גרסה" לשאלה "אילו סימנים עליי לחפש". (אלסטי)

מיקרוסופט פרסמה שאלות נפוצות והנחיות למגינים, תוך שהיא מדגישה את הגרסאות שנפגעו ואת האופי של הבעיה כבעיה בשרשרת האספקה. (TECHCOMMUNITY.MICROSOFT.COM)

CVE-2024-3094

נסה את הכלי AI Hacker >>

הסבר על CVE-2024-3094: מודל האיום שתואם את המציאות

מה נכתב בתיעוד ה-CVE, ומדוע לניסוח יש חשיבות

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

כלומר, "המשטח הפגיע" אינו ממשק API בודד. הוא:

לשחרר תוצרים
התנהגות מערכת הבנייה
צינורות אריזה
קבוצת הצרכנים במורד הזרם שצורכים את האובייקטים הללו

למה כולם כל הזמן אמרו "דלת אחורית ב-sshd"

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

עם זאת, הפרשנות התפעולית המדויקת היא:

הרכיב שנפגע הוא liblzma
הניצול תלוי בתנאי ההידור והקישור/הטעינה הספציפיים
ההגדרה "כל מערכת שבה מותקן xz" אינה חלה באופן אוטומטי

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

מי הושפע מכך, וכיצד להימנע מלהפוך את תהליך הגדרת היקף הפרויקט למיתוס

גרסאות מושפעות בעלות רמת אמינות גבוהה

הפרויקט המקורי ו-CISA מצביעים שניהם על XZ Utils 0.6.0 ו-0.6.1 כגרסאות העיקריות שנפרצו. (טוקאני)

הרשומה ב-NVD מציינת גם פריצה המתחילה בקבצי tar החל מגרסה 5.6.0. (NVD)

מדוע החשיפה להפצות נוטה לטובת ענפי הפיתוח

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

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

הטעות בהגדרת היקף הפרויקט שיש להימנע ממנה

הרבה צוותים שאלו: "האם xz מותקן אצלנו איפשהו?"

זו שאלה ראשונה לא נכונה, כי היא יוצרת רעש. כמעט לכולם יש xz איפשהו.

רצף שאלות טוב יותר הוא:

האם יש לנו xz/liblzma 5.6.0 או 5.6.1 ניתן להתקין בכל מקום
אם כן, מאיפה הגיעו החבילות האלה, ומאיזה מסלול הן נלקחו?
האם המארחים הללו הם נקודות קצה SSH הפונות לאינטרנט, מערכות בנייה, שרתים מוגנים או תשתית בעלת ערך גבוה?
האם נוכל לאסוף ראיות לכך שכל הגרסאות שנפגעו הוסרו או הוחזרו למצב קודם?

אימות, בדיקות בטוחות וניתנות לשחזור עבור צי רכב

המטרה כאן אינה "לבצע הנדסה לאחור של הדלת האחורית". המטרה היא לגבש תשובה מבוססת היטב לשאלה:

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

פקודות מהירות לניהול מלאי צי

משפחת דביאן ואובונטו

# הצגת חבילות מותקנות הכוללות בדרך כלל את xz ו-liblzma dpkg -l | egrep 'xz-utils|liblzma' || true # הצגת גרסאות אפשריות ומקורות מאגרים apt-cache policy xz-utils liblzma5 2>/dev/null | sed -n '1,120p'

# גרסה מקומית מהירה xz --version 2>/dev/null || true

משפחת RHEL, Fedora ו-CentOS Stream

rpm -qa | egrep '(^xz|xz-libs|liblzma)' || true dnf info xz xz-libs 2>/dev/null | sed -n '1,160p' xz --version 2>/dev/null || true

משפחת ארכ

pacman -Qi xz 2>/dev/null | sed -n '1,140p' xz --version 2>/dev/null || true

אם אתה רואה 5.6.0 או 5.6.1, התייחסו לכך כאל עניין בעל עדיפות עליונה והתאימו את תגובתכם להודעות העדכון ולערוץ העדכונים של ההפצה שלכם.

בדוק מה sshd באמת טוען, בלי הנחות מוקדמות

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

הנה בדיקת בסיס בטוחה:

# אם sshd פועל, פרט את הספריות הממופות וחפש את liblzma או רכיבים קשורים pidof sshd >/dev/null && \\ sudo cat /proc/"$(pidof sshd | awk '{print $1}')"/maps 2>/dev/null | egrep 'liblzma|libsystemd' || true

# לחלופין, lsof יכול להציג אובייקטים משותפים פתוחים pidof sshd >/dev/null && \\ sudo lsof -p "$(pidof sshd | awk '{print $1}')" 2>/dev/null | egrep 'liblzma|libsystemd|sshd' || true

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

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

שאלה בנוגע להיקף	מה לאסוף	מה זה אומר	מדוע זה חשוב
האם יש לנו גרסאות שנפגעו?	רשימת החבילות המציגה את גרסאות xz/liblzma	מצמצם את היקף	5.6.0 ו-5.6.1 הם המוקד העיקרי (טוקאני)
האם הם הגיעו ממקורות מסוכנים?	תמונות מראה של רפו, מטא-נתונים של apt/dnf, יומני צינור הבנייה	מקור	CVE מתמקד בקבצי tar במעלה הזרם ובאריזה במורד הזרם
האם מעורבים כאן נקודות קצה בעלות ערך גבוה?	רשימת מעוזים, מערכות חשופות ל-SSH, רצי CI	עדיפות	מפחית את הסיכון במהירות על ידי התמקדות בתרחישי ההשפעה הסבירים ביותר
האם התיקון הסיר את כל ה-builds שנפגעו?	מלאי לאחר השינוי, ראיות חשיש במידת הצורך	סגירה	מספקת ראיות מבוססות עבור מבקרים וסקירות אירועים

רעיונות לזיהוי שעובדים גם כאשר הדלת האחורית הבאה נראית אחרת

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

מגנים טובים נוקטים בגישה רב-שכבתית:

נראות החבילה ו-SBOM
מקורו של חפץ
קווים מנחים להתנהגות בזמן ריצה
זיהוי חריגות בתהליכים מרכזיים

סימן להתנהגות חריגה, תהליכי-בן חריגים של sshd

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

הרעיון המוכח הוא פשוט:

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

חיפושים ב-osquery וב-SIEM: נקודת התחלה מעשית

Elastic Security Labs פרסמה תוכן זיהוי, כולל שאילתות osquery ו-SIEM, ששימשו את רבים מאנשי האבטחה כנקודת התחלה מעשית לתהליך המיון. (אלסטי)

רעיון כללי לשימוש ב-osquery שניתן ליישם בבטחה מבלי להעתיק כללים קנייניים הוא:

רשימת החבילות המותקנות עבור xz/liblzma
לבדוק אילו תהליכים פועלים ואילו ספריות נטענו
לקשר בין זמן הריצה של sshd לאובייקטים משותפים בלתי צפויים

דוגמאות לקטעי קוד של osquery:

-- חבילות, Debian SELECT name, version FROM deb_packages WHERE name IN ('xz-utils','liblzma5');

-- חבילות, RPM SELECT name, version, release FROM rpm_packages WHERE name IN ('xz','xz-libs','liblzma'); -- תהליכי sshd פועלים SELECT pid, name, path, cmdline FROM processes WHERE name = 'sshd';

שלמות הקבצים, התייחסות לקבצי tar כאל אובייקטים אבטחה

אירוע זה מצביע בבירור על הצורך להוסיף מנגנוני בקרה שיבדקו:

מקור קבצי ה-tar של המהדורות
חתימות וציפיות לגבי זהות החותם
בדיקות לשחזור או לבנייה מחדש עצמאית של רכיבים קריטיים

דף ה-backdoor של Upstream מציין במפורש את פרטי יצירת קובץ ה-tarball וחתימתו, ומדגיש מדוע יש לשלב בין אמון בחתימה לבין אמון בזהות ויכולת שחזור. (טוקאני)

CVE-2024-3094

נסה את הכלי AI Hacker >>

תיקון, מה לעשות עכשיו, מה לעשות בהמשך, מה לשנות לתמיד

תוכנית פעולה מיידית לריסון, השעה הראשונה

1. זיהוי וקביעת סדר עדיפויות

חפש מערכות עם xz/liblzma 5.6.0 או 5.6.1
קבעו סדר עדיפויות:
- נקודות קצה SSH הפונות לאינטרנט
- שרתים של Bastion
- רצים של CI ומערכות בנייה
- תשתית אריזה ומראות מאגרים

דבר זה עולה בקנה אחד עם המיקוד המעשי של התראות ה-CISA ותכני התגובה של הספקים. (CISA)

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

CISA המליצה לעבור לגרסה שלא נפגעה. (CISA)

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

גרסאות החבילה לפני ואחרי
חותמות זמן של תמונת מצב רפו
מסלול בקשת השינוי והאישור

3 אספו ראיות, כי יבקשו מכם

כאשר מתרחשים תקריות הקשורות לתשתית הכלים, ההנהלה ומבקרי הפנים מבקשים הוכחות. הכינו חבילת ראיות תמציתית:

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

התקשות בטווח הבינוני, בשבועיים הקרובים

זה המקום שבו רוב הקבוצות מפסיקות מוקדם מדי.

יש להבטיח את המקומות שבהם נוצרת האמון

CVE-2024-3094 מהווה תזכורת לכך שמערכות בנייה, רצים של CI וצינורות אריזה אינם "אמצעי נוחות פנימי למפתחים". הם מהווים "מפעלי אמון" ברמה של סביבת ייצור.

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

עשו את הדברים הבסיסיים שאתם נוטים לדחות:

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

הוסף מעקות בטיחות לערוצי הפיתוח והגרסאות המקדימות

רבים מהדיווחים בנושא החשיפה התמקדו במסלולי הפיתוח ובערוצי האימוץ המוקדם. מדריך השאלות הנפוצות של Tenable מהווה מקור מידע שימושי לגבי "מה הושפע" ככל שהתמונה התבהרה. (Tenable®)

מדיניות מעשית היא:

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

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

זהו החלק שההנהלה נוטה לכנות "עלויות תפעול". אך זה לא כך. זו המשכיות עסקית.

1. בניית גרסאות הניתנות לשחזור ואימות עצמאי של הבנייה מחדש

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

אין צורך בשחזור של 100% כבר מחר. התחל עם הנתיב הקריטי:

ספריות דחיסה
ספריות קריפטוגרפיה
רכיבים הקשורים ל-auth ול-PAM
ssh ומערכת הניהול מרחוק
לבנות את הציוד עצמו

2 מסגרות מקור: חתמו על מה שאתם מפיצים, אמתו את מה שאתם מתקינים

הדגש שהאירוע שם על קבצי tar ועל זהות החתימה מקשה להתעלם מבקרות ברמת האובייקטים. (טוקאני)

בסיס מודרני כולל:

אימות חתימות באמצעות שורשי אמון מפורשים
אישורי מקור עבור גרסאות
יצירת SBOM ושערי כניסה
תשתית מראות מבוקרת

3. יש לממן ולתמוך בשלבים המוקדמים, שכן ההיבטים הכלכליים הם חלק מהסיכון שלכם

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

זו אינה מוסר השכל מופשט. זוהי הצהרה מעשית בנוגע לסיכון:

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

לקחים לצוותי אבטחה התקפית: מדוע התוקפים אוהבים את השכבה הזו

אם אתם מכינים תוכניות לבדיקות חדירה או מדריכים לצוות האדום, CVE-2024-3094 מהווה תזכורת לכך שגישה ראשונית בימינו אינה מסתכמת רק ב"איתור באג באינטרנט". פריצה לשרשרת האספקה היא אטרקטיבית משום שהיא מאפשרת:

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

זהו ההבדל המרכזי בין "פגיעות" לבין "התמוטטות גבול האמון".

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

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

השוואת CVE-2024-3094 ל-CVE אחרים בעלי השפעה רבה: כיצד לקבוע סדר עדיפויות נכון

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

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

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

המסר המשותף אינו ש"ספריות הן מסוכנות". המסר הוא:

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

רגרסיה, השכבה הפרימיטיבית חוזרת שוב ושוב

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

אם בארגון שלכם מתייחסים ל"תיקון" כאל הפתרון המלא, CVE-2024-3094 מהווה דוגמה מובהקת לכך שזה לא כך. האיום אינו רק זמן ההשהיה של התיקון; הוא נוגע לאמינות ולשלמות.

נסה את הכלי AI Hacker >>

רשימת בדיקה מעשית שתוכלו להדביק בתהליך הטיפול בתקלות שלכם

הגדרת היקף

רשימת מארחים עבור גרסאות xz/liblzma, תוך התמקדות ב- 5.6.0 ו-5.6.1 (טוקאני)
זהו את נקודות הקצה של SSH החשופות לאינטרנט וקבעו את סדר העדיפויות שלהן
זיהוי רצות CI, בניית קופסאות, אריזת מראות, סביבות ביניים

אימות

אסוף את גרסאות החבילות והמקורות "לפני"
יש לבצע החזרה לגרסה קודמת או שדרוג בהתאם להנחיות ההפצה ולהמלצות ה-CISA (CISA)
לאסוף ראיות "לאחר מעשה" המעידות על גרסאות בטוחות בכל הצי
תאריכים, מזהי תמונת מצב של המאגר ואישורי שינויים

איתור

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

הקשחה

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

אירועים כמו CVE-2024-3094 ממשיכים לחשוף מציאות שצוותי האבטחה כבר חווים: ניהול פגיעות כבר אינו מסתכם ב"תיקון האפליקציה". רשימת התלות, שרשרת הבנייה והתנהגות בזמן ריצה מהווים חלק ממשטח התקיפה — במיוחד כאשר כלים וסוכנים פועלים בתוך רשתות רגישות. תהליכי העבודה שעומדים בלחץ הם אלה שתרגמו עמימות לפעולות קונקרטיות: מיון החשיפה, אימות התיקונים ובדיקה חוזרת ומתמשכת של סטיות באמצעות ראיות.

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

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