CVE-2025-20393 היא בעיה אבטחתית חמורה ביותר הקשורה לפריסות Cisco AsyncOS ב- שער דואר אלקטרוני מאובטח של Cisco (SEG) ו Cisco Secure Email and Web Manager (SEWM). הסיכון המרכזי אינו עדין: תוקפים יכולים לבצע פקודות מערכת שרירותיות עם הרשאות root במכשירים שנפגעו, והראיות מראות שזה כבר מנוצל בפועל. (NVD)

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

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

מהו סוג הפגיעות CVE-2025-20393?

ברמת הסיווג, NVD רושם את CVE-2025-20393 כ- CWE-20: אימות קלט לא תקין, עם וקטור בסיס CVSS v3.1 המעיד על מתקפת רשת, ללא צורך בהרשאות, ללא אינטראקציה של המשתמש, והשפעה מלאה על הפגיעה. (NVD)

מבחינה מעשית, מקורות רבים מסכמים את ההשפעה כך: ביצוע פקודה מרחוק, ללא אימות, עם הרשאות root במערכת ההפעלה הבסיסית של מכשיר מושפע. (בלוג Cisco Talos)

NVD מציג גם עדכון CISA KEV: תאריך הוספה: 17.12.2025; תאריך יעד: 24.12.2025, יחד עם הפעולות הנדרשות ליישום אמצעי ההפחתה של הספק או להפסקת השימוש אם אמצעי ההפחתה אינם זמינים. (NVD)

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

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

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

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

1. האם אנו מפעילים SEG או SEWM (פיזי או וירטואלי)?
2. האם ניתן לגשת להפרדת דואר זבל או לממשק ניהול האינטרנט מרשתות לא מהימנות?

אם התשובה לשתי השאלות היא "כן", התייחס לכך כאל אירוע עד שיוכח אחרת.

מדוע CVE זה מסוכן מבחינה תפעולית: שרשרת פריצות וכלי פריצה שנצפו

Cisco Talos מייחסת את הפעילות (עם ביטחון בינוני) לגורם איום סיני שהם עוקבים אחריו בשם UAT-9686, ומציין כי הקמפיין נמשך לפחות מאז סוף נובמבר 2025, כאשר סיסקו נוכחה לדעת על כך 10 בדצמבר 2025. (בלוג Cisco Talos)

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

• אקווה-של: דלת אחורית קלה במשקל של Python המוטמעת בקובץ קיים בתוך שרת אינטרנט מבוסס Python. היא מאזינה באופן פסיבי ל HTTP POST לא מאומת בקשות המכילות נתונים שתוכננו במיוחד, מפענחות תוכן ומבצעות פקודות במעטפת המערכת. Talos מצהירה כי היא ממוקמת ב- /data/web/euq_webui/htdocs/index.py. (בלוג Cisco Talos)
• AquaPurge: מסיר שורות יומן המכילות מילות מפתח ספציפיות מקבצי יומן שצוינו, באמצעות egrepסינון סגנון כדי לשמור על שורות "נקיות" ולכתוב אותן מחדש. (בלוג Cisco Talos)
• אקווטונל: קובץ בינארי Go מהודר המבוסס על ReverseSSH, המשמש ליצירת חיבור SSH הפוך אל תשתית התוקף. (בלוג Cisco Talos)
• אזמל: כלי מנהור בקוד פתוח התומך במנהרות TCP/UDP על גבי חיבור HTTP יחיד, שימושי עבור פרוקסינג ופיבוט באמצעות מכשיר קצה. (בלוג Cisco Talos)

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

IOCs בעלי אותות גבוהים ומה לעשות איתם

Talos פרסמה דוגמאות של חתימות SHA-256 עבור כלים (AquaTunnel, AquaPurge, Chisel) ומספר מצומצם של כתובות IP הקשורות לקמפיין, ומפנה למאגר GitHub לקבלת סט IOC המלא. (בלוג Cisco Talos)

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

• פגיעה חיובית על בסיס חתימת כלי או כתובת IP ידועה: יש לדווח מיד, לשמור ראיות, לפתוח תיק אצל הספק ולתכנן שחזור/שיקום.
• פגיעה שלילית: זה לא פוטר אותך; זה רק אומר שאתה צריך לבצע בדיקות התנהגותיות ובדיקות שלמות (מכיוון שהשחקנים מחליפים תשתית, ו-AquaShell עשוי לא להיות זהה מבחינת hash בין הקורבנות). (בלוג Cisco Talos)

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

