אם תזכרו רק דבר אחד על CVE-2023-43208, אז בואו נגיד את זה ככה: זה הפעלת קוד מרחוק עם אישור מראש באג ב- NextGen Healthcare Mirth Connect המשפיע על גרסאות לפני גרסה 4.4.1, והיא קיימת משום שבעיה קריטית קודמת, CVE-2023-37679, תוקן באופן חלקי — כך שנוצרה דלת שנייה לאחר שהראשונה "תוקנה". (NVD)

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

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

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

מהו CVE-2023-43208, במילים פשוטות

CVE-2023-43208 מתואר כפגיעות ב- NextGen Healthcare Mirth Connect איפה ביטול סידור נתונים שאינם מהימנים עלול להוביל ל הפעלת קוד מרחוק ללא אימות, ו גרסאות שקדמו לגרסה 4.4.1 מושפעים. NVD מציין במפורש כי הדבר נגרם על ידי ה- תיקון חלקי ל-CVE-2023-37679. (NVD)

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

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

ההודעה הפומבית של Horizon3 מסכמת את ההשפעה באופן ברור: גרסאות Mirth Connect שקדמו לגרסה 4.4.1 פגיעות ל- RCE ללא אימות, והפעולה המומלצת היא שדרוג. (Horizon3.ai)

מדוע פגיעות זו ממשיכה להופיע בפעילות האבטחה

הרבה פגיעות CVE קריטיות הן מסוג "מתקנים וממשיכים הלאה". CVE-2023-43208 היא ההפך הגמור: היא מהווה מקרה בוחן הממחיש מדוע ארגונים חוזרים ונפלים לאותו סיכון.

עקיפת תיקונים היא רעל לממשל

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

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

ההתראה הקיברנטית של שירות הבריאות הלאומי באנגליה (NHS England) היא ישירה באופן חריג עבור הודעה של המגזר הציבורי: היא מדגישה כי CVE-2023-43208 מהווה עקיפת תיקון של CVE-2023-37679, ומזהיר כי הדבר עלול לאפשר RCE ללא אימות. (NHS אנגליה דיגיטלית)

בהמשך הוסיפה CISA CVE-2023-43208 לקטלוג הפגיעויות הידועות שנוצלו, מה שמעיד בבירור על סדר העדיפויות ועל לוחות הזמנים לתיקון הבעיות בסביבות רבות. (CISA)

בהקשר של Mirth Connect, מדוע ה"צנרת" חשובה

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

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

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

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

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

NVD מסווג את CVE-2023-43208 תחת ביטול סידור נתונים שאינם מהימנים, וה-Huntress מתאר זאת כ-RCE הנגרם על ידי דה-סריאליזציה לא בטוחה, המתרחשת כאשר מטען זדוני מעובד לפני ביצוע בדיקות אימות נאותות. (NVD)

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

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

מדוע RCE באמצעות ביטול סריאליזציה מהווה בעיה תפעולית חמורה

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

הקשר ל-CVE-2023-37679, התיקון הבלתי שלם שיצר את CVE-2023-43208

הדיווח של NVD מפורש: CVE-2023-43208 נגרם על ידי תיקון חלקי של CVE-2023-37679. (NVD)

NHS אנגליה מכנה זאת גם "עקיפת תיקון" של CVE-2023-37679. (NHS אנגליה דיגיטלית)

Horizon3 מתאר את CVE-2023-43208 כפגיעות RCE ללא אימות ב-Mirth Connect וממליץ למשתמשים לשדרג לגרסה 4.4.1. (Horizon3.ai)

זה חשוב כי "תיקון חלקי" אינו באג בודד, אלא דפוס:

• תיקון עשוי לחסום שרשרת גאדג'טים אחת, אך להשאיר אחרות.
• רשימת חסימה עשויה לחסום סוג אחד, אך לא סוג מקביל.
• תיקון עשוי להוסיף בדיקות במסלול קוד אחד, אך לא במסלול החלופי.

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

ההשפעה: מה התוקפים יקבלו אם ינצחו

ברמה הגבוהה ביותר: הפעלת קוד מרחוק בשרת.

בסביבות אמיתיות, ערך התוקף נראה לרוב כך:

• הפעלה באמצעות חשבון השירות שמריץ את Mirth Connect
• גישה לקבצי תצורה, הגדרות ערוצים, פרטי הזדהות או מפתחות API המאוחסנים בסביבה
• תנועה רוחבית באמצעות נתיבי אינטגרציה מהימנים

ומאחר ש-Mirth Connect ממוקם בנקודת המפגש בין המערכות, שלב הניצול שלאחר הפריצה עלול לעבור במהירות מ"פריצה לשרת" ל"פריצה לצינור נתונים".

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

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

אתה רוצה לענות על שלוש שאלות:

1. האם אנו מפעילים את Mirth Connect במקום כלשהו?
2. האם יש מערכות כלשהן החשופות לאינטרנט או נגישות ממגזרים שאינם מהימנים?
3. האם הן בגרסה נמוכה מ-4.4.1?

