Oracle Identity Manager (OIM) הוא סוג של מערכת שלא שמים לב אליה עד שהיא מתקלקלת. היא מספקת זהויות, מנהלת זכויות, מנפיקה או מתווכת גישה, ולעתים קרובות נמצאת במעלה הזרם של כל יישום ארגוני רציני. כאשר מתגלה פגיעות ב-OIM, לעתים נדירות מדובר ב"עוד CVE". CVE-2025-61757 הוא דוגמה קריטית: RCE לא מאומת, נגיש ברשת ברכיב REST WebServices של OIM, אשר עלול להוביל להשתלטות מלאה על שכבת הזהות. NVD מסכם זאת בפשטות: הגרסאות הנתמכות המושפעות הן 12.2.1.4.0 ו-14.1.2.1.0, ניצול דורש ללא אימות, מתרחש מעל HTTP, ותשואות פשרה בעלת השפעה רבה על פני סודיות, שלמות וזמינות, עם ציון CVSS 3.1 של 9.8 (קריטי). (NVD)
מה שהופך את ה-CVE הזה לראוי לקריאה מעמיקה יותר ברמה הנדסית הוא לא רק הציון שלו, אלא גם איפה זה חי. פלטפורמות זהות הן בסיס האמון של ארגונים מודרניים. תוקף מרוחק שמבצע קוד ב-OIM נמצא במרחק צעד אחד מזיוף זהויות, חבלה בהקצאת תפקידים או מעבר לשכבות תוכנה ואפליקציות סמוכות. במילים אחרות, CVE-2025-61757 הוא פרימיטיב של השתלטות על זהות, לא באג צר באפליקציה.
הניתוח הציבורי המצוטט ביותר: מדוע הרשת הזו עובדת
מבין המאמרים הזמינים לציבור, המאמר של Searchlight Cyber ("Breaking Oracle’s Identity Manager: Pre-Auth RCE") הוא כיום הניתוח המפורט ביותר המתייחס ל-CVE-2025-61757, והוא מצוטט על ידי SANS ומאתרי מעקב אחרים. (Searchlight Cyber) טענתם המרכזית היא שהפגיעות היא שרשרת דו-שלבית:
- א עקיפת אימות מקדים במסנן אבטחה מרכזי של Java המגן על משטח הניהול REST, ו
- התעללות ב פונקציית ניהול/סקריפט בעלת הרשאות גבוהות החשופה על ידי ממשקי REST API אלה, שהגיע לשיאו בהפעלת קוד מרחוק. (Searchlight Cyber)
המכניקה המדויקת של המטען אינה חשובה למגינים (ואין לחזור עליה מחוץ למעבדה מורשית). מה שחשוב הוא הדפוס: קלאסי "מסנן מרכזי + רשימת היתרים שברירית" עיצוב, שבו האימות נאכף על ידי התאמת URI של בקשות לרשימת היתרים מתירנית. באפליקציות Java ארגוניות מסורתיות, זה נפוץ; מבחינת אבטחה, זהו פוט-גאן חוזר ונשנה. אם בקרת הגישה שלך תלויה בהתאמת מחרוזות או ביטויים רגולריים בכללי ניתוח URI מורכבים, אתה מהמר על כך ש כל רכיב upstream מנרמל נתיבים באותו אופן. ההימור הזה נוטה להפסיד.
דרך בטוחה לתפוס את צורת הגורם השורשי היא להסתכל על גרסה מופשטת של ההיגיון:
// קוד מדומה הממחיש את האנטי-תבנית (לא קוד מוצר) if (request.uri.matches(ALLOWLIST_PATTERN) || request.query.equalsIgnoreCase("SPECIAL_CASE")) { chain.doFilter(request, response); // מדלג על אימות } else { enforceAuthentication(); }
ברגע שתוקפים מצליחים לעקוף את שער האישור, כל נקודת קצה מנהלית חזקה הופכת למקפצה פוטנציאלית לביצוע. המסקנה העיקרית של Searchlight אינה "נקודת קצה ספציפית זו מסוכנת", אלא "משטחי הניהול של REST בתוך מוצרי IAM כוללים לעתים קרובות קומפילציה של סקריפטים, ניהול מחברים או ווים של זרימת עבודה עם אמון מרומז." כאשר אלה נחשפים ללא אישור, אתה מקבל RCE על פי תכנון, ולא במקרה. (Searchlight Cyber)
הלקח ההנדסי הרחב יותר מועיל מעבר ל-CVE בודד זה: מסננים מרכזיים עם רשימות היתרים הם סוג של פגיעות מבנית. אם אתם מבצעים בדיקת קוד על שירותי Java שלכם (או מבצעים ביקורת על תוכנת אמצע של ספק), התייחסו ל"אימות רשימת אישור מרכזית" כאל סימן המעיד על צורך בבדיקה יריבה.
גרסאות מושפעות והקשר התיקון
Oracle תיקנה את CVE-2025-61757 ב- עדכון תיקון קריטי (CPU) לאוקטובר 2025, שפורסם ב 2025-10-21. (אורקל) הגרסאות הנתמכות המוזכרות במספר מעקבים הן:
| מוצר | רכיב | גרסאות נתמכות מושפעות | קו תיקון |
|---|---|---|---|
| מנהל זהויות Oracle (Fusion Middleware) | שירותי REST WebServices | 12.2.1.4.0, 14.1.2.1.0 | תוקן במעבד באוקטובר 2025 |
זה תואם את NVD, מאגר הפגיעות של Wiz, ואת דוח החשיפה של runZero. (NVD)
נקודה תפעולית עדינה אך חשובה: מעבדי Oracle הם רבעוניים. ארגונים שאין להם יכולת קליטה ופריסה חזקה של מעבדים נוטים לצבור "חוב תיקונים" בערימות הזהויות ותוכנות הביניים, מכיוון שהם נתפסים כמערכות יציבות עם שינויים מועטים. CVE-2025-61757 מפר את ההנחה הזו. זה לא באג שאפשר להשאיר ל"רבעון הבא" אם מישור הניהול REST שלך נגיש מרשתות לא מהימנות.
מציאות שטח התקיפה: מדוע CVE זה ייסרק במהירות
גם בלי לדון בפרטי הניצול, צורת וקטור CVSS מסבירה מדוע גורמים עוינים אוטומטיים מתעניינים בו. NVD ו-Wiz מפרטים אותו כך:
- AV:N (רשת נגישה),
- AC:L (מורכבות נמוכה),
- יחסי ציבור: לא/ממשק משתמש: לא (ללא הרשאות, ללא אינטראקציה עם המשתמש),
- C:H/I:H/A:H (השפעה מלאה). (NVD)
שילוב זה מהווה "אור ירוק" עבור סורקי סחורות. ברגע ש-PoC נוחת בערוצים ציבוריים, הוא הופך ל- טביעת אצבע בבקשה אחת + שרשרת המשך בבוטנטים. שרתים המזהים זהויות, החשופים באופן סמוי עקב תצורה שגויה של מנגנוני איזון עומסים, כללי NAT מיושנים או פרצות בתמיכה מרחוק של ספקים, נוטים להופיע במהירות בסריקות אלה.
יש גם בעיה רחבה יותר: תוכנת הביניים של Oracle הייתה יעד בעל ערך גבוה בשנת 2025, עם מספר באגים קריטיים שלא אומתו במוצרים נלווים (WebLogic, EBS, מודולי שיווק) שהפכו לקמפיינים פעילים. סקירת ה-CPU של Qualys מחודש אוקטובר מדגישה במפורש את הבעיות הקריטיות ב-Fusion Middleware כקבוצה בעלת סיכון גבוה. (Qualys) הדבר מגביר את הסבירות שתוקפים ינצלו את הפגיעה ב-OIM כדי לפגוע בפעילות הרחבה יותר של Oracle.
אימות הגנתי מבלי להפוך את הזיהוי לניצול
עבור רוב הצוותים, המשימה הראשונה היא פשוטה: לזהות חשיפה, ולא לחקות את התוקפים. תהליך עבודה בטוח ומורשה נראה כך:
- גרסאות OIM של המלאי בסביבות שונות ולהשוות מול שורות מושפעות.
- הגבלת גישת הניהול מיד (ACLs ברשת, שער VPN, ZTNA), עוד לפני חלונות התיקון.
- חפש חריגות בניהול REST ביומני הגישה: כתובות URI של בקשות בעלות אנטרופיה גבוהה, פרצי תעבורה מכתובות IP לא מוכרות, או נקודות קצה מסוג admin-class שהופעלו בשעות שבהן לא מתבצעים שינויים.
כדי להמחיש זאת, הנה מתאם גרסאות הגנתי בלבד שתוכלו לשלב במשימות ניהול הנכסים שלכם:
# הגנה בלבד: התאמת גרסאות OIM שהתגלו לקבוצה המושפעת מגרסת הייבוא של החבילה AFFECTED = [ ("12.2.1.4.0", "12.2.1.4.0"), ("14.1.2.1.0", "14.1.2.1.0"), ]
def is_affected(v: str) -> bool: v = version.parse(v) return any(version.parse(lo) <= v <= version.parse(hi) for lo, hi in AFFECTED)
for v in ["12.2.1.4.0", "14.1.2.1.0", "14.1.2.2.0"]: print(v, "affected?" , is_affected(v))
אם אינך יכול לחלץ גרסאות מבאנרים באופן אמין, תן עדיפות לנתוני CMDB פנימיים, למניפסטי חבילות מארח או למטא-נתונים של Oracle home. המפתח הוא להימנע מ"בדיקה" של שכבת הזהות שלך בדרכים המגדילות את הסיכון התפעולי.
ציד לאחר התיקון: איך ייראה הפשרה
שרשרת Searchlight מרמזת על סוג מסוים של התנהגויות שעליכם לשים לב אליהן, גם לאחר השדרוג:
- נקודות קצה של ניהול REST נפגעות ממקורות לא ידועים, במיוחד מטווחי IP ציבוריים.
- פעלי ניהול המשמשים מחוץ לחלונות שינוי, במיוחד כל דבר שמאגד, מעלה או משנה זרימות עבודה/מחברים.
- חשבונות שירות חדשים או שינויים בתפקידים שאינם תואמים את הפעולות המפורטות בכרטיס.
RunZero ו-Wiz ממליצים לבדוק את היומנים כדי לאתר פעילות REST חריגה ולהגביל את נגישות הניהול כחלק מהתחזקות, ולא רק כתיקון. (RunZero)
הסיבה שיש להתייחס לכך ברצינות לאחר התיקון היא שבאגים מסוג RCE לפני אימות מנוצלים לעתים קרובות. לפני גילוי. אם שכבת REST נחשפה, יש להניח שהיא נגעה.
הפחתה המפחיתה בפועל את הסיכון
ההנחיה הרשמית של Oracle היא להחיל את עדכוני ה-CPU של אוקטובר 2025, הכוללים את התיקון. (אורקל) מנקודת מבט הנדסית, הפעולות להפחתת הסיכון נערמות כך:
- תקן מיד בכל גרסה נתמכת מושפעת.
- הסר נגישות ציבורית של מישורי ניהול REST. ממשקי API לניהול זהויות לא צריכים להיות חשופים לאינטרנט.
- סובב אישורים מיוחדים ולדרוש MFA כאשר הדבר אפשרי מבחינה תפעולית.
- קו בסיס וניטור סטייה בתצורת OIM (תפקידים, מחברים, זרימות עבודה).
- פילוח שכבת ה-IAM כך שאפילו אם OIM נפגע, התנועה הרוחבית מואטת.
אין בזה שום חידוש, אבל CVE-2025-61757 הוא מקרה בוחן שממחיש מדוע לא ניתן להתייחס לחיזוק IAM כאל "הגדר ושכח". תוכנת אמצע זהות נמצאת כעת באותה רמת עדיפות מבחינת איומים כמו VPNs קצה ושערי אינטרנט.
מדוע CVE זה חשוב למהנדסי אבטחת AI
אם אתם עובדים בתחום המשלב בין מערכות בינה מלאכותית ואבטחה, OIM הופך להיות תלות מקורית רלוונטית יותר ויותר. אשכולות שירותי המודלים, פלטפורמות הנתונים, CI/CD ואפילו כלי LLM פנימיים שלכם יורשים לעתים קרובות החלטות גישה מ-IAM הארגוני. השתלטות מראש על תשתית הזהויות היא הדרך שבה תוקפים "מכשירים" את הפגיעה המאוחרת בערימת ה-AI: הם אינם צריכים להרוס שרת מודלים אם הם יכולים ליצור זהות שמאפשרת לשנות אותו.
מנקודת מבט של בינה מלאכותית הגנתית, CVE-2025-61757 מהווה תזכורת לכך שיש להתייחס לטלמטריית זהות כאל אות מדרגה ראשונה בתהליכי הזיהוי שלכם. אם אתם בונים כלי אבטחה סוכניים, ה"אוטומציה בעלת ההשפעה הרבה ביותר" המציאותית ביותר אינה יצירת ניצול ספקולטיבי — אלא מלאי בעל דיוק גבוה, מודלים של רדיוס פיצוץ ותזמור תיקונים עבור נכסי זהות ותוכנות אמצעיות.
הערה שקטה על אוטומציה (כאשר היא מתאימה)
בארגונים גדולים המשתמשים ב-Oracle, התפשטות הגרסאות היא תופעה אמיתית: מחלקות הפיתוח, בקרת האיכות, התאוששות מאסון ודיירים ותיקים לעיתים קרובות מפגרים ברבעונים. פלטפורמות אוטומציה עם מעורבות אנושית, כגון Penligent, יכולות לסייע בכך. מלאי גרסאות OIM בכל הצי, אימות חשיפה ומעקב אחר תיקונים, מבלי לדחוק את הצוותים לניצול מסוכן. כאשר הפגיעות היא קריטית ברמת הזהות, המהירות והדיוק בלולאה "איתור → תעדוף → תיקון" חשובים יותר מכל דבר אחר.
סגירה
CVE-2025-61757 אינו רק באג; זהו מסלול פגיעה ברמת הזהות בעל השפעה רבה, הנובע מדפוס אנטי-תבניתי ידוע ב-Java ארגוני. הפתרון המיידי ברור — יש לתקן את גרסאות ה-OIM המושפעות ולנעול את הגישה לניהול REST. הפתרון לטווח הארוך הוא רחב יותר: אם ניתן להגיע למטוס הבקרה של IAM, הוא יותקף — ומסנני רשימת ההיתרים המרכזיים יעקפו. התייחסו ל-CVE זה כאל פונקציית אכיפה לבדיקת האופן שבו מערכות הזהות שלכם נחשפות, מאומתות ומפוקחות.