1) בדיקות תקינות קבצים (נקודת התחלה)

# בדוק את חותמת הזמן וההרשאות של קובץ ממשק המשתמש האינטרנטי שהוזכר ב-Talos stat /data/web/euq_webui/htdocs/index.py

# בצע Hash והשווה לבסיס הייחוס הידוע כטוב (אם יש לך כזה) sha256sum /data/web/euq_webui/htdocs/index.py # אם אתה שומר גיבויים/תמונות מצב של תצורה, השווה בין הגרסאות diff -u /path/to/known-good/index.py /data/web/euq_webui/htdocs/index.py || true

Talos מציין במפורש את הנתיב הזה כמיקום שבו ממוקם AquaShell. (בלוג Cisco Talos)

2) סריקת IOC יוצאת ביומנים חיצוניים (מומלץ)

# דוגמה: grep עבור כתובות IP ידועות ביומנים שיוצאו (החלף נתיבים בטלמטריה שלך) grep -RIn --binary-files=without-match \\
  -E "172\\.233\\.67\\.176|172\\.237\\.29\\.147|38\\.54\\.56\\.95" \\ /var/log 2>/dev/null | head -n 200

כתובות ה-IP שלעיל פורסמו על ידי Talos כקשורות לקמפיין. (בלוג Cisco Talos)

3) ציד "POST יוצא דופן" (השתדל ככל יכולתך, אל תגזים)

# חפש פעילות POST באינטרנט הנוגעת לדפוס הנתיב המוזכר (אם קיימים יומנים) grep -RIn --binary-files=without-match \\ -E "POST|/euq_webui/|/htdocs/index\\.py" \\ /var/log 2>/dev/null | head -n 200

התנהגות AquaShell, לפי Talos, מסתמכת על בקשות HTTP POST לא מאומתות הנושאות תוכן פקודה מקודד. (בלוג Cisco Talos)

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

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

הקלות כאשר עדיין אין תיקון

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

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

המטרה האסטרטגית פשוטה: לצמצם את שטח התקיפה מהר יותר מהתוקף יכול לסרוק ולנצל אותו.

רצף פעולות מעשי להפחתת נזקים שצוותים יכולים לבצע כבר היום:

1. הסר חשיפה לאינטרנט לספאם בהסגר ולכל ממשקי הניהול.
2. הגבל את גישת הניהול לרשימה מצומצמת של אתרים מורשים (VPN + bastion בלבד).
3. תפקידים נפרדים: מישור הניהול לא צריך להיות אותו מישור חשיפה כמו מישור הטיפול בדואר. (BleepingComputer)
4. שמור יומנים וטלמטריה חיצונית לפני שתסובב משהו — Talos מתעד כלי לניקוי יומנים (AquaPurge), לכן יש להניח שהארכיונים המקומיים עשויים להיות לא שלמים. (בלוג Cisco Talos)
5. הפעל בדיקות תקינות בנתיב ממשק המשתמש באינטרנט שטאלוס מזכיר, וחפש כלי מנהרה. (בלוג Cisco Talos)
6. אם יש לך אינדיקציות לפריצה, לפתוח תיק ב-Cisco TAC (Cisco ו-Coverage ממליצים על נתיב זה לצורך אימות ותגובה לפריצות). (BleepingComputer)

שיפוץ לעומת "ניקוי במקום": היו כנים לגבי המציאות של המכשיר

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

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

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

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

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

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

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

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

הפניות

https://nvd.nist.gov/vuln/detail/CVE-2025-20393

https://www.cve.org/CVERecord?id=CVE-2025-20393

https://blog.talosintelligence.com/uat-9686

https://www.runzero.com/blog/cisco-secure-email-gateway

https://www.bleepingcomputer.com/news/security/cisco-warns-of-unpatched-asyncos-zero-day-exploited-in-attacks

https://www.cisa.gov/known-exploited-vulnerabilities-catalog

https://cwe.mitre.org/data/definitions/20.html

https://github.com/Fahrj/reverse-ssh

https://github.com/jpillora/chisel

https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sma-attack-N9bf4