איתור נכסים המתאים לסביבות מורכבות

התחילו עם מה שכבר יש לכם:

• רשומות CMDB המזכירות את המונחים "Mirth" או "NextGen"
• תמונות מכולות וקבצי compose
• תבניות VM המשמשות את צוותי האינטגרציה
• הגדרות פרוקסי הפוך שמנתבות לממשק המשתמש הניהולי של Mirth

לאחר מכן, בדוק זאת במארח.

בדוק את הגרסה בשרת

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

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

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

בדיקת חשיפה ללא ניצול

בדיקת חשיפה בטוחה מתמקדת ב- נגישות, ולא מטענים:

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

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

דוגמה לסריקת נגישות #; אין להתייחס אליה כאל אישור לקיומה של פגיעות nmap -Pn -sS -sV -p 80,443,8080,8443

זה רק מתאר את התמונה הכללית. זה לא מאשר את ה-CVE, ואין להציג את זה ככזה.

איתור: על מה יש לשים לב ביומנים ובנתוני הטלמטריה

מכיוון ש-CVE-2023-43208 היא פגיעות מסוג RCE הקשורה לתהליך ביטול הסידור, יש לתת עדיפות לזיהוי:

• דפוסי בקשות חריגים המגיעים לנקודות קצה ספציפיות של האפליקציה
• סימנים מחשידים הקשורים לסידור סדרתי או ל-XML
• התנהגות לאחר ניצול מתוך עץ התהליכים של Mirth

Huntress מתארת את מנגנון התקיפה ברמה הכללית כקובץ XML זדוני שעובד ללא בקרת גישה נאותה לפני אימות, מה שמאפשר ביצוע פקודות. (huntress.com)

יומני יישומים ויומני פרוקסי הפוך

חפשו:

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

גישה מעשית לרישום יומנים:

• יש לוודא שיומני ה-proxy ההפוך כוללים את נתיב הבקשה, קוד התגובה, הגודל, סוכן המשתמש וכתובת ה-IP של המקור
• ליצור קשר עם אירועי ביצוע של תהליכי שרת

טלמטריית נקודות קצה, האותות החזקים ביותר

אם יש לך EDR:

• שימו לב לתהליך Mirth Java שמפעיל מסופי פקודה
• שימו לב ליצירת קבצים זמניים או להנחתת מטענים
• שימו לב לחיבורים יוצאים חשודים שיוזם השרת Mirth

דוגמה לשאילתת Splunk, טבלת ציר של ביצוע תהליכים

זהו תבנית כללית שתוכלו להתאים לשמות השדות שלכם. היא אינה ספציפית ל-CVE, אלא ספציפית להתנהגות הניצול.

index=edr (parent_process_name="java" OR process_name="java") | search (command_line="*bash*" OR command_line="*cmd.exe*" OR command_line="*powershell*" OR command_line="*curl*" OR command_line="*wget*")
| סטטיסטיקה earliest(_time) כ-firstSeen latest(_time) כ-lastSeen ערכים(process_name) ערכים(command_line) לפי host, user, parent_process_name | מיון - lastSeen

דוגמה ל-KQL: תהליכים-בנים חשודים מ-Java

DeviceProcessEvents | where InitiatingProcessFileName =~ "java.exe" or InitiatingProcessFileName =~ "java" | where FileName in~ ("cmd.exe","powershell.exe","bash","sh","curl","wget")
| פרויקט Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, AccountName | סדר לפי Timestamp יורד

זיהויי רשת ו-WAF: שימושיים אך לא מספיקים

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

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

טבלה למיון מהיר, סימנים המצריכים העברה לדרג גבוה יותר

אות	מדוע זה חשוב	מה לעשות עכשיו
גרסאות של Mirth Connect הנגישות לציבור מתחת לגרסה 4.4.1	חשיפה ידועה ל-RCE קריטית לפני אימות	לבודד, לתקן, לבדוק אם התרחשה פריצה (NVD)
כלי עזר של Java להפעלת פקודות	אינדיקטור ניצול חזק	לשלוף את עץ התהליכים, ולבצע צילום זיכרון במידת הצורך
תנועה יוצאת חריגה משרת Mirth	שלב נפוץ לאחר ניצול	חסום את היציאה, חפש אחר עמידות
בקשות חוזרות ונשנות לכתובות קצה לא שגרתיות	בדיקת פגיעויות או אוטומציה	לבצע התאמה עם מערכות זיהוי וניתוח חדירות (IDS/WAF) ומערכות זיהוי ותגובה מרחוק (EDR)

תיקון נזקים – מה באמת מפחית את הסיכון במהירות

הפתרון האמיתי

שדרג ל Mirth Connect 4.4.1 או גרסה מאוחרת יותר. Horizon3 ממליצה במפורש לשדרג לגרסה 4.4.1, וה-NVD מציין כי גרסאות שקדמו ל-4.4.1 פגיעות. (Horizon3.ai)

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

אם אתה צריך להרוויח זמן:

1. הסר חשיפה לאינטרנט אם יש צורך לאפשר גישה אליו, יש להציב אותו מאחורי VPN או שער עם אימות חזק.
2. הגבלת ממשקי הניהול אפשר גישה רק מרשתות משנה ייעודיות לניהול.
3. הוספת פילוח רשת ובקרות יציאה רשתות RCE רבות הופכות ל"הורדת מטען + יצירת קשר עם השרת". סינון תנועה יוצאת יכול לחסום את השלב השני.
4. חיזוק יומני הגבירו את הרישום ב-proxy ההפוך ובטלמטריית המארח, כדי שתוכלו לענות מאוחר יותר על השאלה "האם הייתה פגיעה?".

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

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

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

לכל הפחות, שמרו את הראיות:

• פלט הגרסה
• תמונת מצב של התצורה המציגה את הגבלות הרשת
• לשנות הפניות לכרטיסים

מילות החיפוש ה"רלוונטיות ביותר" שאנשים באמת משתמשים בהן בהקשר ל-CVE זה, ומה הן מעידות

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

• הכיתוב "Mirth Connect unauthenticated RCE" מופיע ישירות במסגרת הגילוי של Horizon3. (Horizon3.ai)
• "ביטול סריאליזציה של נתונים לא מהימנים" הוא סיווג ה-NVD, והוא מופיע במסדי נתונים שונים של פגיעות אבטחה. (NVD)
• המונחים "פגיעויות ידועות שנוצלו" ו"קטלוג KEV" מופיעים בהתראה של CISA ומהווים מילות מפתח חשובות לקביעת סדר העדיפויות. (CISA)
• הניסוח "עקיפת התיקון של CVE-2023-37679" משמש במפורש על ידי NHS England ובהיסטוריית ה-NVD, מה שהופך אותו לביטוי חיפוש בעל ערך רב עבור אנשי אבטחה המאמתים את עבודת התיקון הקודמת. (NHS אנגליה דיגיטלית)
• "RCE לפני אישור" ו"דה-סריאליזציה לא בטוחה" – כך מסבירה Huntress את המנגנון לאנשי המקצוע. (huntress.com)

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

1. האם אני חשוף?: הגרסאות המושפעות, כיצד לבדוק, אילו יציאות
2. עד כמה זה דחוף: ניצול בפריצה, KEV, עקיפת תיקון
3. כיצד לזהות: כללי SIEM, IOCs, התנהגויות תהליכים

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

גישה בטוחה לאימות בתוכניות בדיקות התקפיות

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

תהליך עבודה אחראי נראה כך:

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

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

כאשר מדובר בפגיעות מסוג RCE לפני אימות (pre-auth RCE) בעלת רלוונטיות תפעולית נרחבת, החלק היקר הוא לעתים נדירות קריאת ה-CVE — אלא תהליך העבודה מקצה לקצה: איתור נכסים, אימות החשיפה, איסוף ראיות ודיווח חוזר ונשנה שאינו מסתכם בצילומי מסך ובידע פנימי.

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

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

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

פריט	ערך
CVE	CVE-2023-43208 (NVD)
מוצר	NextGen Healthcare Mirth Connect (NVD)
גרסאות מושפעות	גרסאות שקדמו לגרסה 4.4.1 (NVD)
השפעה	הפעלת קוד מרחוק ללא אימות (NVD)
מחלקת השורש	ביטול סריאליזציה של נתונים לא מהימנים, מסגור לא בטוח של ביטול סריאליזציה במדריכים מעשיים (NVD)
CVE קשור	תיקון עוקף או תיקון חלקי של CVE-2023-37679 (NVD)
אות קביעת סדרי עדיפויות	נוסף להתראות בקטלוג הפגיעויות המנוצלות של CISA (CISA)

הפניות

• הערך ב-NVD עבור CVE-2023-43208 (NVD)
• התראה של CISA על הוספת CVE-2023-43208 לקטלוג הפגיעויות הידועות שנוצלו (CISA)
• התראה סייבר של NHS אנגליה בנוגע לפגיעות ב-Mirth Connect (NHS אנגליה דיגיטלית)
• Horizon3.ai גילוי נאות בנוגע ל-NextGen Mirth Connect RCE (Horizon3.ai)
• רשומת CVE של Tenable עבור CVE-2023-43208 (Tenable®)
• דף ספריית האיומים של Huntress עבור CVE-2023-43208 (huntress.com)
• CVE-2023-43208 והפרצה שעקפה את התיקון והפכה את Mirth Connect לפגיעת RCE בעלת עדיפות גבוהה הפונה לאינטרנט (Penligent)
• CVE-2023-43208, פרצת ה-RCE של Mirth Connect לפני אימות שהפכה את תשתית האינטגרציה לאירוע ברמת האינטרנט (Penligent)
• Claude Code Security שובר את המודל הישן של סריקת קוד, וכולל קטע המתייחס ל-CVE-2023-43208 כאל דוגמה טיפוסית לעקיפת תיקונים (Penligent)